White Paper

w w w. m r c y. c o m WHITE PAPER Encrypted data-at-rest When data is written to the NAND media of an SSD, it becomes data- at-rest. Modern secure SSDs, sometimes called SEDs (Self Encrypting Drives) use Advanced Encryption Standard (AES-256) XTS to encrypt and protect data-at-rest in the NAND media. Using a 256-bit key value, AES- 256 provides strong protection for data-at-rest. With power removed, a properly designed secure SSD contains no discoverable key value. SEDs (Self Encryption Drives) are one of the information security industry's best kept secrets. They solve many common data loss problems, are easy to use and operate with minimal impact on system performance. In different words, if every memory device, including the NAND media, were removed and the contents fully examined, no key value would be found. With power applied, the SSD requires an authentication before allowing access to the previously stored data. Without going into detail, a secure SSD waits for the host system to supply an authentication val- ue. The SSD supplies the authentication value to an internal algorithm that derives/decrypts the actual DEK. The DEK is the key that encrypts and decrypts the host data. Once authentication completes, the SSD can begin normal operation. The strength of the authentication parameter(s) and the randomness of the DEK determine the strength of protection provided for the SSD data-at-rest. Almost all SEDs include an onboard random number generator to self- generate a DEK value. The DEK value is retained as an encrypted secret inside the SSD however; many COTS SSDs and some Defense Grade SSDs allow key value exportation with additional authentication. The most secure Defense Grade SSDs don't support key export operations. Many SSDs, both COTS and Defense Grade, implement security using OPAL and a host based hardware device called the Trusted Platform Module (TPM). OPAL defines a specification for features and commands that a storage device can implement to add security. As the most popular method to secure SSDs, OPAL/TPM has been well vetted in many de- vices and applications. While vulnerabilities exist, most of them apply to implementation flaws, TPM attacks 1 , or attacks carried out with power applied. Are Trusted Computer Group (TCG) and Trusted Platform Module (TPM) secure? In 2010, an American hacker presented details of his successful attack on a TPM chip the Black Hat DC security conference. While beyond the capabilities of the average hacker, the attack allowed reading of data stored on the TPM chip as well as RSA, DES crypto- graphic keys. Data-at-rest in a properly designed and powered-off OPAL/TPM comput- er is secure. The SSD has no discoverable key value obtainable by any but the most extraordinary means, for example, key burn-in 2 or capture of authentication credentials. OPAL based SSDs can easily thwart the skills and abilities of the common hacker, but how well do COTS SSDs and Defense Grade SSDs withstand the hacking capabilities of a na- tion state? Reviewing the security requirements for defense applications provides some indications. The replay-attack fix Like COTS SSDs, Defense Grade SSDs require authentication such as a password, a key, or both. Both types of SSDs can self-generate a DEK. Many Defense Grade SSDs provide additional key management features, for example, the ability to externally fill the DEK value. External key fill has distinct advantages: • First, it allows the defense application to accept keys known to have high entropy (randomness) • Second, while not ideal, a "fleet" of SSDs can be filled with the same known DEK • Third, if the threat is mitigated, the key can be purged If the threat is mitigated, the known key value can be re-filled to restore access to potentially high value data. Externally filled keys can be en- crypted and support a feature called replay-attack mitigation. In a replay attack, an attacker monitoring the communication between the host sys- tem and the secure SSD, implements hardware or other techniques to capture authentication credentials passed to the SSD. At a later time, the captured authentication credentials are "replayed" to authenticate with the SSD. Replay-attack mitigation uses one of several techniques that allow the authentication credentials to change on each successive authentication operation. To the attacker, the authentication parameters appear to be different each time they are sent and replaying of any one captured authentication parameter is interpreted by the SSD as a failed authentication attempt. Secure SSDs count failed authentication attempts. Once an upper limit is reached, a penalty is taken. For COTS SSDs the penalty is not severe, typically a requirement for a power cycle. COTS SSD manufacturers don't have the product support bandwidth to resolve problems when customers contact them for help with lost authentication parameters. By contrast, Defense Grade SSDs implement severe penalties for too many failed authentication attempts. At a minimum, the penalty is an immediately purge of the DEK, however; executing a full zeroization and/ or sanitize of the NAND media is common. S EC U R E D T R U S T E D 4

• Cover