Microchip PolarFire SoC 上のファームウェアTPM 2.0（fTPM）

    • Microchip PolarFire SoC 向けに、wolfTPM のファームウェアTPM（fTPM）サンプルを追加するプルリクエストを公開しました。MPFS250T Video Kit 上でエンドツーエンドの動作を確認済みです。専用の RISC-V ハート上で TPM 2.0 サービス全体を動作させ、Linux から分離します。ディスクリートの TPM チップも、サードパーティ製の TEE も必要ありません。

    重要なポイント

    TPM を組み込む多くのケースでは、SPI/I2C 接続のディスクリートチップを載せるか、他社の TEE の内部に置かれたファームウェアTPM を使うかのいずれかが必要でした。今回ご紹介するのは第三の選択肢です。ハードマクロの RISC-V コア上で動作し、AMP パーティショニングによって分離され、M モードに収まるほど小さい、エンドツーエンドでお客様自身が掌握できる TPM 2.0 サービスです。コードサイズは約 200 KB に収まり、セキュリティチップもベンダー提供のバイナリも介さずに、Linux へ TPM 相当の鍵保管、シーリング、アテステーションを提供します。

    wolfTPM の fTPM を採用する理由

    どのターゲットでも同一の fwtpm ライブラリを使用可能です。TPM 2.0 のコマンドディスパッチ、TIS プロトコル、NV ジャーナル、および FWTPM_NV_HAL / FWTPM_CLOCK_HAL / FWTPM_TIS_HAL の各インターフェースは、デスクトップ版や STM32H5 版と同一です。新しいデバイスへ移植する際は、3 つの小さな HAL シム（ストレージ、クロック、トランスポート）とスタートアップファイルを用意するだけで済み、TPM そのものを設計し直す必要はありません。

    この移植性は実証済みです。同一のコアを ARM TrustZone（STM32H5）、AMP 構成の RISC-V ハート（今回の移植）、Cortex-R5 のロックステップ構成（Xilinx ZCU102）で動作させています。wolfTPM であるため、SPDM で保護されたセッション（v1.84）や、耐量子暗号の ML-DSA / ML-KEM（v1.85）も、監査可能なソースコードを提供する単一のベンダーから入手できます。

    構成

    PolarFire SoC は 4 つの U54 アプリケーションコアと、1 つの E51 モニタコアを搭載しています。Microchip の HSS が AMP ペイロードを起動します。

    • E51: HSS モニタ
    • U54 ハート 1〜3: Linux（OpenSBI 上の S モード）と Yocto ルートファイルシステム
    • U54 ハート 4: fwTPM サーバー。M モードのベアメタルで動作し、0x91C00000 にロード

    Linux からハート 4 へは、0x08000000 から始まる L2 LIM 上に配置した共有メモリのメールボックス、コンソールリングバッファ、TIS レジスタブロックを介してアクセスします。

    0x08000000  mailbox      (64 B   - cmd/rsp + boot/trap debug)
