SLP103 Charles Guillemet – Hardware Wallet Security and Hacking at Donjon Ledger

Posted in: bitcoin Posted on

Charles Guillemet, Chief Security Officer of Ledger, and also leading Ledger Donjon, joins me to talk about Bitcoin hardware wallet hacking. We talk about the attacks possible, the cost of these attacks, and defence against these attacks. You won’t want to miss this episode!

Charles and Donjon Ledger links:

SLP Hardware Wallet Interview Series: 

Sponsor links:

Stephan Livera links:

Podcast Transcript by GiveBitcoin.io:

Stephan Livera: Charles, welcome to the show.

Charles: Hi Stephan. Thanks for having me. I’m very happy to be part of the show. I heard the first few episodes about hardware wallets. That was very interesting. Many contrasting opinions, and I’m going to try to share my views on this topic that I know quite well now.

Stephan Livera: I’m sure you do have a lot to share. So, let’s get a little bit of background on you, and how did you get into this world?

Charles: Sure. About me, well, first of all sorry for my strong accent. I’m French. During my education in France, I studied pure mathematics, computer science and cryptography. This is basically my technical background. I’ve been working in the security and hardware security, specifically industry from the beginning of my career a bit more than 10 years ago. At first, I worked in a small company in France which is called TEMPO. This company design secure element.

Charles: I started there as an intern and during my internship I breached the security of one of their circuit using side-channel attacks. So they decided to keep me for a few years, and I was in charge of the security of circuits. After that, I joined the French ITSEF, and ITSEF is information technology security evolution facility. Basically, this is a third-party security evaluation lab, which is officially accredited by the ANSSI in France.

Charles: ANSSI is the French security certification body. And to give an example with secure elements, the circuits are designed for critical applications such as banking and passports. But before putting those smart cards on the market, the vendors have to go through an evaluation and certification process. It lasts several months, and at the end of the evaluation when all the vulnerabilities which have been found by the ITSEF have been fixed or solved, the certification authority emits a security certificate. And this certificate grants the vendor to sell the secure element for critical application.

Charles: What makes a secure element, this is the security certification basically. I worked there for around four years and I was leading the lab. And I joined Ledger almost two years ago as the CSO. Basically, I’m responsible for the security of Ledger’s product. As you can imagine, this is a huge mission. I created the Donjon. The Donjon is our internal security evaluation lab. We are eight security experts coming from the security industry.

Charles: And day to day, we try to break our products because I think this is the only way to improve the security of our products. And when we found vulnerabilities or possible enhancement, we work tightly with the design team to improve our product. Our field of expertise are quite wide. We have experience in hardware security, software security and cryptography.

Stephan Livera: Fantastic. As I understand, Donjon Ledger doesn’t just hack Ledger products, it actually hacks even other hardware wallets as well, and there’s a bit of a process around working with that other hardware wallet vendor, around working with them on if they need to patch that vulnerability.

Charles: Yes, you’re correct. During the past two years, basically we spent most of our time studying our products. This is maybe 95% of our time. But we also spend some time to evaluate the security of our vendor’s product because we use HSM, for instance. We use secure elements, we use different circuit. So we also evaluate this product because as we construct a security product, not from scratch, but with basic blocks, we have to evaluate them. This is also part of our time. And also we spend some time to look at the security of the hardware wallet on the ecosystem, but not only hardware wallet, basically, security product.

Stephan Livera: Fascinating. And so can you give us a little bit of a background then? What are some of the basics of Bitcoin, hardware wallet, security? What does good look like?

Charles: Well, basically hardware wallet is a physical device to store your cryptocurrency keys and to perform transaction security. The basic threat model for a hardware wallet can be simplified into three main security features. The first one for me is the capability to generate high quality randomness. This is very important at least for generating your seed. If ever your wallet has bad quality random, it can have terrible consequences. It is very simple, but it is, very, very important.

Charles: The second main security features for me is probably the ability to prove genuineness of the device, from the hardware point of view, and also from the firmware point of view. The hardware wallet must have a secure mechanism for this, and this is at the utmost importance. The wallet should ensure secure display and secure inputs, for verifying and granting transaction. And these properties can only be granted if, the wallet has a genuineness and integrity mechanism.

