Encrypting storage in small form factors

Story

October 06, 2015

 

The primary use for encrypted storage – whether implemented in software, firmware, or hardware – is to satisfy security requirements concerning “data at rest”; that is, requirements for protecting data while it resides in nonvolatile storage. While it may seem obvious that encrypting data while it is at rest will satisfy the letter of the requirement, caution is nonetheless warranted regarding the handling of cryptographic keys.

Why small form factor?

Increasingly, computation in military systems is moving to mobile devices. If such mobile devices are tied to data sources via cabling or wireless networking, then their flexibility and/or battery life suffers. As a result, mobile devices commonly store (or cache) any data necessary for their operation locally. A second common motivation for small-form-factor storage relates to system sanitization: To more easily sanitize sensitive data from complex systems, it is frequently helpful to isolate the storage and usage of such data in a removable module. Since such a module is often carried away with the operator as part of standard operating procedure, a pocket-sized form factor is a convenient choice. (Figure 1.) Note that these motivations in favor of small-form-factor storage directly imply a heightened risk of loss, and therefore motivate enhanced security for their data while at rest.

 

Figure 1: Small-form-factor storage enables portable devices. Shown are 2.5-inch SSD drive, mSATA, BGA, and custom module (memory module).

(Click graphic to zoom by 1.8x)

 

What is encryption, really?

At its most abstract level, encryption is an invertible means to replace a meaningful message with one that is meaningless. There are two general ways this is accomplished: Symmetric ciphers define a bijection (one-to-one mapping) between the space of meaningful messages (plaintexts) and the space of meaningless ones (ciphertexts). In contrast, asymmetric ciphers compute a mathematical identity in two or more distinct steps, such that “encryption” moves to an intermediate result (ciphertext), and “decryption” completes the identity, returning to the original value (plaintext).

If the underlying mathematical primitive (i.e., bijection or identity-in-use) is well-known or predictable, then any- one can recover the plaintext for a given ciphertext. This is where the keys enter: Successful cryptosystems select the mathematical primitive to be used – from a very large pool of possible primitives – using the key. AES-256 is a shorthand way to represent 2 ²⁵⁶ different block-sized lookup tables, where the key selects which one to use. Without the key, a malicious user cannot practically determine the underlying mathematical primitive.

The critical observation is that encryption alleviates concerns about revealing the plaintext. It does, however, generate a new concern: protecting the key against exposure. Attempting to protect the key via encryption would yield an infinite recursion. Therefore, encryption offers a transformation of the data-confidentiality problem, not a solution. The task of protecting arbitrary data is transformed into the task of protecting a key with a fixed form.

Securely leveraging small-form-factor encrypted storage

Self-encrypting storage devices must secure cryptographic keys without the aid of cryptography. The need to manage the cryptographic keys is the fundamental engineering challenge in producing secure systems that leverage self-encrypting storage. Listed below are some common security scenarios for military systems and several strategies by which small self-encrypting devices can be leveraged to help provide solutions.

Purgeable persistent random keying

The inherent risk of military operations sometimes leads to equipment loss, such as the 1999 downing of the F-117A Nighthawk over Serbia, or the modified Blackhawk reportedly lost during the 2011 raid on Osama bin Laden’s compound in Pakistan. In cases where weapons systems gain their tactical advantages though advanced software or specialized data, it is imperative that these critical technology elements be rendered permanently inoperable before abandoning the equipment.

This status can be achieved by a self-encrypting storage device that supports persistent static keying if the device is initialized with a high-quality random key. During an abandonment event (e.g., pilot ejection), the random key is immediately cleared. Presuming no record of the key persists, the hosted software and data is rendered immediately unrecoverable while subsequent sanitization procedures execute. As military systems continue to miniaturize and adopt mobile paradigms, small-form-factor self-encrypting storage solutions will play this role with increasing frequency.

Purgeable persistent user-specified keying

Other systems benefit from having data rendered temporarily unrecoverable. Consider the protection of data recorded during mission execution; such data can reveal tactics or even overarching strategic objectives under intelligence analysis. However, this data is also valuable for enhancing and optimizing tactics for future operations. In cases where recorded data is carried away from a weapons system on mobile media, there is a heightened likelihood of physical loss. Ideally, such physical media should be rendered inoperable during the transit between the weapons system and its secure destination.

This objective can be supported by a self-encrypting storage device that is initialized with a user-specified key before accepting data, and then purging the key for transport. Upon reaching the secured destination, the device can be rekeyed with the same key to re-enable access to the data.

Volatile keys

