背景

ファームウェアは特別なタイプのソフトウェアで、主に基盤となるハードウェアの制御と通信に使用されます。ファームウェアの範囲が広すぎて、セキュリティ問題に関連するファームウェアの領域が大きく異なります。この記事では、サーバー、ノートブック、デスクトップなどの一般的なコンピューターで実行されているファームウェアについてのみ説明します。

現在の問題

UEFIは、現時点ではまだ主流のファームウェアソリューションです。UEFIエコシステムにはいくつかの問題があります。

*技術的なアーキテクチャ設計では、その複雑なサプライチェーンは考慮されていませんが、tianocore/EDK2のリファレンス実装はOEMファクトリ実装とは大きく異なります。リバースエンジニアリングとテストを通じて、一部のOEMファームウェアにSMMベースの機能が実装されていることを知るのは難しくありません。SMM は、“Ring -2” とも呼ばれる実行モードの特権が “RING 0” よりもさらに高いため、x86 ではリスクの高い攻撃対象領域の 1 つです。これが、オペレーティングシステムがリング0以下の脅威を検出するのが難しい主な理由です。

• 設計と実装の欠陥は、多くのファームウェアのセキュリティリスクにつながります:

*サプライチェーンが長いため、バグ修正サイクルが長くなります。さらに重要なことは、既知の脆弱性の修正の遅延や拒否によって、ユーザーの運用環境に対するリスクが高まることです。

*非監査可能性、ほとんどのOEMベンダーはユーザーにファームウェアのソースコードを提供していません。ソース・コード・レベルでの監査は実行不可能です。脆弱性の監査は、バイナリ監査またはファジーザーにのみ依存できます。バックドアまたはデバッグ機能の監査のコストは、ソースコードなしでは非常に高いです。Intelは2019年にMinimum platformでオープン性に対処しようとしているが、そのカバレッジは期待どおりにうまくいかなかった。

‘"‘次世代’"’ ファームウェア

1999年の冬、ロスアラモス国立研究所の研究者であるロン・ミニッチは、ハードウェアの初期化の段階でできるだけ少ないコードを持ち、ハードウェアの初期化が完了したときに残りの部分を処理するためにLinuxベースのペイロードをロードするという哲学的な考えで、プロプライエタリなファームウェアをフリーソフトウェアに置き換えるように設計されたLinuxBIOSと呼ばれるプロジェクトを開始しました。LinuxBIOS は後に coreboot と改名された。今日のコアブートはLinux以外の幅広いペイロードをサポートしており、このアーキテクチャは、おそらく必然性と確率の両方のために、ファームウェアの問題を再検討し、「次世代」ファームウェアを探求するため、2020年代の業界にとって重要な基盤です。

業界は2010年代からさまざまなファームウェアセキュリティオプションを模索し始めています。UEFIの検証済みブートソリューションの1つは、「セキュアブート」とも呼ばれ、署名を検証するための信頼チェーンを構築し、マーケティングで広く普及しています。もう1つのオプションはMeasuredBootですが、「セキュアブート」としてはあまり知られていません。TXT (ユーザーが DRTM を使用する場合) と TCG 仕様に基づくその他の機能をサポートするチップセットの数は限られているため、UEFI で実装するのは難しいためです。 2016年、ヘッジファンドTwo Sigmaの研究者であるTrammell Hudsonは、メジャーブートを含むいくつかのセキュリティ機能を備えたheadsと呼ばれるLinuxベースのペイロードを開発し、それをcorebootでロードするというLinuxBIOSの哲学を利用しました。これにより、UEFIエコシステムが数年間低コストで解決するのに苦労してきた問題が解決され、業界は1999年版の「次世代ファームウェア」アーキテクチャに基づいて構築を続けています。 2017年、Googleとヘッドコミュニティは、PEIを保持し、DXEを最小限に抑えてUEFIファームウェアと互換性のあるものにするモードを使用するNERFと呼ばれるペイロードを共同で開発しましたが、再配置の問題により一部のマシンモデルでは機能しませんでした。NERFのもう一つの特徴は、ユーザランドがGo Runtimeに基づいていることであり、興味深いことに、Linuxベースのペイロードスキームをより標準化された段階、LinuxBootに引き上げようとするNERF’の試みです。

上の図からわかるように。「次世代ファームウェア」アーキテクチャであるLinuxBootは、1999年のLinuxBIOSの哲学的アイデアを超えていませんが、その目標はより多くのハードウェア初期化ファームウェアソリューションをサポートすることです。

VaultBoot: ゴンドールの心

VaultBootは、ファームウェアセキュリティ、トラステッドコンピューティング、高度な脅威保護に重点を置いたファームウェアペイロードです。VaultBoot は、CBnT やその他の大量の ACM のプロビジョニング段階で協力するコリブートと連携する場合、最大のメリットをもたらします。

VaultBootはOEMのUEFIファームウェアとも互換性があります。HardenedVault は、ヘッドコミュニティの長期的な貢献者です。したがって、VaultBootのパブリックバージョンはヘッドに基づいていますが、VaultBootはLinuxBootとも互換性があり、CとGoの両方のランタイム環境を提供します。

VaultBootの主な機能:

