データセンターの電源や冷却を制御する機器は、表示が正常でも、起動に使ったファームウェアまで正しいとは限りません。長く使われる設備ほど、機器の設計や更新方法もそろっていないことがあります。では、制御機器が信頼できる状態で起動したかを、どこで確かめればよいのでしょう。
2026年8月のOCP APAC Summitで、GoogleのMiguel Osorio氏は、電源・冷却・建物制御などのOT(Operational Technology)機器に外付けの信頼の起点を加える設計案を示しました。ポイントは、起動する機器自身に確認を任せきりにせず、別の部品が起動コードを測定し、その結果を運用側でも照合できるようにすることです。[1・2]
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では、広告が生む収益と、クラウドや計算基盤への投資を、会社全体の数字から整理しています。
参考資料
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 公開リポジトリ。プロジェクトの公開状況を参照。講演中の将来提供日程とは区別しています。

コメントを残す