1 / 60

Cryptographic Protocols

Cryptographic Protocols. Overview. Basic notions of cryptographic (security) protocols Problems with cryptographic protocols /Design principles for cryptographic protocols Formal specification and analysis of cryptographic protocols ) two formalizations ) proofs about protocols.

duncan-bernard
Download Presentation

Cryptographic Protocols

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 Protocols

  2. Overview • Basic notions of cryptographic (security) protocols • Problems with cryptographic protocols/Design principles for cryptographic protocols • Formal specification and analysis of cryptographic protocols • ) two formalizations • ) proofs about protocols

  3. Basic Notions • A protocol consists of a set of rules (conventions) which determine the exchange of messages between two or more participants. • participants: users, processes machines, ... • called “principals” • Protocol steps n : A  B : M • “A sends M to B according to the n’ th protocol step.” A, B principals, M message • Messages may be structured: M = M1, ... , Mn

  4. Basic Notions • A protocol (specification) is a sequence of lines describing protocol steps: 1 : A1 B1 : M1 2 : A2 B2 : M2 . . • (informal) specification of the behavior of ordinary participants (principals) • hostile environment: errors, loss of confidentiality/integrity,delay • runs of the protocol: • arbitrary number of ordinary participants (instantiation of variables in the specification): have to obey the rules • attacker: may “interfere” with protocol steps

  5. Basic Notions • Cryptography • encryption of messages: n : A  B : MK • “M is encrypted using key K.” • for each K exists an “inverse” K-1 : K-1-1 = K • keys indexed by participants: KA public key of AKA,B symmetric key shared between A and B • some “rules” of the “game” (formal definition later): (knows( A, MK)  knows(A, K-1))  knows(A, M) (knows(A,K)  knows(A,M)) ) knows(A, MK )

  6. Basic Notions • Cryptography (ctd.) • for symmetric encryption : K-1= K • for asymmetric systems (recall asymmetric schemes!): K-1 private key : signatures • K public key: (asymmetric) encryption

  7. Basic Notions • Nonces (N) • fresh data items • freshness: not used before (generated at a certain step) • only known by the participant (principal) who generates it (owner) • nonces indexed by owners NA • sometimes operations on nonces available • Timestamps (T) • used to measure time (t0, t1, t2, … ) • expiration of keys

  8. A Simple Protocol (in Detail) { A, NA }KB { NA , NB } KA { NB } KB B A • KB = pk(B), KB-1 = sk(B) • KA = pk(A), KA-1 = sk(A) • Needham-Schroeder Public Key Protocol

  9. A Simple Protocol (in Detail) • Specification 1 : A  B : { A, NA }KB • 2 : B  A : { NA , NB } KA • 3: A  B : { NB } KB • The specification defines a set of sequences of communication events (runs). • (up to now) presentation informal • but necessary to “play” with protocols (in an informal way)

  10. Basic Notions (ctd.) • 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 • attacker also generates (sends) messages • sender and receiver are given but not necessarily known to participantsstephan “Hi, I am Dieter Hutter!”  siekmann • similarities/differences with MSC’s in UML • Other events later

  11. Basic Notions • Sequences of events a1 m1  b1a2 m2  b2a3 m3  b3. . • arbitrary finite length • no “liveness” • define admissible (proper) sequences • for ordinary participants • including attacker

  12. Basic Notions • Abilities of the attacker • attacker knows all information that is accessible without breaking the cryptography . .stephan trans 400 from stephan:3467 to 23876  bank . .charlie trans 40000 from stephan:3467 to 56778  bank. . • and may generate new messages using his current knowledge without breaking the cryptography

  13. Basic Notions • Abilities of the attacker (ctd.) • 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 stephan trans 400 from stephan:3467 to 23876k  bank . .charlie trans 40000 from stephan:3467 to 56778k  bank.

  14. Basic Notions • Abilities of the attacker (ctd.) • the attacker is not restricted by the definition of protocol steps: arbitrary messages

  15. Basic Notions -- A Simple Protocol (ctd.) • The behavior of ordinary participants is given by the protocol specification. • The events have to be possible according to general rules. • Example : event corresponding to the first step of the protocol . .alice { alice, Nalice }Kbob bob • not necessarily the first event: protocol steps of other principals , events caused by the attacker

  16. Basic Notions -- A Simple Protocol (ctd.) • Initial “knowledge” of Alice: • Alice wants to communicate with Bob (knows/holds Bob). • Alice expects certain answers (according to the protocol). • Alice knows the public key of Bob. • Alice knows her private key. • Alice is able to generate nonces (Nalice): Nalice has not appeared in the sequence before. Nalice cannot be generated by other participants.

  17. Basic Notions -- A Simple Protocol (ctd.) • Initial knowledge of Bob: • Bob expects certain messages. • Bob knows the public key of Alice. • Bob knows his own private key. • Bob is able to generate nonces (as above). • Bob has obtained (seen) a message : { alice, Nalice }Kbob • not modeled as an extra event here • The receiver has to be Bob. • Bob cannot see the actual sender. • Bob is able to decrypt the message. He does this in order to continue according to the rules of the protocol. • Bob (now) knows that Alice wants to communicate with him. • He generates an answer according to the rules of the protocol.

  18. Basic Notions -- A Simple Protocol (ctd.) • Example : event corresponding to the second step of the protocol . .alice { alice, Nalice }Kbob bob . .bob {Nalice, Nbob }Kalice alice • not necessarily the next event: protocol steps of other principals , events caused by the attacker

  19. Basic Notions -- A Simple Protocol (ctd.) • Alice has obtained (seen) a message : {Nalice, Nbob }Kalice • Alice cannot see the actual sender. • Alice is able to decrypt the message. • Alice sees her nonce (check performed) together with another data item. ) structure of messages • According to the rules of the protocol she interprets this item as a nonce generated by Bob. • She generates an answer according to the rules of the protocol and sends it to Bob, the person she wants to communicate with. • Note: there is no name mentioned in the message.

  20. Basic Notions -- A Simple Protocol (ctd.) • Example : event corresponding to the third step of the protocol . .alice { alice, Nalice }Kbob bob . .bob {Nalice, Nbob }Kalice alice . .alice { Nbob }Kbob bob . .

  21. Basic Notions -- A Simple Protocol (ctd.) • Example : finalizing the protocol • Bob has obtained a message: { Nbob }Kbob • Bob is able todecrypt the message. • He finds a data item. • According to the rules of the protocol he checks: Is it the nonce (I sent to Alice)? • If the answer is yes, this protocol run was successful.

  22. Basic Notions • Generation of runs: Look at previous messages a principal has sent/received, interpret them according to the protocol specification, and generate an answer message according to the protocol specification. • Initial knowledge assumed. • Consider successful runs. • Interleaving with events generated by other principals (running the protocol) and events generated by an attacker. • problem: selection of messages to react to

  23. Basic Notions -- A Simple Protocol (ctd.) • Up to know: informal semantics of protocol specifications • What do we want to achieve by the protocol? • property that holds for all (successful) runs of a given protocol • example (informal idea) : • This is Alice and I have chosen a new nonce Nalice . • This is Bob, you sent me Nalice . Since I’m able to decrypt I must be Bob. I have chosen a new nonce Nbob. • You sent me Nbob . Since I’m able to decrypt I must be Alice.

  24. A Simple Protocol (in Detail) • Intended effect of each step: • Alice sends a secret (Nalice) to Bob (challenge). Bob knows Nalice. Anything else? • Bob sends Nalice back (response) together with a secret Nbob. Alice knows Nbob. Since Bob and only Bob is able to decrypt the first message and Nalice was Alice’s secret, it was Bob who answered. • Alice send back Nbob. As above Bob concludes that it was Alice who responded. • After a succesful run of the protocol the two nonces are shared only by Alice and Bob. The nonces can be used as keys for an authenticated secure communication. • Is this really true? No!!

  25. Problems with Protocols • A man-in-the-middle attack:alice { alice, Nalice }Kchar charliecharlie { alice, Nalice }Kbob bob ( bob {Nalice, Nbob }Kalice alice )charlie {Nalice, Nbob }Kalice alicealice { Nbob }Kchar charliecharlie {Nbob }Kbob bob

  26. Problems with Protocols • What’s wrong with the protocol? • Bob believes that he is communicating with Alice. • Problem with second message specification: 2 : B  A : { NA , NB } KAinstantiation in the failed run:bob (charlie)  {Nalice, Nbob }Kalice alice • repair specification 2 : B  A : { B, NA , NB } KAinstantiation: bob {bob, Nalice, Nbob }Kalice alice

  27. Problems with Protocols • Why is this problem solved? • Trying the same attack:alice { alice, Nalice }Kchar charliecharlie { alice, Nalice }Kbob bobbob {bob, Nalice, Nbob }Kalice alicecharlie {bob, Nalice, Nbob }Kalice alice • Alice expects an answer from Charlie (and not from Bob).

  28. 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

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

  30. Problems with Protocols • No: Charlie can camouflage Alice.alice {alice, Kac}Kchar charlie • charlie {alice, Kac }Kserv servserv {Nserv }Kac alice • charlie {Nserv}Kac alice • alice {Calice, { Nserv }K -1alice}Kac charliecharlie {Calice, { Nserv} K-1alice}Kac serv

  31. Problems with Protocols • Repair (last step) : A  S : {CA, {A, S, KAS, NS }K-1A} KAS • more explicit: Who wishes to access which server. • alice {alice, Kac}Kchar charlie • charlie {alice, Kac}Kserv servserv {Nserv }Kac charlie • charlie {Nserv}Kac alice • alice {Calice, {alice, charlie, Kac,Nserv }K-1alice}Kac charliecharlie {Calice, {alice, charlie, Kac, Nserv }K-1alice}Kac serv • Server notices that Charlie is meant.

  32. 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

  33. 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.

  34. Problems with Protocols • The disaster: alice Calice, Ccharlie, { {Talice , Kac } K-1alice} Kcharlie charlie • charlie Calice, Cbob, { {Talice , Kac } K-1alice} Kbob bob • Bob believes that the last message was sent by Alice. • If he communicates with Alice using Kac, then Charlie is able to listen. • Complete run: easy exercise!

  35. 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: • charlie Calice, Cbob, { {alice, charlie kac , talice } k-1alice} kbob bob • Bob is able to detect that something is wrong. ) not a proper run of the protocol.

  36. 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

  37. 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?

  38. Problems with Protocols • The attack: • charlie alice bob • charlie charlie  bob • bob Nbob alicebob N’bob  charlie • charlie { Nbob }Kcs bobcharlie { Nbob }Kcs bob • bob { alice, { Nbob } Kcs} Kbs server • bob { charlie, {Nbob } Kcs} Kbs server • server { N’’bob } Kbs bob • server { Nbob }Kbs bob • Illegal (faked by charlie) steps in red. • What is N’’bob ? • Why is the second step necessary? • How to repair the flaw?

  39. 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

  40. 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.

  41. Problems with Protocols • It is possible to keep a key alive: alice {Talice, bob, Kab }Kas server • server {Tser, alice, Kab }Kbs bobcharlie {Tser, alice, Kab }Kbs server • server {T’ser, bob, Kab }Kas alicecharlie {T’ser, bob, Kab }Kas server • server {T’’ser, alice, Kab }Kbs bob • Charlie keeps the key alive.

  42. 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 • Martin Abadi, Roger Needham

  43. Principles for Designing Security Protocols • Aspects related to these principles • names • encryption • timeliness • matching of messages • trust

  44. 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.“

  45. 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 .”

  46. 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 ?

  47. Encryption • Clarify the intent of encryption (as a means to convey information ! • 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 !

  48. 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 .

  49. 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

  50. Encryption: Signing of 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

More Related