Ringkasan
Autentikasi wajah memungkinkan pengguna membuka kunci perangkat mereka hanya dengan melihat ke bagian depan perangkat. Android 10 menambahkan dukungan untuk stack autentikasi wajah baru yang dapat memproses frame kamera secara aman, menjaga keamanan dan privasi selama autentikasi wajah di hardware yang didukung. Android 10 juga menyediakan cara mudah bagi penerapan yang mematuhi keamanan untuk mengaktifkan 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, sidik jari, dan iris. Face HAL berinteraksi dengan komponen berikut.
Gambar 1. Stack biometrik.
FaceManager
FaceManager adalah antarmuka pribadi yang mempertahankan
koneksi dengan FaceService. 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. Class 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 yang dapat dieksekusi Linux yang mengimplementasikan antarmuka HIDL Face 1.0 yang digunakan oleh FaceService. Layanan ini mendaftarkan dirinya sebagai IBiometricsFace@1.0 sehingga FaceService
dapat menemukannya.
Implementasi
Face HIDL
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 mengetahui 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 dikirimkan 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 disediakan. Pesan akuisisi bukanlah status akhir dengan sendirinya; HAL diharapkan mengirimkan sebanyak mungkin pesan ini sesuai kebutuhan untuk menyelesaikan pendaftaran atau autentikasi saat ini. Jika pesan akuisisi
menghasilkan status terminal yang tidak memungkinkan progres, maka HAL harus
mengikuti pesan akuisisi dengan pesan error, misalnya, jika
gambar terlalu gelap dan tetap terlalu gelap sehingga tidak memungkinkan progres. Dalam hal ini, UNABLE_TO_PROCESS dapat dikirim setelah beberapa kali upaya dilakukan, tetapi tidak ada progres lebih lanjut yang dapat dilakukan.
Hardware
Agar perangkat mematuhi persyaratan biometrik kuat untuk Android 10, perangkat harus memiliki hardware yang aman untuk memastikan integritas data wajah dan perbandingan autentikasi akhir. Compatibility Definition Document (CDD) Android menguraikan tingkat keamanan yang diperlukan dan tingkat penerimaan spoof (SAR) yang dapat diterima yang diperlukan. Trusted Execution Environment (TEE) diperlukan untuk pemrosesan dan pengenalan yang aman. Selain itu, hardware kamera yang aman diperlukan untuk mencegah serangan injeksi pada autentikasi wajah. Misalnya, halaman memori terkait untuk data gambar dapat memiliki hak istimewa dan ditandai hanya baca sehingga hanya hardware kamera yang dapat mengupdatenya. Idealnya, tidak ada proses yang boleh 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. Oleh karena itu, tidak ada implementasi
referensi untuk faced.
Metode
Semua metode berikut bersifat asinkron dan harus segera ditampilkan 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 menyimpan informasi dalam cache jika memungkinkan sehingga pemanggil diblokir dalam waktu yang minimal.
| Metode | Deskripsi |
|---|---|
setCallback() |
Dipanggil oleh FaceService untuk menyalurkan semua pesan kembali ke dirinya sendiri. |
setActiveUser() |
Menetapkan pengguna aktif, yang semua operasi HAL berikutnya diterapkan. Autentikasi selalu untuk pengguna ini hingga metode ini dipanggil lagi. |
revokeChallenge() |
Menyelesaikan transaksi aman dengan membatalkan validasi tantangan yang dihasilkan
oleh generateChallenge(). |
enroll() |
Mendaftarkan wajah pengguna. |
cancel() |
Membatalkan operasi saat ini (misalnya, mendaftar, mengautentikasi,
menghapus, atau menghitung) dan mengembalikan faced ke status tidak ada aktivitas. |
enumerate() |
Mencantumkan 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 dalam status mengautentikasi atau
standby. Menggunakan metode ini saat HAL tidak dalam salah satu status
ini akan menampilkan OPERATION_NOT_SUPPORTED. Memanggil
metode ini saat HAL sudah melakukan autentikasi dapat memperpanjang
waktu yang dibutuhkan sistem untuk mencari wajah. |
resetLockout() |
Jika terlalu banyak wajah ditolak, faced diperlukan untuk memasuki status
penguncian (LOCKOUT atau LOCKOUT_PERMANENT). Jika
hal itu terjadi, waktu yang tersisa harus dikirim ke framework agar dapat
ditampilkan kepada pengguna. Seperti setFeature(), metode ini memerlukan
token autentikasi hardware (HAT) aktif untuk mereset status internal secara aman. Mereset penguncian
hanya untuk pengguna saat ini. |
Tiga metode yang tersisa semuanya sinkron dan harus diblokir dalam waktu minimum untuk menghindari terhentinya framework.
| Metode | Deskripsi |
|---|---|
generateChallenge() |
Membuat token acak yang unik dan aman secara kriptografi yang digunakan untuk menunjukkan awal transaksi yang aman. |
setFeature() |
Mengaktifkan atau menonaktifkan fitur untuk pengguna saat ini. Untuk alasan keamanan, hal ini memerlukan HAT dari pemeriksaan pin/pola/sandi pengguna terhadap tantangan di atas |
getFeature() |
Mengambil status pengaktifan fitur saat ini, sebagaimana 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 set 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.