Re: [COSE] COSE Support for AES-CTR and AES-CBC

[David Brown <[e-mail]>]

On Fri, Oct 28, 2022 at 10:21:30AM -0400, Russ Housley wrote:

> > For this purpose ciphers without integrity protection are used to
> >   encrypt the firmware image.  Integrity protection for the firmware
> >   image must, however, be provided and the the suit-parameter-image-
> >   digest, defined in Section 8.4.8.6 of [I-D.ietf-suit-manifest], MUST
> >   be used.
> > 
> > I'm not convinced by that. Why couldn't you just store
> > the tag for each chunk wherever the signature is stored?
> > 
> > Overall, I'd say defining non-AEAD modes doesn't seem
> > like a good trade-off.

> AES-CCM and AES-GCM require the authentication check to be performed
> before any plaintext is returned.  So, one would have to have a
> separate tag for each storage block, which adds a lot of overhead
> and complexity, especially since there is already a digital
> signature over the whole thing.

In the case described, there simply isn't storage space for a tag per
block.  This use case performs a full signature check on the image
before making use of it, as Russ mentions.

In the firmware update case, the system needs to be able to verify the
signature of the image, even after the image has been decrypted, there
has to be a signature that covers the entire plaintext.  Additional
space for tags would reduce the space available for the firmware
itself.  The decryption happens during an image upgrade state.  Any
attack that results in modified plaintext would prevent the firmware
from running, as the signature check would fail.

The goal here is to make these algorithms available for a use-case
where they are already being used, and significant resource
constraints make other solutions unavailable.  We would like to be
able to register these algorithms in such a way that it is clear that
they should not be adopted for any new use, while at the same time
capturing this existing use case.

David