Fix side-channel in BIP-39 mnemonic processing when unlocked
Please note that the following attack is possible only in case the attacker has the Trezor in physical possession and the device is in an unlocked state. In such cases, the attacker can also simply send the funds right away.
In earlier firmware versions of Trezor Model One, the function mnemonic_to_bits() was called to check the recovery seed integrity after Trezor was unlocked. This function was not constant-time and could lead to seed extraction by an attacker who was in physical possession of the unlocked device.
This has been fixed by removing the integrity check, which was redundant, because there is another, even stronger, integrity check already in place.
In earlier universal firmware versions of Trezor Model T, Safe 3 and Safe 5 the same function could be used after Trezor was unlocked to convert the BIP-39 recovery seed to binary form which is needed to derive particular keys.
This has been fixed by storing a binary copy of the BIP-39 recovery seed. The vulnerable function was also fixed by replacing binary search over the wordlist with a linear search to ensure the same number of comparisons.
As mentioned at the beginning, the attacker can also simply send the funds right away. Nevertheless, it is a violation of our threat model where Trezor displays the backup only once.
This attack concerns all Trezor One devices. It also concerns Trezor Model T, Safe 3 and Safe 5 running universal firmware with BIP-39 backup. It doesn't concern Trezor Safe 7 and it doesn't concern Model T, Safe 3 or Safe 5 that are either running bitcoin-only firmware or use SLIP-39 backup, which is the default on these devices.
修正済みの脆弱性
- Inability to cancel certain flows on pre-production firmware2025年10月31日
- Donjon's Trezor Safe 3 evaluation2024年11月12日
- Missing confirmation in the ECDHSessionKey call2023年11月26日
- XSS in Trezor Connect legacy versions2023年2月7日
- Insufficient field size check in Protobuf2021年7月12日
- XSS in Trezor Connect2020年8月3日