Using the same AES key for CBC and ECB

Question

Overview

I'm trying to come up with a way for a server and client to be able to generate a unique IV for each request that is both different for every client and yet deterministic. What I mean by deterministic is that the server can calculate the IV for any request in the future knowing only the starting sequence.

The reason I am need this capability is that I'm using the AES encryption to implement a one time password (OTP) scheme. When the client logs into the server it is given a seed. The first OTP is generated by encrypting this seed. For each subsequent request the client encrypts the last OTP using the shared AES key between the server and the client. Hence, even if an attacker sniffed the last OTP without the shared key they would not be able to get the next OTP. The OTP is being encrypted with AES in CBC mode. The problem comes if the server and client get out of sync. The way I was planning on dealing with this was by generating a few OTP's into the future on the server side and seeing if any of them matched the client's. However, without a way to deterministically calculate the IV for each encryption iteration this is not possible.

Before I get into my proposed solution let me express my understanding about AES, IV's, CBC, and ECB. That way if I have any misunderstandings in my fundamentals they can be pointed out and corrected.

Theory

ECB

I know that ECB will produce the same output for identical blocks of plaintext encrypted with the same keys. Hence it shouldn't be used for multiple blocks of data because information about the plaintext can be discerned by statistically analyzing the data. Based on this it would seem that if you could guarantee your data was always less than 16 bytes (128 bits) it would eliminate the problem of the statistical attack. In addition if you could also guarantee that you never encrypted the same plaintext with the same key you would never get the same output. Therefore it seems to me that using ECB is safe assuming your system will always meet these very strict criteria.

CBC and IV

I know that CBC is meant to eliminate both of these problems. By chaining blocks it eliminates the multi block statistical attack of ECB. By never using the same IV for the same AES key you eliminate the problem of having the same plaintext encrypt to the same output with the same key.

Key Uniqueness

If each client gets a generated AES key then while there is a small probability of multiple users having the same key the chances are extremely small. Therefore it is safe to assume that no two clients will be using the same AES key.

The Proposed Solution

My proposed solution is to give each client a unique AES key. When the key is generated a counter will be initialized to a random number. Each time something must be encrypted the counter will increment by one. This number will be padded to a block and then encrypted using AES in ECB mode. The output of this will be my IV for encrypting the data using CBC.

If the server gets out of sync with the client's counter because it has the same key and ECB requires no IV it can keep generating IV's until it finds one that allows the data to be decrypted.

My thoughts are this IV is safe from the statistical attack because it is equal to the block size of AES. In addition it will be different for every user, every time because each user will have a unique key and the counter will always increment. Obviously the AES keys must be transmitted securely (right now the client is encrypting the generated key with the server's public RSA key).

My Questions

Is my fundamental understanding of the technologies described in the proposed solution correct? Is there anything obviously wrong with my proposed solution? Is there any security flaw of using the same key to generate the IV in the proposed manner as well as to encrypt using CBC?

I realize the last question may be difficult/impossible to answer because cryptography is really hard, but any insight would be appreciated.

Thanks in advance.

Paraboloid

You may want to ask this over on the security part of StackExchange. – Chip

Your understanding is correct, as far as I can tell, but in cryptography you never want to reinvent the wheel. How are your client and server negotiating their shared key, exactly? Is there a reason you cannot treat the shared secret as a "password" and use a standard like PBKDF2 to create keying material? – Aa

I was trying to avoid having any type of static password that's why I didn't just use a shared secret. I'm not familiar with PBKDF2. Is Wikipedia good enough to get a good understanding of it or do you have another place to suggest? – Paraboloid

Answer 1

As stated in the comments, I would avoid to invent a protocol at all cost and rather try to implement a standardized protocol. Some OTP protocols require the clients to use a second, out-of-band device for receiving the OTP when logging into a server, a common scenario with banks is that upon your login request to the server application the server will send you an OTP to your cellphone. The OTP generators for client and server are typically time-synchronized or counter-synchronized, if I understood correctly you plan to use the latter solution. I didn't find in your description how you would intend to manage the client's counter, on a separate device?

Anyway, I would recommend to use a standardized procedure that has been "tested in the field" rather than rolling my own scheme. HOTP could be what you are looking for - although it uses a keyed HMAC solution rather than symmetric encryption, but this should make things easier as you don't have to worry about the IV anymore.

In any case you should plan early on how you want to accomplish establishing the symmetric keys with your clients. If you can't handle this over a secure channel (such as handing out keys in person) this will become a problem for the security of the entire system.

Yordan

I don't have an out of band device for distributing the key or I would have used that. I like the sound of HOTP and will look over the link. If that sounds like it will work to me then that is probably what I'll end up going with. As for establishing the keys I'm generating it on the client and then encrypting it with the servers public key before sending it. From my understanding that is a pretty standard way to establish symmetric keys securely. – Paraboloid

@rhololkeolke: In "textbook" crypto terms, yes, but then you are still subject to replay attacks, relay attacks and what not. Why not take something that has proven as reliable and secure for this , such as TSL (former SSL) for the transport? – Yordan

This is all meant to be used for a small nonprofit organization. Their website only has a self signed certificate. I'm going to push for a proper certificate, but I wanted a different way to exchange keys that would augment/replace their self signed certificate. Do you have any suggestions or is the key exchange flawed without a proper cert? – Paraboloid

@rhololkeolke: In theory it's not, you can use https with a self-signed certificate just fine. The problem with these non-commercial certificates is, that they're obviously not included in the built-in trust mechanisms of the browsers. This means any client would first have to add that self-signed certificate to their trust store, which is fine when you're in a closed environment but impractical and considered bad practice for an "unlimited" user group, e.g. on the web. – Yordan

I see. I was trying to prevent a MITM attack. But if I package the self signed cert with the client then a MITM attack won't be possible. I'll just switch over to using TLS with te self signed cert and look into the HOTP. Thanks for all the help. – Paraboloid

Answer 2

well just a thought ... if you want something self synchronizing, you could set AES up in cipher feedback mode ... that way your cipher text will be used as IV ... if both sides get out of sync, one ciphertext block is enough to regain sync (but the one that will bring re-sync won't be decryptable since the previous one is not available)

Assortment

Answer 3

You can even do away with the ECB part, in principle the one real thing about an IV is that it should be unique, and a counter could very well be. Since it is tricky to get the counter to be unique during attacks (see e.g. WEP encryption), it's much better to use a secure random (a real secure random, not a "Sony PS3" secure random or XKCD secure random).

Your understanding of crypto seems OK, but I would still go with the other recommendations and only go for your own schemes (and implementations) if all else fails.

Rondeau