Universally unique identifier

Dans sa représentation textuelle canonique, les 16 octets d'un UUID sont représentés comme 32 chiffres hexadécimaux en minuscules séparés par 4 tirets sous la forme suivante: 123e4567-e89b-12d3-a456-426614174000 ........-....-M...-N...-............

Les 4 bits de M et les bits de 1 à 3 de N déterminent le format de l'UUID.

M représente la version utilisée par l'UUID alors que N représente la variante, dans l'exemple M vaut 1 et N vaut 10.., indiquant un UUID version-1 variant-1, c'est-à-dire un UUID basé sur la date DCE/RFC 4122.

La RFC 4122 Section 3 stipule que les caractères sont affichés en minuscules même si les majuscules sont permises lors d'une saisie.

Les GUIDs de Microsoft sont parfois représentés avec des accolades : {123e4567-e89b-12d3-a456-426652340000}

RFC 4122 définit une Uniform Resource Name (URN) namespace pour les UUIDs. Un UUID représenté comme un URN s'affiche sous la forme suivante: urn:uuid:123e4567-e89b-12d3-a456-426655440000

L'algorithme de génération diffère selon la version. La première version du standard prévoyait de générer l'identifiant avec l'adresse MAC de l'ordinateur et un temps écoulé (en dixièmes de microseconde) depuis une date de référence. L'UUID produite est unique, sous réserve qu'une même adresse MAC ne soit pas utilisée pour plusieurs cartes réseaux et qu'il n'y ait pas deux identifiants produits en moins de 0,1μs.

Cependant, l'utilisation de l'adresse MAC a un effet pervers : donner des informations sur l'ordinateur qui a généré l'identifiant. Des améliorations ont été entreprises et standardisées par la RFC 4122^[4] (puis normalisées ISO). On peut maintenant faire appel à des nombres pseudo-aléatoires (version 4) et à des fonctions de hachage cryptographiques comme MD5 (version 3) ou SHA-1 (version 5) qui permettent de « casser » toute information relative à l'ordinateur qui a produit l'UUID. Le langage Java 5.0 utilise une variante de la génération de type Leach-Salz dont la spécification a expiré. Toutes ces techniques introduisent cependant une incertitude sur l'unicité de l'identifiant (une séquence pseudo-aléatoire peut sortir deux fois le même résultat, et les algorithmes de hachage ne sont pas bijectifs), la probabilité d'unicité dépend alors de la robustesse de l'algorithme.

Enfin la multiplication de techniques concurrentes non standardisées a fragilisé la robustesse de l'UUID dans ses différentes utilisations (c'est ce qui a motivé la rédaction de la RFC en plus du standard OSF).

La version 1 crée un UUID en se basant sur l'adresse MAC et l'horodatage. Il garantit la génération d'un identifiant unique (pour deux systèmes avec des adresses MAC différentes et agissant à plus de 0,1μs d'écart). Il permet également sur la même machine, de générer jusqu'à 10 millions d'UUID uniques par seconde.

L'adresse MAC est codée sur 48 bits. L'horodatage est codé sur 74 bits, avec un "timestamp" de 60 bits, correspondant au nombre de dixièmes de micro-secondes écoulées depuis le 15 Octobre 1582 à minuit (UTC), considérée comme le début du calendrier grégorien, suivi d'un "clockmark" de 14 bits. Certaines versions de l'algorithme de génération assurent l'unicité de plusieurs identifiants produits en parallèle par les valeurs données aux derniers bits du "clockmark".

D'après la RFC 4122^[4] la version 2 est une variante DCE (« Distributed Computing Environment ») qui inclut des UIDs POSIX.

La version 3 est un hash md5 d'un nom (comme une URL ou un OID). L'UUID généré sera toujours égal pour un même nom, il ne contient donc aucun aspect temporal ou aléatoire.

La version 4 génère un UUID totalement aléatoire.

La version 5 est un hash sha1 d'un nom (comme une URL ou un OID). Comme pour la version 3, l'UUID généré sera toujours égal pour un même nom.

La version 6 est identique à la version 1, sauf que tous les bits de temps sont placés dans l'ordre inverse. Cela permettra aux systèmes de trier dans l'ordre de création par UUID, ce qui n'était pas possible avec la version 1.

L'UUIDv7 est l'une des versions de l'UUID qui est basée sur le temps, comme l'UUIDv1.

Les UUID version 7 (UUIDv7) sont conçus pour les clés des bases de données à forte charge et des systèmes distribués.

L'UUIDv7 commence par un horodatage Unix Epoch de 48 bits gros-boutiste avec une granularité d'environ une milliseconde. L'horodatage peut être décalé de n'importe quelle valeur de décalage temporel. Directement après l'horodatage suit le quartet de la version, qui doit avoir une valeur de 7. Les bits de variante doivent être 10xx^[6]. Les 74 bits restants sont des compteurs aléatoires (facultatifs, au moins 12 bits mais pas plus de 42 bits) et aléatoires.

La version 8 de l'UUID fournit un format compatible RFC pour les cas d'utilisation expérimentaux ou spécifiques à un fournisseur.

La version 8 n'a que deux exigences :

• Les bits de variante doivent être 10xx^[6].
• Le quartet de la version doit avoir la valeur 8.

