CSC 482582 Computer Security Cryptographic Protocols CSC 482582
- Slides: 62
CSC 482/582: Computer Security Cryptographic Protocols CSC 482/582: Computer Security
Topics 1. 2. 3. 4. 5. 6. 7. Dramatis Personae and Notation Session and Interchange Keys Key Exchange Key Generation Cryptographic Key Infrastructure Storing and Revoking Keys Digital Signatures CSC 482/582: Computer Security
Dramatis Personae Cathy, the Computer, trusted 3 rd party. Alice, the 1 st participant Bob, the 2 nd participant Eve, the Eavesdropper CSC 482/582: Computer Security
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 CSC 482/582: Computer Security
Symmetric Key Problems 1. 2. 3. Keys must be distributed in secret. If key is compromised, Eve can decrypt all message traffic encrypted with key. If each pair of users needs a key, number of keys n(n-1) increases rapidly with size of network. CSC 482/582: Computer Security
Mixed PK/Classical Encryption Alice communicates with Bob using PK cipher. 1. Alice randomly generates session key ks. � 2. Alice enciphers ks with Bob’s public key k. B. � � 3. Key ks used only for this single message. k. B enciphers all session keys Alice uses to communicate with Bob. Called an interchange key. Alice sends { m } ks || { ks } k. B to Bob. CSC 482/582: Computer Security
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 �Alice client of Bob’s brokerage. �Communicates with BUY and SELL messages. �Eve enciphers both messages with Bob’s key. �Compares intercepted traffic with ciphertext. CSC 482/582: Computer Security
Key Exchange Algorithms Goal: Alice, Bob 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. �Alice, Bob may trust third party (Cathy. ) �All cryptosystems, protocols publicly known � Only secret data is keys or data used to derive keys. � Anything transmitted is assumed known to attacker. CSC 482/582: Computer Security
Classical Key Exchange Bootstrap problem: how do Alice, Bob begin? �Alice can’t send it to Bob in the clear! Assume trusted third party, Cathy �Alice and Cathy share secret key k. A. �Bob and Cathy share secret key k. B. Let Cathy generate shared key ks. �Cathy can send it securely to either A or B. CSC 482/582: Computer Security
Simple Key Exchange Protocol Alice { request for session key to Bob } k. A Alice CSC 482/582: Computer Security { ks } k. A || { ks } k. B Cathy Bob
Problems How does Bob know he is talking to Alice? Replay attack: Eve records message from Alice to Bob, later replays it; Bob may think he’s talking to Alice, but he isn’t. Session key reuse: Eve replays key exchange message from Alice to Bob, so Bob re-uses session key. Protocols must provide authentication and defense against replay. CSC 482/582: Computer Security
Needham-Schroeder Alice || Bob || r 1 Alice { Alice || Bob || r 1 || ks || { Alice || ks } k. B } k. A Alice CSC 482/582: Computer Security { Alice || ks } k. B { r 2 } k s { r 2 – 1 } k s Cathy Bob Bob
Is Alice really talking to Bob? Second message �Cathy encrypted it, since only A, C know key k. A. �It must be a response to first message as contains r 1. Third message �Alice knows only Bob can read it since encrypted w/ k B. �Any messages enciphered with k. S are from Bob, since only Alice, Bob, and Cathy have k. S. CSC 482/582: Computer Security
Is Bob really talking to Alice? Third message �Cathy encrypted it, since only B, C know key k. B. �Cathy provides session key, says Alice is other party. Fourth message �Uses session key to determine if 3 rd was replay. � If not, Alice 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. CSC 482/582: Computer Security
Needham-Schroeder Assumptions A trusted 3 rd party exists, Cathy. �Many transactions require 3 rd parties. Session keys are always secure. �What if Eve can obtain old keys? CSC 482/582: Computer Security
Denning-Sacco Modification Eve can impersonate Alice if she can obtain old ks. 1. Eve replays Alice’s message { Alice || ks } k. B. 2. Eve uses old ks to decipher Bob’s random number query. Eve Eve CSC 482/582: Computer Security { Alice || ks } k. B { r 2 } k s { r 2 – 1 } k s Bob Bob
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. CSC 482/582: Computer Security
Needham-Schroeder + Denning-Sacco Mod Bob will reject message if timestamp T is too old. Alice || Bob || r 1 Alice { Alice || Bob || r 1 || ks || { Alice || T || ks } k. B } k. A Alice CSC 482/582: Computer Security { Alice || T || ks } k. B { r 2 } k s { r 2 – 1 } k s Cathy Bob Bob
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. CSC 482/582: Computer Security
Otway-Rees Protocol Alice Cathy n || Alice || Bob || { r 1 || n || Alice || Bob } k. A || { r 2 || n || Alice || Bob } k. B Cathy Alice CSC 482/582: Computer Security n || { r 1 || ks } k. A || { r 2 || ks } k. B n || { r 1 || ks } k. A Bob Bob
Argument: Alice talking to Bob Fourth message �If n matches first message, Alice knows it is part of this protocol exchange. �Cathy generated ks because only she & Alice know k. A. �Enciphered part belongs to exchange as r 1 matches r 1 in encrypted part of first message. CSC 482/582: Computer Security
Argument: Bob talking to Alice Third message �If n matches second message, Bob knows it is part of this protocol exchange. �Cathy generated ks because only she & Bob know k. B. �Enciphered part belongs to exchange as r 2 matches r 2 in encrypted part of second message. CSC 482/582: Computer Security
Defeating Replay Attacks Eve acquires old ks, message in third step: �n || { r 1 || ks } k. A || { r 2 || ks } k. B Eve forwards appropriate part to Alice: �Alice has no ongoing key exchange with Bob: n matches nothing, so is rejected. �Alice has ongoing key exchange with Bob: n does not match, so is again rejected. �If replay is for the current key exchange, and Eve sent the relevant part before Bob did, Eve could simply listen to traffic; no replay needed. CSC 482/582: Computer Security
Kerberos Authentication system �Based on Needham-Schroeder with Denning-Sacco modification. �Central server plays role of trusted 3 rd party Cathy. Ticket vouches for identity of requester of service. Active Directory = Kerberos + LDAP CSC 482/582: Computer Security
Ticket Granting Service Requirement: Users only enter password once. �User u authenticates to Kerberos server. �Gets ticket Tu, TGS for ticket granting service (TGS) Requirement: Users don’t send password over net. CSC 482/582: Computer Security
Service Tickets Procedure for a user u to use service s: �User sends authenticator Au, ticket Tu, TGS to TGS asking for ticket for service. �TGS sends ticket Tu, s to user. �User sends Au, Tu, s to server as request to use s. CSC 482/582: Computer Security
Ticket Details Credential saying issuer has identified requester. Example ticket issued to user u for service s Tu, s = s || { u || u’s address || valid time || ku, s } ks where: �ku, 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. CSC 482/582: Computer Security
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 ku, s. Authenticator user u generates for service s Au, s = { u || generation time || kt } ku, s where: �kt is alternate session key. �Time is when authenticator generated. CSC 482/582: Computer Security
Public Key Exchange Here interchange keys known e. A, e. B Alice and Bob’s public keys known to all d. A, d. B Alice and Bob’s private keys known only to owner Simple protocol ks is desired session key. Alice CSC 482/582: Computer Security { ks } e. B Bob
Problem and Solution Vulnerable to forgery or replay Because e. B known to anyone, Bob has no assurance that Alice sent message. Simple fix uses Alice’s private key ks is desired session key. Alice CSC 482/582: Computer Security { { ks } d. A } e. B Bob
Notes Can include message enciphered with ks Assumes Bob has Alice’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-middle attack (next slide; Cathy is public server providing public keys. ) �Solution: Public key infrastructure (PKI) CSC 482/582: Computer Security
Man-in-the-Middle Attack Alice please send Bob’s public key Eve Alice e. E please send Bob’s public key e. B Cathy Eve { ks } e. E Eve intercepts message Eve CSC 482/582: Computer Security Eve intercepts request { ks } e. B Bob
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. CSC 482/582: Computer Security
Certificates Create token (message) containing: � Identity of principal (here, Alice) � Corresponding public key � Timestamp (when issued) � Other information (perhaps identity of signer) signed by trusted authority (Cathy. ) CA = { e. A || Alice || T } d. C CSC 482/582: Computer Security
Use Bob downloads Alice’s certificate �If he knows Cathy’s public key, he can decipher the certificate � When was certificate issued? � Is the principal Alice? �Now Bob has Alice’s public key. Problem: Bob needs Cathy’s PK to validate cert. �Problem pushed up a level. �Solution: signature chains. CSC 482/582: Computer Security
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. CSC 482/582: Computer Security
X. 509 (SSL) Certificates Some certificate components in X. 509 v 3: �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 CSC 482/582: Computer Security
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 CSC 482/582: Computer Security
Issuers Certification Authority (CA): entity that issues certificates; Cathy, the trusted 3 rd party �Multiple issuers pose validation problem. �Alice’s CA is Cathy; Bob’s CA is Don; how can Alice validate Bob’s certificate? �Have Cathy and Don cross-certify � Each issues certificate for the other CA. Notation: Certificate X issued for Y X<<Y>> CSC 482/582: Computer Security
Validation and Cross-Certifying Certificates: Cathy<<Alice>> Dan<<Bob>> Cathy<<Dan>> Dan<<Cathy>> Alice validates Bob’s certificate: �Alice obtains Cathy<<Dan>> �Alice uses (known) public key of Cathy to validate Cathy<<Dan>> �Alice uses Cathy<<Dan>> to validate Dan<<Bob>> CSC 482/582: Computer Security
PGP Chains Open. PGP certificates verified via “web of trust” �No hierarchy of CAs to follow like SSL certificates �Certificates can be signed by multiple parties Open. PGP certificates structured into packets: �One public key packet. �Zero or more signature packets. CSC 482/582: Computer Security
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. ” CSC 482/582: Computer Security
Validating Certificates Alice needs to validate Bob’s Open. PGP cert �!: Fred, Giselle, Ellen. Arrows show signatures Self signatures not shown Alice gets Giselle’s cert Jack �Knows Henry slightly, but signature at “casual” trust. Alice gets Ellen’s cert �Knows Jack, so uses his cert to validate Ellen’s, then hers to validate Bob’s. Jack<<Ellen>>Ellen<<Bob>> CSC 482/582: Computer Security Henry Irene Ellen Giselle Fred Bob
Storing Keys Multi-user or networked systems: attackers may defeat access control mechanisms. 1. Encipher file containing key. � � 2. Attacker can monitor keystrokes to decipher files Key will be resident in memory. 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. CSC 482/582: Computer Security
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? CSC 482/582: Computer Security
CRLs A Certificate revocation 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. CSC 482/582: Computer Security
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. CSC 482/582: Computer Security
Signing and Verification
Key Points 1. Key management critical to effective use of cryptosystems. Different levels of keys (session vs. interchange. ) 2. Use of nonces, sequence numbers, times to avoid replay attacks. 1. 2. Keys require an infrastructure to identify holders and allow revocation. 1. 2. SSL certificates verified with hierarchy of CAs. 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. CSC 482/582: Computer Security
References 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 Mc. Graw, Building Secure Software, Addison-Wesley, 2002. 1. CSC 482/582: Computer Security
Extra Slides CSC 482/582: Computer Security
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. CSC 482/582: Computer Security
Desirable Properties Escrow system should not depend on encipherment algorithm. 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. 1. CSC 482/582: Computer Security
Components 1. User security component Does the encripherment, decipherment. � Supports the key escrow component. � 2. Key escrow component. � 3. Manages storage, use of data recovery keys. Data recovery component. � Does key recovery. CSC 482/582: Computer Security
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. CSC 482/582: Computer Security
User Security Component �Unique device key kunique �Nonunique family key kfamily �Cipher: Skipjack �Classical cipher: 80 bit key, 64 bit I/O blocks �Generates Law Enforcement Access Field (LEAF) of 128 bits: �{ UID || { ksession } kunique || hash } kfamily �hash: 16 bit authenticator from session key and initialization vector. CSC 482/582: Computer Security
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 kfamily �Key numbers combined to make key component enciphering key kcomp �Random seeds mixed with other data to produce sequence of unique keys kunique Each chip imprinted with UID, kunique, kfamily CSC 482/582: Computer Security
The Escrow Components During initialization of user security component, process creates ku 1 and ku 2 where kunique = ku 1 ku 2 �First escrow agency gets { ku 1 } kcomp �Second escrow agency gets { ku 2 } kcomp CSC 482/582: Computer Security
Obtaining Access �Alice obtains legal authorization to read message. �She runs message LEAF through KEDP �LEAF is { UID || { ksession } kunique || hash } kfamily �KEDP uses (known) kfamily to validate LEAF, obtain sending device’s UID. �Authorization, LEAF taken to escrow agencies. CSC 482/582: Computer Security
Agencies’ Role �Each validates authorization. �Each supplies { kui } kcomp, corresponding key number. �KEDP takes these and LEAF: �Key numbers produce kcomp �kcomp produces ku 1 and ku 2 �ku 1 and ku 2 produce kunique �kunique and LEAF produce ksession CSC 482/582: Computer Security
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? CSC 482/582: Computer Security
Problems hash too short �LEAF 128 bits, so given a hash: � 2112 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 kunique fixed for each unit, once message is read, any future messages can be read. CSC 482/582: Computer Security
- Privat security
- Network security protocols
- Playfair cipher
- The most complex part of tls is the
- Data link layer design issues in computer networks
- Elementary data link protocols in computer networks
- Data link control protocols in computer networks
- Hdlc operation
- Protocols and standards in computer networks
- Military cryptographic equipment
- Lcs
- Pkix
- Cryptographic hash functions
- Owasp foundation
- Cryptographic concepts
- Pin punctures steganography
- Cryptographic tools
- Collision resistant hash function
- Cryptographic
- Network security essentials 5th edition
- Cryptographic attacks
- Owasp
- Koi 18
- Insecure cryptographic storage challenge 3
- Osi security architecture with neat diagram
- Guide to network security
- Wireless security in cryptography and network security
- Visa international security model
- Electronic mail security in network security
- Cnss model 27 cells example
- E commerce security meaning
- Seven touchpoints for software security
- Security guide to network security fundamentals
- Security guide to network security fundamentals
- Wan connection types
- Channel partitioning mac protocols
- Proofs of work and bread pudding protocols
- Presentation layer design issues
- Local government protocols
- Cache coherence protocols
- Dedicated line
- Wireless sensor network protocols
- Define nursing protocols
- Communication protocols for rpc
- Cryptography standards and protocols
- What are two pitfalls (problems) of lock-based protocols
- Tcp and sctp are both layer protocols
- What are two pitfalls (problems) of lock-based protocols
- What are two pitfalls (problems) of lock-based protocols
- Session layer protocols
- Local reliability protocols in distributed dbms
- Pipelining protocol
- Data link layer protocols
- Whats my ip
- Therapist driven protocols
- Gfta-3 bell curve
- Channel partitioning protocols
- Real world protocols
- Orange county ems protocols
- Multimedia streaming protocols
- Consistency and replication in distributed systems
- Routing protocols administrative distance
- Gateway protocols