Practical Aspects of Modern Cryptography

Practical Aspects of Modern Cryptography

Practical Aspects of Modern CryptographyJosh BenalohBrian LaMacchiaWinter 20111AgendaIntegrity Checking (HMAC redux)Protocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography2Message Authentication CodesMAC key K, plaintext P, ciphertext C=E(P).

MAC=H(K,P)? MAC=H(P,K)?MAC=H(K,C)? MAC=H(C,K)?

There are weaknesses with all of the above.

HMAC = H(K,H(K,P))January 27, 2011Practical Aspects of Modern Cryptography3HMAC January 27, 2011Practical Aspects of Modern Cryptography4Example: HMAC-SHA1January 27, 2011Practical Aspects of Modern Cryptography5

Crypto HygieneDo I really need to use different keys for encryption and integrity?

Its always a good idea to use separate keys for separate functions, but the keys can be derived from the same master.K1=H(Key1,K) K2=H(Key2,K)January 27, 2011Practical Aspects of Modern Cryptography6AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography7MotivationJanuary 27, 2011Practical Aspects of Modern Cryptography8

8January 27, 2011Practical Aspects of Modern Cryptography9Motivation

9January 27, 2011Practical Aspects of Modern Cryptography10Motivation

10MotivationHow do I know the web site Im talking to is really who I think it is?Is it safe to view to give sensitive information over the Web?What keeps my CC#, SSN, financial information or medical records out of the hands of the bad guys?How do I know that the information Im looking at hasnt been malicious modified? Has someone tampered with it?January 27, 2011Practical Aspects of Modern Cryptography1111Security Protocol PropertiesConfidentialityKeeping message content secret, even if the information passes over a public channelIntegrityKeeping messages tamper-free from origin to destinationAuthenticationDetermining the origin of messages (author and/or sender)January 27, 2011Practical Aspects of Modern Cryptography1212AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography13Kerberos HistoryBased on symmetric Needham-Schroeder (1978)Designed as part of MITs Project Athena in the 1980sKerberos v4 published in 1987Migration to the IETFRFC 1510 (Kerberos v5, 1993)Used in a number of productsExample: Windows domains (since Windows 2000)Many web-based authentication protocols (e.g. Windows Live ID) are essentially Kerberos (or Kerberos-inspired) using HTTP and client-side cookies.January 27, 2011Practical Aspects of Modern Cryptography1414KerberosDesigned for a single administration domain of machines & usersNo public key crypto Provides authentication & encryption servicesKerberized servers provide authorization on top of the authenticated identitiesJanuary 27, 2011Practical Aspects of Modern Cryptography1515The Kerberos ModelClientsServersThe Key Distribution Center (KDC) Centralized trust modelKDC is trusted by all clients & serversKDC shares a secret, symmetric key with each client and serverA realm is single trust domain consisting of one or more clients, servers, KDCsJanuary 27, 2011Practical Aspects of Modern Cryptography1616Picture of a Kerberos Realm January 27, 2011Practical Aspects of Modern Cryptography17Key Distribution Center (KDC)ClientServerTicket Granting Server (TGS)

17Smart Card Logon - Kerberos v5 security provider implements the current IETF draft for PKINIT to support certificate-based authentication

GINA/Winlogon - recognizes the card insertion and prompts the user for a PIN rather than a password

The certificate is retrieved from the card and used to identify the user after a challenge-response requiring a private key operation on the smart card

KDC - the Key Distribution Center looks up the user in the Active Directory based on the identity in the certificate

The end result is a Kerberos Ticket Granting Ticket (TGT) that can be used to request access to network resources including accessing UNIX-based databases using delegation and referral.

Joining a Kerberos RealmOne-time setupEach client, server that wishes to participate in the realm exchanges a secret key with the KDCIf the KDC is compromised, the entire system is crackedBecause the KDC knows everyones individual secret key, the KDC can issue credentials to each realm identityJanuary 27, 2011Practical Aspects of Modern Cryptography1818Kerberos CredentialsTwo types of credentials in KerberosTicketsAuthenticatorsTickets are credentials issued to a client for communication with a specific serverAuthenticators are additional credentials that prove a client knows a key at a point in timeBasic idea: encrypt a nonceJanuary 27, 2011Practical Aspects of Modern Cryptography1919January 27, 2011Practical Aspects of Modern Cryptography20The Basic Kerberos ProtocolAssume client C wishes to authenticate to and communicate with server SPhase 1: C gets a Ticket-Granting Ticket (TGT) from the KDCPhase 2: C uses the TGT to get a Ticket for SPhase 3: C communicates with S20Protocol DefinitionsC = client, S = serverTGS = ticket-granting serviceKx = xs secret keyKx,y = session key for x and y{m}Kx = m encrypted in xs secret keyTx,y = xs ticket to use yAx,y = authenticator from x to yNx = a nonce generated by xJanuary 27, 2011Practical Aspects of Modern Cryptography2121January 27, 2011Practical Aspects of Modern Cryptography22The Basic Kerberos Protocol (1)Phase 1: C gets a Ticket-Granting TicketC sends a request to the KDC for a ticket-granting ticket (TGT)A TGT is a ticket used to talk to the special ticket-granting serviceA TGT is relatively long-lived (~8-24 hours typically)C KDC: C, TGS, NCSent in the clear! 22January 27, 2011Practical Aspects of Modern Cryptography23The Basic Kerberos Protocol (2)Phase 1: C gets a Ticket-Granting TicketKDC responds with two itemsThe ticket-granting ticketA ticket for C to talk to TGSA copy of the session key to use to talk to TGS, encrypted in Cs shared keyKDC C: TC,TGS, {KC,TGS}KCwhere TC,TGS = TGS, {C, C-addr, lifetime, KC,TGS}KTGSOnly the TGS can decrypt the ticketC can unlock the second part to retrieve KC,TGS23January 27, 2011Practical Aspects of Modern Cryptography24ClientPicture of a Kerberos Realm Key Distribution Center (KDC)C KDC: C, TGS, NCKDC C: TC,TGS, {KC,TGS}KCwhere TC,TGS = TGS, {C, C-addr, lifetime, KC,TGS}KTGS

