システムセキュリティー¶
IncusOSはUEFIセキュアブートとTPMの両方にブートのセキュリティーと暗号化を積極的に依存しています。
前提¶
IncusOSのインストール前に、サーバーのセキュアブートをセットアップモードにすること。
特定のPKやサードーパーティーのdb証明書が必要な場合、PK/KEK/db証明書の設定はIncusOSのインストールを開始する前に行っておく必要があります。
PK/KEK/db証明書が存在しない場合、IncusOSはインストールの一部としてセキュアブート証明書を自動登録します。
インストール後のセキュアブートはユーザーモードで稼働すること。これによりIncusOSのKEK証明書で署名されたdbとdbxの更新をIncusOSが自動的に適用できます。IncusOSのPK鍵が登録された場合、KEK鍵も更新できるかもしれませんが、これは非常にまれな運用だと期待されます。
あるいは、セキュアブートがデプロイドモードの場合、db/dbx/KEKの鍵の更新はITスタッフにより手動で適用する必要があります。これはサポート対象外の設定になりそうです。
IncusOSのセキュアブートの鍵は毎年作成され、十分事前に発行されます。
鍵の有効期間はロールオーバーの時間的な余裕を持たせるため18～24か月になります（予定）。セキュアブートは証明書の期限を実際にはチェックしませんが、OSの更新を適用する前に
incus-osdでシンプルなチェックを行います。1月1日以降のIncusOSの最初のリリースでは新年の署名用証明書を取得し使用します。それが起きてからしばらくしたら、昨年の証明書は無効化され、証明書をdbxに配置する更新がAPIを使って発行できます。
証明書の階層¶
IncusOSは以下に示すようなTLS証明書の認証局と証明書の階層に依存しています。セキュアブートはTLSスタイルの証明書の検証は行わないことに注意してください。
IncusOSルートとセキュアブートCAは（ECDSAなどの）最新の標準を使います。
IncusOS PK、KEK、dbの証明書はセキュアブートの標準の制限によりRSA 2048に限定されます。それぞれのセキュアブートの証明書はIncusOSのセキュアブートCAにより署名されます。
Incus OS - Root E1
|
Incus OS - Secure Boot E1
|
\-- Incus OS - Secure Boot PK R1
\-- Incus OS - Secure Boot KEK R1
|-- Incus OS - Secure Boot 2025 R1
\-- Incus OS - Secure Boot 2026 R1
セキュアブート変数の使用¶
PK: OEM／オーナー提供あるいはIncus OS - セキュアブート PK R1
KEK: Incus OS - セキュアブート KEK R1
db: IncusOSの署名鍵
新しい署名鍵は毎年生成され、事前に発行されます
新しい署名鍵がサービスに提供される際、1月1日以降6～12か月のオーバーラップがあります
dbx: 古いIncusOSの署名鍵
キーのローテーションから十分な期間の後、IncusOSの署名鍵は無効にされます
MOK: （IncusOSのセットアップでは使用されずサポートもされません）
実装詳細¶
dbとdbxの更新は登録されたKEKまたはPKの鍵でオフラインで署名できます。そして任意のシステムに配布して自動で適用できます。
既存の値を置き換えるか追加するかのみがサポートされます。
特定の値を削除するにはKEKあるいはPK秘密鍵へのローカルアクセスが必要です。
KEKの更新は登録されたPK鍵でオフラインで署名できます。そしてdbとdbxの更新のように配布できます。
IncusOSのPKが存在しない場合、KEKの更新は手動で適用する必要があります。
KEKの更新は非常にまれであると期待できます。
IncusOSはdb/dbx/KEKの更新をOSとアプリケーションの更新と同様に設定されたプロバイダーから受け取ります。
またdbやdbxに存在しない鍵で署名されたIncusOSの更新はインストールできません。これはシステムの再起動時に新しいイメージで起動するのを拒否するためです。
信頼された署名鍵を更新するのとIncusOSの更新を提供するのは2つの異なるオペレーションであり、間に再起動が入ります。これはセキュアブートの状態と期待されるTPM PCRの値を更新するのは正しく行うのが極めて重要であり、一度に1つの変更だけを許す（新しい信頼された鍵あるいは変更された署名鍵による更新）ほうがロジックが大幅にシンプルになるからです。
セキュアブート鍵の更新¶
KEK、db、dbxの更新はオフラインで署名され、プロバイダーのAPIで公開されます：
.authファイルのシンプルなリストとして提供され、1つのファイルにつき1つの更新を含みます。<VAR>_<SHA256 fingerprint>.authのファイル名のパターン:db_8A78635EA12B2EF676045B661187E08D1412253220A1BD02EF79D177302DB83F.auth、dbx_DA39EF49E3F5D7B902ECE6CA338883623F61DC671ABE10DF2E7B1CBDEC4A2B47.authなどこの命名規則はクライアントが利用可能なすべての鍵のリストを素早く取得し、足りない鍵を特定し、必要な更新をダウンロードすることを自明にします。
更新のチェックはOSの更新チェックと同じ頻度（デフォルトで6時間ごと）で行われます：
UEFI変数の更新はKEK、db、dbxの順に一度に1つずつ適用します。
各アップデート後に再起動が必要です。IncusOSの起動中にアップデートが適用された場合再自動で再起動しますが、自動で再起動できない場合はユーザーが再起動する必要があります。
現在のイメージあるいはバックアップイメージがdbxで署名されている場合、使用不可能になることを避けるため、dbxの更新は適用しません。
更新の利用可能性と完全性¶
攻撃者がIncusOSの更新チェックをブロックしセキュアブート鍵の更新の適用を妨害するかもしれません。
各
.authファイルはIncusOSが稼働しているマシンに登録済みのKEK証明書で署名されています。ファイルが改ざんされた場合、登録は失敗しますので、受け取った更新を保護したりチェックサムを計算する必要性は特にありません。
TPM PCRの使用¶
IncusOSはディスクの暗号鍵をバインドするために3つのPCR（4、7、11）に依存しています。
PCR 4¶
注釈
PCR 4はセキュアブートが無効にされたIncusOSシステムでのみ使われます。
PCR 4はブートプロセスに関与するポータブルエクゼクタブル（PE）に基づいて計算されます。IncusOSでは、これはsystemd-bootスタブとシステムUKIイメージを含みます。UEFIはPCRの最終的な値を各PEバイナリーの認証コードをハッシュ化することで算出します。対応するTPMのイベントログエントリーは、UEFIパス、サイズなどのPEバイナリーについての追加の情報を含みます。
セキュアブートが無効な状態でIncusOSが稼働するように設定されている場合、PCR 7が有用なデータを含んでいるとは信頼できません。値が設定されていても内容が信用できないためです。そのため、ディスク暗号化がバインドされる値のリストにPCR 4を追加します。これにより、指定のIncusOSインストールから起動したときにのみディスクを自動でロック解除するためのある程度の保証を提供します。
IncusOSがブートの初期にTPM PCR 4のイベントログとバイナリーのシグネチャーの検証を行うことと合わせて考えると、IncusOSが起動時に暗号化されたディスクを自動的にロック解除できれば、セキュアブートが無効化されていてもIncusOSが改ざんされていないことをある程度確信できます。
PCR 7¶
PCR 7は現在のセキュアブートの状態をPK/KEK/db/dbxの値に基づいて算出されます。このPCRの最終的な値はsystemd-boot UEFIスタブが開始する前にUEFIにより計算されます。このPCRにバインドすることでセキュアブートが有効でIncusOS証明書が存在する場合にのみデータが利用可能であることを保証できます。（攻撃者が別のマシンでディスクをロック解除したりライブのブートメディアを使って攻撃を行うことを防ぎます。）
PCR 7の計算は簡単で、署名鍵が追加されたり無効化されるたびに実行され、現在稼働中のシステムとは別の鍵でIncusOSの更新が署名されている場合：
TPMのイベントログを取得し、再計算したPCR 7の値が現在のTPM RCP 7の値と一致することを検証します
UEFI変数の更新を適用します
TPMのイベントログを再生し、現在のUEFI変数値を使って将来のPCR 7の値を算出します
現在のTPMの状態を使ってLUKSボリュームのPCR 7バインディングを次回起動時の予想されるPCR 7の値を使って更新します
PCR 11¶
PCR 11は稼働中のUKIをベースに算出され、ブートプロセスのさまざまな時点で算出されます。適切に署名されたUKIイメージと組み合わせることで、UKIの改ざんを検知し暗号化されたディスクのロック解除を拒否することができます。PCR 11の算出は複雑です。systemdはPCR 11ポリシーをイメージのビルド時に作成するために依存するsystemd-measureをもっており、その後そのポリシーはセキュアブートの署名鍵と組み合わせてTPMをバインドします。この手法の利点はPCR 4と7で行うような完全なハッシュのバインディングよりもはるかに柔軟であり、ビルドプロセスがPCR 11の値を完全に予測して結果のUKIイメージにその値を埋め込むことができるという点です。
IncusOSがPCR 11の再バインディングについて気にする必要があるのは、毎年の鍵の更新のように、UKIで使われるセキュアブート鍵が変更される場合のみです。これはPCR 11ポリシーは現在のセキュアブートの署名鍵を使ってTPMにバインドされ、それが再起動時に変わった場合はTPMの状態が合致せず自動のロック解除が失敗するためです。異なるセキュアブート鍵を使ってIncusOSの更新をインストールする際にとられる手順は：
更新されたUKIの鍵がUEFI db変数内に存在し、dbxには存在しないことを検証する。これにより更新のインストールがセキュアブートのポリシー違反で起動に直ちに失敗することを防ぎます。
既存のsystemd-boot UEFIスタブを保留中のOSの更新からの新しい署名されたものに置き換える。
systemd-sysupdateは通常はsystemd-bootスタブを更新しませんが、新しい鍵で署名されたものに確実に更新する必要があります。systemd-bootスタブの署名を変更すると次回起動時のPCR 7の値に影響がでます。そこで上記の工程に従って新しいPCR 7の値を予測します。
TPM PCR 11のポリシーを新しい署名証明書と予測したPCR 7の値で再バインドします。これをすることで現在のTPMの状態は無効化されますので、LUKSヘッダーを更新するにはIncusOSが知っているリカバリーキーに依存する必要があります。LUKSヘッダーがTPMに登録されていない状態になるのを避けるため、更新はできるだけアトミックなプロセスで実行されます。
関連事項¶
PCRの値の予期せぬ変更は自動のロック解除が失敗し、システムを起動するためにリカバリーパスワードの入力が必要になることにつながります。そのような変更は、IncusOSが期待する範囲の外側でシステムのセキュリティー設定に予期せぬなんらかの出来事が起きたことを強く示しています。無害な変更により引き起こされたのかもしれませんし、悪意の攻撃を示しているかも知れません。いずれにせよ、起動時に盲目的にリカバリーパスワードを入力する前に注意してください。
もう1点注意すべきこととして、IncusOSイメージを署名するのに使うセキュアブートキーの1年ごとのローテーションがあります。IncusOSは移行を自動的に処理しますが、何らかの理由で昨年のセキュアブートキーで署名されたリカバリーイメージで起動する必要がある場合、起動にはリカバリーパスワードの利用が必要です。これはsystemd-bootスタブは新しいセキュアブートキーで署名されていますが、リカバリーUKIは古いキーで署名されているからです。このため期待されるPCRの値と実際の値で不整合が置きます。新しいセキュアブートで署名された2番目の更新がインストールされた後は、両方のUKIイメージがsystemd-bootスタブを署名するのに使ったのと同じキーで署名されるため、この問題は解消します。
有用なツール¶
systemdには現在のPCRの値とその値が起動プロセス中にどのように算出されたかを調べるのに役立つsystemd-pcrlockがあります。