Authentication

Android memiliki konsep pengautentikasi pengguna yang digunakan untuk membuka kunci perangkat dan mengizinkan akses ke kunci kriptografis. Hal ini melibatkan komponen berikut:

  • Penyimpanan kunci kriptografis dan penyedia layanan. Android Keystore menyediakan layanan kriptografi yang didukung hardware untuk aplikasi. Sistem Keystore Android di tingkat framework didukung oleh layanan sistem keystore2. Hal ini berdasarkan pada implementasi KeyMint (sebelumnya Keymaster) khusus vendor yang mendasarinya yang memastikan materi kunci hanya dapat diakses di lingkungan aman yang didukung hardware, seperti Trusted Execution Environment (TEE) atau Elemen Pengaman (SE).
  • Autentikasi pengguna. Menunjukkan bahwa autentikasi pengguna berhasil. Android mendukung komponen autentikasi berikut:
    • Gatekeeper untuk autentikasi PIN, pola, atau sandi di TEE.
    • (Opsional) Weaver untuk autentikasi PIN, pola, atau sandi dalam elemen yang aman.
    • Fingerprint untuk autentikasi sidik jari.
    • Metode autentikasi biometrik lainnya. Perangkat yang dilengkapi dengan Android 9 atau yang lebih tinggi dapat menggunakan BiometricPrompt sebagai satu titik integrasi untuk sidik jari dan biometrik tambahan.
    Komponen ini menyampaikan status autentikasi mereka dengan layanan keystore2 melalui penggunaan token autentikasi (AuthTokens) yang didukung hardware .

Setiap komponen ini bersifat khusus vendor, tetapi implementasi vendor diperlukan untuk memenuhi spesifikasi antarmuka Hardware Abstraction Layer (HAL), dan untuk lulus pengujian vendor test suite (VTS) yang sesuai.

Implementasi vendor biasanya juga dibagi menjadi dua bagian, yang terhubung oleh mekanisme komunikasi khusus vendor :

  • Layanan HAL berjalan sebagai proses sistem Android, yang menerima permintaan Binder dari sistem Android.
  • Aplikasi tepercaya (TA) berjalan di lingkungan yang aman, yang melakukan operasi aman yang sebenarnya.

Pendaftaran

Saat perangkat pertama kali dinyalakan setelah reset ke setelan pabrik, semua pengautentikasi akan siap menerima pendaftaran kredensial dari pengguna. Awalnya, pengguna harus mendaftarkan PIN, pola, atau sandi dengan Gatekeeper (atau Weaver, jika tersedia). Pendaftaran awal ini akan membuat ID aman pengguna (SID) 64-bit yang dibuat secara acak yang berfungsi sebagai ID untuk pengguna dan sebagai token pengikatan untuk materi kriptografis pengguna. SID pengguna ini terikat secara kriptografis dengan sandi pengguna; autentikasi yang berhasil ke Gatekeeper menghasilkan AuthToken yang berisi SID pengguna untuk sandi tersebut.

Pengguna yang ingin mengubah kredensial yang ada harus menunjukkan kredensial tersebut. Jika kredensial yang ada berhasil diverifikasi, SID pengguna yang terkait dengan kredensial yang ada akan ditransfer ke kredensial baru, sehingga pengguna dapat terus mengakses kunci setelah mengubah kredensial.

Dalam beberapa situasi, administrator perangkat dapat melakukan pendaftaran tidak tepercaya untuk mendaftarkan kredensial baru tanpa menampilkan kredensial yang ada. Hal ini memungkinkan pengguna mengakses perangkat, tetapi kunci yang dibuat di bawah SID pengguna lama akan hilang secara permanen.

Autentikasi

Bagian ini menjelaskan alur autentikasi standar, yang melibatkan interaksi antara beberapa komponen di Android dan lingkungan aman. Perhatikan bahwa semua komponen aman berbagi kunci HMAC rahasia (per-boot) yang mereka gunakan untuk mengautentikasi pesan satu sama lain.

Setelah pengguna menyiapkan kredensial dan diberi SID pengguna, mereka dapat memulai autentikasi, yang dimulai saat pengguna memberikan PIN, pola, sandi, sidik jari, atau biometrik kuat lainnya. Alur autentikasi

