**Title**: Secure Function Evaluation vs. Deniability in OTR and similar protocols

.:: Secure Function Evaluation vs. Deniability in OTR and similar protocols ::.

Introduction | The Phrack Staff |

Phrack Prophile on FX | The Phrack Staff |

Phrack World News | TCLH |

Linenoise | various |

Loopback | The Phrack Staff |

Android Kernel Rootkit | dong-hoon you |

Happy Hacking | anonymous author |

Practical cracking of white-box implementations | sysk |

Single Process Parasite | Crossbower |

Pseudomonarchia jemallocum | argp & huku |

Infecting loadable kernel modules: kernel versions 2.6.x/3.0.x | styx^ |

The Art of Exploitation: MS IIS 7.5 Remote Heap Overflow | redpantz |

The Art of Exploitation: Exploiting VLC, a jemalloc case study | huku & argp |

Secure Function Evaluation vs. Deniability in OTR and similar protocols | greg |

Similarities for Fun and Profit | Pouik & G0rfi3ld |

Lines in the Sand: Which Side Are You On in the Hacker Class War | anonymous author |

Abusing Netlogon to steal an Active Directory's secrets | the p1ckp0ck3t |

25 Years of SummerCon | Shmeck |

International Scenes | various |

==Phrack Inc.== Volume 0x0e, Issue 0x44, Phile #0x0e of 0x13 |=-----------------------------------------------------------------------=| |=-----------=[ Secure Function Evaluation vs. Deniability ]=------------=| |=------------------=[ in OTR and similar protocols ]=-------------------=| |=-----------------------------------------------------------------------=| |=-----------------------=[ greg <greg@so36.net> ]=----------------------=| |=-----------------------------------------------------------------------=| --[ Contents 1 - Introduction 1.1 - Prelude 2 - Preliminaries 2.1 - Diffie-Hellman 2.2 - RSA 2.3 - Oblivious Transfer 2.4 - Secure Function Evaluation 3 - OTR 4 - The Attack 4.1 - Sharing Diffie-Hellman Keys 4.2 - Generating MAC and Encryption Keys 4.3 - Sending and Receiving Messages 4.4 - The Final Protocol 4.5 - What's Left 5 - References 6 - Greetingz --[ 1 - Introduction Recent cryptographic primitives and protocols offer a wide range of features besides confidentiality and integrity. There are many protocols that have more advanced properties, such as forward secrecy, deniability or anonymity. In this article, we're going to have a deeper look at deniability in communication (e.g. messaging) protocols. One protocol that claims to offer deniability is OTR. Although our construction can probably be extended in a quite general way, we'll stick with OTR as an example protocol. Our goal is to show the limits of deniability, especially in protocols that offer message integrity features (as OTR does). We will do this by constructing a protocol that enables each partner in a conversation to cooperate with an observing party, such that he can prove the authenticity of any message that was part of the conversation to the observing party. ------[ 1.1 - Prelude It was one of these days sitting together with bruhns and discussing stuff (TM). Out of the sudden, he came up with the question: "You know, I'm asking myself what a trusted timestamping service could be good for...?". I told him "timestamps, most probably". He was like "Uhm, yes. And wouldn't that affect the deniability of OTR somehow?". We discussed the matter for quite a while and we finally agreed that a trusted timestamping service itself wouldn't be enough to destroy the deniability of OTR. But our interest remained... --[ 2 - Preliminaries In this section, we're going to give a quick overview of cryptographic primitives we're gonna use. If you're already familiar with those, you can happily skip our explanations and get to the real meat. The explanations in this section will not contain all the mathematical background (i.e. proofs ;) ), which is necessary to really *understand* what's going on. We'd rather like to provide a high-level overview of how all the individual components and how they can be combined. ------[ 2.1 - Symmetric Operations We'll keep this real short; you probably know the most common symmetric crypto algorithms. We will be using symmetric block ciphers (such as AES) and hash functions (SHA for instance). Also, we will need MAC functions in the following sections. You might already know HMAC, which is a MAC scheme based on hash functions. MACs (Message Authentication Codes) are used to protect the integrity of messages. Being a symmetric primitive, creating and verifying the MAC requires knowledge of the same key. If someone can verify a MAC, they can also create one. ------[ 2.1 - Diffie-Hellman The Diffie-Hellman scheme is one of the most widely used key establishment protocols today. The basic idea is the following: Alice and Bob want to securely establish a key over an insecure channel. Diffie-Hellman enables them to do this. During such a key-exchange both parties publicly send some values and after the communication is finished, both can compute a common key, which can *not* be computed by anyone who wiretaps the communication. --------[ 2.1.1 The Math behind it Alice and Bob agree on a prime p and some "generator" g. We won't discuss too many details of the mathematical background here (if you're interested in math, refer to [1]), so it's sufficient to say that in practice, g will often have the value 2 and the prime p will be large. In many cases, p and g are fixed parameters, on which both parties rely. Before describing the actual protocol, we want to show one interesting observation: Given some number x, it's trivial to compute values y = g^x mod p ("square and multiply" are the magic words). Given the value y however, it's not trivial at all to compute the value of x ("discrete logarithm problem", if you're interested). This property can be used to build a key-establishment scheme like this: A --------------- a = g^x mod p --------------> B A <-------------- b = g^y mod p --------------- B A picks a random x, computes a = g^x mod p and sends that value over to B. B picks a random y, computes b = g^y mod p and sends that value over to A. The values a and b are also referred to as Diffie-Hellman public keys. A now performs the following computation: (2.1.1) ka = b^x mod p B does the same and computes (2.1.2) kb = a^y mod p We can observe that due to the equation (2.1.3) ka = b^x mod p = (g^y)^x = g^(yx) = g^(xy) = (g^x)^y = a^y = kb ka and kb are equal. So A and B have established a common key k (k = ka = kb). As an attacker however neither knows x nor y, he cannot perform the same computation. The attacker could try to obtain x from a, but as we outlined above, this is (hopefully) computationally infeasible for large primes p and good generators g. In case of an active attacker, this scheme can be broken by a simple man-in-the-middle attack, where the attacker replaces Alice's and Bob's values by his own ones and then proxies the traffic between both parties. This problem can be fixed by making use of an authentication scheme: Alice and Bob need to "sign" the values that they transfer, so that the attacker cannot modify them without destroying the signature. There are many signature schemes out there (for instance based on RSA, which is described below) and all of them come with additional costs (you need to exchange public keys beforehand etc.). We assume you know about all the higher-level problems, such as key distribution, revocations, trust-models, etc. The basic principle of Diffie-Hellman however stays the same - and that is what we're going to focus on later in this article. ------[ 2.2 - RSA Another gem of modern cryptography is the RSA crypto system. RSA is also based on modular arithmetic, but it works in a different way than Diffie-Hellman. Alice wants Bob to send her an encrypted message. However, Alice and Bob have not exchanged any key material (if they had, Bob could just make use of any block-cipher like AES to send encrypted data to Alice). With RSA, Alice can send Bob a thing called her "public key". This public key can be used by Bob to encrypt messages. However, nobody can decrypt messages encrypted with Alice's public key without knowing another piece of information called Alice's "secret key". As the name suggests, Alice keeps her secret key secret. Therefore everybody can encrypt messages for Alice, but nobody besides Alice can decrypt these messages. --------[ 2.2.1 More Math Alice wants to receive messages from Bob, so she first needs to generate an RSA key-pair. Alice does the following: She picks two primes p and q and computes (2.2.1) N = p * q She picks a value e (in practice, e = 65537 is a common choice) and computes (2.2.2) d = e^-1 mod (p-1)(q-1) (i.e. e*d = 1 mod (p-1)(q-1)) This computation can be performed efficiently using the extended euclidean algorithm (but again, we won't dive into all the mathematical details too much). Alice keeps all the values besides N and e secret. A ---------------- N = p * q, e --------------> B A <--------------- c = m^e mod N --------------- B Alice now sends over N and e to Bob. Bob uses N and e to encrypt his message m as follows: (2.2.3) c = m^e mod N Then, Bob sends the ciphertext c over to Alice. Alice can use d to decrypt the ciphertext: (2.2.4) m = c^d mod N This works due to the way e and d are chosen in equation (2.2.2). To decrypt the ciphertext, an attacker could of course try to compute d. But computing d is hard without knowing p and q. And obtaining p and q from N is assumed to be an infeasible problem for large values of N. The tuple (N, e) is commonly called an RSA public key, whereas (N, d) is called private key. We can view an RSA instance (with fixed keys) as a set of two functions, f and f^-1, where f is the function that encrypts data using the public key and f^-1 is the function that decrypts data using the private key. We'll call such functions one-way functions. Instead of encrypting data with the receiver's public key, we can also use RSA as a signature scheme. The signer of a message first uses a hash function on his message. He then encrypts the hash value with his private key. This signature can be verified using the signer's public key: the verifier uses the public key to decrypt the hash value, computes the hash of the message he received and then compares the hashes. An attacker will not be able to produce such a signature, because he doesn't know the signer's private key. Please be aware that (like all the other algorithms described in this document), RSA should in practice not be used as described above. In particular, we did not describe how to correctly convert messages into numbers (RSA operates on natural numbers, remember?) and how to securely pad plaintexts. Depending on the respective security goals, there are a number of possible padding schemes (such as OAEP+), but we're not going to describe them here in detail. ------[ 2.3 - Oblivious Transfer Oblivious transfer is a real funny primitive. Suppose, Bob knows two values x0 and x1. Alice wants to obtain one of those values, but she doesn't want to tell Bob which value she wants. Now Bob could of course tell Alice both values (that way he wouldn't know, which one Alice was interested in). However, Bob wants to make some money and so he takes $1k per value. Poor Alice however only has $1k, so she can't afford to buy both values from Bob. This problem can be solved with an oblivious transfer. An oblivious transfer is a cryptographic protocol, so it requires a number of messages to be exchanged between Alice and Bob. After the messages are exchanged, Alice will receive the value she wanted and Bob won't know which value that was. --------[ 2.3.1 Math Voodoo There are a number of protocols for performing an oblivious transfer, based on different cryptographic assumptions. We are going to describe one classical example here, which can be implemented using a public-key cryptosystem (such as RSA). More details of this construction can be found in [7]. The system works like this: Bob picks one-way functions f, f^-1 and sends f over to Alice. Along with f, he sends two random values r0 and r1. You can think of f and f^-1 as RSA functions using fixed keys (as described above). A <---------------- f, r0, r1 -------------- B A ------------- z = f(k) XOR rb -----------> B Alice wants to receive value xb (b = 0 or 1) from Bob. She picks a random k, computes f(k) and XORs it with r0 if she wants to receive x0 or with r1 if she wants to receive x1. The XOR operation is sometimes also called "blinding". Depending on the cryptosystem that is used to obtain f and f^-1, there might be more appropriate choices then just using XOR. For RSA, it would be natural to use integer addition and subtraction (modulo N) instead of the XOR operation. Alice now sends the result z to Bob. Bob performs some computations: (2.3.1) k0 = f^-1(z XOR r0) (2.3.1) k1 = f^-1(z XOR r1) One of the k values will be Alice's, but Bob doesn't know which one. The other value will be junk, but it's important to note that this junk value cannot be computed by Alice (she doesn't know f^-1). Now Bob simply does the following: A <---------- x0 XOR k0, x1 XOR k1 --------- B Depending on which k value is the one that Alice actually knows, she can decrypt x0 or x1. And that's it: Alice now knows the value she wanted to receive and one junk value, which doesn't tell her anything. Bob however doesn't know which of the k values was the one that Alice picked, so he he cannot tell, which value Alice wanted to receive. Let's try it out: Say Bob hast two values x0 = 7 and x1 = 1. He is willing to share one with Alice. First he generates f and f^-1. To do that, he just uses RSA. He picks two prime numbers p = 5 and q = 11 and gets N = 55. Also, he picks e = 3 as encryption exponent (don't do that at home, kids!). The decryption exponent would then be d = 27 (you can compute that using the euclidean algorithm or alternatively you could just believe us). Bob now can send out (N, e) = (55, 3) to Alice, along with some random values (r0, r1) = (4, 9). Suppose Alice wants to retrieve the value of x1. First of all, she picks a random k, let's say k = 6. She encrypts it using the public key Bob sent (i.e. she applies Bob's one-way function): f(6) = 6^3 mod 55 = 51. She computes z = f(k) + r1 = 51 + 9 mod 55 = 5, which she sends to Bob. Bob now determines his candidates for k (i.e. k0 and k1) by computing: k0 = f^-1(z - r0) = (5 - 4)^27 mod 55 = 1 k1 = f^-1(z - r1) = (5 - 9)^27 mod 55 = 6 <-- Alice's k, but Bob doesn't know that Bob then sends to Alice: x0 + k0 = 7 + 1 and x1 + k1 = 1 + 6. Alice receives the two values 8 and 7. She knows that Bob's second value was x1 + k. As she is interested in x1, she takes that value and computes x1 = (x1 + k1) - k = 7 - 6 = 1 (observe that k = k1, which only Alice knows). Now Alice could try to cheat and to also obtain x0. But to do that, she would need to know the value that Bob computed for k0, which she won't be able to compute without knowing f^-1 (i.e. the secret exponent d in our case). ------[ 2.4 - Secure Function Evaluation Secure function evaluation is another real gem of modern cryptography. A classical example is the 0day problem. Two hackers A and B have a certain number of 0day exploits each. They want to determine who is more elite, but they are so paranoid that they don't even want the other to know how many 0days they have. So, A knows some number x, B knows y and both want to compute the function f(x, y) = { 1 if x > y, -1 if y > x and 0 otherwise}. Secure Function Evaluation solves this problem. Again, both parties exchange a number of messages and after this is done, both of them know the result of the function without having learned anything about the input of the other party. And instead of the function shown above, they could just arbitrarily agree on any function to be evaluated. One interesting practical application of SFE is to perform mutual authentication based on a shared secret. Two parties knowing a shared secret can jointly compute the function f(x, y) = {1 if x = y, 0 otherwise}. Interestingly, the OTR protocol makes use of such a SFE scheme for authentication. --------[ 2.4.1 More Voodoo Suppose there is a function f(x, y), which two parties want to compute (this is actually secure two-party computation, which is not the most general case - for our purpose however it is sufficient). Both want to share the result and both want to keep their own inputs safe. There are several constructions that allow us to perform SFE. We'll discuss only one of them here: Yao's garbled circuits [3]. As the name suggests, the function to be evaluated by both parties first has to be transformed to a boolean circuit. For many functions, this is generally not a problem. The next step is to "garble" the circuit. The main idea behind this garbling process is that we want everyone to be able to evaluate the circuit, while nobody should see what he actually evaluates. Therefore, we will try to hide all the bits that "flow" through the circuit. For hiding the bits, we could make use of a block cipher. However, we have to take care that the circuit can still be evaluated! Therefore, we will also have to modify all the gates in the circuit somehow, so that they are able to work with "garbled" inputs. Now one could imagine that such a modification is a hard task. Fortunately, there's a simple trick: All the gates in our circuit are very small boolean functions (by small we mean that they don't have many inputs). We can therefore replace every gate by its truth table. The truth table simply maps the input bits to the respective output bits. For a simple NAND gate, the truth table would look like this: \a| b\| 1 0 --+---- 1 | 0 1 0 | 1 1 Now that we have replaced every gate by its truth table, we will just have to modify the truth tables, so that they reflect the fact that all the bit values are garbled. The trick here is the following: Instead of the real values of the input bits (1 or 0), we pick random cryptographic keys (say 128 bits long). We will then use those keys to encrypt the values in the truth table. Instead of the input values for the gate, we will then use the random keys (i.e. instead of 1 or 0, we just pick two random bitstrings per wire). As an example, consider a NAND gate again. We choose four keys ka0, ka1, kb0 and kb1. Those are the keys for the respective input values of the gate (i.e. a=0, a=1, b=0, b=1). Also, we pick an encryption function E and a decryption function D. For simplicity, we assume that if a wrong key is supplied to D, it will signal this (e.g. return an error code) instead of providing a junk plaintext. We now perform the following transformation on the truth table of our gate: \a| \ a| b\| 1 0 b \ | 1 0 --+----- -----> ---------+-------------------------------- 1 | 0 1 1 | E_ka1(E_kb1(0)) E_ka0(E_kb1(1)) 0 | 1 1 0 | E_ka1(E_kb0(1)) E_ka0(E_kb0(1)) The elements in the truth table are double encrypted using the two keys that belong to the values of a or b, respectively. When evaluating the circuit, you only know the keys that correspond to the correct input values (so for example you know ka0 and kb1 but no other key). By simply trying to decrypt every value in the table, it is easy to find the according output value (only one decryption will succeed). The next question would then be: How to garble a whole circuit? It's not much different. Assume that two gates are connected like this: Out | +------+ | G1 | +------+ | | +---+ In_3 |G2 | +---+ | \ In_1 In_2 We have inputs In_1, In_2, In_3 and one output value Out. G2's output is connected to one of the input wires of G1. In the truth table of G2, we therefore put the *key* that corresponds to the respective input value of G1 (so instead of double-encrypting G2's output value 1 or 0, we double-encrypt the respective key for one of G1's input pins). The gate G1 can be garbled as described above. The keys for the input wires In_1, In_2 and In_3 are assumed to be already known by the party evaluating the circuit. G2 can now easily be evaluated and yields the missing key for evaluating the gate G1. However, during the evaluation of the circuit, no intermediate values (like the real output of G2) are disclosed to the evaluating party. Let's try that in practice: Say Alice and Bob want to evaluate a function. The following protocol can be used: A prepares a garbled circuit and hard-codes her input values into the circuit. She sends the result to B. B now needs to retrieve the keys for his input values from A. But beware of two limitations here: 1) B doesn't want to disclose his input values to A (obviously). 2) A doesn't want to tell B the keys for both input values, because then B would be able to reverse-engineer the circuit and to obtain A's input values. You've probably already seen the solution: B uses an oblivious transfer to obtain the keys for his input values from A. For every bit b of his input values, Bob will obliviously obtain the correct key k_b0 or k_b1 like this: A ---------------- f, r0, r1 --------------> B A <------------- z = f(k) XOR rb ----------- B A -------- k_b0 XOR k0, k_b1 XOR k1 -------> B B is now able to evaluate the whole circuit. Depending on how A built the circuit, the output truth tables could contain real or garbled values. Using some simple tricks, we can even split the output between A and B (so that A gets some part of the result and B gets another part). We'll detail on that later. Now there are some problems when one party isn't honest. Alice for instance could just prepare a malicious circuit that leaks information about Bob's secret inputs. There are ways to prevent such attacks ("cut and choose", zero knowledge proofs, etc), but we won't provide the details here. A more detailed description (along with a security proof) can be found in [3]. --[ 3 - OTR For those who are not familiar with the OTR protocol, this section might provide some help. OTR features a number of cryptographic properties, including confidentiality, integrity, forward secrecy and deniability. There are two major phases of the protocol: initial key exchange and message exchange. The initial key exchange is based on the Diffie-Hellman protocol. It is referred to as AKE (Authenticated Key Exchange). To defend against active attackers, a public-key signature scheme (DSA in this particular case) is used. The DSA master keys have to be exchanged beforehand (OTR also offers to authenticate DSA keys using the SMP protocol, but that's not interesting in our case). All the cryptographic details are provided in [2]; it's not particularly helpful to repeat them here. Keeping in mind that OTR's key exchange is based on Diffie-Hellman combined with some symmetric crypto and a signature scheme will suffice. After the key-exchange phase, each party will have a number of symmetric keys for encryption and authentication. Those are derived from the Diffie-Hellman master key by hashing it in various ways (encryption and MAC key will obviously be different). The messages are encrypted using AES in CTR mode, and each message is MACed using the symmetric key material. That offers us confidentiality and integrity. It's important to note that *only* symmetric keys are used for the actual payload crypto. The DSA master keys are only used in the initial key-exchange phase. The next feature we're going to look at is forward secrecy. Forward secrecy means that even if the (DSA) key of a participant is disclosed, past conversations cannot be compromised. Forward secrecy in OTR is established by the Diffie-Hellman protocol: after a conversation ends, both parties can safely wipe the Diffie-Hellman key that they generated. There is no way for an attacker (and not even for the conversation partners) to re-compute that key afterwards: to do that, one would either need to know the private exponent of one party (which is of course also wiped from memory) or one would need to derive the key from the public information exchanged between both parties, which is infeasible (hopefully; that's what Diffie-Hellman relies on in the first place). Having understood how OTR provides forward secrecy, we can move on to deniability. During the conversation, both parties can be sure that the messages they receive are authentic and not modified by an attacker. It is immediately clear that the message authenticity can not be verified without the MAC key. If one of the conversation partners wants to convince a third party that a message is authentic, this conversation partner implicitly proofs his knowledge of the MAC key to the third party. But then again, the third party can not be sure that the conversation partner didn't fake the message (he can do this as he knows the MAC key). This is what we call weak deniability [4]. Obviously, OTR offers weak deniability, as message authentication is performed using only symmetric primitives. But OTR offers even more: In every message, the sending party includes a new Diffie-Hellman key exchange proposal. The proposal is also covered by the MAC to rule out MITM attacks. So both parties frequently generate new key material. And this lets us do a nice trick: as soon as they generate new MAC keys they publicly disclose the old MAC keys. The old keys aren't used anymore, so this is safe. But as the MAC keys are public, *everybody* could create fake messages and compute proper MACs for those. This is what we call strong deniability. OTR ships with a toolkit containing software for actually forging messages. Depending on how much you already know (only the MAC keys, MAC and encryption keys, MAC keys and some message plaintext), you can use different tools to forge messages. If you know parts of the plaintext and the MAC keys, you can exploit the fact that AES is used in CTR mode to directly modify the known parts of the plaintext. If there is no known plaintext, the otr_remac tool might helpful: Every message contains a new Diffie-Hellman key exchange proposal in plaintext (but covered by the MAC). Now you can simply replace that proposal by one that you generated (e.g. using the otr_sesskeys tool) and compute a new MAC for the packet. That allows you to easily fake the rest of the conversation: You know your own private Diffie-Hellman key, so you can generate a plausible set of MAC and encryption keys and just use that one. It will look legitimate because the modified packet (containing your key exchange data) still has a valid MAC. --[ 4 - The Attack The deniability of OTR stems from the fact that a third party does not know whether a message has been sent during a conversation (and before the MAC keys were disclosed) or was generated afterwards (when the MAC keys were public). An obvious way to attack OTR's deniability would therefore be to just monitor all the OTR traffic between A and B. If one party now decides to disclose the MAC and encryption keys used for a particular message, the authenticity of that message can be verified. And as the message has been recorded during the conversation (i.e. before the MAC keys were public), the recording party knows that it was not generated afterwards. Let's look at a real-life example to shed some more light on what we're doing. Imagine two hackers A and B who want to talk about serious stuff (TM) using OTR. Both of them are slightly paranoid and don't trust each other. In particular, Bob fears that Alice might backstab him. However, as OTR is deniable, Bob assumes that even if Alice discloses the contents of their conversation, he could still plausibly argue that Alice just made it up to discredit him. So Bob ignores his paranoia and tells Alice his secrets. Alice indeed plans to backstab Bob. Her first plan is simple: She will just submit all the encrypted and authenticated messages to the police. The police will later be able to state in court that Alice didn't fake the messages after the conversation. She however quickly realizes that this approach is inherently flawed: Bob could argue that Alice just sent fake messages to the police (as Alice knows all the keys she could generate such fake messages). Alice knows that this problem could be fixed if the Police sniffed all the traffic themselves. But she also knows that this is going to be difficult, so she comes up with a second idea: Why not use a trusted third party? Instead of submitting her messages to the police, she will just disclose her private DSA key to her lawyer. Then, during her conversation with Bob, she will use her lawyer as a proxy (i.e. she will let *him* do the crypto). This way the lawyer can be sure that the conversation is authentic. The judges will trust Alice's lawyer in court (at least they'll trust him more than they trust Alice), so her problem is solved. Alice's setup would look like this: +-------+ | Alice | +-------+ ^ | Non-OTR (maybe SSL) v +------------+ | Lawyer | trust +----------------+ | Speaks for | <---------> | Police / Court | | Alice | +----------------+ +------------+ ^ | OTR (Bob thinks he talks to Alice) v +-------+ | Bob | +-------+ But now Alice realizes that she doesn't trust her lawyer enough to give him her private DSA key: He could misuse it to impersonate her. Also, Alice doubts that her lawyer's words would be trusted enough in court. This example shows the problems that Alice has when she wants to break the deniability of OTR. Her problems can be summarized as follows (we'll now call the police the "observing party" and the lawyer will be called "trusted third party"): a) The observing party needs to sniff the network traffic. That implies quite a privileged network position, as the traffic needs to be sniffed passively, i.e. without the help of A or B. Because if A or B would send their traffic to the observing party, A or B might just insert bogus messages into their "sniff" stream and the observing party couldn't be sure about the authenticity. Even worse, paranoid A and B could use an anonymizing network, so that sniffing their traffic would be a non-trivial task. b) Also, the authenticity of a message can only be proven to the observing party, but not to anybody else (as anybody else didn't sniff the traffic and the observing party could just have cut some pieces or inserted new ones). Problem b) is not that much of importance. Just imagine the observing party as the police, the judges or even Fnord. You should always assume that the observing party is exactly the guys you wanna protect yourself against. If you think that the police probably won't even get all the crypto stuff and therefore just believe any plaintext logfile you show them, that's OK (you're probably right). There might however be agencies that would not really trust plaintext logs. And those agencies might be very interested in the contents of some OTR conversations. Problem a) remains open. Obviously, neither A nor B really trust the observing party. If we had a trusted third party, we actually could mount an attack against OTR's deniability, just as described in the lawyer example above. Well, lucky us, neither A, nor B, nor the observing party trust anybody and therefore, there will be no trusted third party ;) Really? Interestingly, a trusted third party can be emulated using secure function evaluation. This is what we didn't tell in the section above: You can view a secure function evaluation scheme as a replacement for a trusted third party. So instead of letting a third party compute some function f(x, y), A and B can perform the computation on their own and still get the same result: both players only receive f(x, y) but A doesn't see y and B doesn't see x. So the main idea of our attack is: Emulate a trusted third party using secure function evaluation. The setup that Alice now plans is the following: +-------+ | Alice |<-----------+ +-------+ | ^ | | | SFE Voodoo for emulating the lawyer | | | v | +----------------+ | | Police / Court | | +----------------+ | | OTR | v +-------+ | Bob | +-------+ Our central idea is the following: A can send all the messages she received from B to the observing party (the police in the figure above, but that could really be everyone). The messages are still encrypted, so this is not a problem. To make sure that the messages are not faked by A, we need to make sure that A cannot produce valid MACs without the help of the observing party. We therefore share the MAC key between A and the observing party. Every time, A wants to validate or produce a MAC, she has to cooperate with the observing party. Later on, A can reveal the encryption key for any message to the observing party, which can be sure that the message is authentic. In the following section (4.1 - 4.3), we will provide a high-level overview of the attack. In section 4.4, you can find the actual protocol that Alice and the observing party use. ------[ 4.1 - Sharing Diffie-Hellman Keys OTR uses Diffie-Hellman to establish sort-lived MAC and encryption keys. The first part of our exercise is therefore to build a Diffie-Hellman compatible 3-party protocol that allows for sharing the generated key between two parties. The following protocol between Alice (A), Bob (B) and the observing party (O) works: O ----- g^o ----> A ---- (g^o)^a ----> B O <---- g^a ---- A A <--- g^b ---- B All computations are done modulo some prime p and g is a generator of a sufficiently large subgroup of Z_p*, just as Diffie-Hellman mandates. B will now compute g^oab as key. However, neither A nor O can reproduce that key. If A wanted to compute it, she would need to know O's secret exponent o. Similar for O. We can therefore say that the key k is shared between O and A, in the sense that A and O need to cooperate in order to actually use it. ------[ 4.2 - Generating MAC and Encryption Keys Now that we have established a shared Diffie-Hellman key, we need to securely derive the MAC and encryption keys from it. Let's assume we have a circuit C, which takes the shared Diffie-Hellman key k as input and returns the corresponding MAC and encryption keys as output. This circuit follows immediately from the OTR specification. Before we can evaluate the circuit, we first need to compute k (which neither A nor O know at this time). So the overall function that A and O want to compute is: f(a, o) = C(((g^b)^a)^o mod p) We can transform this function to a new circuit and evaluate it together (i.e. A and O evaluate the circuit). After the evaluation, A could get the encryption keys. But that's not a good idea, because the OTR spec mandates that MAC_key = hash(encryption_key). If A knew the encryption key, she could compute the according MAC key. Also, it would be bad if O would get the MAC keys, because then O could impersonate A and B. Therefore, we'll slightly modify the circuit, so that A may pick a random bit string, which the circuit XORs to the MAC key and to the encryption key (assuming the random string is long enough for both keys). The "blinded" MAC and encryption keys are then provided to A and O, the bitmask remains in A's memory. If they want to use one of the keys for something, they will evaluate a circuit that first XORs both halves together and then does the actual computation using the key. At no point in time, A or O actually learn the MAC or the encryption key. Now that we know how to generate all the symmetric key material, we are able to perform the full initial key exchange phase of OTR. ------[ 4.3 - Sending and Receiving Messages When A receives a message from B, she cannot immediately decrypt it because she doesn't know the decryption key. Also, verifying and sending messages needs O's cooperation. 1) Message Decryption If A wants to decrypt one of B's messages, she cooperates with O. Both parties will jointly evaluate a decryption circuit. The circuit will be built in such a way that only Alice will learn the result (i.e. Alice will again provide a random bitstring as input the the circuit, which is XORed to the result). 2) Message Verification If A wants to verify one of B's messages, she has to cooperate with O. A and O will jointly evaluate some sort of HMAC circuit, in order to find out whether a message is authentic or not. We can design the message verification function in such a way that O will immediately learn the encrypted message and the MAC verification result. This enables A to afterwards reveal the encryption key for a particular message, so that O will be convinced A didn't fake it. 3) Message Creation When A wants to create a message, she encrypts it together with O, just as described in 1). In order to compute a MAC for the message, A and O again cooperate. As each message has to contain a new Diffie-Hellman public key, A and O will jointly compute such a key using the scheme outlined above. ------[ 4.4 - The Final Protocol In this section we'll describe our final protocol. It offers the following features: * We have three parties: A, B and O. A and O cooperate to backstab B. B is not able to deny any of his messages towards O. * O will not learn any message plaintext, unless A explicitly tells O the respective keys. * O is not able to impersonate neither A nor B. * No trust relation between A and O is required. * A does not have to disclose a whole conversation to O; it is possible to only disclose selected messages. * B does not notice that A and O cooperate. ---------[ 4.4.1 - Initial Key-Exchange This section describes OTR's authenticated key-exchange (AKE). Bob starts the key exchange by picking a random r and x and sending AES_r(g^x), HASH(g^x) to Alice. That's the regular OTR protocol. Alice then does a Diffie-Hellman key-exchange with O as outlined in section 4.1. We assume that A and O communicate over a secure channel. O A <-------- AES_r(g^x), HASH(g^x) ----- B O <------- g^a ------------- A O -------- g^o ------------> A Now Alice sends her Diffie-Hellman public key to Bob. Note that she doesn't know the private exponent of the key: she knows only a and g^ao, but neither ao nor o. A ------------------ g^ao ------------> B Bob has already computed the common key k (which Alice can't do) and uses it to derive encryption keys c and c' and MAC keys m1, m1', m2, m2' (see the OTR specs [2] for details) by hashing k in various ways. Bob builds the following messages: M_B = MAC_m1(g^x, g^ao, pub_B, keyid_B) X_B = pub_B, keyid_B, sig_B(M_B) Where pub_B is Bob's public DSA key and keyid_B is an identifier for Bob's Diffie-Hellman proposal g^x. sig_B is created using Bob's DSA key. Using the already derived symmetric keys, he sends AES_c(X_B),MAC_m2(AES_c(X_B)) over to Alice. A <- r, AES_c(X_B),MAC_m2(AES_c(X_B)) - B Alice is now supposed to also derive all the symmetric keys and to use them to decrypt and verify the stuff that Bob sent. But Alice cannot do that, so she cooperates with O. O sends her a garbled circuit C1, which will compute C1(o, a, mask) = (c, c') XOR mask Alice randomly chooses mask, so only she will learn c and c'. In a number of oblivious transfers, Alice receives the keys for her input values from O. O --------- C1 ------------> A\ \ O -------- <OT> -----------> A \ O <------- <OT> ------------ A | O -------- <OT> -----------> A | Compute c, c' using SFE. Only A . | receives the values. . | . / O <----- eval(C1) ---------- A / O --- (c,c') XOR mask -----> A/ Now Alice is finally able to decrypt the stuff that Bob sent her. She does so and gets X_B. Currently, she is not able to verify the MAC_m2() value Bob sent - she'll do that later. First she sends sig_B(M_B) over to O. O <------- sig_B(M_B) ------ A In order to actually verify sig_B(M_B), A and O first need to compute M_B. As described above, M_B = MAC_m1(g^x, g^ao, pub_B, keyid_B). In order to compute that MAC, both parties again need to cooperate. O creates a circuit C2, which computes: C2(o, a, pub_B, keyid_B) = MAC_m1(g^x, g^ao, pub_B, keyid_B) Alice again uses oblivious transfers to obtain the keys for her secret input value a, evaluates the circuit and both parties obtain the result M_B. O --------- C2 --------------> A\ \ O -------- <OT> -------------> A \ O <------- <OT> -------------- A | O -------- <OT> -------------> A | Compute M_B using SFE. A and O . | receive the value. . | . / O <----- eval(C2) ------------ A / O -------- M_B --------------> A/ Now that both have computed M_B, they first check the signature sig_B(M_B), just as the OTR protocol mandates. If A and O are convinced that sig_B(M_B) is OK, they can verify the MAC_m2(...) that B sent earlier. Again, they perform some SFE voodoo to do that. The observing party prepares a circuit C3, which computes: C3(o, a, AES_c(X_B)) = MAC_m2'(AES_c(X_B)) A again uses oblivious transfers to obtain the keys for her input values and the result is shared between both parties. O --------- C3 --------------> A\ \ O -------- <OT> -------------> A \ O <------- <OT> -------------- A | O -------- <OT> -------------> A | Compute MAC_m2'(AES_c(X_B)) using . | SFE. Both receive the result. . | . / O <----- eval(C3) ------------ A / O --------- MAC -------------> A/ Now A and O are convinced that the key exchange with B succeeded. But they still need to convince B that everything is OK. In particular, OTR mandates that A should compute M_A = MAC_m1'(g^ao, g^x, pub_A, keyid_A) X_A = pub_A, keyid_A, sig_A(M_A) and then send AES_c'(X_A), MAC_m2'(AES_c'(X_A)) over to B. Computing the AES part can be done by A, because A knows the key c'. But for computing the MAC, A and O again need to cooperate. First, A sends AES_c'(X_A) over to O. Then O prepares a circuit C4, which computes: C4(o, a, AES_c'(X_A)) = MAC_m2'(AES_c'(X_A)) Using oblivious transfers, Alice obtains the keys for her inputs from O. After evaluating the circuit, A and O obtain MAC_m2'(AES_c'(X_A)). O <----- AES_c'(X_A) -------- A\ O --------- C4 --------------> A \ \ O -------- <OT> -------------> A | O <------- <OT> -------------- A | Compute MAC_m2'(AES_c'(X_A)). Both O -------- <OT> -------------> A | parties receive the value. . | . / O <----- eval(C4) ------------ A / O -- MAC_m2'(AES_c'(X_A)) ---> A/ That's it. A can now send all the required values to B. - AES_c'(X_A), MAC_m2'(AES_c'(X_A)) -> B B verifies all the stuff (just like A did but without the SFE) and the key exchange is done. ---------[ 4.4.2 - Message Exchange Once they have exchanged their initial key material, Alice and Bob can exchange actual messages. Suppose, Alice wants to send a message to Bob; we'll restrict ourselves to that scenario. Receiving messages works similar. Alice now does the following (from the OTR protocol spec [2]): Picks the most recent of her own Diffie-Hellman encryption keys that Bob has acknowledged receiving (by using it in a Data Message, or failing that, in the AKE). Let key_A be that key, and let keyid_A be its serial number. If the above key is Alice's most recent key, she generates a new Diffie-Hellman key (next_dh), to get the serial number keyid_A+1. To do this, Alice again needs to cooperate with the observing party. The steps are exactly the same as we have already seen in the initial key-exchange: O <------- g^a -------------- A O -------- g^o -------------> A Alice now uses g^ao as next_dh. When she computed next_dh, Alice picks the most recent of Bob's Diffie-Hellman encryption keys that she has received from him (either in a Data Message or in the AKE). Let key_B be that key, and let keyid_B be its serial number. Now Alice would actually need to use Diffie-Hellman to compute a fresh shared key with Bob, which she can use to derive the encryption and MAC key. But as she doesn't really know the private exponent (she knows g^ao, a and g^a, but not ao), she again needs to cooperate with O. So here we go: O prepares a circuit C1: C1(o, a, mask) = (ek, mk) XOR mask The circuit will compute both, ek and mk (the encryption and MAC keys), blinded with some value chosen by Alice. The result will be supplied only to the observing party. Alice will keep the value of mask. In a number of oblivious transfers, Alice receives the keys for her input values from O. O --------- C1 ------------> A\ \ O -------- <OT> -----------> A \ O <------- <OT> ------------ A | O -------- <OT> -----------> A | Compute (ek, mk) XOR mask using SFE. . | Only O receives the result. . | . / O <----- eval(C1) ---------- A / Alice now picks a value ctr, so that (key_A, key_B, ctr) is unique. The ctr value is needed, because AES is going to be used in counter mode to encrypt Alice's payload. The next step for Alice is to encrypt her message. As she doesn't know the encryption key, O prepares a circuit C2 for her: C2(ek_o, ek_a, ctr, msg) = AES-CTR_ek,ctr(msg) The inputs ek_o and ek_a denote O's and A's knowledge about ek, which is ek XOR mask in O's case and mask in A's case. The result of the circuit will only be provided to A (i.e. A just doesn't send it over to O). In a number of oblivious transfers, Alice receives the keys for her input values from O. O --------- C2 ------------> A\ \ O -------- <OT> -----------> A \ O <------- <OT> ------------ A | O -------- <OT> -----------> A | Encrypt msg using SFE. Only A . | receives the result. . / . / Now Alice can compute: T_A = (keyid_A, keyid_B, next_dh, ctr, AES-CTR_ek,ctr(msg)) T_A already contains Alice's message, but she still needs to MAC it. This is again done by A and O together. O prepares a circuit C3: C3(mk_o, mk_a, T_A) = MAC_mk(T_A) O --------- C3 --------------> A\ \ O -------- <OT> -------------> A \ O <------- <OT> -------------- A | Compute MAC_mk(T_A). Both O -------- <OT> -------------> A | parties receive the value. . | . / O <----- eval(C3) ----------- A / O ----- MAC_mk(T_A) --------> A/ Please be aware that Alice will keep T_A secret. Although T_A doesn't contain any plaintext, Alice does not want to disclose it to the observing party. If she did, then her own deniability would also be gone. Also, the OTR protocol mandates that Alice should send her old MAC keys in plaintext to Bob, so that they can be considered public. If A and O wanted to, they could do that (by computing the old MAC key again and sharing the result). But as long as Bob doesn't check what Alice sent, she can just send garbage. Indeed, in its current version (libotr 3.2.0), the OTR implementation doesn't check the disclosed MAC keys. Consider the excerpt from proto.c, line 657: --- snip --- /* Just skip over the revealed MAC keys, which we don't need. They * were published for deniability of transcripts. */ bufp += reveallen; lenp -= reveallen; --- snap --- So Alice can safely send: A -T_A,MAC_mk(T_A),oldmackeys=foobar-> B ------[ 4.5 - What's Left We have seen that in a scenario where at least one party cooperates with the attacker, deniability is non-trivial. Our construction can be extended and adopted and we conjecture that it quite generally applies to deniable messaging protocols. Regarding performance: Yeah, we know that all the SFE voodoo can be quite expensive. Especially modular exponentiation in circuits is not really cheap. However, there are ways to optimize the basic scheme we have outlined here. If you're interested in that, you might wanna read [5] as an introduction. Also, refer to section 4.5.2, which outlines one particular optimization of our Diffie-Hellman-scheme. Regarding network latency: When looking at all the crypto protocols outlined in this article (especially at oblivious transfers), you will notice that often multiple messages need to be exchanged. If you need 3 messages for one oblivious transfer and you want to perform 128 oblivious transfers (for some 128-bit crypto key or so), then you end up with 384 messages being exchanged. In terms of network latency, that might be troublesome. However, there are two things that help us: first, we can perform oblivious transfers in parallel (i.e. still exchange three messages but every message now contains data for 128 oblivious transfers). We can also precompute many values and exchange them before they are really needed (random values for instance). ---------[ 4.5.1 - FAQ Q: This is all bullshit! I could just share my private keys with the police, and that would also kill deniability! Yep. And the police would then be able to impersonate you. One of our key points is that you don't need to trust the observing party, neither need they to trust you. A: But the observing party won't be able to prove anything in court! Well, yes and no. In a constitutional state you'd need to actually prove stuff in court. Unfortunately, such states are rare. But even if you live in such a state, then the observing party could be the judge. Q: But all the conversations that I had before my peer cooperated with the observing party are deniable, right? A: Yes, unless the observing party sniffed your traffic (if you used a decent anonymizer, this is unlikely). Q: Wait, the observing party so far only learned that *somebody* has sent a message. But how do they know it was the person that I tell them it was? Good question. This knowledge is generated during the initial key exchange of OTR. To be precise, the observing party and the backstabber both learn the identity of the conversation peer when he signs his key-exchange proposal with his DSA key. The observing party also sees that and as they track all subsequent key-exchanges, they can build a "chain of evidence". Q: But doesn't [4] already kill the deniability of OTR? A: Ha, even better question! At least it attacks the strong deniability of OTR. However, our scheme also attacks the weak deniability. Furthermore, the attacker in [4] has far more capabilities than in our model. In [4], the attacker is able to arbitrarily read and modify network traffic. In our model, the attacker can rely on the cooperation with one of the two conversation partners. Q: OK, I'm convinced. Is there any implementation? A: You're welcome to build one ;) See section 4.5.2 for details. ---------[ 4.5.2 - How to Implement? If you want to implement the scheme outlined above, first of all, you need some framework for secure function evaluation. There are a number of implementations out there, for instance Fairplay [6] or TASTY [5]. Once you got your SFE framework running, you need to implement all the functions that need to be computed jointly. The Diffie-Hellman stuff is probably most efficient when implemented using a homomorphic cryptosystem (such as RSA or ElGamal maybe). Now you may ask: how does a multiplicatively homomorphic scheme help us computing DH keys? Well. There's some nice optimization, which basically reduces the modular exponentiation to a modular multiplication: Alice picks some random j and sends g^(ab+bj) over to the observing party. The observing party sends g^o. A <---- g^b ------------ B O <------ g^(ab+j) ------ A O -------- g^o ---------> A Note that Bob cannot compute g^abo, because Alice's value is "blinded" with j. Alice cannot do so neither; she doesn't know o. Bob however can compute g^(abo+jo). Alice can compute g^jo and also g^-jo, because she knows j. If Alice would send g^-jo to O, then O could compute g^(abo+jo) * g^-jo = g^abo This is only one modular multiplication. So instead of doing a whole modular exponentiation, the circuit that Alice and the observing party jointly compute does roughly the following: C(o, a) = derive_keys(o*a) Where the function derive_keys() is the OTR key derivation function (hashing the common key in different ways to generate symmetric key material), O's input value will look like g^(abo+jo) and A's input value will look like g^-jo. All the symmetric operations (hashes and block ciphers) should probably be implemented as circuits, for instance using Fairplay. Both SFE schemes (circuits and homomorphic crypto) can be combined using the TASTY approach. --[ 5 - References [1] http://www-ee.stanford.edu/~hellman/publications/24.pdf [2] http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html [3] http://eprint.iacr.org/2004/175.pdf [4] http://www.jbonneau.com/OTR_analysis.pdf [5] http://eprint.iacr.org/2010/365.pdf [6] http://www.pinkas.net/PAPERS/MNPS.pdf [7] http://tinyurl.com/84z7wpu --[ 6 - Greetingz First of all I have to give a big shout to bruhns, who developed this stuff together with me! There's this one person, which I'd like to say thanks for everything (and that's quite a lot). Unfortunately, i cannot name this person here. 291646a6d004d800b1bc61ba945c9cb46422f8ac. Also a big thanks to Phrack staff for reading through all this and supplying me with real helpful feedback! Greetingz go out to the following awesome people in no particular order: ths, fabs, joern, nowin, trapflag, jenny, twice#11 --[ EOF

© Copyleft 1985-2015, Phrack Magazine.