Google Developers Japan

スマートフォンはますます高速化し、高機能になっています。そして、私たちの記憶力を補ったり、世界とつながり、友人や家族やその先のコミュニティと連絡を取り合うための主なインターフェースになり、私たちの暮らしの中で重要な役割を果たしています。この進化に合わせて、私たちが最も個人的な情報をスマートフォンに保存し、管理するようになったことも自然な流れです。そして私たちは、さまざまな形でスマートフォンをデジタルな自分や実際の自分の拡張として扱うようになっています。

スマートフォンに個人情報を預ける、その信頼を得て守ることこそ Android セキュリティ チームの最優先事項です。チームは Android デバイスがユーザーデータのプライバシーや機密性を尊重することを重視しています。その作業の土台となるのが、いわばデバイスの正面玄関となるロック画面です。つまり、ロック画面はデバイスを所有している特定のユーザーだけが個人データにアクセスできることを保証します。

このブログ記事では、Android デバイスのロック画面操作に関する最近の改善点について説明します。さらに、もう少し一般的な認証についても触れたいと思います。とりわけ、生体認証と環境という 2 種類の認証方式について重点的に取り上げます。この 2 つは潜在的に大きな可能性を秘めていると同時に、適切に設計されなければ重大なリスクにもなり得ます。

階層化認証モデル

ロック画面と認証の改善点について詳しく説明する前に、いくつかの背景情報をお伝えします。この情報は、今回の改善点における相互の関連性を把握するために役立ちます。今回の変更は、階層化認証モデルのフレームワークに当てはめてみるとイメージしやすいはずです。階層化認証モデルとは、Android に搭載されているすべての認証方式を概念的に分類し、相互の関連性や、この分類に基づく制約をまとめたものです。

このモデル自体はかなりシンプルで、認証方式を 3 つに分類しています。階層が上がるほどセキュリティのレベルは下がり、それに比例して制約が増えます。第 1 階層では、ユーザーが機能を利用するために第 1 の認証方式の再入力を求められるのは、特定の状況下（たとえば、起動ごとや 72 時間ごとなど）のみであるため、制約は最も少ないと言えます。第 2 階層と第 3 階層の制約はさらに強くなります。最初に第 1 の認証方式が登録されていないと設定および利用できないうえに、機能を制限するさらに強い制約が存在するためです。

1. 第 1 階層 - 知識ファクタ:
   最初の階層は、知識ファクタ、すなわちユーザーが知っていることを利用する方式です。たとえば、PIN（暗証番号） やパターン、パスワードなどです。推測しにくい複雑なパスワードなど、エントロピーの高い優れた知識ファクタは、最高レベルの身元保証を提供できる可能性があります。
   
   Android では、デバイスがハードウェア機能と指数バックオフによって総当たり攻撃に対する保護を提供しているため、知識ファクタは特に有用です。つまり、Android デバイスでは、5 回失敗するたびにハードウェア機能によるタイムアウトが適用されるため、攻撃者が PIN やパターン、パスワードを繰り返し予測することはできません。知識ファクタを利用するすべてのユーザーには、ファイルベースの暗号化（File Based Encryption、FBE）や暗号化デバイス バックアップなどを使用できるという追加のメリットもあります。
   
   
2. 第 2 階層 - 生体認証: 第 2 階層は主に生体認証で構成されます。これは、 ユーザー自身で認証する方式です。第 2 の認証方式の例として、顔や指紋による認証があげられます。生体認証は利便性が高くなりますが、デバイスでユーザーの身元を確認する方法としてのセキュリティは低くなる可能性があります。Android の生体認証については、次のセクションで詳しく取り上げます。
   
   
3. 第 3 階層 - 環境: 最後の階層は、 ユーザーの所有物を利用する方式です。その 1 つが物理トークンです。たとえば、Smart Lock の信頼できるデバイスを使う場合、許可リストに登録された Bluetooth デバイスとペアリングしてスマートフォンをロック解除します。また、デバイス周辺の物理環境に固有のものを使うこともできます。たとえば、Smart Lock の信頼できる場所では、スマートフォンを許可リストに登録された場所に運ぶことでロックを解除できます。

第 3 の認証の改善

