Confidentiality: Securing ...
30 October 19

Confidentiality: Securing Your Keys in Azure

Posted byMbong Ekwoge


In my previous post, I said the following about Confidentiality:

Confidentiality is the concept of the measures used to ensure the protection of data, objects, or resources. The goal of confidentiality protection is to prevent or minimize unauthorized access to data.Encryption is a means to protect the confidentiality of your data. This is extremely important in the Cloud since you have limited control over the cloud provider's infrastructure. It requires the exchange of encryption keys in order for decryption to take place. Protecting these keys is of utmost importance to an organization. Key protection is part of the overall Key Management process.

According to the NIST, "the proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration."

The NIST has further warnings. "Similarly, poor key management may easily compromise strong algorithms. Ultimately, the security of information protected by cryptography directly depends on the strength of the keys, the effectiveness of mechanisms and protocols associated with keys, and the protection afforded to the keys."

What is the solution? The NIST standards are clear. "All keys need to be protected against modification, and secret and private keys need to be protected against unauthorized disclosure. Key management provides the foundation for the secure generation, storage, distribution, use, and destruction of keys."

A robust encryption key management system and its policy should explicitly address:

  • The encryption key lifecycle
  • Physical access to the key server(s)
  • Logical access to the key server(s)
  • User/role-based access to the encryption keys

In this blog post, we will review different encryption types, how to use encryption keys, the concepts of crypto-periods, and Azure Key Management System - Azure Key Vault.

Types of Encryption Keys

Symmetric Keys

When the same key is used to encrypt and decrypt data, this is called symmetric keys. It's primarily used to protect data at rest.

Asymmetric Keys

Asymmetric keys are a pair of keys for the encryption and decryption of data. Both keys are related to each other and created at the same time.

The public key (of the recipient) is used to encrypt the data, which happens on the side of the sender after it has received the public key of the intended recipient. The private key is used to decrypt the data and is known only to the recipient, whose public key has been used to encrypt the data.

Asymmetric keys are primarily used to secure data-in-motion.

How Symmetric Key Systems Work


Terms Definition
Data Encryption Key (DEK) An encryption key whose function is to encrypt and decrypt data.
Key Encryption Key (KEK) An encryption key whose function is to encrypt and decrypt the DEK.
Key Management API (KM API) An application interface that is used to securely retrieve and transport encryption keys from a Key Management Server (KMS) to the client requesting the keys. 
Certificate Authority (CA) An entity that creates public and private keys and certificates, verifies certificates, and performs other PKI functions. 
Transport Layer Security (TLS) A crypto-graphic protocol that provides security for data-in-motion.
Key Management System (KMS) The system that manages the key management software, such as Azure Key Vault.



  1. A user requests access to encrypted data.
  2. The storage system sends a DEK retrieval request to the client Key Manager (KM) API.
  3. The client or KM AP and KM verify each other's certificates:
    1. The KM API sends a certificate to the KM for verification
    2. The KM checks the certificate against the CA for authentication
    3. Once the KM API certificate has been verified, the KM sends its certificate to the KM API for authentication and acceptance.
  4. Once the certificates have been accepted, a secure TLS connection is established between the KM API and the KM.
  5. The KM decrypts the requested DEK with the KEK.
  6. The KM sends the DEK to the client (KM API) over the encrypted TLS session.
  7. The KM API sends the DEK to the storage system.
  8. The storage database (may) cache the DEK in temporary secure memory.
  9. The storage system sends the plaintext information to the user.

How Asymmetric Key Systems Work


  1. The sender and recipient verify each other's certificate.
    1. The sender sends a certificate to the recipient for verification.
    2. The recipient checks the received certificate against its CA for authentication.
    3. Once the sender's certificate has been verified, the recipient sends its certificate to the sender for authentication and acceptance.
  2. Once there's mutual acceptance, the sender requests the recipient's public key.
    1. The recipient sends its public key to the sender.
  3. The sender creates what is known as an ephemeral key (a symmetric key used for a single session only).
  4. The sender encrypts the ephemeral symmetric key with the public key (received from the recipient).
  5. The sender then sends the encrypted data with the encryption symmetric key.
  6. The recipient receives the packet and decrypts the symmetric key with its private key.
  7. The recipient then decrypts the data with the symmetric key.