0x08000040  console ring (4 KB   - server stdout via /dev/mem)
0x08001040  TIS regs     (~8 KB  - regs + cmd/rsp FIFOs)

    LIM は Linux のシステム RAM マップに含まれないため、CONFIG_STRICT_DEVMEM=y の標準カーネルのままでも /dev/mem からメールボックスを読み取れます。カーネルの再ビルドは不要です。デバイスツリーへの変更は、ハート 4 を解放する小さなオーバーレイのみです。

    トランスポートはビルド時に選択できます（FWTPM_XPORT）。デフォルトのキャッシュ可能な L2 LIM メールボックスは HSS の AMP 構成でコヒーレンシが保たれ、そのまま動作します。メールボックスを完全にキャッシュの外へ置きたい設計向けには、非キャッシュの DDR エイリアス経路を検証済みの代替として同梱しています。

    スモークテスト

    サンプルには root 権限で実行する 2 つのスクリプトが付属します。fwtpm_mbox_dump.py は、メールボックス、ブート進行マーカー、M モードのトラップ情報（mcause/mepc/mtval）、および取得したコンソールリングをデコードします。UART を引き出していない環境でも、サーバーがどこまで進んだかを正確に確認できます。fwtpm_smoke.py は、まずサーバーが動作していることを確認し（フェーズ 1）、続いてメールボックス経由で TIS トランザクションを実行します（フェーズ 2）。このとき、サーバーが読み返して送り返すノンスを毎回更新することで、ハート 4 が古いキャッシュラインではなく新しい書き込みを参照していることを確認しています。

    エンドツーエンドでの動作

    Linux とハート 4 の往復通信は実機で動作しています。デフォルトのビルドのまま、特別な設定を加えることなく、両フェーズが再現性をもって成功します。

    エントロピーはデフォルトで安全な構成としました。make を実行するだけで、System Controller のハードウェア TRNG を唯一のエントロピー源として DRBG をシードします（FWTPM_RNG=SCB_NONCE）。この動作は Video Kit 上で検証済みです。立ち上げ初期向けに MTIME のジッタを用いるシードも用意していますが、明示的に指定した場合のみ有効になる開発専用の機能としました。意図せず出荷されることはなく、デフォルトのビルドが弱いシードになることもありません。

    今後の展開

    現在、fwTPM はハードマクロの U54 アプリケーションコア上で動作しています。次の大きな一歩は、これを真のファブリック上の Root of Trust にすることです。MPFS250T の FPGA ファブリックに Microchip の Mi-V RISC-V ソフトコアを実装し、その上で fwTPM を動作させます。ハードマクロの U54 クラスタはこれまでどおり Linux を実行し、Mi-V コアは自身のバスマスタを備えた専用のセキュリティプロセッサとして、プログラマブルロジック内に置かれます。アプリケーションコードと同じシリコンを共有することはありません。

    fwtpm ライブラリは移植性が高いため、この移行で新たに必要になるのは主にトランスポート HAL とスタートアップファイルであり、TPM 2.0 のコア部分は変更しません。狙いは PolarFire のハードウェアセキュリティブロックとの連携です。System Controller の TRNG からエントロピーを取得し（実装済み）、SRAM-PUF にデバイス固有のルート鍵を紐付け、User Crypto（Athena TeraFire）プロセッサへ暗号処理をオフロードし、NV 状態を sNVM のセキュアストレージに保持します。これにより、ソフトコア上の fwTPM は、ファブリック内で自己完結した耐タンパ性のある Root of Trust になります。

    このほか、以下をロードマップに挙げています。

    • FWTPM_NV_HAL の背後に永続 NV を実装し（sNVM の完全性鍵と QSPI のバルク領域）、電源を切っても鍵が残るようにする
    • 耐量子暗号: ML-KEM / ML-DSA を有効化し、ターゲット上でベンチマークを取得する
    • 割り込み駆動のドアベルを追加し、リクエストの合間は TPM コアをスリープさせる
    • wolfBoot を用いた構成に対応する。wolfBoot が HSS を置き換えて E51 上の SBI を担当し、SBI ドアベルと計測ブートを実現する

    ディスクリートチップや閉じた TEE を載せる余裕はないものの、TPM 2.0 の鍵保管、シーリング、アテステーションが必要な設計であれば、これがひとつの答えの形になります。すでに出荷されている RISC-V SoC 上でエンドツーエンドに動作しており、次はソフトコアによるファブリック上の Root of Trust へ進みます。サンプル一式は GitHub で公開しています。お使いのデバイスでの立ち上げについては、お気軽にご相談ください。

    参考

    もし弊社製品についてご質問があれば、お問い合わせ窓口info@wolfssl.jpまでご連絡をお願い致します。

    原文：https://www.wolfssl.com/firmware-tpm-2-0-ftpm-on-microchip-polarfire-soc/