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

[Stephen Farrell <[e-mail]>]

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]> 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.
>