Italiano

Strumenti per sviluppatori · Generatore UUID

Gli UUID della versione 1 possono divulgare il tuo indirizzo MAC e l'ora di creazione

· Perché è importante

uuid crittografia API del browser

Suddivisione di una struttura UUIDv1 che mostra i campi timestamp e i bit dell'indirizzo MAC
Illustrazione vettoriale originale ToolAcre

Un UUID basato sul tempo incorpora un timestamp a 60 bit e un identificatore di nodo a 48 bit che spesso è un indirizzo reale della scheda di rete. Questo post mostra cosa un estraneo può leggere da uno e perché la generazione casuale evita il problema.

L'identificatore che assegna il nome al tuo laptop: perché un ID in un documento esportato può essere più di un ID

Una versione 1 UUID è costruita da un timestamp, un indirizzo MAC e un valore di sequenza orologio. Il timestamp 60-bit rappresenta il numero di intervalli di 100-nanosecondi da 15 ottobre 1582, la data della riforma del calendario gregoriano. Il campo del nodo 48-bit contiene tradizionalmente l'indirizzo IEEE 802 MAC dell'interfaccia di rete che ha generato UUID. Quando esporti un documento, esegui uno strumento o salvi un file che incorpora una versione 1 UUID, chiunque successivamente decodifichi quel UUID può leggere quando è stato creato e, se il campo del nodo è un indirizzo MAC reale, quale macchina lo ha creato. Queste informazioni trapelano silenziosamente da quello che sembra essere un identificatore opaco.

Anatomia di un UUID v1: i campi timestamp, la sequenza dell'orologio e il campo del nodo e la posizione di ciascuno nei caratteri 36

La fuga di informazioni è subdola ma consequenziale per la privacy e l’attribuzione. Se collabori con un coautore su un documento e l'indirizzo MAC della tua scheda di rete è negli UUID v1 incorporati, un osservatore apprende l'hardware in uso in una particolare istituzione o luogo. Se esporti un documento in un momento specifico, il timestamp in ogni v1 UUID delimita il momento in cui si è verificato il lavoro. Un autore che tenta di mantenere lo pseudonimo può essere deanonimato correlando il timestamp UUID con date di pubblicazione note o eventi di creazione del documento. Gli identificatori appaiono innocui perché sono formattati come stringhe di caratteri 36 opache, ma non sono affatto opachi per chiunque conosca il formato v1 e si preoccupi di decodificarli.

Cosa apprende un osservatore: quando è stato creato il record e, se il nodo è un indirizzo hardware, quale macchina o fornitore lo ha creato

L'anatomia di un v1 UUID chiarisce cosa può essere estratto perché la struttura è deterministica e documentata pubblicamente. RFC 9562 definisce il layout: 32 bits per time_low, 16 bits per time_mid, 4 bits per la versione impostata su 1, 12 bits per time_high, 2 bits per variante, 14 bits per clock_seq e 48 bits per node. I campi temporali comprendono 60 bits totale, che se combinati e interpretati come intervalli di 100-nanosecondi da 1582 producono l'esatto istante di creazione entro 100 nanosecondi. Il campo del nodo 48bit solitamente contiene l'indirizzo MAC come numero intero 48bit. La decodifica è deterministica: legge i byte, maschera e sposta i campi e interpreta i valori. Non è coinvolta alcuna crittografia; la struttura UUID rende la codifica completamente trasparente e reversibile.

Una storia cautelativa: come gli identificatori incorporati nei documenti sono stati utilizzati per tracciare la paternità, descritti senza speculazioni

RFC 9562 riconosce la cronologia della privacy e sconsiglia la versione v1 per le nuove applicazioni perché i costi superano i vantaggi. La specifica include alternative v4 casuali e v7 in ordine cronologico con considerazioni sulla privacy documentate. La versione 1 viene mantenuta per compatibilità con le versioni precedenti con i sistemi distribuiti, ma il nuovo codice non dovrebbe generare UUID v1 senza un'attenta revisione della sicurezza e una giustificazione esplicita per l'esposizione. La vulnerabilità non era una svista; si è trattato di una scelta progettuale deliberata negli anni '80, quando le fughe di privacy non erano le preoccupazioni principali e il tracciamento era una caratteristica accettabile per l'identificazione del sistema distribuito.

