Key Management/storage system

Question

In my firm we have a couple of thousand hardware devices, installed externally, that all send back data to a central server. They send back data about every hour.

Each of these hardware devices encrypt the data they send with an individual encryption key, typically an AES 128 bit encryption, but there are several other encryption methods as well, including asymmetric encryption methods.

What I need, is to do is to safely store all these keys and from the input server be able to decrypt data as it comes in, the input system is made in C# .NET. The encryption keys have to, for security reasons, be stored on a different server. Do you know of any encryption key storage systems that support the above?

We may only have a couple of thousand hardware devices currently, but the system should be able to handle hardware devices in the 100s of thousands.

I have through test and research already found that systems such as Oracle Key Vault are not ideal for our purpose. I have yet to find a system that does not focus on Database security, credentials security

Answer 1

You should rework your entire system. It is inherently far less secure than it should be. There is no good reason that you should be storing encryption keys that could be used to impersonate your devices on your servers at all. Rather, you should be providing each device with a signed certificate (from one private CA that you can operate securely using CA best practices). This affirms to you that a) each device actually is using a public/private key pair authorized by you and b) allows you to verify each device from the public cert which you can store in the clear (or even be transmitted by the device at the start of each connection and not stored on your servers at all).

For talking to your servers, you only need to have one private key used for all communications and a public key used by the devices to verify your server. AES can still be used for the individual sessions between the client and server, but the key can be generated on the fly, exchanged using the asymmetric system and then discarded at the end of the session.

Under this setup, you only need to store 2 to 4 keys securely instead of needing an entire infrastructure to manage keys whose only irreplaceable value is to attackers that are trying to compromise your system.

Update: If you really can't use a proper distributed key infrastructure, then you will need to use key chaining to minimize the sensitive data. Encrypt each of the keys with a master key, thus enabling them to be stored safely anywhere. Setup an extremely locked down server with the master key and have it provide encryption and decryption services for the system so that the keys are never decrypted outside that system. That system would then basically be functioning as an HSM (if you can get an actual HSM, that would be preferable.) Connections would be sent off to that system along with their encrypted encryption key. The system would decrypt the traffic and provide it back to the requester. You would additionally need some kind of security to authenticate the services making requests of the encryption/decryption server, though the specific needs there depend largely on what kind of security you need on the data at your site.

Answer 2

As AJ Henderson has mentioned, if you need to use keys in this manner than they should really be stored in an HSM. If you are simply storing the keys on a separate server then this does not provide much, if any, additional security. If one of your servers is compromised then you have to assume that your other servers could be compromised as well, and once this machine has been compromised any key data can simply be read from the drive or from memory.

If the keys were stored in an HSM on the other hand, it would be impossible for anyone to access the key data, even if they have complete control of all your host machines. The key data cannot be exported from the module (at least, not without physical authorisation, depending on the type of HSM), and even physical access to the HSM would not allow the key data to be read as the devices usually use some form of potting covering the components, such that any attempt to access them will destroy the hardware.

Depending on the type of HSM you use they will usually provide a standard API that you can use to access the keys and cryptographic functions. The most common of these is PKCS11, which can be used from C# through various wrappers, though there is also Microsoft's CryptoAPI (CAPI), Capi NextGen (CNG), Java JCE, etc.