1 / 36

Cryptographic Protocols and Possible Attacks

Cryptographic Protocols and Possible Attacks. SOEN321- Information-Systems Security Revision: 1.1 Date: November 25, 2004. Contents. Security Flaws in Cryptographic Protocols Freshness Flaws Oracle Flaws Type Flaws Implementation-Dependent Flaws Elementary Flaws Others. Security Flaws.

symona
Télécharger la présentation

Cryptographic Protocols and Possible Attacks

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 andPossible Attacks SOEN321- Information-Systems Security Revision: 1.1 Date: November 25, 2004 Serguei A. Mokhov, mokhov@cs.concordia.ca

  2. Contents • Security Flaws in Cryptographic Protocols • Freshness Flaws • Oracle Flaws • Type Flaws • Implementation-Dependent Flaws • Elementary Flaws • Others Serguei A. Mokhov, mokhov@cs.concordia.ca

  3. Security Flaws • A flaw is a protocol property that contradicts the security requirements. • A security flaw is a part of a program that can cause the system to violate its security requirements. • Finding security flaws, then, demands some knowledge of the system security requirements. These requirements vary according to the system and the application [Landweher, Bull, McDermott and Choi]. • The proof of a flaw is commonly known as an “attack” and it is generally presented as actions performed on the protocol. Serguei A. Mokhov, mokhov@cs.concordia.ca

  4. Flow Types • Freshness • Oracle • Type • Implementation-Dependent • Others… Serguei A. Mokhov, mokhov@cs.concordia.ca

  5. Freshness Flaws • Freshness flaws appear when critical messages are used in the protocol without including freshness information such as nonces and/or timestamps. • This lack can be exploited by an intruder to do a masquerade by replaying messages belonging to previous runs. Serguei A. Mokhov, mokhov@cs.concordia.ca

  6. Freshness Flaws • A classical example of a freshness flaw occurs in the symmetric-key protocol proposed by Needham-Shroeder: • Message 1 A ->S : A,B,Na • Message 2 S ->A : {Na,B, kab, {kab,A}kbs }kas • Message 3 A ->B : {kab,A}kbs • Message 4 B ->A : {Nb}kab • Message 5 A ->B : {Nb+ 1}kab Serguei A. Mokhov, mokhov@cs.concordia.ca

  7. Freshness Flaws (2) • This protocol aims to provide a mutual authentication between two principals A and B. • Each principal shares a secret key with a trusted server S. • This protocol was thought to be correct until 1981 when the basic weakness was pointed out by Denning and Sacco. • The main problem of this protocol is that the principal playing the role B cannot detect whether the message {kab,A} sent by the principal playing the role A at step 3 has been recently created or not since it does not contain any freshness information. Serguei A. Mokhov, mokhov@cs.concordia.ca

  8. Freshness Flaws (3) • Suppose, for example, that an intruder can compromise one previously distributed key k’ab(by using cryptanalysis for example) and it replays the appropriate message to the principal playing the role B in step 3. • In this case, the principal playing the role B will accept this key as a new one and it replays by the message {Nb}k’ab • Hence, the intruder can intercept this message and impersonate A’s reply by sending the message {Nb+ 1}k’ab Serguei A. Mokhov, mokhov@cs.concordia.ca

  9. Freshness Flaws (4) • To fix this weakness, Denning and Sacco have proposed to add a timestamp to the messages used at step 2 and step 3: • Message 1A -> S : A,B,Na • Message 2S -> A : {T,Na,B, kab, {kab,A, T}kbs}kas • Message 3A -> B : {kab,A, T}kbs • Message 4B -> A : {Nb}kab • Message 5A -> B : {Nb+ 1}kab • Needham and Shroeder have proposed a solution based on the use of nonces. The two proposed solutions seem to resolve the problem, however there is no correction proof for any one of those new versions. Serguei A. Mokhov, mokhov@cs.concordia.ca

  10. Oracle Flaws • Oracle flaws occur when the cryptographic protocol dialog allows an adversary to know some secret information or to foretell the content of some encrypted messages. • Two subclasses of oracle flaws are distinguished: • Single oracle flaws and, • Multi-role oracle flaws. Serguei A. Mokhov, mokhov@cs.concordia.ca

  11. Single Oracle Flaws • It consists of oracle flaws that occur when the protocol does not allow principals to change their roles from one protocol run to another. • The most famous example of a single role oracle flaw was given by Rivest, Shamir, and Adelman. It consists of the following three-steps protocol: • Message 1A -> B : {M}ka • Message 2B -> A : {{M}ka}kb • Message 3A -> B : {M}kb • We assume that the encrypting function is commutative i.e. {{M}ka}kb={{M}kb}ka Serguei A. Mokhov, mokhov@cs.concordia.ca

  12. Single Oracle Flaws (2) • The goal of this protocol is to transfer secret messages from one principal to another without the help of a trusted server. • In step one, the principal playing the role A encrypts the messages M under its secret key ka(can be randomly generated) then sends the result to the principal playing the role B. • In the second step, the principal playing the role B encrypts the received message with its secret key kband sends the result to the principal playing the role A. • Finally, the principal playing the role A decrypts the message {{M}ka}kbto obtain the message {M}kb(this can be achieved under the commutative assumption) which is sent to the principal playing the role B. Serguei A. Mokhov, mokhov@cs.concordia.ca

  13. Single Oracle Flaws (3) • This protocol can be attacked as follows: • Message 1A -> I(B) : {M}ka • Message 2I(B) -> A : {M}ka • Message 3A -> I(B) : M • At step one, the intruder intercepts the message {M}kawhich is supposed to be sent to the principal playing the role B. • At step two, the intruder sends the intercepted message to the principal playing the role A as a B’s response. • Finally, the principal playing the role A decrypts the received message and sends the result (M) to the principal playing the role B. • However, the intruder intercepts this message; hence, it learns the information that was supposed to be secret. Serguei A. Mokhov, mokhov@cs.concordia.ca

  14. Multi-Role Oracle Flaws • Multi-role oracle flaws occur when the protocol assumptions allow principals to change their role from one run to another. • In this case, an intruder has more chance to attack the protocol. • In fact, the intruder can participate in many runs executed concurrently; hence, messages of one run can be used to form messages that will be used in another run. Serguei A. Mokhov, mokhov@cs.concordia.ca

  15. Multi-Role Oracle Flaws (2) • A good example of multi-roles oracle flaws is: • Message 1A -> B : {Na}kab • Message 2B -> A : {Na+ 1}kab • The objective of this protocol is to convince the principal playing role A that the principal playing role B is operational. Serguei A. Mokhov, mokhov@cs.concordia.ca

  16. Multi-Role Oracle Flaws (3) • At step one, the principal playing role A sends a challenge, the nonce Naencrypted using the key kab. • The principal playing role B can easily give a response ({Na+1}kb) to this challenge at step two since it knows the key kab. • This protocol can be attacked as follows: • Message 1.1A -> I(B) : {Na}kab • Message 2.1I(B) -> A : {Na}kab • Message 2.2A -> I(B) : {Na+ 1}kab • Message 1.2I(B) -> A : {Na+ 1}kab • At step one of the first protocol run, the intruder intercepts the message {Na}kaband uses it as its own challenge in the first step of the second protocol run. Serguei A. Mokhov, mokhov@cs.concordia.ca

  17. Multi-Role Oracle Flaws (4) • Therefore, it is not surprising that the principal playing the role A will answer by sending the message {Na+ 1}kabin step two of the second protocol run. • Furthermore, this message is also the necessary one to finish the first run. • Finally, the principal playing the role A is convinced that the principal playing the role B is operational, however this principal may not exist any longer in the system. Serguei A. Mokhov, mokhov@cs.concordia.ca

  18. Type Flaws • The extraction of message components requires a full knowledge about their types. • In fact, a message is implemented in a concrete level as a sequence of bits, then to extract the value of the first component, for example, we need its type (length). • Such information can be implicit if the receiver has a previous knowledge about the message’s components, their types and their positions. • Another solution is to represent types explicitly in the transmitted data structure. • In this case, the receiver does not need to know previously the types since it will find them embedded within the received message. Serguei A. Mokhov, mokhov@cs.concordia.ca

  19. Type Flaws (2) • Type flaws occur when an adversary can induce the receiver to infer message component types which are different from their real one. • The Andrew Secure RPC (From Andrew File System) Protocol, presented below, provides a good example for this class of flaws. • Message 1A -> B : A, {Na}kab • Message 2B -> A : {Na+ 1,Nb}kab • Message 3A -> B : {Nb+ 1}kab • Message 4B -> A : {k’ab,N’b}kab Serguei A. Mokhov, mokhov@cs.concordia.ca

  20. Type Flaws (3) • In step one, the principal playing the role A sends its identity and a challenge {Na}kabto indicate to the principal playing the role B that it wishes to communicate with it. • At the second step, the principal playing the role B sends the message {Na+ 1,Nb}kabwhich is a challenge to the principal playing the role A. • At step three, the principal playing the role A replies to the challenge of the principal playing the role B by sending the message {Nb+ 1}kab. • At the last step, the principal playing the role B creates a session key k’ab, concatenates it with N’b, an identifier for a future communication, encrypts the result with the key kaband sends it to principal playing the role A. Serguei A. Mokhov, mokhov@cs.concordia.ca

  21. Type Flaws (4) • Suppose that nonces and keys have the same length (x bits). • This protocol can be attacked as follows: • an intruder I can intercept the message {Na+1,Nb}kabsent at the second step and send it in step four as B’s reply. • In this case, the principal playing the role A will consider the value of Na+ 1 as the value of the key kab. Serguei A. Mokhov, mokhov@cs.concordia.ca

  22. Type Flaws (5) • The complete attack is: • Message 1A -> B : A, {Na}kab • Message 2B -> A : {Na+ 1,Nb}kab • Message 3A -> B : {Nb+ 1}kab • Message 4I(B) -> A : {Na+ 1,Nb}kab Serguei A. Mokhov, mokhov@cs.concordia.ca

  23. Binding Flaws • In public key cryptography, it would be catastrophic if a principal misjudges the key of another. • In fact, a public key is used to send secret information, since only the principal having the appropriate private key can decrypt the encrypted message. • However, if, for example, an intruder I having a public key kican convince a principal A that B’s public key is ki, then the intruder can read all secret messages (encrypted by ki) coming from A and going to B. • To avoid such a flaw, a veritable binding between agents and public keys must be established. Serguei A. Mokhov, mokhov@cs.concordia.ca

  24. Binding Flaws (2) • In general, with a distributed systems, a trusted server takes in charge the key distribution task. • Each principal uses an authentication protocol to get public keys of other principals from the server. • However, if the authentication protocol is not carefully designed, binding flaws can take place. Serguei A. Mokhov, mokhov@cs.concordia.ca

  25. Binding Flaws (3) • A good illustrative example of this class of flaws is given hereafter: • Message 1 A -> S : A,B,Na • Message 2 S -> A : S, {S,A,Na, kb}ks-1 • Here, the principal playing the role A wishes to know the public key of the principal playing the role B with the help of the trusted server S. • At step one, the principal playing the role A sends its identity, the identity of the principal playing the role B and a nonce Nato the server S. • In step two, the server replies by a message containing its identity, A’s identity, the nonce Na(to ensure the freshness of the message) and the public key of the principal playing the role B. • All these components are concatenated and encrypted under S’s private key (signature) allowing the principal playing the role A to be sure about the origin of the message. Serguei A. Mokhov, mokhov@cs.concordia.ca

  26. Binding Flaws (4) • As shown by Hwang and Chen, this protocol can be attacked as follows: • Message 1.1 A -> I(S) : A,B,Na • Message 2.1 I(A) -> S : A, I,Na • Message 2.2 S -> I(A) : S, {S,A,Na, ki}ks-1 • Message 1.2 I(S) -> A : S, {S,A,Na, ki}ks-1 • At step one of the first protocol run, the intruder I intercepts the message “A,B,Na”, substitutes the identity of B by its identity and sends the result as the first message of a new run of the protocol (Message 2.1). • At step 2.2, the server replies by a message containing I’s public key, since it thinks that the principal playing the role A is asking for this public key. • Finally, the intruder replays S’s message to the principal playing the role A. Thus, a binding flaw occurs, since the principal playing the role A thinks that the public key of the principal playing the role B is ki. Serguei A. Mokhov, mokhov@cs.concordia.ca

  27. Binding Flaws (5) • To avoid this flaw, Hwang and Chen proposed the following modification: • Message 1 A -> S : A,B,Na • Message 2 S -> A : S, {S,A,Na,B, kb}ks-1 Serguei A. Mokhov, mokhov@cs.concordia.ca

  28. Repudiation Flaws • We say that a cryptographic protocol contains a repudiation flaw if at least one principal is able to deny its participation in any run of this protocol. • A popular example of this category of flaws was given by the coin-flip protocol proposed by Toussaint. • This protocol can be used by two principals to toss a coin over a “phone” as follows: • B sends his choice of Heads or Tails to A. • A • chooses a key ka. • sends the message {ka, Heads}ka, {ka, Tails}kato B. • B chooses arbitrary one of {ka, Heads}kaand {ka, Tails}kaand sends his choice, say X, to A. Serguei A. Mokhov, mokhov@cs.concordia.ca

  29. Repudiation Flaws (2) • A decrypts X, compares the result with B’s initial choice and sends the key kato B. • B decrypts X and compares the result with his initial choice. • The probability that the principal A wins is equal to B’s one (1/2) as is shown by Toussaint. • However, in this protocol, the result of the game is known by A before B. • Then, if the principal A discovers that he has lost, he can abort the protocol at step four and never reveal the key kato B at the last step. • In other terms, the principal A can deny his participation in this protocol run and a repudiation flaw occurs. Serguei A. Mokhov, mokhov@cs.concordia.ca

  30. Implementation-Dependent Flaws • Cryptosystems used within cryptographic protocols are supposed to be perfect, modulo a set of properties containing at least integrity and confidentiality. • However, some examples show that these conditions are not sufficient for some protocols, because their security can be severely affected by the implementation approach adopted for cryptographic functions. • The interaction between cryptosystems and cryptographic protocols did not have the chance to be deeply studied and it is still an open area of research. • However, it is clear that speaking about the security of a protocol combination with respect to a specific cryptosystem is better then speaking about the security of a protocol in absolute. Serguei A. Mokhov, mokhov@cs.concordia.ca

  31. Implementation-Dependent Flaws (2) • To be convinced by the severity of this problem let us see the example proposed by Massey as shown below: • Message 1 A -> B : {M}ka • Message 2 B -> A : {{M}ka}kb • Message 3 A -> B : {M}kb • Suppose that we use the XOR function to cipher messages. • Hence, if k is a key and M is a message, encrypting M under k turns to do the simple following operation: {M}k = M k. • Since k k = 0 (0 0 = 0 and 1 1 = 0 ), the deciphering transformation is performed by using the same operation: {{M}k}k = M k k = M. Serguei A. Mokhov, mokhov@cs.concordia.ca

  32. Implementation-Dependent Flaws (3) • The intent of this protocol is to transmit a secret message M from a principal playing the role A to a principal playing the role B. • However, if we compute the XOR of the three messages used in this protocol: • ({M}ka {{M}ka}kb {M}kb), • then the result is M (the message which is supposed to be secret). Serguei A. Mokhov, mokhov@cs.concordia.ca

  33. Other Flaws • Elementary Flaws: • Some cryptographic protocols provide only a marginal protection against an adversary. In general, this category of protocols is breakable with a little effort. • A little protection or a non-protection of a protocol leads in almost all the cases to so-called elementary flaws. • A simple example of these flaws can be given by the following protocol: • Message 1 A -> B : {Na, kab}ka-1 • Message 2 B -> A : {Na}kab Serguei A. Mokhov, mokhov@cs.concordia.ca

  34. Other Flaws (2) • Password Guessing Flaws: • Password guessing flaws occur if it is easy to an adversary to guess some secret key. • An intruder can do an exhaustive search in a word space smaller than the whole key space to look for keys that are not randomly selected. • This category of flaws is independent from the protocol design but it is related to cryptographic techniques used to generate keys. Serguei A. Mokhov, mokhov@cs.concordia.ca

  35. Other Flaws (3) • Calculi Flaws: • Normally, after receiving a message, the receiver does some verification in order to know if this received message is the good expected one or not. • However, if these computations are not completed or they are not correctly done, then a calculi flaw could arise. Serguei A. Mokhov, mokhov@cs.concordia.ca

  36. References • Dr. Mourad Debbabi • http://www.ciise.concordia.ca/~debbabi/inse7100.html Serguei A. Mokhov, mokhov@cs.concordia.ca

More Related