<p dir="ltr"><br>
On 16 Nov 2015 18:05, "Perry E. Metzger" <<a href="mailto:perry@piermont.com">perry@piermont.com</a>> wrote:<br>
><br>
> On Mon, 16 Nov 2015 11:19:40 -0500 Kyle Rose <<a href="mailto:krose@krose.org">krose@krose.org</a>> wrote:<br>
> > This guess isn't completely blind, however, and so if you have some<br>
> > information that needs to remain secret for 20 years,<br>
><br>
> Just a slight redirect of the model in your mind. The issue isn't only<br>
> keeping information qua information secure for long periods.<br>
><br>
> SCADA systems and other embedded hardware may need to be kept secure<br>
> from tampering for 30 years or longer. This stuff shows up in<br>
> surprising places -- people really are doing things like putting<br>
> building heating and elevator systems onto the internet now.</p>
<p dir="ltr">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. </p>
<p dir="ltr">As you say, I'm not even talking about a life critical safety system with a thirty year lifespan</p>
<p dir="ltr">><br>
> The biggest current problem is that generally the engineers building<br>
> such systems have no idea how to design them for security, but even if<br>
> they did, how do you design a system to remain secure when it might be<br>
> in place in forty years because no one wants to replace their elevator<br>
> controller since it is still working?<br>
><br>
> Say you have thousands of such systems or even millions of them out in<br>
> the field, all happily dialing home and getting new instructions, all<br>
> that protected by an RSA key or an elliptic curve signature key. How<br>
> do you keep that safe for a stupid amount of time?<br>
><br>
> The sad truth is, you probably can't...</p>
<p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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. </p>
<p dir="ltr">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.</p>
<p dir="ltr">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*<br></p>
<p dir="ltr">Max</p>
<p dir="ltr">*perhaps they used to but not anymore in any wide measure</p>