今後の展開

今年の基調講演は、昨年よりさらにパワーアップして、二部構成でお送りします。

開催概要

このような方の参加をお待ちしています。

非推奨と廃止の違い

• 非推奨 : 使用をやめることをおすすめするものです。この理由として、他の良い代替方法や計画的な廃止などが挙げられます。
• 廃止 : 以前は使用できたものが今後使用できない、またはサポートされないことを表します。廃止されたソフトウェアを呼び出すと、予期しない動作や無効なレスポンスが発生する可能性があります。

SDK における非推奨 : API の非推奨との違い

SDK で機能 B を非推奨にする例。v3.0 には機能 B が含まれていないため、機能 B をサポートしている最後のバージョンは v2 となります。機能 B の使用を続けるには、v2 の指定が必要となります。v3.0 にアップグレードするには、コードから機能 B の使用の削除が必要です。

非推奨の機能をサポートする最後のバージョンが廃止されると、その機能をサポートするバージョンはなくなり、機能の継続的な使用は保証されませんので、ご注意ください。

この認証（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 は、さまざまな要件を満たすために独自の制御を作成する手間をかけずに済みます。

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