AES encryption key stored in X509Certificate?

Question

There is a service that stores user data on a remote file share. The user data needs to be encrypted so the remote file store such that anyone accessing it directly cannot access it. The front-end machines that do the storage and retrieval do need the private key to encrypt and decrypt.

Does it make sense to use a self-signed X509Certificate, stored in the cert store on each front-machine, to hold the private key?

I thought this made sense but, looking at the APIs for AesCryptoServiceProvider, I don't see an easy way to load the X509Certificate2 private-key into the AES as the private key.

Answer 1

I thought this made sense but, looking at the APIs for AesCryptoServiceProvider, I don't see an easy way to load the X509Certificate2 private-key into the AES as the private key.

X509Certificate2 represents asymetric cryptography. AES represents symetric cryptography.

When encrypting large data asymetric cryptography is not a good option (performance reasons). However use of asymetric cryptography (i.e. certificates) is good for authenticating users and authorizing operations like encrypt and decrypt for this user. Designing encryption and decryption of user data can be done in multiplne ways.

• Each user could have his own AES key that would be encrypted with user's certificate. Before encryption or decryption of user data first there must be done the decryption of users AES key. AES key in encrypted form will be kept at backend. There has to be mechanisms developed to reencrypt the key when old certificate is going to expire. You should consider the option that user's certificate could be revoked and then it is up to you if you allow or don't allow decrypting of user's AES key.
• Have a master AES key on backend that is used for all user data encryption and decryption. This master AES key should be kept in a very safe place because if exploited data of all users are exploited as well (well that depends if data storage has been breached or not).

Answer 2

Does it make sense to use a self-signed X509Certificate, stored in the cert store on each front-machine, to hold the private key?

Not really. Don't use an X509 certificate; rather use PKCS #12.

An X509 certificate binds an entity (user, org, etc) to a public key. Its the wrong tool for the job. PKCS #12 is Personal Information Exchange Syntax Standard. It defines a file format used to store private keys with public key certificates, protected with a password.

So the user gets the PKCS #12 file to decrypt his/her data. The front-end server gets the X509 certificate from the PFX file to encrypt the user's data.

---

I don't see an easy way to load the X509Certificate2 private-key into the AES as the private key

That's a different problem. But its kind of out of scope since the AES key won't be stored in the X509 certificate. You'll make other gyrations for it later.