Authentication

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

  • Penyedia layanan dan penyimpanan kunci kriptografi. Menyimpan kunci kriptografi dan menyediakan rutin kripto standar di atas kunci tersebut. Android mendukung hardware-backed Keystore dan KeyMint (sebelumnya Keymaster) yang didukung hardware 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 autentikasi yang berhasil. Android mendukung Gatekeeper untuk autentikasi PIN/pola/sandi dan Sidik Jari untuk autentikasi sidik jari. Perangkat yang dilengkapi dengan Android 9 dan yang lebih tinggi dapat menggunakan BiometricPrompt sebagai satu titik integrasi 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 untuk 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, 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 reset 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 kriptografi ke sandi pengguna; autentikasi yang berhasil ke Gatekeeper akan 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 yang tidak tepercaya untuk mendaftarkan kredensial baru tanpa memberikan 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 yang aman. Perhatikan bahwa semua komponen yang aman berbagi kunci HMAC rahasia (per-boot) yang digunakan 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. Di perangkat yang menjalankan Android 8.x dan yang lebih lama, 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 sesuai, 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 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 Sidik Jari TA di TEE, melalui Sidik Jari HAL. Jika autentikasi di TEE berhasil, Sidik Jari 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 dan TA HAL biometrik yang sesuai.
  3. Daemon menerima AuthToken yang ditandatangani 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 AuthToken ke KeyMint dan memverifikasinya menggunakan kunci yang dibagikan dengan Gatekeeper dan komponen TEE biometrik yang didukung. KeyMint mempercayai stempel waktu dalam token sebagai waktu autentikasi terakhir dan mendasarkan keputusan rilis kunci (untuk mengizinkan aplikasi menggunakan kunci) pada stempel waktu.

Alur autentikasi tidak memerlukan komunikasi langsung antara TA di lingkungan yang aman: Alur AuthToken dari TA pengautentikasi ke layanan keystore2 di Android, yang kemudian meneruskannya ke KeyMint TA. Hal ini juga memungkinkan layanan keystore2 untuk menolak permintaan yang pasti gagal dengan cepat, karena 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 dengan semua komponen TEE (Gatekeeper, KeyMint, dan trustlet biometrik yang didukung). Oleh karena itu, untuk perlindungan tambahan terhadap serangan replay, kunci HMAC harus dibuat secara acak setiap kali perangkat di-reboot.

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 startup perangkat, sehingga memungkinkan turunan kunci HMAC yang aman antara TA yang berpartisipasi. Namun, TA yang berpartisipasi harus memiliki akses ke rahasia bersama yang telah dibagikan sebelumnya.
  • Akses langsung: TA yang berada dalam lingkungan aman yang sama dapat menggunakan mekanisme komunikasi antar-proses internal (yang bergantung pada platform) untuk berbagi 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 trustlet biometrik yang sesuai. Kunci HMAC hanya disimpan di KeyMint; Sidik Jari 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 untuk menolak permintaan yang pasti gagal dengan cepat karena memiliki pengetahuan tentang tabel autentikasi dalam sistem, sehingga menghemat IPC yang berpotensi mahal ke TEE.