Is it safe to use single-block AES for mutual authentication?

Question

I read the question Symmetric mutual authentication with client using a derived secret and its answer which, if I'm not mistaken, assert that it should be safe to use the proposed protocol for mutual authentication between a client A and a server B as follows:

1. At commissioning, each client A gets a unique identifier $i_A$ and a derived key $k_A$ which is generated from the secret $s$ by HMAC($s$, $i_A$).
2. To authenticate B, A sends $i_A$ and a random nonce $c_A$ to B.
3. B calculates the expected derived key $k_A'$ = HMAC($s$, $i_A$) and replies with $r_B$ = HMAC($k_A'$, $c_A$) as well as a random nonce $c_B$.
4. A can now authenticate B by comparing $r_B$ to HMAC($k_A$, $c_A$).
5. To enable authentication of A with B, A sends $r_A$ = HMAC($k_A$, $c_B$) to B.
6. Now B can authenticate A by comparing $r_A$ to HMAC($k_A'$, $c_B$).

Now I would like to use a single-block AES128 for the HMAC calculation in this scheme such that every message item (namely, $i_A$, $c_A$, $r_B$, $c_B$, and $r_A$) between A and B is exactly 128 bits long and the AES128 is used in ECB mode.

Given this answer to a question about AES Message Authentication Vulnerability, I think this should be safe?

Answer 1

If we assume that AES is a pseudorandom permutation (which is a standard model for block ciphers), then AES can replace the HMAC in your construction. Be aware, this only works because you have a fixed message length, i.e. the protocol must not accept nonces $> 128$bit.

Besides, I guess you are aware of this but you have a shared secret key among all users. Hence, your protocol does not authenticate a specific user. Instead, the protocol only verifies that the other side is a user that knows the secret key.

The reason is that any user knowing $s$ can compute $k_A = \text{HMAC}(s, i_A)$. Even if $i_A$ is not made public explicitly. Everyone that communicated once with $A$ will know $i_A$. Besides, this would mean that you have to protect $i_A$ while being transmitted and finally this has the problem that the authenticity of $i_A$ must be verifiable. Otherwise, an attacker could use an arbitrary value as $i_A$.

If you only want to get a proof of membership, this protocol works but is overly complicated as you can omit the key derivation step. You can simply use $\text{HMAC}(s,nonce)$...

As you included the identifiers I guess you wanted something stronger than a proof of membership. In this case, you should switch to some standard mechanism like TLS with a PKI. You will not really be able to omit public key crypto in this setting. The only (impractical) solution in the symmetric setting would be the establishment of one key for each pair of users.

Answer 2

Now I would like to use a single-block AES128 for the HMAC calculation in this scheme [...]

HMAC requires a hash function with a variable input size, so you cannot just use AES in it. If you want to use some other MAC instead of HMAC, you can use AES. AES ECB is a secure MAC for single block messages, so that would work.

Given this answer to a question about AES Message Authentication Vulnerability, I think this should be safe?

Correct. However, with a block size of 128 bits, the birthday bound for $c_A$ or $c_B$ colliding with an earlier value is only $2^{64}$. You should follow normal practice for AES and limit yourself to e.g. $2^{48}$ authentication attempts before you rotate keys.

(If you made B use $k_{AB} = AES(k_A, i_B)$ for encryptions they send it would simplify tracking key lifetimes if you have many parties with the same shared key, since each could count the number of times they have used their key. You could reserve the top bit to distinguish between $i_X$ and $c_X$.)