Ringkasan
Otentikasi wajah memungkinkan pengguna untuk membuka kunci perangkat mereka hanya dengan melihat bagian depan perangkat mereka. Android 10 menambahkan dukungan untuk tumpukan autentikasi wajah baru yang dapat memproses bingkai kamera dengan aman, menjaga keamanan dan privasi selama autentikasi wajah pada perangkat keras yang didukung. Android 10 juga menyediakan cara mudah untuk implementasi yang mematuhi keamanan guna mengaktifkan integrasi aplikasi untuk transaksi, seperti perbankan online atau layanan lainnya.
Tumpukan autentikasi wajah Android adalah implementasi baru di Android 10. Implementasi baru ini memperkenalkan IBiometricsFace.hal , IBiometricsFaceClientCallback.hal , dan types.hal .
Arsitektur
API BiometricPrompt mencakup semua otentikasi biometrik termasuk, wajah, jari, dan iris mata. Face HAL berinteraksi dengan komponen berikut.
Manajer Wajah
FaceManager adalah antarmuka pribadi yang memelihara koneksi dengan FaceService . Ini digunakan oleh Keyguard untuk mengakses otentikasi wajah dengan UI khusus. Aplikasi tidak memiliki akses ke FaceManager dan harus menggunakan BiometricPrompt sebagai gantinya.
Layanan Wajah
Ini adalah implementasi kerangka kerja yang mengelola akses ke perangkat keras autentikasi wajah. Ini berisi mesin status pendaftaran dan otentikasi dasar serta berbagai pembantu lainnya (misalnya, enumerasi). Karena masalah stabilitas dan keamanan, tidak ada kode vendor yang diizinkan untuk dijalankan dalam proses ini. Semua kode vendor diakses melalui antarmuka HIDL Face 1.0 .
menghadapi
Ini adalah executable Linux yang mengimplementasikan antarmuka HIDL Face 1.0 yang digunakan oleh FaceService . Ia mendaftarkan dirinya sebagai IBiometricsFace@1.0 sehingga FaceService dapat menemukannya.
Penerapan
Wajah HIDL
Untuk mengimplementasikan HIDL Wajah, Anda harus mengimplementasikan semua metode IBiometricsFace.hal di perpustakaan khusus vendor.
Pesan kesalahan
Pesan kesalahan dikirim melalui panggilan balik dan mengembalikan mesin status ke status siaga setelah dikirim. Sebagian besar pesan memiliki string menghadap pengguna yang sesuai untuk memberi tahu pengguna tentang kesalahan, tetapi tidak semua kesalahan memiliki string yang menghadap pengguna ini. Untuk informasi lebih lanjut tentang pesan kesalahan, lihat types.hal . Semua pesan kesalahan mewakili status terminal, artinya kerangka kerja mengasumsikan bahwa HAL kembali ke status siaga setelah mengirim pesan kesalahan.
Pesan akuisisi
Pesan akuisisi dikirimkan selama pendaftaran atau otentikasi dan dimaksudkan untuk memandu pengguna menuju pendaftaran atau otentikasi yang berhasil. Setiap ordinal memiliki pesan terkait dari file FaceAuthenticationManager.java . Pesan khusus vendor dapat ditambahkan selama string bantuan yang sesuai disediakan. Pesan akuisisi bukanlah status terminal dalam dan dari dirinya sendiri; HAL diharapkan mengirim sebanyak mungkin yang diperlukan untuk melengkapi pendaftaran atau otentikasi saat ini. Jika pesan akuisisi menghasilkan keadaan terminal di mana tidak ada kemajuan yang dapat dibuat, maka HAL harus mengikuti pesan akuisisi dengan pesan kesalahan, misalnya, di mana gambar terlalu gelap dan tetap terlalu gelap untuk kemajuan yang akan dibuat. Dalam hal ini, wajar untuk mengirim UNABLE_TO_PROCESS setelah beberapa upaya telah dilakukan tetapi tidak ada kemajuan lebih lanjut yang dapat dibuat.
Perangkat keras
Agar perangkat mematuhi persyaratan biometrik yang kuat untuk Android 10, perangkat tersebut harus memiliki perangkat keras yang aman untuk memastikan integritas data wajah dan perbandingan autentikasi terbaik. Dokumen Definisi Kompatibilitas Android (CDD) menguraikan tingkat keamanan yang diperlukan dan tingkat penerimaan spoof (SAR) yang dapat diterima. Lingkungan eksekusi tepercaya (TEE) diperlukan untuk pemrosesan dan pengenalan yang aman. Selain itu, perangkat keras kamera yang aman diperlukan untuk mencegah serangan injeksi pada otentikasi wajah. Misalnya, halaman memori terkait untuk data gambar dapat diistimewakan dan ditandai hanya-baca sehingga hanya perangkat keras kamera yang dapat memperbaruinya. Idealnya, tidak ada proses yang memiliki akses kecuali TEE dan perangkat keras.
Karena perangkat keras autentikasi wajah sangat bervariasi, driver khusus perangkat keras perlu dikembangkan untuk mengaktifkan autentikasi wajah, bergantung pada arsitektur perangkat tertentu. Dengan demikian, tidak ada referensi implementasi untuk faced .
Metode
Metode berikut semuanya tidak sinkron dan harus segera kembali ke kerangka kerja. Gagal melakukannya menghasilkan sistem yang lambat dan kemungkinan pengaturan ulang Watchdog. Disarankan untuk memiliki antrian pesan dengan banyak utas untuk menghindari pemblokiran penelepon. Semua permintaan GET harus menyimpan informasi dalam cache jika memungkinkan sehingga pemanggil diblokir untuk waktu yang minimal.
| metode | Keterangan |
|---|---|
setCallback() | Dipanggil oleh FaceService untuk mengembalikan semua pesan ke dirinya sendiri. |
setActiveUser() | Mengatur pengguna aktif, yang menerapkan semua operasi HAL berikutnya. Otentikasi selalu untuk pengguna ini sampai metode ini dipanggil lagi. |
revokeChallenge() | Menyelesaikan transaksi aman dengan membatalkan tantangan yang dihasilkan oleh generateChallenge() . |
enroll() | Mendaftarkan wajah pengguna. |
cancel() | Membatalkan operasi saat ini (misalnya, mendaftarkan, mengotentikasi, menghapus, atau menghitung) dan mengembalikan faced ke keadaan siaga. |
enumerate() | Menghitung semua templat wajah yang terkait dengan pengguna aktif. |
remove() | Menghapus template wajah atau semua template wajah yang terkait dengan pengguna aktif. |
authenticate() | Mengautentikasi pengguna aktif. |
userActivity() | Metode ini hanya boleh digunakan ketika HAL dalam status otentikasi atau siaga. Menggunakan metode ini ketika HAL tidak berada dalam salah satu status ini akan mengembalikan OPERATION_NOT_SUPPORTED . Memanggil metode ini saat HAL sudah mengautentikasi dapat memperpanjang jumlah waktu sistem mencari wajah. |
resetLockout() | Jika terlalu banyak wajah yang ditolak, faced harus memasuki status penguncian ( LOCKOUT atau LOCKOUT_PERMANENT ). Ketika ya, itu diperlukan untuk mengirim sisa waktu ke kerangka kerja sehingga dapat menampilkannya untuk pengguna. Seperti setFeature() , metode ini memerlukan token otentikasi perangkat keras (HAT) aktif untuk menyetel ulang status internal dengan aman. Mengatur ulang penguncian hanya untuk pengguna saat ini. |
Tiga metode yang tersisa semuanya sinkron dan harus diblokir untuk jumlah waktu minimal untuk menghindari mengulur-ulur kerangka kerja.
| metode | Keterangan |
|---|---|
generateChallenge() | Menghasilkan token acak yang unik dan aman secara kriptografis yang digunakan untuk menunjukkan awal dari transaksi yang aman. |
setFeature() | Mengaktifkan atau menonaktifkan fitur untuk pengguna saat ini. Untuk alasan keamanan, ini memerlukan HAT untuk memeriksa pin/pola/kata sandi pengguna terhadap tantangan di atas |
getFeature() | Mengambil status pengaktifan fitur saat ini, seperti yang ditentukan oleh default atau panggilan ke setFeature() di atas. Jika ID wajah tidak valid, implementasi harus mengembalikan ILLEGAL_ARGUMENT |
getAuthenticatorId() | Mengembalikan pengenal yang terkait dengan set wajah saat ini. Pengenal ini harus berubah setiap kali wajah ditambahkan |
Diagram Negara
Kerangka kerja mengharapkan faced mengikuti diagram keadaan di bawah ini.
