Pavol Rusnak aka Stick, CTO of SatoshiLabs (the company behind Trezor) joins me in this episode to talk about his journey creating the world’s first bitcoin hardware wallet. We talk about:

  • Making the world’s first bitcoin hardware wallet
  • SLIP39 and Shamir’s secret sharing
  • Multi signature support
  • Airgapping
  • Privacy
  • Bitcoin-only firmware
  • FIDO2 authentication

Pavol Rusnak and Trezor links:

Sponsor links:

Stephan Livera links:

Podcast Transcript by GiveBitcoin.io:

Stephan Livera: Pavol, welcome to the show.

Pavol Rusnak: Hello, hello.

Stephan Livera: Looks, thanks for joining me in the Hardware Wallet interview series and obviously, I had to get someone from Trezor on. It was great to have you to join me. Let’s start with a little bit on the background on you. Let’s hear a little bit on how you got into bitcoin and a little bit of your history with SatoshiLabs.

Pavol Rusnak: Yeah, all right. I was born on Slovakia but since 2002, I am living in Prague. I moved there to study computer science at Charles University and even during the studies, I already started to work at a company called SUSE Linux which is one of the biggest commercial Linux vendors and that got me into the world of open source because everything we did back then was open source and I was collaborating a lot with people not only inside of our company but also with the competitors like Red Hat but we got our own common goal to be a good Linux ecosystem basically and during that time, I think it was like 2012 or even a little bit before that, we started a hackerspace in Prague called Brmlab and somehow, there was a conference in 2011 called Bitcoin Conference organized by Amir Taaki and he came to the hackerspace telling us about Bitcoins and how we should attend the conference. He was pretty nice and that’s where I think maybe, not for the first time but maybe for the first time I met Slush and we were discussing a lot about hardware aspects of bitcoin and basically it was mostly about mining but then we were also talking about the security of the coins.

Pavol Rusnak: Basically it’s a huge problem to have private keys stored on your computer and coincidentally, there was a talk at that particular 2011 conference by Clemens Cap. He was a German professor and he was presenting his idea of his students of hardware wallet and they were building that on Arduino and we had a lot of discussion with Slush that it’s probably not enough power because it would take maybe one or two minutes to sign a transaction and that’s not very usable and we played with the idea a little bit but not very much because I still was working at my previous company and Slush was very busy with his Slush Pool back then.

Pavol Rusnak: One year later, in 2012, there was a Bitcoin Conference in London and there was absolutely no mention of any hardware wallet effort and that was the tipping point where we basically decided we should start doing this because nobody is taking care of that really crucial and missing part of the ecosystem and we started to tinker a little bit at the Brmlab hackerspace and playing with the ideas, how it should work and both me and Slush, we were sofware engineers. We basically had really no idea what we were doing at the time but it was so fun and we learned a lot and somehow the ecosystem also changed and from the original idea where we wanted to produce 100 devices for our friends and from the people we knew from the bitcoin talk, the ecosystem got bigger and it was 2014 when Alena joined us and persuaded us basically that we should really start a company and do that in a really big batch. That was how SatoshiLabs and Trezor was started. In 2013, there was an official company started back then.

Stephan Livera: Look, obviously this is the world’s first bitcoin hardware wallet. What were some of the challenges and the trials that you faced along the way when you were building that first device, the Trezor One?

Pavol Rusnak: Like I mentioned, we had really no very good idea what we were doing back at the time. Funnily enough, Trezor was my first PCB every created and it seems it somehow worked fine. Obviously there were a lot of other iterations later and in the beginning, what seemed to be the biggest problem, it turned out to be really easy, I mean the electronics and something that we have never thought might be a problem turned out to be a big problem. We had electronics ready in maybe 2013 but then we had a really huge problem with getting these electronics into either a metal casing or plastic casing, which was kind of crucial because we wanted to delivery a full product, not just an electronics board. With the metal casing, we had a problem that the buttons were just too small and at one point during the process, you need to put these aluminum parts into an acid, basically, to create this protective coating on top and that’s a very delicate process because if you don’t have this aluminum in acid for a long time, the protective coat will not get created but if you keep that there for a long time, the acid will start to dissolve the parts a little bit.

