Certificates

Robin Burke

ECT 582

Last class

Public key cryptographySolves what problem?

New problempublic key identity

Man-in-the-middle attack

Eve intercepts all communications Masquerades as both Bob and Alice Bob thinks he has Alice's public key

but he doesn't How can Bob know for sure?

Complex

This issue highlights the problems of trust in the digital world

A lot of infrastructure needs to be in place Digital certificates Multiple collaborating certification authorities Registration authorities Certificate directories Certificate revocation servers

Trust

We can't trust the public key associated with a

message We might trust

an authoritative source to vouch for Alice

Trusted third party

Certification authority (CA) CA can

meet with Alicelook at her driver's license / birth

certificate / etctake her fingerprints

CA will thensign her public key

Man-in-the-middle?

When Eve tries to substitute her public key for Alice'sBob will either notice that the key isn't

certified, orNotice that it is certified but not for

Alice, for someone else

Masquerading as CA?

Eve could falsely issue a certificate and sign the certificate pretending to be the

CA But

the CA is a big institution strong interest in making its correct public

key well known Multiple sources to access the CA's public

key Some public keys are actually bundled with

IE

Public key certificate

A public key An identifier

whose key? The whole package signed by the CA

Benefits of certification

Alice and Bob can exchange certificates directlyno need for a separate way to

communicate public keyscertificate is self-protecting

Many users can participateonly need to know CA's public key

Issues

Trust in the CAissuance policies

Security of the CA's private keyvery important!!!

Multiple CAs

If there is only one CAall is simple

Multiple CAsAlice's public key is signed by C1Bob's public key is signed by C2

How can Bob be confident?maybe C1 is really Eve in disguise

Solutions

Full distribution every user has the public key for every CA impractical

Cross certification Suppose Alice presents Bob with C1's

public key Signed by C2 Bob can verify the certificate C1's public key can be trusted Therefore Alice's public key can be

Hierarchical trust model

Root CA a generally-trusted CA

• Federal Reserve Bank all parties trust root

Non-root CAs have certificates signed by root CA, or signed by another non-root CA

• closer to the root CA Certification path

the chain of certifications from the root to a particular public key certificate

More about this next week

CA relationships

Intra-organization communication Bank ATM network Organization can be its own CA

Open communication CA is an independent entity third party CA

The third party CA is like a notary public is evaluating the truth of a person's representation may be liable if due diligence is not performed

Validity

Public key is not valid forever limits risk associated with key compromise 1 year is typical

Certificates have a valid period expired certificate may still be useful (non-

repudiation) new certificate issued when old one expires

• Possibly the same key re-certified

Certificate assumptions

During the valid periodpublic key is valid for useassociation with identity assumed

correctrevocation notifications will be

published

Revocation

What if Eve hacks into Bob's computer and steals his private key?Alice will still be sending encrypted

messages, but now Eve can read Certificate must be revoked

can no longer be trustednew certificate issuedhow does Alice find this out?

Revoking a certificate

Reasons for revocationDetected or suspected compromiseChange of data

• e.g. subject name

Change of relationship between subject and CA

• e.g. employee quitting a job from an organization which uses the current CA

Who can revoke?

who revokes?the subjectthe CAan authorized third party

• e.g. the organization with an employee quitting

Authentication of the source of revocation request is needed.

What happens?

The CA determines that the revocation request is valid

Then adds the certificate to its "certificate revocation list"CRL

CRL

CRL is a time-stamped list of revoked certificates, digitally signed by the CA available to all users

Each revoked cert is identified by a certificate serial number

CRL contains digital signatures, thus can be sent via unprotected channels

Users of public key certificates should check a suitably-recent CRL

Note

The user of a public key must check the CRL every time the key is used not enough to check when the certificate is

originally accepted CA

must keep a revoked certificate in the CRL until it expires

list could get large

Suitably recent?

Question of riskwhat is the risk associated with a