*検証済みの起動。UEFIサークルではセキュアブートとしても知られているこの機能は、署名されたカーネルとそれに付随するデータ(initrdなど)のみを通常のブートプロセスでブートするためにロードできることを意味します。UEFIサークルでは、署名はカーネルの同じファイルに格納する必要があるため、専用のツールが必要で、署名プロセスが操作しにくいです。Vaultbootでは、署名検証プロセスはバンドルされたgnupgツールによって行われます。 公開鍵を含む専用のgnupgキーチェーンをinitrdにバンドルすることができます。OSのカーネル、initrd、ブート設定は、スマートカードに格納された対応する秘密鍵によってsigedされ、署名は別々のファイルとしてブートパーティションに格納され、カーネルファイル自体を変更することなく、次の署名プロセスをOSで行うことができます。署名が無効になると、自動ブート プロセスが中断され、Vaultboot は管理者が手動で OS を起動したり、署名チェーンを修正したりするための回復シェルを提供します。

*測定されたブーツ。メインボードにTPMが装備されている場合は、ロードするすべてのコンポーネント(ペイロードを含む)を測定するためにcorebootを構築することもできます。Vaultboot は、TPM (1 または 2) 機能を使用して構築することもできます。その場合は、コアブートが自身を測定するために使用する PCR に対して、ランダムなシークレットを TPM に封印し、管理者が検証できるようにブート プロセスでランダムなシークレットを TOTP として提示できます。ファームウェアが変更されると、PCR が変更され、ファームウェアの意図しない変更について管理者に警告するために、管理者によって検証された封印されたシークレットを TPM から封印解除できなくなります。これは、ローカル構成証明の一形態である可能性があります。ブートプロセスで TOTP を検証するのが不便な場合は、リモート構成証明を使用できます。シークレットの封印解除に失敗した場合、自動ブートプロセスは中断され、回復シェルが提供されます。

*Vault_SMM。これは HardenedVault が開発した独自の強化モードであり、チップセットが提供する強化機能のペイロード ステージへの有効化を遅らせ、VaultBoot は SMM を使用して操作を実行します。保守性も考慮に入れながらセキュリティを確保し、この設計は2019年にLinuxBIOSの創設者によって承認されました。VaultBootは、セキュリティ強化のみを目的として高リスクの特権モードとしてSMMを使用しますが、このソリューションを利用するにはcorebootと連携する必要があることは注目に値します。

• TPMベースのFDE(フルディスク暗号化)。TPM が使用可能で、OS にブート プロセス中にロックを解除する LUKS がある場合、Vaultboot はランダムなキーを LUKS に追加し、そのキーを TPM に (パスフレーズの有無にかかわらず) 封印できます。キーの封印が正常に解除できた場合、Vaultboot は OS の initrd をその tmpfs にコピーし、コピーされた initrd にキーとクリプトタブ項目を追加し、変更された initrd で OS を起動するため、ブート プロセス中にキーによって LUKS のロックが解除されます。キーを追加すると、LUKS ヘッダーが測定され、ロック解除キーがシールされている PCR の 1 つである PCR になります。したがって、ファームウェアまたはLUKSヘッダーが変更された場合、キーはもう封印されず、自動ブートプロセスは中断されます。もちろん、ファームウェアが更新されたり、LUKS ヘッダーがユーザーによって意図的に変更された場合、LUKS のロックを解除して新しいキーを追加する他の手段があれば、LUKS 用に新しいキーが生成されて封印される可能性があります。

*ハードウェア内蔵の鍵交換によるパラメータ暗号化。TPMv2 では、TPM 内で生成されたキーと交換されるセッション キーを使用して、機密性の高いパラメーター (シール/シール解除するプレーンテキストなど) を暗号化する新機能が導入されました。Vaultbootはこの機能を利用して、TPM Genieなどの物理的な攻撃を防御します。

• インテルCSME。ユースケースによって異なります。詳しくは研究報告書をお読みください。

まとめ

ファームウェアは、オペレーティングシステムが配置されているRING 0よりも高いレベルで動作します。ユーザーの脅威モデルに攻撃者の永続性が含まれている場合、ファームウェアのセキュリティを無視することはできません。この分野の攻撃的側面と防御的側面の両方が、業界の注目を集めています。米国国立標準技術研究所(NIST)は、ファームウェアのセキュリティに関する4つの特別出版物を発行しました。

• NIST SP 800-147: BIOS 保護ガイド, 4月 2011
• NIST SP 800-155: BIOS インテグリティ測定ガイド、2011 年 12 月
• NIST SP 800-147B: サーバー BIOS 保護ガイド, 2014 年 8 月
• NIST SP 800-193: BIOS プラットフォームファームウェアレジリエンスガイド, May 2018

2021年5月26日、米国サイバーセキュリティ・インフラ安全保障局(CISA)は、RSA 2021カンファレンスでVBOS(OSの下の脆弱性プログラムを発表しました。ファームウェアレベルは過去15年間に停止したことがない。VBOSプログラムは、秘密の戦争を今、テーブルの上に引きずり出している。EUには、米国のような体系的なファームウェアセキュリティコンプライアンスガイドラインはありませんが。しかし、欧州委員会は、2014年に開始されたHorizon 2020を通じて、多数のオープンソースチップおよびファームウェアセキュリティプロジェクトに資金を提供してきました。 ドイツ連邦情報セキュリティ局(BSI)は、オープンソースファームウェアのサポートとフォローアップ作業を繰り返し公に言及しています。2019年、BSIはドイツのセキュリティベンダーであるgenua GmbH(番号BSI-DSZ-CC-1085-2019)のネットワークセキュリティ製品を認定し、オープンファームウェアシステムをサポートしました。

高度な脅威保護の世界的な傾向の中で、ファームウェアは全体的な防御の中核の1つです。VaultBootは、現在の攻撃対象領域に基づいていくつかのセキュリティ機能を開発しました。HardenedVaultは現在、x86用のKabyLake/CoffeeLakeサーバープラットフォーム用のセキュリティファームウェアソリューションを提供しており、arm64のサポートは2022年度にリリースされる予定です。