How & Why
- Penetration Tests a Turning Point in Security Practices? Organizational Challenges and Implications in a Software Development Team. (2nd WSIW)
- First-time Security Audits As a Turning Point? Challenges for Security Practices in an Industry Software Development Team. (CHI'16 EA)
- Idea: Usable Platforms for Secure Programming - Mining Unix for Insight and Guidelines. (ESSoS'16)
- Security Analysis of TrueCrypt. (BSI, 2015)
- Sicherheitsanalyse TrueCrypt. (BSI, 2015)
- CAST-Workshop Sichere Software entwickeln am 12. November 2015
- ASSD 2015 – 1st Int. Workshop on Agile Secure Software Development (submission deadline: 2015-04-15)
- 2. CAST-Seminar Sichere Software entwickeln - Erfahrungen, Methoden, Werkzeuge am 15. Mai 2014
- Hiwi-Job: Entwicklung von Werkzeugen für das Secure Software Engineering (2013-07-25)
Attacking the BitLocker Boot Process
Disk encryption keeps data confidential when a computer gets lost or stolen and provides good security against opportunistic attacks. Encryption leaves, however, attack vectors open for targeted attacks, particularly if the attacker can gain physical access to the computer. The term evil maid attack concisely describes the scenario: if the owner leaves a computer unattended in a hotel room, an evil maid, or any one else with access to the room, could tamper with this computer. Tampering with the computer means to compromise the platform that executes the encryption and decryption functions and thus necessarily has access to keys and plaintext data. The attacker could modify software on the computer, or even its hardware, for instance by installing a hardware key logger to obtain passwords. This way the attacker could gain access to confidential data or even compromise the entire operating system.
BitLocker Drive Encryption (BDE), the disk encryption feature available in Windows Vista, Windows Server 2008, and Windows 7, uses functions of the Trusted Computing platform if the computer has a Trusted Platform Module (TPM). The TPM allows software to seal data—encrypt them using a key stored inside the TPM—such that unsealing requires the same TPM again and a particular state of essential components. During the boot process, these components—for instance the BIOS and boot loader of the operating system—and the TPM work together to establish an audit trail of measurements of the current state of the system. The TPM refuses to unseal data if the current state of the system differs from the reference state specified when sealing the data.
Current implementations of Trusted Computing in personal computers do not include the keyboard in their measurements and also do not establish a secure channel to the keyboard. A variety of hardware-based attacks against BitLocker therefore remain possible in the evil maid scenario. But many people seem to believe that Trusted Computing would automatically protect the system from all software-based attacks against the boot process, and in particular that using BitLocker with a TPM would achieve such protection. In our video on this page we demonstrate how an attack based solely on tampering with the boot loader may still succeed and help the attacker to gain access to confidential data.
During the boot process, BitLocker needs to interact with the user to obtain a password, a key file from a USB memory stick, or both. The program code interacting with the user resides on the disk unencrypted. An attacker with physical access to the computer can arbitrarily modify this code and for instance add a function to store any user-provided key in an unused part of the disk. The TPM will notice this modification when the user boots the computer the next time, and refuse the unsealing of any keys bound to the unmodified state of the boot code. However, BitLocker does not use the measurement information provided by the TPM to prevent the execution of modified code outside of the encrypted partition.
An evil maid attacker can thus replace the original BitLocker boot code with a manipulated version and spoof the user interaction of BitLocker. This modified boot code cannot continue the boot process after obtaining keys from the user. It can, however, restore the original state of the boot loader and initiate a reboot in a way that might seem plausible to the user. If the attacker can get away with this forced reboot, it takes only a second visit of the evil maid for the attack to succeed, this time to steal the computer.
Our attack demonstration does neither imply a bug in BitLocker, nor renders it Trusted Computing useless. BitLocker still works as well as other disk encryption products, it only fails to fulfill an unrealistic yet common expectation. BitLocker even profits from using the TPM despite our attack: the attack becomes more noticeable, and a number of other attack scenarios become infeasible. As an application of the Trusted Computing platform, BitLocker uses only a subset of the functions available, and it does so in a particular way. Our attack applies only to the combination of platform, application, attack scenario, and attack objective discussed here.
- Press release (in German)
- Research paper:
S. Türpe, A. Poller, J. Steffan, J.-P. Stotz, J. Trukenmüller: Attacking the BitLocker Boot Process, Proc. Trust 2009.
- Our mobile security services