Fitur

Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Halaman ini berisi informasi tentang fitur kriptografi Keystore di Android 6.0 dan yang lebih baru.

Primitif kriptografi

Keystore menyediakan kategori operasi berikut:

• Pembuatan kunci
• Mengimpor dan mengekspor kunci asimetris (tanpa key wrapping)
• Impor kunci simetris mentah (tanpa penggabungan kunci)
• Enkripsi dan dekripsi asimetris dengan mode padding yang sesuai
• Penandatanganan dan verifikasi asimetris dengan mode ringkasan dan padding yang sesuai
• Enkripsi dan dekripsi simetris dalam mode yang sesuai, termasuk mode AEAD
• Pembuatan dan verifikasi kode autentikasi pesan simetris

Elemen protokol, seperti tujuan, mode, dan padding, serta batasan kontrol akses, ditentukan saat kunci dibuat atau diimpor dan secara permanen terikat dengan kunci, sehingga memastikan kunci tidak dapat digunakan dengan cara lain.

Selain daftar di atas, ada satu lagi layanan yang disediakan oleh implementasi Keymaster, tetapi tidak ditampilkan sebagai API: Pembuatan angka acak. Ini digunakan secara internal untuk pembuatan kunci, Vektor Inisialisasi (IV), padding acak, dan elemen lain dari protokol aman yang memerlukan keacakan.

Primitif yang diperlukan

Semua implementasi Keymaster menyediakan:

• RSA
  • Dukungan kunci 2048, 3072, dan 4096-bit
  • Dukungan untuk eksponen publik F4 (2^16+1)
  • Mode padding untuk penandatanganan RSA:
    • RSASSA-PSS (PaddingMode::RSA_PSS)
    • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
  • Mode ringkasan untuk penandatanganan RSA:
    • SHA-256
  • Mode padding untuk enkripsi/dekripsi RSA:
    • Tanpa padding
    • RSAES-OAEP (PaddingMode::RSA_OAEP)
    • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
• ECDSA
  • Dukungan kunci 224, 256, 384, dan 521-bit didukung, menggunakan kurva NIST P-224, P-256, P-384, dan P-521
  • Mode ringkasan untuk ECDSA:
    • Tidak ada ringkasan (tidak digunakan lagi, akan dihapus pada masa mendatang)
    • SHA-256
• AES
  • Kunci 128 dan 256-bit didukung
  • CBC, CTR, ECB, dan GCM. Implementasi GCM tidak mengizinkan penggunaan tag yang lebih kecil dari 96 bit atau panjang nonce selain 96 bit.
  • Mode padding PaddingMode::NONE dan PaddingMode::PKCS7 didukung untuk mode CBC dan ECB. Tanpa padding, enkripsi CBC atau mode ECB gagal jika input bukan kelipatan ukuran blok.
• HMAC SHA-256, dengan ukuran kunci apa pun hingga minimal 32 byte.

SHA1 dan anggota keluarga SHA2 lainnya (SHA-224, SHA384, dan SHA512) sangat direkomendasikan untuk penerapan Keymaster. Keystore menyediakannya dalam software jika penerapan Keymaster hardware tidak menyediakannya.

Beberapa primitif juga direkomendasikan untuk interoperabilitas dengan sistem lain:

• Ukuran kunci yang lebih kecil untuk RSA
• Eksponen publik arbitrer untuk RSA

Kontrol akses kunci

Kunci berbasis hardware yang tidak pernah dapat diekstrak dari perangkat tidak memberikan keamanan yang memadai jika penyerang dapat menggunakannya sesuka hati (meskipun lebih aman daripada kunci yang dapat diekspor). Oleh karena itu, Keystore harus menerapkan kontrol akses.

Kontrol akses ditentukan sebagai "daftar otorisasi" pasangan tag/nilai. Tag otorisasi adalah bilangan bulat 32-bit dan nilainya adalah berbagai jenis. Beberapa tag dapat diulang untuk menentukan beberapa nilai. Apakah tag dapat diulang ditentukan di antarmuka HAL KeyMint (sebelumnya Keymaster). Saat kunci dibuat, pemanggil menentukan daftar otorisasi. Implementasi Keymaster di balik Keystore mengubah daftar untuk menentukan beberapa informasi tambahan, seperti apakah kunci memiliki perlindungan rollback, dan menampilkan daftar otorisasi "final", yang dienkode ke dalam blob kunci yang ditampilkan. Setiap upaya untuk menggunakan kunci untuk operasi kriptografi apa pun akan gagal jika daftar otorisasi akhir diubah.

