Does Amazon Want To Control All Encryption Keys?

print
Public cloud providers have absolute control over our data, applications, everything we do on their cloud platform. Independent key management lowers users’ risk exposure and as such is in the interest of cloud providers. Well, Amazon AWS has different thoughts.

The ending: Policy restrictions will prevent  an AWS Marketplace listing of your hardware encryption, whether as paid-for AMI, BYOL AMI or even SaaS.

Enterprise PKI with FIPS140-2 keys

Moving to public cloud can streamline your business and companies are increasingly taking advantage of the scalability, reliability and cost effectiveness of cloud computing. The main argument against is all about security and there are many companies that find it too risky to trust cloud providers like Amazon (AWS) with their sensitive data. By definition, the cloud provider has full access to everything it hosts via backdoor.

One way to alleviate this problem is that customers keep control over encryption keys protecting their sensitive data. In other words, you run your key management either on-premise or in physically secure hardware protecting your keys from tampering (your lock and key).

Our company, Enigma Bridge does just that. It enables companies to use public cloud, while preserving their control over their encryption keys. These keys are stored and protected by tamper-proof computers. If there is an attempt to compromise these keys, the tamper-proof computers will erase them.

After enabling our secure key management platform on Amazon (AWS) we wanted to put our solution in Amazon Marketplace, as part of our marketing activities. But much to our surprise, our application for listing of FIPS 140-2 PKI, was DECLINED as Amazon’s internal policy is to restrict companies to AWS hosted key management. The infrastructure, which they ultimately control.

Our Service Overview

Let me briefly introduce our cloud service in question to provide an initial context. Last September, we have integrated PrimeKey’s PKI enterprise key management system with our encryption platform (you can read about the service here). Our encryption platform uses hardware processors with a high physical security, preventing anyone from tampering with them. (See the note below for details.) This physical security protects you – as a user of such system – against the hosting company and possible mistakes or errors on their side. It is an active protection unlike more common reporting features.

The idea was to offer this service via Amazon’s AWS Marketplace, which simplifies billing, offers some marketing opportunities for small companies, and in a way, can be viewed as an endorsement by Amazon AWS. We built the service to production level with real-time enrollment to our hardware encryption platform. We submitted a request for listing at the beginning of October.

Getting to AWS Marketplace

We submitted the initial form and the first-line support team connected us to AWS solution architects in order to explore our dependency on hardware servers. A necessary requirement to use our hardware encryption. Solution architects escalated us further to security specialists.

The first concern raised was: do we send any personal data out? I’m not sure what kind of personal data could be on a new virtual server – our answer was “no”.

Solution architects asked for a design overview. We provided them with an architecture and design overview. A few days later, we answered how we separate customers on our hardware encryption platform, implement monitoring, and management.

Out of the blue, the solution architects replied:

The nature of the product relies on your hardware, while for SaaS we expect > 50% of resources to be existing in AWS. Sorry we are unable to support this product right now.

We had discussed that before with AWS Marketplace guys and so we used all the contacts we had to re-assure the solution architects that this view was not correct and the AWS seller support team was helpful and acted on our behalf.

Another set of questions followed.

Given the product is CaaS and relies on your HSM to be functional, we would need more information how the crypto hardware is managed (reliability/security etc).

We did say that what we use is CaaS – cryptography as a service – from the outset,  so we just provided more information as requested.

Some days later, we received an update, which included the following statement.

Our security teams have been investigating more into this and it is going to take some time for us to decide. Please note that the decision will impact not just new sellers like EnigmaBridge, but also existing product listings.

That was the last time we heard from the AWS solution architects – no replies to our queries, no explanation.

Eventually, we received a final confirmation from the sellers support team. We had been declined access to the AWS Marketplace in any form.

From what I’ve been able to gather the policy restrictions will prevent an AWS Marketplace listing, whether as paid-for AMI, BYOL AMI or even SaaS.

