Penjaga gerbang

Subsistem Gatekeeper melakukan otentikasi pola perangkat/kata sandi di Lingkungan Eksekusi Tepercaya (TEE). Gatekeeper mendaftarkan dan memverifikasi kata sandi melalui HMAC dengan kunci rahasia yang didukung perangkat keras. Selain itu, Gatekeeper membatasi upaya verifikasi yang gagal berturut-turut dan harus menolak permintaan layanan berdasarkan waktu tunggu tertentu dan sejumlah upaya gagal berturut-turut.

Saat pengguna memverifikasi kata sandi mereka, Gatekeeper menggunakan rahasia bersama yang diturunkan dari TEE untuk menandatangani pengesahan autentikasi untuk dikirim ke Keystore yang didukung perangkat keras . Artinya, pengesahan Gatekeeper memberi tahu Keystore bahwa kunci yang terikat autentikasi (misalnya, kunci yang telah dibuat oleh aplikasi) dapat dilepaskan untuk digunakan oleh aplikasi.

Arsitektur

Penjaga gerbang melibatkan tiga komponen utama:

• gatekeeperd (daemon penjaga gerbang). Layanan pengikat C++ yang berisi logika platform-independen dan sesuai dengan antarmuka Java GateKeeperService .
• Lapisan Abstraksi Perangkat Keras Gatekeeper (HAL) . Antarmuka HAL di hardware/libhardware/include/hardware/gatekeeper.h , dan modul implementasi.
• Penjaga gerbang (TEE) . Mitra TEE dari gatekeeperd . Implementasi Gatekeeper berbasis TEE.

Gatekeeper memerlukan implementasi 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 mencakup fungsi virtual murni untuk membuat/mengakses kunci dan menghitung tanda tangan).

LockSettingsService membuat permintaan (melalui Binder) yang mencapai daemon gatekeeperd di OS Android. Daemon gatekeeperd kemudian membuat permintaan yang mencapai mitranya (Gatekeeper) di TEE:

Gambar 1. Aliran data tingkat tinggi untuk otentikasi oleh GateKeeper

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

implementasi HAL

Daemon gatekeeperd menggunakan HAL untuk berinteraksi dengan mitra TEE daemon gatekeeperd untuk otentikasi kata 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 kata sandi yang berhasil. Untuk 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 mengambil gumpalan kata sandi, menandatanganinya, dan mengembalikan tanda tangan sebagai pegangan. Blob yang dikembalikan (dari panggilan ke enroll ) harus memiliki struktur yang ditunjukkan di system/gatekeeper/include/gatekeeper/password_handle.h .
• Fungsi verify harus membandingkan tanda tangan yang dihasilkan oleh kata sandi yang diberikan dan memastikannya cocok dengan pegangan kata sandi yang terdaftar.

Kunci yang digunakan untuk mendaftar dan memverifikasi tidak boleh berubah, dan harus dapat diturunkan kembali setiap kali perangkat melakukan booting.

Terpercaya dan implementasi lainnya

Sistem operasi Trusty adalah OS tepercaya sumber terbuka Google untuk lingkungan TEE dan berisi implementasi GateKeeper yang disetujui. Namun, Anda dapat menggunakan TEE OS apa pun untuk mengimplementasikan Gatekeeper selama TEE memiliki akses ke kunci yang didukung perangkat keras dan jam monotonik yang aman yang bertanda suspend .

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

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

Android menyediakan implementasi C++ umum untuk GateKeeper yang hanya memerlukan penambahan rutinitas khusus perangkat agar dapat diselesaikan. Untuk mengimplementasikan TEE Gatekeeper dengan kode khusus perangkat untuk TEE Anda, lihat fungsi dan komentar di system/gatekeeper/include/gatekeeper/gatekeeper.h . Bagi TEE GateKeeper, tanggung jawab utama penerapan kepatuhan meliputi:

• Kepatuhan terhadap Gatekeeper HAL.
• AuthToken yang dikembalikan harus diformat sesuai dengan spesifikasi AuthToken (dijelaskan dalam Authentication ).
• TEE Gatekeeper harus dapat berbagi kunci HMAC dengan Keymaster, baik dengan meminta kunci melalui TEE IPC sesuai permintaan atau menjaga cache nilai yang valid setiap saat.

ID Aman Pengguna (SID)

SID Pengguna adalah representasi TEE dari pengguna (tanpa koneksi kuat ke ID pengguna Android). SID dihasilkan dengan generator nomor pseudorandom kriptografi (PRNG) setiap kali pengguna mendaftarkan kata sandi baru tanpa memberikan kata sandi sebelumnya. Hal ini dikenal sebagai pendaftaran ulang tidak tepercaya dan tidak diizinkan oleh framework Android dalam keadaan normal. Pendaftaran ulang tepercaya terjadi ketika pengguna memberikan kata sandi sebelumnya yang valid; dalam hal ini, SID Pengguna dimigrasikan ke pegangan kata sandi baru, dengan mempertahankan kunci yang terikat padanya.

SID Pengguna diberi HMAC bersama dengan kata sandi dalam pegangan kata sandi saat kata sandi didaftarkan.

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

Minta pembatasan

GateKeeper harus mampu dengan aman membatasi upaya brute force pada kredensial pengguna. Seperti yang ditunjukkan di hardware/libhardware/include/hardware/gatekeeper.h , HAL menyediakan waktu tunggu dalam milidetik. Batas waktu tersebut memberi tahu klien untuk tidak memanggil GateKeeper lagi sampai batas waktu tersebut berlalu; GateKeeper tidak boleh melayani permintaan jika ada batas waktu yang tertunda.

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

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