Untuk Keymaster 2 dan yang lebih lama, kumpulan tag yang mungkin ditentukan dalam enumerasi keymaster_authorization_tag_t dan ditetapkan secara permanen (meskipun dapat diperluas). Nama diawali dengan KM_TAG. Empat bit teratas ID tag digunakan untuk menunjukkan jenisnya.

Keymaster 3 mengubah awalan KM_TAG menjadi Tag::.

Kemungkinan jenisnya mencakup:

ENUM: Banyak nilai tag ditentukan dalam enumerasi. Misalnya, kemungkinan nilai TAG::PURPOSE ditentukan dalam enum keymaster_purpose_t.

ENUM_REP: Sama seperti ENUM, kecuali tag dapat diulang dalam daftar otorisasi. Pengulangan menunjukkan beberapa nilai yang diotorisasi. Misalnya, kunci enkripsi mungkin memiliki KeyPurpose::ENCRYPT dan KeyPurpose::DECRYPT.

UINT: Bilangan bulat 32-bit tanpa tanda. Contoh: TAG::KEY_SIZE

UINT_REP: Sama seperti UINT, kecuali tag dapat diulang dalam daftar otorisasi. Pengulangan menunjukkan beberapa nilai yang diotorisasi.

ULONG: Bilangan bulat 64-bit tanpa tanda. Contoh: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP: Sama seperti ULONG, kecuali tag dapat diulang dalam daftar otorisasi. Pengulangan menunjukkan beberapa nilai yang diotorisasi.

DATE: Nilai tanggal/waktu, yang dinyatakan sebagai milidetik sejak 1 Januari 1970. Contoh: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL: Benar atau salah. Tag jenis BOOL diasumsikan "false" jika tag tidak ada dan "true" jika ada. Contoh: TAG::ROLLBACK_RESISTANT

BIGNUM: Bilangan bulat dengan panjang arbitrer, dinyatakan sebagai array byte dalam urutan big-endian. Contoh: TAG::RSA_PUBLIC_EXPONENT

BYTES: Urutan byte. Contoh: TAG::ROOT_OF_TRUST

Penerapan hardware versus software

Tidak semua implementasi hardware aman berisi fitur yang sama. Untuk mendukung berbagai pendekatan, Keymaster membedakan antara penerapan kontrol akses dunia yang aman dan tidak aman, atau penerapan hardware dan software.

Semua implementasi:

• Terapkan pencocokan persis (bukan penerapan) untuk semua otorisasi. Daftar otorisasi dalam blob kunci sama persis dengan otorisasi yang ditampilkan selama pembuatan kunci, termasuk pengurutan. Setiap ketidakcocokan akan menyebabkan diagnostik error.
• Deklarasikan otorisasi yang nilai semantiknya diterapkan.

Mekanisme API untuk mendeklarasikan otorisasi yang diterapkan hardware berada dalam struktur keymaster_key_characteristics_t. Tindakan ini membagi daftar otorisasi menjadi dua sub-daftar, hw_enforced dan sw_enforced. Hardware aman bertanggung jawab untuk menempatkan nilai yang sesuai di setiap hardware, berdasarkan apa yang dapat diterapkan.

Selain itu, Keystore menerapkan penerapan berbasis software untuk semua otorisasi, baik yang diberlakukan oleh hardware aman maupun tidak.

Misalnya, pertimbangkan implementasi berbasis TrustZone yang tidak mendukung masa berlaku kunci. Kunci dengan tanggal habis masa berlaku mungkin masih dibuat. Daftar otorisasi kunci tersebut menyertakan tag TAG::ORIGINATION_EXPIRE_DATETIME dengan tanggal habis masa berlaku. Permintaan ke Keystore untuk karakteristik kunci akan menemukan tag ini dalam daftar sw_enforced dan hardware aman tidak menerapkan persyaratan masa berlaku. Namun, upaya untuk menggunakan kunci setelah masa berlakunya berakhir akan ditolak oleh Keystore.

