Protocol Analysis

CSCE Farkas 2 Cryptographic Protocols Two or more parties Communication over insecure network Cryptography used to achieve goal  Exchange secret keys  Verify identity (authentication)  Secure transaction processing

CSCE Farkas 3 Emerging Properties of Protocols Greater interoperation Negotiation of policy Greater complexity Group-oriented protocols Emerging security threats

CSCE Farkas 4 Protocols Good protocol characteristics: Established in advance Mutually subscribed Unambiguous Complete

CSCE Farkas 5 Symmetric-Key Distribution: Symmetric-Key Techniques (repeat from lecture on 05/13/2014) Symmetric-Key without Server Symmetric-Key with Server

CSCE Farkas 6 Symmetric-Key Distribution without Server Change encryption key E(K new,K), where K new is the session key, K is the master key Encryption Decryption New key Ciphertext C SenderRecipient K

Originator (O,R,I O )E([(I O,R,K OR,E((K OR,O), K R )], K O ) E((K OR,O), K R ) Server CSCE Farkas 7 Symmetric-Key Distribution with Server Recipient Decrypts with K O Knows K OR Does not know E((K OR,O), K R ) Decrypts with K R Knows K OR Knows K O and K R

CSCE Farkas 8 Symmetric-Key Distribution: Public-Key Techniques Simple secret key distribution – insecure Secret key distribution with confidentiality and authentication Diffie-Hellman Key Exchange

CSCE Farkas 9 Simple secret key distribution SenderRecipient 1.KE-S ||ID-S 2. E KE-S (K session ) Vulnerable to active attack! HOW? Public key of S Secret Session key

CSCE Farkas 10 With confidentiality and authentication SenderRecipient 1.E KE-R [N1||ID-S] 2. E KE-S [N1||N2] 3. E KE-R [N2] 4. E KE-R E KD-S (K session ) Assume: KE-R and KE-S are known in advance Nonce Question: Why do we need reliable distribution of public keys?

CSCE Farkas 11 Diffie-Hellman Key Exchange Proposed in 1976 First public key algorithm Allows group of users to agree on secret key over insecure channel Cannot be used to encrypt and decrypt messages

CSCE Farkas 12 Diffie-Hellman Key Exchange Protocol for A and B want to agree on shared secret key: A and B agree on two large numbers n and g, such that 1<g<n A chooses random x and computes X=g x mod n and sends X to B B chooses random y and computes Y=g y mod n and sends Y to A A computes Y x mod n = g yx mod n B computer X y mod n = g yx mod n Secret key: g yx mod n

CSCE Farkas 13 Diffie-Hellman Key Exchange Requires no prior communication between A and B Security depends on difficulty of computing x given X=g x mod n Choices for g and n are critical: both n and (n-1)/2 should be prime, n should be large Susceptible to intruder in the middle attack (active intruder)

CSCE Farkas 14 Intruder in the Middle Attack BobAlice Eve Hi Alice, I’m Bob. Hi Bob, I’m Alice. Hi Alice, I’m Bob. Intruder and Bob Uses Diffie-Hellman To agree on key K. Intruder and Alice Uses Diffie-Hellman To agree on key K’. Question: the attacker may want to have K and K’ be the same, Why?

CSCE Farkas 15 Public-Key Distribution Without server  Broadcasting - insecure  Publicly available directory With trusted server  Public key distribution center  Certificates

CSCE Farkas 16 Public announcement John Smith KE-J.S. Question: What are the vulnerabilities of this approach?

CSCE Farkas 17 Publicly available directory Public Key Directory John Smith Mary Rose KE-J.S.KE-M.R.. Better but not good enough  Directory could Be compromised

CSCE Farkas 18 Public-key authority Public-Key Authority Sender Recipient 1. Request || Time1 2. E KD-Auth [KE-R||Request||Time1] 3. E KE-R (ID-S||N1) 4. Request || Time2 5. E KD-Auth [KE-S||Request||Time2] 6. E KE-S (N1||N2) 7. E KE-R (N2) Question1: What should the Authority, the Sender and the Recipient know before communication? Exercise: After each message, show what the recipient of the message can do and what the Recipient know.

CSCE Farkas 19 Public-key certificates Certificate Authority Sender Recipient KE-S C-S=E KD-CAuth [Time1,ID-S,KE-S] 1. C-S 2. C-R KE-R CR=E KD-CAuth [Time2,ID-R,KE-R]

CSCE Farkas 20 Certificates Guarantees the validity of the information Establishing trust Public key and user identity are bound together, then signed by someone trusted Need: digital signature

CSCE Farkas 21 Digital Signature Need the same effect as a real signature  Un-forgeable  Authentic  Non-alterable  Not reusable

CSCE Farkas 22 Digital signature Direct digital signature: public-key cryptography based Arbitrated digital signature:  Conventional encryption: Arbiter sees message Arbiter does not see message  Public-key based Arbiter does not see message

CSCE Farkas 23 Digital Signatures in RSA Sender Recipient Insecure channel Plaintext Signed plaintext Encryption Alg. Decryption Alg. S’s public keyS’s private key (need reliable channel) SignVerify

Protocol Analysis Exercise 1. Assume that Jane and Paul want to efficiently send very large files to each other. They also want to provide integrity verification, third- party message authentication (i.e., a third party can verify who the originator of the message is), and limit the scope of a compromise (i.e., providing forward secrecy). You can assume that Jane and Paul have public and secret key encryption capabilities, can generate a hash function, and they have a shared secret key K 0 established before the communication. They do not have access to a mutually trusted server, and no other keys but K 0 are known at the beginning of the communication. Propose a security protocol to establish necessary keys and show how Jane can send a file to Paul. CSCE Farkas Lecture 8-9

Exercise 2. Message authentication and key agreement Alice wants to establish a secure communication with Bob. They agree to user the Yahalom protocol for mutual authentication and key agreement. The protocol uses symmetric key encryption only. Alice has a secret key shared with a trusted third party Server, K A and, similarly, Bob has a secret-key shared with Server, K B. N A and N B are nonces generated by Alice and Bob, respectively. E(M, K) indicates encryption of message M with key K, “||” means concatenation of messages. Explain after each protocol step what the recipient of the message knows based on the message and the properties of the encryption and what he/she is capable of doing. For example, CSCE Farkas Lecture 8-9

Exercise 2. Message1: Alice  Server:ID A || E(“request for session key to Bob”, K A ) Server: The server sees that that claimed sender of the message is Alice. The server can decrypt the message using K A that is shared between Alice and the Server. The message must have been sent by Alice because K A is only known by Alice and the server. The server knows that Alice is requesting a session key to be used by Alice and Bob. The server can generate a session key K S to be used by Alice and Bob and send the key to … CSCE Farkas Lecture 8-9

Exercise 2. Message1: Alice  Bob: ID A || N A Bob knows/can do Message2: Bob  Server:ID B || E[(ID B || N A || N B ), K B ] Server knows/can do Message3: Server  Alice: E[(ID B || K S || N A || N B ), K A ] || E[(ID A || K S ), K B ] Alice knows/can do Message4: Alice  Bob: E[(ID A || K S ), K B ] || E(N B, K S )] Bob knows/can do CSCE Farkas Lecture 8-9

Exercise 3. Secure communication Consider the following protocol. Ann wants to send a message M securely to Bob but there is no shared secret key between Ann and Bob, Ann does not even know Bob’s public key. However, using the properties of RSA (in particular the commutative property), Ann proposes the following protocol, where E(M, K) indicates encryption/decryption of message M with key K, “||” means concatenation of messages, K pub A means the public key of A, K priv A means private key of A. CSCE Farkas Lecture 8-9

Exercise 3. Message1: Ann  Bob:ID A || E(M, K pub A ) Message 2: Bob  Ann:ID B || E[(E(M, K pub A )), K pub B ) Message3: Ann  Bob:ID A || E(M, K pub B ) Show a man-in-the-middle attack against the above protocol. CSCE Farkas Lecture 8-9

CSCE Farkas 30 Lecture 8-9 Next class Review for Test 1