"Keys" to COTS encrypting of data-at-rest

Story

March 10, 2014

Paul Davis

Curtiss-Wright

Data security is a major concern for all businesses these days. One only has to follow the news coverage of data breaches at large retailers, major corporations, and government agencies to see the financial and security fallout from these attacks. However, for deployed military applications, data security has always been a concern and thanks to new Commercial Off-The-Shelf (COTS) options, data-at-rest security has become more efficient and affordable.

After data that is “on-the-move” reaches its intended destination and is stored, it is considered “Data-At-Rest” (DAR). For deployed applications, the preferred DAR storage technology is solid-state memory. Rotating disks have been used in rugged deployed applications, but only with elaborate and costly vibration-damping systems. Today there are three types of NAND flash used as the basic building blocks for solid-state memory. Multi-Level Cell (MLC) memory is commonly used in USB sticks and SD cards, but its temperature range is too narrow for deployed applications. While significantly less costly than Single-Level Cell (SLC) memory, MLC has only one-tenth the endurance. SLC memory supports a wide temperature range and provides high endurance (100,000 writes to a single cell), making it today’s preferred memory for deployed applications. A new type of memory provides a compromise approach: “enterprise MLC” (eMLC) offers a wide temperature range and good endurance at a cost between that of SLC and MLC.

All solid-state memory systems employ common methods to ensure that data is properly retained – methods that include wear leveling, bad-block mapping, error correction, and write-amplification techniques to improve the storage life. Now that we have cost-effective memory options for deployed applications, how do we protect that critical data?

Encryption choices

Regardless of whether SLC or eMLC memory is used to store the data-at-rest, choosing the optimal encryption method can be complicated. While a variety of encryption schemes and methods are available, the final choice will depend on the application. The decision about which level of encryption is required for a particular application rests with the program’s Designated Approving Authority (DAA). When selecting and approving the ideal encryption approach, the DAA must trade off costs, schedule, risks, and operational constraints. The DAA may decide, for example, that even though an encryption method is below the level of NSA-certified, the security level is satisfactory for protecting classified data because the stored data will be protected by armed guard. The DAA will also likely evaluate other factors such as the storage medium’s anti-tamper mechanisms.

Encryption built into the SSD

Today, encryption is frequently offered within the Solid-State Drives (SSDs). Some SSDs support AES 128-bit encryption, while newer models are upgrading to AES 256-bit. In either case, the SSD is shipped with the encryption key already installed. The user must log in with a password in order to use the drive. The current key can be cleared or purged by initiating a “Secure Erase” or “Enhanced Secure Erase” process. A new key can be internally generated, often using a random-number generator. However, any data that was encrypted with the old key will be irretrievably lost.

For deployed applications, having the key reside with the SSD poses concerns when the SSD (and data-at-rest) need to be transported. If the SSD were lost or stolen and the password coerced from the user, the key can be accessed, making sensitive data readable. Purging the key prior to transport makes the data unreadable and irretrievable. Sensitive data, such as that captured on an airborne mission, may have been very costly to acquire, making its loss unacceptable.

By itself, encryption within the SSD may be satisfactory for Sensitive But Unclassified (SBU) applications, but the technique is unlikely to satisfy applications requiring higher security levels, such as Secret and Below Information (SABI) or Top Secret and Below Information (TSABI). As noted earlier, the DAA determines which method is acceptable for a particular application. If the SSD is guarded during transport by a soldier with an M-16, the DAA may find this method of encryption adequate.

FIPS 140-2 encryption

Encryption modules for use with SBU data are defined in Federal Information Processing Standards Publications (FIPS PUBS) issued by the National Institute of Standards and Technology (NIST). FIPS products are controlled by the U.S. Department of Commerce, and are not normally International Traffic in Arms Regulations (ITAR)-restricted. “Security Requirements for Cryptographic Modules,” defined by the FIPS PUB 140-2 or FIPS 140-2 standards, specify the security requirements for a cryptographic module utilized within a security system to protect SBU data.

FIPS 140-2 provides four increasing qualitative levels of security, which cover the wide range of potential applications and environments. The standard provides guidance for design and testing for cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; finite-state model; physical security; operational environment; cryptographic key management; Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.