Jika perangkat kemudian diupgrade dengan hardware aman yang mendukung masa berlaku, permintaan karakteristik kunci akan menemukan TAG::ORIGINATION_EXPIRE_DATETIME dalam daftar hw_enforced, dan mencoba menggunakan kunci setelah masa berlakunya berakhir meskipun keystore dirusak atau diabaikan.

Untuk informasi selengkapnya tentang cara menentukan apakah kunci didukung hardware, lihat Pengesahan kunci.

Otorisasi konstruksi pesan kriptografis

Tag berikut digunakan untuk menentukan karakteristik kriptografis operasi menggunakan kunci terkait: TAG::ALGORITHM, TAG::KEY_SIZE, TAG::BLOCK_MODE, TAG::PADDING, TAG::CALLER_NONCE, dan TAG::DIGEST

TAG::PADDING, TAG::DIGEST, dan PaddingMode::BLOCK_MODE dapat diulang, yang berarti beberapa nilai dapat dikaitkan dengan satu kunci, dan nilai yang akan digunakan ditentukan pada waktu operasi.

Tujuan

Kunci memiliki kumpulan tujuan terkait, yang dinyatakan sebagai satu atau beberapa entri otorisasi dengan tag TAG::PURPOSE, yang menentukan cara kunci tersebut dapat digunakan. Tujuannya adalah:

• KeyPurpose::ENCRYPT
• KeyPurpose::DECRYPT
• KeyPurpose::SIGN
• KeyPurpose::VERIFY

Setiap kunci dapat memiliki subset dari tujuan ini. Perhatikan bahwa beberapa kombinasi akan menimbulkan masalah keamanan. Misalnya, kunci RSA yang dapat digunakan untuk mengenkripsi dan menandatangani memungkinkan penyerang yang dapat meyakinkan sistem untuk mendekripsi data arbitrer guna menghasilkan tanda tangan.

Mengimpor dan mengekspor

Keymaster hanya mendukung ekspor kunci publik, dalam format X.509, dan impor dari:

• Pasangan kunci publik dan pribadi dalam format PKCS#8 yang dienkode DER, tanpa enkripsi berbasis sandi
• Kunci simetris sebagai byte mentah

Untuk memastikan bahwa kunci yang diimpor dapat dibedakan dari kunci yang dihasilkan dengan aman, TAG::ORIGIN disertakan dalam daftar otorisasi kunci yang sesuai. Misalnya, jika kunci dibuat di hardware aman, TAG::ORIGIN dengan nilai KeyOrigin::GENERATED akan ditemukan di daftar hw_enforced karakteristik kunci, sedangkan kunci yang diimpor ke hardware aman memiliki nilai KeyOrigin::IMPORTED.

Autentikasi pengguna

Implementasi Keymaster yang aman tidak menerapkan autentikasi pengguna, tetapi bergantung pada aplikasi tepercaya lainnya yang melakukannya. Untuk antarmuka yang diterapkan aplikasi ini, lihat halaman Gatekeeper.

Persyaratan autentikasi pengguna ditentukan melalui dua kumpulan tag. Kumpulan pertama menunjukkan pengguna mana yang dapat menggunakan kunci:

• TAG::ALL_USERS menunjukkan bahwa kunci dapat digunakan oleh semua pengguna. Jika ada, TAG::USER_ID dan TAG::USER_SECURE_ID tidak ada.
• TAG::USER_ID memiliki nilai numerik yang menentukan ID pengguna yang diberi otorisasi. Perhatikan bahwa ini adalah ID pengguna Android (untuk multi-pengguna), bukan UID aplikasi, dan hanya diterapkan oleh software yang tidak aman. Jika ada, TAG::ALL_USERS tidak ada.
• TAG::USER_SECURE_ID memiliki nilai numerik 64-bit yang menentukan ID pengguna aman yang diberikan dalam token autentikasi aman untuk membuka kunci penggunaan kunci. Jika diulang, kunci dapat digunakan jika salah satu nilai disediakan dalam token autentikasi yang aman.

Kumpulan kedua menunjukkan apakah dan kapan pengguna perlu diautentikasi. Jika tidak ada tag ini, tetapi TAG::USER_SECURE_ID ada, autentikasi diperlukan untuk setiap penggunaan kunci.

