Cryptosystem designers frequently assume that secrets will be manipulated in closed, reliable computing environments. Unfortunately, actual computers and microchips leak information about the operations they process. This paper examines speciaec methods for analyzing power consumption measurements to aend secret keys from tamper resistant devices. We also discuss approaches for building cryptosystems that can operate securely in existing hardware that leaks information.

l3y carefully measuring the amourit of time required tm perforin private key operalions, attackers m a y t) P able to find fixed Diffie-IieUirian exponents, fact ,or RSA keys, aid break other crypt,osysteins. Against, a vrilnerablc system, t,he atlack is corriprit,atiorially inexpensive and ofteri requires only known ciphertext. Actual systems are potentially at risk, ind I idi ng cryptographic t okeris, net work-based cryptosystems, arid other applica1,ions where attackers can make reasonably accilrate timing measurements. Techniques for preventing the attack for RSA and Iliffie-Hellman are presented. Some cryptJosysterrrs will need to be revised to protect against thc: at,tack. and new protocols and algorithms may need to incorporate measures t o prevenl timing attacks.

Modern processors use branch prediction and speculative execution to maximize performance. For example, if the destination of a branch depends on a memory value that is in the process of being read, CPUs will try guess the destination and attempt to execute ahead. When the memory value finally arrives, the CPU either discards or commits the speculative computation. Speculative logic is unfaithful in how it executes, can access to the victim's memory and registers, and can perform operations with measurable side effects.Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices.While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak. * After reporting the results here, we were informed that our work partly overlaps the results of independent work done at Google's Project Zero.

The power consumed by a circuit varies according to the activity of its individual transistors and other components. As a result, measurements of the power used by actual computers or microchips contain information about the operations being performed and the data being processed. Cryptographic designs have traditionally assumed that secrets are manipulated in environments that expose no information beyond the specified inputs and outputs. This paper examines how information leaked through power consumption and other side channels can be analyzed to extract secret keys from a wide range of devices. The attacks are practical, non-invasive, and highly effective-even against complex and noisy systems where cryptographic computations account for only a small fraction of the overall power consumption. We also introduce approaches for preventing DPA attacks and for building cryptosystems that remain secure even when implemented in hardware that leaks.

Lessons learned from Meltdown's exploitation of the weaknesses in today's processors.