Pengesahan Kunci dan ID

Keystore menyediakan tempat yang lebih aman untuk membuat, menyimpan, dan menggunakan kunci kriptografik dengan cara yang terkontrol. Saat penyimpanan kunci yang didukung perangkat keras tersedia dan digunakan, materi kunci lebih aman terhadap ekstraksi dari perangkat, dan Keymaster memberlakukan pembatasan yang sulit ditumbangkan.

Namun, ini hanya benar jika kunci keystore diketahui berada di penyimpanan yang didukung perangkat keras. Di Keymaster 1, tidak ada cara bagi aplikasi atau server jarak jauh untuk memverifikasi secara andal jika ini masalahnya. Daemon keystore memuat HAL keymaster yang tersedia dan memercayai apa pun yang dikatakan HAL sehubungan dengan dukungan perangkat keras untuk kunci.

Untuk mengatasinya, Keymaster memperkenalkanpengesahan kunci di Android 7.0 (Keymaster 2) dan pengesahan ID di Android 8.0 (Keymaster 3).

Pengesahan kunci bertujuan untuk menyediakan cara untuk menentukan dengan kuat apakah pasangan kunci asimetris didukung perangkat keras, properti kunci apa, dan batasan apa yang diterapkan pada penggunaannya.

Pengesahan ID memungkinkan perangkat memberikan bukti pengenal perangkat kerasnya, seperti nomor seri atau IMEI.

Pengesahan kunci

Untuk mendukung pengesahan kunci, Android 7.1 memperkenalkan serangkaian tag, jenis, dan metode ke HAL.

Tag

  • Tag::ATTESTATION_CHALLENGE
  • Tag::INCLUDE_UNIQUE_ID
  • Tag::RESET_SINCE_ID_ROTATION

Jenis

Keymaster 2 dan di bawah

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

Metode AttestKey

master kunci 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 dan di bawah

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);
  • dev adalah struktur perangkat keymaster.
  • keyToAttest adalah gumpalan kunci yang dikembalikan dari generateKey yang pengesahannya akan dibuat.
  • attestParams adalah daftar parameter yang diperlukan untuk pengesahan. Ini termasuk Tag::ATTESTATION_CHALLENGE dan mungkin Tag::RESET_SINCE_ID_ROTATION , serta Tag::APPLICATION_ID dan Tag::APPLICATION_DATA . Dua yang terakhir diperlukan untuk mendekripsi gumpalan kunci jika ditentukan selama pembuatan kunci.
  • certChain adalah parameter keluaran, yang mengembalikan larik sertifikat. Entri 0 adalah sertifikat pengesahan, artinya ia mengesahkan kunci dari keyToAttest dan berisi ekstensi pengesahan.

Metode attestKey dianggap sebagai operasi kunci publik pada kunci yang dibuktikan, karena dapat dipanggil kapan saja dan tidak perlu memenuhi batasan otorisasi. Misalnya, jika kunci yang disahkan memerlukan otentikasi pengguna untuk digunakan, pengesahan dapat dibuat tanpa otentikasi pengguna.

Sertifikat pengesahan

Sertifikat pengesahan adalah sertifikat X.509 standar, dengan ekstensi pengesahan opsional yang berisi deskripsi kunci yang disahkan. Sertifikat ditandatangani dengan kunci pengesahan yang disediakan pabrik yang menggunakan algoritme yang sama dengan kunci yang diuji (RSA untuk RSA, EC untuk EC).

Sertifikat pengesahan berisi bidang dalam tabel di bawah ini dan tidak boleh berisi bidang tambahan apa pun. Beberapa bidang menentukan nilai bidang tetap. Tes CTS memvalidasi bahwa konten sertifikat persis seperti yang ditentukan.

URUTAN Sertifikat

Nama bidang (lihat RFC 5280 ) Nilai
tbsSertifikat SEQUENCE Sertifikat TBSC
algoritma tanda tangan AlgorithmIdentifier dari algoritma yang digunakan untuk menandatangani kunci:
ECDSA untuk kunci EC, RSA untuk kunci RSA.
nilai tanda tangan BIT STRING, tanda tangan dihitung pada ASN.1 DER-encoded tbsCertificate.

