Many of the security breaches that you read about are the results of software failures such as buffer overflow. But hardware is also vulnerable to attack. After Chris Eagle's keynote , the rest of the second day was taken up with Jasper van Woudenberg and Robert van Spyk of Riscure not only talking about some of these attack vectors but also demonstrating them. Riscure in general, and Jasper and Robert in particular, are hackers who use an attacker business model (cost/effort vs reward) to break devices to help their customers understand technological risk, which helps them manage their business risk and improve their products. Computer security is notorious for engineers coming up with solutions that "must be secure" because the engineer can't think of a way to break the security. Only by setting attackers on the problem can people like Pay TV companies have any idea how secure their products are. I remember reading that cable companies have a metric of the time from releasing a new set-top-box until cracked versions appear on eBay. Two years is the gold standard apparently. The day was spent on two different approaches to attacking hardware: Side channel analysis Fault injection Side Channel Analysis Side channel analysis (SCA) is an approach to attack that doesn't attempt to attack the cryptography directly, but looks at other things that might give a clue to what is going on. Such things as: Time Power consumption Electromagnetic radiation Light Sound Temperature In 1998, Cryptography Research (which is now part of Rambus) introduced power analysis, looking at the power consumed by a chip. To get cleaner signals, it is best to replace the actual power supply with either batteries or a much more stable power supply, and also to remove the decaps. If it sounds to you like it would be impossible to derive anything really useful from this, you would be wrong. The basic flow is to connect the chip to an oscilloscope and use a PC to drive the target device. The traces can then be aligned and signal processing can be used to increase the signal-to-noise ratio for better analysis. Jasper and Robert had a little board implementing AES encryption. They call it the piñata board since it gets hit a lot. It contains an ARM Cortex-M4 CPU with hardware crypto support. It was designed as a realistic training target for the week-long courses that they run. In the demo, they measured the power consumption at the 3.3V pin. They put the traces up on the screen and it was immediately obvious that there was something going on ten times. Since the AES algorithm contains ten rounds, it seemed likely that each trace corresponded to a round. By focusing in on a single round at a time it was possible to find bits from the key. Within a minute they read out the complete encryption key simply by analyzing the power consumption of the chip. This was a simpler task than if you tried to do it on the SoC in your smartphone, since there isn't anything else going on on the chip creating a lot of noise. In fact, one of their rules was to try and turn as much off as possible except the crypto itself to minimize that noise. Jasper and Robert gave a rapid overview of attacking DES. We were getting in just a few hours information that normally is spread out over a full-week course, including hands-on work actually implementing the algorithms. The main takeaway I got is that these side-channel approaches really can work and it is naive to assume they do not and not take countermeasures such as: Add noise by a noise generator, adding dummy operations, do operations in a random order Mask the cryptographic data with additional random data Confuse the alignment by random interrupts, pauses, or clock jitter Basically, implement more countermeasures than the attacker can handle, and then test them Fault Injection After lunch it was time for fault injection. The basic idea is to glitch the hardware and, hopefully, leave it in an insecure state. This can be done by running the chip out of spec, such as clock cycles that are too short, or lowering the operating voltage. This can also be used for differential fault analysis (DFA). An example of DFA is to run the encryption process, input a fault during the encryption, compare the correct and faulty results to learn some key bits, and repeat until all the key bits are found. Again they showed an example using the Piñata board. In the table above, the green lines are where the algorithm runs correctly, the yellow shows where the algorithm apparently ran correctly but the results was incorrect, and the red is where the number of times around the loop, which was meant to be 30, was wrong (and was only 29). A particularly vulnerable time for a system is during the secure boot. Typically the device will check that the boot code to be run is correctly cryptographically signed, and then run the code. If this process can be hijacked then it may be possible to run arbitrary code instead of the correct boot loader. Jasper and Robert told us about a time with a smart card that has a mode "answer to reset" when it sends the contents of a register that gives the cards capabilities, etc. By glitching the card during this process, they managed to get it so that it didn't halt at the end of the register, and sent out the entire contents of the memory on the card. Oops. Wrapping up, they had a couple of parting remarks. First, the rule of thumb is that "hardware implementations of crypto are harder to attack than software but they can't be updated." Put a chip in the field and it is a constant for ten years. "But my scope is going to be a lot more powerful in ten years." Previous: EDPS Cyber Security Workshop: "Don't Let Convenience Trump Security"![]()
![]()
↧