Re: [CFRG] [EXT] Re: [EXTERNAL] pq firmware signing question

I suspect that if CNSA 2.0 had not recommended dilithium (iirc), we
wouldn't be discussing hybrid signatures at all.

If you don't trust ML-DSA, use SLH-DSA, no need to burn in hybrids.

That's been my takeaway.

OS

On Mon, Mar 18, 2024, 8:45 AM Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
wrote:

> Look at it this way: you want your firmware updates to remain secure after
> CRQC appears.
>
> If your trust anchor can be re-written - then as soon as I can lay my
> hands on a CRQC, I crack your Classic signing key, create and sign my
> malicious firmware with your key and add my new malicious trust anchors to
> replace yours, and push my update to as many of your devices as I can.
>
> If your trust anchors can't be re-written - i.e., burnt in ROM or such -
> then I'll do all of the above except replacing your trust anchors.
>
> Thus, it seems that the only way to defend against the above kind of
> attack is to load PQ trust anchors now.
> --
> V/R,
> Uri
>
> There are two ways to design a system. One is to make it so simple there
> are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
> - C. A. R. Hoare
>
>
>
>
> On 3/17/24, 17:52, "CFRG on behalf of Stephen Farrell" <
> cfrg-bounces@irtf.org <mailto:cfrg-bounces@irtf.org> on behalf of
> stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> wrote:
>
>
>
>
>
>
> On 17/03/2024 21:45, Mike Ounsworth wrote:
> > Stephen.
> >
> > Short answer: firmware verification keys burned into ROM or some
> > other immutable trust store which is itself outside the memory space
> > of the firmware that you can update.
>
>
> Yep, that's the kind of answer I expected, but some details as
> to what and why was more what I was after. You can't of course
> update the ROM unless it's an EPROM or similar but it's not clear
> (to me:-) that the code that causes that key/alg to be used to
> verify new sigs can't be updated.
>
>
> Cheers,
> S.
>
>
> >
> > I am not myself a hardware manufacturer, but I have been lead to
> > believe that this is common practice.
> >
> > - Mike Ounsworth ________________________________ From: CFRG
> > <cfrg-bounces@irtf.org <mailto:cfrg-bounces@irtf.org>> on behalf of
> Stephen Farrell
> > <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> Sent:
> Monday, March 18, 2024 7:41:33 AM
> > To: cfrg@irtf.org <mailto:cfrg@irtf.org> <Cfrg@irtf.org <mailto:
> Cfrg@irtf.org>> Subject: [EXTERNAL] [CFRG] pq
> > firmware signing question
> >
> >
> > Hiya,
> >
> > A number of people have asserted that firmware signing implies
> > distributing a public value now, (or soon) on which they may still
> > have to rely after a CRQC might exist. The implication being that we
> > should start to do this kind of thing now, based on some composite
> > sig-alg, verification of which is assumed to be implemented below the
> > crypto APIs used by relevant applications.
> >
> > I'd like to try tease bits of that apart to better understand what's
> > required.
> >
> > ISTM that firmware signing entirely does allow one to update the
> > signature keys/algs needed for the next signed firmware update and
> > that there is no need, given ongoing updates, to continue to depend
> > on the original key/alg for the public value with which a device was
> > shipped. IOW, update N can update anything, including the sig alg
> > required for update N+1.
> >
> > I don't understand what class of device might be able to load new
> > firmware but not change the verification alg for sigs on subsequent
> > updates. If there are such devices, can someone describe 'em?
> >
> > There does seem to be an exception - a factory-reset of a device
> > would imply returning to depending on the original public value and
> > alg. However, a factory reset also seems to imply that a human can
> > "touch"/control a specific device at a specific point in time so is
> > not an unattended upgrade. And if someone can touch the device, then
> > in many cases it'd be cheaper to replace the whole thing than do a
> > factory reset in the field.
> >
> > And then there's the issue of the specific signing key - it's hard to
> > imagine a system where that can be changed but the verification alg
> > cannot. Are there such systems?
> >
> > All in all, it seems like a lot of firmware signing deployments
> > should be able to allow for the evolution of verification algs, and
> > the set of devices where we now (or soon) need to embed a
> > forever-fixed alg and key for sig verification has to be very small.
> >
> > What am I getting wrong there?
> >
> > Ta, S.
> >
> > Any email and files/attachments transmitted with it are intended
> > solely for the use of the individual or entity to whom they are
> > addressed. If this message has been sent to you in error, you must
> > not copy, distribute or disclose of the information it contains.
> > Please notify Entrust immediately and delete the message from your
> > system.
> >
>
>
> _______________________________________________
> CFRG mailing list
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg
>