SEQUENCE Sertifikat TBSC

Nama bidang (lihat RFC 5280 ) Nilai
version INTEGER 2 (berarti sertifikat v3)
serialNumber INTEGER 1 (nilai tetap: sama pada semua sertifikat)
signature AlgorithmIdentifier dari algoritma yang digunakan untuk menandatangani kunci: ECDSA untuk kunci EC, RSA untuk kunci RSA.
issuer Sama seperti bidang subjek kunci pengesahan batch.
validity URUTAN dua tanggal, berisi nilai Tag::ACTIVE_DATETIME dan Tag::USAGE_EXPIRE_DATETIME . Nilai tersebut dalam milidetik sejak 1 Januari 1970. Lihat RFC 5280 untuk representasi tanggal yang benar dalam sertifikat.
Jika Tag::ACTIVE_DATETIME tidak ada, gunakan nilai Tag::CREATION_DATETIME . Jika Tag::USAGE_EXPIRE_DATETIME tidak ada, gunakan tanggal kedaluwarsa sertifikat kunci pengesahan batch.
subject CN = "Kunci Android Keystore" (nilai tetap: sama pada semua sertifikat)
subjectPublicKeyInfo SubjectPublicKeyInfo berisi kunci publik yang dibuktikan.
extensions/Key Usage digitalSignature: atur jika kunci memiliki tujuan KeyPurpose::SIGN atau KeyPurpose::VERIFY . Semua bit lainnya tidak disetel.
extensions/CRL Distribution Points Nilai TBD
extensions/"attestation" OIDnya adalah 1.3.6.1.4.1.11129.2.1.17; konten didefinisikan di bagian Ekstensi Pengesahan di bawah ini. Seperti semua ekstensi sertifikat X.509, konten direpresentasikan sebagai OCTET_STRING yang berisi pengkodean DER dari SEQUENCE pengesahan.

Ekstensi pengesahan

Ekstensi attestation berisi deskripsi lengkap tentang otorisasi keymaster yang terkait dengan kunci, dalam struktur yang secara langsung sesuai dengan daftar otorisasi seperti yang digunakan di Android dan keymaster HAL. Setiap tag dalam daftar otorisasi diwakili oleh entri ASN.1 SEQUENCE , yang secara eksplisit diberi tag dengan nomor tag keymaster, tetapi dengan jenis deskriptor (empat bit orde tinggi) tertutup.

Misalnya, di Keymaster 3, Tag::PURPOSE didefinisikan di types.hal sebagai ENUM_REP | 1 . Untuk ekstensi pengesahan, nilai ENUM_REP dihapus, meninggalkan tag 1 . (Untuk Keymaster 2 dan di bawahnya, KM_TAG_PURPOSE didefinisikan di keymaster_defs.h.)

Nilai diterjemahkan secara langsung ke tipe ASN.1, per tabel ini:

Jenis master kunci jenis ASN.1
ENUM BILANGAN BULAT
ENUM_REP SET dari INTEGER
UINT BILANGAN BULAT
UINT_REP SET dari INTEGER
ULONG BILANGAN BULAT
ULONG_REP SET dari INTEGER
DATE INTEGER (milidetik sejak 1 Januari 1970 00:00:00 GMT)
BOOL NULL (dalam keymaster, tag present berarti benar, absen berarti salah.
Semantik yang sama berlaku untuk penyandian ASN.1)
BIGNUM Saat ini tidak digunakan, jadi tidak ada pemetaan yang ditentukan
BYTES OKTET_STRING

Skema

Konten ekstensi pengesahan dijelaskan oleh skema ASN.1 berikut.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  applicationId               [601] EXPLICIT OCTET_STRING OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

Bidang KeyDescription

Bidang keymasterVersion dan attestationChallenge diidentifikasi secara posisi, bukan berdasarkan tag, sehingga tag dalam formulir yang disandikan hanya menentukan jenis bidang. Bidang yang tersisa secara implisit diberi tag seperti yang ditentukan dalam skema.

