Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Halaman ini diterjemahkan oleh Cloud Translation API.

Fitur

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

Primitif kriptografi

Keystore menyediakan kategori operasi berikut:

Generasi kunci
Impor dan ekspor kunci asimetris (tanpa pembungkus kunci)
Impor kunci simetris mentah (tanpa pembungkus kunci)
Enkripsi dan dekripsi asimetris dengan mode padding yang sesuai
Penandatanganan dan verifikasi asimetris dengan mode pencernaan dan padding yang sesuai
Enkripsi dan dekripsi simetris dalam mode yang sesuai, termasuk mode AEAD
Pembuatan dan verifikasi kode otentikasi pesan simetris

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

Selain daftar di atas, ada satu layanan lagi yang disediakan oleh implementasi Keymaster, namun tidak diekspos sebagai API: Pembuatan angka acak. Ini digunakan secara internal untuk pembuatan kunci, Vektor Inisialisasi (IV), padding acak, dan elemen protokol aman lainnya 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 intisari untuk penandatanganan RSA:
  - SHA-256
- Mode padding untuk enkripsi/dekripsi RSA:
  - Tanpa bantalan
  - 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, masing-masing menggunakan kurva NIST P-224, P-256, P-384, dan P-521
- Mode intisari untuk ECDSA:
  - Tidak ada intisari (tidak digunakan lagi, akan dihapus di masa mendatang)
  - SHA-256
AES
- Kunci 128 dan 256-bit didukung
- CBC , RKT, 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 mode CBC atau ECB gagal jika inputnya bukan kelipatan ukuran blok.
HMAC SHA-256 , dengan ukuran kunci apa pun hingga setidaknya 32 byte.

SHA1 dan anggota keluarga SHA2 lainnya (SHA-224, SHA384, dan SHA512) sangat disarankan untuk implementasi Keymaster. Keystore menyediakannya dalam perangkat lunak jika implementasi perangkat keras Keymaster tidak menyediakannya.

Beberapa primitif juga direkomendasikan untuk interoperabilitas dengan sistem lain:

Ukuran kunci yang lebih kecil untuk RSA
Eksponen publik sewenang-wenang untuk RSA

Kontrol akses kunci

Kunci berbasis perangkat keras yang tidak dapat diekstraksi dari perangkat tidak memberikan banyak keamanan jika penyerang dapat menggunakannya sesuka hati (meskipun kunci tersebut lebih aman daripada kunci yang dapat dieksfiltrasi). Oleh karena itu, penting bagi Keystore untuk menerapkan kontrol akses.

Kontrol akses didefinisikan sebagai "daftar otorisasi" pasangan tag/nilai. Tag otorisasi adalah bilangan bulat 32-bit dan nilainya bervariasi jenisnya. Beberapa tag mungkin diulang untuk menentukan beberapa nilai. Apakah suatu tag dapat diulang ditentukan dalam dokumentasi untuk tag tersebut . Ketika kunci dibuat, pemanggil menentukan daftar otorisasi. Implementasi Keymaster yang mendasari Keystore memodifikasi daftar untuk menentukan beberapa informasi tambahan, seperti apakah kunci memiliki perlindungan rollback, dan mengembalikan daftar otorisasi "final", yang dikodekan ke dalam blob kunci yang dikembalikan. Segala upaya untuk menggunakan kunci untuk operasi kriptografi apa pun 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 diperbaiki secara permanen (meskipun dapat diperluas). Nama diawali dengan KM_TAG . Empat bit teratas dari ID tag digunakan untuk menunjukkan jenisnya.

Keymaster 3 mengubah awalan KM_TAG menjadi Tag:: .

Jenis yang mungkin meliputi:

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

ENUM_REP : Sama seperti ENUM , hanya saja tag tersebut dapat diulang dalam daftar otorisasi. Pengulangan menunjukkan beberapa nilai resmi. Misalnya, kunci enkripsi kemungkinan memiliki KeyPurpose::ENCRYPT dan KeyPurpose::DECRYPT .

UINT : bilangan bulat 32-bit yang tidak ditandatangani. Contoh: TAG::KEY_SIZE

UINT_REP : Sama seperti UINT , hanya saja tag tersebut dapat diulang dalam daftar otorisasi. Pengulangan menunjukkan beberapa nilai resmi.

ULONG : bilangan bulat 64-bit yang tidak ditandatangani. Contoh: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : Sama seperti ULONG , hanya saja tag tersebut dapat diulang dalam daftar otorisasi. Pengulangan menunjukkan beberapa nilai resmi.

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

BOOL : Benar atau salah. Tag bertipe BOOL dianggap "salah" jika tag tersebut tidak ada dan "benar" jika ada. Contoh: TAG::ROLLBACK_RESISTANT

BIGNUM : Bilangan bulat dengan panjang sewenang-wenang, dinyatakan sebagai larik byte dalam urutan big-endian. Contoh: TAG::RSA_PUBLIC_EXPONENT

