Authentication

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

  • Penyedia layanan dan penyimpanan kunci kriptografis. Android Keystore menyediakan layanan kriptografis yang didukung hardware untuk aplikasi. Sistem Android Keystore di tingkat framework didukung oleh layanan sistem keystore2. Hal ini didasarkan 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), seperti StrongBox.
  • Pengautentikasi pengguna. Membuktikan keberhasilan autentikasi pengguna. Android mendukung komponen autentikasi berikut:
    • Gatekeeper untuk autentikasi PIN, pola, atau sandi di TEE.
    • (Opsional) Weaver untuk autentikasi PIN, pola, atau sandi dalam elemen pengaman.
    • Sidik jari untuk autentikasi sidik jari.
    • Metode autentikasi biometrik lainnya. Perangkat yang dikirim dengan Android 9 atau yang lebih tinggi dapat menggunakan BiometricPrompt sebagai satu titik integrasi untuk sidik jari dan biometrik tambahan.
    Komponen ini mengomunikasikan status autentikasinya dengan layanan keystore2 melalui penggunaan token autentikasi (AuthToken) 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 suite pengujian vendor (VTS) yang sesuai.

Implementasi vendor biasanya juga dibagi menjadi dua bagian, yang dihubungkan 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, melakukan operasi aman yang sebenarnya.

Pendaftaran

Saat booting pertama perangkat setelah reset ke setelan pabrik, semua pengautentikasi disiapkan untuk menerima pendaftaran kredensial dari pengguna. Pengguna harus mendaftarkan PIN, pola, atau sandi terlebih dahulu dengan Gatekeeper (atau Weaver, jika tersedia). Pendaftaran awal ini membuat ID aman (SID) pengguna 64-bit yang dihasilkan secara acak, yang berfungsi sebagai ID untuk pengguna dan sebagai token pengikat untuk materi kriptografis pengguna. SID pengguna ini terikat secara kriptografis ke 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 yang tidak tepercaya untuk mendaftarkan kredensial baru tanpa menampilkan kredensial yang ada. Tindakan 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 yang aman. Perhatikan bahwa semua komponen aman berbagi kunci HMAC rahasia (per booting) yang digunakan untuk mengautentikasi pesan satu sama lain.

Setelah menyiapkan kredensial dan diberi SID pengguna, pengguna 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 menyediakan 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 rendah, 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. Terlepas dari versinya, autentikasi biometrik terjadi secara asinkron setelah permintaan dikirim.
  2. Layanan HAL mengirimkan data ke TA pasangannya, yang menghasilkan AuthToken:
    • Untuk autentikasi PIN/pola/sandi, gatekeeperd mengirimkan hash PIN, pola, atau sandi ke Gatekeeper TA di TEE, melalui layanan Gatekeeper HAL. 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 memproses peristiwa biometrik dan mengirimkannya ke layanan HAL biometrik dan TA yang sesuai.
  3. AuthToken bertanda tangan yang dihasilkan akan diteruskan ke layanan sistem keystore2 melalui antarmuka Binder.
  4. Layanan keystore2 melampirkan AuthToken untuk meminta KeyMint (sebelumnya Keymaster) melakukan operasi kriptografis. 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 yang aman: AuthToken mengalir dari TA pengautentikasi ke layanan keystore2 di Android, yang kemudian meneruskannya ke TA KeyMint. Hal ini juga memungkinkan layanan keystore2 menolak permintaan dengan cepat yang pasti akan gagal, karena layanan ini memiliki pengetahuan tentang AuthToken yang tersedia dalam sistem, sehingga menghemat IPC yang berpotensi mahal ke dalam 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, 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 rahasia bersama: Layanan keystore2 melakukan protokol perjanjian kunci multi-arah saat perangkat dimulai, sehingga memungkinkan derivasi aman kunci HMAC di antara TA yang berpartisipasi. Namun, TA yang berpartisipasi harus memiliki akses ke rahasia umum yang dibagikan sebelumnya.
  • Akses langsung: TA yang berada dalam lingkungan aman yang sama dapat menggunakan mekanisme komunikasi antar-proses internal (yang bergantung pada platform) untuk membagikan kunci HMAC.

Dalam kedua kasus tersebut, kunci HMAC tidak boleh tersedia 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 langsung antara KeyMint dan Gatekeeper atau TA biometrik yang sesuai. Kunci HMAC disimpan hanya di KeyMint; Sidik Jari dan Gatekeeper meminta kunci dari KeyMint untuk setiap penggunaan dan tidak mempertahankan atau menyimpan nilai dalam cache.

Karena beberapa TEE tidak memiliki infrastruktur IPC, tidak ada komunikasi yang terjadi antara applet di TEE. Hal ini juga memungkinkan layanan keystore untuk dengan cepat menolak permintaan yang pasti akan gagal karena memiliki pengetahuan tentang tabel autentikasi dalam sistem, sehingga menghemat IPC yang berpotensi mahal ke dalam TEE.