The main reason we want to use cloud technologies is because they simplify cost management and allow us spend only as much as we need at any given time. The question is how secure it is and what risks are acceptable.

When we embarked on our journey to design and implement a completely new approach to cloud security, we did realize that the hardest bit would be to make others believe us.

We knew that technology couldn’t solve this problem on its own, but we hoped that if we kept this problem in mind, we would be able to come up with good messages to our users later on.

Yes, we should have had realized that CloudHSM (a hardware appliance, hosted in Amazon datacenter) already offered at the time by Amazon doesn’t necessarily solve main issues of companies who want to move to the cloud. Well, we eventually returned to this when we analyzed a number of possible market segments. I, personally, was very much surprised how corporations didn’t accept the concept of CloudHSM.

We made a list of several problems that CloudHSM technologies face and we also realized we can provide a solution for all of them. The availability a particular solution only depended on how much are customers willing to pay for it.

Basic Cloud Security

This is the simplest option from user’s point of view and very much all security-related tasks are automated and provided by the Enigma Bridge service (EB). EB will generate keys using its secure hardware (with physical security and a random number generator (RNG) validated by NIST according to the FIPS140-2 standard).

Remote connections are secured with communication keys that create secure channels directly to secure hardware processors.

Each use of your keys is logged by the same secure hardware processor that has access to its value and can actually use the key.

User Brings Their Own Key (BYOK)

This term (BYOK – bring your own key) has been used for a little while now. It has surprisingly many meanings from the security perspective. We use it for situations when customers need or want to have some control over their keys.

1. When EB requires new user keys, users will provide a random value that is processed by an internal system key of EB secure processors. This allows users to partially control their keys. They can’t see the key value, but they can repeatedly use the same value for different operations. (This option is only available for symmetric keys.)
2. In the same situation, users can also enter their own “plaintext” key value. They can do it in a browser with client-side processing (Javascript).
3. And yet another option extending flexibility of 2. – users can enter their key in components (a discussion at Stackoverflow). It is even possible using secure hardware for situations when this needs to be audited – e.g. for payment card industry (PCI) use-cases like keys for Chip&PIN processing, re-encryptions, and so on.

Control Your Own Key (CYOK)

Enigma Bridge not only stores all keys in a special control structure, but any use of the key needs , each key is wrapped in a special control data structure that defines not only parameters of the service layer agreement (SLA) but also protects the key itself from misuse. Further, existence of the key is not sufficient for using it. The EB service needs to generate authorization tokens.

Users can opt for their key authorization tokens being generated on their premise. The cost of this option is that users must be able to host and make available secure processors for generating authorization tokens. Alternatively, these can be physically located in datacenters. These processors not only control your own key (CYOK) but also represent a physical item suitable for definition of ownership and other legal terms.

Manage Your Own Key (MYOK)

This option represents one of the most visible flaws of CloudHSMs currently on the market, where users do not have any control over appliances. EB servers can be remotely re-initialized by users themselves.

The process is relatively straight-forward. Previous user will initiate erasure of all their keys in a particular EB server or servers. Once this happens, secure hardware will enter a new state that allows new re-initialization.

As we need to manage EB service life-cycle, a minimum set of system keys is preserved. This is used to manage the secure hardware, but is completely separate from user keys. There is no way to exploit them for attacks on user keys.

New user needs asymetric keys to initialize EB servers with their own keys. While we can publish these keys digitally, out-of-band authentication and ownership proof is usually part of this re-initialization process.

Own Your Own Key (OYOK)

We are back to the traditional approach where users own appliances that contain their keys. It means users have to bear the cost of hosting their secure hardware, provide network connectivity with sufficient bandwidth and low latency.

Even in this situation, the fact that EB supports secure remote key loading means that our platform is one of very few available HSMs / CloudHSM systems suitable for modern key management.

Get in touch if you want to find out more!