Preview: Azure Storage updating client-side encryption in SDK to address security vulnerability

About the client-side encryption security vulnerability
Azure Storage .NET, Java, and Python SDKs support encryption on the client with a customer-managed key that is maintained in Azure Key Vault or another key store. Current release versions of the Azure Storage SDKs use cipher block chaining (CBC mode) for client-side encryption (referred to as “v1”). The current implementation of CBC block mode is vulnerable to a padding oracle attack, provided the attacker has write access to the blob and can observe decryption failures. The attacker would need to perform 128 attempts per byte of plain text to decrypt blob contents. We view putting this combination of qualifiers together for an attack to be rare. We encourage customers to assess the risk to their scenarios.

How Microsoft is mitigating the vulnerability
Azure Storage is announcing the release of a new version of the client-side encryption feature (referred to as “v2”) in the Azure Storage SDKS to mitigate the CBC mode vulnerability. Given this vulnerability in CBC, v2 will not use CBC mode for client-side encryption instead use AES-GCM for client-side encryption, which is a major change in client-side encryption feature. The updated sdks are able to read data encrypted with v1 version i.e backward compatible with v1. The update is now available as a preview and will become generally available (GA) in July 2022.

The preview of client-side encryption v2 should not be used with production workloads until it is released for general availability (GA), but we encourage you to try the preview and provide feedback. If you are using client-side encryption in your applications today, we recommend that you start planning and testing so that you can migrate your data with the GA release in July.

Explore adding protection with private endpoints & limiting network access
You could additionally explore adding protection against this vulnerability with Private endpoints and limited network access.

• Private endpoints - It can secure all traffic between your VNet and the storage account over a private link.
• Limit network access to specific networks - It can limit access to specific networks hosting clients.

You can learn about these and explore other security recommendation here

Alternatives to client-side encryption
Azure Storage offers server-side encryption features which address most customers’ needs for encryption protection at rest and reduce the management overhead and burden associated with client-side encryption. We strongly encourage you to explore server-side encryption for your needs and use it in place of client-side encryption if possible. To learn more about server-side encryption offerings, see the “Azure Storage server-side encryption” section at the bottom. If you have any questions, email us at [email protected].

Testing with the preview

There are three steps that you need to follow to update your applications and fully mitigate the above mentioned CBC mode vulnerability. To reiterate, the preview of client-side encryption v2 should be used for testing purposes only, and not with production workloads.

1. Update your code to use the v12.x SDK of your choice if you have not done so already.
2. Update your code to use client-side encryption v2.
3. Validate the migration of your data by downloading it, reencrypting it, and uploading it again. Important: Microsoft does not recommend using the preview to decrypt and reencrypt production data. The preview should be used for testing purposes only.

The following sections describe how to update your code to use client-side encryption v2 with each SDK:

A. .NET SDK

1.  If you are using v11 or previous SDK versions, which are deprecate, please update your code to use the v12.x SDK. Here is the migration guide (here).
2. Download preview release of client-side encryption v2 and update your code to use client-side encryption v2. Download blob package here , queue package here.

C#

var client = new BlobClient(myConnectionString, new SpecializedBlobClientOptions()

{

    ClientSideEncryption = new ClientSideEncryptionOptions(ClientSideEncryptionVersion.V2_0)

    {

        KeyEncryptionKey = myKey,

        KeyResolver = myKeyResolver,

        KeyWrapAlgorihm = myKeyWrapAlgorithm

    }

});

Or

client.WithClientSideEncryptionOptions(new ClientSideEncryptionOptions(ClientSideEncryptionVersion.V2_0)

{

    KeyEncryptionKey = myKey,

    KeyResolver = myKeyResolver,

    KeyWrapAlgorihm = myKeyWrapAlgorithm

});

3. Validate migrating data from client-side encryption v1 to v2 for your scenarios. Don’t use the preview version to migrate your critical production data. See the Sample project here to help you get started.

Java SDK

1. If you are using v8 or previous SDK versions, which are deprecate, please update your code to use the v12.x SDK. Here is the migration guide (here).
2. Download preview release of client-side encryption v2 and update your code to use client-side encryption v2.
   • Download blob package here.
   • Sample code - here. Essentially use create the builder with V2 encryption version i.e EncryptedBlobClientBuilder(EncryptionVersion.V2)
