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

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

See SRF

From: CFRG <[e-mail]> On Behalf Of Orie Steele
Sent: Sunday, March 17, 2024 9:27 PM
To: Blumenthal, Uri - 0553 - MITLL <[e-mail]>
Cc: [e-mail]
Subject: 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.

SRF: Some of us were discussing ways to do hybrid certificates perhaps 5 years before CNSA 2.0 came out.  I have little reason to suspect that such interest would have somehow disappeared without CNSA 2.0.

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

SRF: Now, I do have a certain fondness for SLH-DSA, but that doesn’t change the fact that it is not well suited for the majority of use cases.  The signatures are quite large and the signing takes a long time.  It is a niche solution that works well in certain use cases, but not most.

That's been my takeaway.

OS

On Mon, Mar 18, 2024, 8:45 AM Blumenthal, Uri - 0553 - MITLL <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> 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
> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> on behalf of Stephen Farrell
> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> Sent: Monday, March 18, 2024 7:41:33 AM
> To: [e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]<mailto:[e-mail]>>> 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
[e-mail]<mailto:[e-mail]>
https://mailman.irtf.org/mailman/listinfo/cfrg