• NO_AUTHENTICATION_REQUIRED menunjukkan bahwa tidak diperlukan autentikasi pengguna, meskipun kunci masih dapat digunakan hanya oleh aplikasi yang berjalan sebagai pengguna yang ditentukan oleh TAG::USER_ID.
• TAG::AUTH_TIMEOUT adalah nilai numerik yang menentukan, dalam detik, seberapa baru autentikasi pengguna harus dilakukan untuk memberikan otorisasi penggunaan kunci. Hal ini hanya berlaku untuk operasi kunci pribadi/rahasia. Operasi kunci publik tidak memerlukan autentikasi. Waktu tunggu tidak melewati mulai ulang; setelah mulai ulang, semua kunci tidak pernah diautentikasi. Waktu tunggu dapat ditetapkan ke nilai besar untuk menunjukkan bahwa autentikasi diperlukan sekali per booting (2^32 detik adalah ~136 tahun; mungkin perangkat Android di-reboot lebih sering dari itu).

Memerlukan perangkat yang tidak terkunci

Kunci dengan TAG::UNLOCKED_DEVICE_REQUIRED hanya dapat digunakan saat perangkat tidak terkunci. Untuk semantik mendetail, lihat KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED diterapkan oleh Keystore, bukan oleh Keymaster. Namun, di Android 12 dan yang lebih tinggi, Keystore secara kriptografis melindungi kunci UNLOCKED_DEVICE_REQUIRED saat perangkat terkunci untuk memastikan bahwa, dalam sebagian besar kasus, kunci tersebut tidak dapat digunakan meskipun Keystore telah disusupi saat perangkat terkunci.

Untuk mencapai hal ini, Keystore "mengenkripsi super" semua kunci UNLOCKED_DEVICE_REQUIRED sebelum menyimpannya dalam database, dan jika memungkinkan, Keystore akan melindungi kunci superenkripsi (kunci super) saat perangkat dikunci sedemikian rupa sehingga kunci tersebut hanya dapat dipulihkan dengan membuka kunci perangkat yang berhasil. (Istilah "superenkripsi" digunakan karena lapisan enkripsi ini diterapkan selain lapisan enkripsi yang telah diterapkan Keymaster ke semua kunci.)

Setiap pengguna (termasuk profil) memiliki dua kunci super yang terkait dengan UNLOCKED_DEVICE_REQUIRED:

• Kunci super simetris UnlockedDeviceRequired. Ini adalah kunci AES‑256‑GCM. API ini mengenkripsi kunci UNLOCKED_DEVICE_REQUIRED yang diimpor atau dibuat saat perangkat tidak terkunci untuk pengguna.
• Kunci super asimetris UnlockedDeviceRequired. Ini adalah pasangan kunci ECDH P‑521. Library ini mengenkripsi kunci UNLOCKED_DEVICE_REQUIRED yang diimpor atau dibuat saat perangkat dikunci untuk pengguna. Kunci yang dienkripsi dengan kunci asimetris ini dienkripsi ulang dengan kunci simetris saat pertama kali digunakan (yang hanya dapat terjadi saat perangkat tidak terkunci).

Keystore membuat kunci super ini pada waktu pembuatan pengguna dan menyimpannya di database-nya, yang dienkripsi oleh sandi sintetis pengguna. Hal ini memungkinkannya dipulihkan menggunakan PIN, pola, atau sandi yang setara.

Keystore juga meng-cache kunci super ini dalam memori, sehingga dapat beroperasi pada kunci UNLOCKED_DEVICE_REQUIRED. Namun, sistem ini mencoba meng-cache bagian rahasia kunci ini hanya saat perangkat tidak terkunci untuk pengguna. Saat perangkat dikunci untuk pengguna, Keystore akan mereset salinan bagian rahasia kunci super ini yang di-cache menjadi nol, jika memungkinkan. Secara khusus, saat perangkat dikunci untuk pengguna, Keystore akan memilih dan menerapkan salah satu dari tiga tingkat perlindungan untuk kunci super UnlockedDeviceRequired pengguna:

