In depth security: splitting key in different places

Question

I use AES encryption on a website. At the moment, the key is stored in the source of the PHP script that does the encryption/decryption process thanks to openssl. I know that it isn't secure, so I want to put parts of the key in different places:

• first part in PHP source
• second part as server environment variable
• third part as htaccess env var
• other places in case I remind them

I know that this proceeding doesn't add, at the end, to security, but it makes the cracking a little more difficult (considering that I can't use hardware devices), because the blackhat needs to get all the parts, not only the source of a script.

The question is about the safest way to do it.

• splitting password in 3 parts, putting them in the different places mentioned and join the pieces when I need the complete key
• combining them in other ways, like:

What do you think about it? Thanks a lot for your useful help

Answer 1

Essentially what you're attempting to do is backdoor each user's account in a way that allows only the user and a single administrative user to access their data. This can be achieved as follows:

us  = User salt  = Random unique value (not the same salt as used for authentication)
as  = Admin salt = Random unique value (not the same salt as used for authentication)

uk  = User key    = pbkdf2(user_pass, salt1, 256, rounds)
dk  = Data key    = random 256-bit key
ak  = Admin key   = pbkdf2(admin_pass, salt2, 256, rounds)
P   = RSA private key
p   = RSA public key

uk' = Encrypted user key    = dk ^ uk
dk' = Encrypted data key    = RSA_Encrypt(dk, p)
P'  = Encrypted private key = AES_Encrypt(P, ak)

m = message
iv = initialisation vector (random unique value)
c = ciphertext = AES_Encrypt(m, iv, dk)

We then store uk', dk' and iv with the data record we're encrypting. We store us with the user account record. We also store P' and as with our admin account record. The public key P can be stored in the code.

The user decryption works as follows:

1. Compute uk from the user password and us.
2. Xor uk' with uk to retrieve dk.
3. Decrypt c using iv and dk, giving us m.

The admin decryption works as follows:

1. Compute ak from the admin password and as.
2. Decrypt P using AES_Decrypt(P', ak)
3. Decrypt dk using RSA_Decrypt(dk', P)
4. Decrypt c using iv and dk, giving us m.

Note that when I say "encrypt" and "decrypt" in reference to RSA, it's not really encryption, but it is more or less semantically equal.

Answer 2

To put what Polynomial is saying another way, if you are trying to make it so that encryption works for user data so that only the user and administrators can get to it, the critical piece is to not store the ability to get the information on the server. For users, this is done via their password, for administrators, it is done through their private key (which can also be tied to a password.)

For each user account, you make a new symmetric key. You store that key encrypted based on the users' password so that only the user can get at that version. You then also store the same key but encrypt it using the public key of the administrator, this ensures that the second copy of the user key can only be accessed by the holder of the administrator private key. If the user's password needs to be administratively changed, the administrator can then decrypt the user key with their private key and re-encrypt it based on the user's new password.

Ultimately, the primary limitation is that the administrative user still has to provide the private key to do anything, so I'm not sure if this fits your use case or not. If you need the system to be able to reset a user's password automatically, then you have to have a way to get at the encryption key to re-encrypt it with the new user password.

While you are correct that it doesn't add much security, I would say that your best bet for defense in depth via multiple storage locations (if you don't have any better option) is to use multiple nested encryptions with different keys. ie, store a full, different symmetric key at every location, and require each key to be used in sequence for the data key decryption and rotate them regularly. I must emphasize that this adds a minimal amount of protection, but it does at least make the best of a bad situation if you must have the ability to automatically access the protected data.