Nama bidang Jenis Nilai
attestationVersion BILANGAN BULAT Versi skema pengesahan: 1, 2, atau 3.
attestationSecurity Tingkat keamanan Tingkat keamanan pengesahan ini. Dimungkinkan untuk mendapatkan pengesahan perangkat lunak dari kunci yang didukung perangkat keras. Pengesahan seperti itu tidak dapat dipercaya jika sistem Android disusupi.
keymasterVersion BILANGAN BULAT Versi perangkat keymaster: 0, 1, 2, 3, atau 4.
keymasterSecurity Tingkat keamanan Tingkat keamanan implementasi keymaster.
attestationChallenge OKTET_STRING Nilai Tag::ATTESTATION_CHALLENGE , ditentukan untuk permintaan pengesahan.
uniqueId OKTET_STRING ID unik opsional, ada jika kunci memiliki Tag::INCLUDE_UNIQUE_ID
softwareEnforced Daftar Otorisasi Otorisasi keymaster opsional yang tidak diberlakukan oleh TEE, jika ada.
teeEnforced Daftar Otorisasi Opsional, otorisasi Keymaster yang diberlakukan oleh TEE, jika ada.

Bidang Daftar Otorisasi

Bidang AuthorizationList semuanya opsional dan diidentifikasi oleh nilai tag keymaster, dengan jenis bit yang disamarkan. Pemberian tag eksplisit digunakan sehingga bidang juga berisi tag yang menunjukkan jenis ASN.1-nya, untuk penguraian yang lebih mudah.

Untuk detail tentang nilai masing-masing bidang, lihat types.hal untuk Keymaster 3 dan keymaster_defs.h untuk Keymaster 2 dan di bawahnya. Nama tag keymaster diubah menjadi nama bidang dengan menghilangkan awalan KM_TAG dan mengubah sisanya menjadi camel case, sehingga Tag::KEY_SIZE menjadi keySize .

Bidang RootOfTrust

Bidang RootOfTrust diidentifikasi secara posisi.

Nama bidang Jenis Nilai
verifiedBootKey OKTET_STRING Hash aman dari kunci yang digunakan untuk memverifikasi citra sistem. SHA-256 direkomendasikan.
deviceLocked BOOLEAN Benar jika bootloader terkunci, yang berarti hanya gambar yang ditandatangani yang dapat di-flash, dan pemeriksaan boot yang diverifikasi telah selesai.
verifiedBootState StatusBoot Terverifikasi Status boot terverifikasi.
verifiedBootHash OKTET_STRING Ringkasan semua data yang dilindungi oleh Boot Terverifikasi. Untuk perangkat yang menggunakan implementasi Boot Terverifikasi Android dari Boot Terverifikasi, nilai ini berisi intisari dari struct VBMeta , atau struktur metadata Boot Terverifikasi. Untuk mempelajari lebih lanjut tentang cara menghitung nilai ini, lihat Intisari VBMeta

Nilai VerifiedBootState

Nilai-nilai verifiedBootState memiliki arti sebagai berikut:

Nilai Berarti
Verified Menunjukkan rantai kepercayaan penuh yang terbentang dari bootloader ke partisi terverifikasi, termasuk bootloader, partisi boot, dan semua partisi terverifikasi.
Dalam keadaan ini, verifiedBootKey adalah hash dari sertifikat yang disematkan, artinya sertifikat yang tidak dapat diubah dibakar ke dalam ROM.
SelfSigned Menunjukkan partisi boot telah diverifikasi menggunakan sertifikat yang disematkan, dan tanda tangan valid. Bootloader menampilkan peringatan dan sidik jari kunci publik sebelum mengizinkan proses boot untuk melanjutkan.
Dalam status ini, verifiedBootKey adalah hash dari sertifikat yang ditandatangani sendiri.
Unverified Menunjukkan perangkat dapat dimodifikasi secara bebas. Integritas perangkat diserahkan kepada pengguna untuk memverifikasi out-of-band. Bootloader menampilkan peringatan kepada pengguna sebelum mengizinkan proses boot untuk melanjutkan.
Dalam keadaan ini, verifiedBootKey kosong.
Failed Menunjukkan perangkat telah gagal verifikasi. Tidak ada sertifikat pengesahan yang benar-benar berisi nilai ini, karena dalam keadaan ini bootloader berhenti. Ini termasuk di sini untuk kelengkapan.

Nilai Tingkat Keamanan

Nilai securityLevel memiliki arti sebagai berikut:

Nilai Berarti
Software Kode yang membuat atau mengelola elemen yang relevan (pengesahan atau kunci) diimplementasikan dalam sistem Android dan dapat diubah jika sistem tersebut disusupi.
TrustedEnvironment Kode yang membuat atau mengelola elemen yang relevan (pengesahan atau kunci) diimplementasikan dalam Trusted Execution Environment (TEE). Itu bisa diubah jika TEE dikompromikan, tetapi TEE sangat tahan terhadap kompromi jarak jauh dan cukup tahan terhadap kompromi dengan serangan perangkat keras langsung.
StrongBox Kode yang membuat atau mengelola elemen yang relevan (pengesahan atau kunci) diimplementasikan dalam modul keamanan perangkat keras khusus. Itu bisa diubah jika modul keamanan perangkat keras dikompromikan, tetapi sangat tahan terhadap kompromi jarak jauh dan sangat tahan terhadap kompromi oleh serangan perangkat keras langsung.

Identitas unik

ID Unik adalah nilai 128-bit yang mengidentifikasi perangkat, tetapi hanya untuk jangka waktu terbatas. Nilai dihitung dengan:

HMAC_SHA256(T || C || R, HBK)

Di mana:

  • T adalah "nilai penghitung sementara", dihitung dengan membagi nilai Tag::CREATION_DATETIME dengan 2592000000, menghilangkan sisa apa pun. T berubah setiap 30 hari (2592000000 = 30 * 24 * 60 * 60 * 1000).
  • C adalah nilai dari Tag::APPLICATION_ID
  • R adalah 1 jika Tag::RESET_SINCE_ID_ROTATION ada dalam parameter attest_params ke panggilan attest_key, atau 0 jika tag tidak ada.
  • HBK adalah rahasia terikat perangkat keras unik yang diketahui oleh Lingkungan Eksekusi Tepercaya dan tidak pernah diungkapkan olehnya. Rahasia berisi setidaknya 128 bit entropi dan unik untuk perangkat individu (keunikan probabilistik dapat diterima mengingat 128 bit entropi). HBK harus diturunkan dari material kunci yang menyatu melalui HMAC atau AES_CMAC.

Potong output HMAC_SHA256 menjadi 128 bit.

Kunci pengesahan dan sertifikat

Dua kunci, satu RSA dan satu ECDSA, dan rantai sertifikat yang sesuai, disediakan dengan aman ke dalam perangkat.

pengesahan ID

Android 8.0 menyertakan dukungan opsional untuk pengesahan ID untuk perangkat dengan Keymaster 3. Pengesahan ID memungkinkan perangkat memberikan bukti pengenal perangkat kerasnya, seperti nomor seri atau IMEI. Meskipun merupakan fitur opsional, sangat disarankan agar semua implementasi Keymaster 3 memberikan dukungan untuk itu karena dapat membuktikan identitas perangkat memungkinkan kasus penggunaan seperti konfigurasi remote zero-touch yang sebenarnya menjadi lebih aman (karena sisi remote dapat memastikannya sedang berbicara dengan perangkat yang tepat, bukan perangkat yang memalsukan identitasnya).

Pengesahan ID bekerja dengan membuat salinan pengenal perangkat keras perangkat yang hanya dapat diakses oleh Trusted Execution Environment (TEE) sebelum perangkat meninggalkan pabrik. Pengguna dapat membuka kunci bootloader perangkat dan mengubah perangkat lunak sistem dan pengidentifikasi yang dilaporkan oleh kerangka kerja Android. Salinan pengenal yang dipegang oleh TEE tidak dapat dimanipulasi dengan cara ini, memastikan bahwa pengesahan ID perangkat hanya akan membuktikan pengenal perangkat keras asli perangkat sehingga menggagalkan upaya spoofing.

Permukaan API utama untuk pengesahan ID dibangun di atas mekanisme pengesahan kunci yang ada yang diperkenalkan dengan Keymaster 2. Saat meminta sertifikat pengesahan untuk kunci yang dipegang oleh keymaster, pemanggil dapat meminta agar pengidentifikasi perangkat keras disertakan dalam metadata sertifikat pengesahan. Jika kunci disimpan di TEE, sertifikat akan dirantai kembali ke akar kepercayaan yang diketahui. Penerima sertifikat tersebut dapat memverifikasi bahwa sertifikat dan isinya, termasuk pengidentifikasi perangkat keras, ditulis oleh TEE. Ketika diminta untuk memasukkan pengidentifikasi perangkat keras dalam sertifikat pengesahan, TEE hanya mengesahkan pengidentifikasi yang disimpan di penyimpanannya, seperti yang diisi di lantai pabrik.

Properti penyimpanan

Penyimpanan yang menyimpan pengenal perangkat harus memiliki properti berikut:

  • Nilai yang diperoleh dari pengidentifikasi asli perangkat disalin ke penyimpanan sebelum perangkat meninggalkan pabrik.
  • Metode destroyAttestationIds() dapat secara permanen menghancurkan salinan data turunan pengidentifikasi ini. Penghancuran permanen berarti data benar-benar dihapus sehingga baik reset pabrik maupun prosedur lain yang dilakukan pada perangkat tidak dapat memulihkannya. Ini sangat penting untuk perangkat di mana pengguna telah membuka kunci bootloader dan mengubah perangkat lunak sistem dan memodifikasi pengidentifikasi yang dikembalikan oleh kerangka kerja Android.
  • Fasilitas RMA harus memiliki kemampuan untuk menghasilkan salinan baru dari data yang diturunkan dari pengenal perangkat keras. Dengan cara ini, perangkat yang melewati RMA dapat melakukan pengesahan ID lagi. Mekanisme yang digunakan oleh fasilitas RMA harus dilindungi sehingga pengguna tidak dapat memanggilnya sendiri, karena itu akan memungkinkan mereka untuk mendapatkan pengesahan ID palsu.
  • Tidak ada kode selain aplikasi tepercaya Keymaster di TEE yang dapat membaca data turunan pengenal yang disimpan di penyimpanan.
  • Penyimpanan terbukti tidak rusak: Jika konten penyimpanan telah dimodifikasi, TEE memperlakukannya sama seperti jika salinan konten telah dihancurkan dan menolak semua upaya pengesahan ID. Ini diimplementasikan dengan menandatangani atau meng-MAC penyimpanan seperti yang dijelaskan di bawah ini.
  • Penyimpanan tidak menyimpan pengidentifikasi asli. Karena pengesahan ID melibatkan tantangan, penelepon selalu menyediakan pengidentifikasi untuk dibuktikan. TEE hanya perlu memverifikasi bahwa ini cocok dengan nilai aslinya. Menyimpan hash aman dari nilai asli daripada nilai memungkinkan verifikasi ini.

Konstruksi

Untuk membuat implementasi yang memiliki properti yang tercantum di atas, simpan nilai turunan ID dalam konstruksi S berikut. Jangan simpan salinan lain dari nilai ID, kecuali tempat normal dalam sistem, yang dapat dimodifikasi oleh pemilik perangkat dengan rooting:

S = D || HMAC(HBK, D)

di mana:

  • D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
  • HMAC adalah konstruksi HMAC dengan hash aman yang sesuai (disarankan SHA-256)
  • HBK adalah kunci terikat perangkat keras yang tidak digunakan untuk tujuan lain apa pun
  • ID 1 ...ID n adalah nilai ID asli; asosiasi nilai tertentu ke indeks tertentu bergantung pada implementasi, karena perangkat yang berbeda akan memiliki jumlah pengidentifikasi yang berbeda
  • || mewakili rangkaian

Karena output HMAC berukuran tetap, tidak ada header atau struktur lain yang diperlukan untuk dapat menemukan hash ID individu, atau HMAC dari D. Selain memeriksa nilai yang diberikan untuk melakukan pengesahan, implementasi perlu memvalidasi S dengan mengekstrak D dari S , menghitung HMAC(HBK, D) dan membandingkannya dengan nilai dalam S untuk memverifikasi bahwa tidak ada ID individu yang dimodifikasi/rusak. Selain itu, implementasi harus menggunakan perbandingan waktu-konstan untuk semua elemen ID individual dan validasi waktu S. Perbandingan harus konstan terlepas dari jumlah ID yang diberikan dan pencocokan yang benar dari setiap bagian pengujian.

