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

[Mike Ounsworth <[e-mail]>]

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.

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]> on behalf of Stephen Farrell <[e-mail]>
Sent: Monday, March 18, 2024 7:41:33 AM
To: [e-mail] <[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.