生体認証システム

生体認証システムを使ってデバイスで本人確認をする場合、利便性は高いものの、セキュリティは弱くなる可能性があります。階層型認証モデルでは、第 1 の認証（PIN、パターン、パスワードなどの知識要素に基づくモダリティ）によって最高レベルのセキュリティが確保されます。生体認証システムは、第 2 の認証階層であり、利便性とセキュリティのバランスが取られています。Android CDD では、クラス 3（旧称「強」）、クラス 2（旧称「弱」）、クラス 1（旧称「利便性」）の 3 つのクラスの生体認証強度が定義されています。各クラスには、前提条件、権限、制約があります。詳細については、上記の CDD をご覧ください。これら 3 つのクラスはすべて、ロック画面と統合することが許されています。ただし、android.hardware.biometrics API との統合が許されるのは、「強」と「弱」の認証システムのみです。次の表に、それぞれの認証システムとそれがサポートしている機能を示します。

認証システム ロック画面 BiometricPrompt の統合 キーストア（時間ベースの鍵） キーストア（オペレーション ベースの鍵）
BIOMETRIC_STRONG（クラス 3） ○ ○ ○ ○
BIOMETRIC_WEAK（クラス 2） ○ ○ × ×
BIOMETRIC_CONVENIENCE
（クラス 1）		 ○ × × ×
DEVICE_CREDENTIAL ○ ○ ○ ○

Android フレームワークは、顔と指紋の生体認証をサポートしています。Android は、他の生体認証モダリティ（虹彩など）をサポートするようにカスタマイズできます。ただし、生体認証システムの統合は、モダリティではなく、生体認証のセキュリティに依存します。生体認証セキュリティの仕様について詳しくは、生体認証を用いたロック解除のセキュリティ測定をご覧ください。

ソース

Android 12

  • BiometricManager.Strings API が導入されています。この API は、認証に BiometricPrompt を使用しているアプリ用にローカライズされた文字列を提供します。これらの文字列はデバイスで認識するためのもので、使用できる認証の種類を具体的に示します。
  • ディスプレイ内蔵指紋認証センサー（UDFPS）をサポートしています。

Android 11

  • BiometricManager.Authenticators インターフェースが導入されています。デベロッパーは、このインターフェースが提供する定数を使用して、アプリが受け入れる認証の種類を指定できます。
  • ACTION_BIOMETRIC_ENROLL というインテントのアクションが追加されています。デベロッパーは、これを使用して、アプリの要件を満たす認証方法を登録するようユーザーを案内できます。
  • AuthenticationResult#getAuthenticationType() メソッドが追加されています。デベロッパーは、これを使用して、ユーザーが生体認証情報とデバイス認証情報のどちらを使用して認証を行ったのかを確認できます。
  • BiometricPrompt クラス内での auth-per-use キーのサポートが追加されています。

Android 10

Android 9

  • BiometricPrompt 向けにのみ指紋認証を統合しています。
  • FingerprintManager クラスは非推奨です。バンドルアプリとシステムアプリでこのクラスを使用する場合は、代わりに BiometricPrompt と BiometricManager を使用するよう更新します。
  • BiometricPromptBoundKeysTest を使用して BiometricPrompt をテストするよう、FingerprintManager CTS 検証ツールのテストが更新されています。

実装

ユーザーとデベロッパーがシームレスな生体認証を使用できるよう、生体認証スタックを BiometricPrompt、BiometricManager、ACTION_BIOMETRIC_ENROLL の API に統合します。生体認証センサーを搭載したデバイスは、以下の強度に関する要件を満たす必要があります。また、すべての実装が CtsBiometricsTestCases CTS モジュールに合格しなければなりません。

生体認証スタックを ACTION_BIOMETRIC_ENROLL API と統合するには:

  1. BiometricEnrollActivity を変更して登録フローを提示してください。なお、生体認証システムは、要求された強度を満たしている場合にのみ提供できます。デバイスが複数の生体認証をサポートしている場合、ユーザーが選択できるリストをこのアクションで提示してください。
BiometricPrompt のアーキテクチャ
図 1. BiometricPrompt のアーキテクチャ

HAL 実装のガイドライン

生体認証に関する HAL のガイドラインを遵守して、生体認証データの漏洩を防止し、デバイスからユーザーが削除される際に生体認証データも削除されるようにします。

  • 未処理の生体認証データや派生物（テンプレートなど）に、安全な隔離環境（TEE やセキュア エレメントなど）以外からはアクセスできないようにしてください。保存されるデータはすべて、TEE（高信頼実行環境）のみが把握しているデバイス固有の鍵で暗号化してください。ハードウェアがサポートされている場合は、安全な隔離環境へのハードウェア アクセスを制限し、SELinux ポリシーで保護します。通信チャネル（SPI、I2C など）は、すべてのデバイス ファイルに SELinux ポリシーが明示的に設定されている安全な隔離環境に対してのみアクセス可能にします。
  • データ侵害やその他の攻撃から守るため、生体認証の取得、登録、認識は安全な隔離環境内で行われる必要があります。この要件は、クラス 3（旧称「強」）とクラス 2（旧称「弱」）の生体認証にのみ適用されます。
  • リプレイ攻撃から保護するには、デバイス固有の秘密鍵で生体認証テンプレートに署名してください。Advanced Encryption Standard（AES）の場合、少なくとも絶対ファイル システム パス、グループ、生体認証 ID を持つテンプレートに署名する必要があります。このテンプレート ファイルは、他のデバイスでは使用できないものであるか、同じデバイスに登録したユーザーのみが使用できるものであることが前提となります。たとえば、同じデバイス上の別のユーザーによる生体認証データのコピー、または別のデバイスからの生体認証データのコピーは行われないようにしてください。
  • TEE の外部にデータを保存する必要がある場合は、setActiveUser() HIDL method が提供するファイル システム パスを使用するか、ユーザーが削除されたときにすべてのユーザー テンプレート データを消去する別の方法を提供してください。これは、ユーザーデータの漏洩を防ぐためです。このパスを使用しないデバイスは、ユーザーが削除された後に必ずクリーンアップする必要があります。CDD では、生体認証データと派生ファイルを暗号化された状態で保存することが義務付けられています（特に TEE 内でない場合）。安全な隔離環境のストレージ要件によりそれが不可能な場合は、ユーザーが削除されるとき、またはデバイスがワイプされるときにデータを確実に削除するためのフックを追加してください。LockSettingsService.removeBiometricsForUser() を参照してください。

