Sophie: You will see in https://www.ietf.org/archive/id/draft-moran-suit-mti-02.txt tis proposing a hash-based signature algorithm in the SUIT WG.
Russ > On Oct 31, 2022, at 3:30 PM, Sophie Schmieg > <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
