Maintain sensitive key between requests

Question

EDIT: Reworked question. Previous version too poorly asked.

On my website users write sensitive messages that must be kept secret. The entire user area is over SSL, so the communication between user and server should be fairly secure. Now I want to store the messages in a secure way, so that an attacker who gets access to the database can't read messages.

With the help of Security.SE, I'm currently implementing this encryption scheme Implementation review - Independent key, admin side and user side .

As you can see, userkey (uk) is something sensitive and it is generated at login time with PBKDF2 (with password and user salt). I can't require the user to input the password every time he wants to read a message, so I want to mantain the uk between requests. What's the best way to prevent that an attacker obtains uk?

I think I can generate uk at login time (when the user inputs the pass), encrypt it and store it.

I know that php sessions aren't so secure, apc_cache_info() could be very damaging, cookies can be stolen. So, IV in a cookie, key in APC cache, cipher in the session: attackers have to get the cookies, disk access, RAM access to decrypt the uk. Am I wrong?

What if I:

• Generate a random key r
• Generate a random initialization vector IV
• Crypt the data (a PBKDF2 key, 100 rounds) with AES 128 CBC and with r as key and IV as IV
• Store the cyphertext in the standard session data
• Store the key in APC cache
• Store the IV in a cookie
• Fetch IV, r, and cipher when I need it, decrypt data and use it

I'd want to know if uk is now stored more securely. Could you suggest better way to do it?

Thanks a lot

Answer 1

The short answer to your stated question is that not knowing the IV makes AES, or really any block cipher in a proper operation mode, that much more impossible to brute-force, by basically making the IV an extension of the key. For AES-256, the 256-bit key plus a 128-bit IV basically requires your attacker to correctly guess a sequence of 384 bits, requiring a worst-case 2^384 attempts. Putting that in perspective, a computer running at the electron level at 100% thermal efficiency, given every photon our Sun will produce in its remaining lifetime, would only be able to try about 2^218 keys before the Sun goes black dwarf.

However, the IV is needed by both sides in order to encrypt/decrypt in any mode that uses one, and so, like other specifics about the encryption scheme except the actual key that would be shared between parties during negotiation (such as algorithm, mode, block size, key size) the IV is considered public information. It's possible to hide it, in the same ways that the key can be securely exchanged (offline, public-key crypto), but it isn't necessary.

With that question answered, I must say that there's a lot of information you haven't provided, that makes it impossible to answer the broader question of "is this scheme secure". For instance, how is the user's password related to the key (are you using a KDF or other "key-stretching" scheme?) What mode of operation are you using for the AES encryption (some modes are more secure than others, and some are effectively broken). EDIT: CBC mode isn't a terrible choice (there are worse) but care must be taken to ensure that your code cannot be used as a "padding oracle"; a "black box" that will tell an attacker whether a particular ciphertext message, when decrypted, is properly padded. That can be used to reverse-engineer the plaintext message from the known ciphertext without knowing the key. Since this is solely a server-side process and so no client code is available to use to decrypt, an attacker would need to penetrate pretty far in to be able to turn your server code into a padding oracle, but never assume; if you have a good implementation available to you, I would choose an authenticated mode, such as GCM or CCM, which will resist padding-oracle attacks.

I will also say that this scheme appears to be server-side only; if the key and IV are stored on the server only, then all encryption and decryption must happen there, which would mean that unless you're using something else such as SSL to send data to the client, the security of this particular piece is pretty moot.

Answer 2

Yes, the IV sets up the initial state of the stream that is used to generate the cyphertext. Without the IV, you would get a different stream and the decryption would fail. Depending on the mode of operation, how badly it would fail could differ. I am not sure however why you ask about cracking it without the IV. It sounds like you are talking about decryption. While the IV is needed, it is not a secret. It is fine for the IV to be known, it just prevents attacks by comparing similar messages encrypted with the same key. The key is all that needs to remain secret.

If the key is compromised, there are attacks that greatly weaken the encryption in most modes of operation. While the IV being secret slightly increases security, having it revealed is not catastrophic for the security of the encryption. Secrecy of the key however is paramount as secrecy of the IV will likely not protect a message if the key is known.

Answer 3

Most of the concern about session hijacking and such is valid, but doesn't immediately compromise data on the server. My recommendation would be to encrypt the user key after it is initially obtained with another one time session key, split the key in to three pieces (or encrypting it with 3 different session keys) and then put a piece of the IV (or the appropriate IV) and a piece of the key (or 1 of the 3 keys) in each of the 3 places as the token. Then, when all three pieces of information are provided, the actual key can be decrypted, but any compromised pieces would have no benefit outside of the session and the real decryption key would only be available to the server after the 3 pieces of the session key are provided as an alternative to the password.

Using 3 separate session keys will provide more security, but also requires more processing power. A simple split will still provide some additional protection depending on the mode of operation of the cipher though and is cheaper to do.

The main thing is that you never want to disclose the actual decryption key or any information about the data decryption key to the attacker (or client) and you don't want it in the DB (at rest) unprotected. That means you need to store the data key in a way that it is protected by the information that only the client knows and splitting the information across three pieces to compromise increases the difficulty slightly.