Bring Your Own Key: What Is It and What Are Its Benefits?
29th March 2019 by Elton Jones @ID-3 
Ever since cloud computing first emerged, security has been a prime concern of end users. The idea of handing over control of IT systems to third party operators by running hosted applications and infrastructure on remote servers has always sat uncomfortably with a significant number of business owners and CTOs.
These concerns are doubled when it comes to migrating the most sensitive data and the most mission critical applications into the cloud.
Over the years, cloud service providers have been able to win over most doubters on security with cutting edge privacy and anti-malware protections combined with state-of-the-art redundancy protocols. But on data, the disquiet persists. Out of your control, hosted on a remote multi-tenant server, who’s to say who really has access to it?
All data stored on a cloud platform, and indeed all data traffic communicated back and forth between the client and the host, is protected by encryption. But encryption is only as secure as the encryption keys used to decipher it. The question of ownership of the keys then raises its head. If they are also hosted in the same cloud system, managed by the same third-party operator, you are back to square one with the security concerns. If an external party can see or get hold of your encryption keys, they can get access to your data.
Bring Your Own Key (BYOK) is a protocol that aims to resolve this problem by maintaining a fundamental separation of encrypted data and encryption key. While your data might be entrusted into the hands of a cloud service provider, the key is not – at least, not in a way that forfeits the end user’s control over it, or makes it in any way accessible to external parties.
What does a fundamental separation of encryption and encryption key mean in practice? In the most simple terms, it means that your cloud host does not encrypt your data for you, or have anything to do with generating the key. BYOK means that encryption keys are generated, stored and applied completely independently by the client – they literally ‘bring their own key’ to enable encryption.
Taking HSM into the Cloud
To achieve secure encryption of data assets in an on-premise system, enterprises have long relied on hardware security modules (HSMs). An HSM is a cryptographic device which generates, stores and safeguards strong keys for the management of encryption across an IT system. Sophisticated and tamper resistant, an HSM can manage multiple digital keys for different use cases.
While HSMs remain a powerful cryptographic tool for on-premise systems, they were not designed for external encryption. Once you start introducing the public and private cloud, multiclouds and hybrid infrastructures into the equation, HSMs cease to be as effective. Until recently, there has been no accepted standard by which cloud providers will accept HSM-generated keys to work on their systems.
The main alternative to HSMs for cloud encryption to date has been Key Management Services (KMS). KMS is an encryption service offered and managed by a cloud provider for use on their own platforms. It offers all the key functionality you would get from an on-premise HSM, but solves the issue of compatibility. But the big drawback goes right to the heart of concerns over ownership and control of encryption – it hands the keys to the same people hosting your data services, which requires a considerable level of trust and removes any claim of ‘sole control’.
BYOK can be seen as offering a middle ground between HSM and KMS, some of the control but less of the overhead. Indeed, HSMs are integral to the BYOK concept. The approach has been pioneered by nCipher, which has developed an HSM product – nShield – that is compatible with the three biggest global cloud platforms, Microsoft Azure, Amazon Web Services (AWS) and Google Cloud.
nShield operates like any other HSM. Encryption keys are generated and stored within the on-premise device, meaning you are not handing over control to a third party provider – you are in charge of how and when the keys are used. The main difference is, nShield keys can be exported to the cloud service provider allowing the provider to encrypt data for applications hosted in the cloud as well as those run on premise.
With AWS and Google Cloud, keys are ‘leased’ to the host temporarily to encrypt digital assets on their servers. After an allocated period, the keys are automatically destroyed so there is no risk of them sitting on remote servers indefinitely waiting to fall into the wrong hands. Decryption is handled on the client side. Because the client retains the master key on premise, they can simply export a copy to the cloud provider as and when needed to update or change their encryption.
Azure Key Vault
With Azure, things work differently. nCipher has worked with Microsoft who host a highly available platform of nShield HSMs in the Azure cloud, the Azure Key Vault, and provide a protocol for securely storing encryption keys in it. The key is used to manage data encryption in the cloud environment, without the provider (Microsoft in this case) having any access to the data. In this formulation, BYOK completely integrates the robust security and control offered by HSM with the flexibility of the cloud.
The Azure Key Vault essentially works by encrypting the encryption key. Using the Transparent Data Encryption (TDE) approach, it encrypts the Database Encryption Key (DEK) stored on the boot page of a database using an asymmetric key known as a TDE Protector.
The TDE Protector can be generated in the client’s own on-premise HSM and then exported to the Azure Key vault via a secure bridge. But in what is arguably the biggest innovation of the nCipher and Microsoft BYOK approach (the systems leverage of nShield SecurityWorld controls end-to-end), the Azure Key Vault can also generate the TDE Protector itself. This is not like a KMS where the service provider generates and manages the key – this is all still controlled by the customer, but using a secure cloud environment rather than their own HSM.
The key point here is that even when the TDE Protector is generated within the Azure Vault, the cloud provider does not see and cannot extract the key. This maintains the confidence of full control for the client without the need for a highly available on-site HSM. Moreover, the HSM is not required once the tenant key is in the Azure Vault. Data services might be managed in the Azure cloud, but there is still effective and complete separation from responsibility for encryption and security, with the client managing keys and permissions for the Azure Vault migrated keys themselves.
BYOK is therefore all about establishing and maintaining trust in cloud data security by keeping all control of the encryption in the hands of the data owner – as they would have if they were running their databases on site. What the Azure approach demonstrates is that this confidence can still maintained even when the security protocols themselves are migrated to the cloud.
nCipher shows how nShield BYOK can strengthen your cloud key management practices.
