[Cryptography] Internet of things - can we secure it by going simple?

Thierry Moreau thierry.moreau at connotech.com
Fri Jan 6 11:09:43 EST 2017


see below

On 06/01/17 02:21 AM, Ray Dillinger wrote:
> If we put no more software and complexity in these devices than they
> actually need, don't we suppose that they could be made secure?
>
+1

> Web interfaces on these devices only need to be able to understand eight
> or so different HTML tags.  Skip implementing the rest.  A device that

Actually, the embedded web server does not *parse* HTML, except for HTML 
4.1 forms. HTML *generation* is much more simple.

> never executes anything downloaded, ever, can't easily be recruited into
> a botnet. Command lines on these devices (if they expose command lines
> at all) should only understand three or four different commands.  They
> should not even have access to utilities like "ls" and "cat" and "mv"
> and "copy", let alone interpret pipes and things.  I mean, is there an
> explicit reason, for each and every one of those tools, why it's needed
> for device configuration?.  Because device configuration is the only
> thing these command lines exist for.
>

This is what I aimed at when I tailored a Linux distribution using a 
diskless booksize PC as an "open source HSM"
- booting directly into a single embedded web server application with an 
application-specific "script", and a single HTTP/HTML session capability.
- the "console" is then any HTTP client that happened to grab the single 
session at boot time -- no need for HTTPS
- (since it is an HSM application) any critical input comes from a bar 
code reader, and this includes the SHA-256 fingerprint for the script 
variant to be run, it also includes a decryption key for file upload 
when confidentiality is at stake (e.g. in a closed auction decision 
machine) or the SHA-256 fingerprint (e.g. if the HSM signs certificates 
for a central certification authority)
- conversely, any critical output is assisted with a printer for bar 
code pages (the HSM is evanescent) (e.g. a certificate signed in advance 
of its validity period is encrypted before being downloaded from the 
embedded server and the encryption key is printed as a bar code to be 
distributed to whoever controls the certificate release -- used in my 
designs as an obituary/revocation certificate that may be released even 
if the certification authority private key is lost)

Basically, what has to be audited is critical input and output channels 
usage.

There are remaining challenges, some mainly requesting time/effort.

The more significant remaining challenge is that the whole application 
logic now lies on a tiny memory device (read-only boot media); thus how 
do you and I agree about the software integrity.

That's for an HSM. A simpler IoT application might have some 
characteristics, but not all of them.

> If someone breaks into a thermostat and can install shell scripts on it
> - what the hell was a thermostat doing with a command shell capable of
> running scripts?  If someone can use it for a reflector to poke around
> your network - what the hell did a thermostat need with a repertoire of
> utilities like 'mount' and 'rlogin' and whatever else would get used to
> do that?
>
> The complexities of protocol conformance are sometimes beyond the
> capabilities of simple IoT devices, and secure implementations for them
> are, well, no better than secure implementations for other platforms -
> you're still hosed if you haven't got monthly updates.
>
> But the manufacturers of these devices don't DO monthly updates. They
> want to forget about a device as soon as it's sold.  It's not a contract
> or a subscription, it's just inventory.  Their goto model for service or
> updates is "get a new one," whether that's by another sale or a product
> recall or a guarantee fulfillment.
>

For performance warranty, the remote firmware upgrade is almost 
unavoidable. The problem is the recurring operational mishaps (or 
engineering flaws) with firmware integrity protection. Getting our 
customers to improve their internal processes is seldom possible.

> So we need to build devices which need security updates no more often
> than the length of time a typical customer goes before getting a new one.
>
> That's not so difficult as the complex protocols we're using on desktops
> makes it.  These are simple devices and the protocols and capabilities
> they actually need are also very simple.  They could use protocols with
> two moving parts instead of fifty.   And I think elementally simple
> protocols, running on simple single-tasking machines can in fact be
> implemented securely enough not to need updates more than, say, once in
> six years on average.
>
>
>
> 				Bear
>

- Thierry Moreau



More information about the cryptography mailing list