Charles: Otherwise you will be vulnerable to supply chain attacks, evil maid attack. And basically if an attacker controls the code running on your hardware wallet, he basically controls your coin. So this is also a major security feature. And the third main security feature is also very basic. This is the confidentiality of your keys and the seed.

Charles: The key are generated and stored in the device and they must remain protected against remote attacks but also against physical attacks. That means that the hardware wallet must protect your keys even if your computer is compromised or even if the attacker just stole your device. For me, the threat model of a hardware wallet is very similar but not very easy to insure.

Stephan Livera: Thanks for the breakdown there. So maybe if we were to break some of those three components down, what does it take to, as you said, generate high quality entropy and randomness?

Charles: Hardware wallet are made with IC, with integrated circuit and inside the circuit there is often TRNG, which stands for true random number generator. And this is a specific part of electronics. There are different kinds of design. Often this is a free oscillators and which runs in parallel and they are sampled at a very specific timing. And this very tiny source of entropy is amplified with a different means. But this is often the kind of design.

Charles: And you can find this kind of circuit in a secure element, but also in a general purpose MCU. In the case of secure element, there is security evaluation which verifies the good quality of the randomness. And also there is a mathematical proof which is required for a security certification of the randomness.

Stephan Livera: How about now the second part where you were talking about proving the genuineness of the device. So as you’re saying there’s supply chain attacks, someone may have tampered with your device before it got to you, or the evil maid attack where let’s say you’re staying in a hotel and the maid takes your device and tampers with it or does something with it, how can a device be protected against that?

Charles: You can imagine there are several kind of mechanism, but basically what we would want is, a device which prevents an attacker to read the memory and write the memory. And if you have this basic property, you can put a secret key inside the circuit and you will request the circuit to prove that it actually holds this key. And if the secret cannot be tampered with or rewritten, the genuineness can be achieved using this kind of mechanism.

Stephan Livera: Excellent. And then I think this is probably one that everyone wants to know is, how difficult is it and what does it take to keep the confidentiality of your seed and your keys?

Charles: So in this case it really depends on your threat model and what you consider and what you don’t consider. But, in my threat model I consider remote attacks and physical attacks. For remote attacks you have to take care of all your inputs and to be sure they are properly taken into account. There is no buffer overflow, no stack overflow, no, how to say? You have to take care of all the software attacks basically. And if you also consider the physical attacks threat model, you have to consider the hardware attacks like side-channel attacks, [inaudible 00:10:18] attacks and basic hardware attacks basically.

Stephan Livera: Also, this is another common point for discussion within the hardware wallets world is open source versus closed source models on software and also the hardware. Can you tell us a little bit about how do you think about that?

Charles: This question is very interesting and I think this is quite fundamental. First of all, I’d like to say that I love the open source support. I’ve been working in the security industry for more than 10 years and the usual approach in this industry is to keep everything secret, especially in the hardware security industry. The main reason why they keep everything secret is they want to keep their technology advantage.

Charles: One of the thing which motivated me to join Ledger is the openness of the platform. Yes, we all would like to have all the code to view open source, but already the Nano S and the Nano X now are the only platform running on the secure element where you can load your own native code. From the hardware security industry perspective is already a huge gap. Creating the Donjon, we also decided to open source our attack tools, which is also purely disruptive from the hardware security perspective.

Charles: But my mission is about security. So let’s discuss this question from a security perspective. What we want from hardware wallet is clearly security. First open source allows auditability of your device, but it does not guarantee that relevant people will audit your device. In the case of the Nano, the circuit and the devices have been evaluated by us, but also by several relevant security evolution lab.

Charles: Second, if you decide to make your own open source hardware wallet, you will have no choice but using the general purpose MCU. And from my experience I can say something. The data from a general purpose MCU can be extracted very easily. So it removes two main security features, in the threat model, the possibilities should verify the genuineness of the device and also the confidentiality of your secret key against an attacker with the physical access.

Charles: Finally I’d like to go a bit more into the details of open source hardware wallets. What is actually open source and what is not, because we often think that everything is open source on open source hardware wallet and it’s not clearly the case. So if we look at hardware wallet schematically, let’s consider it’s a chip with a chip with its firmware. We have several layers. The lowest level will be the chip design. Then we’ll have the chip implementation and manufacturing.

