Oracle Cloud Infrastructure – Vault Service to generate, manage and encrypt & decrypt using Keys

The Vault service lets you create vaults in your tenancy as containers for encryption keys and secrets. Vaults are logical entities where the Vault service creates and durably stores keys and secrets. The type of vault you have determines features and functionality such as degrees of storage isolation, access to management and encryption, and scalability. The type of vault you have also affects pricing.

If needed, a virtual private vault provides you with a dedicated partition in a hardware security module (HSM), offering a level of storage isolation for encryption keys that’s effectively equivalent to a virtual independent HSM. Keys are stored on highly available and durable hardware security modules (HSM) that meet Federal Information Processing Standards (FIPS) 140-2 Security Level 3 security certification. The Vault service uses the Advanced Encryption Standard (AES) as its encryption algorithm and its keys are AES symmetric keys. Note that the virtual private vault has a substantial price tag (several $ per hour) whereas the default vault can be used for free.

Note: Before the introduction of secrets as a resource, Oracle Cloud Infrastructure Vault was known as Oracle Cloud Infrastructure Key Management.

Keys are logical entities that represent one or more key versions that contain the cryptographic material used to encrypt and decrypt data, protecting the data where it is stored. When processed as part of an encryption algorithm, a key specifies how to transform plaintext into ciphertext during encryption and how to transform ciphertext into plaintext during decryption.

After you create your first master encryption key, you can then use the API to generate data encryption keys that the Vault service returns to you. Some services can also use a master encryption key to generate their own data encryption keys.

The OCI API for the Vault Service gives the ability to encrypt contents using one of the generated keys – resulting in unreadable contents – and to decrypt contents that has previously been encrypted using that same key. In encrypted state, the data can freely be shared without fear of revealing the original content.

Note: you should be aware before creating a Vault that it cannot be deleted instantly. When you delete a vault, the vault and all its associated keys go into a pending deletion state until the waiting period expires. By default, this is 30 days, but can be set from a minimum of 7 days up to a maximum of 30 days. When a vault is deleted, all its associated keys are also deleted. In terms of costs, it seems that you do not actually pay for the vault in teh pending deletion state.

Here is an example of a Vault:

Creating a key that is used to encrypt and decrypt strings – or anything you want to have encrypted and decrypted – is done in the console like this:

Using the Key for some Encryption

The key can be used to encrypt any contents – from the REST API, the OCI CLI or any of the SDKs. This figure illustrates the process. We start out with some very private details that are currently not secured in any way (in the orange system on the left). We want to transfer the private details to the yellow system on the right – in a secure manner. The first step is to securely invoke the Vault API to use the key we have generated before to encrypt our very private details. This results in an encrypted package of data. The contents of this package is not readable – not to the orange system and not to the yellow system and not to anyone listening in on the transport from one to the other system..

Here we take the opening line from the novel Anna Karanenina, base64 encode it and encrypt it -using the OCI CLI to make a call to the Vault Service;s API.

keys=$(oci kms management key list -c $compartmentId --endpoint $vaultManagementEndpoint)
export keyOCID=$(echo $keys | jq -r --arg display_name "lab-key" '.data | map(select(."display-name" == $display_name)) | .[0] | .id')
toEncrypt=$(echo "Happy families are all alike,every unhappy family is unhappy in its own way." | base64)
# the next line removes the spaces from $toEncrypt variable 
toEncrypt=$(echo $toEncrypt| tr -d ' ')
encrypted=$(oci kms crypto encrypt --key-id $keyOCID --plaintext $toEncrypt --endpoint $vaultCryptoEndpoint)
export cipher=$(echo $encrypted | jq -r '.data | .ciphertext')
echo "This is the result of the encryption, a text that we can send anywhere and that no one will understand: $cipher"

The relevance of this encryption is of course that we now have a piece of content that we can unsafely transport and store. No one will be able to make heads or tails of it. Without the private key held in the OCI Vault, it is not currently possible to decipher this text.

The encrypted value in this case:

EaMrUykRMCjWAJD/USV8K8+ajFvaxJNBAg/3AHR6WJL8ggSRAGfNuyLd/Lzm6CHhXuIj8VdF+bSStgetIofpmcCJ4Nz6QJV78NhaMNsUcG8jK1CJCrQidWQnqmQNr6EHxmHmp/Bc62Q3BhNN/wirRFlrTwAAAAA=

This is not readable. It is secure at the message level – and can be communicated through insecure communication channels – such as a blog article.

Decrypting the Cipher

Let’s assume now we are the yellow system. And we have received a package of gibberish. We cannot read it. No one can. However, we know that the Vault Service knows how to decrypt it. So, assuming that the yellow system has been granted access to the Vault and more specifically, to the key that was used to encrypt the data, this system can now use Vault Service to do the decryption:

And now for some decryption magic: get a the original contents from this unreadable encrypted text, using the decrypt operation for the master key. Let’s assume the cipher has traveled around the world, has been seen by many unworthy eyses. And no one could crack it. The only way to reveal its inner meaning is through the decryption operation in OCI (unless perhaps you have a very big computer and plenty of time and you can crack it).

Now is the time for decrypting the thing – using the key in the vault:

decrypted=$(oci kms crypto decrypt --key-id $keyOCID  --ciphertext $cipher --endpoint $vaultCryptoEndpoint)
export b64encodedPlaintext=$(echo $decrypted | jq -r '.data | .plaintext')
echo $b64encodedPlaintext | base64 --decode

First, the cipher is decrypted. The result is the base64 encoded plaintext that we can normally read when it is base64 decoded.

Conclusion

The OCI Vault Service allows us in a very simple way to make data secure. To allow us to share data securely over insecure transport means.

Resources

OCI Vault, Keys and Secrets – technical documentation

https://blogs.oracle.com/developers/protect-your-sensitive-data-with-secrets-in-the-oracle-cloud

.