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 yang gagal berturut-turut dan harus menolak permintaan layanan berdasarkan waktu tunggu tertentu dan jumlah upaya gagal berturut-turut tertentu.
Saat pengguna memverifikasi sandi mereka, Gatekeeper akan memunculkan token autentikasi yang ditandatangani dengan kunci HMAC per booting yang hanya tersedia untuk komponen yang aman, dan token ini dikirim ke Keystore yang didukung hardware. Artinya, token autentikasi Gatekeeper memberi tahu Keystore bahwa kunci yang terikat 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 AIDLIGateKeeperService, berdasarkan implementasiIGatekeeperyang mendasarinya dan spesifik vendor.- Layanan hardware abstraction layer (HAL) Gatekeeper — Implementasi
khusus vendor dari
antarmuka AIDL
IGatekeeper. Layanan HAL ini berjalan di Android, tetapi fungsi Gatekeeper inti harus berjalan di lingkungan yang aman, sehingga biasanya berkomunikasi dengan TA Gatekeeper. - Gatekeeper Trusted Application (TA) — 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, dan pada gilirannya mencapai
TA Gatekeeper pasangannya 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 IGatekeeper untuk
berinteraksi dengan TA Gatekeeper yang mendasarinya untuk autentikasi sandi. Implementasi
Gatekeeper TA 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 vendor IGatekeeper HAL harus mengimplementasikan
fungsi enroll dan verify:
- Metode
enrollmengambil blob sandi, menandatanganinya, dan menampilkan tanda tangan sebagai handle. Blob yang ditampilkan (dari panggilan keenroll) harus memiliki struktur yang ditampilkan disystem/gatekeeper/include/gatekeeper/password_handle.h. - Fungsi
verifyharus 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, TEE OS apa pun dapat mengimplementasikan Gatekeeper asalkan TEE memiliki akses ke kunci yang didukung hardware persisten dan jam monotonik yang aman yang berdetak dalam mode tunda.
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 token autentikasi yang dikirim ke Keystore untuk memberikan pengesahan verifikasi sandi. Trusty Gatekeeper meminta kunci dari KeyMint untuk setiap penggunaan dan tidak mempertahankan atau menyimpan nilai dalam cache. Implementasi bebas membagikan rahasia ini dengan cara apa pun yang tidak membahayakan keamanan.
Kunci HMAC yang digunakan untuk mendaftarkan dan memverifikasi sandi diperoleh dan disimpan hanya di Gatekeeper.
Android menyediakan implementasi Gatekeeper C++ generik yang hanya memerlukan
penambahan rutinitas khusus perangkat agar lengkap; implementasi Trusty
didasarkan pada hal ini. Untuk mengimplementasikan Gatekeeper TEE dengan
kode khusus perangkat untuk TEE Anda, lihat fungsi dan komentar
di system/gatekeeper/include/gatekeeper/gatekeeper.h. Tanggung jawab utama
penerapan yang sesuai mencakup:
- Kepatuhan terhadap HAL
IGatekeeper. - Token autentikasi yang ditampilkan harus diformat sesuai dengan spesifikasi
HardwareAuthToken(dijelaskan dalamHardwareAuthToken.aidl). - Gatekeeper TEE harus dapat berbagi kunci HMAC dengan KeyMint, menggunakan salah satu dari berikut ini:
- Perjanjian rahasia bersama: Gatekeeper dapat berpartisipasi dalam
negosiasi per booting kunci HMAC dengan mengimplementasikan
HAL
ISharedSecret. Hal ini mengharuskan Gatekeeper dan KeyMint memiliki akses ke rahasia yang dibagikan sebelumnya. - Akses langsung: Gatekeeper dapat mengambil kunci HMAC dari KeyMint menggunakan mekanisme komunikasi antarproses internal TEE, baik sesuai permintaan maupun saat penggunaan pertama (di-cache setelahnya).
- Perjanjian rahasia bersama: Gatekeeper dapat berpartisipasi dalam
negosiasi per booting kunci HMAC dengan mengimplementasikan
HAL
ID aman (SID) pengguna
SID pengguna adalah representasi TEE dari pengguna (tanpa koneksi yang kuat ke ID pengguna Android). SID dibuat dengan generator angka pseudorandom kriptografis (PRNG) 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, sehingga 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 akan membuat kunci yang terikat ke 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.
Throttling permintaan
Gatekeeper harus dapat membatasi upaya 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 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, sangat disarankan agar 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.