Charles: And if we go to the software part, we’ll have the low level software, which is designed by the IC vendor. There is often bootloaders, some boot primitive drivers, this kind of code. And if we stop here, the three layers are closed source and kept secret by the IC vendors. This is the case for the secure element, but this is also the case for general purpose MCU.

Charles: In the case of the IC vendors, in the case of the secure element, this part are designed for security and audited. But in the case of general purpose MCU, they are not audited by anyone basically. If we go a bit higher in the layers, we get the data sheet or the IC. Here is the main difference. The secure element data sheet is accessible only under NDA, maybe because it explains all the proprietary counter measure of the IC, how to configure them and so on.

Charles: And in the case of general purpose MCU, they are public but there are no counter measure basically in the general purpose MCU. Then we arrive to the actual firmware. Open source hardware wallets have mostly a monolithic open source firmware and anyone can audit it. But on the other side, the firmwares of the Nano S and Nano X are divided in two parts. You have the operating system in one side, which is closed source because it chooses the proprietary countermeasure of the IC.

Charles: But this firmware is constantly audited by the Donjon, and it has also been audited and certified by a third party laboratory. On the other side, the application running on top of this operating system like Bitcoin application , Ethereum, our password manager or SSH application, are open source. Sorry for the long explanation. I just wanted to outline that in fact an open source hardware wallet, there is a small part of the critical layers which are actually open source.

Charles: Also our goal is to open source the most part of our operating system. So probably in the next month we’ll open source most of our operating system, keeping close to us only the low level part of the OS, which use the proprietary part of the circuit. So I think people defending open source in this particular case are a bit religious. Finally, what we would like is an open source secure element and it will solve all the question, but this is a complete other story.

Stephan Livera: Right. So if I were to summarize that then there are essentially, there are different layers of this stack if you will. So you’ve got the firmware, you mentioned the data sheet and the IC, which is at a low level. And as I understand you then, there are certain components of that IC that are under NDA, nondisclosure agreement with the creator of that product. And the reason being there are certain proprietary counter measures that they have put in place with that IC.

Stephan Livera: And then the reason if you go back up that stack to the OS, the operating system level, there are certain components of that OS that are closed source because they interact back down with that proprietary counter-measure part within the IC. Would that be a correct summary then?

Charles: This is exactly why our operating system is close to us for this only reason. The NDA only concerns, they have very, proprietary counter measure which are implemented into the secure element.

Stephan Livera: Got it. Okay. I’d be really interested to just talk a little bit about some of the pitfalls and some of the past problems and ways that Bitcoin hardware wallets have been hacked. Could you give us just an overview on what are some of the ways that people try to find vulnerabilities? So as you mentioned there’s side-channel attacks, there might be a problem with the cryptography, it might be insufficient entropy or randomness. Can you outline some of those for us?

Charles: This is the main way to attack hardware wallet basically. And when I joined Ledger, I’ve been explained that, I didn’t know very well this eco system and I’ve been explained that some competitors used general purpose MCU for, storing their seed. And for me that was, I was coming from the secure element industry, and for me that was complete nonsense. I was clearly aware that this kind of MCU were clearly vulnerable for too many different attacks.

Charles: Then I created Donjon. Donjon our security evaluation lab. And during our creation we built some tools and we implemented attack test bench and so on. And, we spent most of our time to evaluate our product, but we also spent some time to evaluate others. So we either look to the other wallets in the market, mostly by scientific interest at first. But when we found all those vulnerabilities, we felt responsible to help the other vendors.

Stephan Livera: Got it. It might be good to break down some of those ideas. I think one of them, and it comes to this asymmetry, the idea of the cost to attack versus the cost of defense. And as I understand you have to try to make it so that the cost to defend is cheaper than the cost to attack. How does that play into what you do with Ledger and the devices?

Charles: The attack and defense is a cat and mouse game basically. The thing is that if you don’t invest in the defense, the attacker wins at the end, at some point. And this is precisely why we, I mean, the Bitcoin community, have to continue to invest our time and resources to improve the security in the ecosystem. And I’m pretty confident that we’ll enable to prevent all these acts. But again, the cost of the defense it is not new.

