AAOS SDV - 安全性を重視した設計

Google は、製品は設計段階から安全であるべきだと考えています。そのため、ソフトウェア定義車両向け Android Automotive オペレーティング システム（AAOS SDV）は、Cuttlefish などの仮想化技術を活用し、既存の市場で実績のあるプラットフォーム上に構築されています。リリースのお知らせでは機能に焦点を当てていましたが、このブログ投稿ではセキュリティのコンセプトをいくつか紹介します。

基盤: ドメインの分離

仮想化による、共同ホスト型インスタンスの分離

電子制御ユニット（ECU）を 1 つのチップに統合する現在のトレンドでは、複数のドメインを並行して実行することで分離が軽減されます。

AAOS SDV インスタンスには内部分離メカニズムが用意されていますが、多くの場合、論理ドメインを独立して実行することが望ましいです。たとえば、クラスタとインフォテインメント システムでは要件が異なります。仮想マシンを使用して複数のインスタンスを並列で実行し、共有が明示的に行われ、分離がデフォルトの動作となるようにしています。

継承された Android のセキュリティ

AAOS SDV は、プライバシー仮想マシン（pVM）向けに最適化された最小限の Android バージョンである Microdroid から進化しました。この系譜により、Android プラットフォーム エンジニアは、すでに知っている確立されたセキュリティ機能を利用できます。

プロセス分離とデフォルトでの拒否

AAOS SDV は、Android のユーザー ID（UID）ベースの分離モデルに従って、各アプリのサンドボックスをセットアップします。各サービスは、アクセス権、データ ディレクトリ、その他の制限を管理する一意の UID を持つ専用プロセスで実行されます。Google は、POSIX（Portable Operating System Interface）機能を使用してオペレーションを厳密に制限し、これを Security-Enhanced Linux（SELinux）と組み合わせて「デフォルトで拒否」の体制を適用しています。このアプローチでは、各サービスを必要最小限に制限します。つまり、構成が不足していると、過度に寛容なシステムが作成されるのではなく、アクセスがブロックされます。この記事の後半で説明するように、Google はこの同じ戦略を通信権限システムに適用しています。

実績のある脆弱性の管理

AAOS SDV は、Android の成熟したセキュリティ対応と脆弱性の管理インフラストラクチャを統合して、セキュリティに関する検出結果の特定、トリアージ、修正、開示を行います。このライフサイクルには、継続的な自動スキャン、年 1 回の詳細なペネトレーション テスト、Android のセキュリティ脆弱性報告プロセスを通じたパートナー主導のインテリジェンスが組み込まれています。セキュリティ チームは、検出された脆弱性をトリアージし、リスクに基づいて重大度評価を割り当て、修復が完了するまで追跡します。Google は、毎月の Android セキュリティに関する公開情報を通じて開示とリリース ポリシーを調整し、厳格な定期セキュリティ監査と包括的なアーキテクチャ レビューによって補完することで、プラットフォームの長期的な復元力を確保しています。

整合性: 安全なソフトウェア デリバリー

安全なプラットフォームでは、プロセス分離を保証するだけでなく、実行前にコードの整合性を確保する必要があります。ソフトウェア デリバリーを保護するには、次のアプローチを使用します。

認証済みのソフトウェア デリバリー

AAOS SDV には 2 つのインストール方法があります。まず、ソフトウェアを読み取り専用のシステム、プロダクト、ベンダー パーティションに直接インストールします。これらのパーティションは、起動のたびに署名を検証します。これにより、基本的なシステム コンポーネントが保護されます。

次に、サービスに Android Pony EXpress（APEX）パッケージを使用します。各 APEX はソフトウェアとその依存関係をカプセル化し、パッケージを必須の署名検証を伴うパーティションとして扱います。AAOS SDV では、APEX はコード署名を継続的なハードウェア適用契約として扱います。APEX は、次の 4 つの主要な柱を通じて、悪意のあるコードの実行を軽減します。

1. 変更不可のストレージ