信頼できる場所や信頼できるデバイス（そして一般的な第 3 の方式）を使うと、便利な方法でデバイスの内容にアクセスできます。しかし、これらに共通する根本的な問題は、最終的にユーザーの身元確認機能の精度の低さに集約されます。たとえば、信頼できる場所を使っているスマートフォンのロックは、ユーザーの自宅のそばを通り過ぎるだけで解除できるかもしれません。また、既製のソフトウェア無線と多少のスクリプトを使えば、比較的簡単に GPS シグナルを偽装することもできます。信頼できるデバイスも同様で、許可リストに登録された Bluetooth デバイスにアクセスできれば、ユーザーのスマートフォン内のすべてのデータにアクセスできることになります。

そこで、Android 10 の環境階層に大幅な改善が加えられ、第 3 階層は積極的にロックを解除する仕組みからロック解除を延長する仕組みに変わっています。この新しいモードでは、第 3 階層でデバイスのロックを解除できなくなりました。その代わり、最初に第 1 の方式か第 2 の方式を使ってデバイスのロックを解除している場合、最大 4 時間にわたってロック解除状態を継続します。

Android の生体認証の詳細

生体認証の実装には、幅広いセキュリティ特性があります。そこで、次にあげる 2 つの重要な要素を利用して特定の実装のセキュリティを判定しています。

1. 構造上のセキュリティ: カーネルやプラットフォームの侵害に対する生体認証パイプラインの耐性を表します。カーネルやプラットフォームが侵害され、未加工の生体認証データが読み取られたり、パイプラインに合成データを注入されたりしても認証結果に影響が及ぶことがない場合、パイプラインは安全であると見なされます。
   
   
2. なりすましの可能性: なりすまし受け入れ率（Spoof Acceptance Rate、SAR）で測定します。SAR は Android P で初めて導入された指標で、なりすましに特化した攻撃に対する生体認証の耐性を測定することを目的としています。SAR の詳細や測定方法については、生体認証を用いたロック解除のセキュリティ測定をご覧ください。

この 2 つの要素を使い、セキュリティの高い順に並んだ 3 つのクラスのいずれかに生体認証を分類します。

• クラス 3（以前の「å¼·」）
• クラス 2（以前の「å¼±」）
• クラス 1（以前の「便利」）

各クラスには、一連の制約が紐付いています。この制約は、それぞれの使いやすさとセキュリティのレベルのバランスをとることを目指したものです。

制約は、生体認証が第 1 階層の認証にフォールバックするまでの時間と、許可されているアプリ統合で表されています。たとえば、クラス 3 の生体認証はタイムアウトまでの時間が最も長く、すべてのアプリ統合オプションを利用できます。一方、クラス 1 の生体認証はタイムアウトまでの時間が最も短く、アプリ統合オプションは提供されません。概要を下の表に示します。完全版を確認したい方は Android Compatibility Definition Document（CDD）をご覧ください。

¹ App Integration（アプリ統合）とは、API をアプリに公開すること（例: BiometricPrompt/BiometricManager、androidx.biometric、FIDO2 API などの統合によって）を意味します。

² Keystore Ingegration（キーストア統合）とは、キーストアを組み込むこと（例: アプリの認証バインドキーをリリースするなど）を意味します。

メリットと注意点

生体認証を利用すると、高レベルのセキュリティを維持しつつ、ユーザーに利便性を提供できます。ユーザーは生体認証を利用するために第 1 の認証方式を設定する必要があるので、ロック画面の採用が促進されます（生体認証を提供しているデバイスは、そうでないデバイスに比べてロック画面の採用が平均 20% 高くなっています）。これにより、ロック画面が提供するセキュリティ機能のメリットを活用できるユーザーが増えます。具体的には、ユーザーの機密データへの認証されていないアクセスを防ぐことができ、暗号化バックアップなどの第 1 の認証方式によるその他のメリットも受けることができます。さらに、生体認証は、肩越しにのぞき見るショルダー サーフィン攻撃によって PIN やパターン、パスワードを入力するのを見た攻撃者が認証情報を再現しようとする試みを減らすうえでも役立ちます。