possibly out-of-date CRL CRLs are distributed regularly

e.g. hourly, daily, biweekly, etc “off-cycle” CRL can be issued

how to detect missing off-cycle CRL?

Example

Eve steals Bob's private key Bob discovers break-in

requests certificate revocation Eve sends a forged message to Alice Alice verifies message

checks CRL no problems with Bob's public key

CA publishes CRL with Bob's revocation too late

CRL Distribution

Pull methodCA periodically updates CRL

depositoryusers check when using a public key

Push methodbroadcast new CRL when it changes

Both subject to denial of service attacks

Online status checking

Online Certificate Status Protocol Alice checks Bob's public key directly with the CA

most effective most costly

Costs handling traffic for every public key use handling cryptographic operations at high spped maintaining high security in Internet environment

Also subject to denial of service attack

Short-Lived Certificates

Certificate valid for 1 day at a time re-requested each day possibly the same public key

Revocation not necessary client stops asking for a new certificate

Suitable for limited resource systems e.g. mobile wireless systems

Assumes efficient certificate generation

Liability

Who gets sued?depends on the timelinedepends on legal framework

b. Key Compromise

a. Issue of CRL 1

c. Revocation Request

d. Revocation Time e. Issue of CRL2

Time

Key pair management

Public and private keys are generated together Afterwards, different lives

Private key some kind of secure storage

Public key self-signed certificate certification then public distribution

Generation

Local generationprivate key never leaves the

environment where it is usedrequired by ANSI security standards

Central generationprivate key must be communicated to

user

Protecting the private key

Smart card more secure but more expensive less portable

Encrypted data file PGP's key ring

Centralized credentials server digital wallet

Key pair management

Public key functionsencryptiondigital signature

Different requirements

Encryption

Encrypted files and messages may be stored indefinitely

If private key is lostthe data is effectively garbage

Private key may need to archivedmore or less permanently

Key life cycle: encryption

Encryption

Decryption

Certificate validity:

Public key usage:

Private key usage:

Alice encrypts a message to Bob.Will use public key if

certificate is in valid periodcertificate not revoked

Signature

Key compromise extremely hazardouseven for historical documentsnon-repudiation lost

A lost signature key can always be replaced for signing the next document

Private key must be securely destroyed

Key life cycle: signature

SigningValidation

Cert validity:

Cert usage:

Public key usage:

Private key usage:

Alice validates a signed message from Bob.Will use public key if

valid period andcertificate not revoked

Will keep public key for historical validation

Key life cycle: real-time validation

Alice installs software sold by Bob

Bob's signature verifies uncorrupted code

Will use software if

certificate is valid at installation time

Private key may have short life

Sign

Install

Cert validity:Public key usage:

Private key usage:

Also

Different constraints on signature vs encryptionencryption may be regulateddifferent algorithms may be preferred

DSA doesn't support encryptionreason for development

Solution

Multiple key pairsEncryptionSigning

PGPallows generation of either an

encryption or signing key

Issuing a certificate

Alice generates a key pairprivate key stored on hardware devicepublic key self-signed

Alice sends the self-signed public keyto who?

Possibly the CAmore likely an intermediary for the CA

Registration authority

An agent for the CADeals with people

Frees the CAto deal with bits

May be internal to an organizationeven if CA is external

RA's responsibility

Gets Alice's certificate request public key

Verify Alice's identity testimonial email ping documents personal presence etc.

Forward request to CA Handle all of Alice's other key management needs

revocation expiry updated information

CA's responsibility

Verification of identityor requisite trust in RA

(Very) Secure signing operation Certificate returned to requestor

possibly archivedpossibly made available to public

Transaction recorded in audit journal

CA's key management

CA keys have many uses signing (real-time validation) historical validation

Short-use private keys better security

But a signed certificate can't have a valid period

beyond the signer's certificate CA will need multiple keys for different

purposes

Break

Certificate distribution

