[prev in list] [next in list] [prev in thread] [next in thread]
List: cfrg
Subject: Re: [CFRG] pq firmware signing question
From: "Dr. Pala" <director () openca ! org>
Date: 2024-03-17 22:16:59
Message-ID: 43914419-e8e9-408f-ba08-2e9226ae086f () openca ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
> CFRG@irtf.org
> https://mailman.irtf.org/mailman/listinfo/cfrg
--
Cheers,
Massimiliano
[Attachment #5 (text/html)]
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Calibri">Dear Stephen, All,</font></p>
<p><font face="Calibri">I totally understand your initial point of
view, however, in practice, I think you might be underestimating
a key point.</font></p>
<p><font face="Calibri">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.<br>
</font></p>
<p><font face="Calibri">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. <br>
</font></p>
<p><font face="Calibri">Ultimately, I think that <b><i>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"</i></b>
because of issues with the cryptography.</font></p>
<p><font face="Calibri">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.</font></p>
<p><font face="Calibri">In summary, I think that:</font></p>
<ul>
<li><font face="Calibri">Many <b><i>Early Adopters want to be
able to use combinations of algorithms during the
transitioning</i></b>, 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.<br>
</font></li>
<li><font face="Calibri">Although we always say "plan for
crypto-agility", the r<b><i>eal-world practice imposes a lot
of limitations that might not make it possible to
field-upgrade</i></b> your credentials and/or the root of
trust.</font></li>
<li><font face="Calibri">Hybrid technologies can help
organizations leveraging the new algorithms, while keeping
their FIPS certifications (if needed) and <b><i>not having to
update/modify standard (or legacy) protocols</i></b> for
the optimized version with respect of the new cryptography.</font></li>
</ul>
<p><font face="Calibri">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, \
<b><i>especially while we are figuring out how to upgrade all our security
protocols</i></b>, can be really valuable for early adopters
such as the Financial sector, the Healthcare industry, and
Governmental Organizations.</font></p>
<p><font face="Calibri"><b><i>The last consideration I want to add
here is about legacy protocols.</i></b> As many of us
understand, the world is not perfect and we need to address many
corner cases. I expect that the <i>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</i> 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.</font></p>
<p><font face="Calibri">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.<br>
</font></p>
<p><font face="Calibri">Kind Regards,<br>
Massimiliano<br>
</font></p>
<p><font face="Calibri"><br>
</font></p>
<div class="moz-cite-prefix">On 3/17/2024 3:41 PM, Stephen Farrell
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:73126498-47c2-4f8a-9425-18a3d9cce22c@cs.tcd.ie">
<br>
Hiya,
<br>
<br>
A number of people have asserted that firmware signing implies
<br>
distributing a public value now, (or soon) on which they may
<br>
still have to rely after a CRQC might exist. The implication being
<br>
that we should start to do this kind of thing now, based on some
<br>
composite sig-alg, verification of which is assumed to be
implemented
<br>
below the crypto APIs used by relevant applications.
<br>
<br>
I'd like to try tease bits of that apart to better understand
<br>
what's required.
<br>
<br>
ISTM that firmware signing entirely does allow one to update the
<br>
signature keys/algs needed for the next signed firmware update and
that
<br>
there is no need, given ongoing updates, to continue to depend on
<br>
the original key/alg for the public value with which a device was
<br>
shipped. IOW, update N can update anything, including the sig
<br>
alg required for update N+1.
<br>
<br>
I don't understand what class of device might be able to load new
<br>
firmware but not change the verification alg for sigs on
subsequent
<br>
updates. If there are such devices, can someone describe 'em?
<br>
<br>
There does seem to be an exception - a factory-reset of a device
<br>
would imply returning to depending on the original public value
<br>
and alg. However, a factory reset also seems to imply that a human
<br>
can "touch"/control a specific device at a specific point in time
<br>
so is not an unattended upgrade. And if someone can touch the
<br>
device, then in many cases it'd be cheaper to replace the whole
<br>
thing than do a factory reset in the field.
<br>
<br>
And then there's the issue of the specific signing key - it's hard
<br>
to imagine a system where that can be changed but the verification
<br>
alg cannot. Are there such systems?
<br>
<br>
All in all, it seems like a lot of firmware signing deployments
<br>
should be able to allow for the evolution of verification algs,
and
<br>
the set of devices where we now (or soon) need to embed a
forever-fixed
<br>
alg and key for sig verification has to be very small.
<br>
<br>
What am I getting wrong there?
<br>
<br>
Ta,
<br>
S.
<br>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" \
wrap="">_______________________________________________ CFRG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:CFRG@irtf.org">CFRG@irtf.org</a>
<a class="moz-txt-link-freetext" \
href="https://mailman.irtf.org/mailman/listinfo/cfrg">https://mailman.irtf.org/mailman/listinfo/cfrg</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Cheers,
Massimiliano</pre>
</body>
</html>
_______________________________________________
CFRG mailing list
CFRG@irtf.org
https://mailman.irtf.org/mailman/listinfo/cfrg
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic