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

2. Outline Public key distribution problems Trusted center solution
Certification authority solution
X.509 Certificate standard
Creating and verifying X.509 certificates
Revoking certificates
The Public Key Infrastructure

3. 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

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

5. 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.

6. Certification Authority
Problem: Trusted Center approach very inefficient
Might need to handle millions of requests simultaneously
Solution: public key certificates created by certificate authority
Trusted third party (Verisign, Geotrust, Equifax, 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

7. 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

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

9. 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

10. 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.

11. Signing X.509 Certificates
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(all fields)
H(all fields) D mod n

12. 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(all fields)
compare
signature E mod n

13. 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!”

14. 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

15. 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
???

16. 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.)

17. Public Key Infrastructure
Alice requests Equifax’s certificate from Verisign
Alice uses known Verisign key to validate certificate and 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

18. Public Key Infrastructure
One user can send another a chain of certificates to validate their public key
Can send certificates for CA you use, signed by all other major CA’s, along with your certificate
Much more efficient to send in advance than having to request it at time of validation
Terminology: X<<Y>> means authority X has signed certificate for user Y

19. Certificate Chaining Example: Bob sends his certificate to Alice
Bob sends certificates Verisign<<Equifax>> and Equifax<<Bob>>
Alice validates Verisign<<Equifax>> using Verisign’s public key
Alice extracts the public key of Equifax from Verisign<<Equifax>>
Alice validates Equifax<<Bob>> using Eqifax’s public key
Alice extracts Bob’s public key from Equifax<<Bob>>