• メカニズム: Android カーネルは、読み取り専用ループバックを使用して、apex_payload.img ファイルを未加工のストレージ デバイスとして直接ループし、厳格な MS_RDONLY フラグでマウントします。
• より安全な理由: ファイルが車両のストレージに展開されないため、OS への書き込みパスが公開されません。攻撃者が root 権限を取得しても、ファイル システム レイヤですべての書き込みコマンドが拒否されるため、実行中の APEX コードを変更することはできません。

2. 暗号化の整合性

• メカニズム: 暗号署名により、ファイル システム イメージ全体の Merkle Tree が検証されます。
• セキュリティが強化される理由: カーネルは、ブロック単位の dm-verity を使用して、4 KB のデータブロックごとに署名をオンザフライで検証します。攻撃者がフラッシュ メモリ上の未加工のブロックを変更すると、カーネルはハッシュの不一致を検出し、実行を直ちに停止します。

3. 厳格な分離

• メカニズム: プロセス分離セクションで説明されているプロセス分離ルールを適用してサンドボックスを作成し、APEX を /apex の下の専用パーティションとしてマウントします。
• セキュリティが強化される理由: 各サービスは独自のユーザー ディレクトリとデータ ディレクトリを受け取るため、明示的に共有しない限りアクセスが制限されます。専用パーティションを作成することで、Android は専用のリンカー名前空間を確立し、明示的に公開されたライブラリのみが非特権システム デーモンからアクセスできるようにして、攻撃対象領域を最小限に抑えます。

4. アトミックな復旧

• メカニズム: APEX は「アクティブ/バックアップ」設計を使用して、ダブルバッファ ロールバックを可能にします。出荷時に書き込まれた APEX は不変の /system パーティションに残り、アップデートは可変の /data パーティションに保存されます。
• セキュリティが強化される理由: 更新が失敗した場合や、悪意のある更新であると思われる場合、apexd デーモンはアーリーブート中に更新を「失敗」としてマークします。システムは、シンボリック リンクを /system パーティションに即座にスワップします。このアトミックな復元により、システムが破損した状態のままになるのを防ぐことができます。

レジリエンス: メモリセーフな開発

検証済み読み込みは、外部からの変更からシステムを保護しますが、プラットフォームの復元力は、基盤となるコードのビルド方法にも依存します。AAOS SDV 向けに開発された新しいコンポーネントでは、メモリの安全性を優先しました。

メイン言語としての Rust

AAOS SDV は、迅速な可用性要件を持つ小規模なシステムを対象としています。これにより、完全な Android スタックでのビルドが妨げられるため、スコープをネイティブ フレームワークに限定しました。分散システムに必要なインフラストラクチャを作成するために、既存のインフラストラクチャに加えて複数のコンポーネントを開発し、Rust を主要な言語として採用しました。また、サービスのビジネス ロジックの開発にも Rust を使用しており、パートナーが安全なソフトウェアを作成できるように支援しています。Rust は、メモリ安全性の機能を活用して一般的なメモリ安全性の脆弱性を防止すると同時に、ネイティブ コードを記述する際のチームのスループットをサポートするように設計されています。

分散型信頼: ネットワークとアクセス制御

ソフトウェア定義自動車では、分離されたドメイン間の安全なやり取りが必要です。AAOS SDV メッシュ プロビジョニング アーキテクチャは、すべての通信エンドポイントのバージョンと作成者を暗号的に検証することで、この複雑さに対処します。

デバイスとメッシュのプロビジョニング

AAOS SDV Mesh は、すべてのコンポーネントのネットワーク ID を実際のバイナリ実行状態に数学的にバインドすることで認証を確立します。このモデルでは、暗黙的なソフトウェア信頼がハードウェア ルートの検証に置き換えられます。

メッシュ認証は、継続的かつ暗号化されるように設計されています。これにより、たとえば、車両ゲートウェイなどのサービスが、正しい IP アドレスを持っているという理由だけで、侵害されたインフォテインメント VM を信頼するようなシナリオを防ぐことができます。

