Entwicklertools · UUID Generator
Version 1 UUIDs können Ihre MAC-Adresse und Erstellungszeit preisgeben
· Warum es wichtig ist
UUID Kryptographie Browser-APIs
Ein zeitbasierter UUID bettet einen 60-Bit-Zeitstempel und eine 48-Bit-Knotenkennung ein, bei der es sich häufig um eine echte Netzwerkkartenadresse handelt. Dieser Beitrag zeigt, was ein Außenstehender daraus ablesen kann und warum die Zufallsgenerierung das Problem vermeidet.
Die Kennung, die Ihrem Laptop den Namen gibt – warum eine ID in einem exportierten Dokument mehr als eine ID sein kann
Eine Version 1 UUID wird aus einem Zeitstempel, einer MAC-Adresse und einem Taktsequenzwert erstellt. Der 60-Bit-Zeitstempel stellt die Anzahl der 100-Nanosekundenintervalle seit dem 15 Oktober 1582 dar, dem Datum der Gregorianischen Kalenderreform. Das 48-Bit-Knotenfeld enthält traditionell die IEEE-802-MAC-Adresse der Netzwerkschnittstelle, die UUID generiert hat. Wenn Sie ein Dokument exportieren, ein Tool ausführen oder eine Datei speichern, die eine Version 1 UUID einbettet, kann jeder, der diese UUID später entschlüsselt, lesen, wann es erstellt wurde und, wenn das Knotenfeld eine echte MAC-Adresse ist, von welchem Computer es erstellt wurde. Diese Informationen dringen stillschweigend aus einem scheinbar undurchsichtigen Identifikator durch.
Anatomie eines v1 UUID – die Zeitstempelfelder, die Taktsequenz und das Knotenfeld und wo sich jedes in den 36-Zeichen befindet
Das Informationsleck ist subtil, aber folgenreich für Datenschutz und Namensnennung. Wenn Sie mit einem Co-Autor an einem Dokument zusammenarbeiten und die MAC-Adresse Ihrer Netzwerkkarte in den eingebetteten v1-UUIDs enthalten ist, erfährt ein Beobachter, welche Hardware an einer bestimmten Institution oder einem bestimmten Standort verwendet wird. Wenn Sie ein Dokument zu einem bestimmten Zeitpunkt exportieren, ist der Zeitstempel in jeder Version 1 UUID begrenzt, wann die Arbeit stattgefunden hat. Ein Autor, der versucht, seine Pseudonymität aufrechtzuerhalten, kann deanonymisiert werden, indem der Zeitstempel UUID mit bekannten Veröffentlichungsdaten oder Dokumenterstellungsereignissen korreliert wird. Die Bezeichner erscheinen harmlos, weil sie als undurchsichtige 36-Zeichenfolgen formatiert sind, aber sie sind überhaupt nicht undurchsichtig für jeden, der das v1-Format kennt und sie entschlüsseln möchte.
Was ein Beobachter erfährt – wann der Datensatz erstellt wurde und, wenn es sich bei dem Knoten um eine Hardwareadresse handelt, welche Maschine oder welcher Anbieter ihn erstellt hat
Die Anatomie eines v1 UUID verdeutlicht, was extrahiert werden kann, da die Struktur deterministisch und öffentlich dokumentiert ist. RFC 9562 definiert das Layout: 32 Bits für time_low, 16 Bits für time_mid, 4 Bits für die auf 1 gesetzte Version, 12 Bits für time_high, 2 Bits für Variante, 14 Bits für clock_seq und 48 Bits für den Knoten. Die Zeitfelder umfassen insgesamt 60 Bits, die bei Kombination und Interpretation als 100-Nanosekunden-Intervalle seit 1582 den genauen Erstellungszeitpunkt auf 100 Nanosekunden genau ergeben. Das 48-Bit-Knotenfeld enthält normalerweise die MAC-Adresse als 48-Bit-Ganzzahl. Die Dekodierung ist deterministisch: Lesen Sie die Bytes, maskieren und verschieben Sie die Felder und interpretieren Sie die Werte. Es ist keine Kryptographie erforderlich; Die Struktur UUID macht die Codierung vollständig transparent und umkehrbar.
Eine warnende Geschichte – wie in Dokumenten eingebettete Identifikatoren zur Rückverfolgung der Urheberschaft verwendet wurden, ohne Spekulationen beschrieben
RFC 9562 erkennt den Datenschutzverlauf an und empfiehlt Version 1 für neue Anwendungen, da die Kosten die Vorteile überwiegen. Die Spezifikation umfasst zufällige V4- und zeitgesteuerte V4-Alternativen mit dokumentierten Datenschutzaspekten. Version 1 wird aus Gründen der Abwärtskompatibilität mit bereitgestellten Systemen beibehalten, neuer Code sollte jedoch keine v1-UUIDs ohne sorgfältige Sicherheitsprüfung und explizite Begründung für die Offenlegung generieren. Die Sicherheitslücke war kein Versehen; Dies war eine bewusste Designentscheidung in den 1980er Jahren, als Datenschutzlecks kein Hauptanliegen waren und die Nachverfolgung ein akzeptables Merkmal für die Identifizierung verteilter Systeme war.
Funktioniertes Beispiel – manuelles Dekodieren eines Beispiels v1 UUID in seine Zeitstempel- und Knotenfelder
Die Zeitleiste ist wichtig für das Verständnis der Gefährdung, da ein v1 UUID in einem in 1998 erstellten Dokument einen Zeitstempel enthält, der die 1998-Ärazeit codiert, was für die Forensik nützlich ist, aber das Problem selbst darstellt. Wenn Sie historische Dokumente mit UUIDs der Version 1 haben und diese später teilen, bleiben die Zeitstempel bestehen. Sie können die historische Tatsache, dass zu einem bestimmten Zeitpunkt ein UUID generiert wurde, nicht rückwirkend entfernen; Sie können nur die Generierung neuer v1-UUIDs stoppen. Einige Anwendungen versuchten, den Verlust der MAC-Adresse zu mildern, indem sie den echten MAC durch ein zufälliges Pseudonym ersetzten, der Zeitstempel blieb jedoch vollständig lesbar und dekodierbar.
Was sich in v4 und v7 ändert – zufällige UUIDs enthalten keine Maschinendaten; v7 zeigt immer noch die Erstellungszeit an, was akzeptabel sein kann oder auch nicht
Ein ausgearbeitetes Beispiel zeigt die Dekodierung in der Praxis unter Verwendung von RFC-Beispielvektoren 9562. Nehmen Sie ein v1 UUID wie f81d4fae-7dec-11d0-a765-00a0c91e6bf6 aus der Spezifikation. Die Bytes in der Reihenfolge sind f81d4fae 7dec 11d0 a765 00a0c91e6bf6. Das Versionsfeld befindet sich in der dritten Gruppe: 11d0 im Hexadezimalformat ist 0001 0001 1101 0000 im Binärformat. Die ersten 4-Bits sind 0001, was der Version 1 entspricht. Der Zeitstempel ist auf die erste, zweite und einen Teil der dritten Gruppe aufgeteilt: time_low ist f81d4fae im Dezimalformat 4170404526, time_mid ist 7dez im Dezimalformat 32236, time_high ist 1d0 aus der dritten Gruppe nach dem Entfernen des Versionsnibbles im Dezimalformat 464. Kombiniert man diese zu einem 60-Bit-Wert, erhält man eine Zahl, die 100-Nanosekundenintervalle seit 1582 darstellt.
Was dies nicht abdeckt – die Option für zufällige Knoten, die einige v1-Implementierungen bieten, die das Zeitstempelleck abschwächt, aber nicht beseitigt
Das Knotenfeld in der vierten und fünften Gruppe ist a765 00a0c91e6bf6, das Maschineninformationen kodiert, wenn Bit 0 Authentizität angibt. Wenn das niedrigstwertige Bit des ersten Oktetts des Knotenfelds Null ist, zeigt es eine echte IEEE-Adresse an; Wenn es auf eins gesetzt ist, gibt es einen pseudozufälligen Wert an, der aus Datenschutzgründen generiert wird. In diesem Beispiel ist a765 im Hexadezimalformat 10100111 01100101 im Binärformat; Das niedrigstwertige Bit ist 1, es handelt sich also um einen zufälligen Pseudoknoten und nicht um einen echten MAC. Ältere Implementierungen speicherten jedoch manchmal echte MAC-Adressen direkt, und wenn dies der Fall war, dekodiert das 48-Bit-Knotenfeld in eine Netzwerkkarten-ID. IEEE unterhält ein Register der MAC-Präfixe; Wenn man weiß, dass eine Netzwerkkarte mit einem bestimmten Präfix beginnt, kann man den Hersteller und möglicherweise das Modell des verwendeten Computers eingrenzen.
Takeaway: Wissen Sie, was Ihre IDs preisgeben – der ToolAcre-Generator bezieht jede Kennung aus dem CSPRNG, sodass weder MAC-Adresse noch Zeitstempel verloren gehen können
RFC 9562 Version 4 und höher vermeiden dieses Leck bewusst, indem sie nur Zufallsdaten anstelle verschlüsselter Informationen verwenden. Eine Version 4 UUID besteht aus 122 Bits kryptografisch zufälliger Daten mit 4 Bits für das Versionsfeld und 2 Bits für das Variantenfeld. Das Auslesen der Bits ergibt nichts, außer dass UUID gültig ist; Es gibt keinen Zeitstempel zum Dekodieren und keine Maschinendaten zum Extrahieren. Version 7 enthält einen Zeitstempel zum Sortieren von Vorteilen, aber dieser Zeitstempel ist von einem in der Unix-Epoche bekannten und standardisierten Wert abgeleitet und nicht von dem obskuren 1582-basierten Wert, und die Spezifikation dokumentiert ausdrücklich, dass Zeitinformationen in der Kennung vorhanden sind. Die Datenschutzeigenschaften unterscheiden sich grundlegend zwischen den Versionen.