通過 mokutil 簽署密鑰
第一次成功安裝 Linux Mint 19.1 Cinnamon 後，我完成了安裝後建議的步驟。在這裡，我還升級了我的系統（在檢查並安裝驅動程序之後）。但是，在此升級過程中，彈出以下消息：
您的系統已啟用 UEFI 安全啟動。UEFI 安全啟動與使用第三方驅動程序不兼容。系統將協助您禁用 UEFI 安全啟動。為確保此更改是由您作為授權使用者而不是攻擊者進行的，您必須選擇一個密碼，然後在重新啟動後使用相同的密碼來確認更改。如果您選擇繼續但在重新啟動時未確認密碼，Ubuntu 仍然可以在您的系統上啟動，但這些第三方驅動程序將不適用於您的硬體。
然後我設置了一個 MOK PW 並重新啟動了機器，簽署了密鑰。但是，我真的不知道是什麼提示了這條消息，以及我在那裡簽名的密鑰。我認為這與我之前安裝的第三方 Nvidia 驅動程序有關，因為我昨天在驅動程序安裝後（系統更新之前）使用時移回滾了我的系統。然後我禁用了 nvidia 顯卡（驅動程序適用於該顯卡），再次更新系統後，沒有彈出提示我簽署密鑰的消息。
我懷疑可能是目前簽名的密鑰之一具有以下屬性，這聽起來很糟糕：
X509v3 Basic Constraints critical CA: False總而言之，我的主要問題如下：這一切意味著什麼？我實際上對簽署所述密鑰做了什麼，這是否會對我的系統產生任何負面影響？我如何找出我最初在那裡簽名的密鑰以及該密鑰是否“安全”？
在 X.509v3 證書術語中，如果證書的創建者（和/或認證機構）要求驗證此證書的人必須了解此副檔名，否則可以將此證書視為無效，則可以將證書副檔名指定為關鍵。
“基本約束”擴展是最基本的證書擴展：它確定證書是普通證書（“CA: False”）還是證書頒發機構證書（“CA: True”，具有可選的路徑長度值，即此 CA 證書之後的中間 CA 證書的最大允許深度）。
在所有現代系統中，“基本約束”證書擴展應該始終是一個關鍵擴展。
所以，這些屬性：
X509v3 Basic Constraints: critical CA: False用人的話說：“這不是CA證書。如果它出現在需要CA證書的情況下，肯定有人做錯了。如果你不理解這個限制，你不應該依賴這個證書完全出於任何目的。” 換句話說，這是對任何非 CA 證書的完全正常和預期的擴展。
如果嘗試驗證證書的程序不理解非關鍵X.509v3 擴展的含義，則應該可以安全地忽略它。
由於不能期望安全啟動在啟動時與任何證書頒發機構進行檢查，因此這些屬性對安全啟動沒有任何意義。當 Secure Boot 生效時，韌體應該驗證任何更改現有主密鑰 (PK) 或密鑰交換密鑰 (KEK) 的請求都使用與目前 PK 證書對應的私鑰進行簽名，並且任何請求更新現有的白名單 (db)、黑名單 (dbx) 或時間戳 (dbt) 密鑰使用與目前 PK 證書或任何目前 KEK 證書對應的私鑰進行簽名。在引導時，載入的任何可執行程式碼都不應與任何黑名單 (dbx) 條目匹配，並且應使用與白名單 (db) 證書之一匹配的密鑰或執行檔’ s 加密雜湊應該直接包含在白名單中。這些檢查完全獨立於 X.509 PKI 層次結構。
安全啟動密鑰證書仍然可以是公司 PKI 層次結構的一部分，因此可以在必要時對證書進行外部驗證，此時，X.509v3 證書擴展可能會發揮作用。但是對於啟動時安全啟動檢查，任何 X.509v3 證書擴展似乎通常都被完全忽略。
因為事實證明某些系統韌體不允許系統所有者以有用的方式修改安全啟動密鑰，所以開發了一個
shim.efi引導載入程序。它為 Secure Boot 提供了擴展方案：shim.efi由 Microsoft 簽名，並提供第二個白名單（MOK，機器所有者密鑰），合理地強烈保證獨立於韌體控制，但在與其他 Secure 類似的安全條件下引導鍵變數。MOK 註冊過程處理 NVRAM 變數和
shim.efi，因此操作結果不會儲存在可以回滾timeshift或類似的正常文件中。事實上，看起來適當的 NVRAM 變數是使用僅指定 UEFI 引導服務訪問的屬性創建的，因此只有shim.efi或另一個 UEFI 引導時間工具可以在創建後修改它們……假設韌體根據 UEFI 工作並且安全啟動標準。