TPM 鎖定的原因
我們部署了多台 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 肯定處於鎖定狀態,但不提供有關原因的任何資訊。有誰知道我是否可以做任何事情來嘗試確定鎖定的根本原因?
最後,我設法在解決這個問題上取得了相當大的進展。我會盡力記住細節,但已經有一段時間了……
不幸的是,有問題的機器是 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。我認為這可能是問題的一個因素。
我讀過的解釋是 TPM 無權寫入任何類型的日誌或導致鎖定它拒絕訪問的驅動器。明智的。給出一個理由也可能存在安全漏洞。
我能找到的唯一資訊是輸入的錯誤密碼的數量。打開提升的 powershell 提示符並輸入:
獲取-tpm
與普通的命令外殼不同,您將擁有 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