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

[Stephen Farrell <[e-mail]>]

On 17/03/2024 21:55, Scott Fluhrer (sfluhrer) wrote:
> I do work for a hardware manufacturer; I can confirm that this is what we do.

Thanks. Can you provide (ptrs to) more details? Other that for a very
tiny range of devices, I don't get why the upgraded device can't change
the range of sig algs usable. I'm also surprised that (I guess) the
root of trust for the signing key also can't be changed ever.

What I'm trying to understand is how prevalent such devices might be,
and therefore how much to weigh their specific requirements against
what's needed for almost all devices that don't have those specific
requirements.

Ta,
S.


> 
> From: CFRG <[e-mail]> On Behalf Of Mike Ounsworth
> Sent: Sunday, March 17, 2024 5:46 PM
> To: Stephen Farrell <[e-mail]>; [e-mail]
> Subject: Re: [CFRG] [EXTERNAL] pq firmware signing question
> 
> 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]<mailto:[e-mail]>> on behalf of Stephen Farrell <[e-mail]<mailto:[e-mail]>>
> Sent: Monday, March 18, 2024 7:41:33 AM
> To: [e-mail]<mailto:[e-mail]> <[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.
>