我们部署了多台 Surface Pro 3 设备,并在 TPM + PIN 模式下启用了 BitLocker。这些设备具有 TPM 2.0 芯片并运行 Windows 8.1 Pro。
我们遇到的问题是,用户在输入正确的 PIN 码时偶尔会收到“错误的 PIN 码尝试次数过多”错误。然后,他们必须输入恢复密钥才能继续启动过程。然后,他们每次启动设备时都需要输入恢复密钥,直到我们使用 tpm.msc 手动重置 TPM 锁定,这显然不方便。
出于某种原因,TPM 正在进入锁定状态,但这似乎不是因为重复错误的 PIN 尝试。如果您让设备运行,锁定最终不会超时这一事实也表明它是出于其他原因,而不是达到最大错误身份验证尝试次数。我了解 TPM 2.0 规范声明应该是这种情况,与将确切行为留给供应商的 TPM 1.2 规范不同。
运行Get-Tpm
表明 TPM 肯定处于锁定状态,但不提供有关原因的任何信息。
有谁知道我是否可以做任何事情来尝试确定锁定的根本原因?
我读过的解释是 TPM 无权写入任何类型的日志或导致锁定到它拒绝访问的驱动器。明智的。给出一个理由也可能存在安全漏洞。
我能找到的唯一信息是输入的错误密码的数量。打开提升的 powershell 提示符并输入:
与普通的命令外壳不同,您将拥有 LockoutCount 和 LockoutMax 的条目。这将为您提供输入了多少错误密码的计数。我确信用户确信他们总是输入正确的密码,但我发现通常存在沟通错误。
话虽如此,还有许多其他锁定原因。 https://technet.microsoft.com/en-us/library/dn383583(v=ws.11).aspx 特别是“什么导致 Bitlocker 恢复?” 从插入 CD 到让设备的电池完全放电,任何事情都可能导致锁定。这是我试图通过混合用户教育、帮助台教育和评估要更改的组/本地策略设置来解决的问题。 https://technet.microsoft.com/en-us/library/jj679890(v=ws.11).aspx
最后,我设法在解决这个问题上取得了相当大的进展。我会尽力记住细节,但已经有一段时间了......
不幸的是,有问题的机器是 Windows 8 机器,因此
Get-Tpm
cmdlet 不会返回有关锁定计数器的信息。我最终设法编写了一个自定义脚本来直接从 TPM 读取这些计数器,果然,锁定计数器已达到锁定阈值。即使我们没有错误地输入 PIN,情况也是如此。经过大量挖掘,我最终偶然发现了 TPM 2.0 规范中的一个部分,该部分描述了一种几乎可以肯定导致问题的机制。在我详细介绍之前,有一点背景知识会很有用... 在操作系统可以使用 TPM 之前,它必须调用 TPM 的启动例程。这似乎发生在显示 BitLocker PIN 屏幕之前。相反,一旦操作系统完成使用 TPM,它应该调用 TPM 的关闭例程。Windows 似乎在操作系统关闭序列期间执行此操作。
当系统关闭而操作系统没有完全关闭时,问题就出现了。在这种情况下,TPM 的关闭程序在芯片断电之前没有被调用。TPM 2.0 规范规定,如果在没有先前调用 TPM 的关闭例程的情况下调用 TPM 的启动例程,它应该将锁定计数器加一。此功能的存在是为了防止针对 TPM 的特定类型的攻击。因此,当设备再次开机时,即使用户输入了正确的 BitLocker PIN,锁定计数器也会加一。
在我的特殊情况下,有问题的设备都是 Microsoft Surface Pro 3 平板电脑。我的预感是用户按住电源按钮以关闭机器而不是干净地关闭它。通常,这不是一个大问题,因为锁定计数器最终会在两小时后再次递减。但是,如果他们经常这样做,锁定计数器就没有时间递减。如果机器重新通电,用于跟踪何时减少的计时器会重置,这意味着它必须在减少之前连续保持两个小时,从而使问题更加复杂。一些用户只在短时间内将他们的机器拿出来。
Surface Pro 3 支持微软称之为“Connected Standby”或“InstantGo”的东西。这是一项使设备在电源管理方面表现得更像移动设备的功能。点击电源按钮会使设备进入低功耗模式,而不是传统的待机或睡眠模式。但是,我们已将电源计划切换为“高性能”,这具有禁用连接待机模式的效果,使设备的行为类似于传统 PC。我认为这可能是问题的一个因素。