メッシュのステータスとプロビジョニング

SDV ブートモードは、SDV VM の SDV サービス ディスカバリ エージェントが、他のサービス ディスカバリ エージェント（他の SDV VM で実行）に接続して安全なメッシュを確立しようとするときにどのように動作するかを定義します。これは、Android 確認付きブートの既存のデバイスの状態のコンセプトに似ています。

SDV ブートモードは、車両 VM トラスト ストア（VVM トラスト ストア、vvmtruststore とも呼ばれます）をプロビジョニングまたは更新する際に使用されます。

SDV Secure Mesh の動作

Service Discovery メッシュは、受け取ったブート値に応じて、Normal、Warning、Fatal のいずれかの状態になります。

お客様に納車される量産車では、SDV Secure Mesh は Normal 状態である必要があります。メッシュでは、Normal 状態から Warning 状態に切り替えるために診断介入が必要です。本番環境（開発やデバッグなどではない）では、Warning 状態はプロビジョニング中にのみ発生します。

Fatal は、Android ブートローダーで system_ext イメージの署名検証が失敗するのと同様の基本的な失敗です。SDV Secure Mesh が無線アップデート（OTA）のみによって Normal から Fatal に移行した場合、アップデートは不良とみなされ、メッシュは元の Normal バージョンにフォールバックします。

以降のセクションでは、状態について詳しく説明します。

check 標準

• サービス ディスカバリの観点から見ると、システム起動は SECURE です。
• サービス ディスカバリは、安全に起動されたピアとのみ接続します。ピアが安全に起動された場合、SDV Secure Mesh も安全であることを意味します。

warning 事前警告

• 一部の検証が無効になっているため、システムの起動が侵害されている可能性があります。
• サービス検出は、無効な検証のまったく同じセットを共有するピアとのみ接続します。これにより、SDV Secure Mesh 内のすべてのピアが同じセキュリティ プロパティを共有します。
• ローカル エラーまたは無効な機能により、ピアブートの成功を確認できません。
• 開発環境や状況以外では、次のような影響があります。
  • ユーザーデータを利用できないようにする必要があります。つまり、SDV Secure Mesh を介した通信によって送信されたり影響を受けたりしてはなりません。
  • メッシュがこの状態の場合、プロビジョニング フローに必要なサービスのみが利用可能になります。

error Fatal

• システムの起動ステージで重大なエラーが発生しました。
• Service Discovery エージェントがメッシュを確立できない根本的な障害またはエラーが 1 つ以上あります。ローカル サービスがリモート サービスと通信できない。
• サービス ディスカバリの観点から見ると、システム起動は UNSECURE です。

SDV 起動モード

SDV ブートモードには、LOCKED と UNLOCKED の 2 つの値があります。サービス検出メッシュの確立では、LOCKED は検証エラーが致命的であることを示し、UNLOCKED は致命的でないことを示します。

ローカル SDV と AVB モードのマッチング

次の表に、AVB モードと SDV ブートモードが SDV セキュア メッシュの動作に与える影響を示します。色は、AVB ドキュメントの Android 固有の統合セクションで定義されているとおりです。

デバイスモードの値

DICE チェーンでは、すべての CDI 証明書にモード値があります。この値は、構成入力に基づいてそのレイヤのセキュリティ状態を表します。デバイス上のすべてのソフトウェアのセキュリティ スタンスを表すため、SDV 仕様では Device Mode の値を定義しています。この値は、特定の SDV VM（Android HLOS と Secure World）に関連する DICE チェーン内のすべての CDI ステージのモード値から導出され、次の列挙型を使用します。

enum DeviceMode {
  NotConfigured = 0,
  Recovery = 1,
  Debug = 2,
  Normal = 3,
}

アルゴリズム

Device Mode 値を計算するアルゴリズムは次のとおりです。

1. deviceMode を DeviceMode::Normal として指定します。
2. diceChainList を SDV VM に関連する DICE チェーンのリストとして指定します。
3. diceChainList の各 diceChain について:
   1. diceChain の CDI 証明書のリストとして cdiList を指定します。
   2. cdiList の各 cdiCert について:
      1. cdiCert.mode に対応する DeviceMode として cdiDeviceMode を指定します。
      2. deviceMode を min(deviceMode, cdiDeviceMode) に設定します。
4. deviceMode を返します。

リモート デバイス モードの値の比較

Service Discovery エージェントは、同じデバイスモード値を持つ他のエージェントとのみ接続します。

デバイスモードの値により、メッシュに異なるセキュリティ プロパティを持つメンバーが存在しないことが保証されます。結果として得られるメッシュでは、すべてのメンバー間でセキュリティ スタンスが統一されます。

工場でのプロビジョニング フロー

これは、公開鍵基盤が利用できないことを前提とした、車両組立ラインでのプロビジョニング フローです。このフローは、Vehicle VM（VVM）Factory Trust または vvmfactorytrust と呼ばれる 1 回限りのプログラマブル（OTP）メモリに保存された 32 バイトの値に依存します。設定すると、この値は androidboot.sdv.vvmfactorytrust という名前のパラメータとしてカーネルに渡されます。

