Quantum Sea

タグ: セキュアブート

  • 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のeRoT提案、制御機器の起動を外部の信頼基点で確かめる

    GoogleのeRoT提案、制御機器の起動を外部の信頼基点で確かめる

    データセンターの電源や冷却を制御する機器は、表示が正常でも、起動に使ったファームウェアまで正しいとは限りません。長く使われる設備ほど、機器の設計や更新方法もそろっていないことがあります。では、制御機器が信頼できる状態で起動したかを、どこで確かめればよいのでしょう。

    2026年8月のOCP APAC Summitで、GoogleのMiguel Osorio氏は、電源・冷却・建物制御などのOT（Operational Technology）機器に外付けの信頼の起点を加える設計案を示しました。ポイントは、起動する機器自身に確認を任せきりにせず、別の部品が起動コードを測定し、その結果を運用側でも照合できるようにすることです。［1・2］

    簡単にまとめると？

    • GoogleのeRoT案は、CPUとは別の信頼基点で、CPUを動かす前に最初の起動コードを測定します。
    • 起動状態を遠隔で照合できても、その後の設定変更や動作中の侵害まで安全と証明するものではありません。
    • 更新は未使用の記憶領域へ準備して切り替える提案で、無停止や必ず復旧できることを保証していません。

    CPUが動き出す前に、最初のコードを測る

    講演が提案するのは、CPUとは別に置くeRoT（external Root of Trust）です。Root of Trustは、鍵や測定値をより信頼できる場所に置き、ほかの確認を始めるための基点を指します。スライドの構成例では、eRoTが起動用のA/B二つのEEPROM、切り替え回路、CPUのリセット信号につながります。これはすべてのOT機器が同じ配線になるという意味ではなく、外付け部品を使う一つの設計です。［2］

    この構成では、まずeRoTが使うEEPROMを選び、CPUの最初に書き換え可能なコード（First Mutable Code）を測定します。その値をTPMのPCR（Platform Configuration Register）へ取り込んでから、CPUのリセットを解除します。CPU自身が動いたあとで初めて測る方式と比べ、最初の書き換え可能な段階を測定に含めやすいのが狙いです。スライドはこの順序を示していますが、機器に実装した際の測定範囲は構成ごとに確かめる必要があります。［2］

    ここで二つの働きを分けておくと、話が追いやすくなります。検証起動（verified boot）は、署名や許可された鍵・版を調べ、認められないコードを起動させないための仕組み。測定起動（measured boot）は、起動時に使ったコードの測定値を後から照合できるように残す仕組みです。Googleの資料は、鍵や許容するファームウェア版を記したプラットフォーム・マニフェストと、この二つの働きを組み合わせる案を示しています。［2］

    測定値は、離れた運用側でも照合する

    起動時に値を記録するだけでは、その値が期待どおりか分かりません。講演は、OpenConfigのAttestZを遠隔証明の例に挙げます。機器がTPM内の鍵で署名したquoteとPCRの値を送り、運用側のサービスが証明書と署名を検査し、あらかじめ登録した期待値と比べる流れです。OpenConfigの公開文書はネットワークスイッチの管理を対象にしています。講演が示したOT機器への適用案そのものが、すべての設備で実装済みというわけではありません。［2・3］

    証明できる範囲にも線があります。講演スライドには「ランタイムの完全性」を示唆する記述がありますが、AttestZの公開文書が勧める測定範囲は、最初の命令から静的なルートファイルシステムまでの起動状態で、動作中の変化は対象外です。したがって、起動状態の照合に成功しても、その後の設定変更や実行中の侵害まで安全だと証明されたことにはなりません。［2・3］

    更新は、使っていないEEPROMに先に書く

    起動を測れても、ファームウェアの更新で動いている領域を直接書き換えると、途中で失敗したときに戻しにくくなります。発表資料の更新案では、ホスト側から専用のUSB経路でeRoTへ新しいデータを送り、使用中ではないEEPROMに新しい内容を準備します。暗号学的な検証を経て、次の起動でA/Bの選択を切り替え、起動が成功した後に新しい側を確定する手順です。使用中の領域を保ったまま準備する考え方ですが、更新中も停止が一切ないことや、失敗から必ず復旧できることを保証するものではありません。［2］

    共通の接続口は、提案を使いやすくするために

    eRoTをさまざまな制御機器へ広げるには、チップだけでなく接続の仕方も大切です。スライドは、DC-SCM基板とRoT Add-In Moduleをつなぐ公開済み設計に触れ、複数のRoT実装を受け入れられる接続を目指すと説明しています。機器のたびに基板を設計し直す負担を減らす、という方向です。ただし、この講演は個々のOT機器での互換性試験や運用実績を示したものではありません。［2］

    OpenPRoTのコードは公開されていますが、講演が掲げる参照スタックの提供時期は、2026年第4四半期の初期版と2027年第2四半期の広い利用を目指す予定です。すでに完成した製品や、すべてのOT機器で使える確定仕様として読むのは早いでしょう。実際の導入では、どの起動段階を測り、誰が期待値を管理し、更新失敗時にどこへ戻るかを、対象機器ごとに確認することになります。［2・4］

    今回の提案が見せるのは、「安全なチップを追加する」だけではない設計の順序です。起動前に測る。測った結果を離れた場所で確かめる。更新は別の領域に準備してから切り替える。この三つをつなぐことで、長く使う制御機器の信頼を、運用の中で確かめ続ける道が開けます。

    Googleを含むAlphabetの事業を知る

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

    Alphabetの企業解説へ

    参考資料

    2026年9月26日確認。講演スライド全26ページと公開文書を照合しました。講演動画の音声・質疑は確認対象に含めていません。

    ［1］Open Compute Project「2026 OCP APAC Summit」発表一覧。演題、登壇者、資料掲載。

    ［2］Google「Composable Security Architecture: Raising the Security Bar for Datacenter Operational Technology Appliances」公式掲載スライド。OTの対象はpp.3–6、eRoT・起動測定はpp.11–20、更新はpp.21–23、接続案と予定はpp.24–25。

    ［3］OpenConfig「AttestZ」公開文書。ネットワーク機器のTPM登録・遠隔証明と、静的な起動状態を中心とする測定範囲。

    ［4］CHIPS Alliance OpenPRoT 公開リポジトリ。プロジェクトの公開状況を参照。講演中の将来提供日程とは区別しています。