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 berturut-turut yang gagal dan harus menolak permintaan layanan berdasarkan waktu tunggu tertentu dan jumlah upaya berturut-turut yang gagal.

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 AIDL IGateKeeperService, berdasarkan implementasi khusus vendor yang mendasari IGatekeeper.
• Layanan hardware abstraction layer (HAL) Gatekeeper — Implementasi khusus vendor dari antarmuka AIDL IGatekeeper. Layanan HAL ini berjalan di Android, tetapi fungsi Gatekeeper inti perlu 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 menjangkau daemon gatekeeperd di Android OS. Daemon gatekeeperd kemudian membuat permintaan layanan HAL IGatekeeper, dan pada gilirannya mencapai Gatekeeper TA-nya 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.

Implementasi HAL

Daemon gatekeeperd menggunakan HAL IGatekeeper untuk berinteraksi dengan TA Gatekeeper yang mendasarinya untuk autentikasi sandi. Penerapan 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 HAL IGatekeeper harus mengimplementasikan fungsi enroll dan verify:

• Metode enroll mengambil 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, OS TEE apa pun dapat menerapkan Gatekeeper selama TEE memiliki akses ke kunci yang didukung hardware persisten dan jam monoton yang aman yang berdetak dalam mode ditangguhkan.

Trusty menggunakan sistem IPC internal untuk menyampaikan secret bersama secara langsung antara KeyMint dan penerapan 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 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; implementasi Trusty didasarkan pada hal ini. Untuk menerapkan TEE Gatekeeper 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 HardwareAuthToken.aidl).
• TEE Gatekeeper harus dapat membagikan kunci HMAC dengan KeyMint, menggunakan salah satu dari hal berikut:
  • Perjanjian secret bersama: Gatekeeper dapat berpartisipasi dalam negosiasi per booting kunci HMAC dengan menerapkan HAL ISharedSecret. Hal ini mengharuskan Gatekeeper dan KeyMint memiliki akses ke secret bersama yang dibagikan sebelumnya.
  • Akses langsung: Gatekeeper dapat mengambil kunci HMAC dari KeyMint menggunakan mekanisme komunikasi antarproses internal TEE, baik on demand atau pada penggunaan pertama (di-cache setelahnya).

ID aman pengguna (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 biasanya hanya terjadi saat pengguna pertama kali menetapkan sandi atau pola.

Pendaftaran ulang yang 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 dengan handle tersebut.

SID pengguna disertakan dalam autentikasi HMAC bersama dengan sandi di nama sebutan 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 tidak tepercaya ke fungsi enroll() mengubah SID pengguna, panggilan akan membuat kunci yang terikat dengan sandi tersebut tidak berguna. Penyerang dapat mengubah sandi untuk perangkat jika mereka mengontrol OS Android, tetapi mereka menghancurkan kunci sensitif yang dilindungi root dalam proses tersebut.

Membatasi permintaan

Gatekeeper harus dapat membatasi upaya brute force dengan aman pada kredensial pengguna. Seperti yang ditunjukkan dalam GatekeeperVerifyResponse.aidl, HAL menyediakan waktu tunggu dalam milidetik. Waktu tunggu akan memberi tahu klien untuk tidak memanggil Gatekeeper lagi hingga waktu tunggu berakhir. 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.