Ces exigences indiquent au système qu'il s'agit d'un UUID de la version 8. Les 122 bits restants sont laissés à l'appréciation du fournisseur. La différence avec la version 4 est que ces 122 bits sont aléatoires, alors que les 122 bits de la version 8 de l'UUID ne le sont pas, car ils suivent des règles spécifiques au fournisseur.

Un GUID (abréviation de l'anglais Globally Unique IDentifier, en français : « identificateur global unique »^[7]) sert habituellement d'identifiant unique pour un composant logiciel, par exemple un plugin. Sa taille est de 16 octets, soit 128 bits (exemple : {3F2504E0-4F89-11D3-9A0C-0305E82C3301}), décomposés en :

• 4 octets ;
• trois groupes de 2 octets ;
• 6 octets.

Ce terme est utilisé à la fois dans le monde Microsoft et dans le monde Unix (voir RFC 4122^[4]). Microsoft utilise le terme de CLSID (de l'anglais class identifier) pour désigner le GUID de la classe d'un objet OLE, et le terme IID (de l'anglais Interface IDentifier) pour les interfaces mises en œuvre par ces classes.

Sous Unix, on utilise le UUID.

Concernant les disques durs, on utilise maintenant les tables de partitionnement GUID, en anglais GUID Partition Table (GPT).

Quatre versions ont été spécifiées par Microsoft :

• version 1 : fondée sur l’horloge de l'ordinateur et l’adresse MAC (avant Windows 2000) ;
• version 2 : réservée (non utilisée en pratique) ;
• version 3 : fondée sur un nom, les différents champs sont produits à partir de ce nom ;
• version 4 : fondée sur des nombres issus d’un générateur de nombres pseudo-aléatoires cryptographique (Windows 2000 et ultérieur).

Sur les 128 bits (dont 4 bits pour la version et 2 pour la variante), seuls 122 sont réellement aléatoires, ce qui représente environ 5 × 10³⁶ combinaisons possibles.

Des GUID sont aussi insérés dans des documents Microsoft Office. Même les flux audio et vidéo dans le codec ASF sont identifiés par un GUID.

Dans le modèle COM (utilisé par ActiveX), les CLSID sont utilisés uniquement pour différencier les classes des objets. Cela veut dire que deux versions d'un composant peuvent avoir exactement le même nom, mais être discernables par leur CLSID. Chacune de ces classes supporte différentes interfaces identifiées chacune par un IID.

La base de registre de Windows contient de nombreux GUID, CLSID et IID.

En particulier, la clé HKEY_CLASSES_ROOT\CLSID (équivalent à HKEY LOCAL MACHINE\SOFTWARE\Classes\CLSID\) contient de très nombreux CLSID.

Certains logiciels espions ajoutent des CLSID. N'étant pas très lisibles, l'opération peut passer inaperçue même pour un utilisateur averti qui connaît le maniement de regedit. Pour donner un exemple de logiciel espion modifiant les CLSID, on peut mentionner : Parent Tools, en juillet 2005 et PC Watch en juin 2005 (exemples indiqués par Symantec) ^{[réf. nécessaire]}.

Dans certaines versions de Windows, les clés de registre HWID (Hardware ID) et MSID (Microsoft ID) servent pour générer un GUID identifiant un ordinateur de façon unique (dans l'arborescence CurrentControlSet de HKEY_LOCAL_MACHINE). Certains logiciels anti-spyware les éliminent.

Dans l'annuaire Active Directory, l'attribut ObjectGUID est le GUID qui sert d'identifiant pour un objet : il ne change jamais, même si l'objet change de nom ou s'il est déplacé.

Dans le jeu vidéo Minecraft, les UUID (identifiants uniques pour chaque joueur) prennent la forme d'un GUID.

Dans l'API Win32, UUIDCreate() est la fonction de base pour créer un GUID. La fonction CoCreateGuid est une fonction qui enrobe UUIDCreate et qui permet de créer un CLSID.

Dans Visual Basic, Guid est un attribut d'un objet Active Directory.

UUIDGEN.EXE est un utilitaire de Microsoft permettant de générer un GUID. Dans le monde Microsoft, il fait partie de Microsoft Exchange Server 2003. Il ne faut pas le confondre avec la commande uuidgen du monde Unix.

GUIDGEN.EXE est un utilitaire de Microsoft permettant lui aussi de générer un GUID. Il est livré avec Visual Studio.

En 1999, l'auteur du ver Melissa a été identifié en partie grâce au champ GUID de documents Microsoft Office qui, à l'époque, contenaient l'adresse MAC. Ce ver exploitait une faiblesse de Word 97. Dans les versions suivantes des logiciels Microsoft, l'algorithme qui génère le GUID a été modifié pour respecter la vie privée des utilisateurs : l'adresse MAC a été retirée.

GUID est aussi le nom d'une balise XML pour RSS (standard de syndication du contenu). Cette balise utilisée par le RSS ne se réfère pas à la norme RFC 4122^[4]. La structure est totalement différente : il contient un texte. En pratique, ce texte correspond à l'URL.

Il existe une balise équivalente dans Atom, un autre standard de syndication du contenu. Cette balise s'appelle ID et contient un URI.

• Request for comments
• Partition de disque dur

• ISO/IEC 9834-8:2008
• generateuuid.net propose un générateur de UUID version 1,3,4,5
• (en) MSDN : La clé de registre CLSID[EN]

• Cet article est partiellement ou en totalité issu de l'article intitulé « Globally unique identifier » (voir la liste des auteurs).

•   Portail de l’informatique
•   Portail de la cryptologie