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”.
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 differently.
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. His 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.
- 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.
- 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. Use of a service has many advantages, but I find the following especially important from an architecture and system design point of view:
- encryption service hides all the complexity of bootstrapping encryption between a random set of devices.
- 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.
- 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 has 3 actual lines in Python (load connection data, create a context, encrypt), which shows how easy it is to use encryption as a service.