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.