• Jika pengguna hanya mengaktifkan PIN, pola, atau sandi, Keystore akan mereset bagian rahasia kunci super yang di-cache. Hal ini membuat kunci super hanya dapat dipulihkan melalui salinan terenkripsi dalam database yang dapat didekripsi hanya dengan PIN, pola, atau sandi yang setara.
• Jika pengguna hanya memiliki biometrik ("kuat") kelas 3 dan PIN, pola, atau sandi diaktifkan, Keystore akan mengatur agar kunci super dapat dipulihkan oleh salah satu biometrik kelas 3 terdaftar pengguna (biasanya sidik jari), sebagai alternatif untuk PIN, pola, atau sandi yang setara. Untuk melakukannya, Keymaster akan membuat kunci AES‑256‑GCM baru, mengenkripsi bagian rahasia kunci super dengan kunci tersebut, mengimpor kunci AES‑256‑GCM ke Keymaster sebagai kunci terikat biometrik yang memerlukan autentikasi biometrik yang berhasil dalam 15 detik terakhir, dan mereset salinan teks biasa dari semua kunci ini ke nol.
• Jika pengguna memiliki biometrik class 1 ("kemudahan"), biometrik class 2 ("lemah"), atau mengaktifkan agen kepercayaan buka kunci aktif, Keystore akan menyimpan kunci super dalam cache dalam teks biasa. Dalam hal ini, keamanan kriptografis untuk kunci UNLOCKED_DEVICE_REQUIRED tidak disediakan. Pengguna dapat menghindari penggantian yang kurang aman ini dengan tidak mengaktifkan metode buka kunci ini. Metode buka kunci yang paling umum yang termasuk dalam kategori ini adalah buka kunci dengan wajah di banyak perangkat, dan buka kunci dengan smartwatch yang disambungkan.

Saat perangkat dibuka kuncinya untuk pengguna, Keystore akan memulihkan kunci super UnlockedDeviceRequired pengguna jika memungkinkan. Untuk membuka kunci yang setara dengan PIN, pola, atau sandi, kunci ini mendekripsi salinan kunci yang disimpan di database. Jika tidak, sistem akan memeriksa apakah telah menyimpan salinan kunci ini yang dienkripsi dengan kunci terikat biometrik, dan jika ya, mencoba mendekripsinya. Hal ini hanya berhasil jika pengguna telah berhasil diautentikasi dengan biometrik class 3 dalam 15 detik terakhir, yang diterapkan oleh Keymaster (bukan Keystore).

Binding klien

Binding klien, yaitu pengaitan kunci dengan aplikasi klien tertentu, dilakukan melalui client ID opsional dan beberapa data klien opsional (masing-masing TAG::APPLICATION_ID dan TAG::APPLICATION_DATA). Keystore memperlakukan nilai ini sebagai blob buram, hanya memastikan bahwa blob yang sama yang ditampilkan selama pembuatan/impor kunci ditampilkan untuk setiap penggunaan dan identik byte demi byte. Data binding klien tidak ditampilkan oleh Keymaster. Pemanggil harus mengetahuinya untuk menggunakan kunci.

Fitur ini tidak ditampilkan ke aplikasi.

Akhir masa berlaku

Keystore mendukung pembatasan penggunaan kunci berdasarkan tanggal. Awal validitas kunci dan masa berlaku kunci dapat dikaitkan dengan kunci dan Keymaster menolak untuk melakukan operasi kunci jika tanggal/waktu saat ini berada di luar rentang yang valid. Rentang validitas kunci ditentukan dengan tag TAG::ACTIVE_DATETIME, TAG::ORIGINATION_EXPIRE_DATETIME, dan TAG::USAGE_EXPIRE_DATETIME. Perbedaan antara "origination" dan "usage" didasarkan pada apakah kunci digunakan untuk "originate" ciphertext/tanda tangan/dll. baru, atau untuk "menggunakan" ciphertext/tanda tangan/dll. yang ada. Perhatikan bahwa perbedaan ini tidak ditampilkan ke aplikasi.

Tag TAG::ACTIVE_DATETIME, TAG::ORIGINATION_EXPIRE_DATETIME, dan TAG::USAGE_EXPIRE_DATETIME bersifat opsional. Jika tag tidak ada, diasumsikan bahwa kunci yang dipermasalahkan selalu dapat digunakan untuk mendekripsi/memverifikasi pesan.

Karena waktu jam dinding disediakan oleh dunia yang tidak aman, kemungkinan tag terkait masa berlaku tidak ada dalam daftar yang diterapkan hardware. Penerapan masa berlaku hardware akan mengharuskan dunia yang aman mendapatkan waktu dan data tepercaya, misalnya, melalui protokol respons tantangan dengan server waktu jarak jauh tepercaya.

