It looks like you're having connection troubles. Reconnect now.
03/28/2026 01:20:50
30c3-talk-5545 Latest text of pad 30c3-talk-5545 Saved March 28, 2026 |
Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!
Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!
======================================================================
Please welcome Pavel Rusnak, which is currently developing. So if a colleague of his, he himself is a co-founder of Sperm Labs and the Fab Lab in Prague, his colleague, I think, is the one who who invented share the bitcoin mining pools, bitcoin mining. And today they will show us a secure device for storing or actually authenticating bitcoin transactions called Trezor. So thank you for the introduction, and I will try to reintroduce our team again, so you might recognize the guy on the left who was mentioned. It's marked by Latinos, also known as slash inventor of pool of mining pool concept and also operator of the first mining pool, which is still one of the biggest with around 10 percent of hash rate on the Bitcoin network. He also invented the stratum protocol, which is currently used in the miners pools and in bitcoin client, and the guy on the left is me popular snack. And I'm responsible for some smaller bitcoin projects like, for example, quantum dot org and put together the form of if Alana, who is sadly not in the photo company called Satoshi Labs. And we tried to have something like an umbrella organization for this bitcoin related project. One of the most important problems in the Bitcoin mass adoption is security and safety of bitcoin private keys by security. I mean, the security of the end users computer because we have compromised computers with viruses and malware and keyloggers. We also have, for example, in an internet cafe, our computers we don't trust. And what's not very common nowadays but may be common in future are clients which look like the regular clients, but they do something they are not supposed to do. And by safety of bitcoin private keys, we mean the data are more particularly wallet loss during various disasters, hardware failures and they, for instance, of operating system and also failing to do proper backups, which is very easy, for example, in bitcoin. There are not a lot of users are aware that you have to back up your wallet
regularly, otherwise you will lose your bitcoins. And solution to this, we think, is hardware wallets, hardware, wallet ideas. This idea is not new. First, I encountered this idea during a bitcoin conference in Prague in 2011, when the Clemmens cap introduced us to this project of hardware wallet. Sadly, he didn't pursue with his students this this idea of Arduino based how to develop further. And after a Bitcoin Conference 2012 in London, we decided we flush to create a project that is now now known as Trezor to actually bring this hardware wallet idea to life. We decided to follow the Keep It Simple principle. So we are building a USB-C gadget, more particularly a human interface device. It has an OLED display and OK cancel buttons, which require a physical interaction with user to confirm or discard transaction. And we don't have batteries because we use just power from the user's be and we don't have radio like Bluetooth or wireless because we aim to focus on the security of bitcoin transaction, not not the mobility, which is quite good nowadays. What's inside of treasure? We have our views arm cortex and Free Micron controller, more particularly ASTM 42 f 205 clocked at 120 megahertz. It has half a megabyte of flesh for our code, one hundred twenty eight kilobytes of RAM and how the random generator, which I will talk a little bit later. And it has OLED display, which is more or less one one one inch wide. During the development, we also created a Raspberry Pi shield, which uses the same display. Sadly, Raspberry Pi that can't act as a USB client device. Just she was B host, so we had to put an extra USB B to serial converter chip on board, and this shield was used as a prototyping platform during a development phase because that allowed us to use Python instead of C and to quickly, quickly try some stuff before implementing the implant it in much loved ever see. And the good thing is that this Raspberry Pi, the shield follows the same logic as the real Trezor
device, so client has no way to determine if there is a real device or a Raspberry Pi shield on the other side. So let me give you an overview of how Trezor works. First, we have to generate the initial entropy and we want to allow its easy backup. Then we use this entropy to derive master private key and master public key. I call them generators because with these master keys, you are able to generate basically an infinite number of private keys and corresponding public keys and addresses. And if you send this master public key to computer, it immediately knows which addresses are there available to be spent. And because of that, a computer can then prepare transactions and send them to Trezor. But these transactions are are not having signatures because computer doesn't know the private keys. It just feels fill in, fills in the gaps with key indices, and then Trezor can use master private key to generate these private needed private keys from these indices. If the user confirms the transaction, then it's signed using these keys sent back to computer and it can broadcast it to the network or like it would normally do. The main idea behind this is that private keys never leave the device because they are generated inside of the device. And even during the signature, there is no reason to buy. They should go out. So how do we generate entropy? We use hardware random generator two to create the internal entropy a, we can request the external entropy from from a computer, and then we use both entropy to generate final entropy. And if we commit to entropy a before receiving entropy b, we can prove that the external entropy was used, for example, with this very simple scheme. More complex schemes were suggested by Timo Hanka and Ilya Gerhart variable, for example, by publishing half of the final entropy. You could say for 90 percent that external entropy was used, and you can increase this percentage by revealing more and more bits from from this final entropy. So we ha
ve this entropy, which is basically 100 to twenty eight or 256 bits, and we want to somehow make them available for pickup. So we use something that's called the mnemonic code, which is heavily inspired by what Thomas did in his Electrum client. The idea is simple we split these bits into a chunk of of the bits. We have a short list of 248 words. We interpret each. This chunk as an integer between zero and 247 and use the the vault from vault waste to to create a sentence. We could use entropy directly to generate the master private key, but we decided to do something more. Likes and standardize it as a mnemonic code for thirty nine. So what we do is we use B-BBEE ADF to to generate master private key. It's a constructed use. So the random function H MC Sha 512. We use password as a password of using mnemonic sentence and we solved it with string mnemonic concatenated user secret and that allows us to create something like password protected monarchs. So the idea is you write down this twelve or twenty five words on the paper put it in a safe and if even if someone steals this paper, he doesn't have your massive private key because he has to provide this user secret. If it was used and also a nice side effect, is that it provides plausible deniability because if you if you give some different user secrets to an attacker, he would obtain a different master private key and a completely different set of addresses. And if you are clever enough to send some small amounts of bitcoins to these fake addresses, he can never know that you gave him a right or wrong user secret. We use 496 iteration and desire to kill these five hundred twelve bits. That's because there is another standard called hierarchical deterministic wallets, which use exactly 512 bits for its master node. And the idea is that using that construct, uh, you could create basically a tree of, uh, of addresses, and each level can can be some logical way how to add how to do this addresses into logical groups.
So, for example, uh, the first level would be what your wallet's second level would be or different wallet chains like, for example, main addresses and change addresses. And the third level would be actual addresses of that kind, and the function that generates a level one from level zero is called child key derivation function. And it takes data from parent node and index. Index zero one. To create different, different child of that particular node. And then you can descend deeper and deeper in the tree and you have some logical structure in your addresses. So it's not like it's flat. The derivation function that uses also HMX are 512, and it was designed by Peter Sipamla. And it's standardized as B-52, and because it's very abstract concept, it provides lots of possibilities. The first one I described on the previous slide, but you can, for example, have first level as a representation of different coin types like, for example, the first node would be bitcoin addresses, second node light code addresses and so on. And then it would follow these logical structure deeper. Or you have some even more complex setup. Imagine there is a company that has headquarters and local branches around the world, and this key that happens to be a headquarter key can derive all oral keys in all branches or around the world. But if you are a director of a local branch, you have access access. Just to address this only happened that that happened in your in your branch. What's even cooler? We can push this concept even further and use first the first node in level one for a cryptocurrency second second node in level one for generating SSL keys, another node for generating full disk encryption keys, and Lex Node for generating challenge response keys, which can happen in if you have some intelligent door to your house, or maybe even to start your car. And that's very cool, because suddenly your wallet's token happens to be identity token. You can do pretty much everything you do. You c
an. Another problem we found or tackled is that SDK signatures require random nonce. During signing for bitcoin. It's 256 bits, and if you use the same nonce twice for sending different messages, you using the same particular key, you would basically be risky. This was demonstrated on 02:33 failure for all the talk about console hacking, how they got the place free private key. And sadly, it was also exploded in August 2013, where there was Android, the Java random number generator vulnerability in secure random class, which didn't use enough entropy to generate this nonsense. And more than 59 bitcoins were stolen. What's what was even worse was that all of all Android clients were affected because the bug was in a shared library. Be below the application code and also it. Even if you imported your own private key into Android. Already, you were not safe because the problem was during generating launches for signatures, not during generating the private keys. So coincidentally, in August same year, out of six six nine seven nine was released with implementation in Java, and Go later reported this idea to buy the Python SDK. This slush and it was merged in 0.9 release. And the idea is you don't use random nonce for signature, but you generate these bits with each mark deterministic random generator, which is seeded with private key and the message so it can cannot happen that you sign off two different messages with the same particular key using the same nonce. And it was great news for us because that avoided the problem. It enabled us to do unique tests which weren't possible before, and now suddenly we could. We could see the Treasury doing the correct thing for during signing. And also what was important that allowed us to prove the Trezor doesn't leak massive private key in nonce because you could create such a scheme that would do that. And let me tell you something about integration in order to be Treasury possible, we need to integrate it into existing discip
lines. So the work is being done in the multi bit by multiple guys and this will be the uses for Bitcoin, Jay and Treasury Library and Electrum and Armory clients, which are written in Python, which we are really fond of with America. And sadly, bitcoin security is pretty complex codebase, and we currently have no immediate goal to to implement Trezor support into it. And also upstream is probably not very hesitant to uh. It's a little bit hesitant to to do such big changes in their code base. The good thing about mobile clients, particularly in Android, is that most of new Android phones have USB OTG, which allows them to communicate with USB devices. And because multi it is written in Java, they can pretty reuse most of the code base that that is that was written for multi bit. And also, what we are working right now is a native browser plugin which will create a bridge between Lovullo value be communication if Trezor to JavaScript. So web wallets can actually use Trezor via JavaScript bindings. And that would allow you to finally create a safe level as because there would be no private keys stored on the server. So I think that's it. If you want to contact us, there is this email. Please put for a DC free in a subject. So I know it's came from this conference. Most of the source code is published on GitHub. We will release. We will release a few of our source code in January. Then we will ship. We will ship most of the preorders. And if there are any questions, I'm willing to answer them right now. I can show them if they want, if they want. I think one minute is OK, but. OK, then. So I can show you, uh, before you line up in a microphone, I can show you some early prototype from from September. So it looks like it is, uh, it's a metallic version, which is more or less final. We will be doing some, uh, polishing touches to the version that will be shipped in January and. OK. I don't know if you see it. And it just just the demo screen, because that's if you femur
back from September. So there is there is some demo demo transaction and I can either confirm it or cancel it. And if I confirm it, then it's just some animation doing the signing. And so that's how it looks. I anyone is. Thank you very much. If you have any questions you already know the drill, please line up behind the microphones so you have a question number three. Please go right ahead. Yes, I was wondering if your your hardware wallet supports other types of complex transactions, like in out of him transactions and such. In the first funeral we be releasing in January, there won't be such a feature. But because we have a future update possibility, we definitely want to include multi-signature in the next version of firmware and probably some more complex, complex transaction types. If. Are there any questions from IOC? Yes, one, please. Um, it's look look like the person perfect solution for Ethereum usage. Um, do you think maybe bitcoin ATM machines are, uh, popular? Integrate it with some popular ATM machines in the future? I think it should. It should be possible to integrate it with ATM in the future there. Well, ATM is more or less common computer nowadays, so I see no reason why we we shouldn't go that way. But if because we don't have any Bluetooth or radio, uh, the first version would have to support USB, but maybe in the future there will be some, some other ways. Number one, please tell me what happens with a bitcoin stored on the device when it breaks, then you able to recover your paper wallet with this 12 or twenty four words. And using this backup, you can recover it into other Trezor device or just use software that's compatible with Bip 49 and send your bitcoins to other other address. So that's the main purpose of this paper. One of the backups? Next question from number four, please. Hi, thank you for your talk. It's very interesting. Thanks. I saw on the website the preorders are closed. Do you have an idea when you will be taking orders ag
ain? We will be shipping Trezor to preorder people in January. And after all these preorders are shipped, we will reopen Trezor for regular sale in February. Well, after we are done. So most probably in February, right? Thank you. Number one, please. Are you thinking about another version where you have maybe a power supply within the device and then you could transfer the transactions via Bluetooth or something, which would be more convenient, maybe for later users? The problem is, if we want to have radio in Trezor, we would need to have a battery and other stuff. And it's it looks simple, but it's adding more and more complexity. I'm not saying we are not going to go this way, but the first version, of course, I suppose version is, yeah, we will see how her market will responds. It's still a new, it's still a new area for us and for everybody. So maybe it will be needed. Maybe it won't. We'll see. It would be nice, but the first version is already very well. Thank you. Lots of luck for that. Thank you. Another question from number four, please. Yes. So you talked about update functionality. How do you prevent any kind of update functionality from compromising the device? Obviously, when you plug it in an untrusted system like web shop, like an internet cafe or the aforementioned ATM machine? All right. What? We have a bootloader that contains our public keys and all of our freeware is signed by us. And if the signature is incorrect, then Trezor will print that you are running an official FINRA so you can build your own forever, but you will have to confirm this warning in order to run it. Thank you. Many of you are trying to find seats for the next talk, but please, I know it's hard. Try not to queue up to walkways any more questions from IOC. Maybe. OK. Then thank you for the talk. Thank you for this lovely.
