HWallet: The simplest Bitcoin hardware wallet
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Nikodijevic, Nemanja
All major cryptocurrency hardware wallets on the market either use general purpose microcontrollers that are never meant to be used as secure devices or break the Kerckhoffs's principle by using chips that require an NDA, thus making it impossible to completely release the source code. HWallet is a project developed as a proof of concept to show that it is possible to have a very secure microcontroller, signing Bitcoin transactions in hardware and still be completely open source. The code is released under GPLv3 and is meant to serve as the basis for some future devices or projects aiming to connect the real world to blockchain. This talk will give a brief introduction to the project and describe ways for it's customization.
 Alright, so next talk is from Nemanja Nikodyevich. Sorry if I miss. It's about H-Wallet, the simplest Bitcoin hardware wallet. Can you hear me? So, contrary to what you expected, it's probably not going to be a talk about blockchain. It's more going to be talk about secure hardware. So, it's going to be a talk about secure hardware. And since I already gave a talk with the same slides, I didn't change 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 going to throw tomatoes at me, but save it please for later. From all the promises we heard about blockchain, that it's going to save the world, it's going to 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, telling me, actually, they disagree with me, and that a hardware wallet is not just something that I believe the hardware wallet is. And some people told me, like, yeah, but it's also, you know, 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 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 a really broad array of attacks, showed a really broad array of attacks on these hardware wallets. So, for example, that everyone with the physical access to that hardware can run, can execute any arbitrary code 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, 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 came to the same conclusion with physical access. You can have the supply chain attack on these wallets where you can actually replace the firmware, even though, but the 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 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 fall 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 KeefKey, which is kind of a repo for Trezor, they use the same microcontroller, STM32F205, which is, as I said, a 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, Leisure 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 hardware support, hardware acceleration for SHA-256, but it definitely cannot be open-source. Though the software for the general-purpose microcontroller can be open-source. 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 AT-ECC, even though you 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-source. 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 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 simple, stupid UART communication with the microcontroller that is actually kind of secure, and it's available without an NDA. So it has hardware acceleration for two... It has two random generator, hardware acceleration for SHA-256, and also supports in hardware elliptic curve SECP256K1, 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... 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 big numbers, but we will see that later. So for Trezor, basically it's completely open-sourced, whereas Ledger has these closed-source components that they were unable to publish because of the NDA with SD. So if you see, 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 secure devices. I doubt that there was proper security audit carried out on them. So Kipke, as a repo, as I said, just adds some code on that, and coldcard uses... 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 D8 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.h files. And as we can see, 2.5 million lines of code for coldcard because of MicroPython, and it actually pulls code for different platforms, for different microcontrollers, just a bunch of everything. Whereas Ledger has around 346,000 lines of code, which is the only open source part, and Trezor and Kipkey expected that they have around the same number of lines of code. Whereas the H wallet that was written from scratch only has around 4,000 lines of code, and of these lines of code, 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 the construction looks like this. There is this microcontroller that communicates to another communication microcontroller and talks to the OLED. So this part is 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. Therefore, I made the code much easier to audit. You can audit it in a couple of days. You can perform proper security audit on the source code. And also, yeah, SPI bus is close to 1.0. 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 that part, that peripheral, is making sure that I can sign the transaction. MMCAU gives me the hash and I get the nonce from TRNG. And LTC supports 256-bit operation, arithmetic, for this elliptic or 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 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. OK, 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 T, L, V and CRC. Super simple, not complicated, easy to audit. OLED part basically just clear the OLED and write the row with a 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? OK, 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 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. So I first used the inversion, so modular, multiplicative inverse, modular 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 P to 56k1, 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 going to send 0.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 GPLv3. 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 communications tag, 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? Thank you. 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 KL82, 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, KL82 and KL81, is because they have another peripheral that is responsible for, like, you would need to write the code for anti-tamper, for probably, 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? Yeah, exactly, everything is supported, except for this anti-tamper part. That's why I use them for this purpose. And they have the Edwards and Montgomery curves as well, so I have one there. Oh, that's very nice. Yeah, yeah, it's like that, 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. Thank you so much. Thanks a lot. So, time-wise, so you should talk for 10 minutes, I think. There's like a 20 minute slot. Yeah, 20 minute slot, and we get all 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. I shouldn't be around so I'm going to switch over to the next one. So you should let your profit set be all right. You've HDMI, is that good? Sorry, what? HDMI cable, is that good? Yeah, HDMI is good too. Okay. There we go. You need to wear a microphone so people can... Can you do a test? Test? So it's... So you need to start in five minutes, and I'm sorry, we can... We need to wait five minutes because... Yeah, and I don't think we'll probably plan on being places. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. So yeah, so ten, twelve minutes, and then a few minutes for questions, and then next because...
 Alright, so next talk is from Nemanja Nikodyevich.  Sorry if I miss.  It's about H-Wallet, the simplest Bitcoin hardware wallet.  Can you hear me?  So, contrary to what you expected,  it's probably not going to be a talk about blockchain.  It's more going to be talk about secure hardware.  So, it's going to be a talk about secure hardware.  And since I already gave a talk with the same slides,  I didn't change 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 going to throw tomatoes at me,  but save it please for later.  From all the promises we heard about blockchain,  that it's going to save the world,  it's going to 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, telling me, actually,  they disagree with me, and that a hardware wallet is not just something  that I believe the hardware wallet is.  And some people told me, like, yeah, but it's also, you know,  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  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 a really broad array of attacks,  showed a really broad array of attacks on these hardware wallets.  So, for example, that everyone with the physical access to that hardware  can run, can execute any arbitrary code 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, 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 came to the same conclusion  with physical access.  You can have the supply chain attack on these wallets  where you can actually replace the firmware, even though,  but the 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 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 fall 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 KeefKey, which is kind of a repo for Trezor,  they use the same microcontroller, STM32F205,  which is, as I said, a 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, Leisure 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 hardware support, hardware acceleration for SHA-256,  but it definitely cannot be open-source.  Though the software for the general-purpose microcontroller can be open-source.  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 AT-ECC,  even though you 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-source.  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 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 simple, stupid UART communication  with the microcontroller that is actually kind of secure,  and it's available without an NDA.  So it has hardware acceleration for two...  It has two random generator, hardware acceleration for SHA-256,  and also supports in hardware elliptic curve SECP256K1,  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...  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 big numbers,  but we will see that later.  So for Trezor, basically it's completely open-sourced,  whereas Ledger has these closed-source components  that they were unable to publish because of the NDA with SD.  So if you see, 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 secure devices.  I doubt that there was proper security audit carried out on them.  So Kipke, as a repo, as I said, just adds some code on that,  and coldcard uses...  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 D8 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.h files.  And as we can see, 2.5 million lines of code for coldcard because of MicroPython,  and it actually pulls code for different platforms, for different microcontrollers,  just a bunch of everything.  Whereas Ledger has around 346,000 lines of code, which is the only open source part,  and Trezor and Kipkey expected that they have around the same number of lines of code.  Whereas the H wallet that was written from scratch only has around 4,000 lines of code,  and of these lines of code, 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 the construction looks like this.  There is this microcontroller that communicates to another communication microcontroller  and talks to the OLED.  So this part is 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.  Therefore, I made the code much easier to audit.  You can audit it in a couple of days.  You can perform proper security audit on the source code.  And also, yeah, SPI bus is close to 1.0.  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 that part, that peripheral,  is making sure that I can sign the transaction.  MMCAU gives me the hash and I get the nonce from TRNG.  And LTC supports 256-bit operation, arithmetic,  for this elliptic or 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 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.  OK, 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 T, L, V and CRC.  Super simple, not complicated, easy to audit.  OLED part basically just clear the OLED  and write the row with a 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?  OK, 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 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.  So I first used the inversion,  so modular, multiplicative inverse,  modular 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 P to 56k1,  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 going to send 0.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 GPLv3.  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 communications tag, 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?  Thank you.  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 KL82, 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,  KL82 and KL81, is because they have another peripheral  that is responsible for, like, you would need to write the code  for anti-tamper, for probably, 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?  Yeah, exactly, everything is supported, except for this anti-tamper part.  That's why I use them for this purpose.  And they have the Edwards and Montgomery curves as well,  so I have one there.  Oh, that's very nice.  Yeah, yeah, it's like that, 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.  Thank you so much.  Thanks a lot.  So, time-wise, so you should talk for 10 minutes, I think.  There's like a 20 minute slot.  Yeah, 20 minute slot, and we get all 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.  I shouldn't be around so I'm going to switch over to the next one.  So you should let your profit set be all right.  You've HDMI, is that good?  Sorry, what?  HDMI cable, is that good?  Yeah, HDMI is good too.  Okay.  There we go.  You need to wear a microphone so people can...  Can you do a test?  Test?  So it's...  So you need to start in five minutes, and I'm sorry, we can...  We need to wait five minutes because...  Yeah, and I don't think we'll probably plan on being places.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  Okay.  So yeah, so ten, twelve minutes, and then a few minutes for questions, and then next  because...
HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_0_143.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_144_1043.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_1044_1103.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_1104_1151.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_1152_1247.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_1248_1403.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_1404_4295.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_4296_4487.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_4488_4607.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_4608_5315.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_5316_5507.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_5508_5771.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_5772_6167.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_6168_7187.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_7188_8807.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_8808_8963.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_8964_9059.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_9060_9863.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_9864_11459.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_11460_13643.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_13644_14231.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_14232_15779.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_15780_15923.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_15924_16151.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_16152_17291.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_17292_17567.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_17568_17963.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_17964_20735.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_20736_27323.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_27324_27719.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_27720_28463.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_28464_30551.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_30552_34055.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_34056_34115.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_34116_34331.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_34332_35915.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_35916_36551.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_36552_37115.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_37116_37355.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_37356_37439.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_37440_37487.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_37488_37535.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_37536_45131.png HWallet__The_simplest_Bitcoin_hardware_wallet_ZwVF3xZ9q-g_45132_45254.png