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

[Peter Gutmann]

Allen <allenpmd at gmail.com> writes:

>> the TLS list is all web browsers and servers...
>> 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 have future application in this area, so I'm wondering if ssh might be
>suitable for an embedded device to use as a secure pipe?

TLS is the universal substrate.  There is some use of SSH, but only where you
need to secure CLI access.  Even then, you need some special-case handling to
deal with the two main uses of SSH, secure telnet vs. VPN with everything
including an RPC mechanism for the Posix filesystem API (a.k.a. SFTP).  If all
you want is secure telnet then you can drop something like 90-95% of the
complexity of the protocol (after the initial handshake), as well as a lot of
the complexity in the handshake itself.  I did a draft profile of this some
years ago:

  The widespread adoption of SSH has seen the emergence of numerous SSH
  implementations, but also numerous interoperability problems among many of
  the non-mainstream versions.  This problem arises because the complexity and
  in places ambiguity of the specification makes it possible to create
  specification-compliant but non-interoperable implementations, and is
  exacerbated by the fact that in many cases where SSH is used, for example
  for the control interface of an embedded device or a Windows file transfer
  facility, the developers are required to implement a specification designed
  to provide a full-blown Unix VPN solution even though in their case they'll
  never use the majority of its facilities.

  This document describes a simplified profile of SSH that provides a standard
  minimal feature set for use in applications that just require a basic no-
  frills secure channel from A to B, building on a decade of SSH
  implementation experience to avoid known problem areas in the SSH protocol.
  As a side-effect this minimal profile reduces the large attack surface of
  SSH to a more manageable level by eliminating much of the complexity in the
  protocol.

but never went further with it apart from implementing it in my code and
making it the default.  Virtually no-one ever enables the non-default (i.e.
full SSH) behaviour, so it's minimalist and safe-by-default.

Which one to use depends on whether you control the client and server, if it's
both then you can probably go with whatever form of SSH you like, but
otherwise TLS is the universal substrate.

Peter.