1 / 30

Protocol Analysis

Protocol Analysis. 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 522 - Farkas. 2. Emerging Properties of Protocols.

warren
Download Presentation

Protocol Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protocol Analysis

  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 522 - Farkas 2

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

  4. Protocols Good protocol characteristics: • Established in advance • Mutually subscribed • Unambiguous • Complete CSCE 522 - Farkas 4

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

  6. CSCE 522 - Farkas Symmetric-Key Distribution without Server • Change encryption key E(Knew,K), where Knew is the session key, K is the master key New key Ciphertext C New key Encryption Decryption Sender Recipient K

  7. CSCE 522 - Farkas (O,R,IO) E([(IO,R,KOR,E((KOR,O), KR)], KO) E((KOR,O), KR) Originator Symmetric-Key Distribution with Server Knows KO and KR Server Recipient Decrypts with KR Knows KOR Decrypts with KO Knows KOR Does not know E((KOR,O), KR) CSCE 522 - 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 522 - Farkas 8

  9. Public key of S Secret Session key Simple secret key distribution • KE-S ||ID-S 2. E KE-S(Ksession) Sender Recipient Vulnerable to active attack! HOW? CSCE 522 - Farkas 9

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

  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 522 - Farkas 11

  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=gx mod n and sends X to B • B chooses random y and computes Y=gy mod n and sends Y to A • A computes Yx mod n = gyx mod n • B computer Xy mod n = gyx mod n • Secret key: gyx mod n CSCE 522 - Farkas 12

  13. Diffie-Hellman Key Exchange • Requires no prior communication between A and B • Security depends on difficulty of computing x given X=gx 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 522 - Farkas 13

  14. Intruder in the Middle Attack Eve Bob Alice Hi Alice, I’m Bob. Hi Alice, I’m Bob. Hi Bob, I’m Alice. Hi Bob, I’m Alice. 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 522 - Farkas 14

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

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

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

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

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

  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 522 - Farkas 20

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

  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 522 - Farkas 22

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

  24. CSCE 522 - Farkas 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 K0 established before the communication. They do not have access to a mutually trusted server, and no other keys but K0 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.

  25. CSCE 522 - Farkas 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, KA and, similarly, Bob has a secret-key shared with Server, KB. NA and NB 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,

  26. CSCE 522 - Farkas Exercise 2. • Message1: Alice  Server: IDA || E(“request for session key to Bob”, KA) • Server: • The server sees that that claimed sender of the message is Alice. • The server can decrypt the message using KA that is shared between Alice and the Server. The message must have been sent by Alice because KA 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 KS to be used by Alice and Bob and send the key to …

  27. CSCE 522 - Farkas Exercise 2. • Message1: Alice  Bob: IDA || NA • Bob knows/can do • Message2: Bob  Server: IDB || E[(IDB || NA || NB), KB] • Server knows/can do • Message3: Server  Alice: E[(IDB || KS || NA || NB), KA] || E[(IDA || KS), KB] • Alice knows/can do • Message4: Alice  Bob: E[(IDA || KS), KB] || E(NB, KS)] • Bob knows/can do

  28. CSCE 522 - Farkas 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, KpubA means the public key of A, KprivA means private key of A.

  29. CSCE 522 - Farkas Exercise 3. • Message1: Ann  Bob: IDA || E(M, KpubA) • Message 2: Bob  Ann: IDB || E[(E(M, KpubA)), KpubB) • Message3: Ann  Bob: IDA || E(M, KpubB) • Show a man-in-the-middle attack against the above protocol.

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

More Related