Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Biometrik

Biometrik menawarkan cara yang lebih nyaman, tetapi berpotensi kurang aman untuk mengonfirmasi identitas Anda dengan perangkat. Di bawah model otentikasi berjenjang, otentikasi utama (yaitu, modalitas berbasis faktor pengetahuan seperti PIN, pola, dan kata sandi) memberikan tingkat keamanan tertinggi. Biometrik berada di tingkat otentikasi sekunder, menawarkan keseimbangan kenyamanan dan keamanan. The Android CDD mendefinisikan tiga kelas kekuatan biometrik: Kelas 3 (sebelumnya Strong), Kelas 2 (sebelumnya Lemah), dan Kelas 1 (sebelumnya Kenyamanan). Setiap kelas memiliki serangkaian prasyarat, hak istimewa, dan batasan - silakan lihat CDD di atas untuk lebih jelasnya. Ketiga kelas diizinkan untuk berintegrasi dengan layar kunci, tetapi hanya pengautentikasi Kuat dan Lemah yang diizinkan untuk berintegrasi dengan API android.hardware.biometrics. Tabel ini menjelaskan setiap autentikator dan fungsionalitas yang didukungnya.

Otentikator Layar kunci Integrasi Cepat Biometrik Keystore (kunci berbasis waktu) Keystore (kunci berbasis operasi)
BIOMETRIC_STRONG (Kelas 3) Ya Ya Ya Ya
BIOMETRIC_WEAK (Kelas 2) Ya Ya Tidak Tidak
BIOMETRIC_CONVENIENCE
(Kelas 1)
Ya Tidak Tidak Tidak
DEVICE_CREDENTIAL Ya Ya Ya Ya (1)
  1. Fungsi ini telah ditambahkan di Android 11, lihat ini untuk rincian

Kerangka kerja Android mencakup dukungan untuk otentikasi biometrik wajah dan sidik jari. Android dapat disesuaikan untuk mendukung modalitas biometrik lainnya (seperti Iris). Namun, integrasi biometrik akan bergantung pada keamanan biometrik, bukan modalitas. Untuk lebih detail tentang spesifikasi keamanan biometrik, lihat Mengukur Biometric Aktifkan Keamanan .

Sumber

Android 11

  • Memperkenalkan para antarmuka BiometricManager.Authenticators , yang menyediakan konstanta yang dapat digunakan pengembang untuk menentukan jenis otentikasi diterima oleh aplikasi mereka.
  • Menambahkan ACTION_BIOMETRIC_ENROLLtindakan niat , yang dapat digunakan pengembang untuk mengarahkan pengguna untuk mendaftarkan metode otentikasi yang memenuhi persyaratan aplikasi mereka.
  • Menambahkan AuthenticationResult #getAuthenticationType () metode , yang pengembang dapat digunakan untuk memeriksa apakah pengguna dikonfirmasi menggunakan mandat biometrik atau kredensial perangkat.
  • Menyediakan dukungan tambahan untuk auth-per-penggunaan kunci dalam kelas BiometricPrompt.

Android 10

  • Memperkenalkan para BiometricManager kelas yang dapat digunakan pengembang untuk query ketersediaan otentikasi biometrik.
  • Termasuk sidik jari dan wajah integrasi otentikasi untuk BiometricPrompt

Android 9

  • Termasuk integrasi sidik jari hanya untuk BiometricPrompt .
  • Menghentikan kelas FingerprintManager. Jika dibundel dan sistem aplikasi Anda menggunakan kelas ini, memperbarui mereka untuk menggunakan BiometricPrompt dan BiometricManager sebagai gantinya.
  • Diperbarui FingerprintManager CTS verifier tes untuk menguji BiometricPrompt menggunakan BiometricPromptBoundKeysTest .

Penerapan

Untuk memastikan bahwa pengguna dan pengembang memiliki mulus pengalaman biometrik, mengintegrasikan tumpukan biometrik Anda dengan BiometricPrompt , BiometricManager , dan ACTION_BIOMETRIC_ENROLL API. Perangkat dengan sensor biometrik harus mematuhi ini persyaratan kekuatan .
Untuk mengintegrasikan tumpukan biometrik Anda dengan BiometricPrompt dan BiometricManager APIs :

  1. Pastikan bahwa Anda <Modality>Service benar terdaftar BiometricService melalui metode IBiometricService # registerAuthenticator dan alat yang IBiometricAuthenticator antarmuka. Modalitas umum (sidik jari, wajah) memperpanjang dari umum superclass . Jika Anda perlu untuk mengintegrasikan modalitas yang tidak didukung, ikuti sidik jari / wajah contoh dan pedoman CDD untuk biometrik.
  2. Pastikan bahwa modalitas baru Anda benar didukung dalam SystemUI . Ada standar BiometricPrompt user interface untuk sidik jari dan wajah. Ini harus mencakup perubahan tata letak atau tema yang diperlukan untuk perangkat Anda. Yaitu perubahan tata letak yang sesuai untuk sensor sidik jari dalam layar.

