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.

Penjaga Gerbang
Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

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

Saat pengguna memverifikasi sandi mereka, Gatekeeper menggunakan secret bersama yang berasal dari TEE untuk menandatangani pengesahan autentikasi yang akan dikirim ke Keystore yang didukung hardware. Artinya, pengesahan Gatekeeper akan memberi tahu Keystore bahwa kunci yang terikat autentikasi (misalnya, kunci yang telah dibuat aplikasi) dapat dirilis untuk digunakan oleh aplikasi.

Arsitektur

Gatekeeper melibatkan tiga komponen utama:

gatekeeperd (daemon Gatekeeper). Layanan binder C++ yang berisi logika yang tidak bergantung pada platform dan sesuai dengan antarmuka Java GateKeeperService.
Gatekeeper Hardware Abstraction Layer (HAL). Antarmuka HAL di hardware/libhardware/include/hardware/gatekeeper.h, dan modul penerapan.
Pemisah komunikasi (TEE). Ekuivalen TEE dari gatekeeperd. Implementasi Gatekeeper berbasis TEE.

Gatekeeper memerlukan penerapan Gatekeeper HAL (khususnya fungsi di hardware/libhardware/include/hardware/gatekeeper.h) dan komponen Gatekeeper khusus TEE (sebagian didasarkan pada file header system/gatekeeper/include/gatekeeper/gatekeeper.h yang menyertakan fungsi virtual murni untuk membuat/mengakses kunci dan komputasi tanda tangan).

LockSettingsService membuat permintaan (melalui Binder) yang menjangkau daemon gatekeeperd di Android OS. Daemon gatekeeperd kemudian membuat permintaan yang menjangkau counterpart-nya (Gatekeeper) di TEE:

Gambar 1. Aliran 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.

Implementasi HAL

Daemon gatekeeperd menggunakan HAL untuk berinteraksi dengan rekan TEE daemon gatekeeperd untuk autentikasi sandi. Implementasi HAL harus dapat menandatangani (mendaftarkan) dan memverifikasi blob. Semua implementasi diharapkan mematuhi format standar untuk token autentikasi (AuthToken) yang dihasilkan pada setiap verifikasi sandi yang berhasil. Untuk mengetahui detail tentang konten dan semantik AuthToken, lihat format AuthToken.

Implementasi file header hardware/libhardware/include/hardware/gatekeeper.h harus mengimplementasikan fungsi enroll dan verify:

Fungsi enroll menggunakan blob sandi, menandatanganinya, dan menampilkan tanda tangan sebagai nama sebutan. 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 memastikannya cocok dengan nama sebutan sandi yang terdaftar.

Kunci yang digunakan untuk mendaftarkan dan memverifikasi tidak boleh berubah, dan harus dapat diturunkan kembali di 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, Anda dapat menggunakan OS TEE apa pun untuk menerapkan Gatekeeper selama TEE memiliki akses ke kunci yang didukung hardware dan jam monoton yang aman yang berdetak dalam mode tunda.

Trusty menggunakan sistem IPC internal untuk menyampaikan secret bersama secara langsung antara Keymaster dan penerapan 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 Keymaster untuk setiap penggunaan dan tidak mempertahankan atau meng-cache nilai. Implementasi bebas membagikan secret ini dengan cara apa pun yang tidak mengancam keamanan.

Kunci HMAC yang digunakan untuk mendaftarkan dan memverifikasi sandi berasal dan disimpan hanya di GateKeeper.

Android menyediakan implementasi GateKeeper C++ generik yang hanya memerlukan penambahan rutinitas khusus perangkat agar selesai. Untuk menerapkan TEE Gatekeeper dengan kode khusus perangkat untuk TEE Anda, lihat fungsi dan komentar di system/gatekeeper/include/gatekeeper/gatekeeper.h. Untuk TEE GateKeeper, tanggung jawab utama dari penerapan yang mematuhi mencakup:

Kepatuhan terhadap HAL Gatekeeper.
AuthToken yang ditampilkan harus diformat sesuai dengan spesifikasi AuthToken (dijelaskan dalam Autentikasi).
TEE Gatekeeper harus dapat membagikan kunci HMAC dengan Keymaster, baik dengan meminta kunci melalui TEE IPC on demand atau mempertahankan cache nilai yang valid setiap saat.

User Secure ID (SID)

SID Pengguna adalah representasi TEE pengguna (tanpa koneksi yang kuat ke ID pengguna Android). SID dibuat dengan generator bilangan pseudorandom kriptografis (PRNG) setiap kali pengguna mendaftarkan sandi baru tanpa memberikan sandi sebelumnya. Hal ini dikenal sebagai pendaftaran ulang tidak tepercaya dan tidak diizinkan oleh framework Android dalam keadaan normal. Pendaftaran ulang tepercaya terjadi saat pengguna memberikan sandi sebelumnya yang valid; dalam hal ini, SID Pengguna dimigrasikan ke nama sebutan sandi baru, sehingga mempertahankan kunci yang terikat dengannya.

SID Pengguna di-HMAC bersama dengan sandi di handle sandi saat sandi didaftarkan.

SID pengguna ditulis ke AuthToken yang ditampilkan oleh fungsi verify dan dikaitkan dengan semua kunci Keystore yang terikat autentikasi (untuk mengetahui detail format AuthToken dan Keystore, lihat Autentikasi). Karena panggilan yang tidak tepercaya ke fungsi enroll akan mengubah SID Pengguna, panggilan akan membuat kunci yang terikat dengan sandi tersebut tidak berguna. Penyerang dapat mengubah sandi untuk perangkat jika mereka mengontrol Android OS, tetapi mereka akan menghancurkan kunci sensitif yang dilindungi root dalam prosesnya.

Membatasi permintaan

GateKeeper harus dapat membatasi upaya brute force dengan aman pada kredensial pengguna. Seperti yang ditunjukkan dalam hardware/libhardware/include/hardware/gatekeeper.h, HAL menyediakan waktu tunggu dalam milidetik. Waktu tunggu akan memberi tahu klien agar tidak memanggil GateKeeper lagi hingga setelah waktu tunggu berlalu; GateKeeper tidak boleh melayani permintaan jika ada waktu tunggu yang tertunda.

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

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