We have been building encryption service for a while. I grew up in the world of encryption and many things just came with experience, without being spelled out. Here’s another why I believe in “hardware encryption”.

Some will say encryption and databases are as different as night and day, which is certainly true about the technology. The similarities are striking though when we look at it from the system design and business point of view. While big cloud providers do a good job on infrastructure encryption (e.g., making sure data is secure when they recycle their SSD disks), there aren’t yet any really good options for applications, where we wouldn’t have to trust the cloud provider – but here are my thoughts.

Over the years, I worked on a number of projects that involved encryption. Almost all of these projects required several platforms and devices to talk to each other. It always involved compromises and many projects spent disproportionate amount of resources on encryption. On the other hand – they simply installed a database to store large collections of data. In a sense, encryption is just like databases – complex, expensive, and doesn’t feature on marketing materials. We just use them to provide different but in both cases crucial functionality.

There was an occasion when I designed a set of protocols and gave them to an independent researcher for a review. He/she came back with a large number of comments related to details of encryption settings. Their advice was good and followed latest disclosures of vulnerabilities and recommendations. However, there wasn’t a single platform, which would support all of them.

Each of the platforms we needed to integrate (incl. iOS, Android, OS X, Windows) had their own peculiarities, inconsistencies, and security issues. I knew what would happen, but I had an obligation to show the review to my client and explain.

There were two main aspects that I had to explain – COST and RISK.

1. If we followed all the recommendations, we would have to build, test, and integrate bespoke cryptographic libraries – while it may be easy for Windows, iOS was a different story.
2. What was the risk of using a “greatest common denominator” – if there were such a thing.

At the end, I recommended a compromise – let’s use out-of-the-box encryption where we had to work with long-term keys and depended on the particular platform. So to bootstrap a secure communication between two devices, we used whatever was available on the given platforms. Once we had a shared key, we used our own protocol to improve detection of possible attacks and close-down any security holes there.

This was just one example where I thought that encryption as a service is how secure communication and data encryption should work. And this is where the similarity with databases is. Both technologies are necessary for any modern application but they are also hidden – users may well notice if they don’t work properly but they wouldn’t think of them as “features”. The latter means there’s little sense for companies to develop their own as they are rarely a business differentiator. And lastly, good application designs separate data from application logic and integrate database storage as a service.

Use of encryption as a service has many advantages, but I find the following especially important from an architecture and system design point of view:

1. encryption service hides all the complexity of bootstrapping encryption between a random set of devices.
2. it significantly reduces the amount of encryption you need to have on the devices – all you need a secure connection to the service, which is much easier and the service may already provide that.
3. you can control the encryption much better as there is one point – the service – where you can collect all the data needed for attack detection, velocity checks, unauthorized communications, and so on.

There is one big drawback though – we create a central point, which may easily become a single point of attack. Here’s where “physical security” is important. Using secure hardware, we can significantly improve the security of all keys. It prevents all kinds of tampering and increases the cost of any attacks.

If you need to attack an encryption service using secure hardware devices, you will need to enter a datacenter, enter racks hosting the servers, remove the tamper-resistant chips and get inside them (this requires specialized laboratory equipment), or launch a side-channel attack (inside the data-center, again with specialized hardware and analytical software).

I find it interesting that this argument showing the need for hardware-secure encryption is built purely on the cost of implementing an application with a secure distributed communication needs.

That’s why I believe that our CloudFoxy (with PDF signing) as well as cloud encryption platform Enigma Bridge works even when you just need to protect your master database keys. We have created a demonstration code, which is rich on comments but shows just 3 core lines in Python :

• uo_aes = pickle.loads(base64.b16decode(USE_CONTEXT))  – load connection data
• pd = ProcessData(uo=uo_aes, config=uo_aes.configuration) – create a service context, including the definition of the encryption operatoin
• result = pd.call(from_hex(‘6bc1bee22e409f96e93d7e117393172a’)) – the encryption itself

This shows how easy it is to use encryption as a service.

PS: You may argue that I left out a lot of details – true. I would argue that all the concerns you may have can be taken care of by the service (and if not, there’s no straightforward solution there anyway). For example – this service allows users to determine keys but they will not know them as they will be combined with master keys inside secure hardware chips (unless specifically defined as imported from outside). Encryption operations are done in security chips – with really good physical (tamper-responsive) security (FIPS 140-2 Level 4 for physical security). The chips need to be initialized – but that process uses secure chips and secure channels between those chips – this initialization could be “doctored” but that is possible to discover witch a subsequent audit – if anyone can be bothered – without compromising the service security.

There’s been a lot of thinking going into this particular service design – by pretty good guys (some of them discovered ROCA problem, some successfully hacked commercial HSMs, aka hardware security modules).

This level of security and good design is not something you can come up with in a couple of months time during a well-funded project.