Dev Corner: Security Updates 1.8.0 and 2.1.0 With Andrew Kozlik, Cryptography Specialist at Trezor

Matt: [00:00:11] Hello and welcome. My name is Matt and I’m at Trezor today. We would like to introduce you to a brand new type of content called Dev Corner, where we will meet interesting people, we will look behind the scenes of Trezor, and much more. I’m here with Andrew.

Andrew: [00:00:22] Hi Matt.

Matt: [00:00:24] Andrew is a dedicated cryptographer in a security team at Trezor. Andrew today I would like to talk to you about probably one of the main reasons for the recent firmware updates, and that’s the discovered vulnerabilities. What can you tell me about them? What is the nature of these issues?

Andrew: [00:00:37] So what all these vulnerabilities have in common is that they require the attacker to gain prolonged physical access to your device, which usually means stealing it, they also need specialized equipment and a high level of technical expertise.

Matt: [00:00:52] I’ve read the article from Stick, from the CTO at Trezor, and I believe that it was possible to eventually access PINs. Is that correct?

Andrew: [00:01:03] Yes, that was one of the attacks. What the researchers did there is they monitored the electromagnetic emissions of the Trezor during PIN checking, and the power consumption, and using this information they were able to guess the correct PIN after several unsuccessful PIN attempts. So the reason behind this was that the PIN was being stored in the flash memory in clear-text. Now that was something that we weren’t too happy about for quite some time and we were already making plans to encrypt the storage using the user’s PIN. That way the PIN is not actually stored anywhere, but you verify the PIN by trying to decrypt the storage. This means that there are no side channels to monitor which could reveal the correct PIN.

Matt: [00:01:50] When I think about it. What sense does it make to encrypt the storage with a PIN that has a low entropy?

Andrew: [00:01:57] Well, you’re correct that the PIN has low entropy. We recommend that users use a six-digit PIN which is one million possible combinations. But the user or the attacker, in this case, has only 16 attempts to enter the PIN before the storage gets wiped with all the sensitive information. So generally, they will not be able to guess the correct PIN in 16 attempts. That’s the first reason. The second one is that if an attacker were able to somehow convince the Trezor into thinking that it’s unlocked when the correct PIN was not actually entered. I think something like a fault injection attack. Then even if the attacker convinces the Trezor, he cannot use the Trezor because the seed is encrypted using the PIN which he does not know.

Matt: [00:02:48] Andrew perfect thanks for the explanation. The next issue that I would like to talk to you about is the one that was discovered or let’s say announced during the CCC conference. I believe that the team behind this managed to partially disable the read-protection on the STM32 chip by glitching the voltage during the exact moment during the boot. What can you tell me about this?

Andrew: [00:03:10] Yes, we always have the read protection set to the highest level, which is Level two, but they were able to decrease the read protection level by one level, which means that they are able to read the RAM but not the flash.

Matt: [00:03:24] But what is the benefit of getting access to the RAM? There shouldn’t be any sensitive information stored before the correct bin is entered.

Andrew: [00:03:32] Correct. However, the researchers utilized the fact that on Trezor One during the firmware upgrade we copy the sensitive information into RAM and at that moment they were able to read it out using the J-tag. So we solved this by not copying that information into RAM during the firmware upgrade which is what we already do on the Trezor T.

Matt: [00:03:54] So this is the same mechanism that is being used on the Model T.

Matt: [00:03:57] But let’s say backported onto the Trezor One to resolve this issue.

Andrew: [00:04:01] Precisely, we just backported the existing process.

Matt: [00:04:02] Perfect, thank you. Now there was a third attack. What can you tell me about this? Discovered by Colin O’Flynn.

Andrew: [00:04:08] Oh this was a neat one. So what he did is he created a USB request to read the USB descriptor from memory, and then he used electromagnetic fault injection to disable the size check on the USB request. And this way he was able to read past the memory location where the USB descriptor is located and even read out the sensitive data on the Trezor.

Matt: [00:04:32] So, how did you solve this issue?

Andrew: [00:04:35] We solved this by placing an invalid memory segment just before the sensitive data. That way if you read past anything that you’re allowed to read you hit this invalid memory segment and you won’t get to the sensitive data, but you’ll end up with a with an exception.

Matt: [00:04:52] That’s crazy. I believe that all three of these attacks are fairly sophisticated. When you come across an issue like this, do you consult the resolutions with someone? What is the procedure? How do you work this out?

Andrew: [00:05:03] Yes of course. In addition to the internal team that we have here, we also consult all of our fixes with external consultants. Jochen Hoenicke, Saleem Rashid you may know, and Christian Reitter. And of course with the person who reported the issue.

Matt: [00:05:19] Andrew thank you for such extensive answers. It was my pleasure to talk to you I truly enjoyed our talk.

Andrew: [00:05:24] Thank you, Matt.

Matt: [00:05:25] And thank you all for watching. And if you would like to learn more please visit the Trezor Blog where you can find always more information. Thank you.


Article by channel:

Read more articles tagged: Cryptography