首次成功安装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扩展应该是安全的忽视，如果它的意义不是由程序试图验证证书的理解。
由于不能期望安全启动在启动时与任何证书颁发机构进行核对，因此这些属性对于安全启动实际上没有任何意义。当安全启动生效时，固件应验证是否有任何更改现有主键（PK）或密钥交换密钥（KEK）的请求已使用与当前PK证书相对应的私钥签名，并且是否有任何请求更新现有的白名单（db），黑名单（dbx）或时间戳（dbt）密钥使用与当前PK证书或任何当前KEK证书相对应的私钥进行签名。在启动时，加载的任何可执行代码都不应与任何黑名单（dbx）条目匹配，并且应使用与白名单（db）证书之一匹配的密钥进行签名，或者该可执行文件 加密的哈希值应直接包含在白名单中。这些检查完全独立于X.509 PKI层次结构。
安全启动密钥证书仍然可以属于公司PKI层次结构的一部分，以便可以在必要时从外部验证证书，并且此时X.509v3证书扩展可以起作用。但是，对于启动时的安全启动检查，通常似乎会完全忽略任何X.509v3证书扩展。
由于事实证明某些系统固件不允许系统所有者以有用的方式修改安全启动密钥，shim.efi因此开发了自举程序。它提供了安全启动的扩展方案：shim.efi由Microsoft签名，并且提供了第二个白名单（MOK，机器所有者的密钥），可以合理地保证其独立于固件控制，但在其他安全性与其他Secure相似的安全条件下引导键变量。
MOK的注册过程处理NVRAM变量和shim.efi，因此操作结果未存储在常规文件中，而常规文件可以通过timeshift类似方式回滚。实际上，似乎使用仅指定UEFI引导服务访问权限的属性创建了适当的NVRAM变量，因此shim.efi一旦创建，只有一个或另一个UEFI引导时间工具可以修改它们...假设固件根据UEFI和安全启动标准。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句