Cold boot attack

In cryptography, a cold boot attack (or to a lesser extent, a platform reset attack) is a type of side channel attack in which an attacker with physical access to a computer is able to retrieve encryption keys from a running operating system after using a cold reboot to restart the machine.[1][2] The attack relies on the data remanence property of DRAM and SRAM to retrieve memory contents that remain readable in the seconds to minutes after power has been removed.[2][3]

Description

To execute the attack, a running computer is cold-booted. A removable disk is then immediately used to boot a lightweight operating system, which is then used to dump the contents of pre-boot physical memory to a file.[4] Alternatively, the memory modules are removed from the original system and quickly placed in a compatible machine under the attacker's control, which is then booted to access the memory. Further analysis can then be performed against the information that was dumped from memory to find various sensitive data, such as the keys contained in it. Automated tools are now available to perform this task for attacks against some popular encryption systems[5] using various forms of key finding attack.

The attack has been demonstrated to be effective against full disk encryption schemes of various vendors and operating systems, even where a Trusted Platform Module (TPM) secure cryptoprocessor is used.[2] This is because the problem is fundamentally a hardware (insecure memory) and not a software issue. While the focus of current research is on disk encryption, any sensitive data held in memory is vulnerable to the attack.[2]

Liquid nitrogen or compressed air cans can be improvised to cool memory modules, and thereby slow down the degradation of volatile memory

With certain memory modules, the time window for an attack can be extended to hours by cooling them with freeze spray. Furthermore, as the bits disappear in memory over time, they can be reconstructed, as they fade away in a predictable manner.[2] In the case of disk encryption applications that can be configured to allow the operating system to boot without a pre-boot PIN being entered or a hardware key being present (e.g. BitLocker in a simple configuration that uses a TPM without a two-factor authentication PIN or USB key), the time frame for the attack is not limiting at all.[2]

This is not the only attack that allows encryption keys to be read from memory—for example, a DMA attack allows physical memory to be accessed via a 1394 DMA channel. Microsoft recommends changes to the default Windows configuration to prevent this if it is a concern.[6]

The ability to execute the cold boot attack successfully varies considerably across different systems, types of memory, memory manufacturers and motherboard properties, and is more difficult to carry out than software-based methods or a DMA attack.[7]

Mitigations

Full memory encryption

Encrypting random access memory (RAM) mitigates the possibility of an attacker being able to obtain encryption keys or other material from memory via a cold boot attack. This approach may require changes to the operating system, applications, or hardware. One example of hardware-based memory encryption was implemented in the Microsoft Xbox,[8].

Another related example is memory scrambling used to minimize undesirable parasitic effects of semiconductors as a feature of modern Intel Core processors.[9][10][11][12] However, because the scrambling is only used to decorrelate any patterns within the memory contents, the memory can be descrambled via a descrambling attack.[13][14] Hence, memory scrambling is not a viable mitigation against cold boot attacks.

Software-based full memory encryption is similar to CPU-based key storage since key material is never exposed to memory, but is more comprehensive since all memory contents are encrypted. There are multiple academic papers describing methods of encrypting memory and at least one commercial product from PrivateCore.[15][16][17]

More recently, several papers have been published highlighting the availability of security-enhanced x86 and ARM commodity processors.[18][19] In that work, an ARM Cortex A8 processor is used as the substrate on which a full memory encryption solution is built. Process segments (for example, stack, code or heap) can be encrypted individually or in composition. This work marks the first full memory encryption implementation on a general-purpose commodity processor. The system provides both confidentiality and integrity protections of code and data which are encrypted everywhere outside the CPU boundary.

Dismounting encrypted disks

Most disk encryption systems overwrite their cached encryption keys as encrypted disks are dismounted. Therefore, ensuring that all encrypted disks are dismounted (secured) when the computer is in a position where it may be stolen may eliminate this risk, and also represents best practice.[20] This mitigation is typically not possible with the system disk that the operating system is running on.

Advanced encryption modes

The default configuration for Bitlocker uses a TPM without a boot PIN or external key—in this configuration, the disk encryption key is retrieved from the TPM transparently during the operating system startup sequence without any user interaction. Consequently, the Cold Boot Attack can still be executed against a machine with this configuration, even where it is turned off and seemingly safely secured with its keys in the TPM only, as the machine can simply be turned on before starting the attack.

Two-factor authentication, such as a pre-boot PIN or a removable USB device containing a startup key together with a TPM, can be used to work around this vulnerability in the default Bitlocker implementation.[21][22] In this mode, a PIN or startup key is required when turning the machine on or when waking from hibernation mode (a power off mode). The result is that once the computer has been turned off for a few minutes, the data in RAM will no longer be accessible without a secret key; the attack can only be completed if the device is obtained while still powered on. No additional protection is offered during sleep mode (a low power mode) as the key typically remains in memory with full disk encryption products and does not have to be re-entered when the machine is resumed.

