Security Investigators Evade Encryption on Self-Encrypting

Despite the verification industry standard description by no means guarantees the security of the self-encrypting.

Security Investigators Evade Encryption on Self-Encrypting
Bypassing Encryption on Self-Encryption

The necessity of encrypting data on devices has never been greater, particularly with regulation such as the European Union’s General Data Protection Regulation (GDPR). Buying a self-encrypting (SED) that sticks to the standards of the industry, launched as the Trusted Computing Group’s (TCG) Opal 2.0 standard specifications, should assure you enough that the data stored by the device is encrypted and secure from illicit access. Sadly, this may not be the case always.

A group of academics based at Radboud University in the Netherlands has issued a paper that points out the weaknesses in certain solid-state-drives (SSDs) or drives that claim to stick to these standards. These exposures enable an attacker to circumvent the disk encryption feature without demanding the genuine user’s preferred password.

And to further worsen the matters, some software-oriented encryption solutions involuntarily apply the hardware encryption option by default, on SSDs built according to these standards.

Susceptibilities in hardware and software are common, but the knack to evade a user-selected password by destabilizing an unassuming “if-then” type check as an alternative of a solid cryptographic strap is not only a huge security loophole but also an error that even a first-year University student would avoid doing. Putting it in simple terms, the password sequence unlocked the encryption key instead of the password that is being used as a part of the encryption key or as the encryption key itself. This brings up the question of how the vulnerability made its way through to a released product in the presence of documented standard specifications.

A vendor while entering the encrypted drive market and developing an SED begins with pure intentions, goes on joining TCG and provides their developer with a copy of the Opal 2.0 specifications. They invent the product and claim themselves that the product is fully compliant with the specification. Consumers when they see the compliance declaration expect adherence to the specification.

So does validating and certifying the implementation of Opal 2.0 specification is correct and it can avoid the issue as no susceptibilities will exist due to the interpretation of the specification? Well, here the answer is no because the hackers use a port on the device that is used only during the device manufacturing process. Therefore, it may be out of the Opal 2.0 specification’s scope.

In industries like automotive, there are certifications and validations before placing any standard logo on the product. For instance, if a vendor wants to demonstrate the safety standards of their vehicle can use a certifying agency such as the Insurance Institute of Highway Safety or European New Car Assessment Program.

With the cybersecurity industry still grappling with the revelations by the researchers from Radboud, it is very important to note that some vendors take a further—completely voluntary—step to get their solutions certified.

For instance, let’s consider a product that claims compliance with the Federal Information Processing Standard (FIPS) has been autonomously tested and validated by a licensed laboratory. The authentication for encryption products is FIPS 140-2 Security Requirements for Cryptographic Modules. There are various levels of FIPS certification, compliance, validation, and purchasers should explore which levels meet their requirements.

Data regardless of being corporate or personal, being put at risk because of lack of post-development independent certification and validation that the application of the requirement can be trusted which is flawed in the current SED/Opal 2.0 process.