Using the same AES key for CBC and ECB

Question

Overview

I am trying to create a way for the server and the client to be able to generate a unique IV for each request, which is different for each client and yet deterministic. What I mean by deterministic is that the server can calculate IV for any request in the future, knowing only the initial sequence.

The reason I need this feature is because I use AES encryption to implement a one-time password (OTP) scheme. When a client registers with the server, he is provided with 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. Therefore, even if an attacker sniffed the last OTP without a shared key, they would not be able to get the next OTP. OTP is encrypted by AES in CBC mode. The problem occurs if the server and client are not synchronized. The way I planned to deal with this is to create several OTPs in the future on the server side and see if any of them match the client. However, without a way to deterministically calculate IV for each encryption iteration, this is not possible.

Before I enter my proposed solution, let me express my understanding of AES, IV, CBC and ECB. Thus, if I have any misunderstandings in my basics, they can be pointed out and corrected.

Theory

ECB

I know that ECB will produce the same output for identical plaintext blocks encrypted with the same keys. Therefore, it should not be used for several data blocks, since plaintext information can be recognized by statistical analysis of the data. Based on this, it would seem that if you could guarantee that your data was always less than 16 bytes (128 bits), this would eliminate the problem of statistical attack. In addition, if you can also ensure that you never encrypt the same plaintext with the same key, you will never get the same result. Therefore, it seems to me that using ECB is safe if your system always meets these very strict criteria.

CBC and IV

I know that CBC is designed to fix both of these issues. By blocking blocks, it eliminates the statistical attack of several ECB blocks. By never using the same IV for the same AES key, you fix the problem that the same file will be encrypted with the same output using the same key.

Key uniqueness

If each client receives a generated AES key, then when there is a small chance that several users having the same key have very little chance. Therefore, we can safely assume that none of the two clients will use the same AES key.

Proposed solution

My proposed solution is to provide each client with a unique AES key. When a key is generated, the counter will be initialized with a random number. Each time something needs to be encrypted, the counter will increase by one. This number will be supplemented by a block and then encrypted using AES in ECB mode. The result of this will be my IV for encrypting data using CBC.

If the server does not synchronize with the client counter because it has the same key and the ECB does not require an IV, it can continue to generate an IV until it finds one that can decrypt the data.

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

My questions

Is my fundamental understanding of the technologies described in the proposed solution correct? Is there something clearly wrong with my proposed solution? Is there a security flaw in using the same key to generate IV in the proposed form, as well as for encryption using CBC?

I understand that the last question may be difficult / impossible to answer, because cryptography is really complex, but any understanding will be appreciated.

Thanks in advance.

Answer 1

As stated in the comments, I would avoid inventing the protocol at all costs and would rather try to implement a standardized protocol. Some OTP protocols require clients to use a second out-of-band device to receive OTP when they enter the server, a common scenario with banks is that when you request to enter the server application, the server will send you OTP for your mobile phone. OTP generators for client and server are usually time synchronized or not synchronized if I understood correctly that you plan to use the latest solution. I did not find in your description how you are going to manage the client counter on a separate device?

In any case, I would recommend using a standardized procedure that was “field-tested” rather than minimizing my own scheme. HOTP may be what you are looking for - although it uses a key HMAC solution and not symmetric encryption, but it should make everything simpler, t worry more about IV.

In any case, you should plan ahead how you want to install symmetric keys with your clients. If you cannot deal with this through a secure channel (for example, distributing keys in person), this will become a security problem for the entire system.

Answer 2

well, just a thought ... if you want something self-synchronizing, you can set AES in encrypted feedback mode ... so your encrypted text will be used as IV ... if both sides come out of sync, one block is encrypted enough text to restore synchronization (but the one that will bring resynchronization will not be decryptable, since the previous one is not available)

Answer 3

You can even do away with part of the ECB, in principle, one real thing about IV is that it must be unique, and the counter may well be. Since it is difficult to set the counter to be unique during attacks (see, for example, WEP encryption), it is much better to use a safe random case (a real safe random rather than a “safe random case” or an XKCD “Sony PS3” safe case).

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