Google 致力于为黑人社区推动种族平等。查看具体举措
Halaman ini diterjemahkan oleh Cloud Translation API.
Switch to English

Pengesahan Kunci dan ID

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

Namun, ini hanya berlaku jika kunci keystore diketahui berada dalam penyimpanan yang didukung hardware. Di Keymaster 1, tidak ada cara bagi aplikasi atau server jarak jauh untuk memverifikasi secara andal jika memang demikian. Daemon keystore memuat keymaster HAL yang tersedia dan percaya apa pun yang dikatakan HAL sehubungan dengan dukungan hardware pada kunci.

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

Pengesahan kunci bertujuan untuk memberikan cara untuk menentukan dengan kuat apakah pasangan kunci asimetris didukung oleh perangkat keras, apa properti kunci tersebut, 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 sekumpulan tag, jenis, dan metode ke HAL.

Tag

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

Tipe

Keymaster 2 ke bawah

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

Metode AttestKey

Keymaster 3

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

Keymaster 2 ke 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 apa pun 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 ini diperlukan untuk mendekripsi gumpalan kunci jika mereka ditentukan selama pembuatan kunci.
  • certChain adalah parameter output, yang mengembalikan serangkaian sertifikat. Entri 0 adalah sertifikat pengesahan, artinya 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 dibuktikan 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 dibuktikan. Sertifikat ditandatangani dengan kunci pengesahan yang disediakan pabrik yang menggunakan algoritme yang sama dengan kunci yang dibuktikan (RSA untuk RSA, EC untuk EC).

Sertifikat pengesahan berisi bidang dalam tabel di bawah ini dan tidak dapat 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
tbsCertificate URUTAN Sertifikat TBS
signatureAlgorithm AlgorithmIdentifier dari algoritma yang digunakan untuk menandatangani kunci:
ECDSA untuk kunci EC, RSA untuk kunci RSA.
signatureValue BIT STRING, tanda tangan dihitung pada tbsCertificate berenkode ASN.1 DER.

URUTAN Sertifikat TBS

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

Perpanjangan pengesahan

Ekstensi attestation berisi deskripsi lengkap tentang otorisasi keymaster yang terkait dengan kunci tersebut, 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 deskripsi jenis (empat bit orde tinggi) yang disamarkan.

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 yang lebih lama, KM_TAG_PURPOSE ditentukan di keymaster_defs.h.)

Nilai diterjemahkan secara langsung ke jenis ASN.1, sesuai tabel ini:

Jenis keymaster 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 Jan 1970 00:00:00 GMT)
BOOL NULL (dalam keymaster, tag present artinya benar, absen artinya salah.
Semantik yang sama berlaku untuk pengkodean ASN.1)
BIGNUM Saat ini tidak digunakan, jadi tidak ada pemetaan yang ditentukan
BYTES OCTET_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

Kolom keymasterVersion dan attestationChallenge diidentifikasi secara posisional, bukan berdasarkan tag, jadi tag dalam formulir yang dienkode hanya menentukan jenis kolom. Bidang lainnya secara implisit diberi tag seperti yang ditentukan dalam skema.

Nama bidang Tipe Nilai
attestationVersion BILANGAN BULAT Versi skema pengesahan: 1, 2, atau 3.
attestationSecurity Tingkat keamanan Tingkat keamanan pengesahan ini. Anda dapat memperoleh pengesahan perangkat lunak dari kunci yang didukung perangkat keras. Pengesahan tersebut tidak dapat dipercaya jika sistem Android disusupi.
keymasterVersion BILANGAN BULAT Versi perangkat keymaster: 0, 1, 2, 3, atau 4.
keymasterSecurity Tingkat keamanan Tingkat keamanan penerapan keymaster.
attestationChallenge OCTET_STRING Nilai Tag::ATTESTATION_CHALLENGE , ditetapkan ke permintaan pengesahan.
uniqueId OCTET_STRING ID unik opsional, ada jika kunci memiliki Tag::INCLUDE_UNIQUE_ID
softwareEnforced AuthorizationList Opsional, otorisasi keymaster yang tidak diberlakukan oleh TEE, jika ada.
teeEnforced AuthorizationList Opsional, otorisasi Keymaster yang diberlakukan oleh TEE, jika ada.

