WEBVTT - Automatic transcript; may contain recognition errors. Speaker labels from separate source tracks. Times match the published episode. 00:00:07.800 --> 00:00:10.760 Live from the internet, this is Bitcoin. 00:00:12.342 --> 00:00:12.902 Explained. 00:00:13.780 --> 00:00:14.140 Hey Sjors. 00:00:16.730 --> 00:00:21.790 Yeah, we're doing another remote episode because, well, we promised to make one 00:00:21.790 --> 00:00:27.520 in our last emergency broadcast. So we're going to discuss the cold 00:00:27.520 --> 00:00:33.220 card hack as many other podcasts have done before us and many articles and, 00:00:33.220 --> 00:00:35.220 you know, everyone has shared their opinion. 00:00:36.080 --> 00:00:41.560 We thought we should still make this episode and I can pick your brain on this a 00:00:41.560 --> 00:00:43.600 little bit. It's sort of your expertise. 00:00:44.960 --> 00:00:49.960 Needless to say, COLDCARD is not our sponsor, at least not for this episode. We 00:00:49.960 --> 00:00:52.620 haven't really discussed it. I don't think we're going back. 00:00:52.392 --> 00:00:56.492 No, they stopped sponsoring podcasts in general. That's my understanding. 00:00:54.890 --> 00:00:56.370 Yeah, okay, right. 00:00:58.200 --> 00:01:00.140 Yeah, luckily we have a new sponsor, 00:01:01.102 --> 00:01:03.592 That's right. That's right. 00:01:01.500 --> 00:01:07.160 Mt. Gox. Mt. Gox, check it out. It's a brand new, brilliant Bitcoin exchange. 00:01:09.130 --> 00:01:12.890 Perfectly fine to store your Bitcoin. I hear they have Litecoin coming in two 00:01:12.890 --> 00:01:13.590 weeks from now. 00:01:14.582 --> 00:01:16.242 Oh, nice. I should try that. 00:01:17.740 --> 00:01:22.160 Yeah, jokes aside, that's actually something I also want to discuss. We'll do 00:01:22.160 --> 00:01:25.660 that a bit later in the podcast because obviously, so I want to discuss the cold 00:01:25.660 --> 00:01:31.560 card hack itself and then also... Yeah, kind of share my thoughts, 00:01:31.680 --> 00:01:36.440 your thoughts on them being our sponsor, because that kind of became part of the 00:01:36.440 --> 00:01:40.320 whole story that, you know, COLDCARD, Coinkite was sponsoring like every podcast 00:01:40.320 --> 00:01:40.900 out there. 00:01:41.100 --> 00:01:46.920 And to what extent, you know, are we to blame for all of this? Where do our 00:01:46.920 --> 00:01:49.020 own responsibilities begin and end? 00:01:51.450 --> 00:01:57.210 It sucks what happened. It's painful. But let's first discuss 00:01:57.210 --> 00:01:59.430 the COLDCARD hack itself. 00:02:00.882 --> 00:02:01.442 Let's do that. 00:02:03.800 --> 00:02:07.740 By now, probably everyone knows at least roughly what happened. 00:02:10.040 --> 00:02:15.680 But still, Sjors, what went wrong here? Obviously, 00:02:16.140 --> 00:02:21.140 everyone knows about the news. The cold card turned out to be vulnerable in 00:02:21.140 --> 00:02:26.460 basically the worst way possible. People that, as they say, did everything right. 00:02:26.460 --> 00:02:31.140 They generated their seed on a hardware wallet, never used it online even. 00:02:31.640 --> 00:02:34.460 But still, Bitcoins were being drowned from it. 00:02:35.632 --> 00:02:37.012 Yeah, so... 00:02:35.720 --> 00:02:40.380 Just in short, not to dwell on it too much because everyone knows this, but what 00:02:40.380 --> 00:02:40.700 happened? 00:02:41.282 --> 00:02:45.802 No, I guess there are sort of two bad failures for a hardware wallet. One is if 00:02:45.802 --> 00:02:49.762 somebody can steal the coins from your hardware wallet if they have physical 00:02:49.762 --> 00:02:54.922 access to it or through some trick, like with, you know, we've talked about 00:02:54.922 --> 00:02:59.082 earlier with malicious PSBTs or tricks with fees, like malware on your computer, 00:02:59.182 --> 00:02:59.502 basically. 00:02:59.982 --> 00:03:04.302 And the other that is actually much worse, and that is what happened, is if the 00:03:04.302 --> 00:03:08.812 seed was never secure in the first place. And that's basically what happened, 00:03:08.952 --> 00:03:10.812 right? The seed had too little entropy. 00:03:12.442 --> 00:03:18.122 So basically the number of possible seeds in the world was just a couple of 00:03:13.040 --> 00:03:14.280 Yeah, too little randomness. 00:03:18.122 --> 00:03:23.402 trillion, I think, which is just not enough. It needs to be, you know, 256 bit or 00:03:23.402 --> 00:03:28.002 128 bits. So like the number of possible seeds should be more than the number of 00:03:28.002 --> 00:03:30.762 molecules in the universe. And it wasn't. 00:03:31.540 --> 00:03:36.880 Yeah, the core security function of Bitcoin, I think you can put it that way, 00:03:37.020 --> 00:03:42.780 like the central reason that your Bitcoins are secure or should be secure is 00:03:42.780 --> 00:03:47.340 that the private key or the private keys or whatever the private keys are derived 00:03:47.340 --> 00:03:53.210 from is... A number that's so big that it's impossible to guess even with 00:03:53.210 --> 00:03:55.130 all the computers in the world, blah, blah, blah. 00:03:55.430 --> 00:03:57.550 There's just too many, too many. 00:03:55.812 --> 00:04:01.592 Yeah, I mean, it's one of the foundations, right? The other foundations are that 00:04:01.592 --> 00:04:06.132 the cryptography itself is secure, because if tomorrow it turns out that the SECP 00:04:06.132 --> 00:04:11.932 curve is insecure, then everybody loses their Bitcoin. And the 00:04:09.380 --> 00:04:09.980 Right. 00:04:11.932 --> 00:04:16.352 third one, I guess, is proof of work. If that doesn't work, then Bitcoin is also 00:04:16.352 --> 00:04:20.512 insecure in the sense that you just can't reliably make transactions anymore. 00:04:20.752 --> 00:04:22.852 But you can't steal somebody's coins then, but yeah. 00:04:23.540 --> 00:04:28.240 Yeah, you can double spend, etc. But yeah, at least one of the core security 00:04:28.240 --> 00:04:33.500 assumptions in Bitcoin is that when you generate private keys, then it's going to 00:04:33.500 --> 00:04:38.280 be random and out of such a big amount of possible numbers that no one can 00:04:38.280 --> 00:04:41.860 possibly guess it. And that's what went wrong here, right? 00:04:42.200 --> 00:04:45.100 So again, it's 00:04:42.732 --> 00:04:47.362 Yeah, and then the question, of course, how it went wrong, how that went wrong. 00:04:47.110 --> 00:04:53.030 also a core file, arguably, or maybe not even arguably, just... The number 00:04:53.030 --> 00:04:57.370 one most important thing that a hardware wallet is supposed to do is generate one 00:04:57.370 --> 00:05:02.650 of those random numbers. And it turns out that the way these random numbers were 00:05:02.650 --> 00:05:06.790 generated meant that they weren't exactly random or not random enough. 00:05:07.110 --> 00:05:08.610 And then the question is indeed, 00:05:07.722 --> 00:05:13.322 Well, I would say it's obviously it needs to be done correctly. I would say the 00:05:13.322 --> 00:05:16.582 number one task of a hardware wallet in general is to keep the secrets safe. 00:05:18.352 --> 00:05:21.932 But if it is not capable of making it securely, then it shouldn't make it 00:05:21.932 --> 00:05:24.852 securely, right? Then it should say, look, I'm not going to make a secret for 00:05:24.852 --> 00:05:29.992 you. You make it yourself and give it to me. But if the hardware wallet makes the 00:05:27.840 --> 00:05:28.160 right, 00:05:29.992 --> 00:05:33.072 secret, then it has to do it correctly. Otherwise, yeah, it's terrible. 00:05:33.360 --> 00:05:38.590 yeah. Yeah, so that's what went wrong in a nutshell. And then, yeah, so let's get 00:05:38.590 --> 00:05:43.950 into a little bit of the technical nitty gritty of what the actual problem was. 00:05:44.050 --> 00:05:45.150 Why did this not happen? 00:05:46.162 --> 00:05:51.622 Yeah, so the cold card has a chip in it. I think it's a secure element chip. And 00:05:51.622 --> 00:05:55.972 one of the things that secure element chip can do is make random numbers. And 00:05:55.972 --> 00:06:00.512 making random numbers is, you know, it's not that easy because you need lots of 00:06:00.512 --> 00:06:02.512 entropy from the universe, essentially. 00:06:03.812 --> 00:06:07.072 So there's, I don't know how these chips do that internally. They might just 00:06:07.072 --> 00:06:11.652 measure some noise in the environment, electricity, whatever. Whatever they do, 00:06:11.812 --> 00:06:15.452 they create a secure random number. And as far as we know, they do that 00:06:15.452 --> 00:06:17.392 correctly. So that's always a bit scary. 00:06:18.230 --> 00:06:24.150 Yeah, and so I made a, just real quick, I made a whole episode on hardware 00:06:24.150 --> 00:06:28.230 wallets. That was one of the few episodes I made without you. Back a couple of 00:06:28.230 --> 00:06:32.950 years ago, I made it with Lawrence Nahum of the Jade Wallet and Ben Kaufman of 00:06:32.950 --> 00:06:36.870 Spectre. And COLDCARD is one of the wallets we discussed. 00:06:36.870 --> 00:06:42.850 And what I remember from that is that... Yeah, so the secure element, 00:06:43.170 --> 00:06:48.150 we don't actually know how that part works internally, right? In the case of 00:06:47.922 --> 00:06:52.122 Yes. So what can go wrong, if 00:06:48.150 --> 00:06:53.010 COLDCARD. So the randomness is generated in some way that we, 00:06:54.260 --> 00:06:58.280 yeah, we don't actually know how it's generated in the case of the COLDCARD, I 00:06:58.280 --> 00:06:58.740 believe, right? 00:07:00.662 --> 00:07:05.522 you only use a secure element to generate the entropy, then at least the outside 00:07:05.522 --> 00:07:10.742 world has no way of knowing how that works. Why? Because these secure elements 00:07:10.742 --> 00:07:13.502 are typically patented and secret. 00:07:14.310 --> 00:07:19.110 Yeah, but that's not, but that, to be clear, that wasn't, to be clear, that 00:07:14.942 --> 00:07:17.362 But you can compensate for that by generating 00:07:19.110 --> 00:07:24.730 wasn't the issue here, right? That's not the, no, exactly. Okay, so, yeah, 00:07:19.442 --> 00:07:21.122 no, exactly. 00:07:22.822 --> 00:07:25.802 No, that's the kind of thing that still could go wrong with other hardware 00:07:25.802 --> 00:07:30.242 wallets or even this one. We don't know, right? But there are ways to compensate 00:07:30.242 --> 00:07:30.682 for that. 00:07:32.030 --> 00:07:32.810 yeah. 00:07:32.362 --> 00:07:36.802 But let's assume that the secure element just did its work, right? If it doesn't, 00:07:36.862 --> 00:07:40.602 then you would expect even older cold card versions also to start being drained, 00:07:40.642 --> 00:07:45.162 and we haven't seen that. No, something went wrong in the software that then sits 00:07:45.162 --> 00:07:50.972 on the cold card between you and the secure element. And its job was, 00:07:51.112 --> 00:07:56.832 and it did that correctly initially up to 2021, its job is to 00:07:56.832 --> 00:08:00.052 ask the chip for entropy, basically, and then use that. 00:08:00.452 --> 00:08:05.232 That's the simplest way to frame the job. Now, the problem here is that if you're 00:08:05.232 --> 00:08:10.972 running software on, well, 00:08:11.052 --> 00:08:16.392 let's go back a little bit. As a developer of hardware wallet firmware, 00:08:16.872 --> 00:08:20.692 you need to be able to test things. And the way you typically do that is in a 00:08:20.692 --> 00:08:23.052 simulator on your computer, not on the device itself. 00:08:23.292 --> 00:08:27.992 You probably do both, right? But it's a bit easier to work on a simulator because 00:08:27.992 --> 00:08:31.052 you need to quickly change something, try it, and you don't have to flash the 00:08:31.052 --> 00:08:31.772 firmware all the time. 00:08:33.442 --> 00:08:39.192 And therefore, the code somehow needs to work on both these 00:08:39.192 --> 00:08:42.952 environments. It needs to know whether it's running on the device or whether it's 00:08:42.952 --> 00:08:48.302 running... On the simulator. But that's a little bit dangerous because you don't 00:08:48.302 --> 00:08:49.322 want... 00:08:48.730 --> 00:08:52.570 Simulator, just to be clear, is basically a regular computer. It's what we're 00:08:52.432 --> 00:08:57.052 Yes, but that means it does not have that secure element. Might have another 00:08:52.570 --> 00:08:53.110 talking about. 00:08:54.610 --> 00:08:54.690 Right. 00:08:56.890 --> 00:08:59.420 Yes, right. Right. 00:08:57.052 --> 00:09:01.152 secure element, but not the same one. And so then the question is, how do you 00:09:01.152 --> 00:09:05.052 make that code work on both these environments? One very naive way is to say, I'm 00:09:05.052 --> 00:09:10.132 just going to check in real time where I am. But that's kind of dangerous because 00:09:10.132 --> 00:09:10.912 if... 00:09:10.912 --> 00:09:15.312 If you're trying to inspect how the device works, maybe something goes wrong with 00:09:15.312 --> 00:09:19.692 that check in the software in real time. And you don't want it to fall back to 00:09:19.692 --> 00:09:24.272 the simulator way of doing things. Also, sometimes you just can't even compile it 00:09:24.272 --> 00:09:29.522 because you can't run actual hardware wallet 00:09:29.582 --> 00:09:35.392 machine code on a normal computer sometimes because that chip doesn't exist. 00:09:35.552 --> 00:09:39.022 So the simulator is like, I don't, you know. I can't simulate that chip. I can 00:09:39.022 --> 00:09:42.462 simulate everything else, but I can't simulate the chip. There's some reasons why 00:09:42.462 --> 00:09:47.082 you can't run the exact same code on both the device and the simulator. And 00:09:47.082 --> 00:09:53.042 that's where languages like C have things called macros. And a macro is a way 00:09:53.042 --> 00:09:57.902 to say, or one thing you can do with a macro is to say, if I'm on the device, 00:09:58.102 --> 00:09:59.082 compile this code. 00:09:59.222 --> 00:10:03.242 And if I'm in the simulator, compile this other code. So the actual code that's 00:10:03.242 --> 00:10:07.062 compiled is different for the simulator and the real device. 00:10:08.842 --> 00:10:14.812 And the bug happened basically in that distinction. So the compiler would 00:10:14.812 --> 00:10:20.352 basically use some of the simulator code on the real device. Not all of it, but 00:10:20.352 --> 00:10:25.952 some of it. And in particular, the most critical bit of it, namely how to make 00:10:25.952 --> 00:10:26.572 the random data. 00:10:29.002 --> 00:10:34.022 So the real device uses or should have used the secure element to generate the 00:10:34.022 --> 00:10:39.362 random data. The simulator instead uses a Python library to do it. And that 00:10:39.362 --> 00:10:44.982 Python library was deliberately not actually cryptographically random. And that's 00:10:44.982 --> 00:10:47.782 fine because that Python library wasn't designed for any of this. 00:10:49.462 --> 00:10:52.782 But this is also where it gets really dangerous if you want to detect it. 00:10:49.890 --> 00:10:50.770 Okay. So, 00:10:54.082 --> 00:10:59.182 Because let's say the simulator had a very, very, very weak random number 00:10:59.182 --> 00:11:03.942 generator that only produces the number one. Like whenever you call it, it just 00:11:03.942 --> 00:11:07.562 says one. Well, that means anytime you run the simulator, you get the same seed. 00:11:08.022 --> 00:11:12.782 And so it'd be very obvious. And then if you had this bug, then the devices would 00:11:12.782 --> 00:11:13.882 all be making the same seed. 00:11:14.202 --> 00:11:18.122 That would have been caught like almost immediately, right? The first. QA 00:11:18.122 --> 00:11:20.602 probably would have seen it. And otherwise the customers would be like, why is 00:11:20.602 --> 00:11:23.402 there money on my account? Why is my money disappearing from my account? 00:11:24.762 --> 00:11:25.082 Right? 00:11:24.990 --> 00:11:30.150 yeah, which some people did claim even happened now, but we'll leave that aside. 00:11:32.082 --> 00:11:35.302 Collisions, right? So I think the number of secrets that these devices were 00:11:33.160 --> 00:11:33.740 Yeah. 00:11:35.302 --> 00:11:40.502 generating with the bug is still in the trillions. And then you can do some math 00:11:40.502 --> 00:11:45.282 on how many you need. I always forget. I think it's the square root. So you need 00:11:45.282 --> 00:11:49.602 a million devices to have any chance of overlap. But ask a statistician. 00:11:51.520 --> 00:11:57.210 Yeah, it's the birthday paradox, probably, right? And anyways, like I said, let's 00:11:51.872 --> 00:11:52.992 So probably not. 00:11:54.812 --> 00:11:55.892 Yeah, exactly. 00:11:57.210 --> 00:12:01.170 leave that aside. Yeah, you were saying if the randomness is like really bad, 00:12:01.310 --> 00:12:05.050 then it's obvious enough for anyone to detect. And if it's really good, then 00:12:05.050 --> 00:12:08.530 there's no problem. But it's this awkward middle space where it's still kind of 00:12:08.530 --> 00:12:10.770 good-ish and then no one... 00:12:08.942 --> 00:12:13.582 Yeah, it's a very, very dangerous middle space, right? It's good enough that you 00:12:11.700 --> 00:12:12.280 Yeah. 00:12:13.582 --> 00:12:18.582 can fool a human tester. It's probably even good enough that you can fool an 00:12:18.582 --> 00:12:24.032 automated tester because let's say you... As a company, you might have 100 00:12:24.032 --> 00:12:29.672 test devices or 1,000 test devices, and you could connect them all via USB to 00:12:29.672 --> 00:12:34.032 some computer and have that computer constantly flash it and make a new seed, 00:12:34.052 --> 00:12:37.712 make a new seed, make a new seed, and then see if there's any overlap. 00:12:39.392 --> 00:12:45.222 So if the number of random numbers was maybe 10,000, You know, maybe the machine 00:12:45.222 --> 00:12:48.662 would have caught it. But the number of unique outcomes, I think, is in the 00:12:48.662 --> 00:12:53.282 billions or more. And so it was good enough to fool the humans, good enough to 00:12:53.282 --> 00:12:59.182 fool any kind of automation, even good enough that users wouldn't see these like, 00:12:59.202 --> 00:13:01.102 hey, why is there money in my fresh wallet? 00:13:02.422 --> 00:13:04.862 But not good enough to defeat an attacker. 00:13:06.810 --> 00:13:12.810 Right. So in short, the problem as you describe it is that the test code was 00:13:12.810 --> 00:13:18.370 ultimately used as the real code on the device. That's the bug, basically. Is 00:13:18.370 --> 00:13:21.710 that a good shortcut to explaining it? 00:13:20.872 --> 00:13:24.112 Yeah, not all the test code, right? But the very critical part of the test code. 00:13:24.862 --> 00:13:27.982 Yes. And so, you know, then you can look at how do you prevent problems like 00:13:24.910 --> 00:13:25.230 Right. 00:13:27.982 --> 00:13:28.302 this? 00:13:29.562 --> 00:13:31.122 Well, obviously, 00:13:29.760 --> 00:13:32.480 Yeah. Or how could this happen in the first place? 00:13:34.502 --> 00:13:36.202 yeah. So how it happened? 00:13:34.840 --> 00:13:38.280 You're a developer, right? Like, is this not an obvious thing that you would see? 00:13:38.400 --> 00:13:40.900 Apparently not, right? Because no one saw it for a long time. 00:13:39.862 --> 00:13:40.382 No. 00:13:42.302 --> 00:13:47.722 Well, I guess it depends, right? If your expertise is embedded systems, and 00:13:47.722 --> 00:13:52.182 you saw the change that was causing this, say, the switching between two 00:13:52.182 --> 00:13:56.022 libraries, maybe you would have noticed it. You're like, hey, this is a 00:13:56.022 --> 00:14:01.932 sloppy change. But if you look at the final result, maybe you 00:14:01.932 --> 00:14:03.992 wouldn't because it's very subtle. 00:14:04.112 --> 00:14:09.942 I think it's the difference between ifdef and if zero. So one says, is this 00:14:09.942 --> 00:14:14.182 variable defined? And the other says, is this variable not zero? And these are 00:14:14.182 --> 00:14:18.962 quite typical mistakes to make in code. We run into them in Bitcoin Core multiple 00:14:18.962 --> 00:14:23.602 times where some components shouldn't be included or should be included. 00:14:23.782 --> 00:14:26.242 It's just not happening in any critical place. 00:14:29.880 --> 00:14:31.220 Right, okay, so, 00:14:30.912 --> 00:14:36.892 But there's a second bug that made this worse. Or, you know, this bug 00:14:36.892 --> 00:14:39.712 could have existed and nothing would have gone wrong if there were some other 00:14:39.712 --> 00:14:42.852 things that had happened. So that might be useful to get into. 00:14:41.910 --> 00:14:47.050 okay, and just to be clear, because there's different versions of the gold cards, 00:14:47.230 --> 00:14:51.370 right, and some of them were affected more than others, so what you just 00:14:51.370 --> 00:14:55.730 described, there was test code, and even though the secure element presumably 00:14:55.730 --> 00:15:00.850 worked, the test code didn't call on the secure element for the randomness, and 00:15:00.850 --> 00:15:01.190 it was, 00:15:00.992 --> 00:15:06.112 The real code, yeah, exactly. The real code didn't use the test path to get the 00:15:06.112 --> 00:15:08.192 randomness instead of the secure element. 00:15:07.330 --> 00:15:13.250 yeah, and is this the MK3 problem already, or is there more to it there as 00:15:13.250 --> 00:15:13.450 well? 00:15:14.342 --> 00:15:18.922 No, that's what happened on MK3. But even on MK3 could have been prevented with 00:15:18.922 --> 00:15:20.082 additional randomness. 00:15:21.372 --> 00:15:26.732 So there's something quite nice about entropy, which is that if you take bad 00:15:26.732 --> 00:15:32.052 entropy, so low entropy, not enough randomness in it, and you add to it 00:15:32.052 --> 00:15:37.072 very good entropy, or the other way around, I guess, easier to understand. If you 00:15:37.072 --> 00:15:43.012 take very good entropy, so completely quantum number generated noise, and 00:15:43.012 --> 00:15:46.912 you add to it bad entropy, like just the word hello, it doesn't matter. 00:15:47.092 --> 00:15:50.192 Like you do not weaken entropy. Entropy only gets stronger. Entropy just 00:15:50.192 --> 00:15:55.202 increases if you add it. That's a very nice property. And that means what you can 00:15:55.202 --> 00:15:59.962 do is you can take, once as a device that's trying to generate a key, you can 00:15:59.962 --> 00:16:03.442 take the entropy from the skewer element, and then you can start adding other 00:16:03.442 --> 00:16:08.632 stuff to it. And the coldcard was doing that a little bit, but not enough. 00:16:04.740 --> 00:16:05.180 Right. 00:16:07.880 --> 00:16:09.260 The MK3 also. 00:16:10.272 --> 00:16:12.192 I think so, yes. 00:16:14.142 --> 00:16:19.622 I'm not sure. I think, yes, the amp-key3 added a little bit about the timing of 00:16:19.622 --> 00:16:20.802 where it was in the boot sequence. 00:16:22.612 --> 00:16:26.512 Because if you just take the Python random number generator that they used 00:16:26.512 --> 00:16:31.432 without any other data, then they would have all had the same seed because it was 00:16:31.432 --> 00:16:35.372 a deterministic random number generator. This always produces the same thing 00:16:33.620 --> 00:16:34.800 Oh, right. Okay. 00:16:35.372 --> 00:16:39.172 given the same input. So they already, in a way, added a little bit of entropy, 00:16:39.272 --> 00:16:43.822 but it was just not enough. But typically what you do is you generate your seed, 00:16:44.022 --> 00:16:48.602 or sorry, you generate some entropy with one source, and then you XOR, it's like 00:16:48.602 --> 00:16:52.722 an addition, essentially, another source of entropy into it, and you just keep 00:16:52.722 --> 00:16:54.302 doing that with other sources. 00:16:54.482 --> 00:16:59.632 And these other sources can be, well, on a normal computer, you can take a 00:16:59.632 --> 00:17:05.432 screenshot off your desktop, you can measure, you can read a bunch of files, just 00:17:05.432 --> 00:17:06.812 random files and hash those. 00:17:08.772 --> 00:17:13.372 You can look at mouse movements. I don't know if people used PGP back in the 90s, 00:17:13.472 --> 00:17:18.932 but then you'd have to wiggle your mouse for like a minute for it to have enough 00:17:18.932 --> 00:17:24.142 entropy to create a secure PGP key. I don't know if that was actually true or 00:17:22.150 --> 00:17:27.920 Yeah, also with the original paper wallet websites 00:17:24.142 --> 00:17:25.042 just therapeutic, but 00:17:27.920 --> 00:17:31.380 that you had in like 2013, 2014, that was also a thing. 00:17:31.852 --> 00:17:35.572 yeah, but some of these paper wallets were highly insecure despite that. 00:17:36.140 --> 00:17:39.980 I know I'm not recommending them, but I'm just pointing out that was like a thing 00:17:37.022 --> 00:17:37.422 Yeah, 00:17:39.980 --> 00:17:42.530 back then. And should 00:17:40.672 --> 00:17:43.312 so mouse movement makes sense. Now, the problem with hardware wallets is they 00:17:43.312 --> 00:17:48.552 have less of that, right? Because they are isolated devices, they have very 00:17:48.552 --> 00:17:52.852 little software, so the file system is very predictable. It's not like you can 00:17:52.852 --> 00:17:57.752 just look at somebody's desktop background or whenever they last opened their 00:17:57.752 --> 00:17:59.972 email. There's none of that on the hardware wallet. 00:18:00.072 --> 00:18:05.972 It's much more sterile, much more similar. So it probably 00:18:05.972 --> 00:18:09.172 wouldn't be enough to just look at random things on the hardware wallet. The 00:18:09.172 --> 00:18:12.232 hardware wallet also doesn't know the actual time in the universe. It just knows 00:18:12.232 --> 00:18:16.202 how long it's been awake. But that's typically very short because you're just 00:18:16.202 --> 00:18:21.692 creating a new one. So things you could probably do is have a 00:18:21.692 --> 00:18:23.872 gravity sensor or accelerometer. 00:18:24.192 --> 00:18:27.592 You know, your phone knows which side is up because it knows which way the 00:18:27.592 --> 00:18:31.612 gravity is pulling on the sensor. And so if you just tell the user to rotate 00:18:31.612 --> 00:18:35.332 their device a couple of times and you have such a sensor, that could be an 00:18:35.332 --> 00:18:36.512 additional source of entropy. 00:18:38.442 --> 00:18:41.222 We just tell the user, like, shake the device for, like, two seconds. 00:18:42.582 --> 00:18:46.882 And you just add that to what the secure element is giving. Some hardware 00:18:46.882 --> 00:18:50.062 wallets, I think, nowadays have cameras. Those are great, too, for entropy. 00:18:50.832 --> 00:18:54.372 Because they just take, essentially, they just take photons from the universe. 00:18:54.872 --> 00:18:59.032 And these are all just completely unique. Assuming the camera is working, right? 00:18:59.072 --> 00:19:02.772 If the camera is black, like there's nothing coming in, well, then they're all 00:19:02.772 --> 00:19:03.092 the same. 00:19:04.152 --> 00:19:07.372 So you would never want to rely on any of these single sources. The sensor is 00:19:07.372 --> 00:19:12.132 broken, it's not giving random data, then you still have a problem. So if they 00:19:12.132 --> 00:19:17.322 had done that, that would have compensated for this, basically. But on the MK4, 00:19:17.402 --> 00:19:21.582 there was an even better situation, in theory, because they had multiple secure 00:19:21.582 --> 00:19:25.462 elements. And they were combining entropy from all three of them. 00:19:26.012 --> 00:19:27.112 They just did it wrong. 00:19:29.510 --> 00:19:35.020 we... About the MK3 real quick, because that's the worst one, 00:19:35.300 --> 00:19:39.180 the one that's worst effective. So I think what we just described about the test 00:19:39.180 --> 00:19:43.680 code and all that, that's true for all of them, right? For all reasons, once, but 00:19:43.512 --> 00:19:47.672 Yeah, that's the fundamental thing that went wrong. What I just described after 00:19:43.680 --> 00:19:44.520 then some added, 00:19:46.580 --> 00:19:47.660 yeah, but then some, 00:19:47.672 --> 00:19:49.772 this is like, what could have made it less bad? 00:19:49.880 --> 00:19:55.180 yeah, but then some did make it less bad, right? So how do you know the 00:19:55.180 --> 00:19:59.280 differences between like what else went wrong or didn't go wrong or what 00:19:56.982 --> 00:19:57.382 Yeah. 00:19:59.280 --> 00:20:02.860 mitigation did some of the wallets still have? 00:20:01.342 --> 00:20:05.862 Yeah, so what happened in the MK4 is that they did add more entropy, namely from 00:20:05.862 --> 00:20:09.942 these other secure elements. And if they had done that correctly, namely adding 00:20:09.942 --> 00:20:13.782 all the entropy from the other secure elements, then there would not have been a 00:20:13.782 --> 00:20:17.142 problem at all, because as long as one of them works, you're good. 00:20:18.170 --> 00:20:21.730 Okay, so they did not do that correctly either. So what did they do then? 00:20:18.722 --> 00:20:19.562 But they didn't. 00:20:20.832 --> 00:20:26.172 No. They took some entropy from these other devices, from these other secure 00:20:26.172 --> 00:20:29.792 elements, but then they trimmed it. So they only took, like, I think it was four 00:20:29.792 --> 00:20:33.312 bytes of it. 4 times 8 is 32 bits. 00:20:34.812 --> 00:20:37.872 So they had only 32 bits of real extra entropy. 00:20:39.720 --> 00:20:42.020 So they took four bits out of how many? 00:20:43.522 --> 00:20:49.162 Well, they could have taken infinity, but let's say normally you'd want a seed 00:20:49.162 --> 00:20:55.142 that's 256 bit, so 32 bytes. So they could have taken 00:20:55.142 --> 00:21:00.702 32 bytes from one of the secure enclaves, taken another 32 bytes from the other 00:21:00.702 --> 00:21:02.582 one, and XOR all of them. 00:21:02.642 --> 00:21:07.082 So just take all the 32 bytes from each of the devices. But instead, they took 00:21:07.082 --> 00:21:11.642 only four. And I don't know why, because that is the kind of thing that I think 00:21:11.642 --> 00:21:17.012 anyone looking at that code would have spotted. But anyone knowing a little bit 00:21:17.012 --> 00:21:17.492 about entropy. 00:21:18.170 --> 00:21:23.940 Okay, and this effect, correct me if I'm wrong. I believe so that they took four 00:21:23.940 --> 00:21:29.420 bytes out of 32 for a reason that you don't understand. But then this was 00:21:29.420 --> 00:21:35.260 itself also hashed again, right? With the Yasmarang. That's just 00:21:35.260 --> 00:21:38.020 a MK4 and your specific feeling. 00:21:36.482 --> 00:21:40.922 Yeah, so the Yasmarang is this Python library. So the Yasmarang is this Python 00:21:38.140 --> 00:21:38.500 Is that correct? 00:21:40.922 --> 00:21:44.442 pseudorandom number generator. We talked about that in the milk set episode, 00:21:44.602 --> 00:21:49.532 about the general phenomena of a pseudorandom number generator. It takes some 00:21:49.532 --> 00:21:54.322 input. And it gives a random looking number, but it's actually, if you give the 00:21:54.322 --> 00:21:55.902 same input, you always get the same output. 00:21:56.002 --> 00:22:01.632 So it's not really random. And so if the input to that generator 00:21:57.940 --> 00:21:58.420 Yeah. 00:22:01.632 --> 00:22:07.612 is four bytes, essentially, four bytes of uniqueness, then you're only going 00:22:07.612 --> 00:22:11.602 to get four bytes of worth of entropy in the end. 00:22:13.242 --> 00:22:17.382 Because you essentially just have these four bytes and the pseudorandom number 00:22:17.382 --> 00:22:21.402 generator doesn't add anything. It's just four bytes in is four bytes out in 00:22:21.402 --> 00:22:21.942 terms of entropy. 00:22:24.260 --> 00:22:29.300 So this really does sound like it's disaster upon disaster upon disaster then. 00:22:30.682 --> 00:22:36.622 No, it's a disaster that could have been fixed in the MK4, could 00:22:36.622 --> 00:22:40.622 have been harmless in the MK4, but wasn't harmless because they didn't use the 00:22:40.622 --> 00:22:45.042 entropy they had, the extra entropy they had. They just didn't use it. So like 00:22:44.220 --> 00:22:46.700 Yeah, well, that's a second disaster then, right? 00:22:45.042 --> 00:22:47.102 you add two chips that could have given you... 00:22:48.512 --> 00:22:51.412 Yeah, I guess it depends on your definition of disaster. Yeah. 00:22:51.290 --> 00:22:54.010 How would you call it? Blunder? 00:22:55.872 --> 00:23:01.672 It's one disaster plus one bad implementation, 00:23:01.672 --> 00:23:02.532 I guess. I don't know. 00:23:03.972 --> 00:23:07.552 I don't know what the reason is why they only kept four bytes, but my guess would 00:23:07.552 --> 00:23:12.312 be that they did not have this intuition that good entropy plus bad entropy is 00:23:12.312 --> 00:23:18.092 good entropy. Because if you think, generally, if you think a nice cup of 00:23:18.092 --> 00:23:22.632 tea plus poison is just bad tea, right? 00:23:23.612 --> 00:23:26.992 But entropy doesn't work that way. You can just add as much badness or poison. So 00:23:26.992 --> 00:23:30.992 they might have just mistrusted these other secure devices. They're like, well, 00:23:31.412 --> 00:23:34.012 they're different manufacturers, but we don't fully trust them, so we don't use 00:23:34.012 --> 00:23:37.812 all of it, what's coming out of it. But that's the wrong intuition. 00:23:39.450 --> 00:23:43.450 Right. Let me pull this apart real quick just to make sure that I understand and 00:23:43.450 --> 00:23:48.630 then hopefully our listeners also. Because I do want to point out, it sounds to 00:23:48.630 --> 00:23:54.510 me there are three different mistakes that happened on different... 00:23:53.282 --> 00:23:55.822 Probably more, but there's two critical ones, yeah. 00:23:56.370 --> 00:24:01.890 Yeah, so the first one is that there was a bug in the firmware, in the code that 00:24:01.890 --> 00:24:06.710 made the COLDCARD use test codes, which therefore didn't pull the randomness from 00:24:06.710 --> 00:24:12.550 the secure element. That's one. We discussed that one. Two is only 00:24:12.550 --> 00:24:18.070 four bytes out of 32 were used when the secure elements were combined. 00:24:18.550 --> 00:24:22.270 Instead of just using all the randomness, they only use part of the randomness. 00:24:22.470 --> 00:24:23.970 And then the third mistake. 00:24:25.750 --> 00:24:30.770 Did I get this straight? Is that the Yasmarang thing is a pseudo-random, is not 00:24:27.662 --> 00:24:29.642 Yeah, so another way to put that is to say, 00:24:30.770 --> 00:24:34.950 even a random number generator at all, not a good one. So there were three 00:24:34.162 --> 00:24:37.942 well, that is part of the test code. The pseudo-random number generator is the 00:24:34.950 --> 00:24:36.030 mistakes in that sense. 00:24:37.942 --> 00:24:43.932 test code. So you basically take on the... Yes. 00:24:40.420 --> 00:24:42.210 Is that Yasmarang? 00:24:44.172 --> 00:24:49.632 So what happens is on the MK3, you take nothing, you don't take the 00:24:44.340 --> 00:24:45.320 Oh, okay. 00:24:49.632 --> 00:24:52.192 random number generator, and you just give it to Yasmarang. 00:24:53.152 --> 00:24:58.552 And on the MK4, I think you did that, plus you then added 00:24:53.670 --> 00:24:54.190 Okay. 00:24:58.552 --> 00:25:01.372 real secure elements, but you only added four bytes of them. 00:25:02.850 --> 00:25:05.030 Okay, I see. So then there's... 00:25:03.612 --> 00:25:07.972 And I think those did not go to the Yasmarang. So it's like you take nothing, you 00:25:07.972 --> 00:25:12.482 put it through Yasmarang, and then that's one source, and then you add another 00:25:12.482 --> 00:25:14.022 source, but you don't add the full source. 00:25:17.100 --> 00:25:17.620 Right. 00:25:17.112 --> 00:25:22.612 And that first one, I think, could have been missed in a security audit of that 00:25:22.612 --> 00:25:25.992 part of the code. The second, I don't understand it. 00:25:27.862 --> 00:25:31.082 I mean, of course, everything can be missed. And it depends on what you tell an 00:25:28.180 --> 00:25:28.700 Okay. 00:25:31.082 --> 00:25:34.822