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.
In this blog post, we will cover the following,
1. How Microsoft is mitigating the vulnerability
2. How to verify if you use client-side encryption feature?
3. Explore additional protection with private endpoints & limiting network access
4. Alternatives to client-side encryption – Azure Storage server-side encryption
5. Action Required to remediate this vulnerability
6. Brief – Azure Storage server-side encryption
7. Frequently Asked Questions
If you have any further questions or concerns, please open a support case through the Azure Portal at aka.ms/azsupt.
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 provide ability for you to read and write data encrypted with v1 version i.e backward compatible with v1. The updated sdks are now in GA(Generally Available).
This vulnerability impacts only if your code is using client side encryption feature of Azure Storage SDK. Below is how you can check if your code is using client side encryption feature from Azure Storage SDK.
You could additionally explore adding protection against this vulnerability with Private endpoints and limited network access.
You can learn more about these and explore other security recommendation here
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 azstorageencryption@microsoft.com.
There are three steps that you need to follow to update your applications and fully mitigate the above mentioned CBC mode vulnerability.
The following sections describe how to update your code to use client-side encryption v2 with each SDK:
A. .NET SDK
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
});
B. Java SDK
C. Python SDK
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)
If you have any further questions or concerns, please open a support case through the Azure Portal at aka.ms/azsupt.
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.
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 azstorageencryption@microsoft.com.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.