Outils de développement · Générateur UUID
Version 1 Les UUID peuvent divulguer votre adresse MAC et l'heure de création
· Pourquoi c'est important
uuid cryptographie API du navigateur
Un UUID basé sur le temps intègre un horodatage 60 bits et un identifiant de nœud 48 bits qui est souvent une véritable adresse de carte réseau. Cet article montre ce qu'un étranger peut en lire et pourquoi la génération aléatoire évite le problème.
L'identifiant qui nomme votre ordinateur portable : pourquoi un identifiant dans un document exporté peut être plus qu'un identifiant
Une version 1 UUID est construite à partir d'un horodatage, d'une adresse MAC et d'une valeur de séquence d'horloge. L'horodatage 60 bits représente le nombre d'intervalles de 100 nanosecondes depuis le 15 octobre 1582, date de la réforme du calendrier grégorien. Le champ de nœud 48 bits contient traditionnellement l'adresse MAC IEEE 802 de l'interface réseau qui a généré le UUID. Lorsque vous exportez un document, exécutez un outil ou enregistrez un fichier qui intègre une version 1 UUID, toute personne qui décode ultérieurement cette UUID peut lire quand il a été créé et, si le champ de nœud est une véritable adresse MAC, quelle machine l'a créé. Ces informations fuient silencieusement à partir de ce qui semble être un identifiant opaque.
Anatomie d'un v1 UUID — les champs d'horodatage, la séquence d'horloge et le champ de nœud, et où chacun se trouve dans les caractères 36
La fuite d'informations est subtile mais lourde de conséquences en termes de confidentialité et d'attribution. Si vous collaborez avec un co-auteur sur un document et que l'adresse MAC de votre carte réseau se trouve dans les UUID v1 intégrés, un observateur apprend le matériel utilisé dans une institution ou un emplacement particulier. Si vous exportez un document à une heure précise, l'horodatage de chaque v1 UUID limite le moment où le travail a eu lieu. Un auteur essayant de conserver son pseudonymat peut être désanonymisé en corrélant l'horodatage UUID avec des dates de publication connues ou des événements de création de documents. Les identifiants semblent inoffensifs car ils sont formatés sous forme de chaînes de caractères opaques 36, mais ils ne sont pas du tout opaques pour quiconque connaît le format v1 et souhaite les décoder.
Ce qu'un observateur apprend : quand l'enregistrement a été créé et, si le nœud est une adresse matérielle, quelle machine ou quel fournisseur l'a créé
L'anatomie d'un UUID v1 clarifie ce qui peut être extrait car la structure est déterministe et documentée publiquement. La RFC 9562 définit la disposition : 32 bits pour time_low, 16 bits pour time_mid, 4 bits pour la version définie sur 1, 12 bits pour time_high, 2 bits pour la variante, 14 bits pour clock_seq et 48 bits pour le nœud. Les champs de temps comprennent 60 bits au total, qui, lorsqu'ils sont combinés et interprétés comme des intervalles de 100 nanosecondes depuis 1582, donnent l'instant de création exact à 100 nanosecondes près. Le champ de nœud 48-bit contient généralement l'adresse MAC sous la forme d'un entier 48-bit. Le décodage est déterministe : lire les octets, masquer et décaler les champs et interpréter les valeurs. Aucune cryptographie n’est impliquée ; la structure UUID rend l'encodage complètement transparent et réversible.
Un historique de mise en garde – comment les identifiants intégrés dans les documents ont été utilisés pour retracer la paternité, décrit sans spéculation
RFC 9562 reconnaît l'historique de confidentialité et recommande de ne pas utiliser la v1 pour les nouvelles applications, car les coûts dépassent les avantages. La spécification comprend des alternatives aléatoires v4 et v7 ordonnées dans le temps avec des considérations de confidentialité documentées. La version 1 est conservée pour des raisons de compatibilité descendante avec les systèmes déployés, mais le nouveau code ne doit pas générer d'UUID v1 sans un examen de sécurité minutieux et une justification explicite de l'exposition. La vulnérabilité n’était pas un oubli ; il s'agissait d'un choix de conception délibéré dans les années 1980, lorsque les fuites de confidentialité n'étaient pas une préoccupation majeure et que le suivi était une fonctionnalité acceptable pour l'identification des systèmes distribués.
Exemple pratique : décoder manuellement un échantillon v1 UUID dans ses champs d'horodatage et de nœud
La chronologie est importante pour comprendre l'exposition, car une version UUID v1 dans un document créé en 1998 inclut un horodatage codant l'heure 1998, ce qui est utile pour la médecine légale mais constitue le problème lui-même. Si vous disposez de documents historiques avec des UUID v1 et que vous les partagez ultérieurement, les horodatages persistent. Vous ne pouvez pas supprimer rétroactivement le fait historique selon lequel un UUID a été généré à un certain moment ; vous pouvez uniquement arrêter de générer de nouveaux UUID v1. Certaines applications ont tenté d'atténuer la fuite d'adresse MAC en remplaçant le véritable MAC par un pseudonyme aléatoire, mais l'horodatage reste entièrement lisible et décodable.
Ce que les versions 4 et 7 changent : les UUID aléatoires ne contiennent aucune donnée machine ; La v7 révèle toujours l'heure de création, qui peut être acceptable ou non.
Un exemple concret montre le décodage en pratique à l'aide de vecteurs d'exemple RFC 9562. Prenez une v1 UUID comme f81d4fae-7dec-11d0-a765-00a0c91e6bf6 de la spécification. Les octets dans l'ordre sont f81d4fae 7dec 11d0 a765 00a0c91e6bf6. Le champ de version est dans le troisième groupe : 11d0 en hexadécimal est 0001 0001 1101 0000 en binaire. Les premiers 4 bits sont 0001, qui est la version 1. L'horodatage est réparti entre le premier, le deuxième et une partie du troisième groupe : time_low est f81d4fae en décimal 4170404526, time_mid est 7dec en décimal 32236, time_high est 1d0 du troisième groupe après avoir supprimé le quartet de version en décimal 464. Les combiner en une valeur 60 bits donne un nombre représentant les intervalles de 100 nanosecondes depuis 1582.
Ce que cela ne couvre pas : l'option de nœud aléatoire proposée par certaines implémentations v1, qui atténue mais ne supprime pas la fuite d'horodatage
Le champ de nœud dans les quatrième et cinquième groupes est a765 00a0c91e6bf6, qui code les informations de la machine si le bit 0 indique l'authenticité. Si le bit de poids faible du premier octet du champ nœud est nul, cela indique une adresse IEEE réelle ; s'il est défini sur un, il indique une valeur pseudo-aléatoire générée pour la confidentialité. Dans cet exemple, a765 en hexadécimal est 10100111 01100101 en binaire ; le bit le moins significatif est 1, il s'agit donc d'un pseudo-nœud aléatoire, pas d'un vrai MAC. Cependant, les anciennes implémentations stockaient parfois directement les véritables adresses MAC, et si c'était le cas, le champ de nœud 48-bit est décodé en un identifiant de carte réseau. L'IEEE maintient un registre des préfixes MAC ; savoir qu'une carte réseau commence par un certain préfixe restreint le fabricant et potentiellement le modèle d'ordinateur utilisé.
À retenir : sachez ce que révèlent vos identifiants - le générateur ToolAcre extrait chaque identifiant du CSPRNG, il n'y a donc aucune adresse MAC ni horodatage à divulguer
RFC 9562 version 4 et au-delà évitent délibérément cette fuite en utilisant uniquement des données aléatoires plutôt que des informations codées. Une version 4 UUID est constituée de 122 bits de données cryptographiquement aléatoires avec 4 bits pour le champ de version et 2 bits pour le champ de variante. La lecture des bits ne révèle rien sauf que le UUID est valide ; il n'y a pas d'horodatage à décoder, ni de données machine à extraire. La version 7 inclut un horodatage pour les avantages de tri, mais cet horodatage est dérivé de l'époque Unix familière et standardisée plutôt que de l'obscure valeur basée sur 1582, et la spécification documente explicitement que les informations temporelles sont présentes dans l'identifiant. Les propriétés de confidentialité diffèrent fondamentalement d’une version à l’autre.