0

I have some symmetrical encryption keys (DEK) stored in the database alongside with the encrypted data. DEK's are encrypted by the public key of the HSM. The application server uses HSM with PKCS11 interface. The key and data decryption is done inside the HSM. Plain text keys never leaves the HSM memory.

Yet I'm concerned about the security. If an attacker manages to break in to the application server, he could just retrieve the encrypted data from the database and query the HSM.

I would like to have "external" component involved in decryption, linked to the user authentication. So even the attacker manages to hijack the server and the database and gets access on the HSM interface, the key material present is not sufficient. The encryption protocol should contain component which only authorized user knows or haves, but this knowledge is not stored anywhere and is not derivable. There is also a challenge: the key is actually related to the group of the user, not the identity. This means different users of same group must have access to the same key.

Tuomas Toivonen
  • 371
  • 1
  • 2
  • 10
  • You've described MFA (multi-factor authentication) and 4-Eyes (quorum) protecting the use of the HSM. Gaining access to the database via a hack of the app server doesn't do any good unless they also have access to the HSM, as you noted, but implementing a Quorum on access of the key-material needed to decrypt the data, and requiring MFA for the quorum members, means that you are protected from anything but an insider-threat + conspiracy. And no security policy in the world will protect you from that... – rip... Oct 20 '18 at 20:51

1 Answers1

0

Well, if you plan on having this per-user, I see no other way then to store a separate DEK for each user. You can then use a variety of ways to encrypt this DEK.

One idea would be to use the password to derive the key for decrypting the DEK. Of course this has to be derived in a different way than the hash of the password stored in the DB, for example by prepending "key-" in front of the password.

Another option is to user something like SCRAM-256 and then use for example Client-Key to encrypt the DEK (client key is not stored on the server in SCRAM).

Another option of course would be just keeping an additional key stored on the user computer, but this has the disadvantage of the user having to protect and backup this file.

Community
  • 1
Peter Harmann
  • 7,728
  • 5
  • 20
  • 28