Re: [CFRG] pq firmware signing question

["Dr. Pala" <[e-mail]>]

Dear Stephen, All,

I totally understand your initial point of view, however, in practice, I 
think you might be underestimating a key point.

The root of trust is usually burned into hardware to prevent being able 
to replace it, even over a long period of time. Think about many 
different types of devices, TPMs included.

Because in many environments device credentials are very long lived, it 
is very conceivable we might need to be a bit more cautious about the 
consequences of bad planning than software-based environments. Although 
technologies like TEEs are gaining traction, their use is still not 
wide-spread not very easy to use/implement.

Ultimately, I think that */it all depends on what is the level of risk 
you are willing to take and what are the consequences of having devices 
in the future that might become de-facto "freely upgrade-able"/* because 
of issues with the cryptography.

It is also important to consider your market. For example, if you work 
with governments and/or public administrations, you should also consider 
the implications of your choices and possible policy changes and impact. 
Same applies if you are on the other side of the fence: the technology 
decisions will deeply affect your organization(s), your citizens, and 
your users/customers.

In summary, I think that:

  * Many */Early Adopters want to be able to use combinations of
    algorithms during the transitioning/*, whenever possible, to lower
    risks associated with new crypto deployments. This is clearly stated
    at every single quantum-related conferences, events, and papers.
    Just take a look at the post-quantum workshop at MWC in Barcelona.
  * Although we always say "plan for crypto-agility", the r*/eal-world
    practice imposes a lot of limitations that might not make it
    possible to field-upgrade/* your credentials and/or the root of trust.
  * Hybrid technologies can help organizations leveraging the new
    algorithms, while keeping their FIPS certifications (if needed) and
    */not having to update/modify standard (or legacy) protocols/* for
    the optimized version with respect of the new cryptography.

As we discussed many times in LAMPS and other venues, I think that the 
availability of standardized tools to ease migration from 
quantum-vulnerable cryptography, */especially while we are figuring out 
how to upgrade all our security protocols/*, can be really valuable for 
early adopters such as the Financial sector, the Healthcare industry, 
and Governmental Organizations.

*/The last consideration I want to add here is about legacy protocols./* 
As many of us understand, the world is not perfect and we need to 
address many corner cases. I expect that the /world-wide community will 
do a great job upgrading the "latest and greatest" versions of the 
protocols... but there are many instances where this will NOT be the 
case/ and organizations will be left with very costly upgrades... maybe 
having some tools to address these real-world use-cases could help 
everybody and lower the cost of migration.

Whichever risk profile for your organization and your environments might 
be, you might need different deployment strategies that can be updated 
over time. Hybrids (whichever version) can help you getting there in a 
cost-effective way.

Kind Regards,
Massimiliano


On 3/17/2024 3:41 PM, Stephen Farrell wrote:
>
> 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.
>
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://mailman.irtf.org/mailman/listinfo/cfrg

-- 
Cheers,
Massimiliano