Pengidentifikasi perangkat keras

Pengesahan ID mendukung pengidentifikasi perangkat keras berikut:

  1. Nama merek, seperti yang dikembalikan oleh Build.BRAND di Android
  2. Nama perangkat, seperti yang dikembalikan oleh Build.DEVICE di Android
  3. Nama produk, seperti yang dikembalikan oleh Build.PRODUCT di Android
  4. Nama pabrikan, seperti yang dikembalikan oleh Build.MANUFACTURER di Android
  5. Nama model, seperti yang dikembalikan oleh Build.MODEL di Android
  6. Nomor seri
  7. IMEI semua radio
  8. MEID dari semua radio

Untuk mendukung pengesahan ID perangkat, perangkat membuktikan pengidentifikasi ini. Semua perangkat yang menjalankan Android memiliki enam perangkat pertama dan mereka diperlukan agar fitur ini berfungsi. Jika perangkat memiliki radio seluler terintegrasi, perangkat juga harus mendukung pengesahan IMEI dan/atau MEID radio.

Pengesahan ID diminta dengan melakukan pengesahan kunci dan menyertakan pengidentifikasi perangkat untuk dibuktikan dalam permintaan. Pengidentifikasi ditandai sebagai:

  • ATTESTATION_ID_BRAND
  • ATTESTATION_ID_DEVICE
  • ATTESTATION_ID_PRODUCT
  • ATTESTATION_ID_MANUFACTURER
  • ATTESTATION_ID_MODEL
  • ATTESTATION_ID_SERIAL
  • ATTESTATION_ID_IMEI
  • ATTESTATION_ID_MEID

Pengidentifikasi yang harus dibuktikan adalah string byte yang disandikan UTF-8. Format ini juga berlaku untuk pengidentifikasi numerik. Setiap pengenal yang akan dibuktikan dinyatakan sebagai string yang disandikan UTF-8.

Jika perangkat tidak mendukung pengesahan ID (atau destroyAttestationIds() dipanggil sebelumnya dan perangkat tidak dapat lagi membuktikan ID-nya), setiap permintaan pengesahan kunci yang menyertakan satu atau beberapa tag ini gagal dengan ErrorCode::CANNOT_ATTEST_IDS .

Jika perangkat mendukung pengesahan ID dan satu atau lebih tag di atas telah disertakan dalam permintaan pengesahan kunci, TEE memverifikasi pengidentifikasi yang disertakan dengan masing-masing tag cocok dengan salinan pengidentifikasi perangkat kerasnya. Jika satu atau lebih pengidentifikasi tidak cocok, seluruh pengesahan gagal dengan ErrorCode::CANNOT_ATTEST_IDS . Ini berlaku untuk tag yang sama untuk diberikan beberapa kali. Ini dapat berguna, misalnya, saat membuktikan IMEI: Perangkat mungkin memiliki beberapa radio dengan beberapa IMEI. Permintaan pengesahan valid jika nilai yang diberikan dengan setiap ATTESTATION_ID_IMEI cocok dengan salah satu radio perangkat. Hal yang sama berlaku untuk semua tag lainnya.

Jika pengesahan berhasil, ID yang disahkan ditambahkan ke ekstensi pengesahan (OID 1.3.6.1.4.1.11129.2.1.17) dari sertifikat pengesahan yang diterbitkan, menggunakan skema dari atas . Perubahan dari skema pengesahan Keymaster 2 dicetak tebal , dengan komentar.

API Jawa

Bagian ini hanya bersifat informasi. Pelaksana keymaster tidak mengimplementasikan atau menggunakan Java API. Ini disediakan untuk membantu pelaksana memahami bagaimana fitur tersebut digunakan oleh aplikasi. Komponen sistem mungkin menggunakannya secara berbeda, itulah sebabnya bagian ini penting untuk tidak diperlakukan sebagai normatif.