初めてLinux Mint 19.1 Cinnamonを正常にインストールした後、推奨インストール後の手順に従いました。ここでは（ドライバを確認してインストールした後）、システムもアップグレードしました。ただし、アップグレード処理中に次のメッセージが表示されます。
システムでUEFIセキュアブートが有効になっています。 UEFI セキュアブートはサードパーティ製ドライバの使用と互換性がありません。システムはUEFIセキュリティブートを無効にするのに役立ちます。この変更が攻撃者ではなく承認されたユーザーによって行われたことを確認するには、パスワードを選択し、再起動後に同じパスワードを使用して変更を確認する必要があります。再起動時にパスワードを確認せずに続行することを選択した場合、Ubuntuはシステムから引き続き起動できますが、これらのサードパーティ製ドライバはハードウェアでは使用できません。
その後、MOK PWを設定し、システムを再起動し、キーに署名しました。しかし、このメッセージを引き起こした原因が何であるか、どのキーでそこに署名したのかは実際にはわかりません。昨日ドライバをインストールした後（システムアップデート前）にシステムをロールバックしたので、以前にインストールしたサードパーティのNvidiaドライバと関連があると思います。その後、（ドライバがターゲットにした）nvidiaグラフィックカードを無効にし、システムを再アップデートするときにキーに署名するように求められませんでした。
現在署名されているキーの1つ（おそらくそうです）には、次のような属性がありますが、本当にひどいようです。
X509v3 Basic Constraints critical
CA: False
全体的に私の主な質問は次のとおりです。これはすべてどういう意味ですか？そのキーで実際に何に署名し、これが私のシステムに悪影響を及ぼしますか？もともと署名した鍵が何であるか、その鍵が「安全」であるかどうかはどうすればわかりますか？
ベストアンサー1
X.509v3 証明書の用語では、証明書拡張は次のように指定できます。批判的証明書作成者（および/または認証機関）が要求する場合この証明書を確認した人〜しなければならないこの拡張機能について学ぶそれ以外の場合、証明書は無効と見なされます。
「基本制約」拡張は、最も基本的な証明書拡張です。証明書が一般証明書（「CA：False」）であるか、認証局証明書（「CA：True」）であるかを決定し、次のオプションのパス長値を使用します。この CA 証明書は、中間 CA 証明書の最大許容深さです。
すべての最新システムでは、「基本制約」証明書拡張は常に重要な拡張でなければなりません。
したがって、次の属性は次のようになります。
X509v3 Basic Constraints: critical
CA: False
人間の言葉では、「これはいいえCA証明書CA証明書が必要な場合は、誰かが何か間違っていることは間違いありません。この制限を理解していない場合は、いかなる目的にもこの証明書に頼ってはいけません。これは、CAではなく証明書の完全に正常で予想される拡張です。
ㅏ重要ではない証明書を検証するプログラムがX.509v3拡張の意味を理解できない場合は、これを無視してもかまいません。
セキュアブートはブート時に認証局を検証できないため、これらのプロパティはセキュアブートには意味がありません。セキュアブートが適用されると、ファームウェアは、既存のマスターキー（PK）またはキー交換キー（KEK）の変更要求が現在のPK証明書に対応する秘密鍵で署名されていること、および既存のPK証明書に対する変更があることを確認する必要があります。マスターキー（PK）またはキー交換キー（KEK）キー（PK）またはキー交換キー（KEK）への要求が署名されたかどうか。現在のPK証明書または現在のKEK証明書に対応する秘密鍵で署名する既存のホワイトリスト（db）、ブラックリスト（dbx）、またはタイムスタンプ（dbt）キーを更新します。起動時にロードされた実行コードは、ブラックリスト（dbx）エントリと一致しないでください。ホワイトリスト（db）証明書の1つと一致するキーで署名する必要があります。または、実行可能ファイルの暗号化ハッシュをホワイトリストに直接含める必要があります。これらの検査は、X.509 PKI階層とは完全に独立しています。
セキュアブートキー証明書は依然として会社のPKI階層の一部である可能性があるため、必要に応じて証明書を外部で確認できます。この場合、X.509v3証明書拡張が適用される可能性があります。ただし、ブート時のセキュアブートチェックの場合、X.509v3証明書拡張は通常完全に無視されるようです。
shim.efiブートローダは、一部のシステムファームウェアでは、システム所有者がセキュリティブートキーを有用な方法で変更することを許可しないという事実のために開発されました。これは、マイクロソフトが署名したセキュアブートの拡張を提供し、shim.efiファームウェア制御とは無関係であることを合理的に強力に保証しますが、同様の安全条件で他のセキュリティ起動キー変数で使用される2番目のホワイトリスト（MOK、システム所有者キー）を提供します。します。 。
MOK登録プロセスでは、NVRAM変数とshim.efi演算結果は次のようになります。いいえまたは、同様の機能を使用してロールバックできる通常のファイルに保存されますtimeshift。実際、適切なNVRAM変数はUEFIブートサービスによるアクセスのみを指定する属性で生成されるため、shim.efi作成後は他のUEFIブートタイムツールのみを変更できます。ファームウェアはUEFIに従って動作し、次のように仮定します。セキュリティ開始標準。