Power management

Shutting down a computer causes a number of well-known encryption software packages to dismount encrypted data and delete the encryption keys from memory. When a machine is shut down or loses power and encryption has not been terminated (such as in the event of sudden loss of power) data may remain readable from tens of seconds to several minutes depending upon the physical RAM device in the machine. Ensuring that the computer is shut down whenever it might be stolen can mitigate this risk.[2][23]

For systems using the hibernation feature (ACPI state S4), the encryption system must either dismount all encrypted disks when entering hibernation, or the hibernation file or partition would need to be encrypted as part of the disk encryption system.

By contrast sleep mode (ACPI states S1, S2 and S3) is generally unsafe, as encryption keys will remain vulnerable in the computer's memory, allowing the computer to read encrypted data after waking up or after reading back the memory contents. Configuring an operating system to shut down or hibernate when unused, instead of using sleep mode, can help mitigate this risk.

TCG-compliant systems

Another mitigation method is to use hardware and an operating system that both conform to the "TCG Platform Reset Attack Mitigation Specification",[24] an industry response to this specific attack. The specification forces the BIOS to overwrite memory during POST if the operating system was not shut down cleanly.

However, this measure can still be circumvented by removing the memory module from the system and reading it back on another system under the attacker's control that does not support these measures (as demonstrated in the original paper).

The BIOS can also be modified while the system is running to circumvent any protections enforced by it, such as memory wiping or locking the boot device.[25][26][27]

Booting

Although limiting the boot device options in the BIOS may make it slightly less easy to boot another operating system,[22] many BIOSes will prompt the user for the boot device after pressing a specific key during boot. Limiting the boot device options will not prevent the memory module from being removed from the system and read back on an alternative system either. In addition, most chipsets allow the BIOS settings to be reset if the mainboard is physically accessible, allowing the default boot settings to be restored even if they are protected with a password.[28]

Register-based key storage

Kernel patches for Linux such as TRESOR[29] and Loop-Amnesia[30] modify the kernel of an operating system so that CPU registers (in TRESOR's case the x86 debug registers and in Loop-Amnesia's case the AMD64 or EMT64 profiling registers) can be used to store encryption keys, rather than RAM. Keys stored at this level cannot easily be read from userspace and are lost when the computer restarts for any reason. TRESOR and Loop-Amnesia both must use on-the-fly round key generation due to the limited space available for storing cryptographic tokens in this manner. For security, both disable interrupts to prevent key information from leaking to memory from the CPU registers while encryption or decryption is being performed, and both block access to the debug or profile registers.

A 2010 thesis identified two register areas in modern x86 processors which could potentially be used for key storage: the SSE registers which could in effect be made privileged by disabling all SSE instructions (and necessarily, any programs relying on them), and the debug registers which were much smaller but had no such issues. The author left the latter for others to examine, and developed a proof of concept distribution called paranoix based on the SSE register method.[31]

The developers claim that "running TRESOR on a 64-bit CPU that supports AES-NI, there is no performance penalty compared to a generic implementation of AES",[32] and run slightly faster than standard encryption despite the need for key recalculation.[29] The primary advantage of Loop-Amnesia compared to TRESOR is that it supports the use of multiple encrypted drives; the primary disadvantages are a lack of support for 32-bit x86 and worse performance on CPUs not supporting AES-NI.

Cache-based key storage

An approach to mitigating the cold boot attack is known as "frozen cache" (sometimes known as "cache as RAM"),[33] which disables the CPU's L1 cache and uses it for key storage. Disabling the CPU cache in this manner is disastrous for performance to the point that early experiments appear to indicate such a system would be too slow to be usable for most purposes.[34] Multicore CPUs may mitigate this issue, since only one core would need to have its cache disabled, but it appears examination of this approach has stalled.

Copker[35] in Network and Distributed System Security Symposium (NDSS) 2014 presented another cache-based solution against cold-boot attacks for public-key cryptographic computations. Public-key cryptographic algorithms such as RSA, requires much more memory space than symmetric encryption algorithms such as AES. Copker employs the WB (Write-Back) cache mode to keep data in caches. The WB cache mode is the most common mode; that is, modified data are not synchronized from caches into the RAM until explicit or implicit write-back operations. RSA computations are conducted with private keys in memory under the WB cache mode; then, sensitive private keys are kept in caches. Then, Copker finished the following mechanisms to prevent the sensitive private keys from being synchronized into RAM. (1) Eliminate heap variables, and only static variables are used in the computations; switching stack to pre-allocated data variables. So all used data variables are stored in reserved address space within caches, - no cache conflict among these data. (2) Task scheduling and kernel preemption are disabled. So, the RSA computations are not suspended; otherwise, the states of suspended tasks may be swapped into RAM. (3) All other cores are forced to enter the No-Fill cache mode. In such mode, read misses do not cause cache replacement (data are read either from another core that holds the newest copy of the data, or directly from RAM), and write misses access RAM directly. Hence, the cores sharing caches with the Copker core that are executing RSA computations, are forced to enter the no-fill mode, so that they cannot evict Copker’s caches.

