このガイドでは、Android 互換性テスト スイート (CTS) によって評価されるセキュリティ パッチを適用するために Google が推奨するベスト プラクティスについて説明します。自動車、テレビ、セットトップボックス、家電製品など、3年以上サポートされるAndroid互換のOEM機器（メーカー）を対象としている。このガイドは、エンド ユーザー (車両所有者など) を対象としたものではありません。
承認と免責事項
このガイドは、Google やその他のメーカーを法的または契約的に拘束するものではなく、一連の要件を定めることを目的としたものではありません。むしろ、このガイドは推奨される実践方法を説明するための教材です。
フィードバック
このガイドは包括的なものではありません。追加の改訂が計画されています。フィードバックをmakers-guide-android@googlegroups.comに送信してください。
用語集
| 学期 | 意味 |
|---|---|
| ACC | Android 互換性への取り組み。以前は Android 断片化防止協定 (AFA) として知られていました。 |
| AOSP | Android オープンソース プロジェクト |
| ASB | Android セキュリティ速報 |
| BSP | ボードサポートパッケージ |
| CDD | 互換性定義文書 |
| CTS | 互換性テストスイート |
| フォタ | 無線ファームウェア |
| GPS | 全地球測位システム |
| ミスラ | 自動車産業ソフトウェア信頼性協会 |
| NIST | 米国国立標準技術研究所 |
| OBD | オンボード診断 ( OBD-II は、機能と標準化の両方において OBD-I よりも改良されています) |
| OEM | OEMメーカー |
| OS | オペレーティング·システム |
| セイ | ソフトウェア工学研究所 |
| SoC | システムオンチップ |
| SOP | 生産開始 |
| SPL | セキュリティパッチレベル |
| TPMS | タイヤ空気圧監視システム |
Android OSについて
Android は、さまざまなデバイスやフォーム ファクター向けに設計された、オープン ソースの Linux ベースのフル ソフトウェア スタックです。 2008 年の最初のリリース以来、Android は最も人気のあるオペレーティング システム (OS) となり、 世界中で 14 億台以上のデバイスに搭載されています (2016 年)。 2017 年 3 月の時点で、これらのデバイスの約 67% が Android 5.0 (Lollipop) 以降を使用しています (より新しい数値はAndroid ダッシュボードで入手できます)。デバイスの大部分は携帯電話とタブレットですが、Android はスマートウォッチ、テレビ、車載インフォテインメント (IVI) デバイスで成長しています。
Google Play ストアで利用できる Android アプリの数は220 万以上(2016 年) に達しました。 Android アプリ開発は、Android 互換性プログラムによって支援されています。このプログラムは、互換性定義ドキュメント (CDD)を介して一連の要件を定義し、互換性テスト スイート (CTS)を介してテスト ツールを提供します。 Android 互換性プログラムにより、Android アプリは、アプリに必要な機能をサポートする Android 互換デバイス上で確実に実行できます。
Google は、新しい OS バージョン、OS セキュリティ アップデート、発見された脆弱性に関する情報を定期的にリリースします。メーカーは、Android OS をサポートする製品に対するこれらのアップデートの適用可能性について、 Android セキュリティ情報を確認する必要があります。 Android のセキュリティ、互換性、ビルド システムのレビューについては、次を参照してください。
コネクテッドビークル（正規の長寿命製品）について
1920 年代の AM ラジオの導入により、車両が接続され始めました。そこから、規制当局や自動車メーカーが診断とサービス (OBD-II ポートなど) を容易にし、安全性を向上させ (TPMS など)、燃費目標を達成するためにエレクトロニクスに注目するにつれて、外部の物理接続と無線接続の数が増加し始めました。 。次のコネクティビティの波では、リモート キーレス エントリー、テレマティクス システム、Bluetooth、Wi-Fi、スマートフォン プロジェクションなどの高度なインフォテインメント機能などのドライバーの便利な機能が導入されました。現在、統合されたセンサーと接続性 (GPS など) が安全性と半自動運転システムをサポートしています。
車両接続の数が増加すると、潜在的な車両の攻撃対象領域の面積も増加します。接続には、家庭用電化製品と同様のサイバーセキュリティ上の懸念が集まります。ただし、再起動、毎日のパッチ更新、および原因不明の動作は家庭用電化製品では一般的ですが、自動車などの安全性が重要なシステムを備えた製品では矛盾しています。
メーカーは、現場での製品の継続的なセキュリティと安全性を確保するために、積極的なアプローチを講じる必要があります。つまり、メーカーは製品の既知のセキュリティ脆弱性を認識し、リスクベースのアプローチでそれらに対処する必要があります。
長期的なセキュリティを確保
コネクテッド ビークルには、OS、ライブラリ、ユーティリティなどの複数のソフトウェア コンポーネントを含む 1 つ以上の電子制御ユニット (ECU) が搭載されていることがよくあります。メーカーは、そのようなコンポーネントを追跡し、次のような事前分析によって既知の公開された脆弱性を特定する必要があります。
- Common Vulnerabilities and Exposures (CVE) データベースに対して製品を定期的に評価します。
- 製品関連のセキュリティ上の欠陥に関する情報収集。
- セキュリティテスト。
- Android セキュリティ速報を積極的に分析しています。
OS とセキュリティ パッチの更新例 (Android を実行している IVI):
図 1.車両の耐用年数にわたる主要な OS およびセキュリティ更新プログラムのサンプル。
| # | ステップ | 活動内容 |
|---|---|---|
① | 開発ブランチ | メーカーは Android のバージョン (Android X) を選択します。この例では、「Android X」が、最初の生産開始 (SOP) の 2 年前に車両に搭載されるものの基礎となります。 |
| ② | 初回起動 | Android X が製品に同梱される最初の OS バージョンになる数か月前に、セキュリティ アップデートは Android Security Bulletins (ASB) や、メーカーが価値があると判断したその他のソースから取得される可能性があります。 y2 = Android バージョン X の 2 番目のセキュリティ情報。メーカーによって Android X に適用 (バックポート) されます。このアップデートは製品に同梱されており、Android X.y2 では製造時計がゼロ年から時を刻み始めます。 この例では、メーカーは最新の Android X+1 年次リリースを出荷しないことを決定しました。最新リリースを出荷する理由には、新機能の追加、新しいセキュリティ脆弱性への対処、新しい Android バージョンを必要とする Google サービスやサードパーティ サービスの出荷などが含まれます。最新リリースでの出荷に反対する理由は、すべての規制要件と認証要件への準拠を含め、変更を統合、テスト、検証するために必要な車両の開発および発売プロセスに固有の時間が不足していることです。 |
| ③ | OSの完全アップデート | SOP 後、メーカーは Android X+2 OS アップデートをリリースします。これは、初期製品 (Android X0) に使用されたバージョンから 2 つ後の Android リリースです。 ASB セキュリティ アップデートは API レベル (出荷日現在) で利用できるため、アップデートは SOP から約 1.25 年後に X+2.y0 として発行されます。この OS アップデートは、フィールド製品と互換性がある場合とない場合があります。そうであれば、配備された車両を更新するための計画を作成できる可能性があります。 他のビジネス上の契約が締結されていない限り、完全な OS アップデートを行うかどうかは完全にメーカーの裁量に任されています。 |
| ④ | セキュリティアップデート | 車両の生産寿命から 2 年が経過し、メーカーは Android X+2 OS にパッチを適用しました。この決定は、メーカーのリスク評価に基づいています。メーカーは、リリース X+2 の 3 番目の ASB セキュリティ アップデートをアップデートのベースとして選択します。セキュリティ アップデートを受け取る製品は、現在 (X+2.y3) OS + Android セキュリティ パッチ レベルです。 メーカーは個別の ASB から個別のセキュリティ パッチを選択できますが、セキュリティ情報に関連付けられた Android セキュリティ パッチ レベル (SPL) (たとえば、2017-02-05) を使用するには、セキュリティ情報で必要な問題をすべて修正する必要があります。サポートされている製品のバックポートとセキュリティ リリースを実行するのはメーカーの責任です。 |
| ⑤ | OSの完全アップデート | ステップ 3 (完全な OS アップデート) を繰り返し、2 回目の完全な OS アップデートにより、製品は Android X+4 に引き上げられ、車両の生産耐用年数が 3 年になります。メーカーは現在、最新の Android バージョンの新しいハードウェア要件と製品のハードウェアのバランスを調整しており、ユーザーは更新された Android OS から恩恵を受けることができます。メーカーはセキュリティ更新なしで更新をリリースするため、製品は現在 (X+4.y0) OS + Android セキュリティ パッチ レベルになります。 この例では、ハードウェアの制限により、X+4 がこの製品に提供される Android の最後のメジャー バージョンですが、車両の予想耐用年数は 6 年以上あり、依然としてセキュリティ サポートが必要です。 |
| ⑥ | セキュリティアップデート | 手順 4 (セキュリティ更新) を繰り返します。メーカーには、Android のかなり新しいバージョン (X+6) から ASB セキュリティ アップデートを取得し、それらのアップデートの一部またはすべてを Android X+4 に移植するという任務があります。更新をマージ、統合、実行する (またはサードパーティと契約する) のは製造元の責任です。また、メーカーは、サポートされなくなった Android のバージョンのセキュリティ問題は ASB でカバーされていないことを認識する必要があります。 |
| ⑦ | セキュリティアップデート | 車両の生産ライフサイクルが開始されてから 8 年が経過し、ステップ 5 (フル OS アップデート) の最後の OS アップデート以降 4 回の Android リリースがあり、Android X が指定されてから 10 年が経過しており、セキュリティ パッチのキュレーションとバックポートの負担は完全にメーカーにあります。 API レベルの公開リリースから 3 年以上前のバージョン。 |
セキュリティのベストプラクティス
セキュリティの侵害をより困難にするために、Google では、 「セキュリティの実装」で説明されているように、セキュリティとソフトウェア エンジニアリングに関して一般的に受け入れられているベスト プラクティスの使用を推奨および採用しています。
セキュリティガイドライン
セキュリティに関して推奨される方法は次のとおりです。
- 最新バージョンの外部ライブラリとオープンソース コンポーネントを使用します。
- OS のリリース バージョンには、侵入的なデバッグ機能を含めないでください。
- 使用されていない機能を削除します (不要な攻撃対象領域を減らすため)。
- 最小特権の原則とその他のAndroid アプリ開発のベスト プラクティスを使用します。
ソフトウェア開発ガイドライン
システムのライフサイクルにわたって安全なソフトウェア開発を行うために推奨される実践方法は次のとおりです。
- 脅威モデリングを実行して、資産、脅威、および潜在的な緩和策をランク付けして特定します。
- アーキテクチャ/設計レビューを実行して、安全で健全な設計を確保します。
- 定期的にコードレビューを実行して、アンチパターンやバグをできるだけ早く特定します。
- 次のような高コード カバレッジの単体テストを設計、実装、実行します。
- 機能テスト (ネガティブなテストケースを含む)
- 定期的な回帰テスト (修正されたバグが再発しないことを確認するため)
- ファズテスト (単体テストスイートの一部として)
- 静的ソース コード分析ツール (スキャン ビルド、lint など) を使用して、潜在的な問題を特定します。
- AddressSanitizer、UnknownBehaviorSanitizer、FORTIFY_SOURCE (ネイティブ コンポーネント用) などの動的ソース コード分析ツールを使用して、システム開発中の潜在的な問題を特定して軽減します。
- ソフトウェアのソース コードとリリース構成/バージョンの管理戦略を立てます。
- ソフトウェア パッチの生成と展開のためのパッチ管理戦略を立てます。
セキュリティバックポートポリシー
Google は現在、発見および報告されたセキュリティ脆弱性のセキュリティ バックポートに対して、 API レベルの公開リリースから 3 年間、アクティブなサポートを提供しています。アクティブ サポートは以下で構成されます。
- 脆弱性レポートを受信して調査します。
- セキュリティ更新プログラムを作成、テスト、リリースします。
- セキュリティ更新プログラムの定期的なリリースとセキュリティ情報の詳細を提供します。
- 確立されたガイドラインに従って重症度評価を実行します。
API レベルの公開リリース日から 3 年後、Google は次のガイドラインを推奨します。
- API リリースから 3 年以上前の OS セキュリティ アップデートのバックポート サポートには、サードパーティ (SoC ベンダーやカーネル プロバイダーなど) を使用します。
- サードパーティを利用して、公的に提供されている ASB を使用してコード レビューを実行します。 ASB は現在サポートされているバージョンの脆弱性を特定しますが、メーカーは提供された情報を使用して、新しくリリースされたアップデートを以前のバージョンと比較する場合があります。このデータを使用して影響分析を実行し、API リリースから 3 年以上前の OS バージョンに対して同様のパッチを生成できる可能性があります。
- 必要に応じて、セキュリティ アップデートを Android オープンソース プロジェクト (AOSP) にアップロードします。
- メーカーは、ベンダー固有のコード (独自のデバイス固有のコードなど) のセキュリティ更新プログラムの処理を調整する必要があります。
- メーカーは、NDA Android Security Bulletin Partner Preview 通知グループに参加する必要があります (開発者 NDA などの法的契約の署名が必要です)。速報には次の内容を含める必要があります。
- お知らせ
- CVE や重大度など、パッチ レベルごとの問題の概要
- 必要に応じて脆弱性の詳細
追加の参考文献
安全なコーディングとソフトウェア開発の実践に関する手順については、以下を参照してください。
- Motor Industry Software Reliability Association (MISRA) 。
- Software Engineering Institute (SEI) のツールとメソッド。
- 米国標準技術研究所 (NIST)。
推奨される製品の実践方法
Google では、次の推奨方法の使用を推奨しています。
一般的な発売ガイドライン
一般に、接続されている製品は最新の OS バージョンで起動することが推奨されており、メーカーは製品を起動する前に最新の OS バージョンの使用を試みる必要があります。テストと検証の前に安定性を高めるにはバージョンをロックダウンする必要がありますが、メーカーは、古い OS バージョンから得られる製品の安定性と、既知のセキュリティ脆弱性が少なくセキュリティ保護が強化された新しい OS バージョンとのバランスを取る必要があります。
推奨されるガイドラインは次のとおりです。
- 車両開発プロセスに特有の開発リードタイムが長いため、メーカーは OS バージョン n-2 以前で発売する必要がある場合があります。
- 無線 (OTA) キャンペーンを使用して、リリースされた Android OS バージョンごとに Android 互換性への準拠を維持します。
- 迅速で顧客フレンドリーなアップデートを実現するために、製品 Android Firmware-over-the-Air (FOTA) 対応を実装します。 FOTA は、コード署名や製品と IT バックオフィス間の TLS 接続などのセキュリティのベスト プラクティスを使用して実行する必要があります。
- 独自に特定した Android セキュリティの脆弱性を Android セキュリティ チームに提出します。
注: Google では、Android セキュリティ情報でデバイスの種類や業界固有の通知を検討しています。ただし、Google は特定のデバイス (自動車、テレビ、ウェアラブル、電話など) のカーネル、ドライバー、チップセットを知らないため、デバイスの種類に応じて特定のセキュリティ問題にラベルを付ける決定的な方法を持っていません。 。
製品サイクルのガイドライン
メーカーは、製品サイクルの機能強化中に、最新の OS バージョンまたは使用中のバージョンのセキュリティ アップデートを使用するようあらゆる試みを行う必要があります。更新は、定期的な製品更新中に実行することも、品質やその他の問題に対処するためのホットフィックスのために実行することもできます。推奨される実践方法は次のとおりです。
- ドライバー、カーネル、プロトコルの更新に対処する計画を作成します。
- 導入された車両に更新を提供するために業界に適切な方法を利用します。
互換性定義文書 (CDD)
互換性定義文書 (CDD) には、デバイスが Android と互換性があるとみなされるための要件が説明されています。 CDD は公開されており、誰でも利用できます。 Android 1.6 から最新バージョンまでの CDD バージョンを、 source.android.comからダウンロードできます。
製品のこれらの要件を満たすには、次の基本的な手順が必要です。
- パートナーは Google と Android 互換性コミットメント (ACC) に署名します。その後、テクニカル ソリューション コンサルタント (TSC) がガイドとして割り当てられます。
- パートナーは、製品の Android OS バージョンの CDD レビューを完了します。
- パートナーは、結果が Android 互換性に関して許容できるようになるまで、CTS 結果 (後述) を実行して送信します。
互換性テストスイート (CTS)
Compatibility Test Suite (CTS) テスト ツールは、製品実装が Android と互換性があること、および最新のセキュリティ パッチが含まれていることを検証します。 CTS はパブリック、オープンソースであり、誰でも利用できます。 Android 1.6 から最新バージョンまでの CTS バージョンを、 source.android.comからダウンロードできます。
一般にリリースされる Android ソフトウェアの各ビルド (工場出荷時インストールおよびフィールド更新イメージ) は、CTS の結果を通じて Android 互換性を証明する必要があります。たとえば、デバイスで Android 7.1 が実行されている場合は、リリース目的のビルド イメージが作成およびテストされるときに、対応する最新バージョンの CDD 7.1 および CTS 7.1 を参照する必要があります。メーカーは、問題を特定して修正するために、早期かつ頻繁に CTS を使用することを強くお勧めします。
CTS ワークフロー
CTS ワークフローには、テスト環境のセットアップ、テストの実行、結果の解釈、および CTS ソース コードの理解が含まれます。次のガイドラインは、CTS ユーザー (開発者、メーカーなど) が CTS を効果的かつ効率的に使用できるようにすることを目的としています。
- テストを頻繁に実行します。 CTS は、ビルド システムに統合される自動ツールとして設計されています。 CTS を頻繁に実行すると、ソフトウェアの劣化や回帰が発生したときに、欠陥を迅速かつ早期に発見できます。
- CTS ソース コードをダウンロードして調べます。完全な CTS ソース コードは、誰でもダウンロードして使用できるオープン ソース ソフトウェアです (ダウンロードされたソース コードは完全にビルドおよび実行可能です)。デバイスでテストが失敗した場合、ソース コードの関連セクションを調べると、その理由を特定するのに役立ちます。
- 最新の CTS を入手します。新しい Android リリースでは、バグ修正、改善、新しいテストで CTS を更新できます。 CTS ダウンロードを頻繁にチェックし、必要に応じて CTS プログラムを更新します。 CTS が更新され続ける間、ある時点で製品を凍結する必要があるため、メーカーと Google は製品の発売に渡す CTS バージョンについて合意するものとします。
CTSを通過する
Android 互換製品の場合、Google はデバイスの CTS と CTS Verifier レポートのテスト結果が許容できるものであることを確認します。原則として、すべてのテストに合格する必要があります。ただし、デバイスが Android 互換性要件に準拠していない以外の理由でテストが不合格になった場合は、Google による審査の対象となります。このプロセス中:
- メーカーは、提案された CTS パッチ、パッチの検証、および議論を証明するための根拠を Google に提供します。
- Google は提出された素材を検査し、承認された場合は、デバイスが CTS の次のリビジョンに合格できるように、関連する CTS テストを更新します。
セキュリティ パッチを適用した後に CTS テストが突然失敗した場合、製造元は互換性を損なわないようにパッチを修正するか、テストが間違っていることを示してテストの修正を提供する必要があります (前述のとおり)。
CTS は引き続きテスト修正のレビューを受け付けています。たとえば、Android 4.4 は引き続き修正を受け入れます ( https://android-review.googlesource.com/#/c/273371/を参照)。
よくある質問 (FAQ)
Q: Android の特定の実装にセキュリティ アップデートを適用する責任は誰にありますか?
A: デバイスを直接提供するメーカーが責任を負います。このエンティティは Googleではありません。Google は、特定のデバイス (車両など) 向けではなく、AOSP でセキュリティ アップデートを公開します。
Q: Google は Android のセキュリティ問題にどのように対処しますか?
A: Google は継続的に問題を調査し、潜在的な修正を開発しており、定期的なセキュリティ アップデート プロセスの一環として、サポートされているすべての API レベルで修正を利用できるようにしています。 2015 年 8 月以来、Google は、 source.android.comへの更新情報とリンクを定期的に公開してきました。 Google は、メジャー OS リリースの一部としてセキュリティ アップデートも公開します。 「セキュリティ バックポート ポリシー」も参照してください。
Q: メーカーが ASB からのすべての AOSP パッチを統合したが、同じ速報で言及されている BSP ベンダーからのパッチを統合しなかった場合でも、セキュリティ レベルを高めることはできますか (たとえば、対応するパッチをプラットフォーム/ビルドに適用する) 。
A: Android セキュリティ パッチ レベル (SPL) を宣言するには、メーカーは、Android セキュリティ情報 (以前の情報を含む) で公開され、特定の Android SPL にマッピングされている必要なすべての問題に対処する必要があります。たとえば、 2017 年 3 月のセキュリティ情報(2017-03-01 SPL) を使用しているメーカーは、その SPL の 2017 年 3 月のセキュリティ情報に記載されているすべての必要な問題と、以前のすべての Android セキュリティ情報のデバイス固有の更新を含むすべての更新に対処しています。 2017-02-05 SPL に関連するデバイス固有のアップデート。
Q: メーカーが BSP ベンダーによって提供されるセキュリティ アップデートに同意しない場合、または ASB によって義務付けられたセキュリティ アップデートがベンダーによって提供されない場合はどうなりますか?
A: ASB はセキュリティの脆弱性 (CVE のリストで列挙) を説明し、多くの場合、対応するセキュリティ テストを提供します。目標は、リストされた脆弱性がデバイス上で再現できないこと、およびデバイスが関連するセキュリティ テストに合格できることを確認することです。そのため、問題は Google やサードパーティ ベンダーが提供するセキュリティ アップデートを適用することに関するものではなく、デバイスが ASB の CVE のリストに対して脆弱ではないことをメーカーが証明することに関するものです。メーカーは、提供されたセキュリティ更新プログラムを自由に使用できます。また、自社のデバイスにより適した変更がある場合は、その変更を代わりに使用することもできます。
たとえば、Google がコード変更を使用して AOSP のセキュリティ脆弱性に対処し、コンポーネントが完全に機能し、CDD に準拠した状態を維持できるようにするケースを考えてみましょう。メーカーがそのコンポーネントがデバイスに必要でないか、CDD (または関連する認定テスト) によって義務付けられていないと判断した場合、メーカーはコンポーネントを削除して、将来のサービスの必要性を減らし、攻撃対象領域を減らすことができます。メーカーは提供されたセキュリティ アップデートを使用しませんでしたが、セキュリティ情報に記載されている CVE に対してデバイスが脆弱でないことを確認しました。ただし、推奨されるセキュリティ更新プログラムから逸脱すると、メーカーは問題に誤って対処したり、新たなセキュリティ脆弱性が導入されたり、最終ビルドの機能が低下したりするリスクを負うことになります。
当社はすべての SoC パートナーと協力して ASB のすべての問題に対する修正が確実に存在するようにしていますが、メーカーにはデバイスのライフサイクルにわたって SoC ベンダーとのサービス契約を確保することをお勧めします。 SoC は希望よりも早くチップセットのサービスを停止する可能性があるため、デバイスのチップセットを選択する前に合意を確立することは、デバイスの発売プロセスの重要な部分です。
最後に、ASB に文書化された問題の修正を直接取得したり、独自に作成したりすることが不可能な場合、メーカーは以前の Android SPL を維持しながら、利用可能な新しい修正をビルドに追加することができます。ただし、この方法では、最終的にはビルド認証に関する問題が発生します (Android では、認証済みデバイスで最新のセキュリティ パッチ レベルが利用可能であることが保証されているため)。 Google では、このような行為を避けるために、事前に SoC と連携することをお勧めします。
Q: メーカーが ASB アイテムが自社の製品に適用されないと判断した場合でも、他の Google 要件を満たすため、または CTS に合格するために、そのアイテムを適用またはパッチ適用する必要がありますか?
A: Android セキュリティ パッチ レベル (SPL) を宣言するためにパッチを取得する必要はありません。メーカーには、自社のビルドがこの問題に対して脆弱ではないことを証明することが求められます。
一例としては、パッチを適用するコンポーネントが製造元のシステムに存在しない場合や、問題に対処するためにコンポーネントが製造元のシステムから削除される場合があります。その場合、メーカーがパッチを適用する必要がなくても、システムは準拠している可能性があります。
これは、たとえば、セキュリティ テストの不合格の原因となる他の適用可能なパッチを適用せずに、重要なパッチのみを修正したいメーカーとは根本的に異なります。この場合、SPL は満たされていないと想定されます。