Why?

Initially, the problem we hit was identified as a “breach of T&Cs” of the AWS Marketplace, but it was then re-phrased to “a change in the Amazon’s policy“. Does it really take two months to find out that we are in breach of the policy or did our request raise red flags somewhere in the risk/legal departments?

The latest response suggested that the final decision would impact all currently listed marketplace products using hardware security. That is – hardware security provided by third parties – is my understanding. If I put it bluntly – AWS said they would NOT allow any independent key management, which would limit their access to keys of AWS customers. Your keys! That is a breathtaking decision.

One of the reasons we were given was that Amazon is not able to verify security of all such services. That seems to make sense, but only till you start thinking about.

Amazon Marketplace offers a range of services, which impact security of users’ data – from database encryption, virtual key management, network routing and filtering services, and so on. I believe that the idea that the use of a third party hardware encryption is somehow special in terms of the need to verify its security wouldn’t stand any scrutiny.

My Thoughts

While an independent security audit can be a genuine concern, I have difficulties to understand how hardware encryption differs from products like network routing, databases, or even software encryption products. Anyone building cloud applications should agree that encryption is only part, possibly a small part, of application security. And there is a saying about the importance of “the weakest link”.

Amazon is active in promoting products of other companies and building partner networks. That was certainly our impression and experience as well. The support team was very helpful so I don’t believe us offering a competing product to their CloudHSM service could be a factor here.

There is an aspect of the control though.

Amazon and Control Over Customers

We live in the real world. There is a constant re-balancing between internet users trying to protect their privacy, enterprises protecting their commercial interests, and government protecting us all.

There has been a few years of discussions about the power of governments, their access to our data and where should the line between privacy and security of the people be (key disclosure, government access in EU,  NSA and disclosure policies, etc.). The question is, what is the role of cloud providers.

All big players in the public cloud platform space offer a very good protection on the “platform level”.

  1. They encrypt data on the disk  – if someone steals a disk from their data center, the data will be encrypted.
  2. They provide HTTPS – so if someone listens on your web traffic, it will be encrypted.
  3. They provide audit logs – if your employee accesses a database server, you will see a record of that.

Neither of these security measures, however, protects against threats from the cloud platform provider:

  1. The disk encryption key is stored in software on a virtual server run by the cloud provider.
  2. The HTTPS server key is available on your virtual servers or via the provided software key management service.
  3. A court order may prevent the cloud provider to log access to your data if approved by a judge.

We do appreciate there is a security landscape, the real world, trying to balance all interests I just didn’t expect that it could prevent a start-up company getting its hardware encryption to a public cloud marketplace.

But maybe I’m wrong and I should trust the Amazon team that they just want to protect their customers from rogue service providers that could compromise their data. They may further argue that it is sensible to have a complete control over all our data. It’s the only way for Amazon to ensure that no-one else can compromise it.

A Note About Physical Security

Physical security is important when third parties host computers or servers. They provide lock&key to their owners and users. There are several standards defining the level of assurance as it has been an important aspect for governments, banks, and other enterprises for a long time.

One of the standards is FIPS140-2 by the U.S. based NIST institute.

If one tries to extract keys from physically secure computers, they will erase the keys if the computers have been evaluated to the overall Level 3 or 4. The processors we use have the highest level of the physical security, the Level 4 as defined by the FIPS140-2 standard and overall security is on Level 3. Amazon AWS, Microsoft Azure, and others offer FIPS140-2 services as well, but only on overall Level 2.

You may think that the difference between Level 2 and 3 must be small but the opposite is true if you don’t control physical servers. In layman terms, Level 2 means you can see broken tamper-evident seals on the server when you inspect the box, Level 3 means that the server erases secrets before the attacker can extract them.

Published by

Dan Cvrcek

Founder and CEO of Enigma Bridge, engineer, entrepreneur, cryptography SME, security architect, and professor.