Mimosa[36] in IEEE S&P 2015 presented a more practical solution for public-key cryptographic computations against cold-boot attacks and DMA attacks. It employs hardware transactional memory (HTM) which was originally proposed as a speculative memory access mechanism to boost the performance of multi-threaded applications. The strong atomicity guarantee provided by HTM, is utilized to defeat illegal concurrent accesses to the memory space that contains sensitive data. The RSA private key is encrypted in memory by an AES key that is protected by TRESOR. On request, an RSA private-key computation is conducted within an HTM transaction: the private key is firstly decrypted into memory, and then RSA decryption or signing is conducted. Because a plain-text RSA private key only appears as modified data in an HTM transaction, any read operation to these data will abort the transaction - the transaction will roll-back to its initial state. Note that, the RSA private key is encrypted in initial state, and it is a result of write operations (or AES decryption). Currently HTM is implemented in caches or store-buffers, both of which are located in CPUs, not in external RAM chips. So cold-boot attacks are prevented. Mimosa defeats against attacks that attempt to read sensitive data from memory (including cold-boot attacks, DMA attacks, and other software attacks), and it only introduces a small performance overhead.

Physical prevention

If memory modules are soldered onto a motherboard or glued in their sockets, then they cannot easily be removed and inserted into another machine under an attacker's control.[37]

References

  1. ↑ MacIver 2006.
  2. 1 2 3 4 5 6 7 Halderman et al. 2008.
  3. ↑ Skorobogatov 2002.
  4. ↑ Memory Research Project Source Code.
  5. ↑ "Passware Software Cracks BitLocker Encryption Open" (Press release). PR Newswire. 2009-12-01.
  6. ↑ KB2516445, Microsoft, 2011.
  7. ↑ Carbone, Bean & Salois 2011.
  8. ↑ B. Huang "Keeping Secrets in Hardware: The Microsoft Xbox Case Study", "CHES 2002 Lecture Notes in Notes in Computer Science Volume 2523", 2003
  9. ↑ Igor Skochinsky (2014-03-12). "Secret of Intel Management Engine". SlideShare. pp. 26&ndash, 29. Retrieved 2014-07-13.
  10. ↑ "2nd Generation Intel Core Processor Family Desktop, Intel Pentium Processor Family Desktop, and Intel Celeron Processor Family Desktop" (PDF). June 2013. p. 23. Retrieved 2015-11-03.
  11. ↑ "2nd Generation Intel Core Processor Family Mobile and Intel Celeron Processor Family Mobile" (PDF). September 2012. p. 24. Retrieved 2015-11-03.
  12. ↑ Michael Gruhn, Tilo Muller. "On the Practicability of Cold Boot Attacks" (PDF). Retrieved 2018-07-28.
  13. ↑ Johannes Bauer, Michael Gruhn, Felix C. Freiling. "Lest we forget: Cold-boot attacks on scrambled DDR3 memory". Retrieved 2018-07-28.
  14. ↑ Salessawi Ferede, Yitbarek Misiker, Tadesse Aga. "Cold Boot Attacks are Still Hot: Security Analysis of Memory Scramblers in Modern Processors" (PDF). Retrieved 2018-07-28.
  15. ↑ Y. Hu, G. Hammouri, and B. Sunar "A fast real-time memory authentication protocol", "STC '08 Proceedings of the 3rd ACM workshop on Scalable trusted computing", 2008
  16. ↑ G. Duc and R. Keryell, "CryptoPage: an efficient secure architecture with memory encryption, integrity and information leakage protection", Dec. 2006
  17. ↑ X. Chen, R. P. Dick, and A. Choudhary "Operating system controlled processor-memory bus encryption", "Proceedings of the conference on Design, automation and test in Europe", 2008
  18. ↑ M. Henson and S. Taylor "Beyond full disk encryption:protection on security-enhanced commodity processors", "Proceedings of the 11th international conference on applied cryptography and network security", 2013
  19. ↑ M. Henson and S. Taylor "Memory encryption: a survey of existing techniques", "ACM Computing Surveys volume 46 issue 4", 2014
  20. ↑ Dean 2009.
  21. ↑ Bitlocker Technical Overview, 2008.
  22. 1 2 MacIver 2008.
  23. ↑ Wired, 2008.
  24. ↑ "TCG Platform Reset Attack Mitigation Specification". Trusted Computing Group. 2008-05-28. Retrieved 2009-06-10.
  25. ↑ Ruud, Schramp (2014-06-13), OHM2013: RAM Memory acquisition using live-BIOS modification, retrieved 2018-07-28
  26. ↑ Michael, Gruhn. "Forensically Sound Data Acquisition in the Age of Anti-Forensic Innocence": 67.
  27. ↑ Schramp, R. (March 2017). "Live transportation and RAM acquisition proficiency test". Digital Investigation. 20: 44–53. doi:10.1016/j.diin.2017.02.006. ISSN 1742-2876.
  28. ↑ Michael, Gruhn,. "Forensically Sound Data Acquisition in the Age of Anti-Forensic Innocence": 67–68.
  29. 1 2 TRESOR USENIX paper, 2011 Archived 2012-01-13 at the Wayback Machine.
  30. ↑ Loop-Amnesia ACSAC 2011 paper and code
  31. ↑ Müller 2010.
  32. ↑ TRESOR home page
  33. ↑ Tews 2010.
  34. ↑ Frozen Cache Blog
  35. ↑ Le Guan, Jingqiang Lin, Bo Luo, and Jiwu Jing. "Copker: Computing with Private Keys without RAM", 21st ISOC Network and Distributed System Security Symposium (NDSS), 2014
  36. ↑ Le Guan, Jingqiang Lin, Bo Luo, Jiwu Jing, and Jing Wang. "Protecting Private Keys against Memory Disclosure Attacks using Hardware Transactional Memory", 36th IEEE Symposium on Security and Privacy, 2015
  37. ↑ Halderman et al. 2008, p. 14.

