Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.

Halaman ini diterjemahkan oleh Cloud Translation API.

Pemilah Komunikasi

Subsistem Gatekeeper melakukan autentikasi pola/sandi perangkat di Trusted Execution Environment (TEE). Gatekeeper mendaftarkan dan memverifikasi sandi menggunakan kunci rahasia yang didukung hardware. Selain itu, Gatekeeper membatasi upaya verifikasi gagal berturut-turut dan harus menolak permintaan layanan berdasarkan waktu tunggu tertentu dan sejumlah upaya gagal berturut-turut tertentu.

Saat pengguna memverifikasi sandi mereka, Gatekeeper akan mengeluarkan token autentikasi yang ditandatangani dengan kunci HMAC per-boot yang hanya tersedia untuk komponen aman, dan token ini dikirim ke Keystore yang didukung hardware. Artinya, token autentikasi Gatekeeper memberi tahu Keystore bahwa kunci yang terikat dengan autentikasi (misalnya, kunci yang telah dibuat aplikasi) dapat digunakan oleh aplikasi.

Arsitektur

Gatekeeper melibatkan tiga komponen utama:

gatekeeperd (daemon Gatekeeper) — Layanan Binder C++ di Android yang berisi logika independen platform yang mengimplementasikan antarmuka AIDL IGateKeeperService, berdasarkan implementasi IGatekeeper spesifik vendor yang mendasarinya.
Layanan hardware abstraction layer (HAL) Gatekeeper — Implementasi khusus vendor dari antarmuka AIDL IGatekeeper. Layanan HAL ini berjalan di Android, tetapi fungsi inti Gatekeeper harus berjalan di lingkungan yang aman, sehingga biasanya berkomunikasi dengan TA Gatekeeper.
Aplikasi Tepercaya (TA) Gatekeeper — Implementasi khusus vendor yang berjalan di TEE, dan melakukan verifikasi sandi atau pola yang sebenarnya.

LockSettingsService membuat permintaan (melalui Binder) yang mencapai daemon gatekeeperd di Android OS. Daemon gatekeeperd kemudian membuat permintaan layanan HAL IGatekeeper, yang pada gilirannya mencapai TA Gatekeeper yang setara di TEE:

Gambar 1. Alur data tingkat tinggi untuk autentikasi oleh GateKeeper.

Daemon gatekeeperd memberi API framework Android akses ke HAL, dan berpartisipasi dalam melaporkan autentikasi perangkat ke Keystore. Daemon gatekeeperd berjalan dalam prosesnya sendiri dan terpisah dari server sistem.

Penerapan HAL

Daemon gatekeeperd menggunakan HAL IGatekeeper untuk berinteraksi dengan TA Gatekeeper yang mendasarinya untuk autentikasi sandi. Penerapan TA Gatekeeper harus dapat menandatangani (mendaftarkan) dan memverifikasi blob. Semua penerapan diharapkan mematuhi format standar untuk token autentikasi (HardwareAuthToken) yang dihasilkan pada setiap verifikasi sandi yang berhasil. Untuk mengetahui detail tentang konten dan semantik HardwareAuthToken, lihat definisi HardwareAuthToken.aidl.

Implementasi HAL IGatekeeper oleh vendor harus menerapkan fungsi enroll dan verify:

Metode enroll mengambil blob sandi, menandatanganinya, dan menampilkan tanda tangan sebagai tuas. Blob yang ditampilkan (dari panggilan ke enroll) harus memiliki struktur yang ditampilkan di system/gatekeeper/include/gatekeeper/password_handle.h.
Fungsi verify harus membandingkan tanda tangan yang dihasilkan oleh sandi yang diberikan dan memastikan tanda tangan tersebut cocok dengan handle sandi yang terdaftar.

Kunci yang digunakan untuk mendaftarkan dan memverifikasi tidak boleh berubah, dan harus dapat diturunkan ulang pada setiap booting perangkat.

Trusty dan implementasi lainnya

Sistem operasi Trusty adalah OS tepercaya open source Google untuk lingkungan TEE dan berisi implementasi Gatekeeper yang disetujui. Namun, OS TEE apa pun dapat menerapkan Gatekeeper selama TEE memiliki akses ke kunci persisten yang didukung hardware dan jam monotonik yang aman yang berdetak saat ditangguhkan.

