Cryptographic Protocols Topics 1. Dramatis Personae and Notation 2. Session and Interchange Keys 3. Key Exchange 4. Key Generation 5. Cryptographic Key Infrastructure 6. Storing and Revoking Keys 7. Digital Signatures Dramatis Personae, the Computer, trusted 3 rd party., the 1 st participant, the 2 nd participant Eve, the Eavesdropper 1
Notation X sends Y a message Z encrypted with key k. X Y : { Z} k Concatenation of bit sequences A and B A B Key subscripts indicate ownership k A is the key belonging to user A(lice) k A,B is a key shared by A(lice) and B(ob) Nonces (nonrepeating random numbers) r 1, r 2 Symmetric Key Problems 1. Keys must be distributed in secret. 2. If key is compromised, Eve can decrypt all message traffic encrypted with key. 3. If each pair of users needs a key, number of keys n(n-1) increases rapidly with size of network. Mixed PK/Classical Encryption communicates with using PK cipher. 1. randomly generates session key k s. Key k s used only for this single message. 2. enciphers k s with s public key k B. k B enciphers all session keys uses to communicate with. Called an interchange key. 3. sends { m } k s { k s } k B to. 2
Session Key A key used to encrypt a single session. Advantages Reduces data ciphered with a single key. Protection against replay attacks. Prevents forward search attack. Forward search example client of s brokerage. Communicates with BUY and SELL messages. Eve enciphers both messages with s key. Compares intercepted traffic with ciphertext. Key Exchange Algorithms Goal:, obtain shared secret key. Requirements: Key cannot be sent in clear: Attacker can intercept key. Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper., may trust third party (.) All cryptosystems, protocols publicly known Only secret data is keys or data used to derive keys. Anything transmitted is assumed known to attacker. Classical Key Exchange Bootstrap problem: how do, begin? can t send it to in the clear! Assume trusted third party, and share secret key k A. and share secret key k B. Let generate shared key k s. can send it securely to either A or B. 3
Simple Key Exchange Protocol { request for session key to } k A { k s } k A { k s } k B { k s } k B Problems How does know he is talking to? Replay attack: Eve records message from to, later replays it; may think he s talking to, but he isn t. Session key reuse: Eve replays key exchange message from to, so re-uses session key. Protocols must provide authentication and defense against replay. Needham-Schroeder r 1 { r 1 k s { k s } k B } k A { k s } k B { r 2 } k s { r 2 1 } k s 4
Is really talking to? Second message encrypted it, since only A, C know key k A. It must be a response to first message as contains r 1. Third message knows only can read it since encrypted w/ k B. Any messages enciphered with k S are from, since only,, and have k S. Is really talking to? Third message encrypted it, since only B, C know key k B. provides session key, says is other party. Fourth message Uses session key to determine if 3 rd was replay. If not, will respond correctly in fifth message. If 3 rd message was replay attack, Eve can t decipher r 2 and so can t respond, or responds incorrectly. Needham-Schroeder Assumptions A trusted 3 rd party exists,. Many transactions require 3 rd parties. Session keys are always secure. What if Eve can obtain old keys? 5
Denning-Sacco Modification Eve can impersonate if she can obtain old k s. 1. Eve replays s message { k s } k B. 2. Eve uses old k s to decipher s random number query. Eve { k s } k B Eve Eve { r 2 } k s { r 2 1 } k s Solution How can we avoid replay in step 3 of N-S? Use time stamp T to detect replay. Weakness: if clocks not synchronized, may either reject valid messages or accept replays. Parties with slow/fast clocks vulnerable to replay. Resetting clock does not eliminate vulnerability. Needham-Schroeder + Denning-Sacco Mod will reject message if timestamp T is too old. r 1 { r 1 k s { T k s } k B } k A { T k s } k B { r 2 } k s { r 2 1 } k s 6
Otway-Rees Protocol Corrects replay attack w/o timestamps. Not vulnerable to clock skew problems of Denning- Sacco modification. Uses integer n to associate all messages with a particular exchange. Otway-Rees Protocol n { r 1 n } k A n { r 1 n } k A { r 2 n } k B n { r 1 k s } k A { r 2 k s } k B n { r 1 k s } k A Argument: talking to Fourth message If n matches first message, knows it is part of this protocol exchange. generated k s because only she & know k A. Enciphered part belongs to exchange as r 1 matches r 1 in encrypted part of first message. 7
Argument: talking to Third message If n matches second message, knows it is part of this protocol exchange. generated k s because only she & know k B. Enciphered part belongs to exchange as r 2 matches r 2 in encrypted part of second message. Defeating Replay Attacks Eve acquires old k s, message in third step: n { r 1 k s } k A { r 2 k s } k B Eve forwards appropriate part to : has no ongoing key exchange with : n matches nothing, so is rejected. has ongoing key exchange with : n does not match, so is again rejected. If replay is for the current key exchange, and Eve sent the relevant part before did, Eve could simply listen to traffic; no replay needed. Kerberos Authentication system Based on Needham-Schroeder with Denning-Sacco modification. Central server plays role of trusted 3 rd party. Ticket vouches for identity of requester of service. Active Directory = Kerberos + LDAP 8
Ticket Granting Service Requirement: Users only enter password once. User u authenticates to Kerberos server. Gets ticket T u,tgs for ticket granting service (TGS) Requirement: Users don t send password over net. Service Tickets Procedure for a user u to use service s: User sends authenticator A u, ticket T u,tgs to TGS asking for ticket for service. TGS sends ticket T u,s to user. User sends A u, T u,s to server as request to use s. Ticket Details Credential saying issuer has identified requester. Example ticket issued to user u for service s T u,s = s { u u s address valid time k u,s } k s where: k u,s is session key for user and service. Valid time is interval for which ticket valid. u s address may be IP address or something else. 9
Authenticator Credential containing identity of sender of ticket. Contains username and session key to confirm sender is entity to which ticket was issued. Authenticator cannot be accessed without ticket, since data encrypted with k u,s. Authenticator user u generates for service s A u,s = { u generation time k t } k u,s where: k t is alternate session key. Time is when authenticator generated. Public Key Exchange Here interchange keys known e A, e B and s public keys known to all d A, d B and s private keys known only to owner Simple protocol k s is desired session key. { k s } e B Problem and Solution Vulnerable to forgery or replay Because e B known to anyone, has no assurance that sent message. Simple fix uses s private key k s is desired session key. { { k s } d A } e B 10
Notes Can include message enciphered with k s Assumes has s public key, and vice versa If not, each must get it from public server. If keys not bound to identity of owner, attacker Eve can launch a man-in-the-middleattack (next slide; is public server providing public keys.) Solution: Public key infrastructure (PKI) Man-in-the-Middle Attack please send s public key Eve intercepts request please send s public key Eve e B Eve e E Eve { k s } e E Eve intercepts message Eve { k s } e B Cryptographic Key Infrastructure Solution: bind identity to key Classical: not possible as all keys are shared Use protocols to agree on a shared key (see earlier.) Public key: bind identity to public key Crucial as people will use key to communicate with principal whose identity is bound to key. Erroneous binding means no secrecy between principals. Assume principal identified by an acceptable name. 11
Certificates Create token (message) containing: Identity of principal (here, ) Corresponding public key Timestamp (when issued) Other information (perhaps identity of signer) signed by trusted authority (.) C A = { e A T } d C Use downloads s certificate If he knows s public key, he can decipher the certificate When was certificate issued? Is the principal? Now has s public key. Problem: needs s PK to validate cert. Problem pushed up a level. Solution: signature chains. Certificate Signature Chains Create certificate: Generate hash of identification information of requester. Encipher hash with issuer s private key. Validate Obtain issuer s public key. Decipher enciphered hash. Recompute hash from certificate and compare. 12
X.509 (SSL) Certificates Some certificate components in X.509v3: Version Serial number Signature algorithm identifier: hash algorithm Issuer s name; uniquely identifies issuer Interval of validity Subject s name; uniquely identifies subject Subject s public key Signature: enciphered hash X.509 Certificate Validation Obtain issuer s public key The one for the particular signature algorithm Decipher signature Gives hash of certificate Recompute hash from certificate and compare If they differ, there s a problem Check interval of validity This confirms that certificate is current Issuers Certification Authority (CA): entity that issues certificates;, the trusted 3 rd party Multiple issuers pose validation problem. s CA is ; s CA is Don; how can validate s certificate? Have and Don cross-certify Each issues certificate for the other CA. Notation: Certificate X issued for Y X<<Y>> 13
Validation and Cross-Certifying Certificates: <<>> Dan<<>> <<Dan>> Dan<<>> validates s certificate: obtains <<Dan>> uses (known) public key of to validate <<Dan>> uses <<Dan>> to validate Dan<<>> PGP Chains OpenPGP certificates verified via web of trust No hierarchy of CAs to follow like SSL certificates Certificates can be signed by multiple parties OpenPGP certificates structured into packets: One public key packet. Zero or more signature packets. Signing Single certificate may have multiple signatures. Notion of trust embedded in each signature Range from untrusted to ultimate trust. Signer defines meaning of trust level (no standards!) All version 4 keys signed by subject Called self-signing. 14
Validating Certificates needs to validate s OpenPGP cert Arrows show signatures!: Fred,Giselle,Ellen. Self signatures not shown gets Giselle s cert Jack Knows Henry slightly, but signature at casual trust. Henry Ellen gets Ellen s cert Irene Knows Jack, so uses his cert Giselle to validate Ellen s, then hers to validate s. Fred Jack<<Ellen>>Ellen<<>> Storing Keys Multi-user or networked systems: attackers may defeat access control mechanisms. 1. Encipher file containing key. Attacker can monitor keystrokes to decipher files Key will be resident in memory. 2. Use physical devices like smart card. Smart card performs encryption. Computer transfers plaintext to card. Card transfers ciphertext to computer. Card can be stolen, split key between two devices. Key Revocation Certificates invalidated before expiration Usually due to compromised key. May be due to change in circumstance (e.g., someone leaving company.) Problems Is entity revoking certificate authorized to do so? Can revocation information circulates to everyone quickly enough to avoid a compromise? 15
CRLs A Certificate revocation list lists certificates that are revoked, with their IDs and revocation dates. X.509: only issuer can revoke certificate. PGP: signers can revoke signatures; owners can revoke certificates, or allow others to do so. Revocation message placed in PGP packet and signed. Flag marks it as revocation message. Digital Signature Construct that authenticates origin & contents of message in a manner provable to a disinterested third party ( judge. ) Nonrepudiatable Sender cannot deny having sent message. Proves that sender s key was used to sign message. What if you claim key was stolen/compromised? Court would have to decide. Signing and Verification 16
Key Points 1. Key management critical to effective use of cryptosystems. 1. Different levels of keys (session vs. interchange.) 2. Use of nonces, sequence numbers, times to avoid replay attacks. 2. Keys require an infrastructure to identify holders and allow revocation. 1. SSL certificates verified with hierarchy of CAs. 2. PGP certificates verified via web of trust. 3. Digital signatures: integrity of origin and content. 1. Signature is hash of signed document that is encrypted with signer s private key. References 1. Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005. 2. Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone, Handbook of Applied Cryptography, http://www.cacr.math.uwaterloo.ca/hac/, CRC Press, 1996. 3. Bruce Schneier, Applied Cryptography, 2 nd edition, Wiley, 1996. 4. John Viega and Gary McGraw, Building Secure Software, Addison-Wesley, 2002. Extra Slides 17
Key Escrow Key escrow system allows authorized third party to recover cryptographic keys. Useful when keys belong to roles, such as system operator, rather than individuals. Business: recovery of backup keys. Law enforcement: recovery of keys that authorized parties require access to. Goal: provide escrow w/o weakening cryptosystem Very controversial. Desirable Properties 1. Escrow system should not depend on enciphermentalgorithm. 2. Privacy protection mechanisms must work from end to end and be part of user interface. 3. Requirements map to key exchange protocol. 4. System supporting key escrow must require all parties to authenticate themselves. 5. If message to be observable for limited time, key escrow system must ensure keys valid for only that time period. Components 1. User security component Does the encripherment, decipherment. Supports the key escrow component. 2. Key escrow component. Manages storage, use of data recovery keys. 3. Data recovery component. Does key recovery. 18
Example: EES, Clipper Chip Escrow Encryption Standard Set of interlocking components. Designed to balance need for law enforcement access to enciphered traffic with citizens right to privacy. Clipper chip prepares per-message escrow information Each chip numbered uniquely by UID. Special facility programs chip. Key Escrow Decrypt Processor (KEDP) Available to agencies authorized to read messages. User Security Component Unique device key k unique Nonunique family key k family Cipher: Skipjack Classical cipher: 80 bit key, 64 bit I/O blocks Generates Law Enforcement Access Field (LEAF) of 128 bits: { UID { k session } k unique hash } k family hash: 16 bit authenticator from session key and initialization vector. Programming User Components Done in a secure facility Two escrow agencies needed Agents from each present Each supplies a random seed and key number Family key components combined to get k family Key numbers combined to make key component enciphering key k comp Random seeds mixed with other data to produce sequence of unique keys k unique Each chip imprinted with UID, k unique, k family 19
The Escrow Components During initialization of user security component, process creates k u1 and k u2 where k unique = k u1 k u2 First escrow agency gets { k u1 } k comp Second escrow agency gets { k u2 } k comp Obtaining Access obtains legal authorization to read message. She runs message LEAF through KEDP LEAF is { UID { k session } k unique hash } k family KEDP uses (known) k family to validate LEAF, obtain sending device s UID. Authorization, LEAF taken to escrow agencies. Agencies Role Each validates authorization. Each supplies { k ui } k comp, corresponding key number. KEDP takes these and LEAF: Key numbers produce k comp k comp produces k u1 and k u2 k u1 and k u2 produce k unique k unique and LEAF produce k session 20
Would you trust Clipper? 1. Do you think your messages would be private under Clipper? 2. Do you think law enforcement should have access to all cryptographic keys? Problems hash too short LEAF 128 bits, so given a hash: 2 112 LEAFs show this as a valid hash 1 has actual session key, UID Takes about 42 minutes to generate a LEAF with a valid hash but meaningless session key and UID; in fact, deployed devices would prevent this attack. Does not meet temporal requirement As k unique fixed for each unit, once message is read, any future messages can be read. 21