 All right, so next talk is from Nemanja Nikodyevich. Sorry if I miss, it's about H-Wallet, the simplest Bitcoin hardware wallet, and you can go. Thank you. Can you hear me? Yeah, okay. So, contrary to what you expected, probably not gonna be a talk about blockchain, it's more gonna be talk about secure hardware. So, so, it's gonna be a talk about secure hardware. And I already, since I already gave a talk with the same slides, I didn't change it up. These slides, you can already find this talk on YouTube. So, I want to move it a bit in a bit other direction. I will go through slides, of course. But first, I want to say that from all the promises that we got from blockchain, I know some people are gonna throw tomatoes at me, but save it please for later. From all the promises we heard about blockchain, that it's gonna save the world, it's gonna cure cancer and everything, I believe that there are only two visible benefits for the whole community, for the general public. First of all, mining hardware can be reused for AI. And second, advancement in open source secure hardware will probably lead to growth in usage of U2F tokens which will increase security of your accounts on various online services. But let's move on with the talk. And then later, I would also like to hear your opinion about what is a hardware wallet. Because when I gave this talk at other places, some people approached me later asking me, telling me actually, they disagree with me and the hardware wallet is not just something that I believe the hardware wallet is. Some people told me like, yeah, but it's also, saying hardware wallet is kind of a pleonasm because wallet itself is hardware, right? So they say, yeah, also like using a smart card would be a hardware wallet for bitcoins and so, yeah, true. But you don't have a screen. So you are not sure what is actually being signed on that hardware. And I would really like to hear later if anyone else has other opinions on what actually hardware wallet is and what it should be. But let's move on with slides now. So there were vulnerabilities in almost all widely used hardware wallets. So there was a really interesting talk at the last CCC where security researchers gave really broad array of attacks, showed a really broad array of attacks on these hardware wallets. So that, for example, that everyone with the physical access to that hardware can run any, can execute any arbitrary code because due to the flaw in the bootloader. So that's kind of the construction of ledger. So there is an OLED, there is a microcontroller which is an insecure microcontroller like just off the shelf, STM32. And there is a secure MCU. So secure MCU stores all the keys and does all the signing. But if you infect this microcontroller that actually shows on the OLED what you are signing, then this is kind of a pointless scenario and this converges to the security that you can have, for example, on a smart card. So you don't need a wallet for this. On the other hand, yeah, there was also an interesting blog post from roughly a year ago which basically comes to the same conclusion with physical access. You can, if you have access, you can have a supply chain attack on these wallets where you can actually replace the firmware even though, but firmware is actually supposed to be verified by the secure microcontroller. But if you have some redundant parts of the firmware on the general purpose microcontroller, this can actually, you can just resend the same part and then put your malicious code in the redundant part of the code. For Trezor, there were actually, because I believe that hardware wallets should be actually should be resistant to remote attacks. So it means that nobody, like even if we consider a threat model that your computer, your laptop is compromised, your cold storage should be safe. Well, let's say that's not 100% the case with Trezor because they actually wrote a really nice blog post about it. They have a really good security blog for that, for these purposes, but yeah. So in this theoretical attack because of the four in the USB software stack, which is the third party code, actually that can lead to, if your computer is compromised, you can send malicious packets to the wallet and then you can write up to 60 bytes of data into the protected part of the memory, which is definitely not good. And also, of course, like with physical access, blah, blah, you can do the same thing. So let's see how are they constructed, which hardware is used there. So for Trezor and for Kipke, which is kind of a repo for Trezor, they use the same microcontroller, STM32F205, which is, as I said, general purpose microcontroller. It doesn't have any true random number generator. It doesn't have any acceleration for any cryptographic primitives, but because you don't need to sign an NDA to publish this software, it's completely open source, which is awesome. On the other hand, Ledger has this secure microcontroller, which is under an NDA, so that's why I couldn't conclude whether it has or it doesn't have the support, hardware support, hardware acceleration for SHA-256, but it definitely cannot be open sourced. Though the software for the general purpose microcontroller can be open sourced. And there is also another hardware wallet called Coldcard, which has an interesting construction, so it has this secure element, which is supposed to store keys, but on the other hand, even though it's ATECC, even though we would assume that it does support elliptic curve cryptography, but it doesn't support the elliptic curve that is needed for signing Bitcoin transactions, so the actual signing has to be done on the insecure microcontroller, but of course, this can be also open sourced. And the construction that I just developed, because I wasn't happy really with the existing approach, was that I decided to move the OLED and then put the microcontroller in between the computer, like the communication microcontroller, because usually USB software stack is really heavy and going through, and it's also dependent on interrupts in most cases, and that can lead to many different cases where you can actually compromise the whole, so this way you maintain the same threat model as if your laptop was compromised, but you minimize, you close the door, close the gap by only using like simple stupid UART communication with the microcontroller that is actually kind of secure, and it's available without an NDA. So, and it has hardware acceleration for two, it has like two random generator, hardware acceleration for shot to 56, and also supports in hardware elliptic curve sec P256K1, which is needed for signing Bitcoin transactions and Ethereum also. And thus the whole setup can be completely open sourced. So, checking the library dependencies, well, I tried to be independent completely from any library in HWallet, so I didn't even use the standard C library, that therefore I actually had to do some tricks to do even division with like big numbers, but we will see that later. So, for Trezor, basically it's completely open sourced, whereas Ledger is using these, has these like closed source components that they were unable to publish because of the NDA with SD. So, and if you see Trezor, and both Trezor and Ledger, they depend also on lots of third party libs, so that's how actually this buffer overflow happened in Trezor because it was part of these third party libraries that were actually just used as they are. They were never actually meant to be used in security devices. I doubt that there was a proper security audit carried out on them. So, keep key as a repo, as I said, it just adds some code on that, and cold card uses, like it has common code with all of these projects. And it has huge code base because of the usage of MicroPython. I know what you're saying, like you probably think I'm crazy, I'm rolling my own crypto. Well, I would disagree because I'm actually just interfacing hardware primitives in the microcontroller. So, that's why my code base can actually be really small. That's why the H wallet has really, really, really small code base compared to, so I actually pulled each of these projects from GitHub and also including their submodules and then counted the number of lines of code in C and not H files. And as we can see, 2.5 million lines of code for cold card because of MicroPython, like it actually pulls code for different platforms, for different microcontrollers, it's just a bunch of everything. Whereas Ledger has around 346,000 lines of code which is the only open source part and Trezor and Keeb expected that they have around the same number of lines of code. Whereas the H wallet that was written from scratch only has like around 4,000 lines of code and of these lines of code, like only slightly above 2,000 lines of code is the actual meat. The rest is the font for displaying, like you don't even have to audit that code. And license headers which don't even get compiled. So regarding the code layers, yeah, you can find the code on this link. It hasn't been updated for a while, but yeah, I don't have enough time to work on that at the moment. But if you see, this is the basic layer, these are the basic drivers that the code actually interfaces the hardware, the metal. So if the construction looks like this, there is this microcontroller that communicates to another communication microcontroller and talks to the OLED. So this part is, I actually fixed the speed to 115.2 kilobot because that helped me optimize the whole code, I didn't have to calculate values for certain registers that therefore, I made the code much easier to audit, like you can audit it in a couple of days, like you can perform proper security audit on the source code. And also, yeah, the SPI bus is clocked in one megahertz, the same, I actually applied the same approach as with UART, and the other part, the crypto part over there. So basically, I have the building blocks for all of these, so LTC is making sure that part, that peripheral is making sure that I can sign the transaction, MMCA gives me the hash, and I get the nonce from TRNG, and yeah, LTC supports 256-bit operation, arithmetic for this helipaker, also for generating the signature. These are some operations that I used to implement the ECDSA algorithm here. And the upper layer is kind of split in three parts. So there is this packet part which is used for communication, let's say, let's call it upstream to the communication, MCU and further to the computer and to the network, to the OLED, which is basically the interface that you get. Okay, it includes also GPIO that is used for buttons, but I didn't have to show it here, it's obvious. And crypto part, which is covering these three peripherals that I already mentioned. So yeah, packet, there is really simple interface with send and receive, packet structure is like TL, VNCRC, super simple, not complicated, easy to audit. OLED part, basically just clear the OLED and write the row with certain string via SPI. And this is a bit more complicated part where the actual signing takes place and hashing. And the trickiest part was to actually implement the division because does anyone know why I would need big number division for signing Bitcoin transactions? Anyone? Okay, it's because when you want to populate the string for someone of the foreign address, you need to use base 58. And in order to get the base 58, you need to divide that number with, you need to divide the address with 58 and then get these human readable characters. And in order to do that, I had to implement this division which was not supported in hardware. So the way I did it, I actually abused the existing stuff. I first used the inversion. So modular, multiplicative inverse, module number B, so I get the B prime and then I deduct the module, A module B from A to get the round number for the result. And what I do then is I basically multiply these two numbers. And in order for this to work, I have to make sure that I can get the multiplicative inverse module N. And for that to work, N has to be a large prime and larger than any A and B. So I looked at the code that I already had and I found, yeah, there is a P from stack P256k1 which is a large prime number and that's how this was implemented in least number of lines of code possible. Main loop is a stupid main loop that just reads packets via UART. So no interrupts, it's just waiting for these packets and depending on the packet after it verifies the CRC, it sends it further up the stack to different modules. So for example, if it's intended to be used for Bitcoin module, it's just sending it to that part of the upper layer of the code. And then so the type field is actually divided in two so packet type can be either module or actually can be like the module part defines the module and function defines a function within that module on the upper layer. So far I only implemented the Bitcoin module and this is how the process function looks like. Basically, it just has a switch case for the function and then if the computer says, yeah, if the communication chip actually sends like now, initialize the transaction, this is the stuff that the transaction is consisted of and then, okay, now ask the user to sign it and then something like this shows up on the screen and if you say yes, you're gonna send point 001 Bitcoins to this address. So what's next? I don't actually plan to build it because this microcontroller has a super crazy lead time. Like last time I checked, it was almost a year so it's kind of, I guess, pointless to start. But if you want to test it yourself, you can buy these boards that are easily available online from various websites. So yeah, I plan to probably at some point implement or any one of you, you're welcome to commit the code. It's completely released under GPL v3. So for some future plans, maybe implementing the U2F and also, yeah, there is another microcontroller in these series, which is if you want to go NDA more secure, anti-temper, you can use that one and reuse the same code. But then you need to sign an NDA with the chip vendor which is not really friendly for an event like FOSDM, right? And you can also put some other communication microcontroller, the one that I used was already on the board which it was used actually for debugging purposes but I kind of abused it to communicate. But if you put some other, for example, one of these Nordic chips that they support also like Bluetooth, NFC and USB so you can actually connect your wallet to anything and you don't care if there is a vulnerability in that communication stack because all you care about is that this software runs as intended because in the end, you are the one who has the last word if you want to sign a transaction. Maybe one of the next things to implement would be also the recovery seed to implement these three Bitcoin implementation proposals and maybe more cryptocurrencies but yeah, you're welcome to commit code for that. And any questions? Yeah, very nice. So the KL82 chip and there's an 81 anti-tampering I believe they're two separate chips. How do they differ? Do they require NDAs and do they support other than the SECK256K1? Yeah, so first, yeah, sorry, I didn't elaborate that further. There is K82 and there is KL82. So KL82 is based on Cortex-M4 and KL82 is based on Cortex-M0 and I think the board price is twice, two times smaller. So it's 50% cheaper and therefore it's maybe better if you want to give it a shot to try this code yourself. But the only difference between these, K82 and KL82 and KL81 is because they have another peripheral that is responsible for, you would need to write the code for like anti-temper for probably like they support I think mesh protection and stuff like that but you need to sign an NDA for that. I didn't sign an NDA, I didn't even get in touch with the chip vendor so yeah, I'm just expressing my opinion here. Are they useful at all without an NDA? Do they support the Koblitz curves? Do they support Montgomery Edwards curves? Yeah, exactly, everything is supported except for this anti-temper part. That's why I use them for this purpose. And they have Edwards and Montgomery curves as well, the 25519, oh that's very nice. Yeah, that's why I use this one because I've actually checked many different microcontrollers and this one was by far the most advanced I could find. So, thank you. Any other questions? Any other questions? Okay, thank you very much. I'm sure it's fine. Time wise, it took about 10 minutes I think. It was like a 20 minute slot. That's a minute slot and we... And the questions. Yeah, the questions and then a few minutes to switch speakers as well, but I'm saying 10 minutes, I guess it can be 12, that's it. Yeah, that's okay. Yeah, yeah. It shouldn't be about 10 minutes. Sorry, what? HDMI cable, is that good? Yeah, HDMI is good too. Fun stuff. Yeah. Can you do a test? Can you do a assessment? Test? It's working. Cool. So it's... No, it's fine too. Okay. So you need to talk in, you need to start in five minutes and I'm sorry, we can, I have to start at 13, 14. So I have to wait five minutes? Yeah. I've been using all this video for basically all the software to make videos. And so the time stamps, the software will show you the time stamp or the schedule, so... Yeah, and I bet people probably plan on being places. Yeah, yeah, I'm sorry. I guess if I really wanted to see a problem. Yeah, that's a good problem. Yeah. There's no peace to it. To their customers in the country during the day, how many are there? Or that they're worried about the fine of local water, the fine of the sauna, the fine of the water, the fine of the water, the fine of the water, but there's nothing that requires trust. I'm sorry. I'm not going to put it just on you. Trust. Yeah, of course. I'm sorry. I'm sorry. So as long as they're... Yeah. ...teacher right below, actually they're trustworthy. Yeah. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. I'm sorry. Yeah, I know. I know. I know. I know. I know. Can you dial for me? Yeah. Can you? Okay. Sorry, I'm sorry. Woah. Why? Well, you know, everything is the saying here. It looks very cool. I... Indeed. I am... It looks... I'm re-reading your nitpicks. Yeah, I left for... I'm a doll. I'm the biggest one in the League of Kittles who presented us. We work on the blockchain project called Tezos. Oh, yeah. The security. Yeah, I know. But those two ports are not the least. No, no. I'll go. So you're on the co-ordinate team? Yeah. Well, we're all called in many clubs. Yeah, well, I'm interested in anonymity stuff, privacy stuff. Nice. I see you're using a setting. Yeah. I mean, that's just what we expected out of it, which is, I mean, privacy properties. Like, you're really using a deep setting for Tezos to have a very early stages. But at some point, we'd like to have an anonymous player from Russian media and for this. Nice. Yeah, I'm excited to see more cryptocurrencies do that. Yeah. Do you think that that's necessary to scale? I would say so, yeah. Yeah. Yeah, we're not a bank account. I'll be in public. No, you don't. I mean, for experiment phase, it's cool. Yeah. Exactly. 130? Yeah. Yeah, like, 130. Well, depending on your job, I will do the intro. OK, cool. Then I'll just wait for your cue. Yeah. I suppose it's something like go. So, yeah. So 10, 12 minutes. And then, 10 minutes for questions. And then next week up, we'll learn.