X.509

Topics

PGP

S/MIME

Kerberos

Directory Authentication Framework• X.509 is part of the ISO X.500 directory standard. • used by S/MIME, SSL, IPSec, and others

1) a standard certificate format

Important Components of X.509

2) a standard scheme for implementing certificate authorities

3) standard authentication protocols

4) a digital signature “standard” • no particular cipher is dictated, but RSA is recommended• no particular hash is dictated.

VersionCertificate Serial #

Dig. Sig. (algorithm & parameters)Issuer name (CA)

Start DateEnd Date

Subject name

Public Key (algorithm & parameters)Public KeyIssuer ID

Subject IDExtensions

Dig. Sig. (algorithm & parameters)Digital Signature

• Simple authentication occurs when two subjects are issued certificates from one CA.

• CAs issue certificates to subjects.

ExampleA

B C

D

Ole

Lena

Sven

NotationA, B, C, and D are CAs.Ole, Sven and Lena are subjectsCertificate: Issuer «Subject»

D «Ole» D «Sven»

C «Lena»

Suppose Ole wants to validate Sven.

... but what if Ole wants to send a message to Lena?

• A subject can transmit his/her certificate to a different subject.

Example (cont’d)A

B C

D

Ole

Lena

Sven

NotationA, B, C, and D are CAs.Ole, Sven and Lena are subjectsCertificate: Issuer «Subject»

D «Ole» D «Sven»

C «Lena»

For Ole to validate Lena

B «D»D «B»

General authentication requires CAs to exchange certificates, supporting certificate chaining.

A «B»B «A»

A «C»C «A»

Note: two kinds of certificates: forward - holder is subject, issuer is another CA reverse - holder is issuer, subject is another CA

He obtains ___________ & validates B as a CA using D’s public key.He obtains ___________ & validates A as a CA using B’s public key.He obtains ___________ & validates C as a CA using A’s public key.He obtains ___________ & validates Lena using C’s public key.

Certificate Chain:

Assume that Ole wishes to authenticate Lena. There are three possible protocols.

One Way

NotationSig denotes a digital signature (an MD encrypted

with the sender’s private key)TimeStamp consists of optional generation time

and expiration timenonce is a random number unique until expiration time

TimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub)

Ole LenaThis establishes a) the integrity of the message b) the identity of the sender (Ole) c) that the message is intended for Lena (confidentiality)

Notes: 1) a message could also be sent this way (protected by Sig). 2) session key is optional.

Two WayTimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub)

Ole Lena

This establishes additionally a) the integrity of the reply b) the identity of the receiver (Lena) c) that the message is intended for Ole

Ole Lena

TimeStamp2 || nonce2 || IDOle || Sig || E(SessionKey, KOlePub)

Three WayTimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub)

Ole Lena

Ole Lena

TimeStamp2 || nonce2 || IDOle || nonce1 || Sig || E(SessionKey, KOlePub)

Ole Lena

nonce2 || Sig

This echos nonces to avoid replay w/o time stamps.

• 1991 - PGP created by Phil Zimmerman

• widely-used secure email standard

• 1996 purchased by Network Associates

Brief History

Ring of Trust• Each user maintains a trusted keyring (public keys) and an owned keyring (private keys).

• Keys may be retrieved from a server or included at the end of a message.

• Each key is signed by owner (and possibly others).

• Trust is based on who signed the key.

• Subject discretion ultimately determines who to trust.

• Keys can be revoked by the owner.

• create a random session key (for symmetric cipher)

• encrypt/decrypt session key using public key (RSA or Diffie-Hellman)

• encrypt/decrypt message using session key (IDEA, 3DES or CAST-128)

Potential PGP Operations

• generate & encrypt (or decrypt) MD (SHA-1) using private key

• attach encrypted session key (as a digital signature) to a message

• transmit message

Private Key RingTime Stamp

Key ID

Public Key (of pair)

Private Key (of pair)

User’s ID

least significant 64 bits of public key

usually the user’s email address

Public Key RingTime Stamp

Key ID

Public Key (of pair)

User’s ID

PGP uses the concept of a one-time session key

Typical Message Format (from Lena to Ole)ID of KOlePub

E( SessionKey, KOlePub )

TimestampID of KLenaPub

Leading two octets of MD

E( MD, KLenaPriv )

File NameTimestamp

Data

This part is firstcompressed (zip)then encrypted withSessionKey

The entire transmissionis encoded in radix-64.

Why use a one-time (session) key?

Certificate Processing • Uses X.509v3 certificates

S/MIME -- Secure / Multipurpose Internet Mail Extensions

