Torturing OpenSSL

Valeria Bertacco

• Valeria has a talk, and a demo, but of course the hardware isn’t co-operating.
• Cryptography is pervasive. It’s also big business. The direct value of companies like RSA and Verisign is tens of billions. The value of ecommerce companies is hundreds of billions.
• Asymmetric cryptography, RSA keys, rely on two large primes, with which ou perform clever maths.
• Cryptanalysis: poking the cryptography with a stick.
• 2009 we proved you could brute-force 768-bit keys, but it required computation-years to do reliably.
• Side-channel attacks: you measure the time required to encrypt, and guess the key form that. We no pad encryption to avoid this.
• Fault-based: a faulty CPU may leak information in the form of errors.
• Attacks via Transient Faults: when transistors give the wrong values intermittently.
• These are normal events, but normally last <1 clock cycle, but in bad cases will propogate up the stack to the software.
• The probability is very low. But they can be triggered by solar particles (alpha particles, which is dependent on altitude), and are non-predictable.
• As transistors have shrunk, they have become more susceptible to this sort of fault, because they’ve become more fragile.
• As we get smaller we may even get to the point where a sinle alpha particle can flip many transistors.

Forcing Faults Reliably

• A transient fault that occurs when performing the handshake may leak information through the corrupt response. If you can do enough corrupted handshakes, you may get a lot of informaiton.
• Our testbed is an FPGA board running a SPARC v8@40MHz, running Debian. We munt it with a voltage controller to induce faults.
• When you drop voltage, the multiplier, which is the most sensitive component, will have problems. If we gofrom 1.5V to 1.0V always fails. But if you drop it to, say, 1.3V, it will fail intermittently.
• OpenSSL uses a fast algorithm to encrypt; it then verifies the encrypted data, and falls back to a slower, more reliable algorithm if that doesn’t work.
• The attacker collects the faulty signatures over the time. It relies on the fact the slow, reliable algorithm breaks the message into windows. The attacker can collect leaked information window-by-window.
• This ends as a window-by-window brute force.
• But it means you are brute-forcing only, e.g. 4 bits instead of 1024 bits. 100 seconds per check, 2^6 checks in the worst case.
• This makes it quite a lot easier to break the server’s private key.
• In the example, 8,800 signatures were collected in a few hou rs, and then analyzed. They 1024-bit private key was cracked in 100 HOURS.
• Apparently 60 degrees C is about optimal for creating key-cracking errors with the hardware she’s using. Temperature is harder to control that voltage, though.
• OpenSSL 0.9.8i was the victim in this case; before giving the talk, Valeria supplied a patch to stop using the fall-back algorithm, which helps avoid that specific attack.

General Advice

• Keep crypto libraries up to date.
• Overclocking IS A SECURITY RISK.
• Overheating IS A SECURITY RISK.
• Unreliable power IS A SECURITY RISK.

Brilliant session.