Re: [TLS] Consensus Call on MTI Algorithms

[Peter Gutmann <[e-mail]>]

Nico Williams <[e-mail]> writes:

>Sure, that'd be nice (because different manufacturers of IoT devices will
>want to know what to implement as a common denominator).

The IoT environment doesn't work the way some people seem to think it does.
IoT devices can be divided into two classes, those that can't run TLS and
those that can.  The class "those that can't run TLS" is a lot larger than you
think, because a typical target might for example have 15% of an ARM7 TDMI and
18K RAM available, and restrictions like the fact that no operation can tie up
the CPU for more than 2ms before it's killed by the system watchdog.

So for "TLS" on these devices you've got a large class of systems that have to
run some homebrew protocol invented by an embedded systems guy who's read the
first three chapters of Applied Cryptography (this became particularly
problematic when smart meters started to become widespread and regulators
imposed requirements for certificate-based signed messaging and updates onto
CPUs like TI MSP430s, Motorola ColdFires, and ARM Cortex-Ms, some clocked as
high as 16MHz and with as much as 32kB of RAM (for everything, not just the
crypto).  The solution with smart meters was to cut corners as much as
possible in order to make things fit, skipping certificate verification,
assuming hardcoded public keys, and various other measures that are destined
to become entertaining Black Hat or Defcon presentations in the future).

For the other class, those that can run TLS, the reason for running it isn't
to talk to another device running TLS (you use your homebrew protocol for
that), it's so they can be controlled via a web interface.  For these devices
the profile is "whatever we need to implement to talk to a web browser/smart
phone/web control/AJAX/whatever".  That is the entire device profile.  Since
the underlying hardware can't handle this, you get approaches like the ones
I've talked about in the past, 1024-bit keys for everything (perfectly OK for
embedded device security, I've been waiting for the negotiated-ff-dhe draft to
be approved so I can push out one that extends it to specify 1024- and 1280-
bit parameter sets), pre-encoded cert chains memcpy()'d out into TLS streams
(the device has zero PKI functionality because there isn't room), and so on,
just whatever you can get away with and have the other side still talk to you
(I've seen some truly ingenious solutions applied to systems that have to talk
to web browsers but just can't handle the high resource requirements for TLS).

If you want to do an IoT TLS profile (what would have been called an embedded
device TLS profile before IoT became a buzzword) you need to look at how TLS
is used in the embedded world, and for what purposes.  Simply dreaming up
something and calling it an IoT profile won't work, because vendors are
already working with de facto profiles of "whatever we need to do to get
things working".

Peter.