Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Authentication

Android menggunakan konsep kunci kriptografis yang dibatasi autentikasi pengguna yang memerlukan komponen berikut:

Penyimpanan kunci kriptografis dan penyedia layanan. Menyimpan kunci kriptografis dan menyediakan rutinitas kripto standar di atas kunci tersebut. Android mendukung Keystore yang didukung hardware dan Keymaster untuk layanan kriptografis, termasuk kriptografi yang didukung hardware untuk penyimpanan kunci yang mungkin menyertakan Trusted Execution Environment (TEE) atau Elemen Pengaman (SE), seperti Strongbox.
Autentikasi pengguna. Menunjukkan kehadiran pengguna dan/atau autentikasi yang berhasil. Android mendukung Gatekeeper untuk autentikasi PIN/pola/sandi dan Fingerprint untuk autentikasi sidik jari. Perangkat yang dilengkapi dengan Android 9 dan yang lebih baru dapat menggunakan BiometricPrompt sebagai satu titik integrasi untuk sidik jari dan biometrik tambahan. Komponen ini menyampaikan status autentikasi mereka dengan layanan keystore melalui saluran yang diautentikasi. (Sistem Android Keystore di level framework juga didukung oleh layanan keystore.)

Komponen Gatekeeper, Sidik Jari, dan Biometrik berfungsi dengan Keystore dan komponen lainnya untuk mendukung penggunaan token autentikasi (AuthTokens) yang didukung hardware.

Pendaftaran

Saat perangkat pertama kali dinyalakan setelah reset ke setelan pabrik, semua pengautentikasi akan siap menerima pendaftaran kredensial dari pengguna. Pengguna harus mendaftarkan PIN/pola/sandi dengan Gatekeeper terlebih dahulu. Pendaftaran awal ini akan membuat ID aman pengguna (SID) 64-bit yang dibuat secara acak dan 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 harus menunjukkan kredensial yang ada. 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. Jika pengguna tidak memberikan kredensial yang ada, kredensial baru akan didaftarkan dengan SID Pengguna yang sepenuhnya acak. Pengguna dapat mengakses perangkat, tetapi kunci yang dibuat berdasarkan SID pengguna lama akan hilang secara permanen. Hal ini dikenal sebagai pendaftaran tidak tepercaya.

Dalam keadaan normal, framework Android tidak mengizinkan pendaftaran yang tidak tepercaya, sehingga sebagian besar pengguna tidak akan pernah melihat fungsi ini. Namun, reset sandi paksa, baik oleh administrator perangkat maupun penyerang, dapat menyebabkan hal ini terjadi.

Autentikasi

Setelah pengguna menyiapkan kredensial dan menerima SID pengguna, mereka dapat memulai autentikasi, yang dimulai saat pengguna memberikan PIN, pola, sandi, atau sidik jari. Semua komponen TEE memiliki kunci rahasia yang mereka gunakan untuk mengautentikasi pesan satu sama lain.

Gambar 1. Alur autentikasi

Pengguna memberikan metode autentikasi dan layanan terkait membuat permintaan ke daemon terkait.
- 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.
Daemon mengirimkan data ke daemon lainnya, yang menghasilkan AuthToken:
- Untuk autentikasi PIN/pola/sandi, gatekeeperd mengirimkan hash PIN, pola, atau sandi ke Gatekeeper di TEE. Jika autentikasi di TEE berhasil, Gatekeeper di TEE akan mengirimkan AuthToken yang berisi SID pengguna yang sesuai (ditandatangani dengan kunci HMAC AuthToken) ke pasangannya di Android OS.
- Untuk autentikasi sidik jari, fingerprintd memproses peristiwa sidik jari dan mengirimkan data ke Sidik Jari di TEE. Jika autentikasi di TEE berhasil, Sidik Jari di TEE akan mengirimkan AuthToken (ditandatangani dengan kunci HMAC AuthToken) ke pasangannya di OS Android.
- Untuk autentikasi biometrik lainnya, daemon biometrik yang sesuai akan memproses peristiwa biometrik dan mengirimkannya ke komponen TEE biometrik yang sesuai.
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 kembali dan saat sandi perangkat berubah.)
Layanan keystore meneruskan AuthTokens ke Keymaster dan memverifikasinya menggunakan kunci yang dibagikan ke Gatekeeper dan komponen TEE biometrik yang didukung. Keymaster memercayai stempel waktu dalam token sebagai waktu autentikasi terakhir dan mendasarkan keputusan rilis kunci (untuk mengizinkan aplikasi menggunakan kunci) pada stempel waktu.

