<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 24, 2014 at 5:18 AM, Alexandre Anzala-Yamajako <span dir="ltr"><<a href="mailto:anzalaya@gmail.com" target="_blank">anzalaya@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Recent research has shown that numerous devices (headless servers for<br>
example) generate their long lived cryptographic keys upon their first<br>
start.<br></blockquote><div> </div><div>But in this case there is a file system and it is clear that </div><div>extra effort is needed to generate entropy.  Long lived keys</div><div>would be known to be fragile and in need of replacement</div><div>if the extra effort is missing.   </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In that case there is no "last time" that can be reliably trusted.<br>
Unless I misunderstood your point I don't clearly see the engineering option.<br></blockquote><div><br></div><div>The lack of persistent storage is the issue.  A refrigerator</div><div>or other device that generates a fresh set of keys each time</div><div>it powers up needs hardware engineering.  A factory process could be engineered</div><div>that would insert a trustable entropy seed in such a device as part of testing. </div><div>Network MAC addresses are factory programmed and if the device</div><div>containing a MAC address had room such a seed could be used</div><div>once and combined with site specific local data time, temperature, arp, </div><div>broadcast ping, DHCP, bootp ...  input so the long lived keys can start</div><div>live on improved footing.   Other hardware could have a one time latch</div><div>that gates read access to a seed and after reading the seed device </div><div>once at boot time  it would be unavailable.  Future entropy seeding could</div><div>look at it and also for a filesystem cookie combine them and move on.</div><div><br></div><div>The first start is a challenge but engineering can improve it. Cost</div><div>reductions can make it more difficult.  </div><div><br></div><div>Site process can connect to new headless servers quickly and insert </div><div>trusted entropy, regenerate keys and more before allowing a server</div><div>to connect to anything except a single trusted host.   But this</div><div>requires engineering at the site.  Best practice analysis and models can </div><div>remove a lot of mis-steps.</div><div><br></div><div> </div></div>-- <br><div dir="ltr">  T o m    M i t c h e l l</div>
</div></div>