In contrast to the preceding scenarios, which respond to an explicit purge command or signal, many systems desire to satisfy their data-at-rest needs by automatically rendering data unrecoverable when power is removed. This strategy is frequently used to reduce protection requirements in designs for systems that must use algorithms and data that are considered “critical technology,” but which can offload storage-at-rest of these items to another system. In this usage, the self-encrypting storage acts as a secure volatile cache.

To support this scenario, a self-encrypting storage device simply needs to guarantee that it will hold no remnant of the filled key once power is removed. This may require use of remanence-resistant memories or other technologies to ensure key clearage.1 Applications arise where a smaller slave system assists a more secure system; for example, an XMC form factor single-board computer attached to a larger system.

Authenticated key derivation

Many systems do not require autonomous unmanned power-up. When an operator is available, one has the option to protect persistent cryptographic keys by storing them as a split between a persistently stored value and a value derived from an operator password. Any mobile device with a user interface – such as radio, GPS units, and pilot kneeboards – can require the operator to participate in securing cryptographic keys.

A strong password in conjunction with a cryptographically sound password-based key-derivation function can produce a significant barrier to key recovery, even for an adversary with physical access and destructive reverse-engineering capability.

To support such an authenticated key-derivation scheme, a self-encrypting storage device must implement little more than a hybrid of the persistent-keying and volatile-keying models described above. If one populates the volatile key by combining the persistent key with the outcome of a password-based key-derivation function, then one has the desired behavior.

Since strong passwords can be difficult for users to remember, considerations must be given to the human-factors side of the design. A password consisting of eight alphanumeric characters represents a space of only 36 ⁸ ≈ 2 ⁴¹ possible passwords. To mitigate the feasibility of a brute-force exhaustion of the password space, significant delays should be introduced after a few incorrect authentication attempts. Higher-security scenarios may also desire permanent disablement (purging of the persistent split of the key or erasure of the drive) upon continued authentication failure.

Additionally, consideration must be given to the eventual need to change passwords, either through security policy or personnel loss. An ideal solution should not require the storage device to be repopulated from scratch when updating the password.

System-derived password

An enhancement to the authenticated key-derivation approach can be made by removing the human factor from consideration. For example, consider a system that desires to bind the operation of a self-encrypting storage device to a host environment into which it is embedded. Rather than an operator-supplied password, the password can be derived from data strings present in the system (Figure 2).

 

Figure 2: Data sources for system-derived password.

(Click graphic to zoom by 1.9x)

 

Applications for this technique arise where common portable devices are used to provision data for specific systems in a secure environment, but which then move into a hostile environment.

Consider, for example, that a pilot provisions his mission-specific data onto the flight computer of his aircraft using common hardware. For safety reasons, it is desirable to retain the mission-specific data in case it must be re-provisioned to the aircraft; however for security during deployment, it is desirable that the mission data be rendered to a form such that it can only be read by the specific aircraft. This can be achieved by re-encrypting the mission-specific data on the portable hardware using a system-derived password – effectively a “password change” in the context of authenticated key derivation.

Continuing interest

Given the emerging role of small-scale self-encrypting devices in modern military embedded systems – particularly identifying key management and data confidentiality for such systems as the primary security concern – designers should also consider the topics of side-channel analysis, device sanitization, selection of appropriate cipher modes, and the potential for surreptitious interposition of malicious hardware between a self-encrypting storage device and its host system as a means to acquire encrypted data.

To assist designers, Microsemi has designed a family of self-encryption storage drives called TRRUST-Stor that fit into small-form-factor applications. These solutions focus on protecting data at rest in a threat environment using similar keying techniques. (Figure 3.)

 

Figure 3: TRRUST-Stor solid-state devices, engineered specifically for defense applications, can be used in data recorders, ruggedized mobile systems, mobile man-packs, and ground vehicle applications.

(Click graphic to zoom by 1.9x)

 

Reference

1 J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten. “Lest we remember: cold-boot attacks on encryption keys,” Communications of the ACM 52, 5 (May 2009), 91-98. DOI=10.1145/1506409.1506429 http://doi.acm.org/10.1145/1506409.1506429

Carey Johnson is the SSD Application Engineer at Microsemi, where he supports the company’s SSD business. He has worked in the microelectronic industry for more than 20 years in applications, product, and tactical marketing roles for leading global semiconductor companies. Carey holds Bachelor of Science degrees in electrical and mechanical engineering from North Dakota State University. He can be contacted at [email protected]. (Dr. Scott Miller, Principal Scientist, Microsemi, also contributed to the article.)

Microsemi www.microsemi.com