Encryption using static AES256 symmetric key vs ephemeral session key

Question

For a hackathon I am designing an information exchange system for healthcare. Healthcare data is stored on unsecured systems. I want to assure confidentiality, integrity and authenticity of this data nonetheless. To allow multiple people to access the same data, I want to use a system like openPGP (without the email/HTML vulnerabilities), where I use an AES256 symmetric key (CBC, PCKS5 padding?) that is encrypted with RSA-2048 encryption using the public key of each authorized user.

The encrypted versions of the symmetric key will be stored with the data. New files will be added to the data over time, so I don't want to create a symmetric key per file, since revoking or granting access to a new user would mean we need to re-encrypt the symmetric keys of all files every time we do this.

To guarantee integrity and authenticity of the files, I want to sign them using the private key of one of the authorized uses using SHA256-RSA. Public keys will be stored on a PKI, but public key validity will be verified in a face-to-face contact.

My question is two-fold.

1. What is the risk of using a static symmetric key for encryption vs a session key that changes each time? Is it purely the forward secrecy that ensures that if one session key gets compromised the other data remains safe? Or are there also other risks with not changing the symmetric key?

2. How good/bad is this setup in general? Any other problems I am overlooking in this setup? Other algorithms I should use?

Answer 1

What is the risk of using a static symmetric key for encryption vs a session key that changes each time?

1. Flexible access control: A big reason to use session keys is that it is easier to adjust your access control. It seems to me that the access for the files is not different. As long as that remains the case there is no direct need to use different keys to protect the data. However, with session keys you can make a different access control scheme without having to re-encrypt your data.

2. Access to the keys: remember that key management has a lot to do with the accessibility. It doesn't make much sense to use multiple keys if they are evenly vulnerable to attacks. However, patient information can get relatively large. It might be feasible to protect the master key better than the session keys that are required to decrypt large amounts of data.

3. Limitations of modes of operations and IV's: Modes of operation such as CBC do have limitations. If you would be encrypting large amounts of data then you might get into trouble in case the input of the block cipher repeats, as it would generate the same ciphertext block, and that would leak information to an adversary.

4. Forward secrecy: You already mentioned forward security, where the leakage of a session key doesn't compromise the confidentiality of data encrypted with other session keys.

---

What you could do is to encrypt the session keys with the master key. This may not feel more secure, but it does allow you keep the master key safe, possibly in a more secure system or device.

Another option that you could use is to use a key derivation function or KDF that derives session keys from the master key. That way the limitations of the mode of operation can be diminished. You may also use any kind of information rather than to use a specific IV. A KDF also solves the problem of the forward secrecy as you cannot derive the master or any of the other keys given a session key. This way you don't have to store any session keys; you don't however get the same flexibility as wrapping (encrypting) session keys.

How good/bad is this setup in general? Any other problems I am overlooking in this setup?

That's a very broad question. I would not consider OpenPGP. Not so much because the protocol is bad, but it simply hasn't designed for this kind of operation. Furthermore, it is a rather old protocol which hasn't been updated to support the latest / greatest algorithms. More importantly, I don't thing the PGP method of distributing keys does justice to a rather hierarchical setup used mainly at hospitals. X.509 may make a lot more sense.

RSA 2048 is not considered all that secure anymore, giving a security strength of about 112 bits. See keylength.com to see some comparable key strengths. Using it together with AES-256 gives you and your users a false sense of security. You may have to go for Elliptic Curve crypto and preferably an asymmetric Post Quantum Crypto algorithm to provide 256 bits of security. This may require long term security, after all.

With regards to algorithms, I think you should learn about new modes of operation such as AEAD modes of operation. Using AES-CBC is fraught with dangers; I would not consider CBC mode best of breed anymore.

Answer 2

Proxy Re-encryption (PRE) lets you have a separate session key per file, without needing to re-encrypt that key every time you want to grant or revoke a user's access. You avoid having a system-wide key, so that you can grant different access to individual files and don't require the same access across the system.

We have a paper about how we do this here.