[ad_1]
Hardware wallets are devices used exclusively to store the highly sensitive cryptographic information that authenticates cryptocurrency transactions. They are useful if one is worried about the compromise of a general purpose computer leading to the loss of such secrets (and thus loss of the funds the secrets identify). The idea is to move the critical data away from a more vulnerable network-connected machine and onto a device without a network connection that is unable to run other software. When designing a security focused hardware devices like hardware wallets it’s important to consider what threats need to be protected against. More sophisticated threats warrant more sophisticated defenses and at the extreme end these precautions can become highly involved. In 2015 when [Jochen] took a look around his TREZOR hardware wallet he discovered that maybe all the precautions hadn’t been considered.
Let’s start with a discussion of some common threats to a microcontroller and how they might be mitigated. When developing firmware it’s pretty common to use a serial console to print debug messages. It’s obvious that if this is enabled when the final product is shipped, you shouldn’t print out sensitive information (like private keys) during operation, lest someone connect a serial adapter and see the messages! Of course you can try hiding the physical pins the serial console is connected to, but the common wisdom about such “security by obscurity” is that it is ineffective and thus insufficient. What about wherever you physically store the data? If it’s in an external device (SD card, NAND/NOR flash, EEPROM, etc) can someone tap the lines between that and the microprocessor and see the key-related messages pass by? Can they just remove the external storage and read it themselves? They probably can, in which case you can encrypt the data, but then where do you put that key? Some microcontrollers have “one time programmable” (OTP) flash onboard for saving such secrets. For many products storing keys in OTP, disabling debug access, and turning off the debug console is sufficient. But for a security focused product like a hardware wallet, whose primary feature is security, more stringent measures are required.
Side channel attacks focus on exploiting systems based on the system itself instead of the software running on it. The full scope of possible side channels is quite wide but in this case we’re interested in using a technique called power analysis to examine what code a microcontroller is running and what data it is handling. When a CPU is executing code its power consumption changes minutely depending on what instructions it’s running. With sufficiently sensitive tools (an oscilloscope and shunt resistor can be good enough) you can measure these fluctuations and over time and capture a detailed picture of what the CPU is up to. There are both software and hardware countermeasures to protect against power analysis but those are somewhat out of scope for the moment.
Back to [Jochen’s] TREZOR. At the time of their post the device worked by storing a seed value which was used to compute public and private keys. When it was connected to a computer it could be asked to provide public keys to participate in transactions. [Jochen] noticed that if they monitored the device’s power consumption with a cheap scope and shunt resistor, the algorithms that generated the keys were easy to discern. The display on the device obscured the CPUs activity somewhat but during certain phases of the process it was possible to observe power spikes caused by the algorithms which were used to compute the public and private keys from the original seed. By counting the timing of these fluctuations and using reference a power signature from another device it was possible to recover the series of 1s and 0s which comprised the private key, at which point the device is ineffective. [Jochen’s] concern was that an attacker could snag a TREZOR, watch while it quickly generated keys, then return it without the owner noticing. Take a read through [Jochen’s] post for a much more thorough explanation of what’s going on.
[ad_2]
Source link
