Security Protocols
Topics 1. Basic Concepts of Cryptography 2. Security Protocols 3. Authentication Protocols 4. Key Exchange Protocols 5. Kerberos 6. Public Key Infrastructure
Encryption and Decryption The message M is called the plaintext. Alice will convert plaintext M to an encrypted form using an encryption algorithm E that outputs a ciphertext C for M. Sender Communication channel Recipient encrypt decrypt ciphertext plaintext plaintext shared secret key Attacker (eavesdropping) shared secret key 3
Encryption and Decryption As equations: C = E(M,K) M = D(C,K) The encryption and decryption algorithms are chosen so that it is infeasible for someone other than Alice and Bob to determine plaintext M from ciphertext C without knowing the key K. Thus, ciphertext C can be transmitted over an insecure channel that can be eavesdropped by an adversary. 4
Caesar Cipher Replace each letter with the one three over in the alphabet. Public domain image from http://commons.wikimedia.org/wiki/file:caesar3.svg 5
Kerckhoff s Principle Security of cryptosystem should only depend on 1. Quality of shared encryption algorithm E 2. Secrecy of key K Security through obscurity tends to fail ex: DVD Content Scrambling System 6
Symmetric Cryptosystems Alice and Bob share a secret key, which is used for both encryption and decryption. Sender Communication channel Recipient encrypt decrypt ciphertext plaintext plaintext shared secret key shared secret key Attacker (eavesdropping) 7
Symmetric Key Distribution Requires each pair of communicating parties to share a (separate) secret key. shared secret shared secret shared secret shared secret shared secret n (n 1)/2 keys shared secret 8
Public-Key Cryptography Bob has two keys: a private key, SB, which Bob keeps secret, and a public key, PB, which Bob broadcasts widely. In order for Alice to send an encrypted message to Bob, she need only obtain his public key, PB, use that to encrypt her message, M, and send the result, C = E PB (M), to Bob. Bob then uses his secret key to decrypt the message as M = D SB (C). 9
Public-Key Cryptography Separate keys for encryption and decryption. Sender Communication channel Recipient encrypt decrypt plaintext ciphertext plaintext plaintext public key private key Attacker (eavesdropping) 10
Public Key Distribution Only one key is needed for each recipient private private public public public public n key pairs private private 11
Digital Signatures Public-key encryption provides a method for doing digital signatures To sign a message, M, Alice just encrypts it with her private key, SA, creating C = E SA (M). Anyone can decrypt this message using Alice s public key, as M = D PA (C), and compare that to the message M. 12
Cryptographic Hash Functions A checksum on a message, M, that is: One-way: it should be easy to compute Y=H(M), but hard to find M given only Y Collision-resistant: it should be hard to find two messages, M and N, such that H(M)=H(N). Examples: MD5, SHA-1, SHA-256. 13
Message Authentication Codes Allows for Alice and Bob to have data integrity, if they share a secret key. Given a message M, Alice computes H(K M) and sends M and this hash to Bob. Communication channel message M h 6B34339 4C66809 4C66809 MAC MAC (attack detected) 87F9024 =? received computed MAC MAC h message M Sender shared secret key Attacker (modifying) shared secret key Recipient 14
What is a Protocol? Human protocols: rules and procedures followed in human interactions, such as social situations. Example: Ordering, eating, and paying in a restaurant. Network protocols: rules followed in networked communication systems. Examples: TCP/IP, HTTP, FTP, etc. Security protocols: communication rules followed in a security application. Examples: SSL/TLS, IPSec, Kerberos, etc.
ATM Machine Protocol 1. Insert ATM card. 2. Enter PIN. 3. Correct PIN? (3 tries allowed) Yes? Conduct your transaction No? Machine eats card
Dramatis Personae Cathy, the Computer, trusted 3 rd party. Alice, 1 st participant Bob, 2 nd participant Eve, the Eavesdropper
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
Car unlocking protocols Principals are the engine controller E and the car key transponder T. T E: KT How does protocol address the threat of car theft? Threat can replay KT to gain access to car later. Can thief guess the transponder key, KT?
Car unlocking protocols II Principals are engine controller E and the car key transponder T. N is a nonce, number used once. T E: T {T,N} KT How does protocol address the threat of car theft? E verifies T with encrypted version of T. Nonce prevents replay attack.
Car unlocking protocols III Principals are engine controller E and the car key transponder T. N is a nonce, number used once. E T: N T E: {T N } KT How does protocol address the threat of car theft? Interactive protocol starts with E sending T a nonce N. T encrypts and returns nonce with transponder ID T. Nonce cannot be replayed since returned nonce is encrypted.
Nonce A nonce is an arbitrary nonrepeating number used in security protocols to protect against replay attacks. If a nonce repeats, it fails to prevent replay attacks. Generating a nonce Timestamp Random number from sufficiently large space not to repeat frequently enough to be vulnerable to replays.
Authentication Protocols I m Alice Prove it My password is letmein Alice Bob Single computer authentication protocol, where Alice is the user. Bob is the login program.
Authentication Protocol Threats I m Alice Prove it Alice My password is letmein Bob Eve Sniffing Replay attacks Modifications
Hashes protect against Sniffing I m Alice Prove it Alice h(alice s password) Bob h is a one-way (hash) function. Bob can compare with a stored hash of Alice s password. Eve What about replay attacks?
Challenge-Response Authentication I m Alice nonce Alice h(alice s password nonce) Bob The nonce is the challenge. The hash is the response. Eve
Challenge-Response Protocol Request from Alice Challenge information Alice Information that can only be from Alice which Bob can verify. Bob Eve
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 Alice communicates with Bob using PK cipher. 1. Alice randomly generates session key k s. Key k s used only for this single message. 2. Alice enciphers k s with Bob s public key k B. k B enciphers all session keys Alice uses to communicate with Bob. Called an interchange key. 3. Alice sends { m } k s { k s } k B to Bob.
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 (dictionary) 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.
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.
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 k s. Cathy can send it securely to either A or B.
Simple Key Exchange Protocol { request for session key to Bob } k A Cathy { k s } k A { k s } k B Cathy { k s } k B Alice Bob
Simple Key Exchange Vulnerabilities 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.
Needham-Schroeder Alice Alice Bob r 1 Cathy Alice { Alice Bob r 1 k s { Alice k s } k B } k A Cathy Alice { Alice k s } k B Bob Alice { r 2 } k s Bob Alice { r 2 1 } k s 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.
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.
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?
Denning-Sacco Modification Eve can impersonate Alice if she can obtain old k s. 1. Eve replays Alice s message { Alice k s } k B. 2. Eve uses old k s to decipher Bob s random number query. Eve { Alice k s } k B Bob Eve { r 2 } k s Bob Eve { r 2 1 } k s 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.
Needham-Schroeder + Denning-Sacco Mod Bob will reject message if timestamp T is too old. Alice Alice Bob r 1 Cathy Alice { Alice Bob r 1 k s { Alice T k s } k B } k A Cathy Alice { Alice T k s } k B Bob Alice Alice { r 2 } k s { r 2 1 } k s 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.
Otway-Rees Protocol Alice n Alice Bob { r 1 n Alice Bob } k A Bob Cathy n Alice Bob { r 1 n Alice Bob } k A { r 2 n Alice Bob } k B Bob Cathy n { r 1 k s } k A { r 2 k s } k B Bob Alice n { r 1 k s } k A Bob
Argument: Alice talking to Bob Fourth message If n matches first message, Alice knows it is part of this protocol exchange. Cathy generated k s because only she & Alice know k A. Enciphered part belongs to exchange as r 1 matches r 1 in encrypted part of first message.
Argument: Bob talking to Alice Third message If n matches second message, Bob knows it is part of this protocol exchange. Cathy generated k s because only she & Bob 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 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.
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
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.
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 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 k s is desired session key. Alice { k s } 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 k s is desired session key. Alice { { k s } d A } e B Bob
Notes Can include message enciphered with k s 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)
Man-in-the-Middle Attack Alice please send Bob s public key Eve intercepts request Cathy Eve please send Bob s public key Cathy Eve e B Cathy Alice e E Eve Alice { k s } e E Eve intercepts message Bob Eve { k s } 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.
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.) C A = { e A Alice T } d C
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.
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.
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; 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>>
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>>
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.
Validating Certificates Alice needs to validate Bob s OpenPGPcert Arrows show signatures!: Fred,Giselle,Ellen. Self signatures not shown Alice gets Giselle s cert Jack Knows Henry slightly, but signature at casual trust. Henry Ellen Alice gets Ellen s cert Irene Knows Jack, so uses his cert Giselle to validate Ellen s, then hers to validate Bob s. Fred Jack<<Ellen>>Ellen<<Bob>> Bob
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?
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
Key Points 1. Security protocols 1. Definition and notation 2. Authentication protocols 2. Key protocols critical to effective use of cryptosystems. 1. Different levels of keys (session vs. interchange.) 2. Nonces, sequence numbers, timestamps to avoid replay attacks. 3. 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. 4. 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.