Public Key Management and X.509 Certificates

CSCI 5857: Encoding and Encryption

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)

signature E mod n

compare

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

Bob’s certificate signed with Equifax key

Verisign public key

Verisign

request

Equifax’s certificate signed with Verisign key

validate

validateEquifax public key

store

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