we used Encrypt and decrypt blobs using Azure Key Vault to protect our files from dev ops person or any unwanted access to files.
i have created the RSA key like below
now i have few doubts
#1 : if i set expiration date to this key,( let's say 2 year from today's date ) will it effect my encryption? -
for example, after 2 year, i will create new RSA key and old files which is already encrypted wont be able to decrypt ? if answer is no - how the version changed will make sure decryption keep working?
#2 : which RSA key size i have to use ? what is best as per industry standards?
#3 : in blob files, have metadata properties added by SDK : "encryptiondata" - what is that, and it include "EncryptedKey" also, what's that use?, seems like SDK is doing behind the process, when we set "BlobEncryptionPolicy"
#4 : when we set KEY to azure key vault - is it private key or public key? will we're able to see it's content ?
let's say someone got to know the RSA key from key vault in plain text..he/she will download encrypted files directly from blob and use that key in separate program and unlock/decrypt it?
Thanks,
#1 In Azure Keyvault the encryption keys don't have an expiry by default. But it is a good practice to set one. And then rotate the keys.
Rotation would involve Generate new key(s),
Re-encrypt all data that was encrypted using the old key, using new key(s)
Delete old encrypted data and old encrypted key.
Azure supports three models with respect to Data Encryption.
1)Server-side encryption using Service-Managed keys
2)Server-side encryption using customer-managed keys in Azure Key Vault
3) Server-side encryption using customer-managed keys on customer-controlled hardware
You can read more about that here. https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-models
and choose the option that you need.
If you need to bring your own keys in azure storage - https://learn.microsoft.com/en-us/azure/storage/common/customer-managed-keys-overview
Rotation process can be automated with Events, event grid, functions.
For example A secret near expiry gets triggered when the secret is near its expiry date and that is captured in an event grid and the necessary action is taken via an azure function who's trigger is that event grid mapping for this event.
Azure runbook based automation options are also possible.
#2 Bigger keysize is tougher or takes time to crack is what I know and from what I read 2048 or 4096 should be good. But again there are schools of thought on not using standard keysize etc. I guess you can consult a security/cryptography expert for the specifics.
#3 those properties refer to the default encryption at rest done in azure storage. Refer the data encryption models available for azure storage.
#4 In Azure keyvault a Cryptographic key is represented as JWK (JSON Web Key)
for Example a .pfx certificate file that contains a pair of public & private keys.
The API call to GetKeyAsync doesn't return private key data.This is why the DecryptAsync wrapper method does use the Key Vault API for decryption.
Related
Hi everyone im trying to receive my blob storage data via my spring boot client application. I can retrieve the data however it is encrypted.
In my Storage Account settings the encryption type is "Microsoft-managed keys". Now, where do find the key i need for decrypting my data? I am kinda confused i'm just not able to find the key.
Thanks a lot in advance
Azure Storage encrypts all data in a storage account at rest. By
default, data is encrypted with Microsoft-managed keys
All data that is written into Azure storage will be automatically encrypted by Storage service prior to persisting, and decrypted prior to retrieval. Encryption and decryption are completely transparent to the user. All data is encrypted using 256-bit AES encryption, also known as AES-256—one of the strongest block ciphers available. With encryption enabled by default.
Reference: https://azure.microsoft.com/en-in/blog/announcing-default-encryption-for-azure-blobs-files-table-and-queue-storage/
And The Microsoft managed keys used for encryption are not available
In Your scenario check the encryption type at the client side Data that is already encrypted when it is received by Azure. With client-side encryption, cloud service providers don’t have access to the encryption keys and cannot decrypt this data. You maintain complete control of the keys.
For more details refer this document: https://learn.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest
I have some encrypted Azure Blobs that I need to decrypt using this Azure Key Vault mechanism. Is there any possibility of using Scala or Python in databricks to do this decryption? I am not sure if there are any libraries available in either of these languages that will allow me to do the decryption? If you know of any libraries or have some sample code that can work in Python or Scala, it would really help.
Thanks!
Try using Azure Storage Client Library for Python supports encrypting data within client applications before uploading to Azure Storage, and decrypting data while downloading to the client.
Use the Encryption via the envelope technique contains the following steps
1) The Azure storage client library generates a content encryption key (CEK), which is a one-time-use symmetric key.
2) User data is encrypted using this content encryption key (CEK)
3) The CEK is then wrapped (encrypted) using the key encryption key (KEK). The KEK is identified by a key identifier and can be an asymmetric key pair or a symmetric key, which is managed locally. The storage client library itself never has access to KEK. The library invokes the key wrapping algorithm that is provided by the KEK. Users can choose to use custom providers for key wrapping/unwrapping if desired
4) The encrypted data is then uploaded to the Azure Storage service. The wrapped key along with some additional encryption metadata is either stored as metadata (on a blob) or interpolated with the encrypted data (queue messages and table entities).
Decryption via the envelope technique: contains the following steps
1) The client library assumes that the user is managing the key encryption key (KEK) locally. The user does not need to know the specific key that was used for encryption. Instead, a key resolver, which resolves different key identifiers to keys, can be set up and used.
2) The client library downloads the encrypted data along with any encryption material that is stored on the service
3) The wrapped content encryption key (CEK) is then unwrapped (decrypted) using the key encryption key (KEK). Here again, the client library does not have access to KEK. It simply invokes the custom provider's unwrapping algorithm
4) The content encryption key (CEK) is then used to decrypt the encrypted user data.
For more details and step by step procedure refer this document
It would be great to know
what are they,
what are they used for
why would one prefer one versus the other.
A very simple answer:
Key
A Cryptographic key represented as JWK (JSON Web Key)
Example: store A .pfx certificate file that contains a pair of public & private keys
Secret
KV accepts any value and stores it as a binary (there is a max size limitation)
Example: A password or API key
Further Reading
About Keys and Secrets
Key Vault Keys:
Keys in Azure Key Vault are 'Cryptographic keys' used to encrypt information without releasing the private key to the consumer(users\Service). It acts like a black box to encrypt and decrypt content using the RSA algotithm.
The RSA algorithm, involves a public key and private key. The public key can be known to everyone; it is used to encrypt messages. Messages encrypted using the public key can only be decrypted with the private key.
Scenario:
Assume you have to store the customer CreditCard, the secure way to keep it in your DB is to store it encrypted, during the software design and
business requirements it is perfect clear that you should encrypt it,
what most people don't realize or don't bother is how you protect your
encryption keys, most of the time, stored as part of your software
configuration, if the attacker or employee has access to the key, the
information is not secure anymore.
Using key vault keys, you could send the CreditCard information to KeyVault and it will encrypt the information and return to the caller the enccrypted value.
On high performance scenarios, you could get the public key from KeyVault, use it for encrypting the information from Application side and store in DB already encrypted without sending the data to KV.
The only way to get the real data back would be sending the encrypted data to KV where it will return the decrypted CreditCard.
Key Vault Secrets
Secrets in Azure Key Vault are octet sequences with a maximum size of 25kb each. It is described as octet because it does not care about the data type being stored, the only limitation is the size of 25kb. Once you send the data, it is encrypted and stored, you can retrieve it at any time if you have the permissions to do so. It is used to store information like application settings, tokens and if you will database connection strings, passwords and so on.
The good side of Key Vault Secrets is that you can use pre-defined rotation values defining the Expiration/NotBefore values. So you could register temporary values that will be rotated at specified periods, while the reader has access to the Key Vault with Get permission, they will be able to read the current ones only, while the future ones are already defined and not visible to the Get operation.
The Azure Key Vault (KV) can store 3 types of items: (1) secrets, (2) keys, & (3) certificates (certs).
Secrets - provides secure storage of secrets, such as DB connection strings, account keys, or passwords for PFX (private key files). An auth app can retrieve a secret for use in its operation. More on AZ KV Secrets
(Cryptographic) Keys - keys represented as JWK (JSON Web Key). Supports multiple key types and algorithms, and enables the use of Hardware Security Modules (HSM) for high value keys. More on AZ KV Keys
Cert - is a managed X.509 certificate, which are built on top of keys and secrets and add an automated renewal feature/auto-rollover. More on AZ KV Certificate
We would like to make use of Azure Key vault for storing our sensitive key in azure key vault and make use of stored sensitive key for encrypting our string/plain text data before sending to service. Again Service will interact with Azure Key vault, retrieve sensitive key for decrypting encrypted string send by client. can any one throw some light on how to make use of azure key vault for above scenario.
Azure Key vault has built-in encryption method for encrypt the data, does it mean client has to sent data to azure key vault for encryption. Is it correct. If yes, is there roll over for every 30 minutes changes in Key used for encryption.
sorry for asking very noob question
Regarding roll over, at this time Key Vault does not do auto-rollover of keys. The key vault owner must explicitly roll keys. You do this via the Add-AzureKeyVaultKey cmdlet or REST API, passing in the same key name as earlier. A new version is added to the key.
(More in-depth on how Azure Key vault works here:
http://tomkerkhove.ghost.io/2015/07/22/securing-sensitive-data-with-azure-key-vault/)
I want to increase my safety of my web app in case of an attack.
The following components are present in my system:
Azure Web App
Azure Blob Storage
Azure SQL Azure
Azure KeyVault
Now there is the scenario that the app encrypts and stores uploaded documents.
This works as described:
1) User Uploads doc to the web app
2) random encryption key is generated
3) random encryption key is stored to the azure key vault
4) sql azure stores the blob url and the key url
Now my question is:
How is using the key vault safer in case of hacking the web app instance? I mean there is the client id and client secret in the app.config to access the keyvault, we need it to read and write keys. So if i use key vault or not does not increase safety in terms of hacking the web app, right?
The Key Vault is an API wrapped around an HSM. What makes the Key Vault or HSM Secure is that the keys can not be extracted from them once imported / created. Also, the crypto (encrypt / decrypt in your case) operations happen inside the vault so the keys are never exposed, even in memory.
If someone was able to hack your web application and get the credentials to your key vault they could use the vault to decrypt the data. So, in this case you could regenerate the credentials for the Key Vault and still continue to use the same keys that are in the vault - because they were never exposed. Meaning any data that is encrypted that the attacker didn't already decrypt is still safe because the keys were never exposed.
Typically HSMs aren't designed to store a large number of keys in only a few really important keys. You might want to consider using a key wrapping solution where you have one key in the vault.
You probably want to encrypt the client id and client secret in your config and decrypt them at runtime - this adds another layer of security. Now the attacker either needs to read the keys out of your application memory while it is running on your Cloud Service / VM (not an easy task). Or the attacker would need to obtain the config file and the private key of the certificate used to encrypt your config values (easier than reading memory, but still requires a lot of access to your system).
So if i use key vault or not does not increase safety in terms of
hacking the web app, right?
It all depends at what level they were able to hack the site. In the case you describe, if they obtained your source code then - yes, its game over. But it doesn't have to be that way. It truly comes down to your configuration.
However, most of the time, developers forget that security is a layered approach. When you're talking about encryption of data and related subjects, they are generally a last line of defense. So if a malicious actors has acquired access to the encrypted sensitive data they have breached other vulnerable areas.
The problem is not Key Vaults but your solution of using client secret. Client secret is a constant string which is not considered safe. You can use certificate and thumbprint as a "client secret". Your application needs to read the .pfx file which is stored in web app, then decrypt to grab thumbprint. Once thumbprint is retrieved successfully then you Key Vault secret is retrievable. Moreover, in Key Vault you are given the ability to use your own certificate rather than just a masked string in Secret. This is so-called "nested encryption".
The hacker if getting access to your app.config, he get nothing than the path of .pfx file which he does not know where to store, even how it looks like. Generating the same pfx file becomes impossible. If he could he would break the entirely crypto world.