Untuk mengintegrasikan tumpukan biometrik Anda dengan ACTION_BIOMETRIC_ENROLL API:

  1. Memodifikasi BiometricEnrollActivity untuk menyajikan aliran pendaftaran Anda. Perhatikan bahwa biometrik Anda hanya dapat ditampilkan jika memenuhi kekuatan yang diminta. Jika perangkat Anda mendukung lebih dari satu, tindakan ini akan menampilkan daftar yang dapat dipilih pengguna.
Arsitektur BiometricPrompt
Arsitektur Gambar 1. BiometricPrompt

pedoman pelaksanaan HAL

Ikuti panduan HAL biometrik ini untuk memastikan bahwa data biometrik tidak bocor dan dihapus ketika pengguna dihapus dari perangkat:

  • Pastikan bahwa data biometrik mentah atau turunannya (seperti template) tidak pernah dapat diakses dari luar lingkungan terisolasi yang aman (seperti TEE atau Elemen Aman). Semua data yang disimpan harus dienkripsi dengan kunci khusus perangkat yang hanya diketahui oleh TEE (Trusted Execution Environment) Jika dukungan hardware itu, membatasi akses hardware dengan lingkungan yang terisolasi aman dan melindunginya dengan kebijakan SELinux. Jadikan saluran komunikasi (misalnya, SPI, I2C) hanya dapat diakses oleh lingkungan terisolasi yang aman dengan kebijakan SELinux eksplisit pada semua file perangkat.
  • Akuisisi biometrik, pendaftaran, dan pengenalan harus terjadi di dalam lingkungan terisolasi yang aman untuk mencegah pelanggaran data dan serangan lainnya. Persyaratan ini hanya berlaku untuk kelas 3 (sebelumnya Strong) dan Kelas 2 (sebelumnya Lemah) biometrik.
  • Untuk melindungi dari serangan replay, tandatangani template biometrik dengan kunci pribadi khusus perangkat. Untuk Advanced Encryption Standard (AES), minimal menandatangani template dengan jalur sistem file absolut, grup, dan ID biometrik sehingga file template tidak dapat dioperasikan di perangkat lain atau untuk siapa pun selain pengguna yang mendaftarkannya di perangkat yang sama . Misalnya, mencegah penyalinan data biometrik dari pengguna yang berbeda di perangkat yang sama atau dari perangkat lain.
  • Jika Anda perlu untuk menyimpan di luar data TEE, gunakan file sistem jalur yang disediakan oleh setActiveUser() HIDL method atau memberikan cara lain untuk menghapus semua data pengguna template yang ketika pengguna dihapus. Alasannya adalah untuk melindungi kebocoran data pengguna. Perangkat yang tidak menggunakan jalan ini harus membersihkan setelah pengguna dihapus. CDD diharuskan untuk menyimpan data biometrik dan file turunan terenkripsi - terutama jika tidak di TEE Jika ini tidak mungkin karena persyaratan penyimpanan lingkungan terisolasi yang aman, tambahkan kait untuk memastikan penghapusan data saat pengguna dihapus atau perangkat dihapus. Lihat LockSettingsService.removeBiometricsForUser()

Kustomisasi

Jika perangkat Anda mendukung beberapa biometrik, pengguna harus dapat menentukan default dalam pengaturan. Anda BiometricPrompt pelaksanaan harus memilih Kelas 3 (sebelumnya Kuat) biometrik sebagai default kecuali pengguna secara eksplisit menimpa itu, maka kebutuhan pesan peringatan akan ditampilkan menjelaskan risiko yang terkait dengan misalnya, Sebuah foto dari Anda mungkin membuka kunci perangkat biometrik ( )

Validasi

Implementasi biometrik Anda harus lulus tes berikut:

  • CTS BiometricManager
  • CTS BiometricPrompt (kewarasan, mendalam pengujian bergantung pada verifier)
  • CtsVerifier Biometric Uji bagian : Harus lulus secara individual dengan setiap modalitas yang mendukung perangkat

Selain itu, jika perangkat Anda mendukung biometric yang memiliki AOSP HIDL ( fingerprint@2.1 , fingerprint@2.2 , face1.0 ), harus lulus tes VTS yang relevan ( sidik jari , wajah )