Quantum Sea

タグ: Caliptra

  • ASPEEDが示すCaliptra、BMCの起動・更新・復旧をどう守るか

    ASPEEDが示すCaliptra、BMCの起動・更新・復旧をどう守るか

    サーバーの状態を見守り、離れた場所から管理するBMC。そのBMC自身が、正しいファームウェアで動いているかを確かめるには、どこを信頼の起点にすればよいのでしょう。起動するソフトウェアに、自分の正しさをすべて任せるわけにはいきません。

    ASPEEDのChiawei Wang氏とNeal Liu氏は、2026年8月のOCP APAC Summitで、Caliptraを組み込んだ管理用半導体の構成を紹介しました。資料は、起動時の検証から、更新、古い版への巻き戻し防止、復旧までをつなげています。［1］

    簡単にまとめると？

    • BMCの信頼を支えるには、起動するコードを段階ごとに検証し、次の処理へ引き渡す仕組みが必要です。
    • 更新データの署名確認と、古い版へ戻さないための確認は役割が異なり、復旧用のコードにも検証が必要です。
    • AST2700とAST1080は同じ用途のチップではありません。Caliptraの版や組込み方も分けて読む必要があります。

    起動する側より先に、確かめる側を動かす

    Caliptraは、半導体に組み込むRoot of Trust（信頼の起点）の仕組みです。ASPEEDの構成図では、ROMや記憶領域を土台に、iRoTと呼ぶ内部の信頼基盤、その中で暗号処理や検証を担うCaliptraが描かれています。BMCの通常の仕事と、起動や更新を確かめる仕事を分けた構成として読むことができます。［1］

    起動の順序を示すのが図1です。最初に、書き換えられないSoCのROMから処理を始め、Caliptraのリセットを解除します。続いて、SoCで最初に書き換え可能なコードであるFMC（First Mutable Code）を読み、実行前に署名を検証する流れです。iRoTのファームウェアもCaliptraへ送って確認してから起動し、最後にBMCの通常の処理へ渡します。［1］

    図の階段は、チップの物理的な積層ではなく、検証しながら処理を引き渡す順序を表しています。最初の段階から次の段階を確かめ、その先へ信頼をつなぐ考え方です。

    SoCのROM、CaliptraとSoCの最初の書換え可能コード、iRoT、BMCファームウェアの順に、実行前の検証を経て処理を渡す四段階を示すASPEEDの図。物理的な積層ではなく起動の順序を表す。
    図1　ROMからBMCファームウェアへ、検証を経て処理を渡す順序。Chiawei Wang、Neal Liu（ASPEED Technology）「Caliptra Silicon Root of Trust in BMC SoCs」、OCP APAC Summit、2026年8月、p.6「The Chain of Trust Staircase」。原資料／図を拡大する

    署名が正しいことと、使ってよい版であること

    動き始めた後の更新にも、確認する場所が要ります。資料の更新フローでは、外部から届いたファームウェアを、まず隔離したDRAMの一時領域へ置きます。登録された公開鍵情報に基づく署名検証を経て、認められた内容をSPIフラッシュへ書く構成です。ネットワークから受け取ることと、起動に使う記憶領域へ書き込むことの間に、検証の段階を置いています。［1］

    ただし、署名が正しいだけでは、古い脆弱な版へ戻される問題は防げません。過去に正規の提供元が署名したファームウェアでも、現在の運用で受け入れてよいとは限らないためです。

    ASPEEDの資料は、OTPという一度の書込みを前提にした領域に支えられたSVN（Security Version Number）を使い、必要な値に届かないイメージを拒否する方式を説明しています。署名によって出所と内容を確かめる役割と、受け入れるセキュリティ上の版を制限する役割を組み合わせています。［1］

    外へ示す測定結果と、復旧するときの検証

    起動を認める判断とは別に、機器の状態を外部へ示す仕組みもあります。資料の遠隔証明の図では、外部ホストからのSPDM要求に対し、Caliptra側が測定値を扱い、暗号学的に署名した応答を返します。SPDMは、機器どうしが識別情報や測定情報をやり取りするための仕組みです。［1］

    ここで区別したいのは、コードの実行を認めることと、測定した状態を相手へ示すことです。署名された測定結果が得られても、その後のあらゆる動作や設定変更が安全だと証明されたわけではありません。今回のスライドには、運用中の全状態を網羅した検証結果は示されていません。

    通常の起動へ進めない場合に備えるのが、復旧の経路です。資料では、SoCのROMが復旧状態を検知し、外部ホストから復旧用ファームウェアを受け取ります。その署名を実行前に確認し、復旧用の処理から通常のA/Bイメージを戻す流れになっています。復旧のためだから確認を省くのではなく、戻すためのコードも確かめる設計です。［1］

    AST2700とAST1080は、役割を分けて読む

    発表は二つの製品を並べていますが、AST2700はサーバー管理用のBMC SoC、AST1080はPRoT（Platform Root of Trust、プラットフォームの信頼の起点）を担うSoCです。公式製品ページもこの用途を分けており、AST1080をAST2700と同じBMCとして扱うと構成を読み違えます。［2］［3］

    講演資料の比較表では、AST2700のCaliptra IPは1.2で、BootMCUがCaliptraブロックへの主な仲介を担います。AST1080は2.1で、Subsystem方式を組み込み、iRoTがCaliptraのSSMCU上で動くと説明されています。同じCaliptraという名前でも、採用する版と周辺の制御構成は同一ではありません。［1］

    これらは2026年8月の発表で示された構成です。資料には攻撃への耐性試験の成功率、起動の所要時間、復旧時間を比較できる実測値はありません。「信頼の起点を搭載した」という情報から、どの製品でも同じ保護範囲や運用結果が得られるとは判断できません。

    BMCのセキュリティを見るときは、採用チップ名だけでなく、起動のどの段階を誰が確かめるか、更新をどこで止められるか、復旧用のコードをどう認めるかまで追うと、設計の役割が見えてきます。ASPEEDの発表は、その受け渡しを一つの管理用半導体の構成として読むための材料です。

    ASPEEDの事業を知る

    サーバー管理向け半導体を手がけるASPEEDの事業全体は、Cyclewaveの企業解説で紹介しています。

    ASPEEDの企業解説を読む

    参考資料

    1. Chiawei Wang、Neal Liu（ASPEED Technology）「Caliptra Silicon Root of Trust in BMC SoCs」、2026年8月、全16ページ。構成と起動はpp.4–6、遠隔証明・更新・版戻し防止・復旧はpp.7–10、製品の比較はp.12。OCP公式の資料一覧。講演音声・質疑は対象に含めていません。
    2. ASPEED「AST2700」公式製品情報。サーバー管理用プロセッサーとしての位置づけとCaliptraの採用。2026年10月7日確認。
    3. ASPEED「AST1080 PRoT」公式製品情報。PRoT向けSoCとしての位置づけ。2026年10月7日確認。
  • Googleが示すCaliptraのプロビジョニング、製造時に整える識別情報と証明書

    Googleが示すCaliptraのプロビジョニング、製造時に整える識別情報と証明書

    サーバーの起動時にファームウェアの署名を確かめるには、最初に信頼する情報が必要です。その鍵は誰が設定したのか。このチップは、製造時に登録された個体と同じなのか。確認をさかのぼると、データセンターへ届く前の工程に行き着きます。

    2026年8月のOCP APAC Summitで、GoogleのZachary Halvorsen氏とTimothy Trippel氏は、Caliptra Subsystemのプロビジョニングを説明しました。プロビジョニングはここでは、チップ固有の情報や起動時の検証に使う情報を設定し、試験・製造の状態から運用できる状態へ進める作業を指します。［1・2］

    簡単にまとめると？

    • Caliptraの製造時設定は、チップ固有の情報と検証の仕組みを整え、本番へ引き渡す工程です。
    • 個体識別の秘密をチップ内に保ち、証明書を求める情報を外へ出す役割を分けます。
    • 参照コードの公開と、各製品の製造工程が完成・検証済みであることは別です。

    信頼の起点にも、最初の設定がある

    Caliptraは、SoCに組み込むオープンソースのRoot of Trust（信頼の基点）です。機器の識別、起動するファームウェアの測定、その状態を暗号学的に示す証明などを支えます。今回の発表は、Caliptraのコアに制御用のMCUなどを組み合わせたSubsystemを、製造工程でどう準備するかが主題です。［2・4］

    設定する情報には、役割の違うものが含まれます。チップ固有の秘密、ファームウェアの検証に使う公開鍵に対応したハッシュ値、工程を進めるためのトークン、証明書を作るための属性などです。これらは、OTP（One-Time Programmable）と呼ばれる一度の書き込みを前提にしたヒューズ領域などへ、定められた状態で設定します。秘密鍵をすべて外から書き込む、という仕組みではありません。［2・3］

    UDSは、外へ渡す証明書とは役割が違う

    UDS（Unique Device Secret）は、その個体を暗号学的に識別するための秘密の起点です。Caliptraでは、ヒューズに保持するUDSのシードをもとに、デバイスの識別鍵を導出します。起動時の測定と識別情報を結びつけるDICE（Device Identifier Composition Engine）の仕組みも、この起点につながります。［2・4］

    一方、IDevID（Initial Device Identifier）は、製造時に確立するデバイス識別情報です。CaliptraのROMが識別鍵を導出し、その公開側の情報を含むCSR（Certificate Signing Request、証明書署名要求）を作ります。外へ取り出すのはこの要求であり、IDevIDの秘密鍵そのものではありません。公式仕様では、その秘密鍵を外部へ公開しない設計が求められています。［4］

    この区別は製造工程を読むうえで大切です。チップの中に保つ秘密と、相手へ示せる証明書は、同じ「識別に使う情報」でも扱いが違います。

    試験、製造、本番へ、状態を進める

    発表は製造の流れを、大きくRaw、Test、Manufacturing、Productionの四段階で説明しています。Rawはまだ設定されていない状態。Testではチップの試験と工程用トークンの設定を行い、ManufacturingでUDSや証明書に関わる準備を進めます。Productionは本番運用へ引き渡す段階です。［2］

    単に作業者が工程名を書き換えるわけではありません。ライフサイクル状態によって、デバッグで触れる範囲や、書き込めるヒューズが変わります。資料は、いくつかの状態遷移でパスワードに似たトークンを要求する流れを示しています。公式ガイドによれば、状態はヒューズに記録され、チップをリセットしても前の状態には戻りません。四段階の説明の内側には複数の試験状態があり、返却解析などの別経路も用意されています。［2・3］

    つまり、製造時には試験に必要なアクセスを確保し、そのまま本番へ持ち越さないようにする設計です。「本番状態になったから、あらゆる検査用の経路が永久になくなる」とも言い切れず、許可されたデバッグや返却時の扱いは、状態と権限を分けて読む必要があります。

    証明書の発行は、チップの外にもつながる

    製造工程の図では、チップがIDevIDのCSRと、その真正性を確かめるためのHMAC（鍵付きのメッセージ認証コード）を出力します。製造側のHSM（Hardware Security Module）がHMACを検証し、証明書の発行を支えます。HSMは、こうした処理で使う鍵を保護する専用の装置です。発行した証明書は、個体情報のデータベースへ登録する流れになっています。［2・3］

    ここで目指しているのは、受け取った要求に無条件で署名することではありません。正しい製造経路から来た要求かを確かめ、どの個体の証明書なのかを記録し、その後の運用へ渡せるようにすることです。チップの内部の保護に加え、証明書を発行する側の鍵と記録も、信頼をつなぐ役割を持ちます。

    工場で決める情報と、運用者が加える情報

    発表資料は、設定を製造時と運用段階に分けています。製造時にはUDS、ベンダーのファームウェア検証に関わる情報、工程やデバッグのトークン、IDevID証明書の属性などを準備します。運用側には、追加の乱数材料であるField Entropy、古い版への巻き戻しを防ぐための情報、鍵の管理、所有権移転などに関わる設定があります。［2］

    Productionへ進んだ後も、所有者が認可されたコマンドで必要な設定を行う、というのが発表の流れです。ただし、ヒューズを通常の設定ファイルのように何度でも書き直せるわけではありません。公式ガイドは、運用中に変更できる領域とロック条件を区別しています。どの情報を工場で確定し、どれを所有者に残すかは、製造と運用をつなぐ設計事項です。［2・3］

    参照コードの公開と、製品への組み込みは分けて見る

    講演が提供予定として挙げたのは、状態遷移を行うJTAGスクリプト、UDS設定やCSR取得を担う製造用ファームウェア、運用中の設定変更を認可するMCUファームウェアです。スライドの最終説明では、これらの成果物は開発中と明記されています。［2］

    その後、公式リポジトリでは2026年8月24日にMCU Runtime SDKの2.0と2.1向け初回リリースが公開され、2.1の説明には製造用のヒューズ設定ファームウェアも含まれています。一方、9月26日に確認したプロビジョニングガイドには、共通の参照フローや支援ツールを開発中とする記述が残っています。公開されたコードがあることと、各製品の製造工程が完成・検証済みであることは分けて考えたいところです。［3・5］

    今回の発表が示すのは、信頼の基点を載せるだけでなく、その個体を登録し、検証に使う情報を設定し、権限を切り替えて引き渡すまでのつながりです。製造者と運用者がこの境目を共有できれば、サーバーが届いた後に「何を根拠に信頼するのか」を、より具体的に確かめられます。

    Googleを含むAlphabetの事業を知る

    Googleは、検索やYouTube、企業向けクラウドなどを手がけるAlphabet傘下の企業です。cyclewaveでは、広告が生む収益と、クラウドや計算基盤への投資を、会社全体の数字から整理しています。

    Alphabetの企業解説へ

    参考資料

    2026年9月26日確認。公式スライド全17ページ、製造フロー図、Caliptraの公開仕様・ガイド・リリース記録を照合しました。講演動画の音声・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題・登壇者・公式資料への導線。

    ［2］Google「Caliptra Subsystem Provisioning」公式掲載スライド。設定対象はpp.2–4、状態と製造フローはpp.5–12、参照コードと開発段階はpp.13–15。

    ［3］CHIPS Alliance「Caliptra Subsystem Provisioning Guide」。ヒューズ、ライフサイクル、CSRの認証、製造後の設定制約。製造インフラの個別認証を保証する文書ではありません。

    ［4］CHIPS Alliance「Caliptra」公開仕様。UDS、IDevID、DICE、秘密鍵の扱い。閲覧時点のmainブランチを参照しています。

    ［5］CHIPS Alliance「caliptra-mcu-sw」リリース一覧。2026年8月24日公開のrt-sdk-2.0.0／rt-sdk-2.1.0と、製品ごとの組み込みが必要な参照SDKとしての位置づけ。