1 / 53

Cryptographic Protocols Problems and Design

Cryptographic Protocols Problems and Design. Faulty Security Protocols. The more protocols … … the more bugs. Problems with Protocols.

flynn
Download Presentation

Cryptographic Protocols Problems and Design

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. Cryptographic ProtocolsProblems and Design

  2. Faulty Security Protocols The more protocols … … the more bugs

  3. Problems with Protocols • SSL allows for the exchange of session keys on the web A previous version of the protocol: A  S : { A, KAS }KSS  A : { NS } KASA  S : { CA, { NS }K-1 A } KAS • Some explanations: • KAS intended to be the session key • S is the server • KS = pk(S) • K-1A = sk(A) , signature of A • CA certificate of A

  4. Problems with Protocols • Intended effect of each step: • Alice sends a session key KAS and her/his name. • Server sends a secret (challenge) encrypted by KAS . • Alice signs the challenge. • The server assumes that only Alice knows its private key. • Certificate issued by trusted party (certification authority): (name, public key , .... ) • Aim: authentication of client Alice to server. • Is the protocol secure ?

  5. Problems with Protocols No ! Charly can camouflage Alice. Alice{ A, KAC }KCCharly Charly {A, KAC }KS Server Charly {NS }KACServer Alice {NS }KAC Charly Alice {CA, { NS }K -1A}KACCharly Charly {CA, { NS } K-1A}KACServer

  6. Problems with Protocols Repair (last step) : A  S : {CA, {A, S, KAS, NS }K-1A} KAS Alice{ A, KAC }KCCharly Charly {A, KAC }KSServer Charly {NS }KACServer Alice {NS }KAC Charly Alice {CA, {A, C, KAS, NS }K -1A}KACCharly Charly {CA, {A, C, KAS, NS } K-1A}KACServer here the server notices that Charly is meant

  7. Problems with Protocols • Authentication (“Wide-Mouthed-Frog”) A  S : {TA, B, KAB }KASS  B : {TS, A, KAB }KBS • Explanations: • S a server providing session keys • KAS and KBS for secret communication with the server • TA and TS are timestamps, server updates TA to TS

  8. Problems with Protocols • Intended purpose of this protocol: • A at a certain point of time wants to communicate with (access) using KAB (as long as KAB is valid). She/he therefore asks a server to pass this request on to B. • Since the server is able to decrypt with KAS it must be A who was sending the message. The server tells B this result. The server also computes a new timestamp and passes the session key to B. After a certain amount of time B will no longer accept this key. • If A wants to continue she/he has to run the protocol again. Makes it easier to revoke keys.

  9. Problems with Protocols It is possible to keep a key alive: Alice {TA, B, KAB }KASServer {TS, A, KAB }KBSBobAlice {T’S, B , KAB }KAS Server {TS, A, KAB }KBSCharly Charly {T’S, B , KAB }KASServer {T’’S, A, KAB }KBSBob ... Charly keeps the key alive forever.

  10. Problems with Protocols • Key exchange (Dennis & Sacco) A  S : A, BS  A : CA, CBA  B : CA, CB , {{ TA, KAB }K-1A} KB • Explanations: • S a server providing certificates • KAB intended to be the secret session key • KB = pk(B) , B is the intended communication partner • K-1A = sk(A) , signature of A • CA, CB certificates of A and B • TA a timestamp generated by A

  11. Problems with Protocols • Intended purpose of this protocol: • KAB is known only to A and B (session key) • B can be sure that it was sent by A: • She/he can check the signature (using the public key KA). • ) KA is bound to A by the certificate. • B knows that the message was intended for her/him because her/his public key is used. • A knows .... ? • Timestamp may limit the use of session key.

  12. Problems with Protocols • The disaster: Alice  CA, CC, { {TA , KAC } K-1A} KC Charly • Charly  CA, CB, { {TA , KAC } K-1A} KB Bob • Bob believes that the last message was sent by Alice. • If he communicates with Alice using KAC, then Charly is able to listen. • Complete run: easy exercise!

  13. Problems with Protocols • Repair:A  B : CA, CB , {{ A, B, TA, KAB }K-1A} KB • Explicitly expressing that KABis for communication between A, B. • Now: • Charly  CA, CB, { {A, C, TA KAC , TA } K-1A} KBBob • Bob is able to detect that something is wrong. ) not a proper run of the protocol.

  14. Problems with Protocols • Authentication using symmetric key crypto (Woo & Lam)A  B : A B  A : NBA  B : { NB } KASB  S : { A, { NB }KAS } KBSS  B : { NB } KBS • Explanations: • S a server • KAS and KBS for secure communication with the server • B is the intended communication partner

  15. Problems with Protocols • Intended purpose of this protocol: • A claims her/his identity: “Hi, I am A!” • B provides a nonce as a challenge. • A returns challenge encrypted with KAS. This key is shared only between A and S. • B passes this on to S together with A asking for verification. Again KBS is known only to B and S. A is bound to the second part of the message. • If S sent back { NB } KBS , then B can be sure that actually A has responded to his challenge. • Why?

  16. Problems with Protocols • The attack: • Charly A Bob • Charly C Bob • (Alice) NB BobCharly N’B Bob • (Alice) { NB }KcsBobCharly { NB }KcsBob • Bob { A, { NB } KCS} KBSServer • Bob { C, {NB } KCS } KBSServer • Bob{ N”B } KBS Server • Bob { NB }KBS Server • What is N”B ? Why is the second step necessary? How to repair the flaw? N“B = { {NB}KCS }KAS Step 5: S  B : { A, NB } KBS

  17. Security by Design Principles for Designing Security Protocols by Martin Abadi, Roger Needham How to use names, nonces, encryption, timeliness, trust …

  18. Principles for Designing Security Protocols • Each message should say what it means (be self contained): • The interpretation of a message should dependonly on the content (and be independent of the context in which it occurs). • expressed by a natural language sentence • The conditions for a message to be acted upon should be clearly set out. • can be checked by a reviewer

  19. Naming • Denning and Sacco : A  B : CA, CB, { { KAB , TA }SK(A) }PK(B) should denote that: • A has sent the message because of SK(A) (signature) • B is the intended receiver of the message because of PK(B) • But attack as above • Thus partners of communications should be part of the message: A  B : CA, CB, { { A, B, KAB , TA }SK(A) }PK(B) • „At time TA A says KAB is a key good for communication between A and B.“

  20. Naming • Woo and Lam S  B : { NB } KBS should denote that: • A has responded correctly to the challenge • But attack as above since no connection between query (to server S) and response (as above). • The principal “checked” by the server should be mentioned in the message: S  B : { A, NB } KBS • „In order to check (the identity of) A I was able to obtain NB .”

  21. Naming • SSL (previous version) A  B : { CA, { NB }K-1A } KAB should denote that: • A is able to sign the challenge (nonce) sent to her/him by B • But attack as above • A signs challenge in a certain context: A  B : {CA, {A, B, KAB, NB }K -1A } KAB • „I, A, declare to have proposed KAB as a session key for the communication between me and B in the NB - process (run).” • role of NB ?

  22. Naming - Principle If the identity of a principle is essential to the meaning of a message, mention the principle‘s name in the message !

  23. Encryption • Confidentiality: • protection of information: does not convey information • Only the intended recipients are able to recover the information (using the appropriate key). • Authentication (integrity): • Only the proper sender knows the key for encryption. • A message { M } K -1stems from the owner of the secret key K-1 . • Binding of messages: • difference between { X, Y } K -1 and { X } K -1, { Y } K -1 !

  24. Encryption - Principles • Be clear about why encryption is being done! … Encryption is not synonymous with security and its improper use can lead to errors • When a principal signs a message that has already been encrypted, it should not inferred that the principal knows the content of the message…

  25. Example: Encryption in the Kerberos - Protocol • The protocol: 1: A  S : A, B 2: S  A : { TS , L, KAB, B, { TS, L, KAB, A} KBS }KAS 3: A  B : { TS, L, KAB, A} KBS , { A, TA } KAB 4: B  A : { TA + 1 } KAB • TS and TA are timestamps, L is their lifetime • purpose: After a successful run (only) A, and B share KAB .

  26. Example: Encryption in the Kerberos - Protocol • Step 1: no encryption) denial of service attack possible (not considered) • Step 2: • KAB has to be kept confidential. (protection) • authentication of S as the (trusted) server (signature) • Step 3: • double encryption in step 2 {TS, L, KAB, A} KBS ? A must have looked at message 2 in order to extract it. • { A, TA } KAB : A proves the knowledge of KAB at time TA .(TS < TA ) ) really necessary? • Step 4: similar

  27. Encryption: Signing Encrypted Messages • Signing of encrypted messages versus encryption of signed messages • Example (CCITT X.509) : • A  B : A, { TA, NA, B, XA, { YA } KB} KA-1 • XA, YA are data, YA is confidential. • Assured origin and integrity of XA, YA • Problem: not guarantee that A knows YA

  28. Encryption: Signing Encrypted Messages • Possible attack: • Charly removes signature • copies encrypted data (blindly) • adds his own signature • Related scheme: A  B : { XA } KB , {H(X)}KA-1 • asymmetric systems • H hash function (one-way) • similar problem • What can happen?

  29. Timestamp, Nonces and Timelines • Preventing replay - attacks • A message can only be produced in the knowledge of a message that was sent before. (succession) • relating messages (association) • (possible) properties : new, random, unpredictable • predictable nonce have to be protected • use of nonces: challenge-response • Use of timestamps • explicit time

  30. Use of Nonces : The Ottway -Rees Protocol • The specification: • 1: A  B : M, A , B, {NA , M, A , B } KAS • 2: B  S : M, A , B, { NA , M, A , B } KAS , {NB , M, A , B } KBS • 3: S  B : M, { NA , KAB } KAS , { NB , KAB } KBS • 4: B  A : M, { NA , KAB } KAS • Purpose : Establish shared key with help of a server • three nonces M, NA , NB

  31. Use of Nonces : The Ottway -Rees Protocol • Remarks: • In 2 the nonces are bound to names (encryption). • Secure reference is made to these names in 3 and 4. • Nonces are used as substitutes for names (after the binding).

  32. Use of Nonces : The Ottway -Rees Protocol Modified • The new specification: • 1: A  B : A , B, NA • 2: B  S : A , B, NA , NB • 3: S  B : { NA , A, B, KAB } KAS , { NB , A, B, KAB } KBS • 4: B  A : { NA , A, B, KAB } KAS • Use of explicit names simplifies protocol.

  33. Use of Nonces : Freshness • Needham Schroeder Symmetric Key Protocol: • 1: A  S : A, B, NA • 2: S  A : {NA , B, KAB, {KAB, A} KBS }KAS • 3: A  B : { KAB, A} KBS • 4: B  A : {NB} KAB5: A  B : {NB +1} KAB • Remarks: • Any message containing N is recent. • But not every key used for encrypting K is new.

  34. Use of Nonces : Freshness • Again Needham Schroeder Symmetric Key Protocol: • 4: B  A : {NB} KAB5: A  B : {NB +1} KAB • Purpose of 4,5: Handshake of B with A proves that A is present currently (after NB was introduced). • +1 needed to distinguish between the two messages • Does not prove (for B) that KAB is fresh.

  35. Use of Explicit Time • Time management is critical • Synchronous clocks • need protocols to access a time server • time request based on nonces: A  S : A, NAS  A : { TS, NA } KAS • NA must not be predictable • ) attack? • otherwise protection by encryption of NA

  36. Principles for Timelines, Recognizing Protocol (Steps) • The use of predictable quantity can server in guaranteeing newness (through challenge-response). But to be effective, it should be protected so that an intruder cannot simulate a challenge and later replay a response • If timestamps are used for freshness guarantees by reference to absolute time, then differences between local clocks are critical. Time maintenance becomes critical as well. • A key may have been used recently, yet be quite old, and compromised. Recent use does not make the key look any better than it would overwise • If encodings are present then it should be possible to tell which encodings are used. If the encoding is protocol dependent then then it should be possible to deduce that a message belongs to this protocol (run) and to know its step in the protocol.

  37. Trust • Who trusts whom using a protocol • Is there a transitive relation of trust? • Examples: • Cerberos: principal has to trust server and time manager • CA: trust in hierarchy of certification authorities • In general: transport of private messages • Principle: Explicit modeling of trust relation !

  38. Modeling Security Protocols Formalizing the security protocols … … and the attacker

  39. Analysis of Security Protocols • Aim: “Prove” (establish) the security requirements of the protocol • Protocol can have different security requirements • Authentication of principals • Secret key exchange • Formal Analysis: • Formalization of (security) requirements • Formalization of the behaviour of the principals • Formalization of the behaviour of the attacker (Dolev-Yao) • Proof that protocol satisfies the requirements

  40. Modeling the Protocol Basic events a  m  b • a sends m to b (caused by a) • a, b sender and receiver, possible instantiations of variables for principals • arbitrary many agents • sender and receiver are given but not necessarily known to participant • similarities/differences with Message Sequence Charts (MSC) in UML

  41. Modeling the Principals • Protocol defines interaction between principals { A, NA }KB { NA , NB } KA { NB } KB B A

  42. Modeling the Protocol - Traces • Traces  are sequents of events • Each event is typically an instance of a message • Sender and receiver are principals A, B, D… or attacker C • Events may belong to different protocol runs Examples: A - B : { A, NA } KB B - A : {NA , NB} KA A- B : {NB } KB A - B : { A, NA } KB A - D : { A, ND } KD B - A : {NA , NB} KA A - B : { A, NA } KB C - A : { C} KA

  43. Modeling the Principals - Local Views { A, NA }KB { A, Y }KB { NA , X} KA { Y, NB } KA {X} KB {NB } KB A‘s view of the protocol B‘s view of the protocol • Local views reveal less information • unknown sender / receiver • unknown structure of non-decipherable messages

  44. Alice’s (Formal) View of the Protocol Step 1 of the protocol: B 2 Knows(A), NA Used(), 2 P ¢ ( A  B : { A, NA }KB ) 2 P • NA Used(): NA has not been used before in  • B 2 Knows(A): A knows B • 2 P :  is a NSP-beginning

  45. Alice’s (Formal) View of the Protocol Step 3 of the protocol: A  B : { A, NA }KB2, B‘  A : { NA, Y}KA2, 2 P ¢ ( A  B : { Y}KB ) 2 P • 2 P :  is a NSP-beginning

  46. Bob’s (Formal) View of the Protocol Step 2 of the protocol: NB Used(), A‘  B : { A, X}KB2, 2 P ¢ ( B  A : {X, NB }KA ) 2 P • 2 P :  is a NSP-beginning • NB Used(): NB has not been used before in 

  47. What is a successful protocol ? Authentication • Successful authorization of designated principalsi.e. principals are alive and responding • Attacker is not able to authorize as another principal Key exchange • Key has been exchanged between designated principals • Attacker has not learned anything about the key Formalization in general high-level way is rather difficult ▶ Formalization in terms of the individual protocols (nonces etc)

  48. Modeling the Principals • Memory of principals • how long do principals store used nonces or keys? • have principals „unbound“ memory? • Types et al. • do principals check the types of messages? • do principals check the length of messages? • Prudence • do principals care about duplicated messages? • do principals care about nonsense messages?

  49. Modeling the Attacker • Abilities of the attacker • the attacker knows all information that is accessible without breaking the cryptography Hutter  trans 400 from Hutter:3467 to 23876  Bank . .Charly  trans 40000 from Hutter:3467 to 56778  Bank • and may generate new messages using his current knowledge without breaking the cryptography

  50. Modeling the Attacker • The attacker cannot read (know) the content of encrypted messages unless he knows the key • The attacker cannot generate encrypted messages unless he knows the message and the key Hutter  trans 400 from Hutter:3467 to 23876k  Bank . .Charly  trans 40000 from Hutter:3467 to 56778k  Bank.

More Related