Pixel で検証可能なセキュリティ水準の継続的な向上について

モバイル デバイスのセキュリティ評価は難しく、信頼できる方法で企業のクレイムを検証するには、独立した業界の認証（Certification）によるものである必要があります。スマートフォンの場合、特に確実なエンドツーエンドの認証（Certification）に Common Criteria（CC）Mobile Device Fundamentals（MDF）Protection Profile があります。Common Criteria は、31 か国に広がる大規模なセキュア IT プロダクトの相互認証（mutual recognition）を確立する原動力です。ここ数年間、すべての OS のバージョンで継続的に認証（Certification）を受けているスマートフォン メーカーは、Google、Samsung、Apple の 3 社のみです。2 月初頭には、現在サポート対象で、Android 11 を実行する Pixel スマートフォンのすべての認証（Certification）が完了しました。Google は、最新の OS バージョンで認証（Certification）を受けた最初のメーカーです。

この認証（Certification）は、コンシューマや企業が直面する現実の脅威に対するデバイスの防御力を評価するために設計されています。次の表は、CC MDF 保護プロファイルに示されている脅威と対策の概要です。

脅威	対策
ネットワークの盗聴 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する ネットワーク攻撃 - 攻撃者がワイヤレス通信チャンネルなどのネットワーク インフラストラクチャ上に存在する	通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル 認可と認証 - ネットワークやバックエンドの安全な認証（Authentication） モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能
物理アクセス - 物理アクセス可能な攻撃者は、モバイル デバイスから認証情報を含むユーザーデータの取得を試みる可能性がある	ストレージの保護 - デバイスに含まれるデータを安全に保存（すなわち、保存データの暗号化）  認可と認証 - パスワード、PIN、指紋、顔認証など、既知のロック解除要素を利用した安全なデバイス認証（Authentication）
悪意や欠陥のあるアプリケーション - モバイル デバイスに読み込まれたアプリケーションに、悪意のあるコードや悪用可能なコードが含まれる可能性がある	通信の保護 - 安全な暗号化通信を保証する IPsec、DTLS、TLS、HTTPS、Bluetooth などの標準プロトコル 認可と認証 - ネットワークやバックエンドの安全な認証（Authentication） モバイル デバイス設定 - ユーザーや企業の管理者が定義するセキュリティ ポリシーを設定して適用する機能 モバイル デバイスの整合性 - ソフトウェア、ハードウェアの両方における重要な機能のデバイスの整合性 エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供
恒常的な存在 - 攻撃者がデバイスに恒常的に存在する場合、デバイスは整合性を失い、それを取り戻せないことを意味する	モバイル デバイスの整合性 - ソフトウェア、ハードウェア両方における重要な機能の整合性を保証するためのデバイスの整合性が保たれている エンドユーザー プライバシーとデバイスの機能 - アプリケーション分離やサンドボックス化、フレームワーク アクセス許可により、ユーザー アクティビティごとの分離やプライバシーを提供

この認証（Certification）が重要なのは、認定を受けたラボが実際にデバイスを評価し、さまざまなテストをして以下を確認しているためです。

1. すべての対策があらかじめ定義された標準や基準を満たしている。
2. すべての対策が公表されているとおりに機能する。

概念的には、評価対象（TOE）はデバイスのハードウェア（システム オン チップ）とオペレーティング システム（Android）の組み合わせです。上記の脅威に対する対策を検証するため、ラボは以下のセキュリティ機能を確認します。

• 通信の保護（転送データの暗号化） - Wi-Fi トラフィックやその他のネットワークの操作や通信を暗号化するために使用する暗号アルゴリズムと転送プロトコル。
• ストレージの保護（保存データの暗号化） - システム オン チップが提供する暗号化、信頼済み実行環境、Titan M や Android OS などのその他個々の改ざんできないハードウェア。具体的には、ファイルベースの暗号化の実装、ハードウェアのルート オブ トラスト、鍵ストアの操作（鍵生成など）、鍵の保存、鍵の破棄、鍵階層などを調査します。
• 認可と認証 - パスワード、PIN、生体認証など、ユーザーのデバイスのロック解除の仕組み。レート制限などの対策手法と、生体認証の場合は他人受入率やなりすまし受け入れ率。
• モバイル デバイスの整合性 - Android の確認付きブート、Google Play システム アップデート、シームレス OS アップデートの実装。
• 監査性 - デバイスのスタートアップやシャットダウン、データの暗号化、データの復号化、鍵の管理などのイベントのログをユーザーや IT 管理者が記録できる機能。
• モバイル デバイス設定 - ユーザーや企業の管理者が Android Enterprise を利用してデバイスにセキュリティ ポリシーを適用できる機能。