Key Usage

In general, a single key should be used for only one purpose, be it encryption, authentication, key wrapping, random number generation, or digital signatures. There are several reasons for this:

  • The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.
  • Limiting the use of a key limits the damage that could be done if the key is compromised.
  • Some uses of keys interfere with each other. For example:
    • Consider a key pair used for both key transport and digital signatures.
      • The private key is used as both a private transport key to decrypt data encryption keys (DEK) and a private signature key to apply digital signatures.
      • It may be necessary to retain the private transport key beyond the crypto-period of the corresponding public transport key in order to decrypt the data encryption keys needed to access encrypted data.
    • If that scenario is unnecessary, the private key signature should be destroyed at the expiration of its crypto-period to prevent its compromise.

This principle does not preclude using a single key in cases where the same process can provide multiple services. For example:

  • When a digital signature provides nonrepudiation, authentication, and integrity protection using a single digital signature.
  • When a single symmetric data encryption key can be used to encrypt and authenticate a single cryptographic operation - e.g. using an authenticated encryption operation, as opposed to separate encryption and authentication operations.


A crypto-period is the time span during which a specific key is authorized for use by legitimate entities, or the keys for a given system will remain in effect. A suitably defined crypto-period:

  • Limits the amount of information protected by a given key that is available for cryptanalysis.
  • Limits the amount of exposure if a single key is compromised.
  • Limits the use of a particular algorithm to its estimated effective lifetime.
  • Limits the time available for attempts to penetrate physical, procedural, and logical access mechanisms that protect a key from unauthorized disclosure.
  • Limits the period within which information may be compromised by inadvertent disclosure of keying material to unauthorized entities.
  • Limits the time available for computationally intensive crypto-analytic attacks (in applications where the long-term key protection is not required).


In general, short crypto-periods enhance security. For example, some crypto-graphic algorithms might be less vulnerable to cryptanalysis if the adversary has only a limited amount of information encrypted under a single key.

On the other hand, where manual key distribution methods are subject to human error and frailty, more frequent key changes might actually increase the risk of exposure. In these cases, especially when very strong cryptography is employed, it may be more prudent to have fewer, well-controlled manual key distributions rather than more frequently, poorly-controlled manual key distributions.

Azure Key Vault

Azure Key Vault helps solve the following problems:

  • Secrets Management
    • Azure Key Vault can be used to securely store and tightly control access to tokens, passwords, certificates, API keys, and other secrets.
  • Key Management
    • Azure Key Vault can also be used as a Key Management solution. It makes it easy to create and control the encryption of keys used to encrypt your data.
  • Certificate Management
    • Azure Key Vault is also a service that lets you easily provision, manage, and deploy public and private Secure Sockets Layer / Transport Layer Security (SSL / TLS) certificates for use with Azure and your internal connected resources.
  • Store secrets backed by Hardware Security Models
    • The secrets and keys can be protected either by software or FIPS 140-2 Level 2 validated HSMs.

As a secure store in Azure, Key Vault has been used to simplify scenarios like:

  • Azure Disk Encryption
  • The always encrypted functionality in SQL server and Azure SQL Database
  • Azure App Service

Key Vault itself can integrate with storage accounts, event hubs, and log analytics.


Thus far you've been introduced to Key Management Systems and Encryption-at-Rest. In the next blog post, we'll take a deeper look at other confidentiality protocols and their implementation in Azure. Stay tuned.


Dive deeper into Azure with Cloud Application Architecture-A Structured Approach, led by Mbong Ekwoge.

Sign in with your All Access Pass today!




Need training for your entire team?

Schedule a Demo

Hey! Don’t miss anything - subscribe to our newsletter!

© 2022 INE. All Rights Reserved. All logos, trademarks and registered trademarks are the property of their respective owners.
instagram Logofacebook Logotwitter Logolinkedin Logoyoutube Logo