Public Key Management and X.509 Certificates

1. Public Key Management and X.509 Certificates CSIS 5857: Encoding and Encryption

2. Public Key Distribution • How does Bob know where a public key comes from? • Darth can: • Create a public/private key pair KDarthPR, KDarthPU • Send the public key KDarthPU to Bob, claiming it is from Alice • Ask Bob to send sensitive data encrypted with the public key • Intercept the data and decrypt it with his private key KDarthPR “Here is my public key KAlicePU– Alice” Secure data encrypted with what Bob thinks is Alice’s public key

3. Trusted Third Party Approach • Trusted center: • Verifies identities of users before registration • Stores list of public keys for registered users • Has key pair KTPr, KTPu • Will provide public keys upon request, signed by the trusted center with KTPr • All users know Trusted Center’s public keyKTPu

4. Trusted Center • Alice sends request for Bob’s public key to center • Includes timestamp to prevent replay • Trusted Center sends Bob’s key to Alice • Includes timestamp signed with Trusted Center’s private key • Alice verifies with Trusted Center’s public key.

5. Certification Authority • Problem: Trusted Center approach very inefficient • Might need to handle millions of requests at a time • Solution: public key certificates created by certification authority • Trusted third party (Verisign, Geotrust, etc.) • Well known public key • Certificate contains user’s public key, signed with CA’s private key • Any other user can validate certificate using CA’s public key

6. Certification Authority • Bob provides his public key to CA • CA verifies Bob’s identity • CA creates certificate with Bob’s public key signed with CA’s private key • Bob distributes certificate to public

7. X.509 Standard • Many known CA’s (Verisign, Geotrust, Equifax, etc.) • X.509 Standard provides common format for all certificates • Makes verification much simpler

8. X.509 Standard • Serial number: Unique ID assigned to certificate • Bob may have many certificates over time, need to be able to identify each • Signature algorithm ID: public key algorithm (RSA, etc.) this CA uses for its signatures • Need to know this to verify signature • Issuer name/unique ID: way to uniquely identify issuing CA • Need to know this to decide which CA’s public key to use for verification

9. X.509 Standard • Validity period: Expiration date after which certificate not trusted • For security, certificates and subject public key should be changed regularly • Subject name/unique ID: Way to uniquely identify subject (Bob) • Subject public key: public key + algorithm (RSA, etc.) subject uses • Sender needs to know this to encrypt messages to subject • Not necessarily same as issuer • Extensions: Other information subject wants signed • Biometrics, etc.

10. X.509 Standard • Signature created by CA: • Message digest created from all other fields • Signed with CA’s private key • Includes ID for hash algorithm used to create the message digest H(allfields) H(allfields) Dmod n

11. Verifying X.509 Certificates • Use indicated hash algorithm to create digest from all fields in certificate • Use CA’s public key to decrypt signature and get enclosed digest • If the two match, certificate is valid and has not been tampered with H(allfields) compare signature E mod n

12. Revoking X.509 Certificates • May need to make certificate invalid before expiration date • Subject’s private key compromised • Subject no longer trusted by CA • Example: CA issued to company subject no longer works for • CA’s private key compromised • Will need to revoke all current certificates issued! • Need way to inform all users about revoked certificates “I have you now!”

13. Certificate Revocation List • Issuer maintains revocation list • All unexpired certificates revoked (by certificate ID) • Signed by CA so can’t be faked or altered • Updated regularly • For greater efficiency, can post delta CRL with just new revocations since last update • User can check list before deciding to trust certificate

14. Public Key Infrastructure • Problem: May be difficult for one CA to manage thousands or millions of users • Solution: Hierarchical key management • Root CA validates other CAs • Other CAs validate users • May be many levels… Alice Bob

15. Public Key Infrastructure • One user can send another a chain of certificates to validate their public key • Terminology: X<<Y>> means authority X has signed certificate for user Y • Example: Alice sends her certificate to Bob • Alice sends certificates CA<<CA1>> and CA1<<Alice>> • Bob validates CA<<CA1>> using CA’s public key • Bob extracts the public key of CA1 from CA<<CA1>> • Bob validates CA1<<Alice>> using CA1’s public key • Bob extracts Alice’s public key from CA1<<Alice>>

16. Public Key Infrastructure Problem: • Alice and Bob may use different CA’s • Alice uses Verisign, has Verisign public key • Bob uses Equifax, has Equifax public key • How can Alice validate Bob’s certificate without the Equifax public key? Bob’s certificate signed with Equifax key Alice’s certificate signed with Verisign key Verisign public key ???

17. Public Key Infrastructure Mesh Solution: • Each certificate authority maintains certificates for all other certificate authorities • Can contact your CA to get certificate containing public key for other CAs • Can keep other useful information (revocation lists, etc.)

18. Public Key Infrastructure • Alice requests Equifax’s certificate from Verisign • Alice uses known Verisign key to extract Equifax key • Alice uses Equifax key to validate Bob’s certificate • Alice can also store the Equifax key for future use request validate Equifax’s certificate signed with Verisign key Verisign public key validate store Equifax public key Verisign Bob’s certificate signed with Equifax key