Binding root of trust

Keystore mewajibkan kunci untuk terikat dengan root of trust, yang merupakan bitstring yang disediakan ke hardware aman Keymaster selama startup, sebaiknya oleh bootloader. Bitstring ini terikat secara kriptografis ke setiap kunci yang dikelola oleh Keymaster.

Root of trust terdiri dari kunci publik yang digunakan untuk memverifikasi tanda tangan pada image booting dan status kunci perangkat. Jika kunci publik diubah untuk memungkinkan image sistem yang berbeda digunakan atau jika status kunci diubah, maka tidak ada kunci yang dilindungi Keymaster yang dibuat oleh sistem sebelumnya yang dapat digunakan, kecuali jika root of trust sebelumnya dipulihkan dan sistem yang ditandatangani oleh kunci tersebut di-booting. Tujuannya adalah untuk meningkatkan nilai kontrol akses kunci yang diterapkan software dengan membuat sistem operasi yang diinstal penyerang tidak dapat menggunakan kunci Keymaster.

Kunci mandiri

Beberapa hardware aman Keymaster dapat memilih untuk menyimpan materi kunci secara internal dan menampilkan handle, bukan materi kunci terenkripsi. Atau mungkin ada kasus lain saat kunci tidak dapat digunakan hingga beberapa komponen sistem dunia non-aman atau aman lainnya tersedia. HAL Keymaster memungkinkan pemanggil meminta kunci menjadi "mandiri", melalui tag TAG::STANDALONE, yang berarti tidak ada resource selain blob dan sistem Keymaster yang berjalan yang diperlukan. Tag yang terkait dengan kunci dapat diperiksa untuk melihat apakah kunci bersifat mandiri. Saat ini, hanya dua nilai yang ditentukan:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Fitur ini tidak ditampilkan ke aplikasi.

Kecepatan

Saat dibuat, kecepatan penggunaan maksimum dapat ditentukan dengan TAG::MIN_SECONDS_BETWEEN_OPS. Implementasi TrustZone menolak untuk melakukan operasi kriptografi dengan kunci tersebut jika operasi dilakukan kurang dari TAG::MIN_SECONDS_BETWEEN_OPS detik sebelumnya.

Pendekatan sederhana untuk menerapkan batas kecepatan adalah tabel ID kunci dan stempel waktu penggunaan terakhir. Tabel ini berukuran terbatas, tetapi menampung minimal 16 entri. Jika tabel penuh dan tidak ada entri yang dapat diperbarui atau dihapus, implementasi hardware yang aman akan "gagal aman", lebih memilih untuk menolak semua operasi kunci yang dibatasi kecepatan hingga salah satu entri berakhir masa berlakunya. Semua entri dapat berakhir masa berlakunya setelah dimulai ulang.

Kunci juga dapat dibatasi hingga n penggunaan per booting dengan TAG::MAX_USES_PER_BOOT. Hal ini juga memerlukan tabel pelacakan, yang mengakomodasi minimal empat kunci dan juga aman. Perhatikan bahwa aplikasi tidak dapat membuat kunci terbatas per booting. Fitur ini tidak ditampilkan melalui Keystore dan dicadangkan untuk operasi sistem.

Fitur ini tidak ditampilkan ke aplikasi.

Pembuatan ulang seed generator angka acak

Karena hardware aman menghasilkan angka acak untuk materi kunci dan vektor inisialisasi (IV), dan karena generator angka acak hardware mungkin tidak selalu sepenuhnya dapat dipercaya, Keymaster HAL menyediakan antarmuka untuk memungkinkan klien memberikan entropi tambahan, yang dicampur ke dalam angka acak yang dihasilkan.

Gunakan generator angka acak hardware sebagai sumber seed utama. Data seed yang disediakan melalui API eksternal tidak boleh menjadi satu-satunya sumber keacakan yang digunakan untuk pembuatan angka. Selain itu, operasi pencampuran yang digunakan harus memastikan bahwa output acak tidak dapat diprediksi jika salah satu sumber benih tidak dapat diprediksi.

Fitur ini tidak ditampilkan ke aplikasi, tetapi digunakan oleh framework, yang secara rutin menyediakan entropi tambahan, yang diambil dari instance Java SecureRandom ke hardware yang aman.