Confidentiality and integrity for web session

Question

When the client authenticates with our service, he is issued an opaque "token". This token includes the information, that identifies the client and some other information about the client ("payload"). The payload is used by the service, when the client passes the token back to the service on subsequent requests. The payload should not be disclosed to the client, so not only integrity must be maintained, but confidentiality too.

Here's what I was going to use for generating this token: - HMAC-SHA256 for integrity - AES in CBC mode for confidentiality

So, given payload P, keys K1 and K2 to generate the "token" I

• pad P to a multiple of 16
• generate IV of length 16
• encrypt P using AES with K1 and IV
• concatenate IV and encrypted P
• get a digest of the result (IV + encrypted P) using HMAC-SHA256 with K2 as a key
• concatenate digest with the result

Since IV and digest are of known length, no separators are needed. The padding will probably be done with spaces, since the format used for payload does not give significance to trailing spaces.

I must say, that I am not very much into security, so I might be missing some very obvious things. Anyway, the questions:

• Doing this seems very much like "rolling my own crypto". Am I reinventing the wheel here?
• Is there any added security in using separate K1 and K2, given that they will be stored "side-by-side"? If not, it will certainly be more convenient for me to use the same key
• ... well, did I miss anything?

Answer 1

Well, you are reinventing the wheel, but at least you are using a circular shape for that, which is better than what most wheel-inventors out there do. And, frankly, there is a bit of a shortage of immediately usable high-quality wheels.

You use CBC with an IV (which must be generated with a strong PRNG), and that's good. You apply HMAC on the encrypted data, and that's good. You do not forget to include the IV in the input to HMAC, which would have been the classic mistake of encrypt-then-MAC. And you are using distinct keys for the encryption and the MAC, which is nice. So, really, not bad at all.

You may want to consider the following points:

• In your format, there is no indication of what algorithms are used, so there is no algorithm agility: if tomorrow you want to switch to another encryption algorithm, you cannot do it without breaking compatibility with existing payloads (unless you play with the total length). For clean algorithm agility, you may want to add a header: a single byte with a conventional value, e.g. always 0x01 (subsequent versions of the payload format would use other values). Important note: if you do that, then do not forget to add the header byte in the HMAC input as well.

• If having two keys K1 and K2 is inconvenient for you, you may want to store a single key K, and derive keys K1 and K2 from K. As long as the derivation process is one-way and uniform, this will be fine. We want the encryption key and the MAC key to be distinct so as to avoid nasty interactions between the two algorithms; no such interactions are known in the case of AES-CBC and HMAC/SHA-256, but "better safe than sorry". In your case, just hash K with SHA-256, use the first half (128 bits) for K1, the second half (128 bits) for K2.

• There are newer authenticated encryption modes which combine encryption and integrity check, and do all the hard work for you. In particular, GCM and EAX are consider secure, and are patent-free. They offer some bonuses: no need for a random IV (a non-repeating IV such as a counter is sufficient), no need for padding (they rely on CTR mode internally), only one key (any "expansion" is handled internally).

• If a user can obtain several payloads, then he can switch them and replay old payloads. Depending on your context, this may or may not be a problem for you.

• If keys are not user-specific, then colluding users could swap payloads. Depending on your context, this may or may not be a problem for you.

Answer 2

The padding will probably be done with spaces, since the format used for payload does not give significance to trailing spaces.

It's likely that you'll be better off using a standard padding scheme then inventing your own. For example, padding to of n bytes by using a n repeating bytes of n, or adding a dummy pad block if it's already of a suitable length.