Encryption Standards/Apps

1. Encryption Standards/Apps Topics X.509 PGP S/MIME Kerberos

2. X.509 Directory Authentication Framework • X.509 is part of the ISO X.500 directory standard. • used by S/MIME, SSL, IPSec, and others Important Components of X.509 1) a standard certificate format 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.

3. X.509 Certificate Version Certificate Serial # Dig. Sig. (algorithm & parameters) Issuer name (CA) Subject name Start Date End Date Public Key (algorithm & parameters) Public Key Issuer ID Subject ID Extensions Dig. Sig. (algorithm & parameters) Digital Signature

4. Ole Sven Lena D A B C X.509 CA Hierarchy • CAs issue certificates to subjects. • A subject can transmit his/her certificate to a different subject. • Simple authentication occurs when two subjects are issued certificates from one CA. Example Notation A, B, C, and D are CAs. Ole, Sven and Lena are subjects Certificate: Issuer «Subject» C «Lena» D «Ole» D «Sven» Suppose Ole wants to validate Sven. ... but what if Ole wants to send a message to Lena?

5. A B C D Ole Lena Sven General authentication requires CAs to exchange certificates, supporting certificate chaining. Notation A, B, C, and D are CAs. Ole, Sven and Lena are subjects Certificate: Issuer «Subject» Example (cont’d) A «B» B «A» A «C» C «A» B «D» D «B» C «Lena» Note: two kinds of certificates: forward - holder is subject, issuer is another CA reverse - holder is issuer, subject is another CA D «Ole» D «Sven» For Ole to validate Lena 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:

6. Ole Lena X.509 Authentication Assume that Ole wishes to authenticate Lena. There are three possible protocols. One Way TimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub) This 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. Notation Sigdenotes a digital signature (an MD encrypted with the sender’s private key) TimeStamp consists of optional generation time and expiration time nonce is a random number unique until expiration time

7. Ole Ole Ole Ole Ole Lena Lena Lena Lena Lena Two Way TimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub) TimeStamp2 || nonce2 || IDOle || Sig || E(SessionKey, KOlePub) This establishes additionally a) the integrity of the reply b) the identity of the receiver (Lena) c) that the message is intended for Ole Three Way TimeStamp1 || nonce1 || IDLena || Sig || E(SessionKey, KLenaPub) TimeStamp2 || nonce2 || IDOle || nonce1 || Sig || E(SessionKey, KOlePub) nonce2 || Sig This echos nonces to avoid replay w/o time stamps.

8. PGP Brief History • 1991 - PGP created by Phil Zimmerman • widely-used secure email standard • 1996 purchased by Network Associates 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. • Keys can be revoked by the owner. • Each key is signed by owner (and possibly others). • Trust is based on who signed the key. • Subject discretion ultimately determines who to trust.

9. PGP Operations Potential PGP Operations • 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) • generate & encrypt (or decrypt) MD (SHA-1) using private key • attach encrypted session key (as a digital signature) to a message • transmit message

10. least significant 64 bits of public key usually the user’s email address PGP Key Private Key Ring Time Stamp Key ID Public Key (of pair) Private Key (of pair) User’s ID Public Key Ring Time Stamp Key ID Public Key (of pair) User’s ID

11. This part is first compressed (zip) then encrypted with SessionKey PGP Session Key PGP uses the concept of a one-time session key Typical Message Format (from Lena to Ole) ID of KOlePub E( SessionKey, KOlePub ) Timestamp ID of KLenaPub Leading two octets of MD E( MD, KLenaPriv ) File Name Timestamp Data The entire transmission is encoded in radix-64.

12. PGP Session Key Why use a one-time (session) key?

13. S/MIME S/MIME -- Secure / Multipurpose Internet Mail Extensions Originally developed by RSA Certificate Processing • Uses X.509v3 certificates • Responsibility for maintaining certificates is local. • Certificates are signed by a Certificate Authority • CAs - VeriSign, GTE, Nortel, U.S. Postal Service 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.

14. Class 1 Class 2 Class 3 S/MIME VeriSign Certificates Classes VeriSign required unambiguous name and email address, PIN is emailed to user Web browsers, email VeriSign does online database search and sends digital ID & PIN to postal address online subscriptions, secure email banking, secure database, membership-based services, e-commerce Client must prove identity via notary public or appear in person 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)

15. Kerberos • Kerberos is an authentication system - authenticating users and services. • It was originally developed as part of Project Athena - MIT. • Kerberos relies upon a centralized Kerberosserver per realm. • Multi-realm communication is also possible. • A kerberos server must contain a database of user IDs and hashed passwords. • A kerberos server must share a secret key with registered servers. • The client can maintain a list of trusted certificates.

16. Ole Ole Ole AS AS S Kerberos Protocols Alternative 1 IDOle || pwdOle || IDS) TicketS== E( IDOle || IPOle || IDs, keyS) Ticket|| IDOle Weaknesses Notation Oleis the client AS is the authentication/Kerberos server pwdC is the password for C IPC is the IP address of C keyS key shared by AS and server S

17. Alternative 2 TGS -- ticket granting server Ole Ole Ole Ole Ole TGS AS TGS S AS key based on Ole’s pwd IDOle || IDTGS login TicketTGS E( IDOle || IPOle || IDTGS || Lifetime1 || TimeStamp1, keyOle) IDOle || IDS || TicketTGS to obtain service TicketS E( IDOle || IPOle || IDS || Lifetime1 || TimeStamp2, keys) IDOle || TicketS once per service session Weaknesses 1) lifetime 2) server is never authenticated to the client

18. Version 4 protocol Ole Ole Ole Ole Ole Ole AS TGS AS S S TGS IDOle || IDTGS || TimeStamp1 login E(KeyOle&TGS || IDTGS || TimeStamp2|| Lifetime2 || TicketTGS, keyOle ) TicketTGS == E( KeyOle&TGS || IDOle || IPOle || IDTGS || TimeStamp2 || Lifetime2,keyTGS) IDS || TicketTGS || E(IDOle || IPOle|| TimeStamp3, keyOle&TGS ) to obtain service E(KeyOle&S || IDS || TimeStamp4|| TicketS, keyOle&TGS ) TicketS== E( KeyOle&S || IDOle || IPOle || IDS || TimeStamp4|| Lifetime4, keys) TicketS || E(IDOle || IPOle|| TimeStamp5, keyOle&S ) once per service session E( 1 + TimeStamp5, keyOle&S )

19. Version 5 protocol login Options || IDOle || RealmOle || IDTGS || Times || Nonce1 RealmOle || IDOle || TicketTGS || E(KeyOle&TGS || Times || Nonce1 || RealmTGS || IDTGS, keyOle ) Ole Ole Ole Ole Ole Ole S AS AS TGS S TGS TicketTGS== E( Flags || KeyOle&TGS || RealmOle || IDOle || IPOle || IDTGS || Times,keyTGS) Options || IDS || Times || Nonce2 || TicketTGS || E(IDOle || RealmOle || TimeStamp1, keyOle&TGS ) to obtain service RealmOle || IDOle || TicketS || E(KeyOle&S || Times || Nonce2 || RealmS || IDS, keyOle&TGS ) TicketS== E( Flags || KeyOle&S || Realm || IDOle || IPOle || Times, keys) once per service session Options || TicketS || E(IDOle || RealmOle || TimeStamp2 || subkey || seq#, keyOle&S ) E( TimeStamp5 || subkey || seq#, keyOle&S )

20. Kerberos Versions • 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.