近年、サイバー攻撃はますます高度化し、従来の署名検証だけでは守りきれない場面も現れています。
本稿では、その先の対策として注目される「遠隔アテステーション」に対応したセキュアブートの実現例を紹介します。
セキュアブートはファームウェアイメージの真正性を担保します。つまり「このイメージが信頼された鍵によって署名されている」ことを保証する仕組みです。
しかし、多くの現代のシステムではそれだけでは足りず、デバイスアテステーション（attestation）も必要とされるようになりつつあります。アテステーションは信頼する側（relying party）に対して、実際に何が起動しているのかを検証可能な形で証明する仕組みです。
このような証明は以下の場面で重要になります。
- デバイスをネットワークに登録する(オンボーディング)時
- ファームウェアの遠隔更新時
- デバイスのライフサイクル全体を通じて
そこで登場するのが DICE(Device Identifier Composition Engine)です。
DICEはデバイス固有の秘密値（UDS/HUK）とブートプロセスで取得された計測値(measurement)からデバイスのアイデンティティを構成します。これにより、ソフトウェア状態に暗号的に結び付けられたアテステーション情報が生成されます。もしメジャードブートの状態が変化すれば、導出されるアイデンティティ、あるいはアテステーション情報（アテステーションの証拠）もそれに応じて変化します。
wolfBoot はDICE ベースの PSA初期アテステーションをサポートします。
これにより、システムは ブートチェーンから直接PSA準拠の「アテステーション情報」を生成できます。
しかも、ブートローダーを大きなTEEプロジェクトにする必要はありません。
メジャードブートは、ブートチェーンに含まれる重要なコンポーネント（ブートローダやファームウェアイメージ、さらにアーキテクチャによってはその他の要素）のハッシュ値を記録します。
DICE はこの仕組みを土台として、これらの測定結果を実際に利用可能な情報（evidence）へと変換します。
- 安定したデバイス固有の秘密（UDS / HUK） は、デバイスのアイデンティティを物理デバイスそのものに結びつけます。
- 測定値（measurement） は、そのアイデンティティを実際に実行されたソフトウェアに結びつけます。
- その結果として生成されるのが、リモートから検証可能なアテステーショントークンです。
これにより、例えば次のようなポリシーを実現できます。
「このデバイスが承認されたファームウェアで起動した場合にのみ、ネットワークへの接続を許可する」
これは特に、ファームウェア更新、機能アンロック、プロビジョニング、サービスへのアクセスなどが、
単なる工場出荷時の一度きりのデバイスIDではなく、実際に証明された実行状態（proven state）に基づいて決定される場合に有効です。
- ファームウェア更新
- 機能のアンロック
- プロビジョニング
- サービスへのアクセス制御
wolfBoot が提供する DICEアテステーション
wolfBoot は、wolfCrypt を基盤としてファームウェア認証と安全な更新フローを実現する、
ポータブルでOS非依存のセキュアブートローダです。
DICEアテステーションの導入により、wolfBoot の役割は
– 「検証して起動する（verify and boot）」
という段階から、
-「検証し、計測し、証明する（verify, measure, and prove）」
という段階へと拡張されます。それでもなお、wolfBootでは、組込み機器の制約（限られたリソースやシンプルな構成）に適合する形を維持しています。
次に、wolfBootが提供する主な機能について紹介します。
PSA仕様に準拠した初期アテステーションAPI
wolfBoot は PSAの初期アテステーション(Initial Attestation)準拠の API を実装しています。
呼び出し元には 標準 PSA エントリポイント経由でアテステーショントークンを返却します。
TrustZone-M を用いた構成では、このトークンは セキュアワールドのサービスによって生成します。
これにより、鍵素材や署名処理は 非セキュアコードから隔離された状態で保持・実行されます。
COSE_Sign1 でラップされた EAT （PSA トークンプロファイル）
生成されるアテステーション情報（evidence）は、PSA Attestation Token Profile に従った EAT(Entity Attestation Token) で、COSE_Sign1 形式でラップされています。
これは製品開発チームにとって重要な点です。
というのも、この形式を採用することで、出力されるトークンが
- PSA互換の既存の検証システム（verifier）
- 既存のアテステーションパイプライン
と相互運用可能な形に保たれるからです。
実際のワークフローに適した「最小限のクレーム」
wolfBoot が生成するトークンには、多くの実運用環境で必要とされる主要なクレーム（claims）が含まれています。
- Nonce バインディング（challenge）
フレッシュネスを保証するため（リプレイ攻撃防止） - デバイス識別子（UEID）
デバイス固有のアイデンティティ - Implementation ID とライフサイクル情報
プラットフォームが提供している場合に含まれる - メジャードブートコンポーネント
wolfBoot 自体およびブート対象イメージの測定値
wolfBoot は、アテステーションのためだけに別の測定システムを用意する必要はありません。
トークンに含まれるコンポーネントの測定値は、通常のイメージ検証のためにすでに必要となるイメージハッシュ計算パイプラインをそのまま再利用しています。
各コンポーネントのクレームには次の情報が含まれます。
- 測定タイプ
- 測定値
- 短い説明文字列
これにより、検証側（verifier）はボード固有の知識に依存することなく、
「何が測定されたのか」を解釈できるようになります。
ビルド時に選択可能な鍵モデル
製品によってプロビジョニングのモデルが異なるため
wolfBootは2種類のアテステーション鍵方式をサポートします。
- DICE 導出鍵（外部プロビジョニング不要）
wolfBootはHALフックを使ってUDS/HUKベースの秘密を取得します。
そこからCDI, 署名された鍵をHKDFで導出します。
この方式ではデバイスごとの鍵インジェクションを使用しませんが、それでもハードウェア原点の秘密値、メジャードブートの計測値に基づくアイデンティティが確立されます。
- プロビジョンによる初期アテステーション鍵(IAK)
製造工程でIAKを安全なストレージに書き込む場合は、wolfBootはHALフック経由でIAKを取得しトークンに署名します。
いずれの場合も、署名処理は安全なドメイン内で実行します。
小さな HAL インターフェース、共有された実装
DICE の実装は “src/dice/” ディレクトリ配下に配置されており、複数のターゲット間で共有されています。
各ターゲットファミリは、自身のハードウェアでサポートされている HAL フックのサブセットを実装します。
例えば次のようなものがあります。
- UDS / HUK ベースの秘密値を取得または導出するためのフック
- UEID、Implementation ID、Lifecycle を提供するためのオプションのフック
- プロビジョニング済みの IAK を取得するためのオプションのフック（IAK モード）
デモ用途のために、wolfBoot には テスト専用のフォールバック機能も含まれています。
これは、明示的に有効化した場合に限り、デバイス UID から UDS を導出することができるものです。
この機能は素早く動作を確認するためには便利ですが、本番環境での利用は想定されていません。
UDS の保存方法：本番向けの OBKeys と、実用的な OTP
DICE は、安定したデバイス固有の素材（device-unique material）に依存しています。
wolfBootは、SoCが提供する機能に応じて複数の方法をサポートしています。
STM32H5のOBKeys UDS（利用可能な場合は推奨）
これに対応しているSTM32H5シリーズでは、OBKeys セキュアストレージが iRoT（Immutable Root of Trust）の鍵素材に適した保護領域を提供します。ここには デバイス固有の UDS も含めることができます。
この機能を有効にすると、STM32H5 の HAL はまずOBKeysからUDSを読み出すことを試みるようになり、
本番環境のプロビジョニングフローとも自然に整合する設計になっています。
OTP による UDS 保存（初期化アプリを利用した開発用途 + フォールバック）
wolfBootは、OTP keystoreの初期化アプリケーションを使用して、DICE アテステーション用のランダムなUDSをOTPに保存する方法もサポートしています。
この初期化アプリは、
- 専用の FLASH OTP 領域に公開鍵をプロビジョニングする
- DICE アテステーションを早期に立ち上げる
ためにも使用されます。そのため、OBKeysのプロビジョニングがまだ整っていない段階でも、DICEアテステーションを動作させるための実用的な手段になります。
この設計により、次のような段階的な導入が可能になります。
- 開発および初期統合段階
→ OTP を使用 - 本番環境でのハードニング
→ OBKeys（または別のセキュアストレージ機構）へ移行
wolfBoot：Zephyr の TEE スーパーバイザ
wolfCrypt により駆動され、wolfPSA から利用可能
DICE アテステーションは、明確なPSAクライアントモデルと組み合わせることで特に強力になります。
wolfBootはZephyrを使用したTrustZone-Mシステムにおいて、ARM TEEの代替として利用することができ、セキュア側のPSAプロバイダとして動作します。
このモデルでは次のようになります。
- wolfBootがセキュア側PSAサービスとCMSE veneers を提供する
- Zephyrのnon-secureアプリケーションが標準PSA APIを呼び出す
- wolfBootがセキュアドメイン内でそれらのリクエストを処理する
PSAモードが有効な場合、wolfBootは次の機能を提供します。
- PSA初期アテステーション（DICE トークン生成）
- PSA Crypto API（セキュアドメイン内でwolfPSAを介して提供、内部実装は wolfCrypt）
- PSA Protected Storage（同じセキュアサービスモデルを利用）
これは、PSA スタイルのポータビリティを確保しつつ、重いセキュアランタイムを導入したくないチームにとって非常に魅力的な構成です。一つの組込み可能コンポーネントである wolfBootによって、
- 安全なブート
- 安全なサービス
を統合した基盤を提供でき、しかもそれはwolfSSLの暗号スタック上に構築されています。
適用シナリオ：オンボーディング、フリート整合性、セキュアアップデートポリシー
DICE ベースのアテステーションにより、
「正しく起動したはずだ」
という状態から、
「何が起動したかを証明できる」
という状態へと移行できます。主な利用例としては次のものがあります。
- ゼロタッチ・プロビジョニング
承認されたブート状態を証明できたデバイスのみを受け入れる - ポリシー制御付きセキュアアップデート
アテステーションが成功した場合にのみ更新・機能フラグ・認証情報の配布を許可する - フリートコンプライアンス監視
デバイスが期待された状態を維持しているかを継続的に検証する - ロールバックや改ざんへの防御
メジャードブートの状態変化が verifier 側から検知可能になる
wolfBootを使い始める
wolfBootは、評価および統合のために wolfSSL GitHubで公開しています。
対応するMCU上での立ち上げを支援するドキュメントやターゲットガイドも用意しています。
商用ライセンス、長期メンテナンス、機能開発、あるいは既存のファームウェアパイプラインへのwolfBootの統合支援が必要な場合には、wolfSSLがライセンスおよびサポートを提供しています。
さらに詳しい情報は、弊社問い合わせ窓口info@wolfssl.jpまでお問い合わせください。
原文：https://www.wolfssl.com/wolfboot-adds-dice-and-measured-boot-via-psa-initial-attestation/