BYTES : Urutan byte. Contoh: TAG::ROOT_OF_TRUST

Penegakan perangkat keras vs. perangkat lunak

Tidak semua implementasi perangkat keras yang aman memiliki fitur yang sama. Untuk mendukung berbagai pendekatan, Keymaster membedakan antara penegakan kontrol akses dunia yang aman dan tidak aman, atau penegakan perangkat keras dan perangkat lunak.

Semua implementasi:

Terapkan pencocokan tepat (bukan penegakan) semua otorisasi. Daftar otorisasi di blob kunci sama persis dengan otorisasi yang dikembalikan selama pembuatan kunci, termasuk pemesanan. Setiap ketidakcocokan menyebabkan diagnostik kesalahan.
Deklarasikan otorisasi yang nilai semantiknya diterapkan.

Mekanisme API untuk mendeklarasikan otorisasi yang didukung perangkat keras ada dalam struktur keymaster_key_characteristics_t . Ini membagi daftar otorisasi menjadi dua sub-daftar, hw_enforced dan sw_enforced . Perangkat keras yang aman bertanggung jawab untuk menempatkan nilai yang sesuai pada masing-masing perangkat, berdasarkan apa yang dapat diterapkannya.

Selain itu, Keystore menerapkan penegakan semua otorisasi berbasis perangkat lunak, baik yang diterapkan oleh perangkat keras yang aman atau tidak.

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

Jika perangkat kemudian ditingkatkan dengan perangkat keras aman yang mendukung masa berlaku habis, maka permintaan untuk karakteristik kunci akan menemukan TAG::ORIGINATION_EXPIRE_DATETIME dalam daftar hw_enforced , dan upaya untuk menggunakan kunci setelah habis masa berlakunya akan gagal meskipun keystore entah bagaimana ditumbangkan atau dilewati .

Untuk informasi selengkapnya tentang menentukan apakah kunci didukung perangkat keras, lihat Pengesahan kunci .

Otorisasi pembuatan pesan kriptografi

Tag berikut digunakan untuk menentukan karakteristik kriptografi 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, artinya beberapa nilai dapat dikaitkan dengan satu kunci, dan nilai yang akan digunakan ditentukan pada waktu operasi.

Tujuan

Kunci memiliki serangkaian tujuan terkait, dinyatakan sebagai satu atau lebih entri otorisasi dengan tag TAG::PURPOSE , yang menentukan cara penggunaannya. Tujuannya adalah:

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

Kunci apa pun dapat memiliki subset apa pun dari tujuan ini. Perhatikan bahwa beberapa kombinasi 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.

Impor dan ekspor

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

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

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

Otentikasi pengguna

Implementasi Secure Keymaster tidak mengimplementasikan autentikasi pengguna, namun bergantung pada aplikasi tepercaya lainnya yang menerapkannya. Untuk antarmuka yang diterapkan aplikasi ini, lihat halaman Gatekeeper .

Persyaratan otentikasi pengguna ditentukan melalui dua set tag. Set pertama menunjukkan pengguna mana yang dapat menggunakan kunci tersebut:

TAG::ALL_USERS menunjukkan 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 berwenang. Perhatikan bahwa ini adalah ID pengguna Android (untuk multi-pengguna), bukan UID aplikasi, dan ini hanya diterapkan oleh perangkat lunak 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 diulangi, kunci dapat digunakan jika salah satu nilai diberikan dalam token autentikasi yang aman.

Set kedua menunjukkan apakah dan kapan pengguna perlu diautentikasi. Jika tidak satu pun dari tag ini ada, namun TAG::USER_SECURE_ID ada, autentikasi diperlukan untuk setiap penggunaan kunci.

NO_AUTHENTICATION_REQUIRED menunjukkan tidak diperlukan autentikasi pengguna, meskipun kunci tetap hanya dapat digunakan oleh aplikasi yang berjalan sebagai pengguna yang ditentukan oleh TAG::USER_ID .
TAG::AUTH_TIMEOUT adalah nilai numerik yang menentukan, dalam hitungan detik, seberapa baru autentikasi pengguna diperlukan untuk mengotorisasi penggunaan kunci. Ini hanya berlaku untuk operasi kunci pribadi/rahasia. Operasi kunci publik tidak memerlukan otentikasi. Batas waktu tidak melewati reboot; setelah reboot, semua kunci "tidak pernah diautentikasi". Batas waktu dapat disetel ke nilai yang besar untuk menunjukkan bahwa autentikasi diperlukan satu kali setiap boot (2^32 detik sama dengan ~136 tahun; mungkin perangkat Android di-boot ulang lebih sering dari itu).

Pengikatan klien

Pengikatan klien, pengaitan kunci dengan aplikasi klien tertentu, dilakukan melalui ID klien opsional dan beberapa data klien opsional ( TAG::APPLICATION_ID dan TAG::APPLICATION_DATA , masing-masing). Keystore memperlakukan nilai-nilai ini sebagai blob buram, hanya memastikan bahwa blob yang sama yang disajikan selama pembuatan/impor kunci disajikan untuk setiap penggunaan dan identik setiap byte. Data pengikatan klien tidak dikembalikan oleh Keymaster. Penelepon harus mengetahuinya agar dapat menggunakan kunci tersebut.

