Re: [arch-d] Proposed IAB program on Wholistic Human-Oriented Discussions on Identity Systems (WHODIS)

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Aug 20, 2023 at 4:27 PM Christian Huitema <[e-mail]>
wrote:

>
>
> On 8/20/2023 12:39 PM, Phillip Hallam-Baker wrote:
> > On Sun, Aug 20, 2023 at 12:42 AM Toerless Eckert <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     As long as we keep e.g.: corporate naming schemes such as
> >     eckert-<whatever>
> >     for all equipment assigned to me at some employer, i am sure that the
> >     trackers will be happy to have us develop hardly tracable
> user-identity
> >     for us as people.
> >
> >     Translation: tongue in cheek example for how device identity/naming
> >     may undermine
> >     user identity, and that i fear such outcome will be more likely if
> >     we ignore it
> >     in the process we're about to engage in.
> >
> >
> > That strikes me as an anti-pattern for the reasons you suggest.
>
> Many devices have an identifier that is very hard to change, for example
> MAC addresses, the VIN for cars or the IMEI of phones. Yet these devices
> have strong de facto linkage to the people who use them. If we want hard
> to trace identity for people, we have to make the device identity either
> very hard to access or very easy to change.


MAC addresses used to be hard to change until it became easy and then was
made hard again.

My first residential gateway had a fixed MAC, the next 6 made it trivial to
clone, then DOCSIS came along.

One of the things that came out of the IETF privacy worksop in the wake of
the PRSIM breach is that we managed to sufficiently convince the IEEE folk
that if they wouldn't do switching WiFi MAC addresses, maybe we would.

On cars, the big problem is actually the tire pressure monitors which are
wireless and use a fixed ID. It is pretty easy to make use of randomized
identifiers that can only be used by the relying party.

The way to fix this is with a shared key that is known to the car and the
pressure monitor. This can easily be provisioned by a QR code exchange with
the activation code being printed on the package the monitor comes in.

To send a message communicating its unique identifier ID and current status
Status, the device generates a random nonce n and sends the message  {
nonce, E (ID + Status, k) } where E is OCB encryption mode.

OK so this means that the car has to decrypt every message from every
device sending tire pressure readings. But that isn't much of a problem.
The overhead of OCB is probably very much less than the overhead of
decoding the radio messages.

Back in 1995, using encrypted IDs was wildly impractical, now it can be
routine. The auto industry needs to get a clue and standardize on a small
number of standard VLSI components anyway. The cost of standardizing on a
32bit part is probably negligible at this stage in the game. But even 16
bit parts can do the job unless hobbled by 1970s assumptions that 32
bytes of memory are enough