Frage zu Trezor Physical Security (Secondary Fault Injection Attack zum Auslesen von Flash 256 Bytes auf einmal)
- Dieses Thema hat 8 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 11 Monaten, 3 Wochen von
.
-
Beiträge
-
-
Ich habe eine Frage zur physikalischen Sicherheit des Trezor. Ich habe vor, mir einen Chipflüsterer zu besorgen und diesen Angriff selbst zu versuchen. Ich frage mich, ob es etwas gibt, das ich nicht sehe (wurde etwas getan, um dieses Problem zu entschärfen?). Bis jetzt habe ich Folgendes herausgefunden:
Früher gab es einen Angriff, der wie folgt ablief: Man machte einen Spannungsfehler bei 170μs in der STM32-Bootup-Sequenz, der den Chip in den RDP1-Modus versetzte, was es ermöglichte, das SRAM über den swd-Port auszulesen, und man bekam einen kompletten Dump des SRAM, der den Seed/Pin auf einem Gerät ohne Passphrase enthielt. Trezor hat dies in 2.1.0 behoben, indem es nichts im Sram speichert.
Dann kam kraken vorbei und [figured out](https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/) eine zweite Fehlerinjektion, die es ihnen ermöglichte, einen “Read Memory”-Befehl zu verwenden, der es ihnen erlaubte, im “integrierten Bootloader-Modus” des STM Flash-Inhalte von 256 Byte auf einmal auszulesen, indem sie weitere Fehler einfügten, nachdem der “Read Memory”-Befehl durch swd gesendet wurde.
Sobald man den verschlüsselten Flash-Inhalt hatte, konnte man alle Pins 0000-9999 in weniger als 2 Minuten in einem Offline-Angriff (außerhalb der Trezor-Hardware) ausprobieren.
Meine Frage ist: Wurde dieser Angriff in irgendeiner Weise entschärft, oder ist es so gut wie bewiesen, dass jeder, der derzeit eine Trezor-Wallet besitzt, keinen physikalischen Schutz hat, wenn er weder seine SD-Karte noch eine Passphrase verwendet hat?
-
For obvious reasons, whether this specific attack works or not, you should always prioritize keeping your physical Trezor device secure. It should be kept safe at all cost and funds should immediately be moved to a new wallet if you lose the device.
Something you can do if you are worried about someone potentially gaining physical access to your device is using a strong password (not one that can be guessed or brute forced).
This password acts as a 25th word for your seed, but is not stored on the device. With this in place physical access to the device itself should not be enough to gain access to funds. That being said you should still consider that an attacker might have managed to gain knowledge of the password through other attacks (for example a keylogger if you enter the password on your computer).
If someone does gain physical access to the device you can also make the attackers job harder by making sure you aren’t storing the PIN with the device and avoiding use of any PIN which is very easily guessable (like 1234 or 0000).
A secure PIN will mean the attacker will need to spend at least some amount of time executing an attack similar to the one described in the post and they will also need some amount of technical knowledge and equipment to execute it.
This means that someone just coincidentally finding the device while for example looking for other valuables will not be able to easily access the funds through the normal way with a PIN, giving you time to recover the wallet using your backup and transfer out all funds.
Either way you should always assume that anyone gaining physical access to your hardware wallet can probably gain access to your crypto. It is important to keep the device safe and to move the funds immediately if you find that the device is no longer safely in your possession.
-
-
> My question is, has this attack been mitigated at all
Yes… two changes were added to mitigate this attack
1. `sd-protect` that will encrypt your NAND using a key kept on SD not PIN
2. PIN increased to allow crazy long lengths (50 digits?!?!)If you implement #1 having physical access to your Trezor-T without the SD card makes it cryptographically impossible to decrypt NAND regardless of whether you are in RDP1 or not. #2 means you can just make the PIN long enough that it would take decades to decrypt instead of minutes. Remember, the NAND encryption uses an algorithm (bubble???) that is intended to make brute force attacks slow. 4 digit pins would usually be 1-2 seconds. The fact that it takes 2 minutes means the decrypt and test cycles take LOTS of time. Going through billions or trillions of PINS would take decades.
And finally, the original response still holds. Put a passphrase on it, and decrypted NAND still doesn’t give you funds.
-
-
-
You got your Trezor models confused. You seem to own a Trezor T, but the article is, for the most part, about Trezor One.
Now, the same problem reportedly exists in the whole STM32F family, so the question about mitigation is very relevant — and no, unless we’re talking 15 and more digit PIN, this actually is an unfixable hardware flaw.
But the difference is, from what I’ve heard, the STM32F427 in the Model T is much more difficult to voltage-glitch, possibly to the extent of making this attack non-viable.
Of course, “what I’ve heard” could very well be a matter of skill and/or some unrelated problem. So if you’re gonna try, and succeed, please come back and report your findings!
-
-
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