ECU 内のすべての VM は、同じ SDV ブートモードと VVM ファクトリー トラストを備えている必要があります。

初期状態

すべての ECU は、vvmtruststore に存在する uds_certs を除き、最初は UNLOCKED モードの SDV ブートモードで、VVM ファクトリ トラストと車両 VM トラスト ストアは空です。図 1 は、3 つの SDV VM（VM-A、VM-B、VM-C）が 2 つの個別の ECU（ECU-0、ECU-1）に分散されている例を示しています。

図 1. 工場出荷時のプロビジョニング、初期状態。

ステップ 1: sdv_provisioning_tool を実行する

すべての ECU からすべての VM を起動します。

各 VM で sdv_provisioning_tool を実行します。

1. このツールはローカルの Service Discovery エージェントと通信し、SDV Secure Mesh が完了し、エージェントが UDS 公開鍵のリストを /vvmtruststore/uds_pubs に書き込んだことを示すシグナルを待ちます。
2. この場合、ツールは書き込まれたばかりの /vvmtruststore/uds_pubs のハッシュを取得して出力します。

図 2. ファクトリー プロビジョニング、ステップ 1。

ステップ 2: VVM Factory Trust を書き込む

各 ECU の 1 つの VM で:

1. 前の手順で sdv_provisioning_tool によって出力された /vvmtruststore/uds_pubs のハッシュを VVM Factory Trust に書き込みます。この書き込みの実行方法は OEM またはベンダー固有であり、この仕様の範囲外です。

図 3. ファクトリー プロビジョニング、ステップ 2。

ステップ 3: SDV ブートモードでロックして再起動する

LOCKED モードで SDV ブートモードのすべての ECU のすべての VM を再起動します。

このファイルは VVM Factory Trust と一致するため、Service Discovery エージェントは uds_pubs に記載されている UDS 公開鍵を持つ ECU の VM を信頼します。

ECU は一緒にプロビジョニングされるため、永続的にバインドされ、DICE チェーン検証の観点からは 1 つのハードウェアと見なすことができます。

図 4. ファクトリー プロビジョニング、ステップ 3。

部品交換のフロー

これは、認定された自動車修理工場またはガレージでのプロビジョニング フローです。ここでは、欠陥のある ECU を新しいプロビジョニングされていない ECU に交換する必要があります。

このフローは、vvmconfig で指定されたルート認証局によって直接発行された UDS 証明書、または中間認証局のチェーンを介して間接的に発行された UDS 証明書に依存します。

初期状態

すべての VM はすでに工場出荷時のプロビジョニングが完了しており、LOCKED モードで SDV ブートモードで実行されています。

図 5 は、ECU-0 が誤動作しており、交換が必要な例を示しています。

図 5. 部品交換、初期状態。

ステップ 1: 新しい ECU を取り付ける

新しい ECU を取り付けます。この ECU は空白のプロビジョニングされていない状態です。

図 6 では、ECU-2（交換用 ECU）の電源がオンになると、2 つの別個の SDV セキュア メッシュ（1 つは Warning 状態、もう 1 つは Normal 状態）が存在します。両方の SDV セキュア メッシュが不完全です。

図 6. 部品交換、ステップ 1。

ステップ 2: SDV ブートモードのロックを解除して再起動する

UNLOCKED モードで SDV ブートモードのすべての ECU のすべての VM を再起動します。

図 7 では、VM-B と VM-C が Warning SDV セキュア メッシュに参加し、完了しています。

図 7. 部品交換、ステップ 2。

ステップ 3: sdv_provisioning_tool を実行する

各 VM で sdv_provisioning_tool を実行します。

このツールはローカルのサービス ディスカバリ エージェントと通信し、SDV Secure Mesh の完了と、エージェントが UDS 公開鍵のリストを /vvmtruststore/uds_pubs に書き込んだことを示すシグナルを待ちます。

この場合、ツールは書き込まれたばかりの /vvmtruststore/uds_pubs のハッシュを取得して出力しますが、このハッシュはこのフローでは使用されません。

図 8. 部品交換、ステップ 3。

ステップ 4: UDS 証明書をインストールする

• 任意の SDV VM から /vvmtruststore/uds_pubs を抽出します。同じ SDV Secure Mesh 内のすべての VM で同じであるため、どちらでも構いません。
• その /vvmtruststore/uds_pubs にリストされているすべての UDS 公開鍵のプロビジョニング証明書を取得します。
  • この手順では通常、抽出した UDS 公開鍵（または /vvmtruststore/uds_pubs ファイル）をリモート プロビジョニング サーバーに送信します。サーバーは、既存の証明書を取得するか、ECU の製造時に構築された既知の UDS 公開鍵のデータベースと受信した公開鍵を照合して新しい証明書を生成します。
• 各 SDV VM の /vvmtruststore/uds_certs を書き込みます。

図 9. 部品交換、ステップ 4。

ステップ 5: SDV ブートモードで再起動する（ロック状態）

LOCKED モードで SDV ブートモードのすべての VM を再起動します。

SDV Secure Mesh が完了していない場合は、ステップ 2 に戻ります。

図 10. 部品交換、ステップ 5。