Recently I created the Enclave.NET project, and it shipped with a simple in-memory storage service. It’s not particularly useful in it’s current form, so I created a sample a couple weeks ago that used Azure Key Vault as the storage and crypto service.

But Why?

Of course, you might be wondering why you’d want to use Enclave.NET this way, since Key Vault already provides isolation given that it’s hosted far away from your service. The obvious answer is that maybe you wouldn’t use it this way — it IS isolated enough. That said, this does provide you with some extra separation because your app now doesn’t have access to the secrets to connect to Key Vault — we’re working on the premise that every little bit helps.

And because it’s my project and my site and it seemed like a neat little idea. 😃

So how exactly does this work?

If you remember previously the service is supposed to be hosted locally, but outside of your own application, and relies on an HTTPS channel to offload data protection. That means we have a service host. In this case it’s just a console application. You’d likely want this running in a Windows service or Linux daemon in production so it’s not constantly having to spin up.

 

The service host looks for the settings.json file and spins up a web host given the provided server and client certificates.

 

You’ll also notice there’s a transform type that lets you setup your own services. This just injects the Key Vault storage and processing services.

 

You can find the KeyVaultStorageService and the KeyVaultCryptoProcessor in the sample project.

Once those are set, you can call the service from the client, and at this point the client has no idea where the keys are, or how they’re being used.

 

The neat thing about this is that it provides a great abstraction between the internal workings of the crypto bits, and the code that needs to protect data.