Quantum Sea

OCP APAC 2026 | Caliptraの製造時プロビジョニング、UDSと証明書の役割

淡青の核を内部に保ち、その特徴を外側の小さな形へ受け渡す抽象表現。チップ内の秘密と外へ示す識別情報の役割を表す概念画像。

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

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

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

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では、広告が生む収益と、クラウドや計算基盤への投資を、会社全体の数字から整理しています。

参考資料

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としての位置づけ。

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です