In cryptography, a timing attack is a side-channel attack in which the attacker attempts to compromise a cryptosystem by analyzing the time taken to execute cryptographic algorithms. Every logical operation in a computer takes time to execute, and the time can differ based on the input; with precise measurements of the time for each operation, an attacker can work backwards to the input.
Information can leak from a system through measurement of the time it takes to respond to certain queries. How much this information can help an attacker depends on many variables: cryptographic system design, the CPU running the system, the algorithms used, assorted implementation details, timing attack countermeasures, the accuracy of the timing measurements, etc.
Timing attacks are often overlooked in the design phase because they are so dependent on the implementation and can be introduced inadvertently with compiler optimizations. Avoidance of timing attacks involves design of constant-time functions and careful testing of the final executable code.
A timing attack is an example of an attack that exploits the data-dependent behavioral characteristics of the implementation of an algorithm rather than other mathematical properties of the algorithm.
Many cryptographic algorithms can be implemented (or masked by a proxy) in a way that reduces or eliminates data dependent timing information: consider an implementation in which every call to a subroutine always returns in exactly x seconds, where x is the maximum time it ever takes to execute that routine on every possible authorized input. In such an implementation, the timing of the algorithm leaks no information about the data supplied to that invocation. The downside of this approach is that the time used for all executions becomes that of the worst-case performance of the function.
Timing attacks are practical in many cases:
- Timing attacks can be applied to any algorithm that has data-dependent timing variation. Software run on a CPU with a data cache will exhibit data-dependent timing variations as a result of memory looks into the cache. Some operations, such as multiplication, may have varied execution time depending on the inputs. Removing timing-dependencies is difficult in some algorithms that use low-level operations that frequently exhibit varied execution time.
- Finding secrets through timing information may be significantly easier than using cryptanalysis of known plaintext, ciphertext pairs. Sometimes timing information is combined with cryptanalysis to increase the rate of information leakage.
The execution time for the square-and-multiply algorithm used in modular exponentiation depends linearly on the number of '1' bits in the key. While the number of '1' bits alone is not nearly enough information to make finding the key easy, repeated executions with the same key and different inputs can be used to perform statistical correlation analysis of timing information to recover the key completely, even by a passive attacker. Observed timing measurements often include noise (from such sources as network latency, or disk drive access differences from access to access, and the error correction techniques used to recover from transmission errors). Nevertheless, timing attacks are practical against a number of encryption algorithms, including RSA, ElGamal, and the Digital Signature Algorithm.
In 2003, Boneh and Brumley demonstrated a practical network-based timing attack on SSL-enabled web servers, based on a different vulnerability having to do with the use of RSA with Chinese remainder theorem optimizations. The actual network distance was small in their experiments, but the attack successfully recovered a server private key in a matter of hours. This demonstration led to the widespread deployment and use of blinding techniques in SSL implementations. In this context, blinding is intended to remove correlations between key and encryption time.
Some versions of Unix use a relatively expensive implementation of the crypt library function for hashing an 8-character password into an 11-character string. On older hardware, this computation took a deliberately and measurably long time: as much as two or three seconds in some cases. The login program in early versions of Unix executed the crypt function only when the login name was recognized by the system. This leaked information through timing about the validity of the login name, even when the password was incorrect. An attacker could exploit such leaks by first applying brute-force to produce a list of login names known to be valid, then attempt to gain access by combining only these names with a large set of passwords known to be frequently used. Without any information on the validity of login names the time needed to execute such an approach would increase by orders of magnitude, effectively rendering it useless. Later versions of Unix have fixed this leak by always executing the crypt function, regardless of login name validity.
Two otherwise securely isolated processes running on a single system with either cache memory or virtual memory can communicate by deliberately causing page faults and/or cache misses in one process, then monitoring the resulting changes in access times from the other. Likewise, if an application is trusted, but its paging/caching is affected by branching logic, it may be possible for a second application to determine the values of the data compared to the branch condition by monitoring access time changes; in extreme examples, this can allow recovery of cryptographic key bits.
The 2017 Meltdown and Spectre attacks which forced CPU manufacturers (including Intel, AMD, ARM, and IBM) to redesign their CPUs both rely on timing attacks.[circular reference] As of early 2018, almost every computer system in the world is affected by Spectre, making it the most powerful example of a timing attack in history.
The following Visual Basic code demonstrates a typical insecure string comparison which stops testing as soon as a character doesn't match. For example, when comparing "ABCDE" with "ABxDE" it will return after 3 loop iterations:
Function InsecureCompare(StrA As String, StrB As String, length As Integer) As Boolean Dim result As Boolean For i = 1 To length If Mid(StrA, i, 1) <> Mid(StrB, i, 1) Then Exit For Next result = (i > length) InsecureCompare = result End Function
By comparison, the following version runs in constant-time by testing all characters and using bitwise operations to test without conditional jumps:
Function SecureCompare(StrA As String, StrB As String, length As Integer) As Boolean Dim result As Boolean For i = 1 To length result = result Or (Asc(Mid(StrA, i, 1)) Xor Asc(Mid(StrB, i, 1))) Next SecureCompare = Not result End Function
Timing attacks are easier to mount if the adversary knows the internals of the hardware implementation, and even more so, the cryptographic system in use. Since cryptographic security should never depend on the obscurity of either (see security through obscurity, specifically both Shannon's Maxim and Kerckhoffs's principle), resistance to timing attacks should not either. If nothing else, an exemplar can be purchased and reverse engineered. Timing attacks and other side-channel attacks may also be useful in identifying, or possibly reverse-engineering, a cryptographic algorithm used by some device.
This article includes a list of references, but its sources remain unclear because it has insufficient inline citations. (March 2009) (Learn how and when to remove this template message)
- "BearSSL – Constant-Time Crypto". www.bearssl.org. Retrieved 10 January 2017.
- See Percival, Colin, Cache Missing for Fun and Profit, 2005.
- Bernstein, Daniel J., Cache-timing attacks on AES, 2005.
- Meltdown (security vulnerability)
- Paul C. Kocher: Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems. CRYPTO 1996: 104–113 (https://www.paulkocher.com/TimingAttacks.pdf pdf file])
- David Brumley and Dan Boneh: Remote timing attacks are practical. USENIX Security Symposium, August 2003. pdf file
- Colin Percival: Cache Missing for Fun and Profit, 13 May 2005 (pdf file)
- Lipton, Richard; Naughton, Jeffrey F. (March 1993). "Clocked adversaries for hashing". Algorithmica. 9 (3): 239–252. doi:10.1007/BF01190898. Retrieved 2 September 2008.