Authentication

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

  • Penyedia layanan dan penyimpanan kunci kriptografis. Menyimpan kunci kriptografi dan menyediakan rutin kripto standar di atas kunci tersebut. Android mendukung Keystore yang didukung hardware dan KeyMint (sebelumnya Keymaster) untuk layanan kriptografi, termasuk kriptografi yang didukung hardware untuk penyimpanan kunci yang mungkin mencakup Trusted Execution Environment (TEE) atau Secure Element (SE), seperti StrongBox.
  • Pengautentikasi pengguna. Membuktikan kehadiran pengguna dan/atau keberhasilan autentikasi. Android mendukung Gatekeeper untuk autentikasi PIN/pola/sandi dan Fingerprint untuk autentikasi sidik jari. Perangkat yang dikirimkan dengan Android 9 dan yang lebih tinggi dapat menggunakan BiometricPrompt sebagai titik integrasi tunggal untuk sidik jari dan biometrik tambahan. Komponen ini mengomunikasikan status autentikasinya dengan layanan keystore melalui saluran yang diautentikasi. (Sistem Android Keystore di tingkat framework juga didukung oleh layanan keystore.)

Setiap komponen ini khusus vendor, tetapi penerapan vendor diperlukan untuk memenuhi spesifikasi antarmuka Hardware Abstraction Layer (HAL) dan lulus tes rangkaian pengujian vendor (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, menerima permintaan Binder dari sistem Android.
  • Aplikasi tepercaya (TA) berjalan di lingkungan yang aman, melakukan operasi aman yang sebenarnya.

Pendaftaran

Saat perangkat di-boot pertama kali setelah direset ke setelan pabrik, semua pengautentikasi disiapkan untuk menerima pendaftaran kredensial dari pengguna. Pengguna harus mendaftarkan PIN, pola, atau sandi dengan Gatekeeper (atau Weaver, jika tersedia) pada awalnya. Pendaftaran awal ini membuat ID aman pengguna (SID) 64-bit yang dibuat secara acak yang berfungsi sebagai ID untuk pengguna dan sebagai token pengikatan untuk materi kriptografi 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 memberikan 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 memberikan 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-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 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. Di perangkat yang menjalankan Android 8.x dan yang lebih rendah, FingerprintService membuat permintaan ke fingerprintd). Di 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 yang setara, 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, TA Gatekeeper akan memancarkan 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, Fingerprint TA akan memancarkan AuthToken (ditandatangani dengan kunci HMAC AuthToken).
    • Untuk autentikasi biometrik lainnya, daemon biometrik yang sesuai akan memproses peristiwa biometrik dan mengirimkannya ke layanan HAL biometrik dan TA yang sesuai.
  3. Daemon menerima AuthToken bertanda tangan dan meneruskannya ke layanan keystore melalui ekstensi ke antarmuka Binder layanan keystore. (gatekeeperd juga memberi tahu layanan keystore saat perangkat dikunci ulang dan saat sandi perangkat berubah.)
  4. Layanan Keystore meneruskan AuthTokens ke KeyMint dan memverifikasinya menggunakan kunci yang dibagikan dengan komponen TEE biometrik yang didukung dan Gatekeeper. KeyMint memercayai stempel waktu dalam token sebagai waktu autentikasi terakhir dan mendasarkan keputusan pelepasan kunci (untuk mengizinkan aplikasi menggunakan kunci) pada stempel waktu.

Alur autentikasi tidak memerlukan komunikasi langsung antara TA di lingkungan yang aman: AuthToken mengalir dari TA autentikator ke layanan keystore2 di Android, yang pada gilirannya meneruskannya ke TA KeyMint. Hal ini juga memungkinkan layanan keystore2 dengan cepat menolak permintaan yang pasti gagal, karena layanan ini memiliki pengetahuan tentang AuthToken yang tersedia dalam 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, dan trustlet biometrik yang didukung). Oleh karena itu, untuk perlindungan tambahan terhadap serangan berulang, kunci HMAC harus dibuat secara acak setiap kali perangkat di-reboot.

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

  • Perjanjian secret bersama: Layanan keystore2 melakukan protokol perjanjian kunci multi-arah saat perangkat dimulai, sehingga memungkinkan turunan kunci HMAC yang aman di antara TA yang berpartisipasi. Namun, TA yang berpartisipasi harus memiliki akses ke rahasia yang telah dibagikan sebelumnya dan umum.
  • 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 secara langsung antara KeyMint dan Gatekeeper atau trustlet biometrik yang sesuai. Kunci HMAC disimpan secara eksklusif di KeyMint; Fingerprint dan Gatekeeper meminta kunci dari KeyMint untuk setiap penggunaan dan tidak menyimpan atau meng-cache nilai.

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