 Good morning. Thanks for coming out on the first talk of Sunday. I am Josh. This is Chris. Somewhere in the audience is Krill. He's our plant. So just be careful about that guy. All right. We're talking about breaking Bitcoin hardware wallets. All of the links will be up on our website. Basically slash breaking Bitcoin, the GitHub links, board files. Not everything is up there now, but after the presentation we'll have most of the stuff. Okay. So we're talking about Bitcoin hardware wallets. Well, what is a Bitcoin hardware wallet? So what you need to know for this talk is that Bitcoin is a cryptocurrency and I'm going to start my timer. So Bitcoin is a cryptocurrency. The security of Bitcoin and all of the cryptocurrencies comes down to the security of your private key. So it uses an asymmetric public private key pair system. If I know your private key I can send transactions. So transactions just like a block in the Bitcoin system. Basically I can send money is what you need to know about that. And since we all know that software is insecure, the best way to store your Bitcoin private key is with a hardware wallet. And so a hardware wallet is, so wallet is just the name in Bitcoin for the thing that stores your private keys. Hardware wallet is a dedicated embedded device. There's a few manufacturers of them. The kind of two big ones are the Trezor hardware wallet, which is what you see on the slide. The other one is a Ledger. They're essentially dedicated embedded devices that connect to your computer over USB. And when you want to send money, so when you want to sign a transaction, you plug in the hardware wallet and it goes and your computer will talk to the hardware wallet and say, please sign this for me. And your private key never gets onto your computer, which maybe you use for other things that you may not want to keep lots of money on. Okay, so the other thing that we're going to be talking about today is fault attacks. So what is a fault attack? Well, a fault attack is an attack that applies an external stress on an electronic system and the attack part here means that it generates a security failure. There's two parts to a fault attack. There's the fault injection and the fault exploitation. Just like if you have a stack overflow vulnerability, you know, there's a stack overflow is the vulnerability, but getting the shell code in there, that's the exploit. Same idea with a fault attack. Two parts. We looked at two different ways of injecting faults. We looked at voltage glitching or VCC glitching. Essentially this is just dropping the voltage of the running microcontroller to get it to do things that it shouldn't. So specifically what it seems to do is that when you read and write from memory, that doesn't seem to work like it should when you just kind of drop the voltage at very specific times. The other attack we looked at or the other injection rather is clock glitching. Clock glitching is getting the clock signal so it's a very digital clock kind of pulse and you drop the voltage at very specific times. The end effect is that you end up skipping instructions. How that happens is there's some instruction paper lining going on that we won't have time to get into the theory but that is the end effect. And the exploitation is just you get the fault, you know that it makes the effect and then you time it at the right spot and that's what leads to the exploit. Okay, the last kind of background is what is a chip whisperer. So we use the chip whisperer to do this talk. So this is what a chip whisperer looks like. It's essentially an FPGA with some other hardware on there meant to do these fault attacks. It also does side channel analysis. This is like power analysis, differential power analysis. We didn't do that. We focused on fault attacks. So you don't have to know too much about it for now. There's a lot of information on the wiki, on the chip whisperer wiki. All you need to know is that that's the tool that we used to insert the faults onto the hardware wots. Okay, and so this talk is basically the combination of those three things. So we wanted to look at three questions specifically. You know, we looked at the TREZR hardware wallet which is based on the microcontroller TREZR and all clones I should say. The STM part, F205, is this vulnerable to fault injection? Can we exploit it via a fault? And how do we raise awareness for these kind of attacks? So the first thing we did is, you know, I get a keep key. First thing I do like any normal person is take it apart. Start looking at things. I look up on GitHub and then there's this two-year-old bug sitting on GitHub when they forked it from TREZR that they hadn't fixed yet. So string compare, all you need to know about this is that string compare was being used to check the pin. The pin is what is the primary authentication mechanism to allow you to send funds on the device. And string compare also has this problem that it fails on the first wrong character. So if you measure it with an oscilloscope, if the first character is wrong, that will fail in about 100 nanoseconds on the device. If the fourth character is wrong, that's 1100 nanoseconds. And so if you just measure the time and can guess the pin, you can basically see if your guesses are working. It really doesn't work in practice because there's this back off timer that they implement that makes you wait to enter the next pin. The first time it's wrong, you have to wait a couple seconds. But by time, like the eighth time it's wrong, you have to wait like a day. So we clearly needed another way to get around this pin. All right. So how hard could it be? You know, you dig out your chip whisper from the box, kickstarter items that you haven't played with. And you set it up, you get your environment going. And you start running through the tutorials. Within the first few tutorials, you're actually scripting the chip whisper to drop out the password from an X mega target that it comes with. And that's perfect because that's exactly what we want to do with the pin, right, on the key key. So you run through some more tutorials and you start doing glitches on the X mega and you're glitching over a while loop which is exactly what we want to do with the back off timer. So, you know, plug in the key key, press the glitch button, receive bitcoin, right? Well, it's not that easy. So as you can see my setup here at the towards the end kind of looks like surgery. And a lot like surgery, we only had one mistake to make. We had one key key to work with. Our timing was really bad. Bitcoin was doing new highs every day. It was over $2,600. We saw somebody pay $500 for a treasure wallet somewhere online, which is crazy. So you couldn't even find the STM3205 part on DigiKey and other websites. So it's really, we had a very small margin for error here. So, you know, once you start attacking real hardware you get into a lot of technical hurdles. Like Josh said, you talk to the treasure and the key key over USB. So you're sending your pen, you're uploading firmware, everything that you're doing to communicate with those devices is over USB. Well, when you glitch the device, it's going to affect the USB very strongly. And your host machine is not going to like it very well. So some of these are intended, but some of them are unintended. One of the intended hurdles is this signed firmware check. So if you upload your own firmware to make it easier to attack the device, they still check to see if it's signed by KeepKey and they make you press a button. So you've got all these fly wires in your way, you're trying to press the button. It's really complicated and annoying. And I don't know if you've ever worked with arduinos at different voltages as well. The KeepKey is running at 2.8 volts. The chip whisper is running at 3.3. You can't just plug them in and get them to talk together. So, and I don't really have a slide to show you just how tedious it is to fault attack with the chip whisper. It's a lot of trial and error. You're constantly resetting the device because it's not always working. You're trying to find the variables to actually exploit the device. So it was a big pain in the butt. Okay. So we clearly needed something simpler. Tried to go right for the main device. That wasn't working. We needed to just start small and build up from there. We wanted a simple proof of concept. So we can just have confidence that we can do the glitch attack. And what we made is a treasure clone. And we are releasing this clone. We have some of the boards with us that we're going to hand out. All the design files are going to be up on the website. Completely open source hardware, open source firmware. You can make your own treasure. It's in this weird rectangle format because it means it sits on top of the chip whisper. So that's why it looks like that with all the pins. It's a full treasure clone. So it'll both run legitimate firmware if you want. But if you don't set the fuses and you don't put the treasure keys in there, it'll run illegitimate firmware, which is more fun. So that screen is actually the screen where we hacked our own boot loader. So if you own the boot loader, you kind of own the device. So that's more fun. And then we have dedicated on kind of a special glitch hardware on the board so you can glitch without the chip whisper. So this is an example you see in the middle of an Arduino Uno. You don't need a chip whisper to do this attack. You can do it with other hardware. It's a little bit tricky to get the voltage and the timing just right. But you definitely don't need a chip whisper to insert glitches. All right. So thanks to Krill and his hard work we got our breaking Bitcoin boards really quickly. I was able to get a much cleaner setup as you can see here. I've got the chip whisper, the UFO board and the red and our breaking Bitcoin board. No fly wires or any of that stuff. I also didn't have to be as careful. So you know, I could turn the glitching up to 11 as you say. And in fact I did. I burned up one of our boards and actually damaged one of our chip whispers. So you can actually do some damage with that thing. All right. So if attacking, you know, starting out attacking the key key or the treasure is kind of like attacking a final boss on level one in a video game, right? So we made our own hardware to give ourselves a better platform for these attacks. Well now we're going to, I'm going to show you the proof of concept or get the fuck out examples of glitching on our breaking Bitcoin board. So this first one here is basically the hello world. You should print out A, you should wait at line eight and you should never see one, two, three, four print out on the UART. And so I'll just run through real quick what you're seeing here. This is the chip whisper analyzer software. The top right, the red line that looks fuzzy is your voltage. It's kind of like an oscilloscope. You've got your glitch settings in the top left and now we have a serial output in the bottom right here. As you can see at the very bottom where I've highlighted the text, it printed out hello new line A and then one, two, three, four. So we were able to get out of that loop and actually print out one, two, three, four. All right. So this next example is like level two. And this one is interesting because this is structured similar to the back off timer and the treasure keep key. It's nested loops. This one doesn't do anything but print out your variables for sanity checking. But as you can see, this is a good example on the top right of the glitch. So you see the voltage drops all the way to ground for a very small amount of time and comes back up. If you see in the serial output, we've got, you know, the first variable is actually lower. So I don't know if we, did we actually go through the loop faster or did we just modify the memory on the running device, modify the stack variable. The point is that we caused behavior that was unintended in a security device. Some more examples here. You can really start to get some garbage to print out. And this thing is still running at this point. But yeah, you're really croninberging it up here. Yeah. So just the reason that's significant is because we're modifying how a security device is running by an external event. So even that example, we're just seeing the stack variable change. This is a security device. We're not using anything on the device to change it, except for changing the voltage. So our board is basically, it is the same micro controller as the treasure. So that's what we're kind of using to do these examples. And this last level is basically can we skip over a pin? So if I can skip the pin on your treasure and you don't set a passphrase, then I'd be able to do a transaction. So how did this one go? So basically you see there, the password here is touch in line two. It gets the password in as input. If it's denied and print denied goes to a while loop. If it succeeds, welcome. And there's just code at the bottom of the show that the LED turns green if you get past that. And we insert the glitch and you can kind of see in that you are at screen, if you look at the bottom, we typed in the wrong password. So it was a J instead of an H. And in that picture, you're seeing the LED, a green LED, which means we entered the wrong password, glitched, and then jumped out of the failed password and essentially skipped over. So we don't know the password, but it doesn't matter because we just skipped over it. Okay. So we were only able to do this on our board, which is essentially a treasure clone. So we are confident in saying that the F-205 definitely is vulnerable to fault injections. We showed here voltage glitching, which does affect the microcontroller. We also had success with clock glitching. I'll talk about that vulnerability in the next slide. Is the treasure firmware exploitable via fault? Inconclusive, right? So this is where we came up a little short. We couldn't, we could not glitch an unmodified device, but part of the thing in raising awareness for this talk is releasing the board, giving this talk, releasing our tools. There's probably smarter people than us who can get the glitch parameters exactly right to do this, to do the attack on a live device. And the significance here is that once you kind of do this once, it becomes this break once run everywhere attack, right? So if you can learn how to do the glitch parameters, you don't need a chip whisper anymore. You make a custom device and you could maybe like put that over a treasure or something, kind of like a pay TV on Looper. Okay. So the summary of the vulnerabilities we found, and these are all disclosed to Treasure and Keepkey. The F205 is definitely susceptible. Keepkey had that timing analysis bug on the pin verification. Treasure and all clones had, they did not turn on this feature called clock system security, which basically would tell when the external clock failed, I was being glitched, they would get it interrupt and they could do something like erase the pin or take self-defense mechanisms. They did not do that. And so that was actually one of our biggest recommendations is that with either the clock glitching or the voltage glitching, they would be getting these hard faults. It would trigger the interrupt service routine. They could detect that and then, you know, shut down the treasure, wipe the pin and prevent people from experimenting with the glitch attack on it. So as far as I know, that's the change that they're making. If you are a wallet user, like just like normal, don't lose physical control of your wallet, but you really want to set a pin plus passphrase because even though we couldn't glitch over the pin on the device, if you set the passphrase, it also encrypts your private key in two sectors. So that is the strongest way to use it. And we recommend you do that. If you're a hardware designer, either of wallets or any other IoT device, you're going to be glitched. So take that into consideration. Defenses for faults, we're not going to have time to go into this, but there's some really good papers on our website that we link to of how to write functions that are resilient to these kind of attacks. And we want to now show you a live demo if I can switch the video. Okay, I pressed the magic button over here. Okay, so Chris has got the chip whisper up on stage. We've got our board, which again is a treasure clone. He is loading up the chip whisper software, which is in the top left. The top right, you'll see a display of the scrolling output once he turns on the target. And we did all the hard work. We know what the glitch parameters are, so we're just going to press the magic button. And okay, so there was the glitch. And if we stop it, he'll highlight that loop there. He'll highlight where the glitch happened. And the code in the bottom left is this nested while loop. We inserted the glitch. And what we think happened is we busted out of that one while loop, got back to that other while loop and then it kept going. And Chris can modify some parameters and make it not work, make it do different things. We'll do some live glitching here. Okay, so then it resets when you see hello. Okay, that one just reset the board, right? So resets aren't necessarily that interesting. They can be, there are reset attacks like on the Xbox. He'll change some parameters. Sometimes it doesn't work. So this is the trial and error part that we were talking about that's really painful. But yeah, voltage glitching does work on this microcontroller. Thank you. And I think that's going to wrap it up for us. We did also do some other stuff, which will be on the slides. We made an open CV pin descrambler, so if there's a little thing, you can now bypass that with open CV. And we decapped the STM32 and we'll post the silicon slides, pictures of the MC up there. But thank you. Thank you.