24Smart Card Logon - Kerberos v5 security provider implements the current IETF draft for PKINIT to support certificate-based authentication

GINA/Winlogon - recognizes the card insertion and prompts the user for a PIN rather than a password

The certificate is retrieved from the card and used to identify the user after a challenge-response requiring a private key operation on the smart card

KDC - the Key Distribution Center looks up the user in the Active Directory based on the identity in the certificate

The end result is a Kerberos Ticket Granting Ticket (TGT) that can be used to request access to network resources including accessing UNIX-based databases using delegation and referral.

January 27, 2011Practical Aspects of Modern Cryptography25The Basic Kerberos Protocol (3)Phase 2: C gets a Ticket for SC requests a ticket to communicate with S from the ticket-granting service (TGS)C sends TGT to S along with an authenticator requesting a ticket from C to SC TGS: {AC,S}KC,TGS , TC,TGSwhere Ac,s = {c, timestamp, opt. subkey}First part proves to TGS that C knows the session keySecond part is the TGT C got from the KDC25January 27, 2011Practical Aspects of Modern Cryptography26The Basic Kerberos Protocol (4)Phase 2: C gets a Ticket for STGS returns a ticket for C to talk to S(Just like step 2 above...)TGS C: TC,S , {KC,S}KC,TGSWhere TC,S = S, {C, C-addr, lifetime, KC,S}KS

Only S can decrypt the ticket TC,SC can unlock the second part to retrieve KC,S

26January 27, 2011Practical Aspects of Modern Cryptography27ClientPicture of a Kerberos Realm Ticket Granting Server (TGS)C TGS: {AC,S}KC,TGS , TC,TGSwhere Ac,s = {c, timestamp, opt. subkey}TGS C: TC,S , {KC,S}KC,TGS

27Smart Card Logon - Kerberos v5 security provider implements the current IETF draft for PKINIT to support certificate-based authentication

GINA/Winlogon - recognizes the card insertion and prompts the user for a PIN rather than a password

The certificate is retrieved from the card and used to identify the user after a challenge-response requiring a private key operation on the smart card

KDC - the Key Distribution Center looks up the user in the Active Directory based on the identity in the certificate

The end result is a Kerberos Ticket Granting Ticket (TGT) that can be used to request access to network resources including accessing UNIX-based databases using delegation and referral.

January 27, 2011Practical Aspects of Modern Cryptography28The Basic Kerberos Protocol (5)Phase 3: C communicates with SC sends the ticket to S along with an authenticator to establish a shared secretC S: {AC,S}KC,S , TC,Swhere Ac,s = {c, timestamp, opt. subkey}TC,S = S, {C, C-addr, lifetime, KC,S}KS

S decrypts the ticket TC,S to get the shared secret KC,S needed to communicate securely with C28January 27, 2011Practical Aspects of Modern Cryptography29The Basic Kerberos Protocol (6)Phase 3: C communicates with SS decrypts the ticket to obtain the KC,S and replies to C with proof of possession of the shared secret (optional step)S C: {timestamp, opt. subkey}Kc,sNotice that S had to decrypt the authenticator, extract the timestamp & opt. subkey, and re-encrypt those two components with Kc,s29January 27, 2011Practical Aspects of Modern Cryptography30ClientPicture of a Kerberos Realm ServerC S: {AC,S} Kc,s, TC,Swhere Ac,s = {c, timestamp, opt. subkey}S C: {timestamp, opt. subkey}Kc,s

30Smart Card Logon - Kerberos v5 security provider implements the current IETF draft for PKINIT to support certificate-based authentication

GINA/Winlogon - recognizes the card insertion and prompts the user for a PIN rather than a password

The certificate is retrieved from the card and used to identify the user after a challenge-response requiring a private key operation on the smart card

KDC - the Key Distribution Center looks up the user in the Active Directory based on the identity in the certificate

The end result is a Kerberos Ticket Granting Ticket (TGT) that can be used to request access to network resources including accessing UNIX-based databases using delegation and referral.

January 27, 2011Practical Aspects of Modern Cryptography31Key Distribution Center (KDC)ClientPicture of a Kerberos Realm ServerTicket Granting Server (TGS)TGT RequestTGTTicketRequestTicketTicket + service requestDo some stuff

31Smart Card Logon - Kerberos v5 security provider implements the current IETF draft for PKINIT to support certificate-based authentication

GINA/Winlogon - recognizes the card insertion and prompts the user for a PIN rather than a password

The certificate is retrieved from the card and used to identify the user after a challenge-response requiring a private key operation on the smart card