Charles: We have to spend a lot of time and a lot of money to improve the bar for security in this industry. And the cost of the attack it really depends what you are attacking. If the stakes are high, the attacker will spend a lot of money to break systems and they will succeed. Basically this is, if you win more money breaking the system that it cost you to break it, attackers will do it.

Stephan Livera: So let’s try and break down some of the typical ways that you might analyze this. So as you mentioned, this side-channel attacks as I understand, there are different types of those side channels that you may look at. So there’s, as I understand there’s power looking at the variation or the emanation in that power, there’s EM radiation, visual, acoustic. Can you help explain what are some of those and how does it work?

Charles: Side-channel attack. So we love this kind of attacks in the Donjon and we have side-channel attack test bench. The idea of side-channel attacks is to monitor a physical measurement of the circuit joint when it runs some code. You can monitor all the power consumption, you can monitor all the electromagnetic emanation, you can monitor all the sound, you can monitor a lot of thing. What is the most efficient is often electro magnetic emanation or power consumption.

Charles: So what you will do as an attacker is you will use the hardware wallet for instance, and during its computation you will record the power consumption. You will get a lot of traces and you will try to find a corelation between this set of traces and the data which is handled inside the hardware wallet. And if there is such a correlation, there are plenty of techniques, which allows the attacker to retrieve this data.

Charles: And if this data is a secret key, then you will succeed to mount an attack. We spent some time on the Trezor One implementation of PIN verification, and what we proved is as an attacker, if I steal your device, I will try a few PIN values and record the power consumption of the device during the PIN comparison, and only a few power consumption traces are enough to guess the correct value of the PIN. And then, thus I will be able to access to your funds. We did a responsible disclosure on this one with Trezor after a few months. And I think their new implementation is clearly harder to break, regarding side-channel attacks.

Stephan Livera: And so in that example with the PIN as I understand, there are different countermeasures that a manufacturer may put into place. So one example is, I’ve heard of exponential decay. So every time you try the pin and you fail, it makes it even longer before you can try it again. What are your thoughts on that versus let’s say, having just a hard limit, this is the maximum number of times you may try to brute force the pin, otherwise it bricks the device?

Charles: For instance, in the case of Trezor, we have 15 tries, I think or 15 or 16, and this is already a lot from side-channel perspective because you can record the 15 traces and then try with those traces compute the correlation, try to retrieve the code value of the pin and then use it on your 16 trial.

Charles: So 15 is already a lot, but there are other countermeasure, the idea is to ensure that the power consumption of the device does not depend only on the correct value of the pin, but on other random things for instance. This is one kind of counter measure that you can put in place. And in secure element there are built in counter measure against side-channel attacks, which put a lot of noise on the power consumption, this kind of or timing dis-synchronization, this kind of countermeasure.

Stephan Livera: So I understand there’s this concept of profiling. So you might, for example, let’s say, you know a certain device is a commonly used hardware wallet and you may buy a copy of that hardware wallet. It’s openly available. And you may then use that to try to understand from that oscillogram, okay, what value is it computing at the time that it’s this level. And is that then, you’re using that profile to then if you’re trying to do an attack obviously, you’re then comparing it back against the profile that you created earlier. Is that roughly how, one way you do it?

Charles: You’re completely correct, and this very case this is exactly what we did. We have Trezor One for which we will try a lot of different pin and we reocrd a lot of traces and we will do a profiling as you just explained. Exactly as in computer vision, we will train an AI to recognize not dogs from a cat on picture, but digit equals one or equal nine on power traces. But this is basically exactly the same thing.

Charles: We will train a machine learning algorithm to recognize your digits on the power consumption. So we do that on the device A for which we know the current value of the pin. And on the device that we will steal from the victim, we will just record a few traces and we will ask to our machine learning algorithm what is the correct value of the PIN. And the machine learning algorithm will answer us the most likely value for this traces, for this one, for this one. And when you combine the traces, you’re able to guess the correct value of the pin. On this very example we were able to guess the correct value of the PIN within four traces. So you four wrong value of the PIN and the fifth is the correct one.

Stephan Livera: That’s really fascinating. And another concept I saw just from doing some reading is this concept of DPA. Is it differential power analysis is it? What’s a DPA? What is a DPA attack?

