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. CDD Android mendefinisikan tiga kelas kekuatan biometrik: Kelas 3 (sebelumnya Kuat), 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. Fungsionalitas ini telah ditambahkan di Android 11, lihat ini untuk detailnya

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 detail selengkapnya tentang spesifikasi keamanan biometrik, lihat Mengukur Keamanan Buka Kunci Biometrik .

Sumber

Android 11

  • Memperkenalkan antarmuka BiometricManager.Authenticators , yang menyediakan konstanta yang dapat digunakan pengembang untuk menentukan jenis autentikasi yang diterima oleh aplikasi mereka.
  • Menambahkantindakan maksud ACTION_BIOMETRIC_ENROLL , yang dapat digunakan pengembang untuk mengarahkan pengguna agar mendaftarkan metode autentikasi yang memenuhi persyaratan aplikasi mereka.
  • Menambahkan metode AuthenticationResult #getAuthenticationType () , yang dapat digunakan pengembang untuk memeriksa apakah pengguna mengautentikasi menggunakan kredensial biometrik atau kredensial perangkat.
  • Memberikan dukungan tambahan untuk kunci autentikasi per penggunaan dalam kelas BiometricPrompt.

Android 10

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

Android 9

  • Termasuk integrasi sidik jari hanya untuk BiometricPrompt .
  • Menghentikan kelas FingerprintManager. Jika paket Anda dan aplikasi sistem menggunakan kelas ini, perbarui mereka untuk menggunakan BiometricPrompt dan BiometricManager sebagai gantinya.
  • Memperbarui pengujian pemverifikasi CTS FingerprintManager untuk menguji BiometricPrompt menggunakan BiometricPromptBoundKeysTest .

Penerapan

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

  1. Pastikan bahwa <Modality>Service Anda terdaftar dengan benar di Layanan BiometricService melalui metode IBiometricService#registerAuthenticator dan mengimplementasikan antarmuka IBiometricAuthenticator . Modalitas umum (sidik jari, wajah) meluas dari superclass umum. Jika Anda perlu mengintegrasikan modalitas yang tidak didukung, ikuti contoh sidik jari / wajah dan pedoman CDD untuk biometrik.
  2. Pastikan modalitas baru Anda didukung dengan benar di SystemUI . Ada antarmuka pengguna BiometricPrompt default 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. Ubah BiometricEnrollActivity untuk menampilkan alur 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
Gambar 1. Arsitektur BiometricPrompt

pedoman pelaksanaan HAL

Ikuti panduan HAL biometrik ini untuk memastikan bahwa data biometrik tidak bocor dan dihapus saat 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 perangkat keras mendukungnya, batasi akses perangkat keras ke lingkungan terisolasi yang aman dan lindungi 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 biometrik Kelas 3 (sebelumnya Kuat) dan Kelas 2 (sebelumnya Lemah) .
  • 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 pada perangkat yang sama atau dari perangkat lain.
  • Jika Anda perlu menyimpan data di luar TEE, gunakan jalur sistem file yang disediakan oleh metode setActiveUser() HIDL method atau berikan cara lain untuk menghapus semua data template pengguna saat pengguna dihapus. Alasannya adalah untuk melindungi kebocoran data pengguna. Perangkat yang tidak menggunakan jalur ini harus dibersihkan setelah pengguna dihapus. CDD mengharuskan data biometrik dan file turunan disimpan 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. Implementasi BiometricPrompt Anda harus memilih biometrik Kelas 3 (sebelumnya Kuat) sebagai default kecuali jika pengguna secara eksplisit menimpanya, maka pesan peringatan perlu ditampilkan menjelaskan risiko yang terkait dengan biometrik (misalnya, Foto Anda dapat membuka kunci perangkat Anda )

Validasi

Implementasi biometrik Anda harus lulus tes berikut:

  • Manajer Biometrik CTS
  • CTS BiometricPrompt (kewarasan, pengujian mendalam bergantung pada pemverifikasi)
  • Bagian Tes Biometrik CtsVerifier : Harus lulus secara individual dengan setiap modalitas yang didukung perangkat

Selain itu, jika perangkat Anda mendukung biometrik yang memiliki AOSP HIDL ( fingerprint@2.1 , fingerprint@2.2 , face1.0 ), perangkat tersebut harus lulus uji VTS yang relevan ( fingerprint , face )