 Hey guys. So, uh, who here likes locks? Yeah? Alright, who here likes safe locks? Yeah? Who here likes cracking safe locks? Yeah? Okay. So, you know, I have a safe. It's kind of similar to one of these. Um, it's a fairly decent size gun safe. Has an electronic lock on it. And one day I was thinking, gosh, I wonder how secure is that? Is it, you know, how better than the mechanical counterparts? So I started investigating, found a few things. Uh, first of all, from some context, what we're talking about here. We're talking about high security electronic safe locks, type 1. This is a UL listing. This is, these are decent locks that you're going to find on reasonably sized gun safes typically, often times in residences. What we're not talking about, we're not talking about the cheap crappy locks that you're going to find on hotel safes or fire safes or things like that. Those cheap crappy locks, you can often defeat those with a magnet or by spiking them with some wires or anything like that. The, uh, these high security locks are designed to be impervious to that. On the other hand, we're not also not talking about GSA locks. It's a bit of a different, uh, different topic. Um, so, look at two locks. The first of the locks is made by a company called Sergeant and Greenleaf. Sergeant and Greenleaf is a large reputable manufacturer of locks, both mechanical and electronic. They're about 150 years old. This particular lock, the first lock we're looking at, is the 6120. It's a bit of an older design, designed in the mid-90s. It's a UL listed lock. Um, it's still made and sold, at least as of late last year. So, the way this lock is designed, all of the logic exists inside of the safe. The only things outside of the safe are a keypad, which consists of a resistor ladder keypad and a user replaceable 9 volt battery. Inside the lock is where the microcontroller, the MTU, and the EEPROM exists, as well as a motor to drive an acne screw that will either extend or retract the bolt. So, what I, when I started looking at this, I thought I'd look at something called power analysis. This is a side channel attack. What you do here is place a resistor in series with the battery and the lock. And by monitoring the voltage across that resistor, we can learn how much current the lock is drawing at any particular time. And from that, we can learn something about the state of the lock. What this allows us to do in particular in this lock is monitor the data line between the MCU and the EEPROM. So, you can kind of imagine that this lock has something like a spy bus. We have a single data line going between the microcontroller and the EEPROM. And this data line is pulled up perhaps by a resistor. Well, when you have a higher voltage on that line, the voltage across that pull up resistor is going to be lower. So, your current drain is going to be low. And when you have a zero, a low voltage on that line, there will be a drop across that pull up resistor. So, the current will be, the current drain will be slightly increased by the lock. So, we can monitor the amount of current being consumed by the lock externally. We can learn then what's on the data bus. This is in fact a screenshot. I opened one of these locks up and probed both the actual data line as well as monitoring the amount of current being consumed by the lock in real time. The yellow trace is the actual data line and the blue trace is the current consumption. As you can see, each of these spikes represent one bit being clocked out of the EEPROM. And when the data line is high, it turns out that the current consumption is slightly lower, about 60 microamps lower than if there's a zero at that position in the EEPROM word being read out. All right. So, let's take a look at what this looks like in a video here, a video demo. All right. So, what we're going to do is we're going to enter any old code on the keypad. It doesn't matter what it is, it's definitely going to be the incorrect code. It doesn't matter what it is. Now, in the background, we have a scope monitoring the current being consumed by the lock. And each of these little bursts is a word being read out of EEPROM. Now, the key, again, the lock stores the code in EEPROM. So, what we're going to do is zoom in, look at the first couple of these bursts. Each of these little spikes is one bit being read out of the EEPROM. Again, this is just the current consumption. This is all done externally from the safe external to the lock. We go in, we zoom in and we can see that the first two digits for the lock are 8 and 0. We go over to the next word being read out of EEPROM. The next two digits in the actual key code are 1 and 9. And the final digits then you can see would be 4 and 5. Again, the lower current is a 1, higher current is a 0. So, by starting with any old key code, the wrong key code, we learned what the right key code was by watching the current consumption of the lock. So, let's go over back over to the lock, try that, 8, 0, 1, 9, 4, 5, that key code. And we see that the lock bolt retracts down at the bottom of the screen. So, yeah. So then, I thought, well, you know, that was a somewhat older lock. Again, it's still sold, but it was kind of an older design. I wonder how they improved. So, I got a newer lock from Sergeant and Greenleaf again. This is a Titan pivot bolt. This is part of the Titan family. Other locks in the family of the Titan D drive, basically the same internals. Same exterior components. It's a plug and play replacement for one of these older locks. Still a passive keypad on the outside, still access to the battery. Inside it's a little bit different. Instead of having a separate microcontroller and EEPROM, we have a single chip doing everything. We have a STM-8, which includes a few K of onboard EEPROM. So, the old attack from the 61-20, the older Sergeant and Greenleaf lock. Now, it doesn't work here. However, I was poking around and eventually came to realize that when the Titan lock starts a comparison of the code that was entered by the user to the code that stored in EEPROM, so to the true code, it does it one digit at a time. And if there's a mismatch, it will abort, break out of that comparison loop, and then go off and buzz and do some other stuff. So, you might be thinking, gosh, that sounds like a timing attack, and indeed it is. In fact, there is a 28 microsecond difference per digit, depending on whether or not that digit is the correct digit. So, what this lets us do is far more efficiently search the key space for the correct key code. Now, to do this, you need some markers. You need to know when to start the clock and when to end the clock. Turns out that once again, we can bring power analysis back into the fold, like from the older lock. We have a great marker for the start of a timer. This corresponds to when the user presses the pound key to indicate that they have entered the code. 29.6 milliseconds or so later, there is a second rise in the amount of current being consumed by the lock. And it's this difference between that first current marker and that second current marker that we can use to infer whether or not we have a match for a particular digit or a mismatch for a digit. That time will vary by 28 microseconds. Alright, so how this would work? What you do, if you're using this to your advantage, is you would start with some arbitrary key code. Then you would cycle through the various values for the first digit, zero through nine. And you would keep the other digit values fixed. So you'd go zero, et cetera, et cetera, et cetera, then one, et cetera, et cetera, et cetera. And then you would look at the time required to go between those two current markers and whichever value for that digit had the longest time delay, that's the correct value for that digit. Alright, so in this example here, we found that the first digit is nine. Alright, once we found the first digit, we repeat the cycle with the second digit. We use the digit we just found then cycle the second digit through zero, then one, then two, then three, then four, et cetera, holding the remaining digits fixed. And repeat this again off until the fifth digit. So this allows us to much more efficiently search for, through the possibilities for this key code. The sixth digit is a special case. We'll get to that in a little bit. But the time you attack it works great for the first five digits. Now, you might be wondering, well, how does that actually look on the real world? And this is how it looks. This is looking at a zoomed in version of the second current rise. This is the second marker that we're using. And at the top of the scope shot, we can see overlaid different runs where there was, there was zero digits correct and then one digit correct in sequence. And then where there were two digits, the first two digits were accurate and the remaining were wrong. And then where there were three accurate and then wrong, four and five. So as we got more digits correct in series, we extended out our time delay. It's still a problem, though, because this lock includes a feature called a penalty lockout. If you enter the wrong key code five times in a row, you'll lock you out and prevent any additional attempts for 10 minutes. Now, you can't get around this by pulling the ballot or you can't get around it by, you know, accelerating the clock or something like that. You really have to wait 10 minutes once this has started. So I thought, well, I wonder if you could prevent it from starting in the first place. I wonder if perhaps we could do something like cut power to the lock prior to it writing this incorrect attempt count to EEPROM. And so I did some investigation, got another STM8, just like the one that is in the lock, and fiddled with killing power to it at various times. But what I found was actually even better. So it turns out that if you start a right to an address in EEPROM on the STM8 and then you kill power to that micro controller between 500 microseconds and 2.5 milliseconds after the start of that right, what you'll be left with is not the original value, not the new value, you'll be left with zero. And so the reason this works is because in EEPROM in flash, before you can write a new value to a destination that already has a value, you need to erase that destination byte. And in the STM8, a little unusually, the erase value is zero. Oftentimes in other EEPROMs in flashes it'll be ff. But in the STM8 it's zero. And moreover, the lock firmware appears to treat zero as a valid value. So all we need to do is kill power to the MCU between 500 microseconds, 2.5 milliseconds after the right to that incorrect attempt counter starts. Alright, so it turns out, even better, we know exactly when to do that. That second current rise that we used for the timing attack ends up being actually the start of the right for the incorrect attempt account. So if we key on that, we can accomplish our goal. We can, first of all, we're able to get the voltage low enough quickly enough. If we start at a somewhat lowered voltage that's still valid, we can actually get below the brown out voltage for the microcontroller in about 600 microseconds. So we know we can get there once we start. The question is then when to start that power, cutting that power to the lock? And since we have that current rise from the start of the EEPROM right, the key off of that takes us about 500 microseconds to recognize what's happening and to then begin cut power to the lock with a very fast switch. In total, 1.1 milliseconds from when the right starts to when the lock is below the brown out voltage. Once it's below the brown out voltage, any pending part of the EEPROM erase cycle or right cycle will be aborted. 1.1 milliseconds of course, as well within our window between 500 microseconds and 2.5 milliseconds. So you put this all together and what this lets us do is have an infinite number of attempts to guess the key code. You go through say four attempts or five attempts and then you reset the key the invalid attempt count back to zero. So this allows us to both get the sixth digit and also more efficiently search for the first five digits. The reason it helps with the sixth digit is because we just want to brute force that. We want to go through and try knowing the first five digits, all the possibilities for the sixth digit. So we'll just go through, try each of them and every periodically we'll reset the invalid attempt count and just keep going through all 10 possibilities for that sixth digit. Alright, so attacking this lock I couldn't just do with a resistor. So the first lock I used to have a scope and a resistor, you know that's like first week freshman double electrical engineering class sort of stuff. This is a little more complicated in that I need to build a custom board to support this. It says a micro ram meter on it. This has some supports that can treat this to allow us to emulate key presses. This is essentially just allowing us to present different voltages to the lock emulating a certain key values. Also the power supply and control mechanism to allow us to cut power at very precise time. So we then look at the algorithm used in the lock. It's very similar to what we described earlier. We first use the timing attack to find the first five digits. We'll go through and try all possibilities for the all 10 possibilities for that first digit value, whichever one has the longest delay, that's the first digit, the actual first digit value. We use that first digit value and then try cycling through the second digit values, whichever of those has the longest delay, that's the second digit value and so on. And then we, like I mentioned before, we'll brute force that sixth digit by trying all 10 possibilities there all the while resetting the lock out attempt count periodically. So let's take a look at that. So here we have the support board. It's blue and we have the STM32 board. This is where the attack firmware is running on it. The STM32 is a little ARM Cortex-M4 with a pretty good ADC on it. The scope in the background is just monitoring the current consumption, just there for visual effect. As it cycles through the various possibilities for the key code, it has to do something over sampling. So in a real world environment there's noise so we want to try each of these potential combinations multiple times. And so for that reason this video is actually sped up by a factor of 10 to fit it in the presentation. Even so, the full attack in a fairly robust manner takes about 15 minutes, which is a huge improvement from the potential 3.8 years that a naive brute force attack would take on the lock. And as the attack firmware cycles through and finds the true values for each of these digits in the key code, eventually we'll reach the sixth digit. We'll be monitoring the buzzer line to figure out when it has the correct code because the lock will buzz in a different way depending on whether or not you have entered the correct or incorrect code. And once it detects the correct buzz it says oh we found the correct code and we'll stick with that and we'll then they flash a little green LED and allow that located key code to be replayed. There's a button on the board and when you hit the button it would then replay that identified key code. So that's what's going to happen right now. There it is. Found the final digit. The lock is locked. You can see I'm trying to pull it with my thumb. And we're going to hit the button. It's replaying the key code and the lock is opened. So there we go. Then after five seconds the lock will relock itself automatically. All right. So having said all that, burglars are not going to bother with this. They're just going to use a crowbar or the hydraulic jack from your garage or something like that. Maybe if they're really fancy they'll use a torch but that's really only like movie stuff. I think the more interesting thing here is perhaps applicability to other systems. We see other systems that have these sorts of lockout mechanisms. You know maybe phones or other locks. And I wonder if maybe there might be something similar that could be applied there. And you know the shame is that each of these issues is actually fairly easy to fix in software. Even the original lock which seemed like a hardware issue. It could be a trust in software if they just didn't store the data, the key code in clear text. I mean don't store your data in the clear. I think you know just you'd think that would be a common knowledge but I guess not. So then the timing attack what you could do to mitigate that would be to do your comparison in constant time. Don't abort your search or your comparison loop early. If there's a mismatch go up through all the way through the end. The EPROM manipulation a little more complicated. The way you'd get around that or the way you'd defend against this attack is to assume failure first. So assume that the user will enter the wrong code and increment that invalid attempt count first. And then if they ended up actually entering the right code then clear that out. Enter a zero for that. That would still leave you with the possibility of erasing it, forcing the erasure of that destination. But what you could do there is treat the erased value for whatever method, wherever you're storing this data flash or EPROM or wherever. Treat that value as an invalid value. So instead of treating zero as zero, you know why not treat that as invalid and maybe lock it harder. So the, she also disclosed that I've been trying to get Sergeant Greenleece's attention about this since February and they haven't been providing any useful response. So it's a bit disappointing but I'm hopeful that they'll go forward and make some improvements in the future. There are better locks out there I should mention. There's a federal standard for GSA approved locks. It's FL 2740B and this standard is designed to defend against this sort of attack. So if you really want a good electromechanical lock I would recommend some sort of GSA approved lock. They're kind of expensive though. So feel free to email me if you have any questions. So thanks guys.