Data protection is often cited as a no-compromise priority in pretty much every IT-related study. And yet, there is a disconnect between the beliefs IT leaders espouse and the actions they take – enterprise data protection is an uphill task fraught with skill, resource, and budget constraints.
An IBM study found that malicious attacks made up more than half of all data breaches in the enterprise. What’s more, each of these data breaches cost nearly $4 million to fix on average.
Source: IBM
Traditionally, one of the weakest links used to be the data on the drive, which had very little in the way of inherent defence against unauthorized read/write access. That is history now, with a collaboration between Cigent and Phison. Cigent’s K2 and Denali drives, based on Phison’s PS5012-E12DC Crypto-SSD NVMe controllers, are the industry’s first “self-defending” storage drives with cybersecurity built into the firmware. This platform has ransomware and data theft protection mechanisms built directly into the SSD’s firmware. The drives even automatically encrypt and hide data from prying eyes in the event of an attack.
However, let’s take a few steps back to revisit the context here. A lesser known threat is the lack of protection on the firmware that runs the SSD. Firmware is low-level code that controls hardware and can run without an operating system. A firmware-level threat is a hacker’s delight – the device need not necessarily store consumer or application data; it could be as simple as a BIOS on a network device that stores VPN routes of the company’s intranet.
Malicious code inserted into the firmware is the first to run when the device boots up, pre-empting the OS itself. By controlling the boot process, attackers can subvert security policies, install their own password checking and validation routines, patch the OS and gain complete control on the device. By extension, they gain extra privileges on the entire system that the device is part of.
That’s not all: firmware attacks are highly persistent and remain undetected for extended periods of time. When an attacker gains control of firmware in an enterprise infrastructure, you might not be able to wrest it back even by replacing storage drives or doing a full reimaging of your entire system.
This is why firmware threats are now the staple of highly organized advanced persistent threat (APT) and state-sponsored groups. Taking note, Gartner predicted that 70% of organizations that don’t have a firmware upgrade plan will be breached due to a firmware vulnerability by the end of 2022.
This article explores how firmware vulnerabilities in storage systems can cause serious data breaches and the measures you can take to secure your devices and protect your data.
Firmware vulnerabilities in flash-based storage
What is the ideal target for a hacker looking to steal customer data, operational codes or intellectual property from the enterprise? Any storage device that will survive a format or reset to factory settings.
Traditionally, HDDs and SSDs have been the default – and even easy – targets for hackers with access to a few simple tools. Some security issues plague USB sticks and external storage drives that users pass around like books these days.
In a nutshell, once an unauthorized person has physical access to your storage device, all your enterprise security and data protection strategy measures can potentially go out the window if you haven’t the right protection measures in place.
To prevent attacks that modify the firmware, customers need to purchase products that are designed from the ground up with a root of trust based in public/private key encryption. Two common forms are RSA 4096 and Elliptical Curve P-256. This root of trust can be used to protect user data encryption keys, and it can also protect the firmware itself.
Encryption standards and data security measures
The fundamental way to protect data residing on a hard drive is encryption. There are two kinds of encryption – symmetrical (like AES) which is very fast and asymmetrical (like RSA) which is slower but cannot be accessed without the private password (or key). Both types are very secure, but they must be used correctly to provide robust security.
In a PC environment, user login credentials are converted into a long seemingly random string of bits using a cryptographic process known as Password Based Key Derivation Scheme (PBKDS). This algorithm takes a moderately strong user password and coverts into a much stronger 256-bit sequence of bits.
This bit string that comes from the user is never stored on the SSD Self-Encrypting Drive (SED). It is used to unlock the main Data Encryption Key (DEK) so that user data can be accessed. Without the original user password, the OS cannot generate the bit string. Without the bit string, the SSD cannot access the user data. In this context it is safe to use a symmetrical AES-256 algorithm for data encryption because the DEK can only ever be unlocked with the user password.
Asymmetrical encryption like RSA 4096 is used when a user cannot be in the loop, but an organization wants to retain control of a device. For example, the company that released the SSD or network router does not want a hacker to replace their firmware.
If the company used a symmetrical encryption key to protect hundreds of millions of devices, that key would be at risk if was ever exposed. Once the hacker has the key, they can use it to fool the device by correctly encrypting the hacked firmware. Asymmetrical encryption fixes this problem, because the public key can only be used to confirm the code is valid. It cannot be used to sign modified code.
There are two mainstream standards for encryption of user data on SSDs:
ATA Security: This is the older standard for ATA storage devices and allows for locking and unlocking data with a password. By default, ATA Security is just an access control measure; but it can be used to protect an SED DEK as described above. It’s just that there is no way for the end user to know it without looking at the drive specs.
The problem with ATA Security is that SATA drives that are more than 5-6 years old likely pre-date the industry push for a robust security architecture. Unless the drive is FIPS certified, the protection mechanism should be avoided as there is no way to know if the security is implemented correctly. It also bears mentioning that the FIPS validation process is very demanding and very difficult for even large companies to get it right. Companies claiming FIPS compliance need to provide the certificate ID which can be cross-checked online. The certificate explains what was tested along with other key architectural information.
TCG Security: The Trusted Computing Group (TCG) provides a complete, scalable framework for data encryption on storage devices, including specifications for data encryption and key management. It has two major subsets – TCG Pyrite and TCG Opal. Both support pre-boot authentication and provide access control like ATA Security, but Opal defines extensions for Self-Encrypting Drives (SED). A correctly implemented SED ensures that even if the access control somehow fails or the attacker physically removes the NAND flash chips from the SSD, the data cannot be read.
An SED also supports fast and safe repurposing through a feature called crypto erase. Once triggered, crypto erase deletes the DEK instantly and then unmaps all the old data pointers. The crypto erase process is instantaneous, without having to wait for the drive to fully self-erase, which can take hours on a large drive. The thinking here is that if encryption was able to protect the data when you cared about it, it can continue to protect the data once you delete the key, but now nobody can decrypt it. Though there is no specific need to physically erase the blocks, the option is usually available on most TCG Opal drives.
Source: Phison
Ultimately, the question of securing the weakest link remains – what protects the firmware running on the SSD? Are you sure the debug ports are closed to attackers? Is it possible for unauthorized parties to update the firmware?
Getting firmware security right is an uphill task because of the sheer number and complexity of unlikely scenarios and use cases, and the myriad and multifaceted specifications that manufacturers have to adhere to.
Phison’s data protection solutions for SSD firmware
All firmware from Phison carries an extra layer of security for each aspect of the firmware it designs. Experts from various departments such as design and security come together and collaborate and review each other’s work to make sure there are no vulnerabilities, hacks or points of failure that could compromise the whole system. Some of the salient security measures include:
Code signing
All Phison devices have cryptographically signed firmware. The ROM verifies the signature of the firmware on boot and executes the code only if it is valid. Modifying even a single bit of information would cause the signature verification to fail. This means that any attempt to gain low-level control over the device – including vendor-specific commands, memory corruption (such as stack-based buffer overflows), and storage chip access (using an external reader device) – is rendered useless.
These digital signatures are also used in the download microcode for each firmware update. Updates that fail this check are automatically rejected.
Locked debug mechanisms
All debug mechanisms in the firmware are locked and can only be unlocked by an RSA-based authentication process. In the event an attacker tries to modify the firmware to bypass this authentication, the download mechanism would reject the firmware because of a signature failure. Even if the attacker somehow got through the download verification, the ROM boot would fail the signature and refuse to run the firmware modified by the hacker. The boot ROM is part of the storage controller and cannot be modified once the chip is produced. These steps are in place to ensure the attacker is always locked out.
User-controlled encryption
All security settings on the firmware are encrypted. However, if an attacker could somehow bypass the entire protection mechanism, it isn’t enough to gain access to the user data. In fact, even de-soldering the NAND chips and reading them is not sufficient to get access to the DEK protecting the data. The attacker cannot extract the encryption keys from the NAND without user credentials.
How does this work? The encryption keys are tightly bound to specific and authorized user accounts via NIST-approved key wrap algorithms, which encrypt the keys stored on the NAND flash media. These can only be decrypted with the user credentials, which are never stored on the drive. The credentials are used to generate the unwrapping key and cleared as soon as the contents of the key wrap are extracted.
Finally, cloning the key wrap files is a futile exercise as they can only be accessed using the corresponding account credentials. Modifying the wrapped keys would also not be useful, as they would fail the built-in integrity check upon unwrapping. If the integrity check was somehow hacked, using modified keys would not help as the data would decrypt to random garbage data. When implemented correctly, a strong key hierarchy can only be defeated by brute force guessing, which would take millions of years, even with the fastest computers and GPUs.
A solid firmware security strategy
Virtually every device on the market comes with OS or firmware vulnerabilities. While it’s true that firmware security is largely in the hands of hardware manufacturers, your organizational security policy should include resilient measures to counter firmware-based threats.
Here are some high-level steps you can take to address these risks:
-
- Always update your firmware to the latest versions as soon as the manufacturer releases them.
-
- Add firmware-specific attributes and metrics to the data you collect as well as report as part of your security auditing and monitoring program.
-
- Never plug untrusted external storage devices into your core network.
-
- Integrate firmware management and updates with existing hardware and OS lifecycle management processes.
-
- Stay on top of firmware vulnerabilities for all your devices and run periodic firmware vulnerability scanning tests.
English 
繁體中文 
简体中文 
日本語 
Deutsch 
한국어