azure-service-bus-dotnet-plugins
azure-service-bus-dotnet-plugins copied to clipboard
Azure
Key Vault plugin
Security aspect of the KeyVault plugin requires an additional review and most likely will be pulled out into a separate repo.
Additional benefits to that would be independent versioning and release cycle that doesn't have to tie KeyVault plugin with Message ID plugin.
Curious - Why did this get removed?
This won't be an easy one to build with the current Key Vault limitations to be honest. Keys sounds like the way to go but they only allow you to do 2k/10s, if you are using software keys. This is not a lot for a messaging infrastructure. The problem is that Key Vault does the encryption/decryption, which is a good thing, but that also means that you can't use any caching. The alternative I see is to use a IV, salt & key stored as secrets and cache them in-memory for a certain amount of time.
I can jump in on this one if you need help.
I'll slightly re-phrase what @tomkerkhove has asked. Will the new repo be opened source and be available on GitHub prior to code completion? Thank you.
That would be great indeed, can contribute to it in case you're interested
@tomkerkhove , thanks for the offer. Public contribution is always well appreciated. We will get back on this thread soon regarding the approach for key-vault plugin that we plan to take.
This is the final proposal we have reached to:
1. Get master key from customer*
2. Generate two keys (EncKey and HMACKey) from MasterKey PBKDF2 algorithm. **
3. Generate a new IV() unique to the message.
a. var aes = Aes.Create() // This generates a new Key and IV internally.
b. aes.Key = EncKey; // Override the key with our encryptionKey
c. var iv = aes.IV;
4. Use this aes to encrypt the message body.
5. Generate HMAC for this encrypted data along with IV.
a. var hmac = new HMACSHA256(HMACKey);
b. var hmacInput = concat(IV, encryptedString)
c. var hash = hmac.ComputeHash(hmacInput)
6. Update the message.
a. Message.Header.Put("encryptionType", "AES-HMACSHA256-1000Iterations-ConstantString1-ConstantString2");
b. Message.Header.Put("IV", iv);
c. Message.Header.Put("HMAC", hash);
d. Message.Body = encryptedString;
7. Send the message.
While receiving
8. Receive the message.
9. Generate EncKey and HMACKey
10. Generate HMAC for this encrypted data like above, and verify this is same as Message.Header.Get("HMAC")
11. If same, use Aes to decrypt the Message.Body
[1]* 1. Optionally provide helper methods to generate master key from passphrase using PBKDF2 2. Have static helper methods on plugin to generate a strong key a. Aes.Create().Key 3. Have it flexible enough to input master key either from key vault or as a normal argument (without going through KeyVault at all)
[2]**
Byte[] EncKey = new Rfc2898DeriveBytes(MasterKey, "ConstantString1", numIterations: 1000, hashAlgorithmName = HashAlgorithmName.SHA256).GetBytes(16);
Byte[] HMACKey = new Rfc2898DeriveBytes(MasterKey, "ConstantString2", numIterations: 1000, hashAlgorithmName = HashAlgorithmName.SHA256).GetBytes(16);
Notes: • EncKey and HMACKey will be generated once while initializing the encryption plugin and will be reused for every message. • A new IV will be generated for every message.
@tomkerkhove We have this task in our plan. But it would take at least a couple of weeks before we can get to it. Meanwhile, if you are interested in working on it, it would be highly appreciated.
@nemakam I would recommend to provide a mechanism where the Key Vault artifact version is included somewhere in the headers so that the consumer can use the same version for decryption, otherwise this can run into issues.
I'll wait until your is there since it would be a pity to write 2 components. I presume it will be part of this repo or not?
@tomkerkhove Absolutely. We need lot more info that needs to be sent in encryptionType header. That was a very rough format that I just typed there. It was just an indication of what the plan is and not the exact set of parameters/serialization format to pass around.
We want things to be very modular. So everything from algorithm / key input / understanding message header - should be switchable. That would aptly include having version details.
The main idea of that message was to indicate the default encryption strategy/pseudo code we want to go ahead with which is compliant with security standards.
I presume it will be part of this repo or not?
Yes. this will be part of this repo under src/Microsoft.Azure.ServiceBus.ClientEncryptionPlugin
Hey guys,
I did attempt to build a plugin that does covers,
- encryption and decryption using Rijndael Managed Algorithm.
- message payload integrity checks using MD5 checksum.
Here's the link to the repository: https://github.com/iamvighnesh/azure-servicesbus-message-encryption-plugin
I am planning on integrating Azure KeyVault and Managed Service Identity (MSI) in the coming weeks. I will share more details on that earliest I can.
@nemakam @tomkerkhove is this something that might help you?