Pavol Rusnak: The problem with buttons was they were just too small. If we kept them in acid for like a minute, the protective layer was not there yet, but if it was like one minute and 15 seconds, the buttons were just completely dissolved suddenly. There was a really delicate timing and finally, we were able to figure it out and moved on to creating a mold for injection molding and this turned out to be also a really big problem because of, again, the small buttons and some other areas, which in reality we had to postpone the launch of the plastic version for a couple of months, maybe half a year even. This just never worked out with the original producer and finally, I think it was the middle of 2014, we were able to find a company in the Czech Republic, which was able to produce both electronics and both plastic cases for Trezor and we have this relationship since back then and it’s a really healthy relationship because they can guarantee the electronics will fit into the plastics. That’s how we solved the problem, basically, to find a good partner to help this with us.

Pavol Rusnak: Another problem, which turned out to be unexpected a little bit was the original idea is that we will produce just the hardware and the software wallet ecosystems will integrate the Trezor but there were different priorities for the software wallet developers so it turned out that we need to come up with our own web wallet so our users can actually use Trezor. Luckily, sometime later, all the software wallets started integrating Trezor. One of the best integrations now is available on Electrum and we are happy about it because we want to be a part of the ecosystem. We don’t want to tell people how to use Trezor. I’m really happy that there are other options. This was the original idea but for a couple of years, it wasn’t possible. These two were the biggest challenges, manufacturing problem and the integration of Trezor into other parts of ecosystem.

Stephan Livera: That’s fascinating to hear from your point of view. I think from my point of view, for a long time, it’s been my typical recommendation for newbies that if you’re a newbie and you need to get your coins off the exchange, I would normally tell them, “Just get a Trezor.” It’s one of the well known products that you can give to a newbie and that person can pretty much just plug it in and it’s mostly a nice web wallet interface for them. Although obviously there are some criticisms but we might get to that later but I think on the whole, it should be recognized that this is the first bitcoin wallet and it’s, to this day, better than people leaving it on an exchange. Let’s talk through some of the features then of the Trezor, because you’ve got two main products, right?

Pavol Rusnak: Right.

Stephan Livera: There is the Trezor One and then the Trezor Model T. Do you want to just talk through just at a high level, what are some of the main features of the different devices?

Pavol Rusnak: Like you said, Trezor One was the first hardware wallet and it’s also being used as a benchmark for any other upcoming wallet and people are saying, “Yeah, this feature is better than Trezor,” or, “This feature is worse than Trezor has.” The original idea is just very easy. We just want to have buttons and a display. The display being the crucial part because we wanted to give a full verification available to user so they could check not only the amounts they are sending but also where the coins are being sent to. This original design is very simplistic. It’s minimalistic. It’s very durable, even though it’s made from plastic but that has another advantage. It’s very light. So if you drop it for, I don’t know, five meters, it will survive because even if it’s made of plastic, it will survive such fall.

Pavol Rusnak: We plan to keep selling them because like you said, they are the go-to solution for people. We still think it’s a very good product. Another model, like you said, is a Model T. It was released in February last year, 2018. It’s an evolution of the idea where we replace the monochromatic, means black and white, display with colorful hi-res display and we replace the buttons with a touch screen. It provides much better user experience for people that need to use Trezor every day or if you want to perform more complex operations.

Pavol Rusnak: If you are sending coins in one transaction to multiple people, it’s much easier to check the correctness of the transaction on a bigger display and we consider that as like a flagship of our products and Trezor One is like the entry level. That said, most of the core features, that means management or bitcoin related features are also available on Trezor One. If you don’t care about expert features, Trezor One is perfect for you. Also Model T has SD card, which allows us to perform some of the actions that are just not possible on Trezor One. We might get up to that later but one of these is basically, we can perform bootloader upgrade or firmware upgrade via SD card. If the device is breaked for whatever reason or if you just don’t want to connect the device to the computer to perform the update, you could do that via SD card.

Stephan Livera: Let’s start with multi-signature. I know that’s something that is… The focus is coming onto that a little bit now and there’s a little bit more desire for multi-signature. I know currently it is possible to do with Electrum, that you can run a multi-sig out of that and use Trezor devices as part of your multi-sig set. I know also that the Trezor has… basically it displays some additional details about that transaction when you’re performing the multi-signature. Did you want to just outline some of the thoughts around that?

Pavol Rusnak: Yeah. It’s funny to hear you say that multi-sig is getting traction now because that’s obviously true but also it was getting traction back in 2015. There are not only the hype cycles for the price of the bitcoin but also for various features. Back in 2015, we were discussing how to introduce the multi-sig in Trezor and we were spending a lot of time with trying to come up with great user experience and we discussed how these multi-sig parties should be coordinated together and we were experimenting with all crazy synchronizing mechanisms via [inaudible 00:15:15] or WebRTC so you could synchronize these parties over the browser but then we realized, we are basically inventing…