KDC - the Key Distribution Center looks up the user in the Active Directory based on the identity in the certificate

The end result is a Kerberos Ticket Granting Ticket (TGT) that can be used to request access to network resources including accessing UNIX-based databases using delegation and referral.

Thoughts on Kerberos...Only the KDC needs to know the users password (used to generate the shared secret)You can have multiple KDCs for redundancy, but they all need to have a copy of the username/password databaseOnly the TGS needs to know the secret keys for the serversYou can split KDC from TGS, but it is common for those two services to reside on the same physical machineJanuary 27, 2011Practical Aspects of Modern Cryptography3232Thoughts on Kerberos...(2)Time is very important in KerberosAll participants in the realm need accurate clocksTimestamps are used in authenticators to detect replay; if a host can be fooled about the current time, old authenticators could be replayedTickets tend to have lifetimes on the order of hours, and replays are possible during the lifetime of the ticketJanuary 27, 2011Practical Aspects of Modern Cryptography3333Thoughts on Kerberos...(3)Password-guessing attacks are possibleCapture enough encrypted tickets and you can brute-force decrypt them to discover shared keysIts possible to screw up the implementationIn fact, Kerberos v4 had a colossal security breach due to bad implementations

January 27, 2011Practical Aspects of Modern Cryptography3434RNGs in Kerberos v4Session keys were generated from a PRNG seeded with the XOR of the following:Time-of-day in seconds since 1/1/1970Process ID of the Kerberos server processCumulative count of session keys generatedFractional part of time-of-day secondsHostid of the machine running the serverJanuary 27, 2011Practical Aspects of Modern Cryptography3535RNGs in Kerberos v4 (continued)The seed is a 32-bit value, so while the session key is used for DES (64 bits long, normally 56 bits of entropy), it has only 32 bits of entropyWhats worse, the five values have predictable portionsTime is completely predictableProcessID is mostly predictableEven hostID has 12 predictable bits (of 32 total)January 27, 2011Practical Aspects of Modern Cryptography3636RNGs in Kerberos v4 (continued)Of the 32 seed bits, only 20 bits really change with any frequency, so Kerberos v4 keys (in the MIT implementation) only have 20 bits of randomnessThey could be brute-force discovered in secondsThe hole was in the MIT Kerberos sources for seven years!January 27, 2011Practical Aspects of Modern Cryptography3737AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSPublic Key Infrastructure (PKI)January 27, 2011Practical Aspects of Modern Cryptography38January 27, 2011Practical Aspects of Modern Cryptography39

App-Level Security: SSL/TLS39SSL/PCT/TLS History1994: Secure Sockets Layer (SSL) V2.01995: Private Communication Technology (PCT) V1.01996: Secure Sockets Layer (SSL) V3.01997: Private Communication Technology (PCT) V4.01999: Transport Layer Security (TLS) V1.02006: TLS V1.1 (RFC 4346)2008: TLS V1.2 (RFC 5246)January 27, 2011Practical Aspects of Modern Cryptography4040January 27, 2011Practical Aspects of Modern Cryptography41Typical ScenarioYou (client)Merchant (server)Lets talk securely.Here is my RSA public key.Here is a symmetric key, encrypted with your public key, that we can use to talk.41January 27, 2011Practical Aspects of Modern Cryptography42SSL/TLSYou (client)Merchant (server)Lets talk securely.Here is my RSA public key.Here is a symmetric key, encrypted with your public key, that we can use to talk.42January 27, 2011Practical Aspects of Modern Cryptography43SSL/TLSYou (client)Merchant (server)Lets talk securely.Here are the protocols and ciphers I understand.Here is my RSA public key.Here is a symmetric key, encrypted with your public key, that we can use to talk.43January 27, 2011Practical Aspects of Modern Cryptography44SSL/TLSYou (client)Merchant (server)Lets talk securely.Here are the protocols and ciphers I understand.I choose this protocol and ciphers.Here is my public key and some other stuff.Here is a symmetric key, encrypted with your public key, that we can use to talk.44January 27, 2011Practical Aspects of Modern Cryptography45SSL/TLSYou (client)Merchant (server)Lets talk securely.Here are the protocols and ciphers I understand.I choose this protocol and ciphers.Here is my public key andsome other stuff.Using your public key, Ive encrypted a random symmetric key to you.45SSL/TLSAll subsequent secure messages are sent using the symmetric key and a keyed hash for message authentication.January 27, 2011Practical Aspects of Modern Cryptography4646The five phases of SSL/TLSNegotiate the ciphersuite to be usedEstablish the shared session keyClient authenticates the server(server auth)Optional, but almost always doneServer authenticates the client(client auth)Optional, and almost never doneAuthenticate previously exchanged dataJanuary 27, 2011Practical Aspects of Modern Cryptography4747January 27, 2011Practical Aspects of Modern Cryptography48Phase 1: Ciphersuite NegotiationClient hello (clientserver)Hi! I speak these n ciphersuites, and heres a 28-byte random number (nonce) I just pickedServer hello (clientserver)Hello. Were going to use this particular ciphersuite, and heres a 28-byte nonce I just picked.Other info can be passed along (well see why a little later...)48January 27, 2011Practical Aspects of Modern Cryptography49TLS V1.0 ciphersuitesTLS_NULL_WITH_NULL_NULLTLS_RSA_WITH_NULL_MD5TLS_RSA_WITH_NULL_SHATLS_RSA_EXPORT_WITH_RC4_40_MD5TLS_RSA_WITH_RC4_128_MD5TLS_RSA_WITH_RC4_128_SHATLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5TLS_RSA_WITH_IDEA_CBC_SHATLS_RSA_EXPORT_WITH_DES40_CBC_SHATLS_RSA_WITH_DES_CBC_SHATLS_RSA_WITH_3DES_EDE_CBC_SHATLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHATLS_DH_DSS_WITH_DES_CBC_SHATLS_DH_DSS_WITH_3DES_EDE_CBC_SHATLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHATLS_DH_RSA_WITH_DES_CBC_SHATLS_DH_RSA_WITH_3DES_EDE_CBC_SHATLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHATLS_DHE_DSS_WITH_DES_CBC_SHATLS_DHE_DSS_WITH_3DES_EDE_CBC_SHATLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHATLS_DHE_RSA_WITH_DES_CBC_SHATLS_DHE_RSA_WITH_3DES_EDE_CBC_SHATLS_DH_anon_EXPORT_WITH_RC4_40_MD5TLS_DH_anon_WITH_RC4_128_MD5TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHATLS_DH_anon_WITH_DES_CBC_SHATLS_DH_anon_WITH_3DES_EDE_CBC_SHA49January 27, 2011Practical Aspects of Modern Cryptography50TLS-With-AES ciphersuites (RFC 3268)TLS_RSA_WITH_AES_128_CBC_SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA TLS_DH_RSA_WITH_AES_128_CBC_SHATLS_DHE_DSS_WITH_AES_128_CBC_SHATLS_DHE_RSA_WITH_AES_128_CBC_SHATLS_DH_anon_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHATLS_DH_DSS_WITH_AES_256_CBC_SHATLS_DH_RSA_WITH_AES_256_CBC_SHATLS_DHE_DSS_WITH_AES_256_CBC_SHATLS_DHE_RSA_WITH_AES_256_CBC_SHATLS_DH_anon_WITH_AES_256_CBC_SHA50ECC-based ciphersuites (RFC 4492)TLS_ECDH_ECDSA_WITH_NULL_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_NULL_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_NULL_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_NULL_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_ECDH_anon_WITH_NULL_SHA TLS_ECDH_anon_WITH_RC4_128_SHA TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_128_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA

January 27, 2011Practical Aspects of Modern Cryptography5151January 27, 2011Practical Aspects of Modern Cryptography52Phase 2: Establish the shared session keyClient key exchangeClient chooses a 48-byte pre-master secretClient encrypts the pre-master secret with the servers RSA public keyClientserver encrypted pre-master secretClient and server both compute PRF (pre-master secret, master secret, client nonce + server nonce)PRF is a pseudo-random functionFirst 48 bytes output from PRF form master secret52January 27, 2011Practical Aspects of Modern Cryptography53TLSs PRF (V1.0 & V1.1)PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed); where S1, S2 are the two halves of the secretP_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ... A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) 53Phases 3 & 4: AuthenticationMore on this in a moment...January 27, 2011Practical Aspects of Modern Cryptography5454Phase 5: Authenticate previously exchanged dataChange ciphersuites messageTime to start sending data for real...Finished handshake messageFirst protected message, verifies algorithm parameters for the encrypted channel12 bytes from:PRF(master_secret, client finished, MD5(handshake_messages) + SHA-1(handshake_messages))January 27, 2011Practical Aspects of Modern Cryptography5555Why do I trust the server key?How do I know Im really talking to Amazon.com?What defeats a man-in-the-middle attack?January 27, 2011Practical Aspects of Modern Cryptography56WebServerClientHTTP with SSL/TLS

56Why do I trust the server key?How do I know Im really talking to Amazon.com?What defeats a man-in-the-middle attack?January 27, 2011Practical Aspects of Modern Cryptography57Mallet

HTTP with SSL/TLSHTTP with SSL/TLSClient

WebServer

57January 27, 2011Practical Aspects of Modern Cryptography58SSL/TLSYou (client)Merchant (server)Lets talk securely.Here are the protocols and ciphers I understand.Here is a fresh key encrypted with your key.I choose this protocol and ciphers.Here is my public key and some other stuff that will make youtrust this key is mine.58Whats the some other stuffHow can we convince Alice that some key belongs to Bob?Alice and Bob could have met previously & exchanged keys directly.Jeff Bezos isnt going to shake hands with everyone hed like to sell to...Someone Alice trusts could vouch to her for Bob and Bobs keyA third party can certify Bobs key in a way that convinces Alice.January 27, 2011Practical Aspects of Modern Cryptography5959AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography60What is a certificate?A certificate is a digitally-signed statement that binds a public key to some identifying information.The signer of the certificate is called its issuer.The entity talked about in the certificate is the subject of the certificate.Thats all a certificate is, at the 30,000 level. January 27, 2011Practical Aspects of Modern Cryptography6161Defeating MalletBob can convince Alice that his key really does belong to him if he can also send along a digital certificate Alice will believe & trustJanuary 27, 2011Practical Aspects of Modern Cryptography62Lets talk securely.Here are the protocols and ciphers I understand.I choose this protocol and ciphers.Here is my public key and a certificate to convince you that thekey really belongs to me.BobAliceCertCert

