[Cryptography] Smart electricity meters can be dangerously insecure, warns expert

[Peter Gutmann]

Arnold Reinhold <agr at me.com> writes:

>The problem I see is where does our power engineer go to to get reliable
>advice on a security design? There is so much snake-oil security out there.
>Vendors have their products to sell, right or wrong, government security
>agencies want to protect their offensive capabilities, standards bodies are
>not specialized in computer security and treat it as one more chapter in
>stove-piped specs. Who would you recommend?

This is a serious problem.  When the HTTP/2 spec was being done, a couple of
embedded systems guys commented that it was highly unsuited for use in a
constrained (embedded/SCADA) environment, and could it have a few minor tweaks
(not breaking changes, just small tweaks and options added) to make it usable
for SCADA.  The response from the HTTP/2 designers was "let them eat HTTP
1.1", effectively saying that HTTP/2 was designed for efficient content
delivery by web service providers and nothing else.  So now there's an
explicit fork of HTTP, HTTP4Google and HTTP 1.1 for everyone else.

It's the same with TLS4Google, it's design goal as with HTTP4Google is to more
efficiently serve content from web service providers to consumers.  The total
number of people on the TLS list who represent embedded/SCADA/whatever use of
TLS is... zero.  Zero people.  There are embedded folks who read the list, but
zero who contribute because no-one feels anything would be achieved by it, the
TLS list is all web browsers and servers (not necessarily web servers, also
MTAs, B2B, that sort of thing, but still big iron), people whose sole concern
is to shovel content from A to B at the highest possible rate, no matter how
badly the protocol has to be compromised (look at TLS 1.3 for an extreme
example of this), but no-one who just cares about a straightforward secure
pipe from A to B with a design spec with a 10-20 year lifetime that fits in
with existing deployed devices.

I've been trying to get an LTS profile of TLS 1.x through on behalf of a
number of users in the embedded space, but a typical response, to a comment
about why TLS4Google wasn't going to work in embedded, excerpted so you can
see what the problem is, was "[...] non-starter as web browsers [...] fix the
reasons why web browsers [...] the web browser vendors [...]" (etc).  Use
outside the web doesn't exist, and therefore doesn't have to be accommodated
in any way.

So in response to your question:

>Who would you recommend?

I'd say "there isn't anyone".  Cryptographers publish dinky protocols with all
sorts of fun tricks in them for toy devices in conference papers, but that's
more an exercise in fun protocol design than a real-world spec to work off.
The groups that should be covering this area ignore it, in some cases
explicitly (HTTP4Google), in others implicitly (TLS4Google).  What's left are
industry bodies who work in, and specialise in, high-availability, high-
reliability engineering who are now being asked to do crypto.  It's not
surprising that we get the stuff we've got so far.

That's why I was pleasantly surprised by LoRa, a bunch of guys I've never
heard of before, working in private, came up with a pretty decent design.  If
they ever end up in NZ, I'll buy them dinner.

Peter.