Certificate Systems, Public Key Infrastructures and E-mail Security

1
Certificate Systems, Public Key
Infrastructures and E-mail Security
2
Encryption using Public Key Cryptography
3
Digital Signature using Public Key Cryptography
4
Public Key Distribution

• Finding out correct public key of an entity
• Possible attacks
• name spoofing a person can identify himself
  using a bogus name
• denial of service the legitimate user cannot
  decrypt messages sent to him

5
Public Key Distribution

• Face to face public key exchange
• most primitive, but secure method
• not convenient
• Public announcement
• via newsgroups, web pages, etc.
• subject to forgeries
• hard to determine the liar

6
Public Key Distribution

• Diffie - Hellman (1976) proposed the public
  file concept
• public-key directory
• commonly accessible
• should be online always
• no unauthorized modification
• secure and authenticated communication between
  directory and user is a must

7
Public Key Distribution

• Popek - Kline (1979) proposed trusted Public Key
  Authorities
• Public key authorities know public keys of the
  entities and distribute them on-demand basis
• on-line protocol (disadvantage)

8
Public Key Distribution
9
Certificates

• Kohnfelder (1978) proposed certificates as yet
  another public-key distribution method
• Binding between the public-key and its owner
• Issued (digitally signed) by the Certificate
  Authority (CA)
• Off-line process

10
Certificates

• Certificates are verified by the verifiers to
  find out correct public key of the target entity
• In order to verify a certificate, the verifier
• must know the public key of the CA
• must trust the CA
• Certificate verification is the verification of
  the signature on certificate

11
Certificates
CA
Certified Entity
Albert Levi
Albert Levi
Albert Levi
Verifier
12
Certificates
13
Issues Related Certificates

• CA certification policies (Certificate Practice
  Statement)
• how reliable is the CA?
• certification policies describe the methodology
  of certificate issuance
• ID-control practices
• loose control only email address
• tight control apply in person and submit picture
  IDs and/or hard documentation

14
Issues Related Certificates

• TRUST
• verifiers must trust CAs
• CAs need not trust the certified entities
• certified entity need not trust its CA, unless it
  is not the verifier
• What is trust in certification systems?
• Answer to the question How correct is the
  certificate information?
• related to certification policies

15
Issues Related Certificates

• Certificate types
• ID certificates (for authentication)
• discussed here
• authorization certificates
• no identity
• binding between public key and authorization info
• Certificate storage and distribution
• along with a signed message
• distributed directories
• centralized databases

16
Issues Related Certificates

• Certificate Revocation
• certificates have lifetimes, but they may be
  revoked before the expiration time
• Reasons
• certificate holder key compromise/lost
• CA key compromise
• end of contract (e.g. certificates for employees)
• Certificate Revocation Lists (CRLs) hold the list
  of certificates that are not expired but revoked

17
Real World Analogies

• Is a certificate an electronic identity?
• Concerns
• a certificate is a binding between an identity
  and a key, not a binding between an identity and
  a real person
• one must submit its certificate to identify
  itself, but submission is not sufficient, the key
  must be used in a protocol
• anyone can submit someone elses certificate

18
Real World Analogies

• Result Certificates are not picture IDs
• So, what is the real world analogy for
  certificates?
• Endorsed document/card that serves as a binding
  between the identity and signature
• for example, credit-cards

19
Public Key Infrastructure (PKI)

• PKI is a complete system and defined mechanisms
  for certificates
• certificate issuance
• certificate revocation
• certificate storage
• certificate distribution

20
PKI

• Business Practice Issue certificates and make
  money
• several CAs
• Several CAs are also necessary due to political,
  geographical and trust reasons
• 3 interconnection models
• hierarchical
• cross certificates
• hybrid

21
Hierarchical PKI Example
22
Cross Certificate Based PKI Example
23
Hybrid PKI example
24
Certificate Paths
25
Certificate Paths

• Verifier must know public key of the first CA
• Other public keys are found out one by one
• All CAs on the path must be trusted by the
  verifier

26
Certificate Paths with Reverse Certificates
27
Organization-wide PKI

• Local PKI for organizations
• may have global connections, but the registration
  facilities remain local
• easy to operate
• less managerial difficulties

28
Organization-wide PKI
Certificate Processor/Authority
Certificate Distribution
Registration Authority
29
Hosted vs. Standalone PKI

• Hosted PKI
• PKI vendor acts as CA
• PKI owner is the RA
• Standalone PKI
• PKI owner is both RA and CA

30
Hosted vs. Standalone PKI
31
Hosted vs. Standalone PKI
32
X.509

• ITU standard
• ISO 9495-2 is the equivalent ISO standard
• Defines certificate structure, not PKI
• Also defines authentication protocols
• Identity certificates
• Supports both hierarchical model and cross
  certificates
• End users cannot be CAs

33
X.509 Certificate Format
34
X.509v3 Extensions

• Alternative names
• Policy Identifiers
• Trust issue
• Restrictions based one
• path length
• policy identifiers
• names
• No blind trust to CAs

35
Some X.509 based PKIs

• Privacy Enhanced Mail (PEM)
• hierarchical, no cross certificates
• first but discontinued
• Secure Electronic Transaction
• PKI for electronic payment
• secure but not widely deployed
• PKIX
• general purpose X.509 based PKI

36
DNSSEC

• Security extension to DNS
• Not X.509 based, but hierarchical (uses existing
  DNS topology)
• Distributed
• Provides
• authentication of domain information
• storage and distribution of certificates
• Good and practical system

