Originally published on 21 December 2018
Updated on 24 November 2021
An industry-wide security issue with self-encrypting drives (SEDs) has been highlighted (Carlo Meijer and Bernard van Gastel, Netherlands Radboud University, 5/11/2018).
In the research paper “Self-Encrypting deception: weaknesses in the encryption of solid-state drives (SSDs)”, several SSDs were examined from different vendors. It was discovered that, in many cases, security could be bypassed. This problem was compounded by the fact that the default behaviour of operating systems disk encryption routines (such as Microsoft Windows Bitlocker) relies on using the Opal standard if the drive supports it rather than a software encryption method. Drives using the Opal standard carry out hardware encryption on the device, rather than relying on the Central Processing Unit (CPU) to do the heavy work from an encryption/decryption point of view.
Isn’t it surprising that given the existence of a universally adopted security specification, such a vulnerability makes its way through many disk varieties from different vendors? Here at Optimising IT, we break down the security issues related to hard drive encryption.
How Security Specifications Can Be Vulnerable
Consider BS3621, a lock standard by British Standards Institute (BSI) for thief-resistant locks. You may have come across this when reading your house insurance policy conditions. This test relates to mortise and cylinder rim locks for doors where a key is required for entry or exit, and UK insurers often state that this standard is a requirement.
However, insurers do not generally stipulate a standard for other factors surrounding the lock itself. So if you buy a door that has a BS3621 standard but is made of thin plywood from a supplier, instead of solid bonded & layered oak, they would not have breached the insurer’s conditions (and the door would be cheaper and quicker to manufacture). However, this would not stop the burglars from happily getting into your house since they could break in through the thin plywood or any other alternative weakness without having to try to overcome the BS3621 standard.
What Are the Areas of Concern?
Given the widespread reporting of the disk storage security issue, many security-aware organisations need to ensure they are compliant with government and regulatory standards around privacy and confidentiality. For example, GDPR, ISO27001, Security Operations Centre (SOC), HIPAA, Cyber Essentials etc. are now concerned about:
- What are the reasons for SEDs vulnerability?
- What should they do to their internal disk deployments to maintain adequate security?
- What disks should you buy in the future?
- What technology meets their storage security objectives at the lowest cost to acquire & maintain?
Disk Security History
Before self-encrypting drives (SEDs), disks were limited to performing access control to secure themselves. The ATA Security Feature Set required the disk to be configured with a BIOS-level password matching one set by the host to access it. It was easy to overcome attacks on the disk at BIOS-level to bypass or spoof the checks. Or to get another new identical drive, take out the logic board (which does not have a password, being new) and substitute it into the original drive. This would eliminate access control and allow it to be read.
To mitigate this, software disk encryption (SDE) became available, meaning that either individual files or whole disks could be encrypted by the host when writing to the disk and decrypted when reading from it. The disadvantage was that the processing load of doing the encryption/decryption could significantly slow the host’s other applications. Disk manufacturers introduced SEDs (for a price premium over standard drives) and offloaded the encryption/decryption onto the drive itself.
To ensure interoperability of disk drives across multiple hosts and operating systems, security standards for SEDs were developed by the Trusted Computing Group (Opal 2). Other international storage standards (particularly IEEE-1667, Protocol for Authentication of Removable Storage Devices), were adopted by disk manufacturers.
Opal 2 overcame the limitations of ATA Security by encrypting the disk itself using hardware-based cryptographic functions to encrypt the data inside the disk itself using an internal disk encryption key (DEK). This standard did not focus on the type of cryptography or performance of the disk. Instead, it concerned itself with how the keys themselves were generated, enabled, changed and reset. It also provided the concept of passwords protected by keys, namely ”Key Encryption Keys” (KEK) with multiple levels. This offered the protection of exchanging the key securely with the host using a master encryption key (MEK) which is used to encrypt/decrypt DEK and KEK.
Benefits and Disadvantages of SEDs
The primary benefit of SEDs is based around performance, on the premise that dedicated hardware encryption relieves the burden from the host CPU and transfers bandwidth.
For organisations with robust “data at rest” security requirements and encryption on their storage, SEDs provide features such as the “crypto erase” function. This means that the disk encryption key (DEK) is changed, rendering the contents unusable in an instant without needing to re-encrypt sector-by-sector. This could benefit large-scale estates (e.g. for IaaS service providers to prevent exposing data across hosts without time delays from secure wiping). However, in many cases, the end-users are government organisations implementing a strict physical shredding policy where redeployment to a different security classification is concerned.
The applications have a high write requirement (commonly databases, client-based agents, disk defragmentation operations) which can be an important benefit. However, even in these scenarios, it isn’t a given that the performance of SDE would be significant enough to justify the additional management overhead.
Pricing
Originally, SEDs were sold with a significant additional price tag to organisations with a specific need to do this, but today there is little or no difference in price.
Disk Encryption Vulnerabilities
Both SED and SDE encryption solutions are subject to attacks of varying complexity depending on the operating system (e.g. Microsoft Bitlocker) or third-party security software vendor (e.g. BeCrypt). In many cases, these relate to the key management aspects which apply to them both.
SDE Security Benefits
SDE security is independent of the operating system and is therefore not vulnerable to SED attacks. These may include alternative boot approaches using two-factor keys (USB) and memory attacks to discover encryption keys held in systems memory (side-channel attack). Since the authentication is done on the drive itself using an isolated “pre-boot OS”, the real OS is not accessible to be attacked during the boot process. There is no need to centrally manage the disk encryption keys (DEK) with a SED, though there is still the need to manage the Master and other keys.
SED Security Disadvantages
The fundamental issue with the SED implementations mentioned more recently is that the password exchange routine and disk encryption key process is implemented internally within the drive itself. This is instead of using the password securely held within the host as part of the encryption key. So, if the password exchange routines on the drive are modified, then any host can happily read and write to the disk without encryption (even though internally, the drive is still encrypted). So, even with the security level set to high, the disk is still vulnerable if the security features are rewritten to ignore the initial password check. This would then allow access to the drive and a potential data security breach.
In the case of the SEDs, hackers can use the TAP (Test Access Port) on the device (which is not specifically part of the scope of the Opal 2.0 specifications, just as the door is not part of BS3621). It may seem that this is an advanced attack. However, many board manufacturers (disk manufacturers included) add the industry-standard four-wire JTAG interface. This means that with a simple USB-to-JTAG adapter and some basic programming tools, you can reprogram the disk to not bother checking the user password. You may recall a similar scenario for the Xbox 360, where a widely-published JTAG hack allowed the execution of unsigned code.
Microsoft Windows and other operating systems will automatically use hardware encryption rather than software (e.g. Bitlocker for Windows), meaning that systems are vulnerable to the attack outlined by Meijer & Gastel. When this research was publicised, Microsoft published ADV180028, explaining that Group Policy can override the default behaviour and use the software encryption instead. This clarifies that read performance is slightly reduced and write performance is reduced “up to 50%”, although this usually applies to older hardware as described.
Self-Encrypting Disk Security Configuration and Operation
As described previously, several different levels of security are available from a SED, and implementation generally follows a specific path.
To benefit from the security provided by a SED, the owner (most likely an IT department) needs to define multiple passwords and security levels before using it. They should also be guided by a Security Policy and driven by the Risk Assessment, which demands adequate “Data-at-Rest” controls. This will satisfy many governmental and regulatory standards concerned with data privacy and confidentiality.
This involves installing an operating system for many disk vendors to run the drive prep software to associate the key pair relationship between the host (typically in the TPM chipset) and the drive. This results in crypto erase – meaning that you must put on an operating system again from scratch. For many individuals and organisations, this is an administrative burden that they don’t want to do or are not aware that they need to do (or even that they have a SED in the first place!)
“Users” of the disk (which could be multiple applications, virtual hosts instances, etc.) could set a “User Password” for the parts of the disk they can encrypt. Since there is the possibility that user passwords get unintentionally removed on the platform secure storage area (due to a TPM wipe or hardware failure, for example), the concept of a “Master Password” is provided to recover from the loss of user passwords. This in itself is a security risk, so vendors allow the possibility of changing how this Master Password behaves by setting different levels.
Disk manufacturers may also have defined another password for use when carrying out diagnostics (maker’s credentials). They usually do not allow access to the customer data by their bench technicians. However, the owner is generally given the option to disable this password to be sure while accepting that they may not be covered by warranty if they do so.
Factors to consider when carrying out diagnostics:
- There is no KEK, and the Security feature set is disabled (no user password is needed from the host – the disk is still encrypted internally using the DEK, but any host can use it in the same way as a standard disk).
- Security level High: the MEK is decrypted and verified by KEK, and the Master password can unlock the device and reset the user password, but the data remains intact (since the DEK is retained).
- Security level Maximum: The Master password can reset the user password, but only if data is erased (since the DEK is changed, the encrypted data remains but is effectively useless without the original DEK).
Suppose an organisation with strong data-at-rest requirements can maximise the write performance to meet performance targets (such as write-intensive applications on older hardware). In that case, you can leverage advanced security applications. This would support mass deployments and reduce the risk of the attack highlighted by (e.g. Microsoft TPM Measured Boot, which validates the firmware hash of drives using a centralised attestation server).
What This Means for Organisations
You can avoid the vulnerabilities mentioned above (Carlo Meijer and Bernard van Gastel) by selecting disk drives. The Opal implementation does not suffer from the issues identified, or they are configured so that it does not affect them. If this is the case, then the main beneficiaries of SEDs are likely to be those organisations that need to extract every ounce of computing power for applications over a wide scale. These companies can justify the additional overhead to properly manage the set up and maintain the KEK’s (such as SaaS providers). Those who also benefit from the facility of crypto erase guarantee security for redeployed storage. However, organisations with a large number of legacy computer platforms that do not have modern CPU’s, are more likely to have more pressing concerns than data-at-rest.
While it is easy to see the main benefit of dedicated hardware within the drive, this is less advantageous than in previous years. Modern CPU’s (for the last ten years or so) have built-in hardware acceleration for AES encryption/decryption. Likewise, modern disk systems use the NVMe interface specification that maps I/O to shared memory over the PCIe interface and uses parallel I/O multiple CPU cores coupled with PCIe-based SSDs. This means software-based encryption/decryption is done without significant performance loss (compared to older CPU and disk interface specifications such as SCSI/SAS and ATA/SATA).
Having SDE reduces the implementation and key management overheads of shared keys, increases the efficiency of key recovery and is a portable security control that works across all disk vendors and physical recovery. However, if there is any physical drive damage, SEDs cannot be recovered. This means that there is a lot to be said for it in most general-purpose applications running on modern hardware, provided that the key management procedures are done correctly. In most non-service provider organisations with up-to-date infrastructure, the marginal performance decreases with software disk encryption are generally outweighed by the benefits within data centres.
Assuming physical security is in place to prevent physical access to the system to perform an aside-channel attack, mobile platforms are more of a concern for SDE since it is subject to a side-channel attack. This would be if attackers can access the memory, regardless of the presence of a TPM or 2-factor USB, which SEDs would not be subject to. Mitigating this is possible, e.g., storing keys in areas other than RAM, such as registers or performing memory encryption, but it imposes a performance hit, e.g. 5-30% for Spectre 2. More recently, however, Microsoft has indicated they will be adopting Retpoline that provides a negligible impact.
Find out more about hard drive encryption and device security from the experts at Optimising IT. Get in touch for more information on cyber security.
