Otentikasi Wajah HIDL

Ringkasan

Otentikasi wajah memungkinkan pengguna membuka kunci perangkat hanya dengan melihat bagian depan perangkat. 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 penerapan yang sesuai dengan 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 antarmuka IBiometricsFace.hal , IBiometricsFaceClientCallback.hal , dan types.hal .

Arsitektur

BiometricPrompt API mencakup semua autentikasi biometrik termasuk wajah, jari, dan iris mata. Face HAL berinteraksi dengan komponen berikut.

Tumpukan biometrik
Gambar 1. Tumpukan biometrik

Manajer Wajah

FaceManager adalah antarmuka pribadi yang menjaga koneksi dengan FaceService . Ini digunakan oleh Keyguard untuk mengakses autentikasi wajah dengan UI khusus. Aplikasi tidak memiliki akses ke FaceManager dan harus menggunakan BiometricPrompt .

Layanan Wajah

Ini adalah implementasi kerangka kerja yang mengelola akses ke perangkat keras autentikasi wajah. Ini berisi mesin negara 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 Face 1.0 HIDL .

dihadapi

Ini adalah executable Linux yang mengimplementasikan antarmuka Face 1.0 HIDL yang digunakan oleh FaceService . Ia mendaftarkan dirinya sebagai IBiometricsFace@1.0 sehingga FaceService dapat menemukannya.

Penerapan

Hadapi HIDL

Untuk mengimplementasikan Face HIDL, 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 yang dilihat pengguna untuk menginformasikan kesalahan tersebut kepada pengguna, namun tidak semua kesalahan memiliki string yang dilihat pengguna ini. Untuk informasi selengkapnya tentang pesan kesalahan, types.hal . Semua pesan kesalahan mewakili keadaan terminal, artinya kerangka kerja mengasumsikan bahwa HAL kembali ke keadaan diam setelah mengirim pesan kesalahan.

Pesan akuisisi

Pesan akuisisi dikirimkan selama pendaftaran atau autentikasi dan dimaksudkan untuk memandu pengguna menuju keberhasilan pendaftaran atau 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 terminal; HAL diharapkan mengirimkan sebanyak yang diperlukan untuk menyelesaikan pendaftaran atau otentikasi saat ini. Jika pesan akuisisi menghasilkan keadaan terminal di mana tidak ada kemajuan yang dapat dicapai, maka HAL harus mengikuti pesan akuisisi dengan pesan kesalahan, misalnya, ketika gambar terlalu gelap dan tetap terlalu gelap untuk dapat dilakukan kemajuan. Dalam hal ini, masuk akal untuk mengirim UNABLE_TO_PROCESS setelah beberapa kali mencoba tetapi tidak ada kemajuan lebih lanjut yang dapat dicapai.

Perangkat keras

Agar perangkat dapat memenuhi persyaratan biometrik yang ketat untuk Android 10, perangkat tersebut harus memiliki perangkat keras yang aman untuk memastikan integritas data wajah dan perbandingan autentikasi terbaik. Dokumen Definisi Kompatibilitas (CDD) Android 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, penting untuk mengembangkan driver khusus perangkat keras untuk mengaktifkan autentikasi wajah, bergantung pada arsitektur perangkat tertentu. Dengan demikian, tidak ada referensi implementasi untuk faced .

Metode

Metode berikut ini semuanya asinkron dan harus segera kembali ke kerangka kerja. Gagal melakukan hal ini mengakibatkan sistem lambat dan potensi pengaturan ulang Watchdog. Disarankan untuk memiliki antrian pesan dengan banyak rangkaian pesan untuk menghindari pemblokiran penelepon. Semua permintaan GET harus menyimpan informasi dalam cache jika memungkinkan sehingga penelepon diblokir untuk waktu yang minimal.

metode Keterangan
setCallback() Dipanggil oleh FaceService untuk mengembalikan semua pesan ke dirinya sendiri.
setActiveUser() Menetapkan pengguna aktif yang akan menerapkan semua operasi HAL berikutnya. Otentikasi 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 menghitung) dan faced ke status siaga.
enumerate() Menghitung semua templat wajah yang terkait dengan pengguna aktif.
remove() Menghapus templat wajah atau semua templat wajah yang dikaitkan dengan pengguna aktif.
authenticate() Mengautentikasi pengguna aktif.
userActivity() Metode ini hanya boleh digunakan ketika HAL dalam keadaan autentikasi atau standby. Menggunakan metode ini ketika HAL tidak berada di salah satu status ini akan mengembalikan OPERATION_NOT_SUPPORTED . Memanggil metode ini saat HAL sedang mengautentikasi dapat memperpanjang waktu yang dibutuhkan sistem untuk mencari wajah.
resetLockout() Jika terlalu banyak face yang ditolak, faced harus memasuki status lockout ( LOCKOUT atau LOCKOUT_PERMANENT ). Ketika hal ini terjadi, diperlukan untuk mengirimkan sisa waktu ke kerangka kerja sehingga dapat menampilkannya kepada pengguna. Seperti halnya setFeature() , metode ini memerlukan token autentikasi perangkat keras (HAT) yang aktif untuk menyetel ulang status internal dengan aman. Menyetel ulang penguncian hanya untuk pengguna saat ini.

Tiga metode yang tersisa semuanya sinkron dan harus diblokir dalam waktu minimal untuk menghindari terhentinya kerangka kerja.

metode Keterangan
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. Demi keamanan, hal ini memerlukan HAT dari pengecekan pin/pola/password 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, penerapannya harus mengembalikan ILLEGAL_ARGUMENT
getAuthenticatorId() Mengembalikan pengidentifikasi yang terkait dengan kumpulan wajah saat ini. Pengidentifikasi ini harus berubah setiap kali wajah ditambahkan

Diagram Keadaan

Kerangka tersebut mengharapkan faced mengikuti diagram keadaan di bawah ini.

Diagram Keadaan
Gambar 2. Alur status autentikasi wajah