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

https://medium.com/media/499de4343767daea93c5ad4dba5731bf/href

Matt: [00:00:11] Hello and welcome. My name is Matt and I’m at today. We would like to introduce you to a brand new type of content called Dev Corner, where we will meet interesting , 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 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 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 where you can find always more information. Thank you.

About Us

Created by SatoshiLabs in 2014, the Trezor One is the original and most trusted hardware wallet in the world. It offers unmatched security for cryptocurrencies, password management, and serves as the second factor in Two-Factor Authentication. These features combine with an interface that is easy to use whether you are a security expert or a brand new user.

Trezor Model T is the next-generation hardware wallet, designed with the benefits of the original Trezor in mind, combined with a modern and intuitive interface for improved user experience and security. It features a touchscreen, faster processor, and advanced coin support, as well as all the features of the Trezor One.


Dev Corner: Security Updates 1.8.0 and 2.1.0 With Andrew Kozlik, Cryptography Specialist at Trezor was originally published in Trezor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Post written by our friend SatoshiLabs and Syndicated from trezor.io
Ledger Nano S - The secure hardware wallet

Syndicated from trezor.io

Add a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.