1,6 milliard, c’est le nombre de PC sous Windows qui embarquent un identifiant baptisé GDID, un numéro attribué à chaque installation de Windows. Il fait beaucoup parler de lui depuis quelques jours : le FBI a exploité cette information pour remonter jusqu’à un membre présumé du groupe de pirates Scattered Spider. L’identifiant GDID peut-il être supprimé ? La réponse est non, et je vous explique pourquoi.

Je suis récemment revenu sur le rôle joué par le GDID dans l’enquête du FBI visant Peter Stokes, un citoyen américano-estonien de 19 ans présenté comme un membre de Scattered Spider. Depuis, la publication de la plainte fédérale de 39 pages a alimenté un débat plus large sur la vie privée des utilisateurs de Windows (une fois de plus). Le dossier documente noir sur blanc un identifiant peu connu et sur lequel Microsoft ne communique quasiment pas : GDID (Global Device Identifier).

Cet identifiant présente la particularité d’être lié à un appareil physique : il est stocké en local sur l’ordinateur et sur les serveurs de Microsoft. Il n’est pas dépendant de votre connexion réseau, n’est pas renouvelé tous les X temps et il reste le même en cas de mise à niveau de Windows. Il suit littéralement la machine Windows tout au long de son cycle de vie. Cela signifie aussi qu’un VPN ne sert en aucun cas à masquer le GDID : si Windows décide de partager cette information avec un tiers, il le fera qu’un VPN soit actif ou non.

Mais alors, à quoi ressemble ce GDID ? Comment peut-on l’afficher ? Peut-on l’effacer ? Peut-on empêcher Windows de le partager avec Microsoft ? Tentons de répondre à ces différentes questions.

À quoi ressemblent le GDID de Windows ?

L’identifiant GDID est stocké sur chaque machine Windows dans le registre, à l’emplacement suivant :

Si vous consultez cette valeur à l’aide de l’éditeur du registre (regedit.exe), vous verrez qu’elle se présente sous la forme d’un LID au format hexadécimal. En réalité, le format attendu pour le GDID est celui-ci : . Celui de Peter Stokes, suivi par le FBI, était d’ailleurs celui-ci : . Il n’est pas généré à partir de votre adresse IP, mais bien à partir de votre matériel : deux machines avec le même matériel n’auront pas pour autant le même GDID. C’est un identifiant unique.

Pour obtenir directement la valeur, exécutez ces deux lignes de commande PowerShell :

Voici un exemple sur une machine virtuelle Windows 11 :

J’ai également effectué un second test : afficher le GDID sur une machine Windows 11 fraîchement installée, non connectée à Internet, et donc avec une session basée sur un compte utilisateur local. Le GDID n’est pas généré ! Il est inexistant.

Je me suis alors demandé ce qu’il se passait si je connectais la machine à Internet. Le résultat est sans appel : moins de 10 secondes plus tard, le GDID a été ajouté sur la machine locale. Le fait d’utiliser un compte local ou un compte Microsoft ne change rien : le GDID est créé et enregistré auprès des serveurs de Microsoft. Le simple fait de connecter la machine à Internet (elle a donc accès aux serveurs Microsoft), est suffisant.

Ayant procédé à une capture Wireshark démarrée juste avant de connecter la machine au réseau, voici un aperçu de la chronologie des événements :

Windows est conçu pour réaliser cette inscription sur les serveurs Microsoft dès qu’il en a l’occasion. Je dirais même qu’il cherche à effectuer cette inscription en priorité, sans nous laisser le choix.

Peut-on effacer le GDID de Windows ?

Étant donné que nous savons où est inscrit le GDID dans le Registre de Windows, on peut croire qu’il est facile de l’effacer. La réponse est non. Rien ne vous empêche de supprimer cette valeur, mais n’oubliez pas une chose : elle est également enregistrée sur les serveurs de Microsoft. Donc, lors de la prochaine connexion sur les serveurs en question, votre PC Windows 11 va récupérer de nouveau le GDID et le remettre en place dans le Registre.

Il est difficile de supprimer définitivement le GDID de Windows puisque ce système d’exploitation fait tout pour récupérer cette information. Là où vous avez votre mot à dire, c’est au niveau du trafic réseau.

Peut-on empêcher Windows de partager le GDID avec Microsoft ?

Puisque le levier se situe sur le réseau, la bonne nouvelle est que l’on peut agir en amont, avant même que la machine ne joigne les serveurs de Microsoft. Mais il faut distinguer deux objectifs, car ils n’ont pas du tout le même coût pour l’utilisateur.