ハードウェアによる分離と自動隔離プロトコルにより、プラットフォームが保護されます。SDV メッシュ内のピアデバイスは、次のセクションで詳しく説明するように、DICE ベースの認証と証明書を使用して、不正なコード実行や構成の改ざんを特定して封じ込めます。

VM 間の通信を保護する DICE ベースの TLS

ホストのアイデンティティを現実世界に根付かせる

DICE（デバイス識別子構成エンジン）の基本ルール: ファームウェアのコードが 1 行でも変更されると（マイナー アップデートや悪意のあるエクスプロイトでも）、派生した複合デバイス識別子（CDI）が完全に変更され、まったく異なるエイリアスキーが生成されます。

DICE と TLS（Transport Layer Security）を統合することで、ゼロトラスト アーキテクチャの根本的な課題である、マシンの認証とソフトウェアの完全性の検証を同時に行うことが可能になります。

DICE のハードウェア格納型識別と TLS の暗号化された handshake を組み合わせることで、受信側のマシンは呼び出し元の ID と正確なソフトウェア状態の両方を検証できます。

従来の証明書は、シークレットの所有を証明するだけで、ファームウェアの改ざんを検出することはできません。DICE は、メジャード ブートの階層化によってこの問題に対処します。

• 一意のデバイス シークレット（UDS）: 製造時に生成されるランダムな暗号シークレット。UDS にアクセスできるのは第 1 ステージのブートローダーのみで、他のすべてのソフトウェアや外部インターフェースからはアクセスできません。
• レイヤード測定（複合デバイス識別子）: ハードウェア ROM は、次のファームウェア レイヤの正確なコードと構成を使用して UDS をハッシュ化することで、チェーンを開始します。これにより CDI が作成され、後続の各レイヤが起動するたびに順次チェーンされます。

AAOS SDV メッシュ内のサービス インタラクションは、厳格なアクセス制御によって管理されます。すべての AAOS SDV ソフトウェアと同様に、これらのアクセス制御は認証され、その完全性はデバイスレベルで、またメッシュ内のデバイス間で DICE ベースの認証によって保護されます。

階層化されたアクセス制御

AAOS SDV は、アクセス メカニズムを損なうことなく、車両の動的な更新を可能にする多層防御戦略を採用しています。このモデルは、主に次の 2 つの信頼レイヤに依存しています。

1. サービスレベルの権限: 特定の VM 上のサービスがメッシュ全体でアクセスまたは公開できる特定のリソースを定義します。
2. VM レベルの権限: 特定の VM でホストされているすべてのサービスに対して、VM 間の通信境界を定義します。

このモデルにより、OEM はセキュリティと更新可能性のバランスを取ることができます。セキュリティに敏感でないサービスの場合、寛容な VM レベルのポリシーにより、VM の完全な再デプロイではなく、軽量の APEX アップデートを介してインストールできます。

逆に、セキュリティに敏感なシグナルの権限は、すべての VM にハードコードする必要があります。トレードオフとして、セキュリティに配慮したサービスを新しい VM に導入するには、VM レベルの権限をシステム全体で更新する必要があります。このため、メッシュ内のすべての VM を更新する必要があります。

まとめ

AAOS SDV は、Android のセキュリティ アーキテクチャを拡張し、セキュア バイ デザインのアプローチを通じて自動車固有の要件に対応します。このプラットフォームは、ドメイン分離に仮想化を活用し、「デフォルトで拒否」のアクセス ポリシーを適用することで、ソフトウェア定義自動車向けの復元力のある環境を構築します。暗号の整合性は、実行されたコードのハードウェアによるオンザフライ検証によって維持されます。

このプラットフォームは、プロアクティブな脆弱性の管理から DICE によるハードウェアベースの本人確認まで、継続的なセキュリティ ライフサイクルを統合します。これらの多層防御により、OEM は高度な機能の更新性と、最新の自動車環境に必要な堅牢なセキュリティのバランスを取ることができます。技術仕様と実装の詳細については、AAOS SDV の概要ページをご覧ください。