 um yeah the talk the first talk of the session is return of the hidden number problem a widespread and novel key extraction attack on ecdsa and tca and it will be given by keegan rine. Alright thank you so yes I'm keegan rine this is the return of the hidden number problem. Now the return of the hidden number problem is an ecdsa and dsa side channel based key extraction attack so that means if you have some ecdsa implementation like a smart card or a server or an authenticator that creates ecdsa signatures this attack attempts to use side channels to recover that private key. The return of the hidden number problem uses an old technique that is solving the hidden number problem and it uses it to target a new part of the ecdsa and dsa signing process. This attack is also very common throughout this research I looked at 20 different open source implementations of ecdsa and dsa signing and I found that 11 of these libraries were vulnerable to this key extraction attack. Finally this attack is very efficient it's easy to understand it and it's easy to under uh to apply so throughout this talk I'm going to try to give you an intuition for how this attack works so that you will be able to spot this issue when exploiting other devices and be able to extract ecdsa and dsa keys of your own. So in order to understand the return of the hidden number problem it's important for us to understand the prior work on extracting keys from dsa and dsa implementations. So as a brief refresher for those who don't do side channel attack research we have the ecdsa equations here which compute signature r and s for a message m using private key x. Now the value k here is a per signature random value which is the nonce and all these computations are done modulo q which is a large prime frequently on the order of size 2 to the 256 for the examples we'll use in this presentation. Now I'm going to be a bit uh loose with the notation here uh and not always right when things are done modulo q uh but if you want to see the uh rigorous definitions then I'll refer you to the paper. So in these equations when we're calculating the signature r and s the attacker knows the values of everything except k which is the per signature random value and x which is the long term private key. So if the attacker uses a side channel attack to recover information about that nonce k they can use that partial information to figure information about the private key x and if they repeat this process for many signatures they can compile all that leaked information about x together and recover the full private key. Now more concretely uh I'll explain how the hidden number problem ties into this. So in a naive implementation when calculating the multiplication of k times g it's possible that a naive implementation would compute this product faster when k is small. So the attack can observe that that multiplication k times g happens quickly during the signature generation process and for that k is small. And now when I say small it's not absolutely small but it's relative to the size of the field. So if we have a field that's based on a 256 bit prime then k may be anywhere between 1 and 256 but the side channel may give us information that k is between 1 and 2 to the 250. So we get six bits of information about k but 2 to the 250 is still larger than any brute force attack that we could perform. So with this small amount of leakage about that nonce k we can rewrite the DSA equations as follows uh to show what k equals. So on the right hand side we have a bound which is based on that modulus q uh and the more bits that are leaked about k the tighter that bound gets. And then in the center we have a uh the private key x right here. So every uh equation that we derive from a signature has that private key x. We have a known multiplier which is based on the value of that signature and we have a known offset which is based on the signature and the message being signed. So if the attacker observes this side channel leakage uh for both the offset and the multiplier and they know this bound based on the side channel leakage they can construct this inequality and if they repeat this for several signatures they can construct several inequalities and then the goal is to be able to solve this system of inequalities which is possible using a lattice based reduction approach. So this sort of problem is known as the hidden number problem. In the important parts are we have that hidden number x which we're trying to recover, we have a known multiplier, we have a known offset and we have a known bound. So if we see something of this form that's going to be something that we're able to solve. So the way that these issues were patched because many of the prior attacks on DSA and ECDSA exploited the sort of non-sleakage is that that multiplication of k times g was hardened more countermeasures were added so that if information does not leak about k times g in the computation of r then you can't use that leaked information about k to recover the private key. Now with that in mind it's possible to see how the return of the hidden number problem differs and how that attack works. So we have the same ECDSA equations where the attacker still knows r, s, m and g but instead of targeting that multiplication in the computation of r we ignore that computation of r completely and we only look at the addition in the calculation of that signature component s. So we don't care about all of the countermeasures that were applied in this step, we're only looking at this addition right here. So when we look at the libraries and we see how they implement this addition it's done in a very straightforward way. So if you're trying to add two numbers modulo some other large number first you add the two numbers if it exceeds the modulus then you subtract out that modulus and then you return the final value. So this works if both of the arguments are reduced modulo q at the beginning and it is done very quickly. But since this is a side channel attack you should immediately jump to this conditional branch right here and know that a side channel attack will be able to recover if this branch is taken or not. So our side channel attack is going to be tuned to recover to see if this subtraction occurs or not. And note that if this subtraction occurs then we learn information about the arguments to this function. If that subtraction occurs then a plus b exceeds q. And that's all we need to know to be able to perform the return of the hidden number problem attack. So returning to the equations we are observing the calculation of m plus r times x. We're assuming that m and rx are both already reduced modulo q. And we're going to use a side channel to see if that addition wraps around. And there are many different side channels that we could use for this attack. I use a Flush and Reload attack on a cryptographic library but you could also use a power trace. You could use EM analysis. You could use pretty much anything as long as you learn whether or not this addition wraps around. So if this addition does not wrap around then we can take that equation, see that m plus rx is less than q and rewrite it as follows. And if we see that the addition does wrap around we can again rewrite the equations as follows. And once again I'm being a bit loose with the notation. But the thing that I want to point out is that we have a private value right here that we want to recover. We have a known multiplier which is based on the signature. We have a known offset. And we have a known bound. So this is just an instance of the hidden number problem. If we observe this process for many signatures and put this into a lattice and use that lattice to solve the hidden number problem we will recover the private key x. So it's very straightforward. And this attack has many benefits. For one it's very fast. So you only need about a few thousand signatures in order to be able to perform this attack. And the reduction happens very quickly in many cases under a minute. This information can also leak through many side channels as we've spoke about already. There's the flesh and road. There's all the memory cache. There's all the physical base side channels. Anything that can leak that one piece of information we'll be able to extract the private key. Another benefit is that the attacker is often in control of that message m that's being signed and they can tune that value in order to change what the bounds are. So if I go back to these equations we see that the bound is dependent on m. So if we choose m to be small, for example, around two to the 250 instead of two to the 256, then we can tune these equations so that when we observe the right condition of the modulus being subtracted out or not, we're going to be able to get more information about the private key x in these hidden number problem inequalities. This issue is also nice because we're able to detect it in a black box. So assuming we have some timing dependence on whether or not the subtraction occurs, we can create many signatures with a large m. So that's m where the leading bits are set. And since m is large, it's likely that when adding with the random r times x, that sum is likely to exceed the modulus q. So a large m is going to be more likely to have that wrap around that extra subtraction. A small m is similarly likely to not have that extra subtraction is likely to take less time. So we're able to collect many signatures using both large m and small m. We're able to do a statistical analysis to see if there is a timing difference between those two cases. And then if there is, then we can use a more powerful side channel attack to try to extract information about a single signature. Another benefit of this attack is that it sort of completely sidesteps all the power countermeasures. So many of the power countermeasures were target at that multiplication of k times g. But our attack does not care about that multiplication at all. It only depends on that one addition of m and rx. And the last benefit is that this efficient attack is common. So of those 20 libraries that are looked at, 11 were vulnerable. And it's likely that other libraries are vulnerable as well. So throughout this research, I did look at many implementations I'd like to just show you some of those implementations that I looked at. I started with this long list of different implementations, which I thought might be affected by this issue. They're just cryptographic libraries of some sort or another. And I think there are 30 sites up here. So I started by looking at which ones were open source and I excluded all the ones which were closed source just because I had to analyze these by hand and harness all these by hand is a lot faster to just look at the source code to see whether or not there was an issue. And all of the highlighted libraries here are closed source. Some of these libraries also just wrap the ECDSA or DSA implementation. So again, those libraries are not vulnerable because they just use a different implementation. And finally, a few of these libraries don't implement the DSA algorithm or ECDSA algorithm at all. There's no option to use those. So those are also not vulnerable. But we're left with these 20 libraries. Of these libraries, some of the implementations were entirely constant time. So that modular addition did not follow the pattern of A plus B, if that exceeds Q, subtract Q. These use a fully constant time implementation for that part of the code and are therefore not vulnerable to the attack. If you recall another requirement of the attack is that both the operands of that sum are already reduced modulo Q. M needs to be reduced modulo Q and Rx needs to be reduced modulo Q. And if it's not, then the attack won't work. So some of these implementations did not do that reduction modulo Q. So the attack doesn't work. But that means that all of these remaining attacks, all of these remaining libraries are vulnerable to the attack. And we can see some pretty prominent names. So there's OpenSSL, there's LibGCrypt, all of these libraries were vulnerable to this attack. So it's clearly widespread. It clearly affects a wide variety of implementations. And I'm sure there are many more closed source implementations out there, which are vulnerable as well. So the proof of concept attack that we applied in the paper was done against OpenSSL. But the source code for that attack is very configurable. It's easy to apply to any of these other libraries, as long as you can create an oracle that shows whether or not that extra subtraction occurred. And the last point that I want to leave you with is an example that I actually just found yesterday when I was looking through the code. So do you guys recognize this device? It's the 502 authenticator that we all got as part of CHES. And it turns out that 502 uses ECDSA keys to authenticate you to different web services. So if it's possible to extract that ECDSA key, you can impersonate someone without having to have physical control of their device. Fortunately, the firmware for this device is open source. So I was able to go through and find the actual implementation of the ECDSA signing. And we can see that the implementation is based on microECC. And it says that it's resistant to known side channel attacks. But it was also updated two years ago. So that's prior to this work. And I look through and I found the implementation of that modular addition that it uses for the ECDSA signature. And here's directly from the code what it is. And we can see that once again we have our operands left and right being reduced by a modulus. And we start by adding, we compare it to the modulus. And then if it exceeds the modulus, subtract it out. So a memory side channel attack would be able to detect whether or not this function is called. It would be able to tell that the extra subtraction occurred. And it would be vulnerable to this key extraction attack. So perhaps you use some sort of physical side channel as you're monitoring the execution. Or perhaps it's reliable enough to use timing. But it should be possible to recover ECDSA keys in this way. And now I do want to point out that this is outside of the threat model of these keys. These keys are only designed to resist online attacks. That's attacks where someone is, they only have access to a computer, they don't have physical access to your device. So the point is not that you should not use these devices. You still should use these authenticators. But the issue that I want to raise is that the vulnerability that's exploited by the return of the hidden number problem is widespread. Many things are affected by it. Many completely distinct and unique implementations are vulnerable to the same flawed pattern. So how many other close first implementations out there might be vulnerable to this pattern as well. So in conclusion, the return of the hidden number problem targets a different part of the ECDSA signature process than prior side channel key extraction work did. And this is how it's able to evade many of the counter pressures. This attack is also widespread. A large number of libraries were vulnerable to this key extraction. This attack is efficient. It only takes a few thousand samples and the analysis completes in around a minute. This issue is easy to both understand and exploit. And finally, I hope that you're able to look through ECDSA implementations and as you're developing new side channels, you're able to see if this attack will apply and if you're able to recover your own private keys. Thank you. Yeah. Thank you. Are there any questions? So if there are no questions, so it took quite some time until this attack has been developed. Do you think that there are more things hidden in ECDSA that we yet have to uncover? So I think so, and that kind of goes to the counter measures that were applied in response to this disclosure. So of those libraries that were affected, many of them did not use constant time field operations for that computation of S. And the counter measures that I recommended to these libraries were twofold. One of them was a blinding operation, which would prevent leakage from the specific addition. And the other was making the libraries constant time, which would protect against leakage in other parts of this computation, which involved the Private Key X. And almost universally, the libraries chose to implement only the blinding mitigation and not making the operations constant time. So I would not be surprised at all if a future attack will be able to use that lack of constant time implementation for those field computations in order to leak the Private Key again. Thank you. Thanks. So if there are no further questions, let's thank the speaker again.