[Cryptography] Long-term security (was Re: ratcheting DH strengths over time)

Max Kington mkington at webhanger.com
Mon Nov 16 13:48:40 EST 2015


On 16 Nov 2015 18:05, "Perry E. Metzger" <perry at piermont.com> wrote:
>
> On Mon, 16 Nov 2015 11:19:40 -0500 Kyle Rose <krose at krose.org> wrote:
> > This guess isn't completely blind, however, and so if you have some
> > information that needs to remain secret for 20 years,
>
> Just a slight redirect of the model in your mind. The issue isn't only
> keeping information qua information secure for long periods.
>
> SCADA systems and other embedded hardware may need to be kept secure
> from tampering for 30 years or longer. This stuff shows up in
> surprising places -- people really are doing things like putting
> building heating and elevator systems onto the internet now.

It's actually happening all over the place with IoT enabled home based
technology right now. Two of my neighbours have intelligent Internet
connected heating systems. Even as a home consumer, the upgrade path and
ongoing support is a major reason I've not taken the plunge.

As you say, I'm not even talking about a life critical safety system with a
thirty year lifespan

>
> The biggest current problem is that generally the engineers building
> such systems have no idea how to design them for security, but even if
> they did, how do you design a system to remain secure when it might be
> in place in forty years because no one wants to replace their elevator
> controller since it is still working?
>
> Say you have thousands of such systems or even millions of them out in
> the field, all happily dialing home and getting new instructions, all
> that protected by an RSA key or an elliptic curve signature key. How
> do you keep that safe for a stupid amount of time?
>
> The sad truth is, you probably can't...

I think you're sort of right but playing devils advocate, does it matter?
We accept that when we build and deploy cryptosystems we may need to not
paint ourselves into a corner when selecting algorithms or key lengths. The
reality is these things change far more infrequently than we engineer for.

The most important thing is though, what is the expected lifespan of the
systems we engineer now? Once upon a time a closed embedded system would
never get upgraded because there were no apis with which it needed to stay
compatible with. An upgrade would involve a new one because the
microcontroller had actually died or a repair.

Where systems now have a range of dependencies on networks and external
systems to provide a significant chunk of their value that ability to stay
static has gone. We are, like it or not, in an environment where systems
will *have* to change.

Ideally secure systems engineering would deal with the need to fail away
from certain mechanisms by design accepting that you may lose some value
add to keep the system safe. Consumers I suspect won't be very accepting of
that and as such I can't see it being in the interests of systems engineers
to invest in that kind of thinking.

This intersection with cryptography only comes about because of the
ingrained attitude of cryptographers to have to think to the future in a
way systems developers never have*

Max

*perhaps they used to but not anymore in any wide measure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151116/304a822c/attachment.html>


More information about the cryptography mailing list