The need to encrypt data on devices has never been greater, especially with legislation such as the European Union’s General Data Protection Regulation (GDPR). Purchasing a self-encrypting drive (SED) that adheres to the industry standard, published as the Trusted Computing Group’s (TCG) Opal 2.0 standard specifications, should give you the confidence that the data it stores are encrypted and safe from unauthorized access. Unfortunately, this may not always be the case.
A group of researchers based at Radboud University in the Netherlands has published a paper that details vulnerabilities in some solid-state-drives (SSDs), drives that claim to adhere to these standards. These vulnerabilities allow an attacker to bypass the disk encryption feature without knowing the original user’s chosen encryption password.
And to make matters worse, some software-based encryption solutions automatically utilize the hardware encryption option by default, on SSDs built to this standard.
Vulnerabilities in software and hardware are not unusual, but the ability to bypass a user-chosen password by subverting a simple ‘if-then’ type check instead of proper cryptographic binding is not only a major security flaw but also seems to be an error that even a first year student in University would avoid making. In simple terms, the password routine unlocked the encryption key as opposed to the password being used as or as part of the encryption key. This raises the question of how, when there are documented standard specifications, the vulnerability made it all the way through to a released product.
A vendor entering the encrypted drive market and developing an SED starts out with the best intentions, joins TCG and furnishes their developers with a copy of the Opal 2.0 specifications. They create the product and self-declare that it’s compliant with the specification, then marketers step in and promote the product as being fully compliant with the specification. Consumers seeing the compliance declaration will expect adherence to the specification.
Would validation or certification that the implementation of the Opal 2.0 specifications is correct, and that no vulnerabilities exist due to the interpretation of the specification, have avoided this particular issue? In this case it may not have, as the hackers used a port on the device that is only used during the manufacturing of the device; thus it may be out of the scope of the Opal 2.0 specifications.
In other industries, such as automotive, there are validations and certifications prior to any standards logo being placed on the product. For example, a vendor wanting to demonstrate the safety level of their vehicle may use a certifying agency such as the European New Car Assessment Program or the Insurance Institute of Highway Safety. The vehicle is delivered to the certifier post development/manufacturing and independent validation of the safety features, which may adhere to industry specifications and standards, are evaluated and scored. The vehicle will then carry the safety logo and score from the independent organization, allowing a purchaser and insurer to make decisions knowing that the specification was followed and so was the effectiveness of the implementation.
While the cybersecurity industry grapples with the disclosures made by the researchers from Radboud, it’s important to note that some vendors do take an additional, completely voluntary step to have their solutions certified. For example, a product that states compliance with the Federal Information Processing Standard (FIPS) has been independently tested and validated by a licensed laboratory. The validation for encryption products is FIPS 140-2 – Security Requirements for Cryptographic Modules. There are different levels of FIPS compliance, validation and certification, and purchasers should research which level meets their requirements.
Data, whether personal or corporate, being put at risk due to the lack of post-development independent certification and validation that the implementation of the specification can be trusted seems to be a flaw in the current SED/Opal 2.0 process.
