Windows GDID 全局设备标识符机制曝光：微软如何追踪每台PC？隐私争议与KMS新规解析

近日，美国一起案件意外曝光了微软一项从未公开说明的追踪机制——Global Device Identifier（GDID），这是一种绑定在每台 Windows 设备上的持久标识符，全球约 16 亿台 PC 无一例外。

GDID 首次公开亮相

GDID 的浮出水面源于一起黑客案件。19 岁的美爱双重国籍公民 Peter Stokes 今年 4 月在赫尔辛基机场被国际刑警红色通缉令逮捕，6 月引渡至芝加哥出庭。

他被指控参与黑客组织 Scattered Spider，该组织涉嫌参与超过 100 起网络入侵事件。2025 年 5 月，该组织入侵一家奢侈品珠宝零售商，攻击者冒充员工致电帮助台，通过社会工程学手段重置凭证和多重认证，窃取至少 77 GB 数据并勒索约 800 万美元加密货币。

Stokes 使用了网络代理和多个别名隐匿身份，但 FBI 通过微软获取了其设备 GDID，追踪到同一标识符在攻击者 ngrok 账户创建时连接了注册页面，数小时后通过同一代理访问了受害者站点。

同一 GDID 还出现在爱沙尼亚塔林、纽约和泰国的 IP 地址记录中，时间跨度长达数月，与旅行记录和 Stokes 本人社交媒体发布的照片相互印证，形成完整的证据链。

这是 GDID 首次在公开法律案件中同时被用作追踪标识符并被微软确认存在，也使该机制从暗处走向了公众视野。

服务器生成、注册表存储、无法关闭

根据微软在 United States v. Peter Stokes 案诉状中的描述，GDID 是“一个持久、设备级标识符，用于唯一标识设备上 Windows 操作系统的安装”。它是一个 64 位数字，格式为 g: 后跟一长串数字，由微软服务器外部生成后存储在本地注册表中。每台 Windows 安装都会被分配一个，无论是物理 PC 还是虚拟机。

生成流程大致如下：当 Windows 设置 Microsoft 账户时，Passport 身份服务会主动联系微软服务器，服务器在响应中返回该标识符，随后写入本地注册表路径 HKCU\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties 下的 LID 键值。

随后，Windows 的 Connected Devices Platform 会将其注册到微软跨设备身份系统 Device Directory Service 中，完成从本地到云端的身份绑定。

GDID 在 Windows 更新后保持不变，且在大多数系统更改后依然有效。重装 Windows 会生成新的 GDID，但旧标识符及微软服务器上关联的所有历史记录仍然保留，不会随重装而消失。 这意味着微软服务器上的 GDID 档案是累积式的，每一次设备活动都在为这个档案添砖加瓦。

无处不在的 GDID

独立研究人员逆向工程了该机制后发现，GDID 的嵌入范围远超想象，深度参与 Windows 核心功能链路。这张流程图清晰地展示了其应用场景：

系统层面：Windows 激活状态与 GDID 绑定， Microsoft Store 的购买记录和应用许可验证都附带该标识符。你在应用商店里的每一笔消费，其实都与设备身份挂钩。

跨设备功能：手机连接功能依赖 GDID 建立手机与 PC 的配对关系，跨设备剪贴板同步也通过它识别设备身份。当你在手机上复制内容粘贴到 PC 时，GDID 就在幕后参与了设备匹配。

诊断与浏览数据：常规 Windows 诊断数据携带 GDID，如果 Microsoft Edge 增强诊断功能开启，浏览历史同样与之绑定。这正是调查人员构建 Stokes 案证据链的关键—— Edge 浏览记录通过 GDID 与设备身份关联，即便 Stokes 不断切换代理，GDID 始终如影随形。

用户能做什么？

对于普通用户，可以通过 PowerShell 命令查看自己的 GDID：

$hex = (Get-ItemProperty 'HKCU:\SOFTWARE\Microsoft\IdentityCRL\ExtendedProperties').LID

然后运行 "g:$([Convert]::ToUInt64($hex,16))" ，即可查看你的设备 GDID。该操作不需要管理员权限，任何用户都可以直接运行。

但问题是，你也只是能查看。目前没有任何方法可以阻止 Windows 生成 GDID，且无法删除微软已存档的历史记录。

Zerotrace Lab 曾尝试用自定义密钥替换设备上的 GDID 并公开了完整实验过程。实验结果表明，虽然本地注册表中的值可以被修改，但微软服务器端的记录与本地不一致时会导致部分 Windows 功能异常，说明 GDID 的验证逻辑是双向的，并非简单的本地标识。

虽然没有证据表明微软向广告商等第三方分享 GDID，微软官方文档也声明该标识符仅供内部使用，但执法机构可通过传票或法院令等标准法律渠道获取，Stokes 案就是典型例证。

安全专家和用户最大的不满，其实在于透明度缺失。大多数操作系统都有各自的追踪机制，但通常会通知用户或提示接受条款。苹果要求 App 通过 ATT 框架获取追踪授权，谷歌允许用户重置广告 ID， Linux 发行版则以开源方式让用户可以审查所有数据收集行为。唯独 Windows 是个例外——微软唯一有关 GDID 的公开文档，是 Azure Monitor 参考表中的一行描述，将 GlobalDeviceId 列定义为“微软内部使用的全球设备标识符”。

除此之外，没有专门的支持页面，没有用户告知机制。直到这一起案件，才迫使微软承认了更多细节。考虑到 Windows 运行在全球约 16 亿台 PC 上，这个标识符的影响范围之广、存在时间之长、公众知情之晚，在操作系统隐私实践中都极为罕见。

另起波澜：KMS 激活即将引入 TPM 硬件信任

还有一件事值得关注。微软即将为其批量激活服务 KMS 引入基于硬件信任的新安全机制，该机制要求 KMS 主机通过 TPM（可信平台模块）芯片进行身份验证，确认运行在可信且未被篡改的硬件上后，方可为局域网内的 Windows 设备颁发激活许可，此举旨在打击利用伪造或克隆 KMS 服务器绕过激活控制的盗版行为。

KMS 是微软面向企业环境的批量激活技术，组织内只需激活一台 KMS 主机，局域网内的 Windows 设备向该主机发起激活请求即可完成激活，无需每台设备单独连接微软服务器。但该机制长期被滥用于非授权场景，攻击者搭建伪造的 KMS 服务器，模拟企业批量激活环境，使未经授权的 Windows 设备完成激活。

此次新机制的核心变化在于引入 TPM 证明 环节。TPM 是一类专用硬件安全组件，负责生成和保护加密密钥，确保平台完整性，Windows Hello、 BitLocker、 System Guard 等安全功能均依赖其工作。 启用 KMS 硬件安全后，KMS 主机需先通过 TPM 生成加密证明以建立硬件身份，微软验证该证明及平台完整性无误后，才允许该主机处理激活请求。

具体落实时间上，自 2026 年 8 月起，Windows Server 2025 将先行引入检测机制，系统管理员可以使用命令 (slmgr/dlv) 查询设备是否达标，达标设备会显示“符合具有硬件安全性的 KMS 主机条件”。从下一个 Windows Server 长期服务通道版本（预计为 Windows Server 2028）正式发布开始，TPM 认证将成为强制要求，届时没有硬件证明的 KMS 激活将彻底失效。

从影响范围来看，此次调整目前仅针对 KMS 主机端，普通个人电脑作为 KMS 客户端暂时不会受到直接影响。但长远来看，随着伪造 KMS 主机的门槛拔高，未来网上那些“一键激活工具”或许会迎来一波大洗牌。