2
$\begingroup$

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?

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Nice answer! Regarding the key derivation step, it is mainly to limit the exposure of $s$ to B participants. Ideally I would like to use a derived key for B as well so there is only one party (the commissioning entity) knowing $s$, but I don't think this is possible with AES. $\endgroup$ – FriendFX Oct 1 '15 at 1:24
  • $\begingroup$ Regarding the value $i_A$, you are right in that it is a publicly accessible property of every A participant and just happens to exist and to be unique (somewhat similar to NIC MAC addresses). So I only need proof of membership and just used the existing $i_A$ as a means to (somewhat) limit exposure of $s$ if that makes sense. $\endgroup$ – FriendFX Oct 1 '15 at 1:31
  • $\begingroup$ Thanks, for that setting it might be ok. However, you can at most get passive security (mitm attacks are easy as A does not authenticate himself). $\endgroup$ – mephisto Oct 1 '15 at 13:07
1
$\begingroup$

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$.)

$\endgroup$
  • $\begingroup$ Thanks for your answer! Regarding HMAC, I only took that from the question I derived my protocol from. Since I mentioned all messages are single-block only, I guess it is ok to replace HMAC with AES? $\endgroup$ – FriendFX Oct 1 '15 at 1:37
  • $\begingroup$ I am interested in schemes that (ab)use AES for authentication purposes, so using a derived key $k_B$ in B is tempting - but wouldn't that require that all As know about all Bs at least? Should I maybe ask a separate question for that? $\endgroup$ – FriendFX Oct 1 '15 at 1:41
  • $\begingroup$ @FriendFX, like I wrote in the first paragraph, ECB is a secure MAC in your use case. Using $k_B$ wouldn't require A to know $i_B$ beforehand, since B could send it in step 3. $\endgroup$ – otus Oct 1 '15 at 6:03
  • $\begingroup$ But then A needs to know the secret $s$, which was the reason for me to use $k_A$ instead of $s$ in the first place. Or is there another way? $\endgroup$ – FriendFX Oct 1 '15 at 6:16
  • $\begingroup$ @FriendFX, ugh, yeah, sorry. You would need to derive e.g. $k_{AB} = AES(k_A, i_B)$. I'll update the post. $\endgroup$ – otus Oct 1 '15 at 6:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.