Pavol Rusnak: It seemed to us like we were inventing the whole new Internet, so we postponed that feature and decided just to finish the multi-sig implementation inside of the device and see how the feature evolves. It’s nice to see that now there is another traction and basically we have all these multi-sig features in the hardware wallets and now we are trying to figure out how to make this user experience worthwhile for users. One of the problems we had back then in 2015 was that there was not a very easy way how to prove that the multi-sig address is indeed being used. If a software wallet shows you, this is the multi-sig address, you can use it but still you don’t have approved that the connected device is indeed involved in that multi-sig scheme…

Pavol Rusnak: We came up with a mechanism that basically a software wallet can tell the device, please show me this multi-sig address, and there is proof that you are indeed involved in that multi-sig setup and the hardware wallet or Trezor in that case, will look at this proof and only if it is able to reconstruct that proof, it will show the multi-sig address on the display. That way, you can be really sure that the address you see in the software wallet and at the same time, if you see the address on Trezor, you can be sure that particular Trezor is indeed involved in that multi-sig scheme.

Pavol Rusnak: This can be done best in Electrum. If you have a multi-sig setup backed via Trezor, there is an eye icon next to the address and if you have three Trezors connected, there will be three eye icons next to the address and you can just press first, second or third and it will show you the multi-sig address on the particular device so you can check and really be sure that this Trezor was not omitted from the scheme and it’s indeed being used.

Stephan Livera: Fantastic. That’s actually something I’ve recently tested out as well with Electrum. I just wanted to make sure that part of it as well, that you really can see it. When you click the eye in Electrum and then it shows on your hardware device that’s plugged in. Then the other component with multi-signature is also now the idea and this concept of, we want to try to, in some sense, make it more difficult for an attacker and one way to do that is not just multi-signature with the same manufacturer but multi-signature with other device types. Can you talk to us a little bit on setting up a multi-signature with different hardware wallets?

Pavol Rusnak: Sure. If you want to use different hardware wallets, and I think it’s a good idea because then you are reducing the fragility of the setup, basically, you need to find a solution that communicates with the hardware devices of different vendors and one of these is Electrum, like we mentioned earlier. There is a really good blog post by Saleem Rashid on his blog where he describes experience and individual steps, how to configure that but actually it’s pretty straightforward. There is a guide in Electrum. If you just choose, “I want to use multi-sig. I want to use hardware-backed multi-sig,” and then it will try to look for the devices and will just pick the devices from the detected list and it can create a scheme for that.

Pavol Rusnak: There are also companies, for example, Casa. They are trying to make this process even more straightforward for people and they also support different hardware vendors and they also have some enterprise schemes or maybe not enterprise but they are commercial schemes where you can have Casa participating as one of the multi-sig parties. In case something goes wrong, you can use their servers to recover the situation.

Stephan Livera: Let’s talk now about… Another concept is around backing up the seed. Related to that is this idea of Shamir’s Secret Sharing. I know with Trezor there is this SLIP-39. Can you tell us a little bit about that?

Pavol Rusnak: Sure. The original standard for mnemonic seeds was called, or is still called BIP-39 and we came up with the definition in 2013. It was not an original idea. There were some other implementations predating that. One of them was Electrum but it was never standardized and we really felt that we need to put there a standard so other hardware and software wallets can implement that and that way, we could achieve interoperability of this seed. I’m really happy to say that now, every hardware and even every single software wallet supports BIP-39. You can exchange these mnemonic backups as you wish. If your hardware breaks down, you can buy another one or even from another vendor or use the software wallet if you want to recover that.

Pavol Rusnak: We thought it would be great to come up with another standard again. An open standard so everybody can implement this and we hope we will achieve interoperability of that with Shamir’s Secret Sharing scheme. The idea is actually very simple. Right now, if you initialize the Trezor, it will give you a set of words. They can be either 12 or 24 words and you can use this mnemonic sentence to recover your device. Shamir’s Secret Sharing scheme is a so-called threshold secret sharing scheme. It will give you, for example, five sentences. They are 20 words long and during the initialization, you would just say, these are these five sentences but it is okay to provide just three of them to fully recover the secret. There is one big advantage on just splitting the old seed.

Pavol Rusnak: If you have a BIP-39 seed and you split it in half, there is an issue if somebody has half of your seed, then they can still recover half of the secret but the Shamir scheme doesn’t work that way. If you don’t have enough shares, if you are under the threshold, you cannot recover anything and that’s a really big advantage. I think this is the scheme that should be really used in case you want to have a function like that and not to split the old seed by some custom scheme.

