Properties of a single-message protocol using AES

The following protocol is used for providing data confidentiality between sender and receiver:

$$\text{sender} \rightarrow \text{receiver}: E_k(m \mathbin\Vert \mathrm{ID}_s\mathbin\Vert \mathrm{Timestamp})$$

• $E_k$: the encryption function of AES
• $k$: a shared secret key
• $\mathrm{ID}_s$: the ID of sender
• $\mathrm{Timestamp}$: the time
• $m$: the message (payload) from the sender

Assume that AES is secure. What are the security services that can be provided by this protocol?

I think we can get the Sender authentication because of the sender ID. But how about the others like data integrity, non-repudiation or data authentication? Can AES and this protocol provide this?

2 Answers

Non repudiation : No, as the sender can claim that the other person sent himself the message
Data Integrity : No, as the cipher text can be corrupted in the midway
Authentication : Yes, the message is indeed sent by other sender as the key is known only to sender and receiver
Confidentiality: Yes, as the key is only known to receiver and sender

Hope this helps

• May I ask any other services that would be involved in this situation? Thank you. – Ng Clement Mar 23 '17 at 4:17
• @Ng Clement, can you be bit more specific about what type of services? – Logan Mar 23 '17 at 4:25
• like the Confidentiality, integrity and availability (CIA)? – Ng Clement Mar 23 '17 at 5:38
• Edited the answer for confidentiality, can't say anything about availability as it depends upon the two parties and not on the algorithm in specific. – Logan Mar 23 '17 at 6:12
• I'm not sure what exactly you mean by authentication because messages can be replayed. – Elias Mar 23 '17 at 15:25

The definition of the protocol is not correct: the encryption function of AES can only encrypt a message of exactly 16 bytes (the block size). Evidently here you need to encrypt a variable-length message, so $E_k$ should instead be some mode of operation of AES.

Assuming that $E_k$ is an encryption mode of AES, such as AES-CBC or AES-CTR, the protocol obviously ensures the confidentiality of the payload $m$, since it's only ever sent in encrypted form with a key that remains confidential.

The protocol does not guarantee integrity, authenticity or non-repudiation since it is possible to forge a ciphertext without knowing the key. The forger may not be able to know exactly what is in the fake $m$ that they're sending, but a forgery is feasible. How easy it is depends on the malleability of the encryption algorithm. Taking AES-CTR as an example, you can flip any bit in the ciphertext, and this decrypts to the corresponding plaintext with the same bit flipped. So if an adversary sees a ciphertext, they can send a modified message with a different payload, ID or timestamp with precise control over how the message is modified. AES-CBC is less malleable (to oversimplify, if the adversary modifies the ciphertext at some point, then the following block will decrypt into garbage), but can be corrupted nonetheless, so there is no guarantee of authenticity.

If $E_k$ is an authenticated encryption mode of AES, such as AES-GCM or AES-CCM, then the protocol does guarantee the authenticity of the payload $m$, since the transmitted message includes an authentication tag that covers the combination of the payload $m$ with the sender's identity $\mathrm{ID}_s$. (Note that this would not be the case if the message was $E_k(m)||E_k(\mathrm{ID}_s)||E_k(\mathrm{Timestamp})$, since an attacker could listen to multiple communications and combine different pieces together.)

The protocol does not provide any integrity guarantee since an adversary can suppress messages in transit and can replay old messages. The timestamp does not help with integrity since there is nothing wrong with an old message in itself: how old a legitimate message is depends on the speed of the transmission. To detect message repetition, the recipient could save a log of received timestamps; this can only work if the sender never sends multiple messages with the same timestamp, which either means a very high resolution timestamp and a high clock refresh rate on the sender, or use a counter instead of a timestamp. Using a counter also allows the receiver to detect message losses.

Since the key is shared between the sender and the receiver, there is no non-repudiation property: the receiver can forge any message, so the sender can repudiate a message by claiming the receiver made it.