Azure Key Vault is a new(ish) service offered by the Azure team. This Platform-as-a-Service (PaaS) feature, now in general availability (GA), allows you to securely manage and protect cryptographic keys and secrets that can be used by cloud-enabled applications and services. There are two compelling reasons why someone may choose to use Azure Key Vault:
- It can be used to encrypt keys and secrets (authorisation keys, storage account keys, data encryption keys, etc) using the keys that are stored within the Azure Key Vault service and which are protected by Hardware Security Modules (HMS).
- Alternatively, the stored keys can be used directly to encrypt/decrypt sensitive data.
In simple words, the Azure Key Vault service allows developers to implement cryptographic functionality in an application and never have to worry about securely storing and managing the symmetric or asymmetric keys. This is particularly important because key management is one of the weakest links in any encryption implementation right after selecting weak encryption algorithms (DES, for example is a weak choice). In addition to storing keys, the service can be used to store secrets (small pieces of encrypted data). Although this may not sound as important, the fact that sensitive data can be further decoupled from the main application data is a major benefit.
Azure Key Vault SDK
For developers, the Azure Key Vault comes with 4 different SDKs
- NET SDK
- REST API
It’s important to note that the .NET SDK is just a thin wrapper around the REST API. The wrapper has been carefully designed to abstract away the underlying complexities for setting the necessary request headers and it’s a great choice if you’re doing .NET development.
A deep dive into the service (the juicy part)
Azure Key Vault allows you to store securely cryptographic keys and secrets (encrypted data) on the cloud. The security of the data can be further complemented by using Hardware Security Modules (HSMs). The provided SDKs offer an easy way to manage the keys and secrets and perform certain operations against your data, such as sign/validate, encrypt/decrypt etc. The service supports the JSON Object Signing and Encryption specifications as defined by the IETF. You can find more info about the standards here:
At this point, it may be useful to break down the terminology so that you can get a better understanding as we go through the different features:
Vault: you can have multiple vaults in multiple geographic areas. Each vault consists of a collection of cryptographic keys and cryptographically protected data. You can think of them as folders in the file system. These folders contain sensitive information and group together logical entities. All keys and secrets relevant to a specific application are bundled together
Keys: these are cryptographic keys. Azure Key Vault currently only supports asymmetric keys (RSA 2048). The keys can be either standard (Software Protected) or Hardware Security Module(HSM) protected. Software-protected keys also benefit from HSM protection when stored and, in effect, offer the same assurances such as isolation etc.
Secrets: secrets are small chunks of encrypted data less than 10KB in size. They are useful for storing sensitive application settings in a protected manner. However, you’re not limited in using secrets for applications settings, so anything can be stored as a secret as long as it fits in size.
All objects stored in Azure Key Vault are versioned. Every time you update an existing key or secret, instead of overwriting the existing object, a new version is created. Interacting with Key Vault objects becomes more flexible because you can use different identifiers to access them.
You can use the key/secret name (e.g. “MyKey”) to perform certain operations. Accessing the key/site this way will always use the latest available version. Alternatively, you can use the key/secret name and a specific version identifier to access the non-default/latest object. Each key version has a unique identifier and URL. These allow you to directly access any key without having to request the key version list first. The object name, used as a unique identifier, must be a string between 1-127 characters and cannot contain any special characters. The name is case-insensitive and immutable. The object version, used as an extended unique identifier, is a system generated, 32-character string i.e. a GUID.
Supported encryption and hashing algorithms supported
Before messing with any code, a quick look at the supported algorithms is important in order to identify whether the service matches our security needs. The initial release of the service, only supports symmetric RSA keys. There is scope for asymmetric and elliptic curve keys in future releases. The keys can be generated either by using the service or the clients can choose to import existing keys.
For keys generated using the service, there are 2 types of supported algorithms:
- Simple RSA
More details around the supported algorithm types can be found here
There’s a set of operations that can be performed on key objects:
- List versions
Since keys cannot be exported once they are created in the Key Vault, the Backup and Restore operations can fill that gap. However, keys that are retrieved using a Backup operation are in protected form and can’t be used outside Azure Key Vault.
Cryptographic operations supported by the keys
Once a key has been created and stored in Azure Key Vault, you can perform the following operations:
- Sign a nd Verify: this feature can only be applied to hashes. It can’t be used directly on data. In simple terms, you can sign and verify hashes but not data objects
- Key Wrap a nd Unwrap: this feature is used to protect other keys. You can use one key in the Vault to protect other keys. When you apply this operation to an asymmetric key, you effectively encrypt/decrypt the key. Symmetric keys, on the other hand, are wrapped and unwrapped. Since this is a computationally heavy operation, it’s recommended that it’s performed locally.
- Encrypt/Decrypt: this feature is used to encrypt and decrypt data. Again, this operation should be performed locally for better performance.
The set of operations that can be performed on secret objects is listed below:
Managing permissions on the Key Vault Service
Access to key and secrets can be managed either on per key/secret level or whole Key Vault level. Key access policies are different to secret access policies.
The Azure Key Vault is an excellent service and a welcome addition to the overall Azure services family. It promotes the secure management of cryptographic keys without the associated overhead, which is an important step to adopting and implementing better security within our applications. In the next article, we’ll see how we can setup a Key Vault for our application and use the .NET SDK to create, manage and retrieve keys.