[Freedombox-discuss] secure UUIDs

[Jonas Smedegaard]

Quoting Daniel Kahn Gillmor (2013-07-22 00:26:02)
> The subject of this thread is "secure UUIDs" -- but i take it from the 
> content that the only concern is about leaking the system's MAC 
> addresses via a generated UUID.

No, I suspect that "secure UUIDs" need care at more/different places 
than frequently changing MAC address:

For someone interested in avoiding tracking, I assume it is important 
that externally exposed UUIDs contain no device-specific parts.


We had a thread some time ago about quality of randomness and PRNGs.  
The text I referenced also mentions that UUID generators vary in their 
source and use of randomness.  But perhaps I am mistaken and that only 
affects risk of collision - that strong randomness only really affects 
security when related to long-lasting key material (like initially 
generating a PGP key or the private part for a cert)?


Also, it seemed that the Data::UUID implementation (i.e. the one not yet 
in Debian) instead of MAC address uses a hash of other host-specific 
data, which to me sounds like it is still usable to trach a device (and 
survives MAC-changing!).


Am Iperhaps silly here, that avoiding tracking implies avoiding UUIDs 
altogether? Seems to me that e.g. torrents need to be uniquely 
identifiable yet unable to identify its originating host!

(specifically, torrent tools probably take good care to avoid tracking - 
mentioned just as a _kind_ of usecase involving both "universally unique 
identifier" and need for tracking avoidance.)


> there are many other ways that a system can "leak" a MAC address, 
> including simply talking to other machines on the local network 
> segment (of course),

Yes.  same-net devices need special concern, beyond what is needed for 
communication with hosts on other networks (which is the main goal of 
FreedomBox as I see it).


> and using standard IPv6 address allocation schemes (without the 
> "privacy extensions" -- see "privext" in interfaces(5) or read 
> http://tools.ietf.org/html/rfc4951).

I have little knowledge (and no experience yet) with IPv6, but such 
"privacy extensions" sounds pretty obviously something that FredomBox 
would want always enabled when using IPv6.


> While i think it would be great if someone wanted to make sure that 
> the default UUID generation in the toolchain we use doesn't leak the 
> MAC address, i don't think that's going to solve the "mac address 
> leak" problem.  Seems like if you want to solve that problem at a 
> deeper level, you should regularly change the mac address of your 
> machine.
> 
> Maybe the work that tails folks are doing would be useful here: 
> https://tails.boum.org/blueprint/macchanger/

For those caring about that, it probably is also of interest to check if 
correct that Data::UUID uses _other_ device-specific data than MAC for 
producing UUIDs - and if other UUID generators do similar.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20130722/1d5d270b/attachment.sig>