Charles: You studied the topic. DPA attack is the first one which has been discovered maybe in 1998, and in this case, this is non profiled side channel attacks. That means that you don’t do the first step which consists in understanding how the device is running. But to summarize, this is a statistical process which allows an attacker to distinguish what would be the value of a specific bit of the key.

Stephan Livera: I see. And from a cryptographic point of view, is there anything there that changes in terms of which cryptocurrency is being hacked or is it more ultimately about trying to get at what is the underlying seed within that device?

Charles: This is a good question because, on hardware wallet there is the very moment when you are computing either your public key or you’re computing a transaction. And at this very moment you will use your secret key. And if you are able to measure the power consumption of the device at this very moment, it can give you a lot of information about the key. And this algorithm will depend on the cryptocurrency.

Charles: For instance, if you’re using Monero your secure element implementation will be implemented using Ed25519. And if you’re using Bitcoin, you will use secp256 curves. And in both cases that won’t be the same algorithm. And so there are some caveats in the implementation which will change the properties of the power consumption and that will ease the attacker to extract the key. But in the threat model of hardware wallets, the attacker needs to have the value of the pin to make a transaction

Charles: So this is quite unlikely that an attacker would be able to monitor all the power consumption of your device when you are able to make a transaction. But we also studied the scalar multiplication of Trezor and we proved that it was possible to retrieve the secret value of your Bitcoin key when it computes the public key from your private key. But this is not that important because, if the attacker is able to monitor this power consumption, that means that he has already your pin value. So, that was more for a scientific interest than real attacks.

Stephan Livera: Okay. I see. Another concept that I’ve heard of, and this may, I don’t know. Let me know if this is not a relevant kind of attack or way that can be done. But there’s this concept of fuzz testing. And so as I understand, when you do fuzz testing, you’re trying to, let’s say you’ve got a certain field and you start inputting data that is not meant to go into that field to see if you can get a different response out of the computer. Is there any sort of similar parallel here with hardware wallets and fuzz testing?

Charles: Yes definitely, because hardware wallet there are interfaces, I mean, software interfaces. When you want to make a transaction you will have to input your transaction to the device for USB and some that. There are some interfaces, not that much because, this is made for this hardware wallet, few interfaces for security. But as soon as there are interfaces, you have to ensure that the inputs are correctly used and there is no buffer overflow and so on.

Charles: This kind of properties can be checked using static analysis. This is a good point. It can be checked also by auditing the code. But it can be difficult to figure out in all the code if there is no buffer overflow for instance. So to be more efficient and to have more confidence there is no buffer overflow. We implement fuzzing. And fuzzing what you do is quite naive. You will use your computer to input a lot of different inputs, random inputs.

Charles: You will guide the fuzzer in order that the random is a bit guided that you want to test the same thing a lot of times. So you will guide the random in order to be more efficient. And the fuzzer will try to monitor any behavior which are not planned by the designer. So as soon as you have a crash, it might be because there is a buffer overflow, but a small bug which can turn into a vulnerability. Because vulnerability basically this is a bug, which can be exploited to do something, to do an attack. And the fuzzing process will help you to find a bug just randomly.

Stephan Livera: I see. And I guess in terms of these attacks on Ledger devices, were Ledger devices sort of hardened against these kinds of attacks or what’s the thought there?

Charles: So what we do during the design process, we try to do the most static analysis possible. The Donjon is auditing the code day to day. We find some vulnerabilities and announcements on lots of things that you can improve the security. And also we have emulator in order to make fuzzing more efficiently. And we also do fuzzing and also we do hardware attacks to be sure that our implementation is secure against an attacker with a physical access to your device.

Stephan Livera: Got it. And from a code auditing point of view, are you looking there at things like making sure that let’s say some cryptographic standard has been correctly implemented and that there hasn’t been a mistake made in the random number generation? Is that the sort of thing that you’re looking for when you’re doing code audit?

Charles: Yes. This is part of audit, and this is the most important part of the audit. Auditing the crypto library, being sure that if you, it’s not vulnerable to invalid curve attack, invalid point attack. That the randomness is correctly used, there was no bias and all this kind of vulnerability, which can be found in crypto library.

Stephan Livera: Fascinating. Okay. Can you talk us through a little bit around what does a responsible disclosure process look like? So you found the problem. Now you take that either to, if it’s internal, you take that to your internal team or to another hardware wallet team. And as I understand, there’s obviously some interesting ethical questions around this because obviously you have to, there’s a question of how quickly is the other party going to respond and try to patch that vulnerability because in that time when it’s not patched, all the users are vulnerable. Right?

