Blog | Townsend Security | On-Board Encryption

For applications that require the highest level of security, developers can use the on-board, NIST-compliant encryption and decryption services on Alliance Key Manager, rather than encrypting at the application or database level. Under this strategy, encryption keys never leave the key manager. With on-board encryption services, small chunks of data, such as credit card numbers, Social Security numbers, e-mail addresses, etc are encrypted on the server (physical HSM, VMware, or virtual appliance in the cloud). Because data is securely transferred to the key manager for encryption, it is recommended for smaller amounts of data. For larger amounts of data, it is still recommended to encrypt at the database or application level.

Using an Encryption Service
Businesses can use onboard encryption effectively to improve their security posture and reduce their attack surface. This strategy is helpful in situations where they don’t want to expose the encryption key in their application or server environment. For businesses who have their data in the cloud, this also alleviates the risk of exposure of the encryption key in cloud memory.

Encryption Service Performance
The performance of an encryption service is one of the biggest concerns that businesses have when taking this approach to protecting data. To shed some light on these concerns, we did some testing using our Java SDK on small blobs (<16KB) and with our .NET Key Client for large blobs.

As a general metric, it is fair to say that for small pieces of data, the average latency for AES encryption (using CBC mode) is 50ms, yielding a rate of 20 operations per second.

Large Blob Performance

The results of testing with the .NET Key Client for large blob:

Quant | Avg. enc. time
1MB | 462 ms
2MB | 535 ms
5MB | 949 ms
7MB | 1.16 s
10MB | 1.74 s
15MB | 2.34 s
25MB | 3.61 s
50MB | 7.60 s
70MB | 10.65 s

This can be represented as a graph:

Seconds vs Size

Taking this data and calculating the rate at which Alliance Key Manager is encrypting data, we were able to generate this graph:

AKM size of data being decrypted
The horizontal axis is the size of the data being encrypted--the larger the file, the more likely it will approach maximum speed. For encrypting small pieces of data, the process of establishing a connection to Alliance Key Manager and sending the data vastly outweighs the actual encryption, so the rate shows as very low. It spikes up to about 6.5 MB/s when the size of the data is around 5MB--larger than that, and the time to encrypt can be predicted using that rate.

The major take-away: encrypting large blobs on AKM using the .NET Key Client occurs at a rate of 6.5MB/s. It is likely that the Java SDK, and other SDKs, would have about the same level of performance. This data was compiled on an AKM with 1CPU and 2GB of memory. Doubling those resources yields a small increase in performance--up to 6.9 MB/s .

Conclusion

While there are performance impacts when encrypting large amounts of data with an encryption service (as opposed to encrypting an entire database or column within), it does provide improved security on smaller amounts of data for business wanting to minimize their encryption key exposure. Further, by utilizing Townsend Security’s encryption service, businesses can have confidence that they are protecting their data with NIST-compliant AES encryption. NIST compliance means that the encryption implementation has been reviewed by an independent testing lab who reports the results to NIST for validation.

Supporting two models for encrypting data = Alliance Key Manager

Traditional encryption key retrieval with local encryption is when you retrieve the encryption key from the hardware security module (HSM) key server and use it with your own local encryption library to encrypt or decrypt data. The encryption key is transmitted securely from the key manager to your application, your application uses the key as long as it needs to, and then destroys that key.

On-board encryption is where you can send the data to the server, along with the name of the encryption key, and ask the server to encrypt or decrypt the data. In this case you never retrieve the encryption key, you actually send the data to the HSM device encrypted or decrypted, the encryption takes place on board actually within the hardware security module (the key manager itself), and you get the results sent back securely to your application.

When would you typically choose to do on-board encryption rather than retrieve the encryption key and then do encryption locally?

Vulnerable client applications - you would want to use onboard encryption when you have more risk in an exposed environment (web application or ATM or kiosk), that way the encryption key (which is the secret you're trying to protect) remains within the HSM and never leaves it.
Amount of data to be encrypted is small - Small chunks of data, such as credit card numbers, Social Security numbers, e-mail addresses, etc., are prime examples of things you can use onboard encryption for effectively.
If you don’t have encryption library - if you're working with an embedded system and you have a small amount of resources on your application side.

When should you not use onboard encryption for applications?

When you have large amounts of data it is best to retrieve an encryption key and perform the encryption locally.

How does Townsend Security’s encryption key manager, Alliance Key Manager, implement on-board encryption?

Your application will launch and create a secure encrypted TLS connection to Alliance Key Manager. There is an authentication mechanism that requires you to have a proper certificate and private key.
When that connection is open and authenticated, you send the data that you want encrypted and the name of the encryption key to be used to the key manager HSM.
Once the encryption is complete and the key manager sends data back to your application over the same secure channel, the connection can then be torn down.

Once a developer has decided to use onboard encryption with Alliance Key Manager what do they need?

There are three mechanisms that we deploy to make it a straightforward and simple process for developers use on-board encryption or key retrieval.

First we provide some software libraries, dynamic link libraries, in Windows or .NET assemblies or LINUX of shared libraries that can be used out of the box to perform these kind of tasks. These software libraries are on our AKM supplemental CD image and are free to use.
We also provide actual sample source code, that can be used as a starting point for an on-board encryption or traditional encryption key retrieval project.
We also provide purpose built applications that are ready to use out of the box to implement onboard encryption (typically by a configuration option when our software is installed).

For more information this brief video will talk about traditional encryption key retrieval versus onboard encryption services on the Alliance Key Manager device:

When you want to use, or avoid using, onboard encryption
Practical guidelines on how Alliance Key Manager implements the encryption service
How your applications will actually use either key retrieval or onboard encryption
Some performance and connection issues, and then
We'll point you to some resources that might be helpful as you do your project

Townsend Security Data Privacy Blog

Encryption Service Performance with Alliance Key Manager

Traditional Encryption Key Retrieval vs. On-Board Encryption?

Supporting two models for encrypting data = Alliance Key Manager