Sources

  • "BitLocker Drive Encryption Technical Overview". Microsoft. 2008. Retrieved 2008-11-19.
  • Carbone, R.; Bean, C; Salois, M. (January 2011). "An In-depth Analysis of the Cold Boot Attack: Can it be Used for Sound Forensic Memory Acquisition?" (pdf). Valcartier: Defence Research and Development Canada.
  • Dean, Sarah (2009-11-11). "Cold Boot Attacks on Encryption Keys (aka "DRAM attacks")". Archived from the original on 2012-09-15. Retrieved 2008-11-11.
  • "Encryption Still Good; Sleeping Mode Not So Much, PGP Says". Wired. 2008-02-21. Retrieved 2008-02-22.
  • Halderman, J. Alex; Schoen, Seth; Heninger, Nadia; Clarkson, William; Paul, William; Calandrino, Joseph A; Feldman, Ariel J.; Appelbaum, Jacob; Felten, Edward W. (2008-02-21). "Lest We Remember: Cold Boot Attacks on Encryption Keys". Princeton University. Retrieved 2008-02-22.
  • "KB2516445: Blocking the SBP-2 Driver to Reduce 1394 DMA Threats to Bitlocker". Microsoft. 2011-03-04. Retrieved 2011-03-15.
  • MacIver, Douglas (2006-09-21). Penetration Testing Windows Vista BitLocker Drive Encryption (PDF). HITBSecConf2006, Malaysia: Microsoft. Retrieved 2008-09-23.
  • MacIver, Douglas (2008-02-25). "System Integrity Team Blog: Protecting BitLocker from Cold Attacks (and other threats)". Microsoft. Retrieved 2008-09-23.
  • Müller, Tilo (May 2010). "Cold-Boot Resistant Implementation of AES in the Linux Kernel" (pdf).
  • Tews, Erik (December 2010). FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software. 27th Chaos Communication.
  • "Memory Research Project Source Code". Princeton University. 16 July 2008. Retrieved 7 May 2013.
  • Guan, Le; Lin, Jingqiang; Luo, Bo; Jing, Jiwu (February 2014). Copker: Computing with Private Keys without RAM (PDF). 21st ISOC Network and Distributed System Security Symposium (NDSS).
  • Guan, Le; Lin, Jingqiang; Luo, Bo; Jing, Jiwu; Wang, Jing (May 2015). Protecting Private Keys against Memory Disclosure Attacks using Hardware Transactional Memory (PDF). 36th IEEE Symposium on Security and Privacy (Oakland).
  • Lest We Remember: Cold Boot Attacks on Encryption Keys on YouTube
  • McGrew Security's Proof of Concept
  • Boffins Freeze Phone to Crack Android On-Device Crypto
  • Skorobogatov, Sergei (June 2002). "Low temperature data remanence in static RAM". University of Cambridge, Computer Laboratory. Retrieved 2008-02-27.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.