Report Speech BHS 2019 by Carlo Meijer
Wrap-up report Black Hat Sessions 2019 - Presentation Carlo Meijer written by Sjors van den Elzen- 31 July 2019
Below you will find a brief report written by Sjors van den Elzen (Security Analyst at Secura), of the speech about self-encrypting deception given by Carlo Meijer, PhD candidate at the Digital security group at the Radboud University Nijmegen.
The idea of encrypting a hard drive has been around for a while, as there is an existing need to keep the data that is stored on the hard drive confidential, even in the event of physical protection failing. Without encryption, a laptop that has been forgotten by an employee can reveal just as many company secrets as a laptop that has been compromised. Initially, hard drives were all encrypted using software, where data was encrypted and the result is stored on the drive. It makes, however, sense to make enforce such protection on a physical level as well; leading us to hardware encrypted hard drives. Here the data is stored as-is on the drive, and the drive uses encryption on its contents. This technique is praised by many for being secure, to the point where Windows' encryption tool BitLocker uses the technique as the default option when available. The main question, however, still remains and it pertains the following: Is hardware encryption really as secure as proclaimed by a majority of the manufacturers? In answering this question, three scenarios can be distinguished and it is beneficial to do so from an attacker’s point of view.
In the first scenario, the computer has not been turned off, the encryption key is stored in such a way that an attacker can still retrieve it by performing (for example) a cold boot attack which can be performed for both hardware and software encryption. This can be done for both hardware- as well as software encryption. (for more information on cold boot attacks visit the following link: https://en.wikipedia.org/wiki/cold_boot_attack)
In the second scenario, the computer is turned off, and the user does not know that he is being attacked. In this case, it is possible to retrieve the encryption key by means of a hardware keylogger or backdoor bootloader. When the user then unlocks the hard drive again, the encryption key can be stored on the computer such that it can be retrieved easily. Yet again this can be done on both hardware and software encryption.
The last scenario is the most interesting, and in this scenario the computer is in a state where it has been turned off and the user is aware that he is under attack. In this case, the key cannot be extracted from the computer, and the user cannot be tricked into giving it up either. This case is interesting since, with software encryption, this is a dead-end for the attacker. Against hardware encryption, there may yet be a chance.
Before delving deeper into how to break the encryption, it is first important to understand how encryption works by going more in-depth in the details. Meijer describes two standards for hardware encryption: ATA security feature set and TCG Opal. The ATA security feature set was devised before hardware encryption, and it uses a factory-set master password which by default is able to unlock and wipe the drive, causing it to not be that secure. TCG Opal ,on the other hand, offers a better alternative, and as such, it is the standard that is used by most hard drives implementing hardware encryption. It allows the user to define multiple ranges on the hard drive, and multiple passwords that each can unlock some of the ranges.
As with every security standard, there are several pitfalls in the implementation. The Data Encryption Key (DEK) is the key that is used to encrypt the data, and the first pitfall is in not creating the DEK based on the password that is used to unlock the encryption. The DEK will be based on some other source of semi-randomness, which may or may not be available to an attacker. A second pitfall stems in the possibility of multiple passwords. If a single DEK is being used for all ranges, all passwords can be used to unlock any range, even when that password does not have access to other ranges. So on systems with multiple users having access to the hardware-encrypted drive, a situation for which this standard was developed, the weak password from a single user could grant access to the entire disk. The last pitfall of hardware encryption lies in how the computer writes to its memory. When the user sets the password, the DEK is encrypted so it can be stored securely. This is not necessarily stored in the same place as the unencrypted DEK was stored, however, an insecure DEK might be stored somewhere on an encrypted hard drive, waiting to be used by the attacker.
Lastly, we take a look at several hard drives that implement the TCG Opal standard and evaluate their security in the context of these pitfalls. The results of the drives can be found in the table below. To conclude, hardware encryption is vulnerable to the same mistakes software encryption is vulnerable to, plus some additional hardware-specific vulnerabilities.
Are you interested in participating? Keep up to date with the latest news about the Black Hat Sessions (BHS), receive exclusive (early bird) discounts and secure your seat for interactive workshops. Sign up for our periodical newsletter and we will keep your informed.