Fitur ini tidak diekspos ke aplikasi.

Kedaluwarsa

Keystore mendukung pembatasan penggunaan kunci berdasarkan tanggal. Awal validitas kunci dan kedaluwarsa kunci dapat dikaitkan dengan kunci dan Keymaster menolak 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 "asal" dan "penggunaan" didasarkan pada apakah kunci tersebut digunakan untuk "mengasalkan" teks sandi/tanda tangan/dll yang baru, atau untuk "menggunakan" teks sandi/tanda tangan/dll yang sudah ada. Perhatikan bahwa perbedaan ini tidak berlaku untuk aplikasi.

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

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

Akar pengikat kepercayaan

Keystore memerlukan kunci untuk diikat ke root kepercayaan, yang merupakan bitstring yang diberikan ke perangkat keras aman Keymaster selama startup, sebaiknya oleh bootloader. Bitstring ini terikat secara kriptografis ke setiap kunci yang dikelola oleh Keymaster.

Akar kepercayaan terdiri dari kunci publik yang digunakan untuk memverifikasi tanda tangan pada image boot dan status kunci perangkat. Jika kunci publik diubah untuk memungkinkan penggunaan citra sistem yang berbeda atau jika status kunci diubah, maka tidak ada kunci yang dilindungi Keymaster yang dibuat oleh sistem sebelumnya dapat digunakan, kecuali akar kepercayaan sebelumnya dipulihkan dan sistem yang ditandatangani oleh kunci itu di-boot. Tujuannya adalah untuk meningkatkan nilai kontrol akses kunci yang didukung perangkat lunak dengan membuat sistem operasi yang diinstal penyerang tidak dapat menggunakan kunci Keymaster.

Kunci mandiri

Beberapa perangkat keras aman Keymaster mungkin memilih untuk menyimpan materi kunci secara internal dan mengembalikan pegangan daripada materi kunci terenkripsi. Atau mungkin ada kasus lain di mana kunci tidak dapat digunakan sampai komponen sistem dunia lain yang tidak aman atau terlindungi tersedia. Keymaster HAL memungkinkan pemanggil untuk meminta agar kunci menjadi "mandiri", melalui tag TAG::STANDALONE , artinya tidak diperlukan sumber daya selain blob dan sistem Keymaster yang sedang berjalan. Tag yang terkait dengan kunci dapat diperiksa untuk melihat apakah kunci tersebut berdiri sendiri. Saat ini, hanya dua nilai yang didefinisikan:

KeyBlobUsageRequirements::STANDALONE
KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Fitur ini tidak diekspos ke aplikasi.

Kecepatan

Saat dibuat, kecepatan penggunaan maksimum dapat ditentukan dengan TAG::MIN_SECONDS_BETWEEN_OPS . Implementasi TrustZone menolak 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 kemungkinan besar berukuran terbatas, tetapi dapat menampung setidaknya 16 entri. Jika tabel sudah penuh dan tidak ada entri yang dapat diperbarui atau dibuang, implementasi perangkat keras yang aman "gagal aman", lebih memilih untuk menolak semua operasi kunci dengan kecepatan terbatas hingga salah satu entri kedaluwarsa. Semua entri dapat kedaluwarsa saat reboot.

Kunci juga dapat dibatasi hingga n penggunaan per boot dengan TAG::MAX_USES_PER_BOOT . Ini juga memerlukan tabel pelacakan, yang menampung setidaknya empat kunci dan juga gagal aman. Perhatikan bahwa aplikasi tidak akan dapat membuat kunci terbatas per boot. Fitur ini tidak diekspos melalui Keystore dan dicadangkan untuk operasi sistem.

Fitur ini tidak diekspos ke aplikasi.

Penyemaian ulang generator nomor acak

Karena perangkat keras yang aman menghasilkan angka acak untuk material kunci dan Vektor Inisialisasi (IV), dan karena generator angka acak perangkat keras mungkin tidak selalu dapat dipercaya sepenuhnya, Keymaster HAL menyediakan antarmuka yang memungkinkan klien memberikan entropi tambahan yang akan dicampur ke dalam acak angka yang dihasilkan.

Gunakan generator nomor acak perangkat keras sebagai sumber benih utama. Data awal yang disediakan melalui API eksternal tidak dapat menjadi satu-satunya sumber keacakan yang digunakan untuk menghasilkan angka. Selanjutnya, operasi pencampuran yang digunakan perlu memastikan bahwa keluaran acak tidak dapat diprediksi jika salah satu sumber benih tidak dapat diprediksi.

Fitur ini tidak diekspos ke aplikasi tetapi digunakan oleh kerangka kerja, yang secara rutin menyediakan entropi tambahan, yang diambil dari instance Java SecureRandom, ke perangkat keras yang aman.