ただし、生体認証を使うことによるトレードオフ（発生し得るリスク）をユーザーが理解することが重要です。特に大切なのは、完璧な生体認証システムはないということです。これは Android だけでなく、すべてのオペレーティング システム、フォームファクタ、テクノロジーに対して言えることです。たとえば顔を使った生体認証の実装なら、ユーザーに似た家族やユーザーの 3D マスクでロックが解除できてしまうかもしれません。指紋を使った生体認証の実装なら、ユーザーの潜在指紋を使ってなりすませるかもしれません。このようななりすまし攻撃を緩和するため、なりすまし対策や Presentation Attack Detection（PAD）テクノロジーの開発が進められていますが、これらは緩和策であり、予防策ではありません。

生体認証の利用による潜在的なリスクを緩和するための Android の取り組みとして、Android P で導入されたロックダウン モードがあります。必要な場合、Android ユーザーはこの機能を使って一時的に生体認証や Smart Lock（信頼できる場所や信頼できるデバイスなど）、ロック画面の通知を無効化できます。

ロックダウン モードを使うには、まず第 1 の認証方式を設定し、その後に設定でロックダウン モードを有効化する必要があります。ロックダウン モードを有効化するための厳密な設定はデバイスのモデルによって異なりますが、Google Pixel 4 デバイスでは [Settings] > [Display] > [Lock screen] > [Show lockdown option] にあります。これを有効化すると、ユーザーは電源ボタンを押して電源ボタン メニューのロックダウン アイコンをクリックすることで、ロックダウン モードを起動できます。ロックダウン モードのデバイスは、第 1 の認証方式（PIN、パターン、パスワードなど）を使ってデバイスのロックを解除すると、ロックダウン解除状態に戻ります。

BiometricPrompt - 新 API

Android の生体認証が提供するセキュリティ保証のメリットを活用してもらい、生体認証をアプリに簡単に統合してユーザーの機密データの保護を強化できるようにするため、Android P で BiometricPrompt API を導入しました。

BiometricPrompt API を使用すると、さまざまなメリットが得られます。最も重要なことは、この API を使うと、アプリのデベロッパーが方式を意識せずに、さまざまな Android デバイスで生体認証を利用できることです（つまり、BiometricPrompt は、デバイスでサポートされているさまざまな生体認証方式の単一統合ポイントとして利用できます）。一方で、認証が提供する必要があるセキュリティ保証（フォールバックとしてのデバイス認証情報と合わせてクラス 3 またはクラス 2 の生体認証を必須とするなど）を制御することもできます。これにより、（ロック画面の他に）防御の第 2 階層でアプリデータを保護できることに加え、ユーザーの機密データを尊重することにもつながります。さらに、さまざまな Android デバイスのさまざまな方式の生体認証で一貫したユーザー エクスペリエンスを提供するため、BiometricPrompt は永続的な UI を提供しています。一部の情報（タイトルや説明など）をカスタマイズするオプションも存在します。

次のアーキテクチャ図に示すように、フレームワーク API やサポート ライブラリ（下位互換性を確保するための androidx.bitmetric）のどちらかを通して、Android デバイスのアプリに生体認証を組み込むことができます。注意すべき点は、FingerprintManager ãŒéžæŽ¨å¥¨ã«ãªã£ã¦ã„ることです。デベロッパーには、方式を意識しない認証としてBiometricPrompt ã«ç§»è¡Œã™ã‚‹ã“とが推奨されています。

BiometricPrompt の改善点

Android 10 では、BiometricManager クラスが導入され、デベロッパーはこれを使って生体認証の利用可否を照会できます。また、BiometricPrompt å‘けに指紋認証や顔認証が統合されています。

Android 11 では、BiometricManager.Authenticators　インターフェースなどの新機能が導入されています。これを使うと、デベロッパーはアプリで受け入れる認証タイプを指定したり、BiometricPrompt ã‚¯ãƒ©ã‚¹ã§åˆ©ç”¨ã”との認証キーをサポートしたりできます。

詳しくは、Android 11 プレビューと Android 生体認証システムのドキュメントをご覧ください。BiometricPrompt API の詳しい使用方法については、ブログ記事 Using BiometricPrompt with CryptoObject: how and why や、Codelab Login with Biometrics on Android をご覧ください。

Reviewed by Yuichi Araki - Developer Relations Team and Hidenori Fujii - Google Play Developer Marketing, APAC