Ringkasan
Autentikasi wajah memungkinkan pengguna membuka kunci perangkat hanya dengan melihat bagian depan perangkat. Android 10 menambahkan dukungan untuk stack autentikasi wajah baru yang dapat memproses frame kamera dengan aman, sehingga menjaga keamanan dan privasi selama autentikasi wajah di hardware yang didukung. Android 10 juga menyediakan cara mudah untuk implementasi yang mematuhi keamanan guna memungkinkan integrasi aplikasi untuk transaksi, seperti perbankan online atau layanan lainnya.
Stack autentikasi wajah Android adalah implementasi baru di Android
10. Implementasi baru ini memperkenalkan antarmuka IBiometricsFace.hal,
IBiometricsFaceClientCallback.hal,
dan types.hal.
Arsitektur
BiometricPrompt API mencakup semua autentikasi biometrik, termasuk wajah, jari, dan iris. HAL Wajah berinteraksi dengan komponen berikut.
Gambar 1. Stack biometrik.
FaceManager
FaceManager adalah antarmuka pribadi yang mempertahankan
koneksi dengan FaceService. Ini digunakan oleh Keyguard untuk
mengakses autentikasi wajah dengan UI kustom. Aplikasi tidak
memiliki akses ke FaceManager dan harus menggunakan BiometricPrompt sebagai gantinya.
FaceService
Ini adalah implementasi framework yang mengelola akses ke hardware autentikasi wajah. Paket ini berisi mesin status pendaftaran dan autentikasi dasar serta berbagai helper 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 file Linux yang dapat dieksekusi yang mengimplementasikan antarmuka HIDL Face 1.0 yang digunakan
oleh FaceService. ID ini mendaftarkan dirinya sebagai IBiometricsFace@1.0 sehingga FaceService
dapat menemukannya.
Implementasi
HIDL Wajah
Untuk menerapkan Face HIDL, Anda harus menerapkan semua metode IBiometricsFace.hal
dalam library khusus vendor.
Pesan error
Pesan error dikirim oleh callback dan mengembalikan mesin status ke
status idle setelah dikirim. Sebagian besar pesan memiliki
string yang ditampilkan kepada pengguna untuk memberi tahu pengguna tentang error, tetapi tidak semua
error memiliki string yang ditampilkan kepada pengguna ini. Untuk informasi selengkapnya tentang pesan error, lihat
types.hal.
Semua pesan error mewakili status terminal, yang berarti framework mengasumsikan bahwa
HAL kembali ke status tidak ada aktivitas setelah mengirim pesan error.
Pesan akuisisi
Pesan akuisisi dikirim selama pendaftaran atau autentikasi dan
dimaksudkan untuk memandu pengguna agar berhasil mendaftar atau melakukan autentikasi.
Setiap ordinal memiliki
pesan terkait dari file
FaceAuthenticationManager.java. Pesan khusus vendor dapat ditambahkan selama string bantuan
yang sesuai diberikan. Pesan akuisisi bukanlah status terminal itu sendiri; HAL diharapkan mengirimkan pesan sebanyak yang diperlukan untuk menyelesaikan pendaftaran atau autentikasi saat ini. Jika pesan akuisisi
menghasilkan status terminal di mana tidak ada progres yang dapat dilakukan, HAL harus
mengikuti pesan akuisisi dengan pesan error, misalnya, saat
gambar terlalu gelap dan tetap terlalu gelap agar progres dapat dilakukan. Dalam hal ini, wajar untuk mengirim UNABLE_TO_PROCESS setelah beberapa upaya dilakukan
tetapi tidak ada progres lebih lanjut yang dapat dilakukan.
Hardware
Agar mematuhi persyaratan biometrik yang kuat untuk Android 10, perangkat harus memiliki hardware yang aman untuk memastikan integritas data wajah dan perbandingan autentikasi akhir. Android Compatibility Definition Document (CDD) menguraikan tingkat keamanan yang diperlukan dan tingkat penerimaan spoof (SAR) yang dapat diterima. Trusted execution environment (TEE) diperlukan untuk pemrosesan dan pengenalan yang aman. Selain itu, hardware kamera yang aman diperlukan untuk mencegah serangan injection pada autentikasi wajah. Misalnya, halaman memori terkait untuk data gambar dapat diberi hak istimewa dan ditandai hanya baca sehingga hanya hardware kamera yang dapat memperbaruinya. Idealnya, tidak ada proses yang memiliki akses kecuali TEE dan hardware.
Karena hardware autentikasi wajah sangat bervariasi, Anda perlu
mengembangkan driver khusus hardware untuk mengaktifkan autentikasi wajah, bergantung pada
arsitektur perangkat tertentu. Dengan demikian, tidak ada implementasi
referensi untuk faced.
Metode
Semua metode berikut bersifat asinkron dan harus segera kembali ke framework. Jika tidak dilakukan, sistem akan menjadi lambat dan berpotensi mereset Watchdog. Sebaiknya miliki antrean pesan dengan beberapa thread untuk menghindari pemblokiran pemanggil. Semua permintaan GET harus meng-cache informasi jika memungkinkan sehingga pemanggil diblokir selama jangka waktu minimal.
| Metode | Deskripsi |
|---|---|
setCallback() |
Dipanggil oleh FaceService untuk menyalurkan semua pesan kembali ke dirinya sendiri. |
setActiveUser() |
Menetapkan pengguna aktif, yang diterapkan untuk semua operasi HAL berikutnya. Autentikasi selalu untuk pengguna ini hingga 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, mengautentikasi, menghapus, atau melakukan enumerasi) dan menampilkan faced ke status tidak ada aktivitas. |
enumerate() |
Mengurutkan semua template 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 saat HAL berada dalam status autentikasi atau
standby. Menggunakan metode ini saat HAL tidak berada dalam salah satu status ini akan menampilkan OPERATION_NOT_SUPPORTED. Memanggil
metode ini saat HAL sudah mengautentikasi dapat memperpanjang
waktu sistem mencari wajah. |
resetLockout() |
Jika terlalu banyak wajah yang ditolak, faced diperlukan untuk memasuki status penguncian (LOCKOUT atau LOCKOUT_PERMANENT). Jika demikian, Anda harus mengirimkan sisa waktu ke framework agar dapat menampilkannya kepada pengguna. Seperti setFeature(), metode ini memerlukan
token autentikasi hardware (HAT) aktif untuk mereset status internal dengan aman. Mereset penguncian akun
hanya untuk pengguna saat ini. |
Tiga metode lainnya semuanya sinkron dan harus diblokir selama waktu minimal untuk menghindari penundaan framework.
| Metode | Deskripsi |
|---|---|
generateChallenge() |
Menghasilkan token acak yang unik dan aman secara kriptografis yang digunakan untuk menunjukkan dimulainya transaksi yang aman. |
setFeature() |
Mengaktifkan atau menonaktifkan fitur untuk pengguna saat ini. Untuk alasan keamanan, hal ini mengharuskan HAT untuk tidak memeriksa PIN/pola/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 menampilkan ILLEGAL_ARGUMENT |
getAuthenticatorId() |
Menampilkan ID yang terkait dengan kumpulan wajah saat ini. ID ini harus berubah setiap kali wajah ditambahkan |
Diagram status
Framework mengharapkan faced mengikuti diagram status di bawah.
Gambar 2. Alur status autentikasi wajah.