Alice sends Bob a two line signed email signature ≈ message size certificate > message size

• Alice's public key + CA's signature

certificate for each CA in certification path Certification info could easily be 10x the

message size What if Bob already has Alice's public key?

Certificate + Signature

Inefficient Not practical in network environment Different users might need different

certification pathscan't predict which certificates to

include Doesn't work for encryption

Directory services

General case for public key discovery Online access to a directory

request a public key certificate for a given user

In this caseAlice sends only the signed messageBob is responsible for getting Alice's

certificate

Directory services

ProprietaryNovellMS Active DirectoryLotus Notes

Older standardX.500

NewerLDAP

X.500

Developed by the international standards bodies

Extremely general look up by name browse available entities representing people, devices, applications,

etc. Extension for public key certificates

X.509

LDAP

Useful subset of X.500 Easier to implement than X.500 Widely available

Uses X.509 certificates

X.509

A certificate is a data structure Typically communicated in a binary

formatASN.1

If we were starting over todaywe'd use XMLXML didn't exist in 1988

Certificate format

Certificate fields

Version 1,2,3 or 4 3 is the most widely used

Serial no assigned by CA

Signature algorithm id for CA's signature

CA id Subject id Subject algorithm id Public key Some other stuff CA's digital signature

IDs

Many things need to be identified what algorithm? who is the CA? whose key are we signing?

X.500 Names every unique individual must have a unique name hierarchical naming scheme

X.500 Object Identifiers for things like algorithms also hierarchical but with integer components

Directory Information Tree

Country C=US, Canada, Mexico, etc.

Organization O=DePaul University, UIC, Northwestern

University, etc. Organizational uint

OU=CTI, LA&S, Commerce, Theater, etc. Common Name

CN=Robin Burke, Yonghe Yan, etc.

Distinguished name

A collection of choices at each level of the DITleading to an individual

Not necessarily a personprinter, router, application, web server

DN{C=US, O=DePaul University,

OU=CTI, CN=Robin Burke}

Name collision

Typically we augment the common name with some other identifieremployee / student idemail address

Object identifiers

Problem different organization may want their own

"objects" impossible to create a list of legal values in

advance Like DIT tree

but with integers Used to label

algorithms certificate types

Example

1.2.840.113549.1.1.5 this is a digital signature algorithm SHA-1

from RSA Labs How do we know this?

1 = ISO 2 = Indicates a member of the organization 840 = the USA 113549 = RSA's organizational id RSA chooses the rest of the identifiers

Id tree

OID: 1.2.840.113549.1.1.5

0 (itu-t) 1 (iso) 2 (joint-iso-itu-t)

2 (member-body)

840 (us)

113549 (rsadsi)

1 (pkcs)

1 (pkcs-1)

5 (sha-1WithRASEncryption)

16 (country)

840 (us)

1 (organization)

15678 (sharons)

X.509 Version 3

Versions 1 and 2 of X.509 did not work well for public key management

Problemsmultiple public keys per useradditional required information for

some purposesall certificates not created equal

X.509 Extensions

Instead of fixing all the fields in v. 3an "extension mechanism"allow organizations to define their own

certificate components Extensions

must be registered (object identifier)criticality indicator

Standard extensions

Authority key id CA's may have multiple signing keys helps to build certification path

Key usage what the certified key is for

Certificate policies under what policy was the certificate issued degree of authentication

Path constraints what is a legal certification path from this

certificate

Version 3 naming

Much more flexible naming schemeX.500 names OK

Othersemail addressdomain nameIP addressURL

X.509 CRL format

Similar to certificate itself Also

date/time of issue of this CRL date/time of issue of next CRL

List of revoked certs:user certificate: cert serial numberrevocation date

CRL extensions

Summary

public keys essential to secure communication

public keys must be associated with identitiescertificates

who do we trust to do the certifying? certificates must be managed

created, stored, retrieved, revoked