Pemilah Komunikasi

Subsystem 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 yang diberikan dan jumlah upaya yang gagal berturut-turut.

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 autentikasi (misalnya, kunci yang 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 menerapkan IGateKeeperService antarmuka AIDL, berdasarkan implementasi IGatekeeper khusus vendor yang mendasarinya.
  • Layanan hardware abstraction layer (HAL) Gatekeeper — Implementasi antarmuka AIDL IGatekeeper khusus vendor. Layanan HAL ini berjalan di Android, tetapi fungsi inti Gatekeeper harus berjalan di lingkungan yang aman, sehingga biasanya berkomunikasi dengan Gatekeeper TA.
  • 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 Gatekeeper TA yang sesuai di TEE:

Alur pemilah komunikasi

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

Daemon gatekeeperd memberi framework Android akses API 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 Gatekeeper TA yang mendasarinya untuk autentikasi sandi. Implementasi Gatekeeper TA harus dapat menandatangani (mendaftarkan) dan memverifikasi blob. Semua implementasi diharapkan mematuhi format standar untuk token autentikasi (HardwareAuthToken) yang dibuat pada setiap verifikasi sandi yang berhasil. Untuk mengetahui detail tentang konten dan semantik HardwareAuthToken, lihat definisi HardwareAuthToken.aidl.

Implementasi vendor HAL IGatekeeper harus menerapkan fungsi enroll dan verify:

  • Metode enroll mengambil blob sandi, menandatanganinya, dan menampilkan tanda tangan sebagai handle. 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 mendaftar dan memverifikasi tidak boleh berubah, dan harus dapat diturunkan kembali 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 yang didukung hardware persisten dan clock monoton yang aman yang berdetak dalam mode 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 mempertahankan atau menyimpan nilai dalam cache. Implementasi bebas membagikan rahasia ini dengan cara apa pun yang tidak membahayakan keamanan.

Kunci HMAC yang digunakan untuk mendaftar dan memverifikasi sandi diturunkan dan disimpan hanya 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 TEE Gatekeeper dengan kode khusus perangkat untuk TEE Anda, lihat fungsi dan komentar di system/gatekeeper/include/gatekeeper/gatekeeper.h. Tanggung jawab utama implementasi yang sesuai mencakup:

  • Kepatuhan terhadap HAL IGatekeeper.
  • Token autentikasi yang ditampilkan harus diformat sesuai dengan spesifikasi HardwareAuthToken (dijelaskan dalam Autentikasi).
  • TEE Gatekeeper 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 pengguna (SID)

SID pengguna adalah representasi TEE pengguna (tanpa koneksi yang kuat ke ID pengguna Android). SID dibuat dengan cryptographic pseudorandom number generator (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 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 tidak tepercaya ke fungsi enroll() mengubah SID pengguna, panggilan tersebut membuat kunci yang terikat ke sandi tersebut tidak berguna. Penyerang dapat mengubah sandi untuk perangkat jika mereka mengontrol Android OS, tetapi mereka menghancurkan kunci sensitif yang dilindungi root dalam proses tersebut.

Pembatasan permintaan

Gatekeeper harus dapat membatasi upaya brute-force pada kredensial pengguna dengan aman. Seperti yang ditunjukkan di GatekeeperVerifyResponse.aidl, HAL menyediakan pengembalian waktu tunggu dalam milidetik. Waktu tunggu memberi tahu klien untuk tidak memanggil Gatekeeper lagi hingga waktu tunggu telah 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 pembatasan 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 penghitung kegagalan ditulis ke penyimpanan yang aman. Jika perangkat tidak mendukung enkripsi berbasis file, atau jika penyimpanan yang aman terlalu lambat, implementasi dapat menggunakan Replay Protected Memory Block (RPMB) secara langsung.