I'm receiving a secret encrypted with Key A, and need to send it somewhere else encrypted under Key B.
Both keys can be symmetric or asymmetric - but I'd like to achieve this within the vault itself (first prize) - (avoiding a decrypt, having the secret in the clear, then an encrypt).
Is this possible with Azure Key Vault? If not, any workarounds?
Thanks.
As far as I am aware, at this point in time, it is not possible with the current Key Vault API's. The way I think of Key Vault at this point in time is it's just a tailored service for storing and gaining access to Keys, Secrets, Certificates and managing applications and users that can access them (with some fancy bits on top).
You will need to decrypt and re-encrypt somewhere outside of Key Vault.
One possible workaround though given you are in Azure is to create an Azure Function to do this work. At least then the process of the translation happens inside an isolated Function context (in Azure). The beauty of using an Azure Function is that you could do this with minimal code and without a full application, but you would need to ensure that Function can only be utilised by you.
A possible workflow could be:
1) If Key A is not in Key Vault, upload it.
2) If Key B is not in Key Vault, upload it.
3) Run Azure Function with inputs for Key Vault identifiers for Key A, Key B and A(Secret). Do the conversion and then the Function could store B(Secret) in Key Vault (or another Key Vault if you have access to one).
Alternatively it could just output the new encrypted secret.
C# Key Vault Client:
https://learn.microsoft.com/en-us/azure/key-vault/key-vault-use-from-web-application
An example of Azure Function and Key Vault in C# for reference: http://www.rahulpnath.com/blog/azure-key-vault-from-azure-functions/
Related
Looking for guidance on what items to store in a simple configuration file versus an Azure Key Vault?
For example, an SQL Database name should be stored in a configuration file while its password should be stored in a KeyVault. Is this correct?
Should there be a key vault for each environment (I think not) or simply one for production and one for non-production?
Yes, you can just store the password of SQL Database in azure key vault and store the database name in configuration file, or we can store the whole connection string of the database in azure key vault.
For your second question about should there be a key vault for each environment, I think it's unnecessary for us to create multiple key vault for each environment, you can just separate them with several different names in one key vault.
Anything that should be protected (passwords, certs, API keys, etc..) should be in a Key Vault and have strict access policies assigned to it.
Agree with Hury on the first half; however, disagree on the one key vault for all environments. Different access policies will be applied for different environments.
Your developers may want access to the Key Vault for the dev credentials. As such they'd have an access policy to the dev Key Vault. I would not want to grant them access to a production Key Vault, which would give them access to all the keys in it.
Key Vault is a globally available resource. So if you have multiple instances in different regions connecting that is fine as you wouldn't need to have a separate Key Vault in a different region from a disaster recovery and availability standpoint.
Here is a similar quesiton and also link to Microsoft best practices which supports this
I have to configure RSA HSM Public and private key in the azure key vault and save the data in encrypted form.
For added assurance, when you use Azure Key Vault, you can import or generate keys in hardware security modules (HSMs) that never leave the HSM boundary. This scenario is often referred to as bring your own key, or BYOK. The HSMs are FIPS 140-2 Level 2 validated. Azure Key Vault uses nCipher nShield family of HSMs to protect your keys.
More information about generating and transferring an HSM-protected key over the Internet:
You generate the key from an offline workstation, which reduces the attack surface.
The key is encrypted with a Key Exchange Key (KEK), which stays encrypted until it is transferred to the Azure Key Vault HSMs. Only the encrypted version of your key leaves the original workstation.
The toolset sets properties on your tenant key that binds your key to the Azure Key Vault security world. So after the Azure Key Vault HSMs receive and decrypt your key, only these HSMs can use it. Your key cannot be exported. This binding is enforced by the nCipher HSMs.
The Key Exchange Key (KEK) that is used to encrypt your key is generated inside the Azure Key Vault HSMs and is not exportable. The HSMs enforce that there can be no clear version of the KEK outside the HSMs. In addition, the toolset includes attestation from nCipher that the KEK is not exportable and was generated inside a genuine HSM that was manufactured by nCipher.
The toolset includes attestation from nCipher that the Azure Key Vault security world was also generated on a genuine HSM manufactured by nCipher. This attestation proves to you that Microsoft is using genuine hardware.
Microsoft uses separate KEKs and separate Security Worlds in each geographical region. This separation ensures that your key can be used only in data centers in the region in which you encrypted it. For example, a key from a European customer cannot be used in data centers in North American or Asia.
For implementing bring your own key (BYOK) , please visit here
Hope it helps.
My current customer has secrets stored in Blob Storage and we want to propose them to migrate to KeyVault. May I know what are the benefits or storing secrets into KeyVault as compared to Blob?
When I read the documentation, KeyVault uses the HSM to protect the keys and secrets but Blob also uses the encryption which is also secure. so what are the other advantages?
I'd say that in general they look very similar, however I'd say the most important difference between the two would be the authorization model.
Access to a storage account is done by one of the two available connectionstrings/keys. Access to a KeyVault can be assigned directly to users or groups (from AAD) and the access to resources within the Key vault can be configured with more granularity. Next to that it is very easy to limit the type of resources from within azure that may or may not retrieve data from a KeyVault, reducing the attack service.
Storage accounts do have AAD integration currently in preview, but what i gather is that that is mostly focusing on the Azure file share functionality (https://learn.microsoft.com/en-us/azure/storage/files/storage-files-active-directory-overview).
Another nice differentiation is definitely the integrations that are already available when using KeyVault (i.e. Retrieving Azure DevOps secrets directly from a KeyVault or automatically retrieving Certificates for VMs)
FYI, i'm by no means a KeyVault expert but that's just my 2 cents :)
I am currently developing a iOS app using Swift 4.1.
As my app involves the Twitter REST API, I need to provide the consumer key and consumer secret in one of my classes. (i.e developer's consumer key and secret, users DO NOT need to generate their own key)
Would like to know if it is safe to store the consumer key and consumer secret in the code or do I need to store them somewhere else?
Generally speaking, if it's valuable enough, any secret will eventually be compromised. The trick is to make it harder to steal than the benefit that would result from stealing it.
Specifying your API key as a string constant is a pretty bad idea. A hacker with access to the binary or intermediate bitcode could extract strings from the binary and look for high entropy constants which are likely candidates to be API key values.
Be careful, it is also very easy to store your secret in your git repository and accidentally publish it for the world to see.
As an improvement, consider obfuscating the API key in your code and computing the actual key value at runtime. For example, use a simple exclusive-or mask:
MaskedApiKey = OriginalApiKey XOR Mask
OriginalApiKey = MaskedApiKey XOR Mask
Store the MaskedApiKey and Mask in your code, and combine them at runtime to restore the OriginalApiKey. Now an attacker needs to grab two constants from your code to steal the API key. You can extend this technique to make it arbitrarily obfuscated at runtime. The logical extension of this is white box encryption
A secret is even harder to steal if it is never stored in your code in the first place. So, an alternative technique is to store the API key in an external secrets service off your app. By registering your app with the secrets service, the service can attest that the app is authentic and untampered and provide your app the API key at run time. See Mobile API Security toward the end of the article for an example.
Of course, none of this matters if your API call is made in the clear and is easily observed by a Man in the Middle (MitM) attack. Always make your API calls using TLS
(HTTPS) strengthened by certificate pinning.
Take a look at this OWASP talk for a quick overview of mobile API security.
I read that in Hyperledger v1, encryption and channels can be used to enforce privacy.
I want to try the encryption approach to accomplish this. Since all registered users have private/public keys, I plan to use the public keys of users to encrypt some data (later I plan to combine this with symmetric cryptography to make it more efficient).
In addition, I plan to use the private key of the invoker of a function to perform decryption.
How do I get the public/private keys inside the chaincode? In addition, I also plan to perform encryption/decryption in NodeJS (outside the chaincode) since I'm using the NodeJS SDK for Hyperledger v1. How do I get the public/private keys through NodeJS?
While using NodeSDK you simply load keys from theirs location on disk and to obtain signer (client) certificate you can use API from ChaincodeStubInterface interface which provided you while chaincode is invoked:
// GetCreator returns `SignatureHeader.Creator` (e.g. an identity)
// of the `SignedProposal`. This is the identity of the agent (or user)
// submitting the transaction.
GetCreator() ([]byte, error)
First of all, I think that you should know how are those keys created. There are different ways for it, but Hyperledger Fabric gives you two tools to create these keys:
Cryptogen: this tool is used to generate the cryptographic material (x509 certs) for your network entities. These certificates are representative of identities, and they allow for sign/verify authentication to take place as our entities communicate and transact.
Fabric CA: a component of the Fabric, i.e. the CA that will issue certificates for each member.
Then, once you have the keys, you should manage them. The Fabric project makes it easier thanks to the MSP. When you create a channel, you define the public keys of the peers and the keys of the issuers of those certificates. Then, Fabric manages them to verify the transactions.
The Membership service provider (MSP) offers us the possibility of abstracting from all the cryptographic mechanisms and protocols of validation, authentication verification and signature.