Penjaga gerbang

Subsistem Gatekeeper melakukan otentikasi pola/kata sandi perangkat di Trusted Execution Environment (TEE). Gatekeeper mendaftarkan dan memverifikasi kata sandi melalui HMAC dengan kunci rahasia yang didukung perangkat keras. Selain itu, Penjaga Gerbang membatasi upaya verifikasi yang gagal berturut-turut dan harus menolak permintaan layanan berdasarkan batas waktu yang diberikan dan sejumlah upaya gagal berturut-turut yang diberikan.

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 terikat autentikasi (misalnya, kunci yang telah dibuat aplikasi) dapat dirilis untuk digunakan oleh aplikasi.

Arsitektur

Gatekeeper melibatkan tiga komponen utama:

• gatekeeperd (daemon Gatekeeper). Layanan pengikat C++ yang berisi logika platform-independen dan sesuai dengan antarmuka Java GateKeeperService .
• Lapisan Abstraksi Perangkat Keras Penjaga Gerbang (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 (berdasarkan sebagian pada file header system/gatekeeper/include/gatekeeper/gatekeeper.h yang mencakup fungsi virtual murni untuk membuat/mengakses kunci dan tanda tangan komputasi).

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 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 mitra TEE gatekeeperd untuk otentikasi kata sandi. Implementasi HAL harus dapat menandatangani (mendaftar) dan memverifikasi blob. Semua implementasi diharapkan untuk mematuhi format standar untuk token otentikasi (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. Gumpalan yang dikembalikan (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 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 diturunkan ulang pada setiap boot perangkat.

Terpercaya 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 TEE OS apa pun untuk mengimplementasikan Gatekeeper selama TEE memiliki akses ke kunci yang didukung perangkat keras dan jam monoton yang aman yang berdetak di suspend .

Trusty menggunakan sistem IPC internal untuk mengkomunikasikan rahasia bersama secara langsung antara Keymaster dan implementasi Trusty Gatekeeper (The 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 nilainya. Implementasi bebas untuk membagikan rahasia ini dengan cara apa pun yang tidak membahayakan keamanan.

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

Android menyediakan implementasi GateKeeper C++ generik yang hanya membutuhkan penambahan rutin khusus perangkat untuk menyelesaikannya. 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 implementasi yang sesuai meliputi:

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

ID Aman Pengguna (SID)

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

User SID HMAC'ed bersama dengan kata sandi di 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 otentikasi (untuk detail tentang format AuthToken dan Keystore, lihat Otentikasi ). Karena panggilan tidak tepercaya ke fungsi enroll akan mengubah User SID, panggilan tersebut akan membuat kunci yang terikat ke kata sandi itu tidak berguna. Penyerang dapat mengubah kata sandi untuk perangkat jika mereka mengontrol OS Android, tetapi mereka akan menghancurkan kunci sensitif yang dilindungi root dalam prosesnya.

Permintaan pelambatan

GateKeeper harus dapat dengan aman mencekik upaya kekerasan pada kredensial pengguna. Seperti yang ditunjukkan dalam hardware/libhardware/include/hardware/gatekeeper.h , HAL menyediakan untuk mengembalikan batas waktu dalam milidetik. Batas waktu memberi tahu klien untuk tidak memanggil GateKeeper lagi sampai setelah batas waktu berlalu; GateKeeper seharusnya tidak 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 dibersihkan. Ini mencegah serangan yang mencegah pelambatan 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.