Cold start attack

The cold boot attack or cold boot attack ( English cold boot attack ) referred to in the cryptology a side-channel attack in which an attacker with physical access to the target computer contents of RAM reads after the system was turned off.

It is based on the data remanence in common RAM modules, in which the charge does not volatilize within milliseconds under certain conditions (or solely due to manufacturing tolerances), but gradually over a period of seconds to minutes and the data contents from the memory cells may after some time Minutes can still be read out successfully. Depending on the computer, such residues can be found after several seconds to minutes without power. Cooling the memory modules increases the remanence time drastically. After treating the modules with cold spray , the contents will last for many minutes.

In an attack presented at the USENIX conference in July 2008 , researchers from Princeton University managed to forensically read data immediately after a cold start . For the attack, the target computer is cold restarted with a minimal operating system. Because this mini-system uses little memory, it leaves as much of the memory as possible untouched, so the unused memory can still contain exactly what was stored there before the restart.

The cryptographic keys for encrypted data to which there was access at the moment of the system crash can then be extracted from the data read out. These could, for example, be the keys of full disk encryption systems.

Countermeasures

As a best practice to reduce the chances attack the overwriting of the key at the unhinging of the data carrier (for example, at shutdown of the system) is established, whereby the data are then at least safe. The Trusted Computing Group recommends as a countermeasure in the "TCG Platform Reset Attack Mitigation Specification" that the BIOS empties the contents of the main memory during the power-on self-test if an improper shutdown of the operating system was detected. At most, this prevents a compliant computer from being used for reading out.

One way to solve the underlying problem is to keep keys and the like only in the processor cache . This is embedded in an overall chip from which it is not easy to remove and which, when switched on, goes through an initialization that destroys the memory contents. It must be ensured that the cache content is not synchronized with the main memory as usual ("no-fill" mode). In practice, the method slows down the processor so that it cannot be used.

Another approach is to keep the key exclusively in the processor's registers . For Linux operating systems on x86-64 systems and Android on ARM systems, an implementation of this approach is available as part of the kernel in the form of a patch . For other x86-64 operating systems (e.g. Microsoft Windows ), this type of register storage can be achieved by using suitable hypervisor software. On a 64-bit processor with AES instruction set extension , from Core-i 'Westmere' processors since 2010, the loss of performance is negligible according to the developers.

Individual evidence

1. ↑ J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, Edward W. Felten: Lest We Remember: Cold Boot Attacks on Encryption Keys. Center for Information Technology Policy at Princeton, accessed January 10, 2012 . 
2. ↑ Trusted Computing Group (Ed.): TCG Platform Reset Attack Mitigation Specification; Specification Version 1.00, Revision 1.00 . May 15, 2008 (English, download as PDF [accessed January 10, 2012]).
3. ↑ Juergen Pabel: FrozenCache: Mitigating cold-boot attacks for Full-Disk-Encryption software. December 29, 2010, accessed on January 10, 2012 (English, recordings: MP4 Video , MP3 Audio , Vorbis Audio ( OGG ; 26.8 MB)). 
4. ↑ Jens Neuhalfen: Frozen Cache: Countering Cold-Boot attacks? (No longer available online.) In: neuhalfen.name. January 15, 2009, archived from the original on November 22, 2011 ; accessed on January 10, 2012 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  
5. ↑ ^{a b} TRESOR Runs Encryption Securely Outside RAM. Chair 1 for Computer Science, University of Erlangen-Nürnberg, accessed on June 7, 2013 (English): “Running TRESOR on a 64-bit CPU that supports AES-NI, there is no performance penalty compared to a generic implementation of AES and the supported key sizes are 128, 192 and 256 bits (full AES). " 
6. ↑ Intel® Advanced Encryption Standard (AES) Instructions Set - Rev 3.01. Intel Inc., accessed August 2, 2014 . 
7. ↑ Tilo Müller: TRESOR: Encrypt hard drives securely. December 29, 2011, accessed on January 10, 2012 (recordings: MP4 video , MP3 audio ).