Stephan Livera: Let me just clarify that. As I understand that, this is the 12 or 24 word seed and what some people have been doing, which is not the recommended practice, is to actually split that 24 word seed up and say, “I’ll put half here and half there.” That obviously puts them at a greater risk, let’s say if an attacker gets one of those halves, now it’s easier for them to try and brute force you or to try and figure out-

Pavol Rusnak: The rest.

Stephan Livera: This method, you’re saying to use Shamir’s Secret Sharing, you can split that in a way that, say there’s 24 words, you split that in a more clever way, to make it so even if they got two of five in that example, they would not be able to recover your seed, correct?

Pavol Rusnak: Exactly. If I during the initialization say you need three out of five, you need three out of five, nothing less would work. They wouldn’t recover any, even partial secret. There is also an advanced version of Shamir, also described in the paper and it’s like a second level of Shamir where we introduce groups. You could instruct Trezor to generate two groups of seeds and each group will again have its threshold. Let me give an example. I have a group of family members and I will say, “We need three out of five of these family shares.” Then I have a group of co-workers and I would say, “We need four out of six of these co-worker shares,” and then I need two out of two of these group shares combined. That way, I can create a really complex setup, depending on, who do I trust and who I don’t trust.

Pavol Rusnak: One of the parties could even be a lawyer so in case something happens to me, they can also interact. This is something for the future for us to plan and to maybe discuss with the wider community which kind of schemes make sense for various scenarios.

Stephan Livera: As I understand it, the other thing I’m keen to ask is, how would it be implemented? Is this something that you would put inside the Trezor web wallet interface or would it be a separate program?

Pavol Rusnak: Actually it’s already implemented in the firmware, in our beta firmware and you just instruct the Trezor via the web wallet that you want to perform the recovery of said shares or initialization and the whole process is being done on the device. This has one big advantage. Obviously these shares are much stronger if they are properly distributed among different geographical areas and in the future, we would like to make this process totally independent of the computer. You could just have a power bank and a Trezor and travel all across these locations so you can recover them without a computer. That’s why the full process is being done now on Trezor device.

Stephan Livera: Is that Trezor One or Trezor Model T only?

Pavol Rusnak: It’s just Trezor Model T for now.

Stephan Livera: Got it. Next thing I was really keen to discuss was this concept of air gapping. I think that is also now starting to become a little bit more front of mind for people when they’re trying to be a little bit more security conscious. They are concerned about having to directly plug the device into the computer and if the computer has malware, then there’s a risk there. Some of the ideas I have heard and seen. Obviously there is the Coldcard. I know they have the SD card ability, that you can ferry the transaction using that and then the other idea that people are talking about now is QR codes. Do you have any thoughts there on whether that could be something coming in Trezor devices?

Pavol Rusnak: Yeah. First of all, I really do think that even if you use USB connection, you are already air gapped and protected from the malware. Obviously there are some of the risks that might be hidden in the complexity of the USB stick but that said, if you are not using USB stick but then you are using SD card, there is another complexity hidden in the SD card driver or even in the file system driver. There is no silver bullet. You are just exchanging one set of trade-offs with another. That said, we want to give our users a choice, so it’s obvious that with Trezor Model T having an SD card slot, we are already working on that feature. In some of the future releases, Trezor Model T would be able to sign the PSBT transaction stored on the SD card but like I said, it’s not a silver bullet because still…

Pavol Rusnak: There is no physical connection but still there is data from the computer present on the SD card and we would need to still audit the security of not only the SD card drivers but file system drivers and even the PSBT parser as well. Another air gapping matter you mentioned is the QR code. This is even better, it might seem, because there are no physical data present or how would I say… but there was one moment in the past that really struck me and one of our external collaborators and security researchers, Christian Reiter, he found a buffer overflow in base32 encoding or decoding and it was properly disclosed to all other vendors. It was not a very critical bug because it could just introduce maybe two or three extra bytes, unexpected extra bytes but then I realized, this can also be used to exploit a system via the QR code because if you are able to create a buffer overflow in address decoder basically, then you can get that piece of vulnerability over the QR code as well.

Pavol Rusnak: Even that is not 100 percent secure but still, this is kind of really esoteric or not really possible hacks I would say. An obvious disadvantage is that you would need to have a camera on the hardware wallet, which makes it harder to produce and it increases the price, it increases the length of the process and so on. Like I said earlier, the original Trezor model, Trezor One, was aimed to be really simplistic and we are hesitant about adding new features. It takes some time for us to evaluate that.

