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

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

基盤: ドメイン分離

仮想化による共存インスタンスの分離

電子制御ユニット（ECU）を 1 つのチップに統合する現在の傾向により、複数のドメインを並行して実行することで分離が低下しています。

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

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

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

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

AAOS SDV は、Android のユーザー ID（UID）ベースの分離モデルに沿って、各アプリのサンドボックスをセットアップします。各サービスは、アクセス権、データ ディレクトリ、その他の制限を管理する一意の UID を持つ専用プロセスで実行されます。Portable Operating System Interface（POSIX）機能を使用してオペレーションを厳密に制限し、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 に書き込みパスが公開されません。攻撃者がルート権限を取得した場合でも、ファイル システム レイヤがすべての書き込みコマンドを拒否するため、実行中の APEX コードを変更することはできません。

2. 暗号の完全性

• メカニズム: 暗号署名により、ファイル システム イメージ全体の マークルツリーが検証されます。
• セキュリティが強化される理由: カーネルはブロック単位の 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 の暗号化されたハンドシェイクを組み合わせることで、受信側マシンは呼び出し元の 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 の概要ページをご覧ください。