最初に、TPMの使用方法を大まかに説明します。
私は tpm-luks
と呼ばれるものを使用しています。これは、両方のTPM NVRAMにキーを格納し、そのキーをLUKSキースロットの1つに追加します。次に、initramfsは、TPMから取得したキーを使用して、ルートLUKS暗号化パーティションを復号化します。また、tpm-luks
を使用してキーをsealし、TPM PCRレジスタが指定されている場合にのみキーがTPM NVRAMから解放されるようにします状態(たとえば、所定のブートローダー、initramfs、linuxなどがロードされた後)。 TrustedGRUB [2]はブートローダーとして使用され、TPM PCRに独自のハッシュを記録します。
また、時々システムにリモートの無人アップグレードを行う予定です(たとえば、カーネルを更新するとカーネルファイルのハッシュも変更されます)。この問題を回避するために、tpm-luks
は、再起動する前に、新しい値を使用してハッシュとresealを事前計算する方法を提供します。新しいPCR状態でキーを再度ロック解除できるようにするため。
現在、このプロセスでは、アップグレードを実行して新しいキーを追加するたびに、TPM所有者のパスワードを入力する必要があります。
私の質問は:
tpm-luks
には、これらの既知のパスワードを使用してこれらの操作を実行するオプションがあり、非対話型にすることができます。システムがロックダウンされているので、誰もこれを利用できないと思いますか?20バイトの0の既知のパスワードを所有者/ SRKパスワードとして使用しても問題ありませんか? tpm-luksには、これらの既知のパスワードを使用してこれらの操作を実行するオプションがあります。これにより、非インタラクティブにすることができます。システムがロックダウンされているので、誰もこれを利用できないと思いますか?
所有者とパスワードをデフォルト値または既知の値のままにしておくと、セキュアブートプロセス全体を回避するための扉が開かれます。これは、耐タンパー性を意図した、現場での組み込みシステムにおけるより大きな懸念事項です(この場合の改ざんにより、動作が失敗するか、機能が制限されたフェイルセーフモードに分類されます)。
よく知られている所有者/パスワードを使用する場合、経験または知識がある人は、基礎となるOSイメージ/ハードウェア構成を変更する可能性があります。TPMPCR値を更新し、ファイルシステムキーにアクセスして、実施しているセキュリティ/整合性対策をバイパスします。
そうでない場合、暗号化されたルートパーティションにパスワードを保持することは可能でしょうか?ルートパーティションが復号化される時点でシステムは信頼されているので、パスワードをそこに保存して安全にアクセスできますか?
確かに、私はこれが機能しているのを見ることができますが、システムが起動して「信頼できる」と見なされた後でも、キーを盗み取られ、システムからドライブを取り外して復号化することを許可されます。だから、確かに、そこに保管しても安全です...暗号化されていますが、起動後は危険です。 (これにより、最終的に「信頼されたシステム」にバックドアがインストールされる可能性があります)
そのような操作を実行する必要がある場合は、パスワードを他の安全な場所に保管し、マシンに送信する方が良いでしょうか?上記の2番目のオプションよりも安全かどうかはわかりません。
TPMは、キーを格納するための文字通りの場所です。
上記の目的(TPM NVRAMへの非対話型のキーのストレージ)を達成するために、他に優れたソリューションはありますか?
承知しました。単一のツールの問題に対する複雑なソリューションを検討しているように見えます。ツールでは所有権の自動化やパスワードの設定ができません。
おそらく、ズボンのコードリポジトリをチェックアウトし、ビルドして正常性テストを行った後、tpm_takeownershipツールを変更して非インタラクティブな所有者/パスワードのプロンプトオプションを追加し、アップグレードプロセス中にそのカスタムバイナリを使用します。