Re: [perpass] privacy implications of UUIDs for IoT devices

["Christian Huitema" <[e-mail]>]

On Friday, October 7, 2016 8:11 AM, Michael Richardson wrote:

> Christian Huitema <[e-mail]> wrote:
>>> I'd love to find a way to send the identifier only to an authorized
>>> operator,
>>> which is resistant to an active MITM, given that the new device (the
>>> pledge)
>>> doesn't know who the authorized operator is yet.
>
>> We are looking at that in the pairing draft in DNSSD
>> (https://tools.ietf.org/html/draft-kaiser-dnssd-pairing-00). The
hypothesis
>> is that the two paired devices can display a short authentication
>
> This might be fine for larger devices with displays, but it's a fail
> everywhere else.  Even in ANIMA, one could have a $300K BFR being
deployed,
> but it doesn't have a display or a person to read the display.
> But, does this device need privacy?
> But, the same system ideally bootstraps home routers, which at $39.95,
still
> don't have a display or a competent human to read the display.

You need some signal -- you cannot build trust out of zero knowledge and
zero signal. 

This is not a new problem -- I am copying Daniel, who studied all that in
great detail for his PhD. Over time, we have seen two solutions emerge for
device pairing. Visual comparison of "short authentication strings" is
arguably the best compromise between security and usability. It is widely
used when the devices can display something, e.g. when pairing smart phones,
tablets, PC and cars. The next most used solution is "push buttons". Push
buttons at the same time on both devices, and accept the messages exchanged
during that short time interval. If there is no MITM at that time, you are
good, but you have no way to know that. 

Many other solutions have been tried. One of them is to burn some kind of
key or code in one of the devices, document it on a tag, and use it on the
other device to verify the exchange. It may work for big expensive devices,
but it is a real pain for inexpensive devices because it introduces
additional steps in the manufacturing process. Besides, it requires that the
user reads and enters a long code, and that fails most usability tests.

Besides that, there are solutions that attempt to use alternative channels.
People have demonstrated pairing with the help of ultrasound, but that never
caught. The "synchronized blinking lights" are probably the cutest solution
from the literature. It is basically the same as short authentication
strings, but with no display, just one LED on each device. Instead of
displaying a hash on a screen, you use the hash to determine the pseudo
random blinking pattern of the two lights. If they blink in unison, the user
is assured that there was no MITM. Really cute, but has not quite caught on
yet.

As for the question whether devices need privacy, clearly it depends. My gut
feeling is that mobile devices do. Portable devices, most certainly do.

>> e.g. 6-7 digits. Given that, we can establish a TLS connection without
prior
>> credentials between the two parties, with a probability 99.9999% that

> Such as was done with the STU-III phone...

>> There is another trick, used in the privacy extensions to DNS-SD
>> (https://tools.ietf.org/html/draft-huitema-dnssd-privacy-02). Use TLS
PSK,
>> or better yet TLS/ECDH/PSK. Instead of PSK ID, send a puzzle that can
only
>> be solved by parties knowing the PSK, e.g. nonce + hash (nonce, PSK).
That
>> guarantees connection without MITM, and also without disclosure of the
>> identities to third parties. Problem, it scales as O(number of PSK) known
by
>> the server. We could probably devse an extension of that using public key
>> technology.
>
> How does the responding end know which PSK to try?
> I guess that's why it scales O(number of devices), because the responder
has
> to try *all* of the PSK it knows?  Wow.

BT-LE uses the same pattern. It works, as long as the number of PSK is not
too large. In our draft, we proposed a trick to reduce the server load. Use
a coarse clock as the nonce, e.g. the current time rounded to the nearest 10
minutes. This ensures that the server only has to compute the possible
hash(nonce, PSK) once every 10 minutes. It also defeats the potential DOS
attack in which a botnet bombs the server with connection requests and
forces lots of computations. But clearly there a limits. Would probably be
OK for a few hundred PSK, maybe a few thousands, but after that it breaks. 

> With public key technology, one could sign something, send the signature,
and
> let the responder try all the public keys it knows?  Basically, just omit
the
> Certificate in the handshake.

It is actually very hard to protect the servers using public key technology
alone. The public key is not expected to be secret. If the attackers know
the public key, they can probe for the presence of a server by attempting a
connection. 

What might work is a combination of public key and PSK. Use the known public
key of the server to encode the PSK ID, and then add a proof that the client
sending the message owns the PSK. Third parties cannot deduce the client ID
or the server ID from the initial message, only the server can decrypt its
own public key and identify the client, and everything after that initial
message will be encrypted. You do have to include a nonce in the initial
message to prevent replay attacks, but it could work.

-- Christian Huitema