Esempio realizzato: decodifica manuale di un campione v1 UUID nei relativi campi timestamp e nodo

La sequenza temporale è importante per comprendere l'esposizione perché una v1 UUID in un documento creato in 1998 include un timestamp che codifica l'ora 1998-era, che è utile per la medicina legale ma è il problema stesso. Se disponi di documenti storici con UUID v1 e li condividi successivamente, i timestamp persistono. Non è possibile rimuovere retroattivamente il fatto storico che un UUID è stato generato in un determinato momento; puoi solo interrompere la generazione di nuovi UUID v1. Alcune applicazioni hanno tentato di mitigare la perdita dell'indirizzo MAC sostituendo il vero MAC con uno pseudonimo casuale, ma il timestamp rimane completamente leggibile e decodificabile.

Cosa cambiano le versioni v4 e v7: gli UUID casuali non trasportano dati macchina; v7 rivela ancora l'ora di creazione, che può essere accettabile o meno

Un esempio pratico mostra la decodifica in pratica utilizzando i vettori di esempio RFC 9562. Prendi un v1 UUID come f81d4fae-7dec-11d0-a765-00a0c91e6bf6 dalle specifiche. I byte in ordine sono f81d4fae 7dec 11d0 a765 00a0c91e6bf6. Il campo della versione si trova nel terzo gruppo: 11d0 in esadecimale è 0001 0001 1101 0000 in binario. I primi 4 bits sono 0001, che è la versione 1. Il timestamp è suddiviso nel primo, secondo e parte del terzo gruppo: time_low è f81d4fae in decimale 4170404526, time_mid è 7dec in decimale 32236, time_high è 1d0 dal terzo gruppo dopo aver rimosso il nibble della versione in decimale 464. Combinandoli in un valore 60bit si ottiene un numero che rappresenta intervalli di 100-nanosecondi da 1582.

Cosa non copre: l'opzione del nodo randomizzato offerta da alcune implementazioni v1, che mitiga ma non rimuove la perdita di timestamp

Il campo del nodo nel quarto e quinto gruppo è a765 00a0c91e6bf6, che codifica le informazioni sulla macchina se il bit 0 indica l'autenticità. Se il bit meno significativo del primo ottetto del campo nodo è zero, indica un indirizzo reale IEEE; se impostato a uno indica un valore pseudocasuale generato per la privacy. In questo esempio, a765 in formato esadecimale è 10100111 01100101 in binario; il bit meno significativo è 1, quindi questo è uno pseudonodo casuale, non un vero MAC. Tuttavia, le implementazioni precedenti a volte memorizzavano direttamente gli indirizzi MAC reali e, in tal caso, il campo del nodo 48-bit decodifica in un identificatore della scheda di rete. IEEE mantiene un registro dei prefissi MAC; sapere che una scheda di rete inizia con un determinato prefisso restringe il campo del produttore e potenzialmente del modello di computer in uso.

In conclusione: scopri cosa rivelano i tuoi ID: il generatore ToolAcre estrae ogni identificatore da CSPRNG, quindi non c'è nessun indirizzo MAC o timestamp da trapelare

RFC 9562 versione 4 e successive evitano deliberatamente questa perdita utilizzando solo dati casuali anziché informazioni codificate. Una versione 4 UUID è 122 bits di dati crittograficamente casuali con 4 bits per il campo versione e 2 bits per il campo variante. La lettura dei bit non rivela nulla tranne che UUID è valido; non c'è data e ora da decodificare, né dati macchina da estrarre. La versione 7 include un timestamp per l'ordinamento dei vantaggi, ma tale timestamp è derivato dall'epoca Unix familiare e standardizzata anziché dall'oscuro valore basato su 1582 e la specifica documenta esplicitamente che le informazioni temporali sono presenti nell'identificatore. Le proprietà della privacy differiscono sostanzialmente tra le versioni.