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
signature.asc
Description: PGP signature
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
