 Give a warm-up applause for Stefan Fabüchen. He is a crypto-logist and also a security analyst. And he will tell us about wallet security. So I'm impressed. Hello, can everybody hear me? Okay. So I'm Stefan and I will talk about wallet security. First I will give a little bit of background what I worked on. So I'm a diploma informatica, which is like the old master's degree that they had in Germany. And I work as a security consultant in Switzerland. And I've done more research related to blockchains and Bitcoin, which were related to zero-notage proofs, and zero-coin, which is the predecessor of Zcash. Some people might have heard of Zcash. I did research on ECDSA with regards to Bitcoin. This is also what this talk will be about. For a few months I also worked on my own blockchain project, which failed. Later I worked as a consultant for another blockchain project, which was released last month. And I also did wallet security reviews for several customers who wanted to use their own wallets or wanted to use the wallet and wanted to have a review. So this talk will have five points. So first we will have a little recap of Bitcoin and ECDSA, a little bit of background that will help us to understand what the next thing is about. Then we will talk about wallets. What is a wallet? Then we will see a list of common attacks that have been found in the last years. And then we will talk about a more sophisticated attack. And then we will come to some conclusions about wallet security. So first, I think everybody now has heard of Bitcoin. Regarding this talk, I will always talk in terms of Bitcoin, but the same applies to any cryptocurrency. But to make things simpler, we will use Bitcoin as an example, so we have fixed parameters that we work with. So Bitcoin basically is what we need to know is the public ledger for transactions. Users have public and private keys. They use the private keys to sign transactions. And the transactions are published in a blockchain so that everybody can verify the transactions. It works like this. We have Alice, Bob and Carol. And if Alice wants to send a Bitcoin to Bob, then Alice creates the transaction, signs it and broadcasts it. Miners will collect it. Miners will put them into the block. And Bob waits until the transaction appears in the blockchain. So the creation of the transaction consists of the following steps. Alice first creates the transaction where it says, I will send one Bitcoin to Bob. Then she adds Bob's address where the Bitcoin is going to be sent to and then she signs it with a private key. So what's important for us now is basically two things. They are private keys and public keys. They are used for signatures and all the signatures are published in the blockchain. So the signature algorithm that's used in Bitcoin and in most other blockchains is ECDSA. I think most people have heard about it, but I will give a quick recap on what it is and how it works. So the abbreviation stands for elliptic curve digital signature algorithm. And it's related to many other well-known algorithms. I think everybody has heard about the Diffie-Hellman key exchange. This was pretty much the first public key, private key algorithm. It was based on discrete logarithm model number P. And then Mr. Elgamal, who is also the inventor of SSL, he created the first signature scheme based on Diffie-Hellman. And then Mr. Schnorr, Professor Schnorr from Frankfurt, he made the signature scheme more efficient. And then the American government took the Schnorr signature and created the digital signature algorithm, which is a standardized version of the Schnorr signature, which also standardizes to use SHA as a hash function. And ECDSA is the same algorithm as DSA, but built on elliptic curves instead of discrete logarithm with numbers. So what's an elliptic curve? No first, why do we use elliptic curves in the first place? The problem with the old algorithms, most importantly RSA and DH, Diffie-Hellman, also DSA, which is related to Diffie-Hellman, unfortunately they have no future because the keys are pretty big, the algorithm gets pretty inefficient. And now if you increase the key size, you don't gain much more security if you want to have a key. So if you have a 2000 bit RSA key and a 4000 bit RSA key, then the 4000 bit key is not twice as secure, but only a little bit more secure. And if you really would like to have a twice as secure key for RSA, for example, or for Diffie-Hellman, you would need 15,000 bits and that's very inefficient. So elliptic curves are quite a solution that's used nowadays in order to get a more efficient algorithm. So what's an elliptic curve? Elliptic curves are curves that are defined by an equation. y squared equals x to the power of 3 plus ax plus b. And the elements that we are talking about in the algorithm are points on that curve. So we can see the curve on these pictures and the curve has the property that if you draw a straight, crossing the curve, then the straight will intersect the curve only at a maximum of three points. And based on that, we define operations. So we can, for example, define an addition of points. So if you see on the left picture the points p and q, and we want to define an addition of the two points, then we say p plus q plus r is neutral because those are all points on the straight line. So we define p plus q to be minus r and minus r is the point opposite to r. And in the second picture we see if we want to add a point to itself, then we draw the tangential to the point and the tangential will cross the curve at another point and the inverse of that point will be used as a result. So we have, if we want to add q to q, we say 2q to this. The result is minus p. And with that we have a way to add points to themselves. And we can scale this up. We can also add q to q and to q again. So 3 times q, 4 times q. And this operation has a nice property because multiplying a point with a number is easy, but the inverse operation is hard to compute. So this is the operation where the whole algorithm is based on. So how are signatures with ECDSA generated? So first we have a point g, which is a fixed point that's already, for example, with Bitcoin it's already defined to be a certain point. The point has the order n, which means that if you add the point to itself n times, you will go back to the same point. And we also have a hash function h. In the case of Bitcoin it's char 256. And we have a private key d, which is a number. So all lowercase letters here are numbers. And we have a public key, which is the point q that you get when you multiply the point g by the number d. So to generate the signature, you have to pick a random number k. This is also highlighted as red. We will see later that it is important to keep the red numbers, so the longs and the key secret. You compute a point r by multiplying the generator point with k. Then you take the x coordinate. And then you compute the formula in the first line. It's not really important how the formula works for us. It's more important which values have to be kept secret and which values are published later. And then you return r and s. R and s is the signature for the message m. And to verify it, you compute the following formula. It's not important to see immediately that it works, but this is how the algorithm is defined. What's important to know is that for verifying, you don't need to know the secret k. And you also don't need to know the private key, of course, but you use the public key q. So this algorithm has a property that was already published with the first paper where the algorithm was defined. The longs k, which is highlighted as red, and needs to be kept secret because if you know the secret, if you know the longs k, you can use the parameters that you get in the signature to compute the private key. And so stealing the longs k for one signature is equivalent to stealing the secret key. That's common knowledge, but it will be important later on. So now we will talk about what the wallet is. So we have seen Bitcoin, basically in Bitcoin, you have a private key and a public key and the private key is used to spend bitcoins. So if someone gets access to your private key, he will be able to spend your bitcoins, so you wouldn't want to protect your private key. And the software that you use to manage your private keys is called wallets. So there are different types of wallets that you can distinguish. So the simplest type is software wallets. You just have a software that generates your keys and stores your keys in a file, potentially protected with a password. The software wallet is easy to use. It can be used on a desktop, on a laptop, on a phone, on a server, if you have an online shop. It's flexible, you can modify it, you can update it. But it has the problem that the keys are on the machine where a lot of things are working. So if you have, for example, a malware on the machine, it can be stolen. Then you have hardware wallets. Yesterday there was another talk about hardware wallets. So hardware wallets are dedicated devices, for example USB devices or an offline laptop that are used to manage your keys. So the advantage of it is that you don't have the keys on a host where malware, for example, could steal the keys. You have them on a separate device. One problem with hardware wallets is if you have a small device with only two buttons, you need to make sure that you're actually signing what you think you're signing, but that's another problem. And the new wallets all have quite large displays where they show the transaction that they are signing. So this is quite a solved problem. There's actually a third type of wallet which I put together as a paper wallet so you can print out your key on paper, put it in a safe, and nobody will be able to steal it. But of course you will not be able to use it until you enter your paper wallet, your key from your paper wallet into a computer because you don't want to do the computations by hand. So hardware wallets have another... So there's another distinction that you can do different from hardware wallets and software wallets. You can use crypto hardware. For example, every smartphone nowadays, for example, the iPhone has this little chip that's used to manage keys. So I titled this as hardware key storage. So you can have a chip that generates keys and the chip does not allow you to export keys. So you can be sure that the key will never lose the device, never left, leaves the device. And all the signatures are performed inside the module so you really don't need to see the key. You only need to ask the module to sign something for you. These kind of hardware key storage are quite advanced nowadays. They were used in chip cards for decades. They are used in the iPhone. They are one of the reasons why the FBI can't break the iPhone. But there's one note to make. It's important to have access control to this hardware key store because, for example, if you have a J-braked iPhone, then your J-braked iPhone can always pretend to be the app that's privileged to use the key. So root access always allows you to use the key. That was also exploited in the talk yesterday for the ledger wallet. Once you control the main CPU and once you boot your own firmware, you can use your own firmware to access the keys. You cannot read them, but you can use them. And there are some more downsides. If you have a bug in your hardware key module, you cannot fix it. There was a famous case last year. My work laptop was actually affected. There was an Infinion chip, I think, where they had a bad random number generator, and it turned out that chip was used in many products. It was used in the UB key device, I think, and it was also used in many HP laptops. It was also used for disk encryption by Windows. And the second downside is that the implementation cannot be validated by the user. If you have your own computer where you have some understanding what's running, what's not running, you can always look at the source code, compile it yourself, and you have some idea what the wallet is doing. If you have just a little token that you plug in by USB, then you don't actually know what it is doing. And that will be important later on for our tech. So some examples in servers you have HSMs. They are sometimes not really used to protect keys, but also to increase performance. If a server does a lot of encryption, it's better to have a hardware module, but those hardware modules typically also store keys. And then you have TPM chips in business laptops, and you have smartphones like the iPhone. Yes. So what are common problems and attacks that we've seen with wallet so far in the last years? So the most obvious attack is keys are stolen via network. Someone has a software wallet on its Windows machine. He installs some malware by accident by clicking on some email link. And the malware can steal the keys. So another kind of attack is if you have unsecured storage. For example, if you have a phone where you store your bitcoins and it's stolen and the phone is not encrypted and the wallet is not encrypted, people can steal the keys and steal your bitcoins. And then you have a third kind of attack where you have bad random numbers or predictable random numbers that happened a lot with bad wallets that were implemented in JavaScript. And then if you have a bad browser that's generating bad random numbers, the attacker can guess your random numbers, and this means that they can guess your keys or they can guess your non-sk, which is equivalent as we've seen. And one more interesting thing is that it's not only important that you keep your non-sk secret, it's also important that you use it only once. So if you use it twice, the attacker can also compute your private key even without knowing k. And one problem with bitcoin is all the signatures are published on the blockchain so attackers can just scan the blockchain and see if the number k is appearing for two times and then steal the bitcoins. That happens a lot. So if this happens to you, the bitcoins will probably be stolen in one hour because somebody is always scanning the blockchain and in the early days of bitcoin this attack also happened a lot. But now we want to talk about a more sophisticated kind of attack. Which is the backdoor in the random number generator, which is not just bad random numbers, but intentionally random numbers that can be predicted by an attacker. One famous example for a backdoor random number generator was the dual EC DRBG. So that's a standard by the US government for a random bit generator and there were some parameters in this algorithm that were selected by the US government but they couldn't explain why they selected them and there was no need for selecting them in a cryptographic point of view. So there was suspicion that they were selected in a certain way in order to predict random numbers and later when Edward Snowden had his files released there was some documentation that they actually did this. So what could an attacker do with a backdoor random number generator? So every time the user generates a signature, he needs to generate a nonxk and if this nonxk is generated by the backdoor random number generator then the attacker can later on... So the attacker wants to make the wallet of the victim to generate random number ks in a nonxk in a bad way and the attacker then later on scans all the transactions on the blockchain in order to find the victim's transactions and the victim's signatures and then uses his backdoor knowledge in order to compute the secret key and then after he has the secret key he can steal the bitcoins. So we will talk about something that's called kleptograms. Kleptograms were first introduced by Adam Young and Moti Jung in 1997. Back then it was based on the classical DSA but it's very similar to the elliptic curve DSA. Because we have some more formulas now I have a little description so all lowercase letters are numbers or capital letters are points on the elliptic curve or Greek letters are constants and this function r is a random number generator but this is not the backdoor random number generator but the real random number generator that we assume is strong so it has some properties for example that it's not possible to efficiently distinguish between numbers generated by this random number generator and actual random numbers so if we want to generate two numbers K1 and K2 which are used as nonces in these ECDSA signatures and we later want that the attacker can use the signatures to compute the private key then we can do a simple thing the first random number we can just pick randomly so we have the random number K1 and we can store K1 and we can output K1 to the wallet and the wallet will use K1 and r1 which is the point which is the point that's generated if you multiply the point G with K1 so K1 and r1 are used for the signature and r1 will be published on the blockchain with the signature and then in the second round we compute K2 as a random number derived from r1 and here we don't pick a new random number but we just use the pseudo random number generator and then we output K2 and r2 which is the point for the second signature so what can we do now? so this is the second round again so if the attacker now wants to know K2 it can just scan the blockchain for all values of r1 which are all published on the blockchain and then compute K2 by using the random number generator on r1 and then use it to compute a private key but there's two problems with this anyone can use the random number generator so anyone can compute this so the question is whether we can hide this attack so in order to hide the attack the attacker generates his own private key and public key the random number generator is the same as before and now we generate K1 and K2 again but in a slightly different way for K1 it's the same K1 is just generated as a random number and it is stored and used for the signature and then in the second round we pick a random bit t and then we compute the value z by using the formula that you see in the second line which is not important to understand the details of the formula but you need to the important thing is that the public key of the attacker A is used in this formula and then the second nonce K2 is computed using the random number generator on this value z and then this value K2 is used for the second signature so what happens now is because this is the second round again so what happens now is that the attacker can extract the second value by doing the following computations using his private key A there are two cases so there are two candidates for K2 and it's not clear which one is the right one but it's only like one bit different so you can just try both and one of them will be the right one and because no one else has the private key A no one else can do this computation and because you have the random number generator A you know that the value for the value for K2 is undistinguishable from real random numbers because we assume that the random number generator is strong so how do we use this attack on wallets so the attacker can do the following the attacker can use a popular wallet and backdoor it or can create his own wallet and spread it on the internet and wait for people to use it so then after that the attacker needs some patience the attacker needs to wait until the victim creates some transactions using the wallet and doing that the victims will publish the transactions on the blockchain so all the values that the attacker later wants to have are published on the blockchain and after a while the attacker can just scan the whole blockchain for signatures that are generated by the same key and then do the computation that we've seen in order to derive private keys so there's one more footnote to this the harvest does not have to actually be after the patient's face because even after the attacker steals bitcoins no one can detect the secret in the transaction so it will not disclose the attack so some properties of the attack are some limitations the attack can only be used if the user uses the same key twice to sign transactions but that's the usual typical use in bitcoin you always use your key several times sometimes you even use the same key in the same transaction twice so in some cases even one transaction can be enough to leak the private key and there's another footnote because there's some standard which is called BIP32 which is the standard for deriving many keys in bitcoin from one seed and it means that if the attacker manages to get one of your private keys it might be possible for the attacker to compute more private keys without doing more attacks this attack is independent from how bitcoin in general works it's independent from the consensus algorithm it's independent from mining it also applies to other blockchains that use similar signature schemes some use different curves some use EDDSA but the attack works for them as well and the backdoor also works with other protocols that don't have anything to do with cryptocurrency but in cryptocurrency it's easier because the parameters, the curve and the point and everything is already defined by the protocol you cannot use a different curve in bitcoin so the attacker always knows which curve you are using the attacker always knows which curve it has to use to hide the secret so what are the conclusions? what does it mean for users? so it means that keys can be leaked through the transactions you don't need a side channel, you don't need a second connection you don't need additional data and it cannot be detected even if you're looking at the transactions because the random number generator is used it's indistinguishable from normal random numbers so what does it mean for the user to do? it means the user should be careful not using untrusted wallets even if you use them offline they could still leak your keys and that means for some applications transparency might be more important than temporary resistance for example it might mean that it might be worth to have a software wallet that you know what it's doing in contrast to a hardware wallet which might protect the key from theft but you don't really know what it's doing when it's generating a signature so there are two microphones number two, number one if any questions please go to the microphones and if you leave the room don't do it in front of the camera that the stream if there is any question from the internet make a sign I see a microphone to your question Hi, you said that you could derive additional private keys if one of the keys leaks in bit 32 it's my understanding that that is not possible unless that's the master private key and you know the derivation scheme so could you elaborate what you meant? No, I was just talking about derived keys in general yeah it's not that simple so that's also why I didn't put it on the slides it depends on the scheme that you use for deriving the keys that's true but depending on the scheme you need to keep in mind that one key or one secret might be information that you use to derive other secrets microphone one I would just like to maybe have a piece of practical advice from you so given this consideration that you really need to know a bit of the code that is running a resource on the wallet can you speak up a little bit? yes do you hear better now? yes so do you think there will be a good alternative to have softer wallets running air-gapped but softer wallets instead of harder wallets because they are easier to audit or to see the source code of yeah the point is that it's better to have a wallet that you control, that you know what it's doing because even if you have an air-gap at some point you will put the transactions on the wallet to the network and if the secret is inside the transaction then the air-gap will not help you that's the point, yes and microphone two you have another question okay microphone one so if I understood you correctly this makes the strong assumption that you seed the random number generator on the second step with the point generator from the first step is this correct? yes and this is something which is like prescribed from the Bitcoin protocol or because I don't see any point in seeding it like this, you could seed it also differently no, the normal there are different ways to generate the non-scale so the original way that's part of the ECDSA government standard is to generate a random number so every time you would generate a random number but this malicious wallet is breaking the protocol it's not using the random number it's generating a number in a different way and then there are additional ideas for example this RFC 6979 that you also have on the slide now that's a scheme that generates deterministic nonces from the private key and the message you can generate deterministic nonces so this way you avoid bad random numbers but the malicious wallet it can always break the protocol it does not follow the protocol and it will use a different number do you have a second question at microphone 2, you? yes, sorry if this is a stupid question but could you maybe just summarize the attack vector which you have on people who use wallets in general so like what is the attack vector which permissions do you need to have in order, yeah and which permissions would you gain using your attack? the attacker in this case is the author of your wallet so if the attacker has not touched your wallet the source code or the firmware or the crypto chip that's used by the wallet manufacturer then you are safe thanks are there any questions from the internet? no? yeah, then a big applause for Stefan and keep your keys, bye