Fixed IV value zero for AES-CBC and AES-CTR

[kentakayama]

@hannestschofenig

I think it is better not to fix the IV value as zero.
As you know, section 4.1 of RFC9459 COSE: AES-CTR and AES-CBC says

The same IV and AES key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures the same IV value is not used more than once with the same AES key.

If we use the same IV and CEK on different plaintext, some information about part of them might be leaked.
But there is no guidance to use different CEK with AES-KW section, moreover using the same CEK is mentioned with ES-DH (+AES-KW) section.

I think we should say something like:

1. "you MUST NOT reuse the same IV, or use (pseudo)randomly generated IV" (need to fix our document)
2. "you MUST NOT reuse the same CEK on different plaintext"
3. "you SHOULD consider what happens if you reuse the same CEK with the fixed IV as zero"

Am I missing or confusing something important?

NOTE:
Section 7.1 and 7.2 of v17 draft say,

Hence, sector 0 needs 4096/16=256 AES-128-CBC operations using IV 0.

Hence, when an image is encrypted using AES-CTR-128 or AES-CTR-256, the IV MUST start with zero (0) and MUST be incremented by one for each 16-byte plaintext block within the entire slot.

[kentakayama]

It was my misunderstanding. The same CEK will never used for other payloads.
Should we add "you MUST NOT reuse the same CEK on different payloads"?

https://datatracker.ietf.org/doc/html/draft-ietf-suit-firmware-encryption#section-6.2.2-2.1.1

[kentakayama]

I'm still wondering about the necessity to fix IVs to start with 0 for every use case.
Though firmware encryption for constrained IoT devices with FLASH storage is one of the main target, there are other use cases which don't want to fix the IV starting with 0.

Needed decision

If we make it just for one example use case fixing the IV value, we can move them to section 9. Firmware Updates on IoT Devices with Flash Memory.
Otherwise, I have to update the example binaries to use {/ IV / 5: h'00000000000000000000000000000000'} .

Additionally, I think we should warn readers that the mis-configuration of IV values may a security issue (see below).

Another concern: IV value collisions

Assumption

• Assign one component identifier to each (slot, sector) pairs
  • Each slot has 64 KiB, and each sector has 4096 bytes = 256 AES blocks (same as the example in 7.2.1 and 7.3.1)
  • just one device implementation example
  • NOTE: Users must define it using component identifier because there is no suit-parameter-component-sector
• Fetch chunked ciphertext to each sectors in slot # 1
• Decrypt each sectors from slot # 1 to slot # 0

Correct example

Mis-configured IV example

With this mis-configured IVs, the same IV value will be used, e.g. IV=h'00..0001' is used in 2nd block of [h'01', h'00'] and 1st block of [h'01', h'01'], with the same secret key, which violates the security consideration of RFC 9459.

Once the attacker obtains the two plaintexts XORed together, it is relatively straightforward to separate them. Thus, using any stream cipher, including AES-CTR, to encrypt two plaintexts under the same key stream leaks the plaintext.

TODO

We should warn it in the security considerations.