Stephan Livera: I see. I take your point that QR codes are not a silver bullet but I wonder whether they might be seen as at least one step closer, at least a bit closer to being harder to hack than, say, the SD card option or the direct plug USB.

Pavol Rusnak: Yeah. There is one-

Stephan Livera: Sorry, go on.

Pavol Rusnak: I just wanted to say a final word on that topic. There is another big disadvantage and that is that user experience hurts because then you have to swap either SD cards or you can only fit one kilobyte of data into QR code and then the QR code is really complex so if you want to transmit regular bitcoin transaction, which is usually bigger than a kilobyte, then you would need to exchange a set of QR codes. I think it might be more secure in some sense of things but then if you are making process obscure then it is more error prone and then also securities hurt because people can do mistakes and they will do mistakes.

Stephan Livera: That’s a fair point as well. You’ve got the process fatigue risks but I suppose for the people who are storing lots and lots of value, for them, they would think it’s probably worthwhile but I totally appreciate from your point of view as well, it’s a business and you’ve got to find that sweet spot in terms of what are people willing to pay for? Maybe you would have different devices and a really higher end device, which has all the bells and whistles and that kind of thing but I understand it’s hardware and hardware’s not an easy thing to make. I totally appreciate that as well.

Stephan Livera: Another point I think is interesting for listeners and it’s probably useful for them to know and just from my recent interview with Andrew Chow, he was pointing out as well, he had some difficulties in trying to implement Hardware Wallet Interface, HWI, with Trezor One versus Trezor Model T and the reason was, with the Trezor One, you actually can’t input the pin physically on the device. You’ve actually got to do the scrambled pin on the computer, whereas with the Model T, you actually can enter the pin directly on the device and I think even if you want to try the passphrase recovery, you can do it directly on the Model T device. Listeners might want to know that as well just for if they are thinking about future HWI support and additional security advantages that come from being able to enter directly on the device.

Pavol Rusnak: Yeah, like we said earlier, Trezor Model T has a touch screen. We really want to make it possible to enter every possible piece of information directly on the device so it never touches the computer. Like you said, it’s not only limited to pin. There is a really nice feature of Trezor Model T and that’s unless you enter the pin, the USB communication is not even enabled, so on Trezor Model One, you need to start the USB communication in order to perform this scrambled pin entry. That brings also another level of security and with the passphrase, for model One, you need to enter it on a computer. There’s just no other way yet. We are exploring various ways how to enter a passphrase directly on Trezor Model One but because there are just two buttons, you are very limited and we don’t want to make this process awkward because if this process is awkward, then usually you’ll end up with a really simple passphrase, kind of defeating the purpose altogether. The Model T, it’s much better because you have the touch screen and I personally use a rather complex passphrase and still I am able to enter it directly on the device.

Stephan Livera: Great. Let’s talk a little bit about Trezor hacks and some of these other angles. I suppose just firstly, for the listeners, if you’re a newbie listener, some of this stuff, it might scare you but remember it’s all relative here and you’re better off using a hardware device than leaving it on an exchange but that said, I think it’s useful as well just to make everyone aware, these are the hacks and so on that can occur. Some of the different ones I’ve seen are… There’s a range of them, right? I think there was one around trying to infer from the signal, what was the pin or the passphrase. There’s the other ones where if the attacker has physical access to the device, that they’re able to reverse out or pull out the seed and the pin and just access from there. Did you want to just discuss what was your process around that and then try to mitigate against those?

Pavol Rusnak: Yeah, sure. Security, including physical security, is a very complex topic and I have to admit, I’m also learning it as it goes. What I learned in the process is everything, be it hardware or software, is hackable. The only thing that changes is the price of the attack. If the attacker is motivated and has enough resources, be that either people or money, they can get to your coins. Even if their moral standards are low, they can maybe mug you and torture you for the pin or for the passphrase. No extraction from the device itself is needed, so to say. We’ve foreseen this and like I said, BIP-39 was introduced in 2013 and even that, the original release of that standard contained a passphrase. It’s an idea where you just don’t use the seed stored in the device to generate the keys but you also use the passphrase, which is being added in the mix and only after providing the passphrase, you can generate or derive the keys. One great property of this is that every passphrase is correct, so to say, because there is no mechanism to check the correctness of the passphrase.

Pavol Rusnak: What you can do is you can have small amounts of bitcoins stored with empty passphrase, then maybe you can create a simple passphrase like airplane and put some more bitcoins onto there and then you can have super secret, super complex passphrase, where you would put most of your holdings into. In case you are in the troubled situation, you can show the attacker this simple passphrase and there’s way how to prove there is another secret passphrase. That was the original idea behind the passphrases but also the protection of the physical security was another one in case the seed will get compromised.