Bidang AuthorizationList

AuthorizationList bidang AuthorizationList bersifat opsional dan diidentifikasi oleh nilai tag keymaster, dengan jenis bit yang disembunyikan. Pemberian tag eksplisit digunakan sehingga bidang juga berisi tag yang menunjukkan jenis ASN.1 mereka, untuk penguraian yang lebih mudah.

Untuk detail tentang nilai setiap types.hal , lihat types.hal untuk Keymaster 3 dan keymaster_defs.h untuk Keymaster 2 dan yang lebih lama. Nama tag Keymaster diubah menjadi nama bidang dengan menghilangkan awalan KM_TAG dan mengubah sisanya menjadi huruf besar / kecil, sehingga Tag::KEY_SIZE menjadi keySize .

RootOfTrust

Bidang RootOfTrust diidentifikasi secara posisional.

Nama bidang Tipe Nilai
verifiedBootKey OCTET_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 terverifikasi telah selesai.
verifiedBootState VerifiedBootState Status boot terverifikasi.
verifiedBootHash OCTET_STRING Ringkasan semua data yang dilindungi oleh Boot Terverifikasi. Untuk perangkat yang menggunakan implementasi Android Verified Boot 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 The VBMeta Digest

Nilai VerifiedBootState

Nilai verifiedBootState memiliki arti sebagai berikut:

Nilai Berarti
Verified Menunjukkan rantai kepercayaan penuh yang membentang dari bootloader ke partisi terverifikasi, termasuk bootloader, partisi boot, dan semua partisi terverifikasi.
Dalam keadaan ini, nilai verifiedBootKey adalah hash dari sertifikat yang disematkan, yang berarti sertifikat yang tidak dapat diubah dibakar ke dalam ROM.
SelfSigned Menunjukkan partisi boot telah diverifikasi menggunakan sertifikat yang disematkan, dan tanda tangannya valid. Bootloader menampilkan peringatan dan sidik jari dari kunci publik sebelum mengizinkan proses boot untuk melanjutkan.
Dalam keadaan ini, nilai 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, nilai verifiedBootKey kosong.
Failed Menunjukkan perangkat gagal verifikasi. Tidak ada sertifikat pengesahan yang benar-benar berisi nilai ini, karena dalam keadaan ini bootloader berhenti. Ini disertakan di sini untuk kelengkapan.

Nilai SecurityLevel

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 itu disusupi.
TrustedEnvironment Kode yang membuat atau mengelola elemen yang relevan (pengesahan atau kunci) diimplementasikan dalam Trusted Execution Environment (TEE). Ini dapat diubah jika TEE dikompromikan, tetapi TEE sangat tahan terhadap gangguan jarak jauh dan cukup tahan terhadap gangguan oleh serangan perangkat keras langsung.
StrongBox Kode yang membuat atau mengelola elemen yang relevan (pengesahan atau kunci) diimplementasikan dalam modul keamanan perangkat keras khusus. Ini dapat diubah jika modul keamanan perangkat keras dikompromikan, tetapi sangat tahan terhadap gangguan jarak jauh dan sangat tahan terhadap gangguan oleh serangan perangkat keras langsung.

Identitas unik

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

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

Dimana:

  • T adalah "nilai penghitung temporal", yang dihitung dengan membagi nilai Tag::CREATION_DATETIME dengan 2592000000, menghilangkan sisanya. T berubah setiap 30 hari (2592000000 = 30 * 24 * 60 * 60 * 1000).
  • C adalah nilai Tag::APPLICATION_ID
  • R bernilai 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 dikenal di Lingkungan Eksekusi Tepercaya dan tidak pernah diungkapkan olehnya. Rahasianya mengandung setidaknya 128 bit entropi dan unik untuk perangkat individu (keunikan probabilistik dapat diterima mengingat 128 bit entropi). HBK harus berasal dari bahan kunci yang menyatu melalui HMAC atau AES_CMAC.