Charles: As I mentioned before, we come from an industry where vulnerability stay secret for all players. At Ledger and in the Bitcoin industry, there is this transparency policy, but it does not mean we have to directly become black hat or [inaudible 00:34:38]. I mean, in the Donjon we are a security researcher and we are more interested by the science aspect of the thing rather than the fame or the money.

Charles: So in my perspective, this industry suffers a lot from the fear of the security breaches. So acting ethically is the least we can do. So for the vulnerability we found we brought them directly to the vendor and ask them if they were okay that we disclosed them publicly at some point. In most of the case we agreed with them on a timeframe. And so in a few cases the vendor did not want us to disclose them. We decided not to disclose them simply.

Charles: And for instance if we are talking about the worst I would say vulnerability we found on Trezor which is the seed extraction technique, basically what we were able is to, if you have access, physical access to a Trezor One or Trezor T or KeepKey device, we figure out an attack, which allows an attacker to extract the seed value from the circuit. The thing is, this vulnerability can not be patched.

Charles: There is no way to fix it, and that means, any firmware upgrade won’t allow to plug the vulnerability. So what we decided to do is to disclose it to the vendor in order to, they figured out something to mitigate the vulnerability. But as the vulnerability is not fixable, we decided to not publish how we do. So in this case, I think this is the most responsible way to disclose this vulnerability.

Charles: In this case, users are aware of the attack, so they can choose a way to mitigate it. But real attackers on the field won’t to be able to use it for bad things I would say. So it avoids expectation while it makes the users aware of the vulnerability. But yes, responsible disclosure are very important. We want to make sure that the user of the ecosystem stay safe.

Stephan Livera: Got it. I’m also curious as you came from the more of the secure element world, and as I understand in say banking, they have HSM, hardware security modules. How does the current state of Bitcoin and Bitcoin hardware wallets compare against, say, banking HSM? Do you have a sense of that?

Charles: It’s difficult to compare hardware wallet to HSM. This is the different things. HSM is more basic block for building more complex application, while an HSM is already, hardware wallet is already an application. This is very precise. But, you are talking about HSM in the past months. Us we use HSM for the Ledger Vault for instance. But also for our [inaudible 00:37:59] in order to be sure they are genuine. There is mutual authentication within HSM.

Charles: So we studied, precisely how HSM works and we did a lot of reverse engineering in order to understand everything, a lot of fuzzing, and in this very case we found a few vulnerabilities which are quite critical, and we work tightly with the vendors to help them to patch the vulnerability. This process last maybe one year. We found them last year I guess, and we worked with them in the long process. And when everything has been patched, I think it was the case in the end of 2018.

Charles: We agreed with them to publish, and they decided they did not want to be mentioned. So we decided to publish anonymously the vulnerability we found and we hope that will increase the knowledge of HSM study, security study and improve the security of the HSM ecosystem. And we published them at SSTIC, which is a French security conference and at Black Hat a few days ago.

Stephan Livera: Great. I’m also really interested to ask you around, so obviously you work for Ledger. So I appreciate that. But, what I’m trying to get at here is the question of, what are your thoughts on using specific hardware devices that let’s say an outsider, if they see it and they know you’re using that device, then they know it’s probably got Bitcoin on it, compared to this idea of using nonspecific hardware? And so one example, if you know Trace Mayer, he talks about this idea of using the Purism laptop and the Glacier protocol. How do you compare those different methods and what’s your thoughts on that?

Charles: I know the arguments on non specific hardware, which should be air gapped and so on. First of all, it does not solve the physical access problem. If you use a standard laptop, I mean, if the attacker has a physical access, you lose your funds. So also implementing your own wallet with a laptop is not an easy task. I mean, there are a lot of companies on the market which spend a significant time and money and effort to do hardware wallet or wallets.

Charles: And as you can see it’s not easy. So, if you want to build your own wallet, I would say, you will have some difficulties to make it well. Nevertheless, I think it’s a good idea to implement your own wallet because, it will help you to understand Bitcoin and how it works and so on. I think it’s a good idea, but I wouldn’t recommend the non very advanced user to do that because there are plenty of mistakes that you can do in the process.