Gambar 1. Alur autentikasi

  1. Pengguna memberikan metode autentikasi dan layanan terkait membuat permintaan ke layanan HAL.
    • Untuk PIN, pola, atau sandi, LockSettingsService membuat permintaan ke gatekeeperd.
    • Alur autentikasi berbasis biometrik bergantung pada versi Android. Pada perangkat yang menjalankan Android 8.x dan yang lebih lama, FingerprintService membuat permintaan ke fingerprintd). Pada perangkat yang menjalankan Android 9 dan yang lebih tinggi, BiometricPrompt membuat permintaan ke daemon biometrik yang sesuai (misalnya, fingerprintd untuk sidik jari atau faced untuk wajah) menggunakan class BiometricManager yang sesuai, seperti FingerprintManager atau FaceManager. Apa pun versinya, autentikasi biometrik terjadi secara asinkron setelah permintaan dikirim.
  2. Layanan HAL mengirim data ke TA-nya, yang menghasilkan AuthToken:
    • Untuk autentikasi PIN/pola/sandi, gatekeeperd mengirimkan hash PIN, pola, atau sandi ke TA Gatekeeper di TEE, melalui layanan HAL Gatekeeper. Jika autentikasi di TEE berhasil, Gatekeeper TA akan memunculkan AuthToken yang berisi SID pengguna yang sesuai (ditandatangani dengan kunci HMAC bersama).
    • Untuk autentikasi sidik jari, fingerprintd memproses peristiwa sidik jari dan mengirimkan data ke TA Sidik Jari di TEE, melalui HAL Sidik Jari. Jika autentikasi di TEE berhasil, TA Sidik Jari akan memunculkan AuthToken (ditandatangani dengan kunci HMAC AuthToken).
    • Untuk autentikasi biometrik lainnya, daemon biometrik yang sesuai akan memproses peristiwa biometrik dan mengirimkannya ke layanan HAL dan TA biometrik yang sesuai.
  3. AuthToken yang ditandatangani yang dihasilkan akan diteruskan ke layanan sistem keystore2 melalui antarmuka Binder.
  4. Layanan keystore2 melampirkan AuthTokens untuk meminta KeyMint (sebelumnya Keymaster) untuk melakukan operasi kriptografi. Layanan HAL KeyMint meneruskannya ke TA KeyMint, yang memverifikasinya menggunakan kunci HMAC yang dibagikan dengan Gatekeeper dan komponen TEE biometrik yang didukung. KeyMint memercayai stempel waktu dalam token sebagai waktu autentikasi terakhir, memutuskan apakah akan mengizinkan penggunaan kunci berdasarkan stempel waktu.

Alur autentikasi tidak memerlukan komunikasi langsung antara TA di lingkungan aman: AuthTokens mengalir dari TA pengautentikasi ke layanan keystore2 di Android, yang kemudian meneruskannya ke TA KeyMint. Hal ini juga memungkinkan layanan keystore2 dengan cepat menolak permintaan yang pasti akan gagal, karena memiliki pengetahuan tentang AuthToken yang tersedia di sistem, sehingga menghemat IPC yang berpotensi mahal ke TEE.

Format AuthToken

Format AuthToken diberikan oleh spesifikasi AIDL di HardwareAuthToken.aidl.

Alur booting perangkat

Pada setiap booting perangkat, kunci HMAC AuthToken harus dibuat dan dibagikan ke semua komponen TEE (Gatekeeper, KeyMint/Keymaster, dan TA biometrik yang didukung). Untuk mencegah serangan replay, kunci HMAC harus dibuat secara acak setiap kali perangkat dimulai ulang.

Ada dua cara umum yang digunakan TA untuk mendapatkan akses ke kunci HMAC bersama ini:

  • Perjanjian secret bersama: Layanan keystore2 menjalankan protokol perjanjian kunci multi-arah saat perangkat dimulai, yang memungkinkan turunan kunci HMAC yang aman di antara TA yang berpartisipasi. Namun, TA yang berpartisipasi harus memiliki akses ke secret preshared umum.
  • Akses langsung: TA yang berada dalam lingkungan aman yang sama dapat menggunakan mekanisme komunikasi antarproses internal (yang bergantung pada platform) untuk membagikan kunci HMAC.

Dalam kedua kasus tersebut, kunci HMAC tidak boleh disediakan di luar TEE.

Sistem operasi Trusty, yang berjalan di samping Android, adalah contoh TEE, tetapi TEE lain dapat digunakan sebagai gantinya. Trusty menggunakan sistem IPC internal untuk berkomunikasi secara langsung antara KeyMint dan Gatekeeper atau TA biometrik yang sesuai. Kunci HMAC hanya disimpan di KeyMint; Sidik Jari dan Gatekeeper meminta kunci dari KeyMint untuk setiap penggunaan dan tidak mempertahankan atau meng-cache nilai.