Stephan Livera: It’s an interesting one. I guess I’m just a little unsure how safe the passphrase part really can make you against if they’re there with you, right there. Because in reality, they could just keep hitting you. They could just keep hitting you until you give them everything and who knows? Because even if they’re a smart attacker and they know how a Trezor works, they know how pretty much every hardware wallet works with the passphrase, they could just keep going until they get everything, I suppose. But at the same time, it’s there to provide some level of protection. I think the other question that came up from some of the hardware hacks and so on was around what length does your passphrase have to be to keep you safe? Because theoretically, if an attacker gains physical access to your Trezor device and you’ve run a very short passphrase, they may be able to brute force that and it might not take them that long to do that kind of attack. Can you just tell us a little bit of your thoughts around what length does it need to be to be safe?

Pavol Rusnak: Yeah. We published a post on our blog titled, Is Your Passphrase Strong Enough? Where there are lots of good practices and recommendations how to come up with a good passphrase. You could either use diceware to generate basically another sentence of words that you memorize or you can use a random generator to create a lowercase sequence of characters and so on and there is even a nice table included in the blog post. For example, right now, if you use 13 lowercase letters for the passphrase, the attack would cost around a billion dollars. Obviously, that’s a lot. This will change in the following 10 years because we have better computers every year but still, even in 2030, the cost of this attack would be $10 million and then we could discuss, if an attacker has $1 billion right now, what is easier to perform?

Pavol Rusnak: A hardware level attack on some very sophisticated hardware wallet or to perform a brute force attack on a passphrase? We are basically providing all these means to make it harder for an attacker but in the end, it’s the resources of the attacker that matters and the other important factor is time. We want to make it as hard as possible for the attacker to attack that effectively and if the attack takes, I don’t know, two weeks to perform, then we are pretty much on the safe side because if I do realize during that two weeks that my hardware wallet is missing, I can still send the coins out of this device. That’s a really big improvement because for example, if your, I don’t know, credit card is hacked, you need to replace the device but in that case, you can just generate a new passphrase and send the coins to another passphrase, for example.

Stephan Livera: I think the other thing as well is the length of the passphrase that’s required to make it safe. Some of the best practices and so on, like if you look at, say, I think there was a Coldbit blog post and I think from there, it was basically saying, remember, humans are very bad at doing random or generating random numbers or characters. Best to use these diceware lists. You might sit there rolling dice and come up with a list of six or seven words and use that as your passphrase to help keep you more safe against the attacker but that also does bring in another whole layer because now you have to think about that from backups and restoration point of view because let’s say I need to think, estate planning. How do I pass it on to my heirs or to my family? That’s also an additional consideration and the challenge then, I suppose, there is a risk that the user will not correctly backup the passphrase as well as the seed and put it in some way that their family can access it when they die.

Pavol Rusnak: That’s correct.

Stephan Livera: I suppose that’s just the main risk I might just call out for the listeners but absolutely the passphrase is a good recommended practice but just be aware of that backup and restoration and estate planning aspect of it as well. Let’s talk about now, privacy. This is also another topic that people are becoming a little bit more aware on and are starting to take some further steps. I suppose right now, if a newbie just buys a Trezor and they just use it and they plug in and they go to wallet.trezor.io and so on and they initialize that device, at that point, are they sharing their xPub, the way to generate all their addresses, with the Trezor web server?

Pavol Rusnak: At the moment, that’s correct. You are sharing the xPub with whatever backend you are using. If you are using our backend, that’s true. It’s a little bit more complicated. It depends on the coin. For some coin, you are not sharing the whole xPub, just the individual addresses and it depends on whether there is an optimization for key derivation on the server or not. That said, there is a way how you can use our backend run locally. If you don’t want to do that, you can download our backend sources because these are also open source and random for yourself. Another option, how to initialize the device without xPubs being shared, for example, is you can install Python-Trezor package, which contains trezorctl command line tool and this can perform most of the stuff you want to do with your device. Either initializing or getting addresses or sending transactions but that’s a little bit too low level for regular use but for initialization of the device, it’s just perfect.