Trusty menggunakan sistem IPC internal untuk mengomunikasikan rahasia bersama secara langsung antara KeyMint (sebelumnya Keymaster) dan implementasi Gatekeeper Trusty (Trusty Gatekeeper). Rahasia bersama ini digunakan untuk menandatangani AuthToken yang dikirim ke Keystore untuk memberikan pengesahan verifikasi sandi. Trusty Gatekeeper meminta kunci dari KeyMint untuk setiap penggunaan dan tidak menyimpan atau meng-cache nilai. Implementasi bebas membagikan rahasia ini dengan cara apa pun yang tidak membahayakan keamanan.

Kunci HMAC yang digunakan untuk mendaftarkan dan memverifikasi sandi berasal dan disimpan secara eksklusif di Gatekeeper.

Android menyediakan implementasi Gatekeeper C++ generik yang hanya memerlukan penambahan rutin khusus perangkat agar selesai; implementasi Trusty didasarkan pada hal ini. Untuk menerapkan Penjaga Gerbang TEE dengan kode khusus perangkat untuk TEE Anda, lihat fungsi dan komentar di system/gatekeeper/include/gatekeeper/gatekeeper.h. Tanggung jawab utama penerapan yang mematuhi kebijakan mencakup:

Kepatuhan terhadap HAL IGatekeeper.
Token autentikasi yang ditampilkan harus diformat sesuai dengan spesifikasi HardwareAuthToken (dijelaskan dalam Autentikasi).
Penjaga Gerbang TEE harus dapat membagikan kunci HMAC dengan KeyMint, baik dengan meminta kunci melalui IPC TEE sesuai permintaan atau mempertahankan cache nilai yang valid setiap saat.

ID aman (SID) pengguna

SID pengguna adalah representasi pengguna TEE (tanpa koneksi yang kuat ke ID pengguna Android). SID dibuat dengan generator angka pseudorandom (PRNG) kriptografi setiap kali pengguna mendaftarkan sandi baru tanpa memberikan sandi sebelumnya. Hal ini dikenal sebagai pendaftaran ulang tidak tepercaya dan biasanya hanya terjadi saat pengguna pertama kali menyetel sandi atau pola.

Pendaftaran ulang tepercaya terjadi saat pengguna memberikan sandi sebelumnya yang valid, seperti saat mengubah sandi. Dalam hal ini, SID pengguna dimigrasikan ke handle sandi baru, dengan mempertahankan kunci yang terikat padanya.

SID pengguna disertakan dalam autentikasi HMAC bersama dengan sandi di handle sandi saat sandi didaftarkan.

SID pengguna disertakan dalam HardwareAuthToken yang ditampilkan oleh fungsi verify() dan dikaitkan dengan semua kunci Keystore yang terikat autentikasi (untuk mengetahui detail tentang format HardwareAuthToken dan Keystore, lihat Autentikasi).

Perhatikan bahwa karena panggilan yang tidak tepercaya ke fungsi enroll() mengubah SID pengguna, panggilan tersebut membuat kunci yang terikat ke sandi tersebut tidak berguna. Penyerang dapat mengubah sandi perangkat jika mereka mengontrol OS Android, tetapi mereka menghancurkan kunci sensitif yang dilindungi root dalam proses tersebut.

Pembatasan permintaan

Gatekeeper harus dapat membatasi upaya serangan brute force pada kredensial pengguna dengan aman. Seperti yang ditunjukkan dalam GatekeeperVerifyResponse.aidl, HAL menyediakan pengembalian waktu tunggu dalam milidetik. Waktu tunggu memberi tahu klien untuk tidak memanggil Gatekeeper lagi hingga waktu tunggu berakhir. Gatekeeper tidak boleh melayani permintaan jika ada waktu tunggu yang belum selesai.

Gatekeeper harus menulis penghitung kegagalan sebelum memverifikasi sandi pengguna. Jika verifikasi sandi berhasil, penghitung kegagalan harus dihapus. Hal ini mencegah serangan yang mencegah pembatasan kecepatan dengan menonaktifkan MMC (eMMC) tersemat setelah mengeluarkan panggilan verify. Fungsi enroll juga memverifikasi sandi pengguna (jika diberikan) dan harus dibatasi dengan cara yang sama.

Jika didukung oleh perangkat, sebaiknya counter kegagalan ditulis ke penyimpanan aman. Jika perangkat tidak mendukung enkripsi berbasis file, atau jika penyimpanan aman terlalu lambat, implementasi dapat menggunakan Replay Protected Memory Block (RPMB) secara langsung.