On Thu, 15 Aug 2024, 18:02 Janos Follath, <Janos.Follath@arm.com> wrote:

Yes, more precisely the data in question is constructed in a way prescribed by the CMAC/CTR/CBC modes which are standard secure operation modes and that is what makes this specific application of ECB secure.

Thanks for the confirmation.

I am not sure what you mean by “internal implementations”. If you mean Issue 8617, it is just an idiosyncrasy of the API that the context is set up with ECB mode. The operation performed by the mbedtls_cipher_cmac_* functions will be still CMAC. This will go away in 4.0 and the only way to do CMAC will be the PSA Crypto API (which is already available in all supported versions, and) which doesn’t reference the ECB mode at all.

I was referring to CMAC internally expecting ECB, but your answer clarifies that.

Thanks a lot for the quick responses.


Cheers,

Janos

 

From: Chaitanya Tata <chaitanya.tk17@gmail.com>
Date: Thursday, 15 August 2024 at 11:24
To: Janos Follath <Janos.Follath@arm.com>
Cc: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: Re: [mbed-tls] Usage of ECB in AES mode

Thanks Janos for the clarification.

 

IIUC, ECB mode in MbedTLS refers to data and not the message, so it
is still secure and can be used as the underlying API for CMAC/CTR/CBC
modes?

This is why ECB is in the API as well and how users should use it (to implement a secure standard operation mode that is not supplied by Mbed TLS):https://arm-software.github.io/psa-api/crypto/1.2/api/ops/ciphers.html#c.PSA_ALG_ECB_NO_PADDING>   

From the link

It is recommended that applications only use ECB if they need to construct an operating mode that the implementation does not provide


I understand that this is the reason (to support unsupported implementations) for the ECB API to be publicly available, but based on that wording, for internal implementations that exist e.g., CBC/CMAC, we shouldn't be using ECB, is my understanding correct?

 

Cheers,

Chaitanya.

 

 

On Thu, Aug 15, 2024 at 3:45PM Janos Follath <Janos.Follath@arm.com> wrote:

Hi,

 

ECB mode means that the block cipher is applied block by block to the message directly. This is indeed insecure. However, all modes, CBC/CMAC/CTR etc apply the block cipher to blocks that might be related to individual message blocks but are constructed in a way that the result is safe.

 

When Mbed TLS uses ECB mode internally, it means that the block cipher is applied to a block of data (not to the message directly) in order to implement a secure operation mode. This is why ECB is in the API as well and how users should use it (to implement a secure standard operation mode that is not supplied by Mbed TLS):
https://arm-software.github.io/psa-api/crypto/1.2/api/ops/ciphers.html#c.PSA_ALG_ECB_NO_PADDING

When we say PSA_ALG_ECB_NO_PADDING, we mean a single application of the block cipher to a single block of data and not the actual ECB mode (which means slicing up the message to blocks and applying the block cipher to each block directly).

 

This is why the code you linked is as expected, why using “ECB” to implement CMAC correct and why we can’t remove “ECB” mode.

 

Cheers,

Janos

 

 

From: Chaitanya Tata via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Date: Thursday, 15 August 2024 at 09:55
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] Usage of ECB in AES mode

Hi,

ECB is unsecure, see
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB)
and shouldn't be used in production.

So, I have switched to one of CBC/CMAC/CTR modes, but in
`mbedtls_cipher_cmac_starts`
I see that it only accepts ECB variants, and also doesn't seem to be
using the `type`.

From https://github.com/Mbed-TLS/mbedtls/issues/8617 I see that ECB
for AES was intentional,
even for the CMAC API.

Is this expected?

1. Is using ECB for CMAC API correct?
2.Shouldn't we remove the ECB altogether?

Appreciate any clarifications.

Cheers,
Chaitanya.
--
mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org