 So, hello everyone, thanks for the introductions and thanks for the invitation. So yeah, this was part of my master thesis. This is a joint research with my advisor, Professor Ali Biham, Tetechnion. And we're talking about the Bluetooth and specifically the Bluetooth pairing and a variant of invalid curve attack or fixed coordinate invalid curve attack, which is slightly different. All right. So I'm sure all of you are familiar with Bluetooth. It's becoming one of the most popular protocol of specifically radio protocols in the world right now. All of you probably have this one Bluetooth-capable device in your pocket and more than one in your bag. Yeah. So today, Bluetooth is becoming very, very popular. IoT devices, audio equipment, and nowadays wearables and computer peripherals all move to Bluetooth. But what most of you probably don't know is that Bluetooth today is actually two protocols. So there is Bluetooth BREDR and Bluetooth Low Energy. BREDR is the former version of Bluetooth, the regional standardization. And Low Energy is more recent, but they coexist together, used for slightly different scenarios. Also, both protocols promise to provide confidentiality and many the middle protection in the link layer. So the application, in theory, shouldn't provide their own authentication. And in this talk, we'll talk about this promise and if it's provided as it should be. All right. So the Bluetooth pairing, which is the connection establishment process, is the process where two devices authenticate with each other and exchange their shared secret and the shared DVR monkey. And the main, the most recent pairing protocols for Bluetooth BREDR and Bluetooth Low Energy are secure, simple pairing, or SSP, and LE secure connections for Bluetooth Low Energy. And they are both very, very, very similar. They share a lot of things. And they're both variants of authenticated elliptical DVR monkey protocol. So the first attack that made me list curious about attacking Bluetooth, there was many, many, many attacks before that, but one of the recent attacks was shown over the first release of Bluetooth Low Energy by Mike Ryan. And he showed that the original pairing protocol used in the Low Energy was susceptible to eavesdropping attack without any interaction from the attacker. The attacker could simply eavesdrop to the pairing, iterate through two to the 20 keys, temporary keys, and that's that way breaking the session key and decrypting all of the remaining traffic without interaction at all. So that's like really bad. That's not provide any security whatsoever because two to the 20 operations today, it's less than a second in every computer. And he also provided an open source software which recovers the session key of Bluetooth sessions from captured traffic. Right, but now they addressed this problem and they moved to the new L-E-Secure Connections protocol which relies on elliptic curve cryptography. So very, very short and extremely shallow introduction to elliptic curve cryptography. So what is an elliptic curve? An elliptic curve is a group which is defined by an equation and an underlaying field. So the equation we're looking at are short varstas forms which are defined with two parameters a and b. So we have y squared equals x to the third plus ax plus b. And all of the figures you're about to see are drawn over real field because in cryptography we always use finite fields so the equations are over fq. Right, so we're talking about groups. So we have a group element. So the elements in elliptic curves are points or pairs of coordinates x and y which satisfy the curve equation over the underlaying field. We include another point which is very important for this attack called the point at infinity which will be the identity element of the group. This is a new point that we introduce to this set of points, set of elements of the group. And because it's a group you have an operation, in this case the operation is addition. So we'll denote it by the plus symbol and we'll use the inverse notation of minus one with brackets for a point b. And we also need a scalar multiplication which is simply adding a point to itself several times. Right, so this is the notation we're going to use. So point addition, we'll divide the point addition into, sorry I have the notation for scalar multiplication twice. Anyway, point addition, we'll divide it to point addition and point doubling. Point doubling will be adding a point to itself and point addition is adding two different points. So how the inverse is defined? The inverse is defined very, very simply. All you have to do in order to inverse a point is to negate the y coordinate, reflect it across the x-axis and then get the inverse of that point, right? So this is how it works. And point addition, adding two different points is done by taking the line that grows both points, p and q, finding the third intersection with the curve and reflecting that point across the x-axis, getting the inverse of that point. And this will be the result of p plus q. And you can see here the simple one way to compute this formula. And as you can see, this formula do not involve the curve parameter b. This means that you can compute all of this computation, find the result point without even knowing what the parameter, what the b parameter of the curve. Now we'll move on to point doubling. So very similarly, but instead of taking two points and finding the line that grows both points, we simply take the tangent line at point b and then again find the second point of intersection, inverse that point and get the resultant point. Note that this formula also do not involve the b parameter of the curve. Finally, I want you to notice last observation, which is that there are some special points of some sort that are an order of two. That means that if you add these points to themself, you will always get the identity element. The simplest way to see that is that if you have the y-coordinate equal zero, then when you negate the y-coordinate, when you get the inverse of this point, you will always get the same point and therefore adding them to themself will give you the identity element. Great. So now I'll go briefly about elliptic curve Diffie-Allemann. I'm sure all of you are familiar with the Diffie-Allemann protocol, so I'll do this very, very fast. All you have to remember is that instead of doing things in multiplicative modular group, we're doing these things on elliptic curve groups. And therefore we have to agree on an elliptic curve, which means the parameters a, b, and the underlying field fq. And we also have to agree on a generator point b. So both parties select the secret key to be a scalar, in this case. They multiply this scalar with the generator point b. They get the public keys. They exchange these public keys. And then they multiply the secret key by the correspondent public key to get the shored Diffie-Allemann key. And since this process is commutative and associative, they will get the same shored key. Great. So now we can talk about the first major attack against protocols that use elliptic curve Diffie-Allemann, which is the invalid curve attack. So introduced by BLL, this cryptographic attack uses points which do not satisfy the curve equation in order to extract, in our case, the secret key of a victim. So how it works. So what we're doing here is the attacker, we are in the scenario again of elliptic curve Diffie-Allemann. So we have a victim and we have an attacker. And the attacker selects a different group, a different elliptic curve, which differs from the original elliptic curve that was agreed upon by the B parameter. And what's special about this new curve is that it has subgroups of small size. So he finds this kind of elliptic curve. It's very, very easy to find. And when he finds one, he simply selects a generator point of a small subgroup. We'll call this point P1. He then, the victim transmits its public key. The attacker transmits Q1, sorry, Q1 will be the point with the small subgroup. It transmits Q1. And then the victim will try to compute the shared Diffie-Allemann key by multiplying its secret key by the point Q1. So since this is a generator of a small subgroup, there are a very small amount of possibilities for this shared Diffie-Allemann key. We will have the assumption that as happens in a lot of protocols, now the victim will transmit some message encrypted using the shared Diffie-Allemann key to the attacker. And again, for simplicity, let's assume that this message is known to the attacker. So the attacker can now try to find the disparate log of the secret key under this small subgroup. So what the attacker is doing is simply iterating through all of the possibilities for this shared key under the small subgroup. And that's finding, after finding the correct value, the correct shared key, it actually reveals the information of what is the secret key, modulo, the size of the small subgroup, in our case P1. So by extracting this information, the attacker can now continue this procedure using a different subgroup, a different elliptic curve, or even the same elliptic curve and a different subgroup, and then extract another information about another modulo of the secret key. And finally, after extracting enough information, enough co-prime modulers, the attacker can reveal the secret key by applying the Chinese reminder theorem. So that's the idea behind the original invalid curve attack. Note that the original invalid curve attack uses two basic assumptions. One of them is that we could initiate the key exchange multiple times with the same private key. And the second one is that we could send any pair of points, coordinates, X and Y, which will not satisfy their curve equation. So these are two assumptions that I used during the original attack. And this attack is known for a very long time, and therefore the Bluto specification suggested as a mitigation to the stack to simply refresh the DfM1 keeper every pairing attempt. And that's preventing this attack because the first assumption will no longer be valid. Because if you refresh the keeper every attempt, the secret key will be different on the next attempt. And as we saw later, all of the implementation we've tested, follow this suggestion, sorry. All right. So the Bluetooth pairing, now we'll go a bit deeper into the pairing procedure. So it responsible for generating the shared encryption keys, as we previously said. And due to the, all of the similarities between SSP and LESC, we will only talk about LESC, but everything I'm going to say regarding LESC will also apply to SSP and vice versa. So don't worry about that. So how the other pairing protocol is comprised? So it comprised of four phases. The first phase is feature exchange. It has no cryptographic properties, so we're going to leave it in the side for now. Phase two is the key exchange. Phase three is the authentication, and which is very important to us. We'll take it into it very soon. And phase four is the key derivation phase. All right. So the key exchange is simply an elliptic curve DfM1 key exchange, as we saw just a few slides ago. And it uses the standardized P256 elliptic curve, NIST elliptic curve, which is I think the most widely used curve today. That's in LESC connection in the Bluetooth PR-EDR, it uses a different curve, but also NIST standardized. These two functions, F4 and G2, you don't really have to remember them. I just put in here for completeness of this lecture. These are two cryptographic functions that will be used during the authentication phase. All right. So now we can dig into the authentication phase. I hope you can see this diagram. I'll go every step and then explain it, so if not, that's not horrible. So the authentication phase begin when both parties, device A and device B, selects a random nonce NA and A and B. Both of them are 128 bits long. Then they both set some value that's called RA and RB. In this case, they set it to zero. Doesn't really matter for us right now. Then device B commits to both public keys and its knowns using function F4 and transmits the commitment value, CB. Then device A transmits its nonce and device B reveals his nonce following by a check of the commitment. This process is merely to make sure that no device have advantage regarding the selection of the nonce, because otherwise a attacker that tries to device a man in the middle attack might use the ability to know the nonce, that the nonce is selected in one device before it was selected in the other, and might device some attack according to that, so that's supposed to prevent it. Because again, both device B commits to the nonce and then device A reveals its nonce and then device B reveals its nonce. The most important part of the authentication phase is what comes next, which is the application of function G2 on both public keys and both nonces. This process should prevent any man in the middle attack to happen in the Bluetooth pairing, since I'm sure most of you at least have encountered the fact that when you pair two Bluetooth devices, you are presented with two numbers and you have to confirm on both devices that these numbers are in fact equal. Or in some cases you have, you are displayed one number and you have to enter this number into the other device, that also happens. That's another different way to do it. But this process is actually the authentication of Bluetooth. And what these numbers should mean is the sort of hash function on both public keys and both nonces. And by confirming that both numbers are equal, you're supposed to prevent any man in the middle who wish to change these public keys and device a simple, naive man in the middle attack. Because if you try to change these public keys, then you cannot make sure that the nonces will be equal in both devices and the user will immediately notice it and say, hey, someone attacking me. So that's the basic idea of the Bluetooth authentication. Now to the confusing part. So despite the fact that these diagrams show that the function G2 and F4 is applied to both public keys, pKa and pKb, it is actually applied only to the x-coordinate of both public keys. So this is later in the specification is defined as pKa x and pKb x, but not in the diagrams. All the diagrams show only pKa and pKb. So very confusing, but that's the case in Bluetooth. All right. So now after we know that, after we know how the authentication works, we can think of some attack. So the attack is sort of based on the fact that the y-coordinate is simply unauthenticated during all this authentication procedure. It is not involved in any of the computations. And with that, we can also remember that the Bluetooth standard do not require implementation to validate whether a given point satisfy the curve equation. Again, the mitigation that was used is not that, it's a different one. So what we can do in order to attack this protocol by changing the y-coordinate to any value that we want without affecting the authentication. So we'll describe two versions of our attack. The first one is the semi-passive and the second one is the fully active. So the semi-passive is extremely simple. All you have to do is you are an attacker. You were in the middle scenario. So both devices, device A and device B, want to pair with each other. So they both compute their public keys. Device A transmits its public key to device B. All the attacker do is modify the y-coordinate to zero before transmitting forward to device B. We'll call the new public key pKa prime. Similarly device B transmits its public key and the attacker set the y-coordinate to zero and transmits pKb prime. What happens now? Now if you think about it, they might not get the same DEFIA monkey anymore. We have no such promise because we're working in totally different elliptic curves, totally different subgroups. This is not necessarily will provide the same value and we call this value DHKa and DHKb. But to be more exact, we can say that with rate of 25%, with rate of quarter, we will always get both points, both DEFIA monkeys to equal that point at infinity. Why is that? We just set two public keys to be generator points of subgroup of order two. So we multiply that by some random value and with a chance of half each of the random values will be even. If this value is even, we're adding generator points of order two, even number of times and then therefore getting the identity element. So with rate with probability of quarter, both secret keys are even and therefore both of the shared key will be the point at infinity. So what happens if this event occurs? So if this event occurs, the attacker knows what the shared DEFIA monkey was because everything worked fine. The shared key is synchronized between the two devices. The authentication succeeded. Everything works perfectly and therefore the attacker knows that shared key was the point at infinity. He can derive the long-term key and the MAC key and decrypt and encrypt messages, however he likes, without further intervention with the protocol, without anything else. So that's very simple, very straightforward. Now we need to look at another two functions. Again, you don't really have to remember them. This is function F5 and F6. We need them in order to consider that key derivation. How could we improve this probability, this success probability of quarter? We want to do something better. So how could we, how could you get a better success probability? So in order to do that, we first have to introduce ourselves to the key derivation phase. So the key derivation phase begins where the function F5 is applied on the shared DEFIA monkey, both nonces and both MAC address. We then derive the long-term key and the MAC key using function F5. And then two confirmation values are exchanged, EA and EB. These values are exchanged in order to make sure that both devices actually got the same DEFIA monkey, which is something important if you want to continue encrypting and decrypting messages. So as you remember from the semi-passive attack, we currently succeed, the attack currently succeed only if the two shared DEFIA monkeys are the point at infinity. But in this fully active attack, we want to increase this probability by also, by also using different scenarios. So the scenario we'll be using is the scenario, specifically, when the DEFIA monkey, when the DHKEA equals PKB prime, the attacker already knows that the attack is going to fail. And in the semi-passive version. Because in the semi-passive version, if DHKEA equals PKB prime, there is no chance that DHKEB will equal this value, and therefore the semi-passive attack will fail for sure. And the attacker can do nothing about it in the semi-passive scenario. So how could we use this information in order to improve a success rate? So what we're going to do is simply test during the key derivation phase whether this event occurred. So the attacker could check the value of EA, the confirmation value, send by device A, test it to be either PKB prime or the point at infinity, the identity element. If it equals the point at infinity, it could continue as with the semi-passive attack and it will have a chance of 50%. Otherwise, it knows the semi-passive attack will always fail and therefore it should do something different. So what exactly it should do? So it should arbitrarily select some value DHKEA prime to be one of the two possibilities for DHKEA. It should then compute the correct confirmation value EA to be EA prime by simply inserting the guess, the guess of the DHKEA prime to the function F5 and compute all the confirmation computation as usual, F6, sorry. What the device B will then do, he will try to verify that, again, with probability of 50% of half, this verification will pass, otherwise he will abort the pairing process and if the verification succeeded, the attacker knows what is the Diffie-Amon key chosen by device B because he got the correct guess. So he knows that DHKEA prime just equals DHKEA B. And then device B will compute and send his confirmation value EB and the attacker will compute and transmit the correct confirmation value EB prime, which he already knows because he knows that DHKEA. Note that in this scenario, now the attacker, there are two different session keys and therefore the attacker needs to decrypt and re-encrypt every message, every data packet that is being transmitted between device B and device A, which make it a lot harder to implement than the original semi-passive attack. But with the added benefit of a better success rate, so this is very, very simplifying slide to show you that success rate of the semi-passive attack is only with a quarter of the possibilities and for the active attack, we have quarter of half depending on your guess, but again, it doesn't really matter what your guess is, it's arbitrary. So after we talked about all the details of the attack, we can move on and talk about higher level details and implementation and real-life consideration. All right, so unlike Wi-Fi and other radio frequency-based protocols, Bluetooth has frequency hopping, there are radio-based protocols that use frequency hopping, but some don't. And when we are trying to implement this kind of attacks, we also have to consider this. Even though most of the time these frequency hopping do not provide any cryptographic security, specifically in Bluetooth, I can tell you that the frequency hopping in Bluetooth low energy is extremely simple and could be broken in seconds, if not less, as shown again by Mike Ryan in 2013. And to be honest, it doesn't really matter because Bluetooth protocol is so simple that you can buy slightly more expensive equipment that will simply transmit and listen to all of the Bluetooth channels simultaneously and then that's eliminate this problem once and for all. We should also consider the over-the-air pocket manipulation because as you saw during the attack, we had to capture a packet and then change it before transmitting it to the other party. So there are some projects that try to do it today. As far as I know, but last time I checked was about a year ago or even more, there are no commercially available equipment that could do it reliably for Bluetooth 4.2 with at least secure connections or Bluetooth BREDR, but I'm sure that I don't think it's such a big problem that couldn't be resolved in the following years. And it really depends on the incentive for companies or individuals to design this equipment. If somebody wants, I will be happy to talk about how exactly this thing could be implemented and exactly what is the process that needs to be taken in order to devise these kind of attacks, but it's possible. There has been a lot of work in different protocols that do similar things. So now we can move on to talk about the design flaws in the protocol that made this attack possible. So I think one of the major design flaws, again, I have been approached several times after I gave this talk by several standardization people who told me that as I already knew, there was a lot of problems when standardizing elliptic curve cryptography over the years and especially when we go back to 2007 when Secure Simple Pairing was first designed. So I know some of these critics might be due to this patenting things, but I think it should still be in the slide for future implementations and design of protocols. So using both coordinates during the key exchange is very unadvisable. It highly increased the attack surface and it's really unnecessary today. You have multiple ways to compress points such that you wouldn't have to send both coordinates. There are different elliptic curves that you can work with that do not need the second Y coordinate and you could also simply send the X coordinate and assign and then compute the Y coordinate from that. And secondly, and maybe the most, the more important one is the fact that the protocol authenticates only the X coordinate. We couldn't find any strong reasoning for doing this. I mean, if you already send both coordinates, you should authenticate both coordinates. I don't see why not. I should also point out that original mitigation that was suggested during the standard of refreshing the secret key every pairing attempt do not apply to this attack at all. We don't rely on previous pairing attempts in order to extract information on the current pairing attempt. So this mitigation is irrelevant, sorry. So and the obvious and recommended mitigation against this attack is obviously to validate whether the given public key satisfy the curve equation. If you would do this validation, this attack will be prevented. All right, now as with all the other presentations, we will move on to the disclosure part and the test of vulnerable devices. So we've tested a lot of vulnerable devices and multiple vendors. First we informed the Bluetooth special interest group, which is responsible for the standardization of Bluetooth. The CVE was assigned to this vulnerability. And then we started hunting implementations and checking whether they're vulnerable or not. So first, we had to consider the fact that Bluetooth-ally secure connections and Bluetooth secure simple pairing, the two pairing protocols are implemented in two different places. Any secure connections is implemented in the operating system and therefore we had to look at the implementation of multiple popular operating systems. So the implementation we tested was the implementation of Android, which is called Doodread. We actually haven't tested, but we're informed by Apple that both iOS and the Bluetooth implementation was vulnerable. iOS and macOS implementations were both vulnerable. Microsoft actually at the time didn't have an implementation of any secure connections. But it had only the implementation of the legacy pairing, which as you might remember is vulnerable to the passive, very, very simple attack, so that's not a good thing. Next we moved on to implementation of secure simple pairing. So secure simple pairing opposed to the any secure connection is actually implemented by the Bluetooth chip. So we've tested all of the three major vendors of Bluetooth chips, which is Qualcomm, Broadcom and Intel and found all of them to be vulnerable. So that was, I don't know if surprising or not, because by now we already knew that probably all of them limitations will be vulnerable. And the industry reaction was actually pretty good. It required a lot of effort in order to coordinate between all these vendors, but after we overcome this obstacle, all of the vendors acted very responsibly. They all provided patch to their devices. Some of them released their patches through their vendor partners, like Qualcomm and Broadcom. Others simply released the patch online and all through their update procedures. So yeah, all of the operating systems have been updated. But the more important thing is that the Bluetooth actually addressed this finding very seriously and released a formal statement saying that, yes, this problem occurs and yes, we are aware of it. And we're also, at least as they promised here, will add the vulnerability testing to their qualification program so that no Bluetooth compatible device could be released to the market with this vulnerability in the future, which is very encouraging. And thus, the specification was changed and hopefully this vulnerability will not occur in the future. Finally, I want to sum up by saying that we have introduced a fixed coordinate invalid curve attack, which uses the fixed X coordinate in order to device invalid curve attack in a different way, which might be useful in some other protocols. I currently haven't encountered another protocol that has this special design issue, but maybe. We presented its application on the Bluetooth pairing protocol. We proven that all of the current pairing protocols are insecure. None of them was secure against this attack and previous attacks together. And we've discovered multiple design flaws in the Bluetooth protocol, which again were addressed in protocol specification change. And we found that all of the vendors, all of the big vendors are vulnerable and according to this finding, the protocol was modified and our findings were addressed through all of the channels. Finally, I want to thank the third coordination center for helping us to coordinate with all the vendors. Again, it was very difficult. There were a lot of vendors. And for all of the vendors for patching the system and not having to go through a trouble of ping pong between us a lot about this. That's it. Thank you for the great talk earlier. If you have any question, please come to the micro and thank you. Good work, by the way, not a criticism of the work. But do you have any understanding for how this happened in the Bluetooth process? The checking for the point of infinity, checking for the point on the curve. Those tests were in X9, a gazillion years ago, what, 20 years ago? Do we have any insight into how the Bluetooth people didn't even refer to the ANSI standards that probably existed at the time? So that's totally not an insight information. I really don't know what went through the process. But what I've heard from people that came to me after this talk was that the patenting regarding point validation made things very complicated in the time. There is actually a patent against that covers point validation, which is a very broad thing to cover, which, again, if companies were trying to validate their points by simply testing the curve equation, that might result in a patent violation. So that made things very complicated. So I just had a completely weird question. When you're talking about the existing technology that does over-the-air packet manipulation, is that doing it as it's being broadcast, or is it doing some sort of man-in-the-middle thing? So I haven't tested it fully to understand exactly what it's doing. Again, it doesn't work with the DFM side. So maybe it relies on the fact that you can simply break the encryption key, and that's simply jam the one device and transmit another packet together. I'm not sure. I don't want to confuse you. All right. That's fine. Thanks. Okay. Any other question? If this is not the case, then please thank the speaker once again.