Best Practice: Client-side encryption with Azure Storage Services

Client-side encryption with Azure Storage Service improves data protection ranking. Zero-Knowledge Environment is a good risk mitigation strategy in absent of network or storage level isolation. Payload encryption or client-side encryption can help to achieve both.

In a previous Secure Data by Payload Encryption or Client-side Encryption in Public Cloud Services post, we discussed the advantages and disadvantages of Client-side Encryption at architectural or strategical level.

In this post, let’s discuss best practices around Azure Storage Service and Data Encryption. The implementation of any client-side encryption consists of following,

• Encryption Key Management
• Validation and policy enforcement
• Implementation

Encryption Key Management

In Azure, you can manage secrets either by your own implementation (that may be custom solution, open source application) or Azure KeyVault. I would certainly recommend KeyVault (unless there is a good reason to substitute it).

Advantages of KeyVault

• The service uses HSM (Hardware Security Module), to be specific, Azure KeyVault uses FIPS 140-2 Level 2 validated, Thales nShield family of HSMs. Reference 
• As a PaaS service, it is a fire and forget bullet for any consumer. SLA, Security and Service Management is Microsoft Azure team’s responsibility.
• Azure Key Vault features multiple layers of redundancy to make sure that your keys and secrets remain available in case of region failure or service outage, the secondary region located at least 150 miles away. KeyVault region is routed to a secondary region.
• Supports ACL with Azure AD.
• Supports IETF standards, i.e. JWK, JWE, JWA, and JWS
• Excellent documentation and REST API.

Disadvantages of Azure KeyVault

• No granular control over service, as any other PaaS.
• Currently, it does not support Network Isolation, which is necessary with some finance industry compliances i.e. PCI DSS. However, there are some mitigation techniques can help to solve the issue. (To be frank, I do not see it a disadvantage because from security perspective Azure KeyVault is more secure than many self-managed solutions, it sometimes feels just a be formality).
• Cost (Yes, it is not free). However, employing efficient key caching techniques, you can reduce cost.

For this particular example, 1. Create 128-bit key – ASCII Range character are 1 byte thus 16 characters would make a 128-bit key. (for strength of the key should be considered using threat perception and modelling, the stronger the key better security but less performance) - this best practice is around engineering than security, so you shall revalidate the strength of the key per case basis. 2. Convert to base64. 3. Convert to SecureString. 4. Add to Azure KeyVault. 5. Add appropriate ACL.

//KeyVault name
$myKeyVaultName = "NilayCornerVault"

//Secert name
$mySecretName = "MySecret"

//Secret phrase
$myKey = "loliamnotstupid"

//Convert secret into bytes
$myKeyBinary = [System.Text.Encoding]::UTF8.GetBytes($myKey)

//Base64 encoding
$myKeyEncoded = [System.Convert]::ToBase64String($myKeyBinary)

//Convert to SecureString
$myKeySecretVault = ConvertTo-SecureString $myKeyEncoded -AsPlainText -Force

//Add key to vault
$mySecret = Set-AzureKeyVaultSecret -VaultName $myKeyVaultName -Name $mySecretName -SecretValue $myKeySecretVault -ContentType "application/octet-stream"

C# example to retrieve created a key, it would be good practice to cache the key as necessary.

KeyVaultKeyResolver cloudResolver = new KeyVaultKeyResolver(GetToken);
SymmetricKey symmetricKey = (SymmetricKey) cloudResolver
   .ResolveKeyAsync(
       "https://nilaycornervault.vault.azure.net/secrets/MySecret/",
       CancellationToken.None)
   .GetAwaiter()
   .GetResult();

Validation and policy enforcement

RequireEncryption mode, it is an optional flag, and the default value is false. I would recommend to turn the feature on, as a mode of operation would enforce all uploads and downloads are must encrypt.

The Azure Storage Service client would fail any attempt without an encryption policy or downloading data that is not encrypted.

CloudBlobClient.DefaultRequestOptions.RequireEncryption = true;

The option is supported by Azure Storage Table and Azure Storage Queue as well as.

Implementation

In the age of Microservices and IoT Envelope Encryption is a very useful pattern. Theoretically, the application is universal and supported by Azure Key Vault and AWS KMS.

Advantages of Envelope Encryption pattern

• Data is protected two-fold.
• Additional protection from eavesdropping and phishing.
• Performance.

If you want to learn more about digital envelope encryption then follow the link  . Client-side encryption, implementation is straightforward two-step process,

• Encrypt the content and store in Azure Storage Service
• Retrieve Azure Storage Service content and Decrypt

I am going to skip the Azure Storage Client API context and assume that audience is familiar with the Azure Storage Client.

Encrypt the content

1. The Azure Storage Client generates a content encryption key (CEK). CEK is one use symmetric key. Data is encrypted using CEK.
2. CEK is encrypted using a master encryption key (Key Vault). Generate Key Encryption Key. Master encryption key could be locally managed or ideally stored and manage through Key Vault.
3. Upload encrypted data to Azure Storage Service, and encryption information is either stored as blog metadata or another secure mechanism of your choice.

Decrypt the content

1. Key resolver resolve required key identifiers to keys and retrieved (ideally, store temporarily in the local cache).
2. The Azure Storage Client download the encrypted data along with all metadata that we store during encryption.
3. Decrypt CEK (using master key – Key Vault) and use the content encryption key to decrypt the download user data.

Just come across envelope encryption sample code and tutorial on Microsoft, so I think it would be worth referring the up to date sample code at MSDN Sample  .