Originally developed by RSA

• Responsibility for maintaining certificates is local.

• Certificates are signed by a Certificate Authority

Typical Functions• The client must generate keys.

• A pair of generated keys are registered with a CA.

• The CA supplies certificates in X.509 format.

• The client can maintain a list of trusted certificates.

• CAs - VeriSign, GTE, Nortel, U.S. Postal Service

Class 1

Class 2

Class 3

Algorithms• must support SHA-1 (should support MD5 for backward compatibility)

• must support DSS (should support RSA-512 and RSA-1024 for digital signatures)

• must support RC2/40 with one-time key and should support 3DES

• session key encryption with Diffie-Hellman is preferred (RSA is possible)

VeriSign Certificates Classes

VeriSign required unambiguous nameand email address, PIN is emailed to user

VeriSign does online database search andsends digital ID & PIN to postal address

Client must prove identity via notarypublic or appear in person

Web browsers,email

online subscriptions,secure email

banking, secure database,membership-basedservices, e-commerce

• Kerberos is an authentication system - authenticating users and services.

• It was originally developed as part of Project Athena - MIT.

• Kerberos relies upon a centralized Kerberos server per realm.

• A kerberos server must contain a database of user IDs and hashed passwords.

• A kerberos server must share a secret key with registered servers.

• Multi-realm communication is also possible.

• The client can maintain a list of trusted certificates.

Weaknesses

Alternative 1

NotationOle is the clientAS is the authentication/Kerberos serverpwdC is the password for CIPC is the IP address of CkeyS key shared by AS and server S

IDOle || pwdOle || IDS)

Ole AS

Ole AS

TicketS ==

Ole S

Ticket || IDOle E( IDOle || IPOle || IDs, keyS )

Weaknesses 1) lifetime 2) server is never authenticated to the client

Alternative 2IDOle || IDTGS

Ole AS

Ole ASTicketTGS

Ole TGS

IDOle || IDS || TicketTGS

E( IDOle || IPOle || IDTGS || Lifetime1 || TimeStamp1 , keyOle)

loginTGS -- ticket granting server

Ole TGSTicketS

E( IDOle || IPOle || IDS || Lifetime1 || TimeStamp2 , keys )

key based on Ole’s pwdto obtain service

Ole S

IDOle || TicketS once per service session

Version 4 protocolIDOle || IDTGS || TimeStamp1

Ole AS

Ole AS

Ole TGS

IDS || TicketTGS || E( IDOle || IPOle || TimeStamp3, keyOle&TGS )

E( KeyOle&TGS || IDOle || IPOle || IDTGS || TimeStamp2 || Lifetime2, keyTGS)

login

Ole TGS

E( KeyOle&S || IDOle || IPOle || IDS || TimeStamp4 || Lifetime4, keys )

to obtain service

Ole S

once per service session

E( KeyOle&TGS || IDTGS || TimeStamp2 || Lifetime2 || TicketTGS, keyOle )

TicketTGS ==

E( KeyOle&S || IDS || TimeStamp4 || TicketS, keyOle&TGS )

TicketS ==

TicketS || E( IDOle || IPOle || TimeStamp5, keyOle&S )

Ole SE( 1 + TimeStamp5, keyOle&S )

Version 5 protocol

Ole S

once per service session

Options || TicketS || E( IDOle || RealmOle || TimeStamp2 || subkey || seq#, keyOle&S )

Ole SE( TimeStamp5 || subkey || seq#, keyOle&S )

Options || IDOle || RealmOle || IDTGS || Times || Nonce1

Ole AS

Ole AS

E( Flags || KeyOle&TGS || RealmOle || IDOle || IPOle || IDTGS || Times, keyTGS)

login

E( KeyOle&TGS || Times || Nonce1 || RealmTGS || IDTGS, keyOle )

TicketTGS ==

RealmOle || IDOle || TicketTGS ||

Ole TGS

Options || IDS || Times || Nonce2 || TicketTGS || E( IDOle || RealmOle || TimeStamp1, keyOle&TGS )

Ole TGS

E( Flags || KeyOle&S || Realm || IDOle || IPOle || Times, keys )

to obtain service

E( KeyOle&S || Times || Nonce2 || RealmS || IDS, keyOle&TGS )

TicketS ==

RealmOle || IDOle || TicketS ||

• Version 4 required the use of DES - Version 5 supports the use of algorithm tags

• Version 4 used an 8-bit lifetime - restricted to approx. 21 hrs. - Version 5 more flexible.

• Version 5 also adds realms

• Both versions are somewhat vulnerable to password attacks, because keys are based on passwords.