3. Validate migrating data from client-side encryption v1 to v2 for your scenarios. Don’t use the preview version to migrate your critical production data. See the Sample project here to help you get started.

Python SDK

1. If you are using v11 or previous SDK versions, which are deprecate, please update your code to use the v12.x SDK. Here is the migration guide (here).
2. Download preview release of client-side encryption v2 and update your code to use client-side encryption v2. Download blob package here and queue package here).

blob_client = blob_service_client.get_blob_client(container=container_name, blob=blob_name)

    blob_client.require_encryption = True

    blob_client.key_encryption_key = kek

    blob_client.encryption_version = ‘2.0’  # Use Version 2.0!

   with open(“decryptedcontentfile.txt”, “rb”) as stream:

        blob_client.upload_blob(stream, overwrite=OVERWRITE_EXISTING)

3. Validate migrating data from client-side encryption v1 to v2 for your scenarios. Don’t use the preview version to migrate your critical production data. Detailed steps are here to help you get started.

If you have any questions, email [email protected]. For issues or feedback, please log them in the respective Github repo which you will find via the download links for each language provided above.

Azure Storage server-side encryption

Azure Storage uses server-side encryption to automatically encrypt your data when it is uploaded. All data in all storage accounts is encrypted by default, so you don’t need to do anything to take advantage of Azure Storage server-side encryption at rest.

By default, server-side encryption uses Microsoft-managed keys to encrypt your data. You can also choose to manage encryption with your own keys. To leverage the default encryption option using Microsoft-managed keys, just update your code to stop using client-side encryption. All data that you upload is automatically encrypted by Microsoft. Learn more at Azure Storage encryption for data at rest.

If you choose to manage your own keys for encryption, you have the below two choices. All object metadata will also be encrypted.

1. Customer-managed keys (CMK): You can specify a customer-managed key to use for encrypting and decrypting data in Azure Storage. Customer-managed keys must be stored in Azure Key Vault or Azure Key Vault Managed Hardware Security Model (HSM).
   For more information about CMK, see Configure encryption with customer-managed keys stored in Azure Key Vault.
2. Customer-provided keys (CPK): You can specify a customer-provided key (CPK) on Blob storage operations. A client making a read or write request against Blob storage can include an encryption key on the request for granular control over how blob data is encrypted and decrypted. The CPK is only available to Azure Storage for a limited time to perform the operations and not permanently stored in the service.
   • Azure Storage does not store the key you provide on the request, it stores the cryptographic hash of the key to verify that all subsequent operations against the blob use the same encryption key. Customer-provided keys can be stored in Azure Key Vault or in another key store.
   • For more information about CPK, see Provide an encryption key on a request to Blob storage.

To migrate previously encrypted data, you will need to reupload it to Azure Storage. We are working on getting the steps for this and we will update this blog once we have it. Please email us if you need it urgently, or if you have any questions / feedback / gaps with server-side encryption, at [email protected].

Frequently Asked Questions

1. How likely is this vulnerability going to affect my workload and data ?
   • As explained in the first section, we view this CBC padding oracle to be rare, as it needs combination of many qualifiers together for an attack. We encourage customers to assess the risk to their scenarios.
2. How would I know if I need to take action?

• Please check if you are using either .net, Java or Python Azure Storage SDK and in your code if you use client-side encryption to upload your data to Azure Storage.
• If not, there is no action needed from you.

3. What actions do I need to take ?

Azure Storage SDK is releasing updated version of their sdks which include v2 of client-side encryption to mitigate about mentioned vulnerability is in preview. We recommend following actions,

1. Please start planning and testing the preview version so that you can migrate your code and data with the GA release in July.
2. Please provide feedback as you find any issues or recommendations while you test
3. Explore if you can add additional protection against this vulnerability. See section “Explore adding protection with private endpoints & limiting network access” above.

4. Why is the mitigation in Preview and not in General Availability?

• The v2 version of client-side encryption is removing CBC mode and switching to AES-GCM for data encryption which is a major change. To launch the feature with good quality and performance, we would like to follow the standard process for any major changes i.e to preview, collect feedback from customers and perform additional in-depth testing.
• Hence this is in preview now and will GA in July.

5. When will the mitigation be in GA?

• Will GA in July.

6. Who do I ask any questions?
   • Email [email protected] with your questions or any concerns.