Pangkas keluaran HMAC_SHA256 menjadi 128 bit.

Kunci dan sertifikat pengesahan

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

Pengesahan ID

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

Pengesahan ID berfungsi 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 pengenal 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 pengenal perangkat keras perangkat disertakan dalam metadata sertifikat pengesahan. Jika kunci disimpan di TEE, sertifikat akan berantai kembali ke akar kepercayaan yang diketahui. Penerima sertifikat tersebut dapat memverifikasi bahwa sertifikat dan isinya, termasuk pengenal perangkat keras, ditulis oleh TEE. Saat diminta untuk menyertakan pengenal perangkat keras dalam sertifikat pengesahan, TEE hanya membuktikan pengenal 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 pengenal asli perangkat disalin ke penyimpanan sebelum perangkat meninggalkan pabrik.
  • Metode destroyAttestationIds() bisa secara permanen menghancurkan salinan data turunan pengenal ini. Penghancuran permanen berarti data dihapus sepenuhnya sehingga baik reset pabrik maupun prosedur lain yang dilakukan pada perangkat tidak dapat memulihkannya. Ini terutama penting untuk perangkat yang penggunanya telah membuka kunci bootloader dan mengubah perangkat lunak sistem serta mengubah pengenal yang dikembalikan oleh framework 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 hal itu akan memungkinkan mereka memperoleh pengesahan ID palsu.
  • Tidak ada kode selain aplikasi tepercaya Keymaster di TEE yang dapat membaca data turunan pengenal yang disimpan di penyimpanan.
  • Penyimpanan tidak dapat dirusak: Jika konten penyimpanan telah dimodifikasi, TEE akan memperlakukannya sama seperti jika salinan konten telah dihancurkan dan menolak semua upaya pengesahan ID. Ini diimplementasikan dengan menandatangani atau MAC penyimpanan seperti yang dijelaskan di bawah ini .
  • Penyimpanan tidak menyimpan pengenal asli. Karena pengesahan ID melibatkan tantangan, pemanggil selalu menyediakan pengenal 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 yang diturunkan ID dalam konstruksi S berikut. Jangan simpan salinan lain dari nilai ID, kecuali tempat normal dalam sistem, yang dapat dimodifikasi oleh pemilik perangkat dengan melakukan rooting:

S = D || HMAC(HBK, D)

dimana:

  • D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
  • HMAC adalah konstruksi HMAC dengan hash aman yang sesuai (direkomendasikan SHA-256)
  • HBK adalah kunci terikat perangkat keras yang tidak digunakan untuk tujuan lain
  • ID 1 ...ID n adalah nilai ID asli; pengaitan nilai tertentu ke indeks tertentu bergantung pada penerapan, karena perangkat yang berbeda akan memiliki jumlah pengenal yang berbeda
  • || mewakili penggabungan

Karena keluaran HMAC berukuran tetap, tidak ada header atau struktur lain yang diperlukan untuk dapat menemukan hash ID individual, atau HMAC 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 di 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 S. Waktu perbandingan harus konstan terlepas dari jumlah ID yang diberikan dan pencocokan yang benar dari bagian mana pun dari pengujian.

Pengenal perangkat keras

Pengesahan ID mendukung pengenal perangkat keras berikut:

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

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

Pengesahan ID diminta dengan melakukan pengesahan kunci dan termasuk pengenal perangkat untuk membuktikan 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

Pengenal yang akan dibuktikan adalah string byte berenkode UTF-8. Format ini juga berlaku untuk pengenal numerik. Setiap pengenal yang akan dibuktikan diekspresikan sebagai string berenkode UTF-8.

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

Jika perangkat mendukung pengesahan ID dan satu atau beberapa tag di atas telah disertakan dalam permintaan pengesahan kunci, TEE memverifikasi pengenal yang disediakan dengan masing-masing tag cocok dengan salinan pengenal perangkat kerasnya. Jika satu atau lebih pengenal 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 menguji 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 pengesahan 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 Java

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