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

Sophie:

I fully understand the benefits of an AEAD.  I am one of the co-authors of AES-CCM.

That said, there is a size and performance concern in the bootloader.  We need to find a way to accommodate.  You and others seem to have fewer concerns with AES-CTR because there is no padding.  Frankly, the lack of expansion makes AES-CTR a better fit in most firmware encryption situations.

Perhaps dropping AES-CBC from this draft is a reasonable way forward.  What do you think?

Russ

> On Oct 31, 2022, at 3:30 PM, Sophie Schmieg <sschmieg=40google.com@dmarc.ietf.org> wrote:
> 
> I'd like to note that with firmware in particular, we will soon have to switch to hash based signature schemes in order to gain post-quantum readiness (firmware usually uses fixed signing keys, so this transition needs to happen soon and it needs to use hash based solutions to avoid parameter drift), where the signature is 1KB in the "best" case (this corresponds to stateful hash based signatures, RFC 8554 and RFC 8391, I put "best" in quotation marks because statefulness comes with its own challenges), and 8KB in the easier to use case (the stateless scheme Sphincs+ [1], currently being standardized by NIST), so the devices will need to be able to tolerate a substantial amount of overhead already, so that the 16 byte per chunk tags are less likely to be an issue in any case.
> 
> You mention that the signature is checked over the plaintext, and not over the ciphertext. This should immediately rule out CBC mode, as we would still suffer from CBC padding oracle problems, bypassing the encryption in that case. With CTR mode, this scheme is, if looked at in isolation, secure, although it would adversely affect the rest of the COSE ecosystem, for saving what is a fairly minuscule overhead of 16 bytes per chunk (with chunks being able to be several KB in size) for a use case that is as far as I can tell a DRM scheme (which usually do not rely on standardized approaches, as obfuscation is a major part of DRM).
> 
> [1] https://sphincs.org/ <https://sphincs.org/>
> On Fri, Oct 28, 2022 at 7:45 AM David Brown <david.brown@linaro.org <mailto:david.brown@linaro.org>> wrote:
> 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
> 
> 
> -- 
> 
> Sophie Schmieg | Information Security Engineer | ISE Crypto | sschmieg@google.com <mailto:sschmieg@google.com>
> 
> _______________________________________________
> COSE mailing list
> COSE@ietf.org
> https://www.ietf.org/mailman/listinfo/cose