Pavol Rusnak: There is always Electrum, like we said. You can use Electrum and then you can connect to whatever address server you want to use, even your own one and when it comes to privacy, we have a really big bulk of improvements coming up end of this year or maybe beginning of the next year and the idea is that we want to create a desktop software called Trezor Suite. It will do everything that the current web wallet does but in a desktop environment and then there would be an option for the user to run the local Bitcoin Core instance, so the Trezor Suite software could connect to it directly or you could use TOR to connect to our backends if you don’t want to run local Bitcoin Core instance. You want to use our servers but still you want to protect your privacy.

Pavol Rusnak: With this Trezor Suite, we want to make this process as easy as possible. Our current idea is to just have a really, really simple checkbox, like I want to run the Bitcoin Core instance locally and if you check it, it will do everything for you and connect to the fully synced instance or even if you want to use our backends via TOR again, we want to make it as easy as possible for the user.

Stephan Livera: That’s really good. I didn’t know about a Trezor Suite coming. Is that a relatively new thing?

Pavol Rusnak: Well we’ve been cooking that for quite some time but there are a lot of challenges and not only technical ones but also a lot of discussions about how the user experience should look. Like I said, we want to make it as easy as possible because that’s our goal. We want to make things secure but also very usable because only if they are easy to use they are indeed secure.

Stephan Livera: Got it. So look, let me just summarize that for the listeners if they’re a newbie and they couldn’t quite follow everything there. Basically right now, if you use a Trezor with the standard web wallet, if you just go the wallet.trezor.io. You are giving up your xPub when you first initialize, meaning that the Trezor web server can know your balances, right? Because that’s how it knows your balances. If you use it on Electrum without using something like Electrum Personal Server, ElectrumX or Electrum Rust Server, you’re giving off the transaction data to the public server. But the good part is, if Trezor Suite is coming, then that is a potential way that you can set up wholly on your own computer or using TOR in such a way that you’re not giving up as much of your privacy, or if you’re using fully your own local Bitcoin Core then it’s done in a way where you’re not giving up any of your own information about your balances to the Trezor web server. Would you say that’s a fair summary?

Pavol Rusnak: Yeah. I think that’s correct. Also there is another option like you mentioned at the beginning of the interview. There is a project called HWI, which allows you to connect a hardware wallet to local running Bitcoin Core instance. So that’s also an option but it might be tricky for common people to use. But that’s the best thing you can do because only if you are running your own Bitcoin Core instance then you can be really sure there is no middle man between you and the bitcoin blockchain.

Stephan Livera: Fantastic. All right let’s talk about the question of bitcoin only. If I were to try and just reflect some of the, what I’m going to call, “Bitcoin community sentiment,” I think some of the more hardcore bitcoiners feel like they get a bit paranoid when there’s an update coming on their Trezor device because they’re worried that, “I don’t care about shitcoin support, I just want to keep my bitcoin safe.” Is there an additional risk there around having other alt coins, or support for them, versus the bitcoin only? But at the same time I want to be fair to you, I want to recognize you’re a business and so you’ve got to make sales. I don’t fault you for that. But what are your thoughts around the idea of having the… and I know this is a topic you might have touched on before, around the possibility of having bitcoin only firmware.

Pavol Rusnak: Obviously we were born and raised in bitcoin community and this is what we are coming from. I’m 100 percent bitcoin. I don’t own any other coins. We are bitcoin maximalists. To be frank, if it were not for alt coins, we would not survive the years 2017 and 18. This is something not a lot of people realize. It’s very easy for the new hardware wallets that came up recently to say, “All right so we don’t do the shitcoins.” Personally, if the situation wasn’t that bad two years ago, I wouldn’t add these alternative coins as well but there are also some voices among the company and outside of the company that are basically saying, “All right so there are people that will get into alt coins,” and then they realize there is only bitcoin so that’s also kind of a little bit more stressful maybe but also an onboarding of new bitcoin users through these alt coins acquisitions.

Pavol Rusnak: There is more things to that. When it comes to frequency of the updates, people are saying, “Oh you are just adding some alt coin stuff and I need to update all the time.” Well that’s not really the case because every time there is a firmware update, there is some bitcoin or management feature also being added. I don’t remember any firmware update that included only alt coin related changes. Of course people are asking for bitcoin only firmware. We’ve done some steps to that already. It would obviously make our release process a little bit harder because then we will release two sets of features into firmwares on each update. But this is something we are going to do. I’m not sure if it will be the next update or the update afterwards but yeah, we would really like to deliver that functionality to our users or the stripped down functionality in a bitcoin only firmware to our users.

Stephan Livera: Great. Cool. FIDO2 authentication. Did you want to just touch on that as a feature? What is it? What should the bitcoiners be thinking about when they want to use FIDO2?

