Encrypting “Data At Rest” Using FIPS 140-2 Cryptographic Modules

Sensitive information falling into the wrong hands is a major security concern. The US government’s latest approach to combat this problem is to essentially encrypt everything that transmits or stores data. VPNs or secure socket layers protect data flowing across networks.  Data at rest, which is data stored on physical mediums like hard drives, CD-Rs, DVD-Rs, USB sticks, etc., must also be protected. Hard drive encryption is easy since most modern enterprise-level operating systems include this feature. Removable storage, on the other hand, is a hodge-podge of solutions and very few of them are compatible with each other.

Archiving encrypted data

Important data may need to be kept for long time. Offline storage is a tempting target for thieves and other bad actors. Physical media can be “borrowed,” copied, and replaced without the owners knowledge. Even worse, its contents could be modified to introduce viruses or corrupt data. This is especially easy on re-writable media. Encryption mitigates these risks by making the media unreadable and unmodifiable to anyone without the proper credentials.

The potential for obsolescence is a serious consideration when choosing a solution. It’s difficult to know if the current crop of encryption products will be supported if and when it’s needed in the distant future. It reminds me of the BBC’s Domesday Project:¹

It was meant to be a showcase for Britain’s electronic prowess - a computer-based, multimedia version of the Domesday Book. But 16 years after it was created, the £2.5 million BBC Domesday Project has achieved an unexpected and unwelcome status: it is now unreadable.

The special computers developed to play the 12in video discs of text, photographs, maps and archive footage of British life are - quite simply - obsolete.

As a result, no one can access the reams of project information - equivalent to several sets of encyclopaedias - that were assembled about the state of the nation in 1986.

It took only about a decade and a half before the data became effectively inaccessible. Technology in the mid 80s was not just primitive; it was also extremely diverse. Computers and peripherals from companies like Atari, Acorn, Apple, Commodore, IBM, and Tandy did not play well with each other. Floppy disks formatted in one manufacturer floppy drive couldn’t be read on a competitor’s drive. Word processing programs stored data in unique proprietary formats. Operating systems were usually designed for a single hardware platform. There were very few standards and the ones that existed were bent and broken frequently.

The original Domesday Book was produced on a mature and ubiquitous data storage system: paper. The format of this storage method is well understood and used heavily throughout the world. The 900+ year old book is still readable to this day.

Munroe, Randall. “Digital Resource Lifespan.” xkcd. https://xkcd.com/1909/

The reboot of the Domesday Project using modern technology and file formats should fare much better. Computer ownership and usage has exploded since the project’s heyday. International standards set by governing bodies like ISO ensure data compatibility. I’ll wager that decoding a JPEG file will still be easy to do very far into the future. Nevertheless, not every technology is as pervasive as digital pictures. The state of data-at-rest encryption seems more like 1986 than 2017.

Vendor lock-in

Strong encryption ciphers are pretty standard across the tech industry, but encrypted data formats are not. AES is a widely-used specification for symmetric key encryption and is found in many products. The problem with most encryption software is that they produce encrypted data that cannot be decrypted by another product even if it shares the same algorithm. Imagine if every different company that made pin and tumbler locks had their own particular style of key. There would be no common key “blank” that could be cut and fit into more than one brand of lock. (Most residential door lock companies use either Kwikset or Schlage key/cylinder formats.)

The requirement put forth by the US government is to encrypt data on removable storage media using FIPS 140-2 validated encryption ciphers. Symantec and McAfee offer products that are quite robust. However, they can also be overkill for most organizations. Even more troubling, their encrypted data formats are proprietary. They also require that their software be used exclusively for burning CD/DVD discs. They provide their own layers of security that can be at odds with the standard OS controls. A more lightweight option would be to use a product that just packages, compresses, and encrypts files. Most modern file archival programs include options to encrypt data, but few are FIPS 140-2 compliant. WinZip Enterprise edition claims to include certified ciphers, but the archive files can only be extracted with WinZip. (It might be possible to generate a self-extracting archive, but I’m not sure that option would be FIPS 140-2.) None of the above mentioned products are interoperable with Linux as far as I can tell.

A strange game. The only winning move is not to play.

I don’t trust any vendor to decrypt my data decades from now unless they want to give me the source code and instructions how to compile their product in the event they go belly-up. I decided on an open source software product instead: OpenSSL. Most tech folks know and use OpenSSL to secure website communications. However, it’s also a darn good file encrypter, too. There are FIPS 140-2 libraries available, so a special compiled version can be created that hopefully makes the government auditors happy. Best of all, it’s free.

The downside of OpenSSL is the lack of a user-friendly turn-key operation. Building a FIPS compliant version of it on Linux is relatively easy, but Windows is more difficult. There’s no GUI interface for OpenSSL, so non-techy users would be resigned to use the command-line. Therefore, I decided to create my own graphical front-end for the express purpose of file encryption/decryption. I also wrote a bash script to make it easier to use on the command-line, too.

I will describe how to build OpenSSL with the FIPS libraries on Linux and Cygwin in a future blog entry. I’ll follow that up with a native Windows build and I’ll provide the source code for my OpenSSL GUI.

References

1. McKie, Robin, and Vanessa Thorpe. “Digital Domesday Book lasts 15 years not 1000.” The Observer, Guardian News and Media, 3 Mar. 2002, www.theguardian.com/uk/2002/mar/03/research.elearning.