Loading...

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

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)

 

  1. 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.

 

ManuYareshimi_0-1655507136041.png

 

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.
  1. 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.
  1. 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.
  1. When will the mitigation be in GA?
  • Will GA in July.
  1. Who do I ask any questions?

 

Published on:

Learn more
Azure Storage Blog articles
Azure Storage Blog articles

Azure Storage Blog articles

Share post:

Related posts

Bringing Context to Copilot: Azure Cosmos DB Best Practices, Right in Your VS Code Workspace

Developers love GitHub Copilot for its instant, intelligent code suggestions. But what if those suggestions could also reflect your specific d...

14 hours ago

Build an AI Agentic RAG search application with React, SQL Azure and Azure Static Web Apps

Introduction Leveraging OpenAI for semantic searches on structured databases like Azure SQL enhances search accuracy and context-awareness, pr...

18 hours ago

Announcing latest Azure Cosmos DB Python SDK: Powering the Future of AI with OpenAI

We’re thrilled to announce the stable release of Azure Cosmos DB Python SDK version 4.14.0! This release brings together months of innov...

2 days ago

How Azure CLI handles your tokens and what you might be ignoring

Running az login feels like magic. A browser pops up, you pick an account, and from then on, everything just works. No more passwords, no more...

3 days ago

Boost your Azure Cosmos DB Efficiency with Azure Advisor Insights

Azure Cosmos DB is Microsoft’s globally distributed, multi-model database service, trusted for mission-critical workloads that demand high ava...

5 days ago

Microsoft Azure Fundamentals #5: Complex Error Handling Patterns for High-Volume Microsoft Dataverse Integrations in Azure

🚀 1. Problem Context When integrating Microsoft Dataverse with Azure services (e.g., Azure Service Bus, Azure Functions, Logic Apps, Azure SQ...

6 days ago

Using the Secret Management PowerShell Module with Azure Key Vault and Azure Automation

Automation account credential resources are the easiest way to manage credentials for Azure Automation runbooks. The Secret Management module ...

7 days ago

Microsoft Azure Fundamentals #4: Azure Service Bus Topics and Subscriptions for multi-system CRM workflows in Microsoft Dataverse / Dynamics 365

🚀 1. Scenario Overview In modern enterprise environments, a single business event in Microsoft Dataverse (CRM) can trigger workflows across m...

7 days ago

Easily connect AI workloads to Azure Blob Storage with adlfs

Microsoft works with the fsspec open-source community to enhance adlfs. This update delivers faster file operations and improved reliability f...

7 days ago

Microsoft Azure Fundamentals #3: Maximizing Event-Driven Architecture in Microsoft Power Platform

🧩 1. Overview Event-driven architecture (EDA) transforms how systems communicate.Instead of traditional request–response or batch integration...

7 days ago
Stay up to date with latest Microsoft Dynamics 365 and Power Platform news!
* Yes, I agree to the privacy policy