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

[Michael Richardson <[e-mail]>]

Christian Huitema <[e-mail]> wrote:
    >> 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.

I agree; recall how many times semi-technicals have suggested that having source IP
addresses was a privacy mistake, and we should remove them....

    > 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.

Looking forward to a link to read it!

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

I think you are right, but there is a finer distinction to be made:
1) devices with no local identities that may need to be bootstrap'ed.

2) devices with local identities which are trying to join/use a new network.
   (the first time you visit CoffeeShop at corner of Fifth and Broadway)

3) devices with local identities which are re-joining a network they have
   been on before; but may not wish to leave a trace to a) the network
   operator,  b) other observers.

    > 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.

In the bootstrap or CoffeeShop situation, is the Server part of the network?
In that case, how can the client know the public key of the network?

How is this not vulnerable to an active MITM using a different "known public key"?
This doesn't happen today with Wifi because a human either picks "CoffeeShop"
ESSID, or can validate the cert chain to say "CoffeeShop Inc", but a device
can't do this.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-