カスタマイズ

デバイスが複数の生体認証をサポートしている場合、ユーザーが設定でデフォルトを指定できるようにします。BiometricPrompt を実装する際は、ユーザーが明示的にオーバーライドする場合を除いてクラス 3（旧称「強」）の生体認証をデフォルトにする必要があり、生体認証に関連するリスクを説明する警告メッセージを表示します（例: 「顔写真でデバイスのロックを解除される可能性があります」）。

デバイス固有の認証文字列

Android 12 以降、デベロッパーは BiometricManager.Strings API によりコンテキスト認証文字列を使用できるようになりました。この API により返されるリソース値をカスタマイズして、デバイス固有の文字列を実装できます。その場合は新しい文字列を、デバイスがサポートするすべてのロケール向けに翻訳してください。また、以下のプロパティが維持されるようにしてください。


メソッド
文字列の用途
含める認証のタイプ
生体認証と画面ロックの両方が可能な場合

getButtonLabel()
BiometricPrompt をトリガーするボタンのラベル
認証システムの要件を満たすタイプのうち、登録済みのタイプのみ（可能な場合）
生体認証限定の文字列を使用する（例: 「指紋認証を使用」）

getPromptMessage()
認証中に BiometricPrompt に表示されるメッセージ
認証システムの要件を満たすタイプのうち、登録済みのタイプのみ（可能な場合）
生体認証と画面ロックを組み合わせた文字列を使用（例: 「続行するには指紋認証または PIN を使用」）

getSettingName()
認証で BiometricPrompt を使用できるようにする設定の名前
認証システムの要件を満たすタイプのうち、デバイスでサポートされるすべてのタイプ（登録されていない場合も含む）
生体認証と画面ロックを組み合わせた文字列を使用（例: 「指紋認証または画面ロックを使用」）

たとえば、デバイスに、顔が登録されたクラス 2 の顔認証センサー、登録された PIN、指紋が登録されていないクラス 3 の指紋認証センサーがあるとします。次の表に、使用できる認証システムの組み合わせごとの文字列の例と、呼び出される BiometricManager.Strings メソッドを示します。


使用できる認証システム
getButtonLabel()
getPromptMessage()
getSettingName()

クラス 3 の生体認証（BIOMETRIC_STRONG）
「指紋認証を使用」
（指紋認証のみが認証システムの要件を満たす）
「続行するには指紋認証を使用」
（指紋認証のみが認証システムの要件を満たす）
「指紋認証を使用」
（指紋認証のみが認証システムの要件を満たす）

クラス 2 の生体認証（BIOMETRIC_WEAK）
「顔認証を使用」
（顔認証と指紋認証が要件を満たし、顔のみが登録されている）
「続行するには顔認証を使用」
（顔認証と指紋認証が要件を満たし、顔のみが登録されている）
「顔認証または指紋認証を使用」
（顔認証と指紋認証が要件を満たし、デバイスが両方に対応している）

画面ロック（DEVICE_CREDENTIAL）
「PIN を使用」
（任意の画面ロックが要件を満たし、PIN が登録されている）
「続行するには PIN を入力」
（任意の画面ロックが要件を満たし、PIN が登録されている）
「画面ロックを使用」
（任意の画面ロックが要件を満たしている）

クラス 3 の生体認証または画面ロック
「PIN を使用」
（指紋認証と任意の画面ロックが要件を満たし、PIN のみが登録されている）
「続行するには PIN を入力」
（指紋認証と任意の画面ロックが要件を満たし、PIN のみが登録されている）
「指紋認証または画面ロックを使用」
（指紋認証と任意の画面ロックが要件を満たす）

クラス 2 の生体認証または画面ロック
「顔認証を使用」
（顔認証、指紋認証、任意の画面ロックが要件を満たす。顔が登録されていて、PIN に優先して使用される）
「続行するには顔認証または PIN を使用」
（顔認証、指紋認証、任意の画面ロックが要件を満たし、顔と PIN が登録されている）
「生体認証または画面ロックを使用」
（顔認証、指紋認証、任意の画面ロックが要件を満たす）

検証

生体認証を実装するには、以下のテストに合格する必要があります。

  • CTS BiometricManager
  • CTS BiometricPrompt（基本。検証ツールによってテストの詳細が異なります）
  • CtsVerifier Biometric Test のセクション: デバイスがサポートする各モダリティで合格する必要があります

また、デバイスが AOSP HIDL（fingerprint@2.1、fingerprint@2.2、face1.0）を持つ生体認証をサポートしている場合、関連する VTS テスト（指紋、顔）に合格する必要があります。