Stephan Livera: I see. And so I guess that also ties into the next question around the future directions with hardware wallets. What’s your thoughts on what they will look like and what sort of hardware would they use?

Charles: It’s difficult to predict the future. And at Ledger it’s not exactly my scope. This is more the mission of our CTO, Nicolas Bacca, you probably know. And nevertheless, we want to be part of the mass adoption. This is part of our mission at Ledger. According to me, the mass adoption will only be possible if the user experience is as smooth as possible. For instance, we would like to enable payments in Bitcoin, with the user experience similar to contactless banking cards. I mean, this is the kind of thing we would like to do. Those are big challenges, the security of course, and we’ll have to constantly raise the bar for security. We can’t lose this cat and mouse game.

Stephan Livera: That makes total sense to me. In terms of, sorry. There was one other question I was keen to ask about, and this is around verification of change addresses and the other multi signature devices in that set. So let’s start with the change address one. So, it’s my understanding that with some of the Ledger devices, potentially in the past, potentially even now, I’m not sure there was a difficulty for the user to make sure, yes, my device holds the private key for this change address. Can you speak to that?

Charles: I think you are referring multi sig setup, right?

Stephan Livera: Yes. I think it’s in the case of a multi signature set up.

Charles: So about multi sig first of all, I’d like to say that I love cryptography. I’m fond of the schemes. But multi sig is a wide field. There are secure MPC with the recent threshold signatures paper and the older one like Schnorr signature that we will have in Bitcoin soon, I hope so. But here, I think you’re more talking about script based multi sig used in [inaudible 00:43:15] or most likely PSBT for Bitcoin.

Charles: So just, I heard this one just one saying that multi sig is the ultimate solution to all of our programs. In particular, I heard Michael with who you discuss recently. Well, okay, multi signature schemes need to be reviewed by scientific community and the implementation is also of concern. This is the first thing I would like to say. The main problem is that a tiny mistake that can lead to massive loss and at scale, and this is very concerning to me.

Charles: And when I saw some companies were basing all their security on brand new MPC scientific article which was not even been reviewed by the scientific community. I think it’s a bit irresponsible. And I don’t even talk about implementation issues. There are already examples of loss in Ethereum and others. But talking more precisely about a PSBT on hardware wallet set up, which was your initial question, if I understood correctly.

Charles: Again, I think multi signature adds a complexity and complexity is the enemy of security. So if you really want to use multi signature using hardware wallet, you have to be aware of what you do and what are the threats. It’s not the magic thing that Michael was talking about from my perspective. So, talking about our implementation, we are currently working on a full redesign of the Bitcoin app, and we’d like to include additional validation based on descriptors and pre-validated templates. And I think that will improve the UX and the security as well.

Charles: But waiting this, I’d like to give some recommendations for the advanced user who would like to use a multi sig setup with PSBT and the Nano devices. First of all, the multi signature addresses must be validated using an external channel. The main problem is that there was no straightforward way to validate the public keys that you’re combining are legitimate because, they are not in your wallet. So it’s already a problem.

Charles: So validating the addresses must be done on using an external channel. Another channel basically. We also recommand to validate change addresses through an external channel. The change question is not simple because it depends on template and only validating the addresses on the device is not sufficient. It can work only if all parties comply with the BIP45 and all the standards, which is not sure basically.

Charles: I want to get into all those details. I don’t want to lose people hearing us. But what I want to highlight here is that the security of PSBT multi sig scheme is not straightforward, and I won’t recommend you to use it if you don’t know exactly what you are doing. And in all case, I suggest to start using it on test net and to experiment and understand everything. That would be my advices about multi sig and PSBT set up.

Stephan Livera: Great. Thank you for that. I guess while we’ve spoken about some of the ways in which hardware wallets can get hacked and so on, do you have any advice for the listeners out there, let’s say they’re an individual, they’re using maybe a single signature, a single hardware wallet scenario, what are some tips and things that they should keep in their mind?

Charles: Sure. Let me recall the basic security advices, because you’re looking at our customer support, I would say that they are not well understood by everyone. The first one will be to operate your wallet in a secure environment, especially when you are generating your own seed. Don’t do that on the street. Do that at home, in a quiet place, take your time and so on. It’s very important.

