ロックまたはロック解除のいずれかに設定できる新しい概念であるSDV ブートモードは、安全なメッシュを確立するために他のサービス検出エージェント（他の SDV VM で実行）に接続しようとするときに、SDV VM 内の SDV サービス検出エージェントがどのように動作するかを定義します。これは、Android 確認付きブートの既存のデバイス状態の概念 に似ています。
SDV ブートモードは、車両 VM トラスト ストア のプロビジョニング時または更新時に利用されます。
SDV 安全なメッシュの動作
サービス検出メッシュは、受信するブート値に応じて、正常、警告、致命的のいずれかの状態になります。
車のメッシュが「正常」状態の場合にのみ、車が所有者の手に渡ります。 診断介入なしにメッシュが「正常」状態から「警告」状態に移行することはできません。本番環境（開発/デバッグ以外）では、「警告」はプロビジョニング中にのみ発生します。
「致命的」は、Android ブートローダーで system_ext イメージの署名検証が失敗するのと同様の基本的な障害です。SDV
メッシュが無線（OTA）アップデートのみが原因で「正常」から「致命的」に移行した場合、そのアップデートは不良と見なされ、元の「正常」バージョンに戻ります。
以降のセクションでは、これらの状態について詳しく説明します。
正常
- サービス検出の観点から見ると、システムのブートは
SECUREです。 - サービス検出は、安全にブートされたと見なされるピアとのみ接続します。その結果、サービス検出は、自身が属する SDV 安全なメッシュが安全であると見なします。
警告
- 一部の検証が無効になっているため、システムのブートが侵害されている可能性があります。
- サービス検出は、同じ検証が無効になっているピアとのみ接続します。したがって、サービス検出は、自身と同じセキュリティ プロパティを持つ SDV 安全なメッシュの一部です。
- ピアのブートが正常に完了したか失敗したかは、ローカルでの障害や無効化が原因で確認できません。
- 開発環境や状況以外では、次のような影響があります。
- ユーザーデータは使用できません。つまり、SDV 安全なメッシュを介した通信によって送信されたり、影響を受けたりしてはなりません。
- メッシュがこの状態の場合、プロビジョニング フローに必要なサービスのみを使用可能にする必要があります。
致命的
- システムのブート ステージで重大なエラーが発生しました。
- サービス検出エージェントがメッシュを確立できない基本的な障害またはエラーが少なくとも 1 つあります。ローカル サービスがリモート サービスと通信することはできません。
- サービス検出の観点から見ると、システムのブートは UNSECURE です。
SDV ブートモード
SDV ブートモードには、ロック解除 とロック の 2 つの値があります。サービス検出メッシュの確立に関して、ロックモードでは検証エラーは致命的ですが、ロック解除モードでは致命的ではありません。
SDV ブートモードは、Android のデバイス状態（AVB モード）とは異なります。SDV ブートモードは、SDV 安全なメッシュの動作と、メッシュ接続エラーが致命的かどうかを制御します。AVB モードは、Android ブートローダーによる検証が致命的かどうかを決定します。
| 条件 | SDV ブートモード | |
|---|---|---|
| ロック解除 | ロック | |
| ローカル VVM トラスト ストアが空 | 警告 | 致命的 |
| ローカル DICE チェーンがない | 致命的 | 致命的 |
| ローカル DICE チェーンの検証に失敗した | 警告 | 致命的 |
| ローカル SDV モードと AVB モードが一致する | 表を参照 | |
| リモート デバイスモードの値の比較 | 表を参照 | |
リモート uds_pubs の一致に失敗した |
警告 | 致命的 |
| リモート DICE チェーンの検証に失敗した（DICE ポリシーを使用） | 警告 | 致命的 |
| リモート認証ハンドシェイクに失敗した | 致命的 | 致命的 |
ローカル SDV モードと AVB モードが一致する
次の表に、AVB モードと SDV ブートモードが SDV 安全なメッシュの動作に与える影響を示します。色は、AVB ドキュメントの Android 固有の 統合セクションで定義されているとおりです。
| AVB モード x SDV ブートモード | SDV ブートモード | ||
|---|---|---|---|
| ロック解除 | ロック | ||
| AVB ロック | 緑 | 警告 | 正常 |
| 黄 | 致命的 | 致命的 | |
| AVB ロック解除 | オレンジ | 警告 | 致命的 |
Device Mode の値
DICE チェーンでは、すべての CDI 証明書にモード値があります。これは、構成入力に基づいてそのレイヤのセキュリティ状態を記述するために使用されます。デバイス上のすべてのソフトウェアのセキュリティ スタンスを表すために、デバイスモードの値 が定義されます。これは、特定の SDV VM（ Android HLOS と Secure World）に関連する DICE チェーンのすべての CDI ステージのモード値から派生し、次のように定義されます。
enum DeviceMode {
NotConfigured = 0,
Recovery = 1,
Debug = 2,
Normal = 3,
}
アルゴリズム
deviceModeをDeviceMode::Normalに設定します。diceChainListを SDV VM に関連する DICE チェーンのリストにします。diceChainListの各diceChainについて:cdiListをdiceChain内の CDI 証明書のリストにします。cdiListの各cdiCertについて:cdiDeviceModeをcdiCert.modeに対応するDeviceModeにします。deviceModeをmin(deviceMode, cdiDeviceMode)に設定します。
deviceModeを返します。
リモート デバイスモードの値の比較
サービス ディスカバリ Agent は、自身と同じ Device Mode Valueを持つ他の Agent とのみ接続します。
デバイスモードの値により、メッシュに異なるセキュリティ プロパティを持つメンバーを含めることはできません。したがって、結果として得られるメッシュは、すべてのメンバー間でセキュリティ スタンスが均一になります。
| Device Mode の値 | リモート | ||||
|---|---|---|---|---|---|
| 未構成 | デバッグ | 復元 | 標準 | ||
| ローカル | 未構成 | 致命的 | 致命的 | 致命的 | 致命的 |
| デバッグ | 致命的 | 警告 | 致命的 | 致命的 | |
| 復元 | 致命的 | 致命的 | 警告 | 致命的 | |
| 標準 | 致命的 | 致命的 | 致命的 | 正常 | |
出荷時プロビジョニング フロー
これは、車両組立ラインでのプロビジョニング フローです。公開鍵インフラストラクチャは使用できないものとします。
このフローは、VVMFactoryTrust という 1 回限りのプログラマブル（OTP）メモリに保存された 32 バイトの値に依存します。この値が設定されると、androidboot.sdv.vvmfactorytrust
という名前のパラメータとしてカーネルに渡されます。
ECU 内のすべての VM は、同じ SDV ブートモードと VVMFactoryTrust を持つ必要があります。
初期状態
すべての ECU は、最初は SDV ブートモードがロック解除され、VVMFactoryTrust と
VVMTrustStoreは空です。ただし、uds_certsが
VVMTrustStore に存在する可能性があります。
図 1 は、2 つの個別の ECU（ECU-0 と ECU-1）に分散された 3 つの SDV VM（VM-A、VM-B、VM-C）の例を示しています。
ステップ 1: sdv_provisioning_tool を実行する
すべての ECU からすべての VM を起動します。
各 VM で次の操作を行います。
sdv_provisioning_toolを実行します。- このツールはローカル サービス検出エージェントと通信し、SDV 安全なメッシュが完了したことを示すシグナルを待機します。エージェントは UDS 公開鍵のリストを
/vvmtruststore/uds_pubsに書き込みます。 - この処理が完了すると、ツールは書き込まれたばかりの
/vvmtruststore/uds_pubsのハッシュを取得して出力します。
- このツールはローカル サービス検出エージェントと通信し、SDV 安全なメッシュが完了したことを示すシグナルを待機します。エージェントは UDS 公開鍵のリストを
ステップ 2: VVMFactoryTrust を書き込む
各 ECU の 1 つの VM で次の操作を行います。
- 前のステップで
sdv_provisioning_toolによって出力された/vvmtruststore/uds_pubsのハッシュを VVMFactoryTrust に書き込みます。この書き込み方法は OEM/ベンダー固有であるため、この仕様の範囲外です。
ステップ 3: SDV ブートモードをロックして再起動する
すべての ECU のすべての VM を SDV ブートモードをロックして再起動します。
サービス検出エージェントは、uds_pubs にリストされている UDS 公開鍵を持つ ECU 内の VM を信頼します。このファイルのハッシュは VVMFactoryTrust
と一致するためです。
ECU はまとめてプロビジョニングされたため、永続的にバインドされています。したがって、DICE チェーンの検証の観点から見ると、1 つのハードウェアとして効果的に見なすことができます。
部品交換フロー
これは、認定された自動車修理工場またはガレージでのプロビジョニング フローです。故障した ECU を、プロビジョニングされていない新しい ECU に交換する必要があります。
このフローは、vvmconfig に記載されているルート
認証局によって直接発行される UDS 証明書、または
中間認証局のチェーンを介して間接的に発行される UDS 証明書に依存します。
初期状態
すべての VM はすでに工場出荷時にプロビジョニングされており、SDV ブートモードがロックされた状態で実行されています。
図 5 は、ECU-0 が故障しているため、交換する必要がある例を示しています。
ステップ 1: 新しい ECU をインストールする
新しい ECU をインストールします。これは、空のプロビジョニングされていない状態になります。
図 6 では、ECU-2（交換用 ECU）の電源がオンになると、2 つの分離した SDV 安全なメッシュ（1 つは警告状態、もう 1 つは正常状態）があります。 どちらの SDV 安全なメッシュも不完全です。
ステップ 2: SDV ブートモードをロック解除して再起動する
すべての ECU のすべての VM を SDV ブートモードをロック解除して再起動します。
図 7 では、VM-B と VM-C が警告状態の SDV 安全なメッシュに参加し、メッシュが完成します。
ステップ 3: sdv_provisioning_tool を実行する
各 VM で sdv_provisioning_tool を実行します。
このツールはローカル サービス検出エージェントと通信し、SDV 安全なメッシュが完了したことを示すシグナルを待機します。エージェントは UDS 公開鍵のリストを /vvmtruststore/uds_pubs に書き込みます。
この処理が完了すると、ツールは書き込まれたばかりの /vvmtruststore/uds_pubs のハッシュを取得して出力しますが、このハッシュはこのフローでは使用されません。
ステップ 4: UDS 証明書をインストールする
- 任意の SDV VM から
/vvmtruststore/uds_pubsを抽出します。同じ SDV 安全なメッシュ内のすべての VM で同じになるため、どれでもかまいません。 /vvmtruststore/uds_pubsにリストされているすべての UDS 公開鍵のプロビジョニング証明書を取得します。- 通常、これは、証明書がすでに保存されているか、受信した公開鍵を既知の UDS 公開鍵のデータベースと照合して証明書を生成するリモート サーバーに送信することを意味します。このデータベースは、ECU の製造時に抽出された UDS 公開鍵から構築されます。
- 各 SDV VM の
/vvmtruststore/uds_certsを書き込みます。
ステップ 5: SDV ブートモードをロックして再起動する
SDV ブートモードをロックしてすべての VM を再起動します。
なんらかの理由で SDV 安全なメッシュが不完全な場合は、ステップ 2 に戻ります。