Gazzang provides transparent data encryption and key management to secure sensitive data at rest in big data stores and cloud environments. Gazzang solutions are in place at some of the world’s largest financial institutions, healthcare organizations, and retailers to protect personally identifiable information, corporate IP, and other sensitive data that may be subject to federal, industry, or internal compliance.

The security of the encrypted data relies on the strength of the generated encryption keys. This case study, authored by Gazzang, explains how its data security solutions leverage the Intel RDRAND instruction set included in the 3rd generation Intel® Core™ family processor (codenamed Ivy Bridge), now available on Intel® Xeon® E5 v2 and Intel® Xeon® E7 v2 product families, to enhance its encryption key strength.

Why Randomness is Necessary for Good Security

You may not use the word “entropy” on a regular basis, but it is a lynchpin for secure computing. Entropy is the property in a system that creates disorder or uncertainty.

Entropy creates randomness. Gaming applications depend on randomness in its simplest form to vary the results of a dice roll. In more complex settings, entropy provides a natural-looking flow to a school of fish or flock of birds. Conversely a lack of entropy may cause gaming applications to behave and look less natural.

In IT security, entropy is used to generate random numbers that feed into tough-to-crack encryption keys. The stronger the entropy, the stronger the encryption key.

Intel recognized this and introduced Intel® Data Protection Technology with Secure Key in the Ivy Bridge architecture. Secure Key includes the RDRAND instruction that can be used by security software for generating processor-based, high performance, highly unpredictable, random numbers to be used as crypto keys.

RNG Basics

Cryptographic operations depend on good random numbers, for example to generate an encryption key for an https connection in your browser to protect your login and password sent to your online bank. A good article on the usage of RDRAND for OpenSSL* can be found on the Intel web site.[ⅰ]

Data-at-rest encryption also relies on good encryption keys. If you can imagine thousands of files being encrypted on the fly each requiring a random encryption key, you can sense how good randomness affects the security or alternatively performance of a system.

Gazzang zNcrypt™ is a transparent data encryption solution that takes advantage of the Intel® Data Protection Technology with Advanced Encryption Standard New Instructions (AES-NI)2 crypto accelerator to boost performance. Enterprises rely on zNcrypt to encrypt massive Hadoop and NoSQL big data projects in the cloud and keep these next-generation data stores in compliance.

To decrypt the data, zNcrypt generates a 256-bit encryption key that is then stored and managed in Gazzang zTrustee™, a software-based key manager. zTrustee is one of the most popular commercial key managers used in Hadoop*, Cassandra*, and MongoDB* environments[ⅰ].

Gazzang zNcrypt relies on good entropy, such as that available from the RDRAND instruction, to generate a strong encryption key. There are many ways to use the new instruction. One is to call it directly from assembly using the code examples available on the Intel® Developer Zone website.[ⅱ]

The following section describes an example using RDRAND to feed /dev/random on a Linux* system. Note this is not the only way to use RDRAND, but for many developers this may be the most effective way to quickly take advantage of this new function on a Linux system.

LINUX /dev/random

The Linux operating system uses the concept of an entropy pool. This pool can be fed entropy from various sources; the more and better sources feeding the entropy pool, the better the resulting random numbers that can be pulled from the pool. Good random number generators (RNGs) have the following characteristics[ⅲ]:

Each new value must be statistically independent of the previous value. That is, given a generated sequence of values, a particular value is not more likely to follow after it as the next value in the RNG's random sequence.

The overall distribution of numbers chosen from the interval is uniformly distributed. In other words, all numbers are equally likely and none are more "popular" or appear more frequently within the RNG’s output than others.

The sequence is unpredictable. An attacker cannot guess some or all of the values in a generated sequence. Predictability may take the form of forward prediction (future values) and backtracking (past values).

Generally software developers pull random numbers by reading from /dev/urandom or /dev/random (the "u" stands for unlimited). Calling /dev/urandom will not block when the entropy pool is drained, so systems can continually and quickly make read requests making this method preferred in most cases even if the randomness weakens.

But what if you could feed the entropy pool with a constant stream for data and insure the pool is never drained? With RDRAND and rng-tools you can do just that.

Using rng-tools with RDRAND

There are several methods to feed the entropy pool. A common method is using Haveged.[ⅳ] In our example we will use rng-tools to pull bytes from RDRAND and push entropy into /dev/random. RDRAND is now supported as of rng-tools version 4. The source code for this open source project can be found at Sourceforge[ⅴ].

Once rng-tools is installed, start the rngd daemon by running the following command as root# rngd --no-tpm=1 -o /dev/random

We disable TPM (Trusted Platform Module)_as input and define /dev/random as the output device. rng-tools 4 and above will detect if RDRAND is supported and use it for entropy.

-n 1|0, --no-tpm=1|0
Do not use tpm as a source of random number input (default:0)-o file, --random-device=file
Kernel device used for random number output (default: /dev/random)

Now that you have rng-tools running and RDRAND feeding entropy, you can retrieve random numbers using the fopen() function. . If you are already using /dev/random, then no other change is needed in your application.

Gazzang Test Procedure

Gazzang tested RDRAND with dm-crypt and eCryptfs for data-at-rest encryption keys. Gazzang also tested OpenSSL for data-in-motion encryption keys and for gpg asymmetric key pair creation and use under various types of workloads.

In our simulation tests, the zTrustee client and the zTrustee server were hosted on a single test machine, so that differences in performance on both the client and the server would have an effect on the test results. A script ran through a series of zTrustee commands that could be affected by the quality of the entropy generator being used. First, the script registered with the server and timed the register. Then the script repeatedly registered with the server and removed the local zTrustee configuration for five minutes, while counting how many times it was able to register.

The client then put a deposit and retrieved the deposit, timing each operation. The client requested 1000 bytes of entropy from the server, timing that operation. Finally, the client requested 1000 bytes of entropy from the server over and over for 5 minutes, while the script counted how many times the entropy command could complete.

As RDRAND does not create a device of its own, rng-tools version 4 was used to read data from the hardware randomness generator and write it into the entropy pool in /dev/random. All tests were performed while there was no keyboard or mouse connected to the test system to ensure that the system was not collecting entropy from these devices. All tests were performed three times, and the data from each trial was averaged.

Results

In the graphic below you will see the register command is much faster when using RDRAND (lower is better) in comparison to not using RDRAND or haveged, providing better security AND better performance. The Put, Get, and Entropy operations below using RDRAND had the security benefit of an additional source of entropy for secure keys with no impact to performance. Using both RDRAND and haveged actually caused performance degradation, which was attributed to the extra cycles used for haveged while not contributing to the entropy provided by RDRAND.

Conclusion

While the words randomness, uncertainty, and entropy are typically avoided in business, they’re actually essential to a strong, secure data environment. Gazzang will continue to work with Intel to ensure good entropy sources are available to protect sensitive data and systems wherever they reside.

Test results of Gazzang zNcrypt running Intel RDRAND confirmed the excellent constant stream of entropy to /dev/random, while maintaining or in some cases improving performance.

[1] Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark* and MobileMark*, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. Configurations: [describe config + what test used + who did testing]. For more information go to http://www.intel.com/performance

2 AES-NI requires a computer system with an AES-NI enabled processor, as well as non-Intel software to execute the instructions in the correct sequence. AES-NI is available on select Intel® processors. For availability, consult your reseller or system manufacturer. For more information, see AES-NI