Charles: Don’t forget to backup your seed. We have too much customers who lost their funds because of this, and this is a very dumb mistake. And back up your seed securely. I mean, don’t take picture of it, don’t save it online on your online computer. Don’t send it to you by email. It happens so much time so that there are too much stories of people losing their seed just because of this. And the last very simple advice is, trust only the display of your Nano, don’t trust what is written on your computer because your computer is probably malware. You can also use your passphrase for a plausible deniability for instance. But if you do that, don’t lose it. That was the very basics, but I think it’s important to recall them.

Stephan Livera: I think that’s, totally great reminders for my listeners. How about, do you have any advice for, let’s say people who are operating in maybe they’re more of a family scenario or maybe they’re an institution. Do you have any suggestions on security tips for them?

Charles: Families and institutions are not exactly the same, but for institutional storage, I think the best option on the market so far is the Ledger Vault. I will do some advertising. Sorry for this. But Ledger Vault is very interesting solution from a technical perspective. This is what interest me. But also, in the case of institutional storage, it allows the organization to manage the funds according to their requirements.

Charles: The Ledger Vault brings a very high level of security. The security of defense relies on two main pillars, from one side, the hardware security model, which we audited extensively, and from the other side on the personal security device, the PSD. It allows the customers to define sets of rules and quorums for managing the fence. For instance, there is administrators and they can decide that for specific quorum, this quorum can only make a transaction of an amount of X Bitcoin during a specific period.

Charles: And if they want to do that, they will have to make three signatures out of five using the PSD. But what is flexible, is that they can decide exactly what all their requirements, what is their governance, basically. It’s very flexible and while being very secure since it relies on the secure ware, the PSD and the HSM, but also on cryptography, there is a lot of cryptography between the PSD and the hardware security model, and that’s it basically. And if you are an advanced user and you have a lot of currency, you can have a look to a multi sig setup. But again, I won’t recommend to simple user. I mean, if you’re not an advanced user, I don’t recommend you to go to this set up.

Stephan Livera: Got it. I see. With the vault, actually, I don’t know a huge amount about it. I had a quick look on the website. So understand, then you were mentioning the PSD devices. But that’s not like multi signature though, right? Like it’s more like, they’re calling back to the vault, which is being run out of, is it a web interface for that? What is that?

Charles: So it is more a multi-authorization set up than a multi sig. We don’t do multi sig on chain using the PSD. What we do is a governance layer which allows multi-authorization using the PSD. Each PSD has a secret key and so on. And the HSM layer will verify that we indeed have a three out of five people validating this transaction. What is very interesting in this setup is that you can use the multi-authorization disregarding the cryptocurrency you use. You don’t have to have a script or to have a Schnorr signature. It will work on the Bitcoin exactly the same way as it will work on Ethereum and Monero whatever cryptocurrency you will have.

Stephan Livera: I see. So it’s not using multi signature, it’s more like the authentication into Ledger’s Vault and then the volt is the one that’s enforcing the policy in terms of three out of five quorum or whatever the quorum that you set, right?

Charles: Exactly. You can see it as a multi sig setup because when you’re talking about authentication, there is a signature, provided by each PSD. But at the end that this is not on chain multi signature. This is the main difference. Yes.

Stephan Livera: And so those PSDs, are they internet connected or are they sort of like a hardware wallet but they’re just a specific device for the purpose only of this Ledger Vault?

Charles: They are based on the Ledger Blue hardware wallet. So this is the same platform, but this is very specialized for vault applications. You cannot install the Bitcoin app for instance. You just have one app which is the Ledger Vault app, and this is the Ledger Blue basically. Yes.

Stephan Livera: Got it. Okay, great. Well, thanks for that information. I guess lastly, where can the listeners find you and where can they find Donjon Ledger?

Charles: You can follow me on Twitter. You have just to search for Charles Guillemet, or you can follow the Donjon. Our Twitter handle is Donjon Ledger, and we have also a blog post, a blog, which is ledger-donjon.github.io.

Stephan Livera: Fantastic. I’ll include the links in the show notes for the listeners. But, that was a really great discussion. Thank you very much for joining me, Charles.

Charles: Thank you very much. Thanks for having me today. Bye-bye.

Leave a Reply