Format AuthToken

Untuk memastikan berbagi token dan kompatibilitas di seluruh bahasa dan komponen, format AuthToken dijelaskan dalam hw_auth_token.h. Formatnya adalah protokol serialisasi sederhana dengan kolom ukuran tetap.

Kolom	Jenis	Wajib	Deskripsi
Versi AuthToken	1 byte	Ya	Tag grup untuk semua kolom di bawah.
Tantangan	Bilangan bulat 64-bit tanpa tanda	Tidak	Bilangan bulat acak untuk mencegah serangan replay. Biasanya ID operasi kripto yang diminta. Saat ini digunakan oleh otorisasi sidik jari transaksional. Jika ada, AuthToken hanya valid untuk operasi kripto yang berisi tantangan yang sama.
SID Pengguna	Bilangan bulat 64-bit tanpa tanda	Ya	ID pengguna yang tidak berulang yang terikat secara kriptografis ke semua kunci yang terkait dengan autentikasi perangkat. Untuk mengetahui detailnya, lihat Gatekeeper.
ID Pengautentikasi (ASID)	Bilangan bulat 64-bit tanpa tanda dalam urutan jaringan	Tidak	ID yang digunakan untuk mengikat ke kebijakan pengautentikasi tertentu. Semua pengautentikasi memiliki nilai ASID-nya sendiri yang dapat diubah sesuai dengan persyaratannya sendiri.
Jenis pengautentikasi	Bilangan bulat 32-bit tanpa tanda dalam urutan jaringan	Ya	0x00 adalah Gatekeeper. 0x01 adalah Sidik Jari.
Stempel waktu	Bilangan bulat 64-bit tanpa tanda dalam urutan jaringan	Ya	Waktu (dalam milidetik) sejak booting sistem terbaru.
AuthToken HMAC (SHA-256)	Blob 256-bit	Ya	MAC SHA-256 dengan kunci dari semua kolom kecuali kolom HMAC.

Alur booting perangkat

Pada setiap booting perangkat, kunci HMAC AuthToken harus dibuat dan dibagikan ke semua komponen TEE (Gatekeeper, Keymaster, dan trustlet biometrik yang didukung). Dengan demikian, untuk perlindungan tambahan terhadap serangan replay, kunci HMAC harus dibuat secara acak setiap kali perangkat dimulai ulang.

Protokol untuk membagikan kunci HMAC ini dengan semua komponen adalah fitur implementasi yang bergantung pada platform. Kunci tidak boleh tersedia di luar TEE. Jika OS TEE tidak memiliki mekanisme komunikasi antarproses (IPC) internal dan perlu mentransfer data melalui OS yang tidak tepercaya, transfer harus dilakukan melalui protokol pertukaran kunci yang aman.

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 Keymaster dan Gatekeeper atau trustlet biometrik yang sesuai. Kunci HMAC hanya disimpan di Keymaster; Sidik Jari dan Gatekeeper meminta kunci dari Keymaster untuk setiap penggunaan dan tidak mempertahankan 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 dengan cepat menolak permintaan yang pasti akan gagal karena memiliki pengetahuan tentang tabel autentikasi dalam sistem, sehingga menghemat IPC yang berpotensi mahal ke TEE.