37
SSL (Secure Socket Layer)

• Security layer over TCP/IP
• mostly for HTTP connections
• encrypted and authenticated sessions between web
  servers and web browsers (clients)
• Not a perfect solution, but a convenient solution

38
SSL (Secure Socket Layer)

• Certificate based systems
• web servers must have certificate
• client certificate is optional
• CA certificates are embedded in browsers
• You trust them (by default), because browser
  company says so !
• The worst, but the most practical !!!

39
Using SSL for HTTP Connections

• By using SSL we can
• make sure about the servers name (assuming the
  CA of the server is trusted)
• authentication
• make sure that nobody can see the traffic between
  client and server
• confidentiality

40
Using SSL for HTTP Connections

• By using SSL we can NOT
• provide perfect privacy
• server sees all information that client provides
• important in e-payment merchant sees the the
  card number and name
• provide non-repudiation
• both parties knows the session key
• in e-payment charge-back cost for merchants

41
PGP (Pretty Good Privacy)

• Effort of Phil Zimmermann
• Strong cryptography
• free of government control
• Has not started as a standardization effort
• Controversial international version
• Most widely used security software
• Unique certificate and PKI

42
PGP (Pretty Good Privacy)

• Free personal use
• Source code available
• very important for paranoids
• Multi-platform software
• Basically file encryption/signing software
• Now it has plug-ins for some E-mail client
  programs

43
PGP Cryptographic Functions
H Hash Function KR Private Key EP Public key
Encryption DP Public key Decryption Z
Compression using Zip KU Public Key
44
PGP Cryptographic Functions
H Hash Function KR Private Key Ks Session
Key (Conventional key) EP Public key
Encryption DP Public key Decryption EC Private
key Encryption DC Private-key decryption Z
Compression using Zip KU Public Key
45
PGP Cryptographic Functions
H Hash Function KR Private Key Ks Session
Key (Conventional key) EP Public key
Encryption DP Public key Decryption EC Private
key Encryption DC Private-key decryption Z
Compression using Zip KU Public Key
46
Encoding in PGP

• Binary data must be encoded for e-mail
  compatibility
• Radix-64 conversion
• binary data is grouped 6-bit by 6-bit
• each 6-bit group is converted to a printable
  ASCII character (table look-up)
• inflates the data 33
• Radix-64 applied to after encryption/signing

47
General PGP Message Format
48
Key Management in PGP

• Public keys are not attached to messages
• Instead Public key identifiers are put in
  messages
• Recipient should know/find out senders
  public-key
• personal exchange
• PGP public key servers
• do not trust the authenticity of the keys there

49
Key Management in PGP

• 2 local Key Rings
• private key ring
• to keep your private keys
• public key ring
• to keep yours and other peoples public keys

50
Private Key Ring

• Private-key Ring is a table for the private keys
• Private keys are stored in encrypted form
• Encryption key is derived from passphrase
• The keys in private-key ring are ultimately
  trusted
• Question How can we determine whether or not
  correct passphrase is entered?

51
Public-key Ring

• Table for locally known public keys
• Also contains trust information
• PGP user specifies his/her trusted CAs
• two levels of trusts to CAs
• being in public-key ring does not mean its
  legitimacy
• a public-key signed by a key in private-key ring
  is legit
• otherwise CAs signatures are checked
• complicated scheme

52
Public-key Ring
53
PKI of PGP

• Global public-key ring
• PKI from scratch
• Public-keys are certificates are posted in
  public-key servers
• Thousands of users
• No boss, no governing body

54
PKI of PGP

• Everybody is end user, everybody is CA
• chaotic

55
S/MIME

• A standard way for email encryption and signing
• IETF standard
• Industry support
• commercial reasons
• Not a standalone software, a system that is to be
  supported by email clients

56
History of E-mail

• RFC 822
• only ASCII messages
• MIME (Multipurpose Internet Mail Extensions)
• content type
• Almost any of information can appear in an email
  message
• S/MIME Secure MIME
• new content types, like signature, encrypted data

57
S/MIME

• General functionality is similar to PGP
• digital signature
• the hash of message is signed
• encrypted data (enveloped data)
• a conventional session key is used to encrypt the
  data
• that key is encrypted by the recipients public
  key
• The difference between S/MIME and PGP is
  certificate management

58
Certificate Management in S/MIME

• CA-centered system like SSL
• An ordinary user is not aware of the CAs that
  he/she trusts
• CA certificates come with the client software
• Certificates are sent along with the signed
  messages in S/MIME (unlike PGP)

59
Certificate Management in S/MIME

• One should get a certificate from a CA in order
  to send signed messages
• Verisign Certificates
• Class 1
• Class 2
• Class 3

Increased Security
Harder to issue
60
Whats Wrong?

• Loose control for Class 1 certificates for
  commercial reasons
• visibility
• market share
• The system becomes less secure for the name of
  security

61
What should be done?

• Class 1 certificates must be discontinued
• All certificate must be issued with a personal
  presence requirement or by the approval of
  trusted registration authorities

62
Discussion on Personal Certificates (SSL)

• Certificates ruin your privacy
• Do you really need a certificate?
• Do you want to get caught when you are at a
  specific website?
• Do you want spammers to get your email address?
• Do you want companies to learn your favorites?

63
Discussion on Personal Certificates (S/MIME)

• There is no wide use of certificates
• Only few email clients are supporting S/MIME
• Interoperability problems among the email client
  programs