[feature request]: Add secure key storage and retrieval.

[maythamfahmi]

Contact Details

No response

Is your feature request related to a problem? Please describe.

Add secure key storage and retrieval.

Describe the solution you'd like

Add secure key storage and retrieval.

Describe alternatives you've considered

No response

Additional context

No response

Priority Level

Medium

Code of Conduct

• I agree to follow this project's Code of Conduct

[maythamfahmi]

@jwdonahue any suggestion how to approch this? as you have suggested this feature.

[jwdonahue]

If there isn't an existing portable, secure key storage scheme, then we should design one. More research required. I think I stopped looking when the one thing I originally thought might work, turned out to be a Windows only kind of thing.

Requirements:

1. Dotnet 8+ (portable), preferably C#, but C++ with a C# native library wrapper would be acceptable..
2. Salted + Encrypted at rest.
3. Secure RAM/Flash, where available, when not at rest.
4. Optional USB key support.

I am not a trained security expert, so we should try to enlist one of those, if possible. I am fairly good at doing research, and this is an area I am interested in, but I am sure I can find as many ways to screw it up as get it right. There's probably lots of patent pitfalls in this area as well.

---

5. Some kind of cloud support (Azure/AWS) is probably a good idea, but it should absolutely allow for local, non-cloud/subscription support.

[jwdonahue]

It's been years since I did a deep dive, but my recollection is that there are different levels of hardware support, for key storage and encryption schemes, across all the dotnet platforms. We should survey what is out there now, and if we can't find support for all five of those requirements, we should see if it would not be possible to come up with a reasonable interface/abstraction, and then start implementing for each target (if that's what is required).

[jwdonahue]

To be clear, either we do it the right way, or remove all private key storage and retrieval bits from the code base. We should NOT promote any kind of insecure private key storage or exchange mechanisms. The library may be useful enough by simply encapsulating some of the common encryption mechanisms.

[maythamfahmi]

The question is like any other secret management, is it the libaray responsiblit to take care of secret? in real world I would not save secret as plan text, I would consider saving it in key vault. With that said, if you have idea come with it and we see how we could approch it. I was thinkin we are already having an AES encryption, we could use the libaray our encryption to encrypt own key. but buttom line some one need to remember the secret of encrypiton and decryption.

[maythamfahmi]

@jwdonahue all issues is done expect this one, I was thinking we should make aware of that safing key need to be done in a secure storage like Key Vault or similar technology, Another way, I was thinking of using our AES encryption to encrypt the keys in storage, but that requires the user to have a unique secret to encrypt and decrypt the keys? what do you think?

If we do not find a solutio, we could evently postpone it to 3.0.1 release.

[jwdonahue]

I have not had time to follow up on this.

[maythamfahmi]

no worries, I am finding a posible solution :)