Le premier objectif : empêcher la création du GDID. Pour cela, il faut bloquer , le service d’identité qui provisionne l’identifiant. C’est ce que confirme mon test : en bloquant ce domaine au niveau DNS avant de connecter la machine, le GDID n’apparaît pas. Le souci, c’est que est aussi la porte d’entrée des comptes Microsoft. Le bloquer casse donc la connexion à un compte Microsoft, le Microsoft Store, OneDrive, Microsoft 365 et les applications UWP qui exigent une authentification Microsoft. Autrement dit, on ne peut pas empêcher la création du GDID sans renoncer à l’écosystème du compte Microsoft. Ce n’est pas forcément dérangeant, tout dépend ce que vous souhaitez faire de votre machine Windows. On peut profiter de Windows sans utiliser les services Microsoft.

Le second objectif est plus mesuré : laisser le GDID se créer, mais perturber sa remontée vers Microsoft. On bloque alors uniquement la couche d’enregistrement et de rapport (le Connected Devices Platform vers le Device Directory Service, et Delivery Optimization), tout en laissant intact. En principe, l’accès au compte Microsoft continue de fonctionner, mais le GDID existe toujours, en local comme côté serveur.

Bloquer via AdGuard Home (ou une alternative)

Pour un blocage DNS complet, un résolveur DNS de type AdGuard Home, Pi-hole ou Technitium peut vous aider. L’avantage, c’est qu’il gère les caractères génériques et couvre donc les sous-domaines. Sinon, vous pouvez utiliser la configuration locale via le fichier hosts (), mais c’est plus délicat car les caractères génériques ne sont pas supportés ().

Sur AdGuard Home, dans Filtres puis Règles de filtrage personnalisées, voici les règles que j’ai ajoutées :

La règle couvre à elle seule toute la couche Delivery Optimization, sous-domaines régionaux compris, ce que le fichier ne peut pas faire. Sur une machine fraîchement installée, connectée au réseau, où ce filtrage est appliqué, le GDID n’est pas présent : cette machine n’existe pas aux yeux de Microsoft.

Enfin, pour les administrateurs qui veulent automatiser la seconde approche, le projet open source (sous licence MIT) propose des scripts qui désactivent les services d’enregistrement et de remontée (, , ) et redirigent leurs points de terminaison, tout en laissant intact pour préserver le compte Microsoft. Il fournit un script d’audit en lecture seule et un script de retour arrière. À tester d’abord sur une machine virtuelle avec un instantané, car il désactive des services système.

Quels services Windows sont perturbés ?

Comme je l’évoquais précédemment, bloquer ces flux n’est pas neutre. Chaque domaine bloqué a un impact plus ou moins important au niveau de la machine Windows. Voici un récapitulatif.

En résumé, seul le blocage de a un impact notable, puisqu’il neutralise l’usage du compte Microsoft (et empêche la création initiale du GDID). Les autres domaines ne coûtent que des fonctions annexes. Au niveau du Microsoft Store, le comportement est assez aléatoire : l’installation d’une application échoue dans un premier temps (une erreur est retournée), tandis qu’en insistant, l’installation finit par passer.

Pas d’écran de consentement, pas d’interrupteur

Ce qui est frustrant avec ce GDID, c’est qu’il n’existe aucune façon simple et documentée de le désactiver. De plus, il n’existe aucun écran de consentement et Microsoft se montre très (trop) discret à son propos.

La plupart des systèmes maintiennent une forme d’identité persistante à des fins de licence, d’identification ou de sécurité. Apple gère un UUID matériel et un DSID, Linux dispose d’un . La différence tient à la visibilité et au contrôle : Windows n’expose ni l’un ni l’autre à l’utilisateur, qui ne peut d’ailleurs pas consulter son propre GDID via une interface standard. À ce jour, Microsoft n’a annoncé ni documentation grand public, ni contrôle utilisateur, ni changement dans la façon dont l’identifiant est généré, stocké ou transmis.

Vous pouvez toujours tenter de limiter l’envoi de données de diagnostic via les paramètres de Windows, mais je doute que cela ait un réel impact.

Conclusion

Pour tenter de contrôler l’utilisation du GDID sur Windows, il n’y a pas énormément de solutions. Pour empêcher la création du GDID, la machine ne doit jamais pouvoir communiquer avec login.live.com, sinon c’est foutu. Le positionnement intermédiaire consiste à laisser Windows créer le GDID, pour ensuite contrôler les connexions futures (via un blocage du réseau et/ou des restrictions sur les services). Gardez à l’esprit que le moindre faux pas peut mener à la création du GDID : Windows n’attends que ça.

Pour aller plus loin, vous pouvez regarder du côté des scripts no-gdid créés par Korben. Il s’agit de scripts PowerShell conçus pour désactiver les services associés à l’activité du GDID (connexions entre votre PC et les serveurs Microsoft). Cet article publié sur GitHub est aussi très intéressant et il est probablement le plus complet à ce jour à propos du GDID. Il y a des similitudes entre ce que j’ai pu constater sur mes machines et ce qui est documenté sur cette page.

Qu’en pensez-vous ?