<p dir="ltr"><br>
Den 16 mar 2016 18:16 skrev "Henry Baker" <<a href="mailto:hbaker1@pipeline.com">hbaker1@pipeline.com</a>>:<br>
><br>
> Even though I'm a formalist by nature & training,<br>
> I can see that formal methods are not going to be<br>
> sufficient to solve most of the problems in computer<br>
> security today.</p>
<p dir="ltr">[...] </p>
<p dir="ltr">> I've come around to Dan Geer's way of thinking:<br>
> look to biological systems.  They've been dealing<br>
> with "security" problems for perhaps 2 billion<br>
> years, so there's some chance that they have<br>
> some tricks up their microscopic sleeves.<br>
><br>
> For example, it would seem that cell "suicide"<br>
> is a lot more common than previously thought.<br>
> If a cell determines that it has been overwhelmed<br>
> by forces that it cannot control, and this is<br>
> a threat that can overwhelm other cells, as well,<br>
> it will commit suicide in an attempt to stop a<br>
> pathogen from spreading.  Ditto for individual<br>
> plants and animals; the survival of the species<br>
> is more important than the survival of the<br>
> individual.</p>
<p dir="ltr">Expirations and death signals have been discussed in the past on the various crypto lists. No broad concensus yet, but I favor predefined expiration dates in each and every software component which only can be updated in a signed software update. And to decrease the risk of broken signature algorithms, after a second expiration date (?) it can't be updated remotely, only in-person. </p>
<p dir="ltr">Also, I advocate grateful degradation where possible. An expiration should where possible only take out networking and other untrusted interfaces. Where the functionality needs networking to be meaningful or safe, that too would have to be disabled. A smart fridge becomes just a fridge, a traffic light becomes a brick.</p>
<p dir="ltr">Components that relies on different security assumptions doesn't need to all go offline when only a few has their assumptions broken. Traffic lights for example only need authenticated commands (hash based signatures should last), no secrecy (perhaps the particular block cipher mode in use breaks), so only the traffic camera on that same pole goes offline.</p>
<p dir="ltr">> We now build *distributed* power supplies<br>
> into all of our electronic components,<br>
> because it's far more robust than attempting<br>
> to guarantee a sufficiently smooth source of<br>
> power from the higher-level subsystem.  We<br>
> didn't do this out of a lack of trust in<br>
> power supplies, but perhaps we should, as<br>
> power supplies can be maliciously manipulated<br>
> to cause glitches which can be exploited.</p>
<p dir="ltr">[...] </p>
<p dir="ltr">> Another inspiration from biology: embrace<br>
> randomness.  We've gone to every conceivable<br>
> effort to eliminate randomness from our<br>
> electronic systems, yet every IoT device<br>
> *requires* randomness in order to properly<br>
> generate the random crypto *keys* it will<br>
> need in order to communicate with other<br>
> components *securely*.</p>
<p dir="ltr">My currently favored IoT architecture is an electrically segmented design. Based on the previous ideas of trusted electrical paths and a necessity because of  all the security bugs in all of the more advanced CPUs. </p>
<p dir="ltr">First you create a trusted (trustworthy!) controller segment with the minimal amount of code and circuitry it needs to handle the I/O for all of a device's local sensitive inputs and outputs. Sensitive is defined as anything that can cause harm either by accident or malice. Microphones, cameras, radios, engines, safety mechanisms, etc. This controller provides an optical I/O gate to the computing segment (no electrical glitching), together with a minimal carefully defined API. </p>
<p dir="ltr">This controller segment can have multiple groups of electrical paths for I/O - what it is directly responsible for is connected straight to the controller IC:s (like an engine).  However, for non-controlling intelligence-supporting connections (such as sensors that feed the computing segment with data) there could be direct low-latency lines to the computing segment although with switches that allow the controller segment to electrically disconnect them. </p>
<p dir="ltr">Then there's the computing segment. It has all the intelligence, but it needs permission from the controller segment to do anything (it is an electrical island, the controller is its only bridge). Even for networking, as you might have noticed - the controller segment acts as a proxy for it and can electrically cut the connection. If the controller segment says it's expiration date has passed, then it goes offline - but up until then the computing segment can download and pass on signed firmware updates with extended expiration dates, if one is available.</p>
<p dir="ltr">For as long as the controller accepts commands, the computing segment is free to send any command over the API which the API offers, and the controller will happily comply (the controller may have safety limitations programmed in). </p>
<p dir="ltr">Crypto operations should only happen on circuitry and with code which you can with reasonable certainty assure won't have sidechannels. Either with dedicated crypto acceleration chips or on well understood microcontrollers with safe crypto code adapted for the chip. </p>
<p dir="ltr">Also, for death signals to be effective, the devices issuing them to their local networks should know what exactly is running in there (for efficiency, so you don't need to mirror every such signal ever issued, daily).</p>
<p dir="ltr">To do that and preserve privacy, it would be easier if we had a setup like PHB's Mesh concept where each user has their own master keys and there's a hierarchy between a user's devices, where you could for example have a secure home server (which I'm advocating) which all your devices reports in to and declares their status to (including running software, configurations, etc). The home server would benefit too from the segmented design, with one powerful computing part and one dedicated to security functions. </p>
<p dir="ltr">This home server would then be responsible for polling for security flags and issue death signals when necessary to devices under that user's control. It would also check for software updates and may very well download and cache them while the devices they're for are powered off or otherwise busty. </p>
<p dir="ltr">If the IoT devices at least have a secure connection to the home server, there might be an option to issue a command to bypass the expiration date by making the home server an inspecting proxy / DPI firewall on its external API, by telling the server exactly how to detect and filter malicious commands so that only benign commands will reach the device. This way we can also use software to rewrite commands (when possible) for the IoT device when the old API version gets deprecated and a new one is put in use, but there's no corresponding firmware update issued. </p>
<p dir="ltr">Any questions, suggestions, criticism? </p>