The Cryptographic Module Validation Program (CMVP), a joint effort between NIST and the Communications Security Establishment (CSE) of the Government of Canada, provides validation for cryptographic modules to FIPS 140-2. FIPS 140-2 validated products are accepted by the federal agencies of both countries for the protection of SBU information (United States) or Designated Information (Canada). CMVP-accredited labs – listed on the NIST website – are located in numerous countries, indicating the international nature of FIPS 140-2 and broad acceptance of FIPS 140-2 validated encryption products.

FIPS 140-2 certification can be pursued by any company, which then covers all costs for validating their particular product. Unlike certification for the higher-level Type 1 encryption, FIPS 140-2 does not require a program sponsor. The FIPS 140-2 validation certificate not only indicates that an encryption product is fit to handle SBU data, but also demonstrates a certain discipline in the design and documentation process. Some SSD manufacturers have already obtained or are in the process of obtaining FIPS certification.

FIPS 140-2 validated encryption (and storage) modules are available that incorporate FIPS validated 256-bit AES algorithms. These modules offer administrator options in which the AES key can be either internally generated or externally provided. The security risks of using an internally generated key were discussed above, and if the key is purged, the data-at-rest is lost forever. When the externally provided (or pre-placed) key option is used, the AES key can be provided via commands after properly logging into the FIPS encryption module and the user is authenticated. An externally provided key also gives the DAA additional options. The key can be cleared, the module safely transported, and after, the key can be re-inserted providing access to the data-at-rest once again.

Secret and Below Information

If an application requires SABI data security, the encryption product used must be NSA Type 1-certified for at least SABI. Type 1 products contain approved NSA algorithms and are available to U.S. government users, their contractors, and federally sponsored non-U.S. government clients. Type 1 encryptors are subject to International Traffic in Arms Regulations (ITAR) restrictions.

An example of a DAR system with an encryptor certified for SABI is Curtiss-Wright’s rugged Compact Network Storage (CNS). The CNS-T1 is a convection-cooled network file server that supports CIFS, NFS, HTTP, FTP, and PXE protocols for connection to any computer system supporting industry-standard protocols. Designed for use in manned and unmanned ground, air, and sea vehicles, the CNS features an internal third party SATA-to-SATA encryptor. This encryptor was developed and certified under the auspices of a program that required SABI encryption in an attended vehicle. It is now available for use in similar programs of record with a need for SABI encryption. It can support applications for secret data as well as SBU data.

The encryptor was embedded into the CNS. The CNS acts as the front-end interface to network clients. CNS converts the data from these clients to SATA, after which the data is routed to the encryptor, which encrypts it with an internally generated key. The encrypted SATA data is then sent to an encryption-free SSD-based storage module (see Figure 1).

Figure 1: CNS Type 1 network file server for SABI applications.

(Click graphic to zoom by 1.6x)

When using internal generated keys, both the encryptor and the storage module must be removed for transportation to a CNS in another location. For example, after an aircraft lands from a mission, you must remove the encrypted storage module from the aircraft and utilize a ground station to allow the analyst to read and interpret that data garnered during the mission. In the case of self-generated keys, you must keep the encryptor with the storage module or the data will be unreadable. For applications where this is not practical, mediation is being developed to support the use of Pre-Placed Keys (PPK). With PPK support, the encryptor can be left in place so that only the storage module need be transported. The same key can be loaded in the second location, providing access to the data. Transport of the data without any key is highly desired.

Top Secret and Below Information and unattended operation

For applications that require TSABI security, an encryption product will need a minimum of NSA Type 1 certification. A few TSABI encryptors, developed at government expense for a program of record, are currently available for DAR applications. At present, none of these encryptors have been certified for unattended operation on platforms such as unmanned air, ground, or undersea vehicles. Currently, some programs are considering combined requirements for TSABI and unattended operation. It will require one program of record and a Department of Defense (DoD) sponsor to step forward and drive TSABI encryptor certification for unattended operation.

Summary

System designers have broad encryption options, ranging from SSD encryption and FIPS to SABI and TSABI encryption. For unattended operation, the industry awaits the first program and sponsor to step forward before vendors can take the next steps needed to provide data-at-rest security in unmanned vehicles.

Paul Davis has 30 years of experience holding positions in Product Management, Sales Management, Engineering, and Engineering Management for various technical companies. Paul has been with Curtiss-Wright for 16 years, holding positions as Director of Engineering, Director of Sales and Marketing, Product Manager, and currently holds the position of Director of Product Management. Paul earned a BSEE from the University of Cincinnati and an MBA from Indiana University. Reach him at [email protected].

Curtiss Wright Defense Solutions 703-779-7800 www.cwcdefense.com