62January 27, 2011Practical Aspects of Modern Cryptography63Certificates are Like MarriageBy the power vested in me I now declare this text and this bit string name and key. What RSA has joined, let no man put asunder.--Bob Blakley63Certs in the real worldA drivers license is like a certificateIt is a signed document (sealed, tamper-resistant)It is created and signed by an issuing authority (the WA Dept. of Licensing)It binds together various pieces of identifying informationNameLicense numberDriving restrictions (must wear glasses, etc.)January 27, 2011Practical Aspects of Modern Cryptography6464More certs in the real worldMany physical objects are like certificates:Any type of license vehicle tabs, restaurant liquor license, amateur radio license, etc.Government-issued IDs (passports, green cards)Membership cards (e.g. Costco, discount cards)All of these examples bind an identity and certain rights, privileges or other identifiersBAL ==N1TJT signed FCCJanuary 27, 2011Practical Aspects of Modern Cryptography6565Why do we believe what certs say?In the physical world, why do we trust the statements contained on a physical cert?We believe its hard to forge the certWe trust the entity that signed the certIn the digital world we need those same two propertiesWe need to believe its hard to forge the digital signature on a signed documentWe need to trust the issuer/signer not to lie to usJanuary 27, 2011Practical Aspects of Modern Cryptography6666Defeating MalletBob can convince Alice that his key really does belong to him if he can also send along a digital certificate Alice will believe & trustJanuary 27, 2011Practical Aspects of Modern Cryptography67Lets talk securely.Here are the protocols and ciphers I understand.I choose this protocol and ciphers.Here is my public key and a certificate to convince you that thekey really belongs to me.AliceCert

BobCert67Getting a certificateHow does Bob get a certificate for his key?He goes to a Certificate Authority (CA) that issues certificates and asks for one...The CA issues Bob a certificate for his public key.CA is the issuerBob is the subjectJanuary 27, 2011Practical Aspects of Modern Cryptography6868Using CertificatesNow that Bob has a certificate, is it useful?Alice will believe Bobs key belongs to Bob if Alice believes the certificate Bob gives her for his key.Alice will believe Bobs key belongs to Bob if Alice trusts the issuer of Bobs certificate to make key-name binding statementsHave we made the situation any better?January 27, 2011Practical Aspects of Modern Cryptography6969Does Alice Trust Bobs CA?How can we convince Alice to trust Bobs CA?Alice and Bobs CA could have met previously & exchanged keys directly.Bobs CA isnt going to shake hands with everyone hes certified, let alone everyone whom Bob wants to talk to.January 27, 2011Practical Aspects of Modern Cryptography7070Does Alice Trust Bobs CA?How can we convince Alice to trust Bobs CA?Alice and Bobs CA could have met previously & exchanged keys directly.Bobs CA isnt going to shake hands with everyone hes certified, let alone everyone whom Bob wants to talk to.Someone Alice trusts could vouch to her for Bobs CA and Bobs CAs keyInfinite Loop: See Loop, Infinite.Actually, its just a bounded recursion...January 27, 2011Practical Aspects of Modern Cryptography7171Whats Alices Trust ModelAlice has to implicitly trust some set of keysOnce she does that, those keys can introduce others to her.In the model used by SSL/TLS, CAs are arranged in a hierarchyAlice, and everyone else, trusts one or more root CA that live at the top of the treeOther models work differentlyJanuary 27, 2011Practical Aspects of Modern Cryptography7272AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography73Certificate AuthoritiesA certificate authority (CA) guarantees the connection between a key and another CA or an end entity. An end entity is:A personA role (VP of sales)An organizationA pseudonymA piece of hardware or softwareAn accountSome CAs only allow a subset of these types.January 27, 2011Practical Aspects of Modern Cryptography7474January 27, 2011Practical Aspects of Modern Cryptography75CA HierarchiesCAs can certify other CAs or end entities (EEs)Certificates are links in a tree of EEs & CAsCAEERootCACAEECAEE75January 27, 2011Practical Aspects of Modern Cryptography76BALs No-Frills CertsCertificates can contain all sorts of information inside themWell talk about the details in a little bitIn the abstract, though, theyre just statements by an issuer about a subject:IssuerSubject76Does Alice trust Bobs Key?Alice trusts Bobs key if there is a chain of certificates from Bobs key to a root CA that Alice implicitly trustsJanuary 27, 2011Practical Aspects of Modern Cryptography77CAEERootCACAEERoot CACARoot CARoot CA77Chain Building & ValidationGiven an end-entity certificate, does there exist a cryptographically valid chain of certificates linking it to a trusted root certificate?January 27, 2011Practical Aspects of Modern Cryptography78CAEERootCACAEERoot CACARoot CARoot CA78Chaining CertificatesIn theory, building chains of certificates should be easyJust link them together like dominosIn practice, its a lot more complicated...January 27, 2011Practical Aspects of Modern Cryptography7979January 27, 2011Practical Aspects of Modern Cryptography80Chain Building Details (1)CA2CA1EE1RootCAEE2CA2EE3Root CACA1Root CACA2CA1EE2CA1EE1EE380January 27, 2011Practical Aspects of Modern Cryptography81Chain Building Details (2)CA2CA1EE1RootCA1EE2EE3RootCA281January 27, 2011Practical Aspects of Modern Cryptography82Chain Building Details (3)CA2CA1EE1RootCA1EE2EE3RootCA282January 27, 2011Practical Aspects of Modern Cryptography83Chain Building Details (3)CA2CA1EE1RootCA1EE2EE3RootCA2BridgeCA83January 27, 2011Practical Aspects of Modern Cryptography84Chain Building Details (3)CA2CA1EE1RootCA1EE2EE3RootCA2BridgeCA84January 27, 2011Practical Aspects of Modern Cryptography85CA2CA1EE1RootCA1EE2EE3RootCA2BridgeCA85January 27, 2011Practical Aspects of Modern Cryptography86CA2CA1EE1RootCA1EE2EE3RootCA2BridgeCA86Chaining CertificatesHow do we determine whether two certificates chain together?Youd think this was an easy problem...But its actually a question with religious significance in the security communityAre you a believer in names, or in keys?The model SSL/TLS uses, the X.509 certificate model, is based on namesNames as principlesJanuary 27, 2011Practical Aspects of Modern Cryptography8787PKI Alphabet SoupX.509v3 - standard content of a certificatePKIX IETF Working Group on PKI interoperabilityPKIX == Public Key Infrastructure using X.509v3 certificatesASN.1 - Abstract Syntax Notation, exact description of a certificate formatDER - Distinguished Encoding Rules, how to physically package a certificateJanuary 27, 2011Practical Aspects of Modern Cryptography8888Key fields in a certificateThe core fields of an X.509 certificate areThe subject public keyThe subject Distinguished NameThe issuer Distinguished NameWhats missing here?January 27, 2011Practical Aspects of Modern Cryptography8989Key fields in a certificateThe core fields of an X.509 certificate areThe subject public keyThe subject Distinguished NameThe issuer Distinguished NameWhats missing here?The issuers public key is not present in the certificate.You cant verify the signature on the cert without finding a parent cert!January 27, 2011Practical Aspects of Modern Cryptography9090Back to Chain BuildingOK, assume were a relying party application -- something that received an end-entity certificate and wants to verify it.Our task is to build a cert chain from that end-entity cert to one of our trusted rootsHow do we do that?We start with our EE cert, and using the information contained within we look for possible parent certificates. January 27, 2011Practical Aspects of Modern Cryptography9191Parent certsWhats a valid parent certificate?In the raw X.509 model, parent-child relationships are determined solely by matching Issuer DN in the child to Subject DN in the parentRecall that theres an assumption that you have a big directory handy to find certs.If you dont have a directory handy, you need to do the matching yourselfThis is not as easy as you might thinkJanuary 27, 2011Practical Aspects of Modern Cryptography9292January 27, 2011Practical Aspects of Modern Cryptography93Name matchingIssuer NameSubject NameIssuer NameSubject Name93Even More Chain BuildingName matching is just the beginning of the chain-building processIt is necessary that subject and issuer DNs exactly match for two certs to chain, but not always sufficientThe chain building process is also influenced dynamically by other information contained within the certs themselvesCertificate ExtensionsJanuary 27, 2011Practical Aspects of Modern Cryptography9494Trusted Root CertificatesWho do I trust to be roots at the top of the cert chain?In theory, anyone you wantIn practice, trusted roots come from two sourcesTheyre baked into your web browser or operating systemTheyre pushed onto your enterprise managed desktopJanuary 27, 2011Practical Aspects of Modern Cryptography95January 27, 2011Practical Aspects of Modern Cryptography96Trusted Root Certificates

AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography97Lifecycle ManagementCertificate EnrollmentInitial acquisition of a certificate based on other authentication informationRenewalAcquiring a new certificate for a key when the existing certificate expiresRevocationUndoing a certificateJanuary 27, 2011Practical Aspects of Modern Cryptography9898January 27, 2011Practical Aspects of Modern Cryptography99Certificate EnrollmentEnrollment is the process of obtaining a certificate from a CA.Alice generates a key pair, creates a message containing a copy of the public key and her identifying information, and signs the message with the private key (PKCS#10).Signing the message provided proof-of-possession (POP) of the private key as well as message integrityCA verifies Alices signature on the message99January 27, 2011Practical Aspects of Modern Cryptography100Certificate Enrollment (2)(Optional) CA verifies Alices ID through out-of-band means.CA creates a certificate containing the ID and public key, and signs it with the CAs own keyCA has certified the binding between key and IDAlice verifies the key, ID & CA signatureAlice and/or the CA publish the certificate100January 27, 2011Practical Aspects of Modern Cryptography101DirectoryCertClientCACertificate Requestand InstallationPublish Certificate?Certificate Enrollment Flow

101A certificate enrollment involves a user or client initiating a request that is then sent to a CA for processing. As part of the request, the key pair is generated on the client and a Certificate Template is selected. The request message is known as a PKCS#10.

Certificate Templates - each CA will publish a CA object to the Active Directory at installation time that contains information about the CA including what certificates it can issue.

After the request is successfully processed by the CA it is issued and returned to the user or client in a message known as a PKCS#7. Certificate Publishing - publishing certificates to the user object stored in the Active Directory is a feature of Windows 2000 to enable retrieval of a users S/MIME certificate in order to encrypt data to the user without the user having to have previously sent a signed message

All certificate requests are authenticated by the CAs policy module if the CA is an Enterprise CA. Standalone CAs do not authenticate requestsMore PKI Alphabet SoupPKCS #10 (old) standard message format for certificate requestsPKCS #7 (old) standard message format for encrypted/signed dataAlso used for certificate request responsesReplaced by IETF CMS syntaxCMC Certificate Management with CMSReplacement for PKCS #10/PKCS#7 in a certificate management contextCMP Certificate Management ProtocolsAlternative to CMCJanuary 27, 2011Practical Aspects of Modern Cryptography102102AgendaIntegrity CheckingProtocols (Part 1 Session-based protocols)IntroductionKerberosSSL/TLSCertificates and Public Key Infrastructure (PKI)CertificatesPublic Key InfrastructureCertificate Lifecycle ManagementRevocationJanuary 27, 2011Practical Aspects of Modern Cryptography103Expiration & RevocationCertificates (at least, all the ones were concerned with) contain explicit validity periods valid from & expires onExpiration dates help bound the risk associated with issuing a certificateSometimes, though, it becomes necessary to undo a certificate while it is still validKey compromiseCert was issued under false pretensesThis is called revoking a certificateJanuary 27, 2011Practical Aspects of Modern Cryptography104104Status Info for CertificatesTwo standards within PKIX:X.509v2/PKIX Part 1 Certificate Revocation Lists (CRLs)Online Certificate Status Protocol (OCSP)Both methods state:Whether a cert has been revokedA revocation code indicating why the cert was revokedThe time at which the cert was revokedJanuary 27, 2011Practical Aspects of Modern Cryptography105105Certificate RevocationA CA revokes a certificate by placing the cert on its Certificate Revocation List (CRL)Every CA issues CRLs to cancel out issued certsA CRL is like anti-matter when it comes into contact with a certificate it lists it cancels out the certificateThink 1970s-style credit-card blacklistRelying parties are expected to check CRLs before they rely on a certificateThe cert is valid unless you hear something telling you otherwiseJanuary 27, 2011Practical Aspects of Modern Cryptography106106The Problem with CRLsBlacklists have numerous problemsNot issued frequently enough to be effective against a serious attackExpensive to distribute (size & bandwidth)Vulnerable to simple DOS attacksIf you block on lack of CRL access, why have off-line support in the first place?January 27, 2011Practical Aspects of Modern Cryptography107107The Problem with CRLs (2)CRL design made it worseCRLs can contain retroactive invalidity datesA CRL issued today can say a cert was invalid as of last week. Checking that something was valid at time t wasnt sufficient!Back-dated CRLs can appear at any time in the futureIf you rely on certs & CRLs youre screwed because the CA can change the rules out from under you later.January 27, 2011Practical Aspects of Modern Cryptography108108The Problem with CRLs (3)Revoking a CA cert is more problematic than revoking an end-entity certWhen you revoke a CA cert, you potentially take out the entire subordinate structure, depending on what chaining logic you useHow do you revoke a self-signed cert?The cert revokes itself.Huh?Do I accept the CRL as valid & bounce the cert?Do I reject the CRL because the cert associated with the CRL signing key was revoked?January 27, 2011Practical Aspects of Modern Cryptography109109The Problem with CRLs (4)You cant revoke a CRLOnce you commit to a CRL, its a valid state for the entirety of its validity periodWhat happens if you have to update the CRL while the CRL you just issued is still valid?You can update it, but clients arent required to fetch it since the one they have is still valid!Bottom line: yikes!We need something elseJanuary 27, 2011Practical Aspects of Modern Cryptography110110CRLs vs. OCSP ResponsesAggregation vs. FreshnessCRLs combine revocation information for many certs into one long-lived objectOCSP Responses designed for real-time responses to queries about the status of a single certificateBoth CRLs & OCSP Responses are generated by the issuing CA or its designate. (Generally this is not the relying party.)

January 27, 2011Practical Aspects of Modern Cryptography111111Online Status CheckingOCSP: Online Certificate Status ProtocolA way to ask is this certificate good right now?Get back a signed response from the OCSP server saying, Yes, cert C is good at time tResponse is like a freshness certificateOCSP response is like a selective CRLClient indicates the certs for which he wants status informationOCSP responder dynamically creates a lightweight CRL-like response for those certsJanuary 27, 2011Practical Aspects of Modern Cryptography112112January 27, 2011Practical Aspects of Modern Cryptography113OCSP in ActionEnd-entityCARelyingPartyCertCertRequestOCSP RequestOCSPForCertOCSP ResponseTransaction ResponseCert+Transaction113Final thoughts on RevocationFrom a financial standpoint, its the revocation data that is valuable, not the issued certificate itselfFor high-valued financial transactions, seller wants to know your cert is good right nowSame situation as with credit cards, where the merchant wants the card authorized right now at the point-of-saleCard authorizations transfer risk from merchant to bank thus theyre worth $$$Same with cert status checksJanuary 27, 2011Practical Aspects of Modern Cryptography114114Using CertificatesMost certificate uses do not require any sort of directoryOnly needed to locate someone elses certificate for encryptionAuthentication protocols have the client present their certificate (or chain) to the serverEx: SSL, TLS, Smart card logonRules for mapping a certificate to user account vary widelyCert fields, name forms, binary compareSigning operations embed the certificates with the signatureHow else would you know who signed it?January 27, 2011Practical Aspects of Modern Cryptography115115Using Certificates (2)X.509 and PKIX define the basic structure of certificatesIf you understand X.509, you can parse any certificate youre presentedHowever, every protocol defines a certificate profile for certificate use in that particular protocolEx: TLS, S/MIME, IPSEC, WPA/WPA2CAs/organizations define profiles tooEx: US DoD Common Access Card certsJanuary 27, 2011Practical Aspects of Modern Cryptography116116Additional Implementation ConsiderationsPublishing certificatesHow? Where? What format?Key escrow / data recovery for encryption keys/certsAuto-enrollment (users & machines)Establishing trusts / hierarchiesProtecting private keysDisseminating root certificatesJanuary 27, 2011Practical Aspects of Modern Cryptography117117Supplemental Material onCertificate Extensions(only if time permits)

118January 27, 2011Practical Aspects of Modern Cryptography119Exploring inside an X.509 Cert

119January 27, 2011Practical Aspects of Modern Cryptography120Exploring inside an X.509 Cert

120January 27, 2011Practical Aspects of Modern Cryptography121Exploring inside an X.509 Cert

121January 27, 2011Practical Aspects of Modern Cryptography122Inside an X.509v3 CertificateVersionIssuer Distinguished NameSubject Public KeySigning AlgorithmValidity PeriodSubject Distinguished NameSerial NumberExtensionsExtension 1Extension 2Extension n122Certificate ExtensionsAn extension consists of three things:A critical flag (boolean)A type identifierA value Format of the value depends on the type identifierJanuary 27, 2011Practical Aspects of Modern Cryptography123123January 27, 2011Practical Aspects of Modern Cryptography124Certificate ExtensionsExtensionsKey UsageCritical?Subject Key IDCritical?Authority Key IDCritical?CRL Distribution PointsCritical?Authority Info AccessCritical?Extended Key UsageCritical?Subject Alt NameCritical?Certificate PoliciesCritical?Proprietary Extension 1Critical?Proprietary Extension nCritical?124Critical FlagsThe critical flag on an extension is used to protect the issuing CA from assumptions made by software that doesnt understand (implement support for) a particular extensionIf the flag is set, relying parties must process the extension if they recognize it, or reject the certificateIf the flag is not set, the extension may be ignoredJanuary 27, 2011Practical Aspects of Modern Cryptography125125Critical Flags (2)Some questions you might be asking yourself right now...What does must process the extension if they recognize it mean?What does recognize mean?What does process mean?Youve got me....The IETF standards folks didnt know either...January 27, 2011Practical Aspects of Modern Cryptography126126Critical Flags (3)Actual definitions of flag usage are vague:X.509: Non-critical extension is an advisory field and does not imply that usage of the key is restricted to the purpose indicatedPKIX: CAs are required to support constrain extensions but support is never defined.S/MIME: Implementations should correctly handle certain extensionsVerisign: All persons shall process the extension...or else ignore the extensionJanuary 27, 2011Practical Aspects of Modern Cryptography127127Types of ExtensionsThere are two flavors of extensionsUsage/informational extensions, which provide additional info about the subject of the certificateConstraint extensions, which place restrictions on one or more of:Use of the certificateThe user of the certificateThe keys associated with the certificateJanuary 27, 2011Practical Aspects of Modern Cryptography128128Some common extensionsKey UsagedigitalSignatureSign things that dont look like certskeyEnciphermentExchange encrypted session keyskeyAgreementDiffie-HellmankeyCertSign/keyCRLSignSign things that look like certsnonRepidiationJanuary 27, 2011Practical Aspects of Modern Cryptography129129NonRepudiationThe nonRepudiation bit is the black hole of PKIXIt absorbs infinite amounts of argument time on the mailing list without making any progress toward understanding what it meansWhat does it mean? How do you enforce that?No one knows...Nonrepudiation is anything which fails to go away when you stop believing in itJanuary 27, 2011Practical Aspects of Modern Cryptography130130More ExtensionsSubject Key IDShort identifier for the subject public keyAuthority Key IDShort identifier for the issuers public key useful for locating possible parent certsCRL Distribution PointsList of URLs pointing to revocation information serversAuthority Info AccessPointer to issuer cert publication locationJanuary 27, 2011Practical Aspects of Modern Cryptography131131Even More ExtensionsBasic constraintsIs the cert a CA cert?Limits on path length beneath this certName constraintsLimits on types of certs this key can issuePolicy mappingsConvert one policy ID into anotherPolicy constraintsAnti-matter for policy mappingsJanuary 27, 2011Practical Aspects of Modern Cryptography132132Still More ExtensionsExtended Key UsageBecause Key Usage wasnt confusing enough!Private Key Usage PeriodCA attempt to limit key validity periodSubject Alternative namesEverything which doesnt fit in a DNRFC822 names, DNS names, URIsIP addresses, X.400 names, EDI, etc.January 27, 2011Practical Aspects of Modern Cryptography133133Yet Still More ExtensionsCertificate policiesInformation identifying the CA policy that was in effect when the cert was issuedPolicy identifierPolicy qualifierExplicit textHash reference (hash + URI) to a documentX.509 defers cert semantics to the CAs issuing policyMost CA policies disclaim liabilityJanuary 27, 2011Practical Aspects of Modern Cryptography134134Extensions and Chain Building When you build a cert chain, you start with the EE cert and discover possible parent certificates by matching DNsBuild the chain from the bottom up.However, to verify a cert chain, you have to start and the root and interpret all the extensions that may constrain subordinate CAs (and EEs)Build the chain from the top down.January 27, 2011Practical Aspects of Modern Cryptography135135