これが企業にとって重要な理由

Pixel のセキュリティが企業のニーズを確実にサポートできることは、非常に重要です。規制が厳しい業界の多くでは、機密データが考えられる限り最も強固な保護を受けられるように、Common Criteria 認証（Certified）デバイスの利用が義務付けられています。Android Enterprise 管理フレームワークでは、企業がデバイスの管理などをし、エンドユーザーが実行できる操作を制限したり、デバイスを監査してすべてのソフトウェアが適切に設定されていることを保証したりできます。たとえば、企業の IT 管理者は、カメラ、位置情報サービス、アプリのインストール プロセスなどの機能に対するポリシーを強制できます。

これがコンシューマにとって重要な理由

セキュリティは企業だけが心配することではありません。Common Criteria 認証（Certification）で検証している多くの保護は、コンシューマにも適用されます。たとえば、Wi-Fi に接続するとき、ウェブのブラウズを誰にも盗聴されないことを確認したいと思うでしょう。デバイスの紛失や盗難の際は、ロック画面によって他人が個人情報にアクセスする可能性が減ると確信したいはずです。

Google は、すべてのユーザーにセキュリティとプライバシーをお届けしたいと考えています。Pixel デバイスがこの認証（Certification）基準以上を確実に満たせるようにしたいと考えているのはそのためです。今後もこの基準を満たすために注力しますので、どうぞご安心ください。Pixel スマートフォンでは、スイッチを入れた瞬間から充実したセキュリティを利用できます。

これが Android エコシステムにとって重要な理由

認証（Certification）はサードパーティによる検証として有用な形態ですが、以下の、Google が 3 C と呼ぶものに該当することがよくあります。

• Complex（複雑） - デバイスのハードウェア、オペレーティング システム、その間にあるものすべてを含む評価スコープであるため。
• Costly（高価） - すべての形式とモデルの組み合わせ（SoC + OS）について、認定を受けたラボで実際に評価作業をする必要があり、個々のテストは数百件にのぼるため。
• Cumbersome（厄介） - かなり長い評価手続きで、初回は最長で 18 か月を要するため。

ここ 3 年間は、OEM パートナーを対象に、この複雑さを軽減するための作業をしてきました。その結果、必要なセキュリティ要件を満たすために要求される機能が Android オープンソース プロジェクトに直接組み込まれることをお知らせします。さらに、すべての管理要件と監査要件を Android Enterprise Management フレームワークに追加しました。昨年は、このために開発したツールを GitHub に公開しました。他の Android OEM が認証（Certification）を受ける際に、この作業のメリットを活用できるようにするためです。

新しい Android OS バージョンでの Pixel スマートフォンの認証（Certification）は継続しますが、Google はその他の Android OEM も、この認証（Certification）や、以下のその他の認証（Certification）を取得できるように取り組んでいます。

• アメリカ国立標準技術研究所の Cryptographic Algorithm と Module Validation Programs。これは暗号アルゴリズムとモジュールの評価で、アメリカの公共部門やその他多くの規制のある業界で求められています。Android 11 では、Conscrypt の主要モジュールである BoringSSL がこの検証を終えています（認定番号 3753）。
• アメリカ国防総省の Security Technical Implementation Guide（略称 STIG）。アメリカ国防総省のネットワークに技術を導入する方法をまとめたガイドラインです。かつては Android OEM に独自の実装や制御があったので、それによって異なる STIG が存在していましたが、Google の作業の成果によって、現在は 1 つの Android STIG テンプレートに統合されています。そのため、Android OEM は、さまざまな要件を満たすために独自の制御を作成する手間をかけずに済みます。

今後も、企業とコンシューマの両方を対象にしたセキュリティ対策に注力してまいります。業界の皆さんがこの作業に加わってくれることを歓迎いたします。

Reviewed by Eiji Kitamura - Developer Relations Team