Pavol Rusnak: I would say most of the people that are interested in bitcoin got somehow in contact with U2F because of some of the exchanges are introducing various forms of second factor authentications. Second factor authentication is a very simple concept when you have something you have and something you know. In the case of U2F, the something you have is a hardware token and something you know is the password. When you are logging into the application or web application, you need to provide a username and a password and then the website will ask you for confirmation on a hardware token. Usually that’s YubiKey because that’s the company that pioneered that approach. That’s better than the second factor authentications via SMSs for example because the SMS network could be somehow intercepted and decoded. There are also a lot of social engineering attacks on calling to mobile phones operators and persuading them to transfer the sim cards to some other person. There are a lot of other issues. FIDO2 is another generation of such authentication method.

Pavol Rusnak: It’s backwards compatible with U2F so it could work the same way as the old U2F authentication but also includes something that I call passwordless authentication. There are again two factors included. Something you have, that’s a hardware token. Something you know and that’s a pin to a hardware token. So if you have a hardware token that is protected by a pin, you can get rid of the password basically. If you have got ridden of the password you can very easily get rid of the username because you can use some public key to identify you in the system instead of the username. What FIDO2 allows you is to… or it provides you a very simple and standardized way for a system, application, web application, to ask you for identity and then you can provide that using a hardware device and the hardware device can verify the correct person is using that because there is pin involved in the process.

Pavol Rusnak: This process is really straightforward because it gets rid of all these hassles. I’ve been reading about FIDO2 since maybe two years we were reading some preliminary drafts of the specification. That seemed like a really great thing to do but only recently, a week ago, my colleague presented the FIDO2 in our firmware and I was totally blown away. The user experience of FIDO2 on Model T was just amazing. It would just show the name of the service on the display and your identity being some username in the system for example, and then they would just scroll among the identities on the device, if there are more you can of course register twice on the same service. Then you just confirm it on the Trezor and you are automatic logged in. No password. Nothing else.

Stephan Livera: Yeah, that’s great. I definitely can reflect from my own use with the Model T, it is quite a… I haven’t had a chance to use FIDO2 on it obviously but I do notice the user interface is quite easy to use. So look Pavol, I think that’s mostly the key questions I had for you but did you have any closing thoughts on what we can expect to see coming from SatoshiLabs and Trezor devices? I mean you mentioned the Trezor Suite before but just to let us know if there’s anything you would like to say about Trezor right now?

Pavol Rusnak: Yeah, so I think we covered most of the most exciting changes that are in the pipeline like Shamir backup or FIDO2 or PSBT via SD card. These things are in the pipeline for some time already but it takes some time to fully understand the feature when its not a feature designed by us, for example like FIDO2. Also it’s very hard to even come up with your own feature, for example like Shamir. So there are a lot of discussions. This takes some time, also lots of testing and implementing. But the good news is all of these are already in a testing phase, internal testing phase, so I really hope that these will be rolled out very soon. Then the big leap would be the Trezor Suite, the desktop application for Trezor that I mentioned with all these extra features that were just not possible when using the web application. So either it’s TOR connection to backend servers or connecting to local Bitcoin Core instance. I’m really excited to see that because we think we will make it even better for people to be private and self-sovereign while maintaining the same level of user experience they are really used to.

Stephan Livera: That’s fantastic, yeah, I’m definitely looking forward to seeing the Trezor Suite coming out and some of those features as you mentioned. I think I’d definitely be keen to give those a try. I think that’s basically it but obviously before we let you go Pavol can you just tell my listeners where they can find you online and if they want to get a Trezor, where should they go.

Pavol Rusnak: Yeah sure. So the easiest way how to contact me is on Twitter, I am Pavol Rusnak on Twitter. Trezor also has its Twitter account, it’s Twitter.com/Trezor. Everything we do is open source like I said, so github.com/Trezor, there are all possible sources to firmware backends and obviously you can find me on GitHub among the GitHub issues as well. We do all the development in public so you can see all the features we are working on. The Trezor website is, trezor.io where you can get your devices and we have a small gift for our listeners because this episode is episode 100 if I’m correct.

Stephan Livera: Yes it is.

Pavol Rusnak: So we decided to give our listeners a promo code so if you use promo code SLP100 in our Trezor shop you will get a discount for Trezors. This promo code is valid for one week.

Stephan Livera: Fantastic. All right well I think that’s pretty much going to do it for us so thank you again for joining me today.

Pavol Rusnak: Thank you very much for inviting me. It was nice to see you and to chat in virtual person.

Comments (1)

Leave a Reply