# Authentication using AES

I need to implement an authentication mechanism in an embedded environment which does not support floating point operations but has an AES accelerator module which allows for encyption/decryption operations.

Currently, I'm thinking of using the following approach:

1. Compute the ciphertext of the message using a secret key k1.
2. In parallel compute the ciphertext of the same message using secret key k2(k1 $\neq$ k2). Upon the encryption of each block the current block is XOR-ed with the previous so that the length of the authentication code is always equal to the size of a block (i.e. 128 bits).
3. The message to be sent is obtained by concatenating the ciphertext with the authentication code.

Is this approach secure?

• What modes of encryption does the accelerator use? You could likely use CBC-MAC. – mikeazo Aug 4 '15 at 14:50
• @mikeazo 128-bit CBC – Sebi Aug 4 '15 at 14:51
• What block cipher mode are you using? Why don't you just use CMAC as the MAC? (CBC-MAC is secure only with fixed length messages.) – otus Aug 4 '15 at 14:52
• P.S., you should definitely read this if you want to use CBC-MAC. It goes along with otus's comment. – mikeazo Aug 4 '15 at 14:55
• Does the accelerator give you direct access to the round function? – Richie Frame Aug 4 '15 at 23:45

TL;DR
No, the approach is not secure. Use a standard like CMAC instead. Or even better, check your AES accelerator module to see if it supports any AEAD modes of encryption like GCM, CCM, EAX.

Long Version

In order for a message authentication code (MAC) to be secure, an adversary with oracle access to the MAC (basically this means the adversary can send arbitrary messages to a black-box that will compute the MAC tag), should not be able to forge a MAC (i.e., construct a valid MAC for something that the black box never computed a MAC for).

I am going to ignore step 1 for now since that is the confidentiality part and has no impact on the authentication part. Also, I'm assuming you are using AES-CBC with a 128-bit key based on your comment.

So the proposal is to encrypt the plaintext with a key $k_2$, then XOR all the blocks together to get a MAC tag. Let's assume that a static IV of all 0's is used for the MAC.

For a two block message, say $m_1,m_2$, the MAC would be $MAC_1 = E_{k_2}(m_1)\oplus E_{k_2}(E_{k_2}(m_1)\oplus m_2)$. I could also ask the oracle for the MAC of $m_1$ by itself, which would be $MAC_2 = E_{k_2}(m_1)$.

Notice now that $MAC_1\oplus MAC_2$ is a valid MAC for the message $E_{k_2}(m_1)\oplus m_2$, but I never asked the black box for that MAC. So that would be a break.

How useful is this? Well, since the attacker controls $m_1$ and $m_2$, and can get $E_{k_2}(m_1)$ before choosing $m_2$, the attacker can make $E_{k_2}(m_1)\oplus m_2$ anything she wants by setting $m_2$ appropriately. Therefore, the attacker can ask for two MACs on non-malicious looking messages (likely they will look random), but get a MAC on a chosen message.

So, no, your approach is not secure.

• If it's not available it would be a good idea to implement EAX on top of the accelerator. You'd only need CMAC (or even CBC-MAC, as CMAC relies on CBC-MAC) to implement it. Then you can switch when it becomes available. – Maarten Bodewes Aug 5 '15 at 14:14