VaultBoot:認証はサービスであります June 27, 2022 | 4 最小読み取り

VaultBoot:認証はサービスであります

VaultBoot

最高レベルのセキュリティプロファイル(CRITICAL)では、Vault 111ハードウェアノードは、チップセキュリティ機能を介してマルチトラストアンカーを有効にします。 次世代ファームウェアアーキテクチャは、ハードウェアの初期化と実行ペイロードを別々に処理します。 Vaultbootはheadsに基づいて、 HardenedVaultによって開発および保守されています。 HardenedVaultはアップストリームにもいくつかの機能を提供しました。 Vaultbootは、信頼できるコンピューティングと高度な防御に重点を置いたファームウェアセキュリティペイロードです。例:検証済みブート(セキュアブートとも呼ばれます)と測定済みブート、TPMv2ベースのFDE(フルディスク暗号化)、ローカル/リモート認証、内蔵されたDH鍵交換はTPMGenieのように物理攻撃を抵抗します。

何故”アップストリーム”に貢献しませんか

  • Headsは、肥大化したUEFI DXEのドライバーをLinuxペイロードに置き換えることを目標として、初期(2016年)にTrammel Hudson氏によって開始されたオープンソースプロジェクトです。しかし、Hudson氏は2017年以来Headsの仕事にあまり参加していませんでした。

  • 2017年に、Headsは当初の目標を変更しました。つまり、Headsはcorebootのペイロードとして存在して、corebootとペイロードが全体化としてをテストした理由はよくわかりません。通常の回帰テストでも時間のかかる作業です。多分これは、Headsが活躍のように見える理由の1つかもしれません、たとえほとんどのコミットが機能に関連していません。

  • 2019年にHardenedLinuxはVaultBootのプロトタイプの開発が始まり、当時チップセットのロック登録にSMIハンドラー(SMM経由)を使用した。その後VaultBootは、高度な脅威保護(ATP)ノードのためにTPM2サポート、TPMベースのFDE、パラメーター暗号化などの多くの機能の開発を続けました。headsとvaultbootの哲学は異なり、headsはこの自体を完全なソリューションと見なします(完全なファームウェアとしてheadsをビルドする選択肢と、coreboot用のLinuxペイロードとしてのみビルドする選択肢は削除したのか、ないのかと忘れた)。 VaultBootは引き続きKISSの原則に準拠しており、Linuxペイロードとしてのみ存在します(corebootだけでなく、UEFI、さらにはレガシーBIOSでも、必要な調整後共に作業出来ます)。一方、headsのターゲット顧客は個々のユーザーで、VaultBootは高度な脅威保護(ATP)に関する技術の開発コストを削減して、より多くの中小企業やNGOが使用できるように目指しています。

VaultBootの機能

機能の詳細は「FEATURES」または以前の「記事」で確認してください。 VaultBootはrpi4でのみテストしたことにご注意してください。 以下は機能の一覧です:

Features x86_64 arm64
Verified boot YES YES
Measured boot TPMv1.2/v2.0 TPMv2.0
DRTM Partially CBnT N/A
TPM-based FDE (Full-disk encryption) YES YES
Parameter Encryption YES YES
Remote attestation YES YES

VaultBootのビルド方法

「 HowtoBuild document」で確認してください。

典型的なアテステーションはどのように見えますか?

alter-text

Example of remote attestation with FDE (full-disk encryption)

alter-text

FDE(フルディスク暗号化)を使用したリモート認証の例 第一歩:ノードはEKの公開の部分を抽出し、それを認証サーバーの管理者に送信します。

第二歩:管理者はekの登録データ(EKに対して暗号化された対称鍵を含む)を生成し、それらを認証サーバーにデプロイして、このEKの試行認証を有効にします(PCR値を無視します)。

第三歩:ノードは1回限りのAKおよびAK署名付き引用を生成し、認証サーバーにこの引用を送信します。

第四歩:試用認証中に、サーバーが確認する引用はAK署名されて、AKが登録されて、EKに対しての暗号化された登録データをノードに送信します。

第五歩:ノードは登録データの暗号化と復号化にして、さらに対称鍵を取得します。対称鍵とローカル鍵を組み合わせてFDEを設定します。

第六歩:ノードは試用認証で起動可能であることを確認し、認証サーバーの管理者にEKの正式な認証を有効にするように依頼します(有効にした後、最初に受信したPCR値を信頼します)。

第七歩:正式な認証でノードを起動します。

SaaS (Security as a Service)

VaultBootは、HardenedVaultが提供するSaaSにとって重要な役割を果たします。 私たちは、コミュニティとお客様の両方に利益をもたらすために、オープンソースを引き続きサポートします。