9. Security Features - 102 221 v8

Berikut terjemahan dari bab 9 pada standard ETSI TS 102 221 V8. Beberapa Istilah yang perlu diketahui ketika mempelajari bab 9 ini antara lain :

• Terminal = reader, handphone
• UICC = simcard, 
• PIN = Personal Identification Number
• CRT = Control Reference Template

Setiap aplikasi yang sesuai dengan standard ini dapat mendefiniskan fitur-fitur security lain selain fitur security mandatory yang didefinisikan pada standard ini.

9.1 Supported Security Features

Terminal yang mengikuti aturan-aturan pada standar ini dan didesain untuk UICC yang multi-application harus dapat mengidentifikasi fitur-fitur security yang didefinisikan pada standard ini.

Terminal yang mempunyai 1 aplikasi yang mengikuti standard ini paling tidak dapat mendukung 1 format aturan akses seperti yang terdapat pada standard ini. Aplikasi akan menspesifikasikan format mana yang digunakan.

Terminal yang mempunyai beberapa aplikasi yang didesain untuk mendukung UICC yang multi-verification akan, dari sudut pandang security, mendukung penggunaan dari level 1 verification requirements (PIN) dan level 2 verification requirements (PIN2). Format/aturannya dapata dilihat pada tabel 9.3. Terminal akan, selain itu, mensupport pengunaan universal PIN seperti didefinisikan pada standard ini.

UICC yang multi-verification yang mengikuti aturan pada standard ini, dari sudut security, mendukung lebih dari 1 level user verification requirement (PIN). Acuan ke key tertentu untuk PIN level 1 dispesifikasikan oleh setiap aplikasi seperti yang terdapat pada tabel 9.3. Selain itu, Aplikasi dapat menspesifikasikan level 2 user verification requirement (PIN2). UICC yang multi-verification dapat mendukung penggunaan dari universal PIN. UICC yang seperti ini juga dapat mendukung aturan akses yang definisikan pada atribute security  pada tag '8B' (i.e. direferensi untuk format yang expanded).

UICC yang hanya dapat menggunakan single verification akan, dari sudut pandang security, mendukung 1 buah level 1 user verification requirement (PIN) seperti didefinisikan pada table 9.3. Selain itu, aplikasi dapat menspesifikasikan level 2 user verification requirement sebagai second application verification requirement (PIN2). UICC yang single verification dapat berisi satu atau lebih selectable application jika tidak ada aspek security yang dipertimbangkan/dilakukan antara beberapa selectable applications. Dari sudut pandang security, hanya 1 buah level 1 verification requirement (PIN) yang dimasukkan ke semua ADFs/DFs/ dan file yang berada pada UICC. Selain itu, level 2 user verification requirement (PIN2) dapat pula dimasukkan kepada setiap aplikasi. Dari sudut pandang security dan aturan akses, UICC dilihat sebagai single application card. Format level 1 dan level 2 user verification requriment harus sesuai dengan table 9.3.

9.2 Security Architecture

Suatu aplikasi yang terdapat pada UICC yang memenuhi aturan-aturan pada standard ini harus menspesifikasikan refernsi key level 1 sebagai user verification (PIN). Selain itu, aplikasi dapat pula menspesifikasikan refeernsi key level 2 sebagai user verification requirement (PIN2) yang kedua. Format level 1 dan 2 ddari user verification requirement tersebut harus sesuai dengan tabel 9.3. Selain itu juga, aplikasi dapat pula menspesifikasikan kegunaan dari universal PIN sebagai pengganti untuk PIN aplikasi.

Untuk mengeksekusi suatu command selain SELECT dan STATUS/GET RESPONSE, kondisi securitynya harus dipenuhi. Data object dari kondisi security tersebut berisi beberapa kondisi yang harus dipenuhi agar dapat mengeksekusi command tertentu pada ADF/DF/EF yang telah dipilih.

Jika UICC tidak dapat menentukan kondisi akses suatu file, maka permintaan akses kepada file tersebut tidak boleh diberikan dan card harus mengembalikan status word '6982' (security status not satisfied).

Arsitektur security terdiri dari beberapa bagian yaitu :

• Atribute security : terdiri dari kumpulan aturan-aturan akses
• Aturan akses : terdiri dari mode akses dan satu atau beberapa kondisi securiti
• Access Mode (AM) : yang menunjukkan operasi (command) mana kondisi securiti berlaku.
• Security Condition (SC) : berisi acuan/referensi ke key reference yang applicable (PINs).

Subbaba 9.2.1 sampai 9.2.7 mendefinisikan bagian-bagian dari arsitektur securiti.

9.2.1 Security Attributes

Security attributes berada pada suatu ADF/DF/EF dan merupakan bagian dari FCP. Security attributes ditunjukkan pada FCP menggunakan tag '8B', tag '8C' atau tag 'AB' tergantung format yang digunakan. Untuk lebih jelasnya dapat melihat ISO/IEC 7816-4.

9.2.2 Access Mode

Byte/object data dari access mode (AM byte/ AM_DO) mendefinisikan bagaimana kondisi security dari suatu group/tipe suatu command dapat dilakukan. Penerjemahan dari AM byte/AM_DO ada file dependent (i.e perbedaan untuk DF/ADF dan EF lihat ISO 7816-4). Type/group command didefinisikan dan dikodekan sesuadi dengan ISO/IEC 7816-4.

Untuk beberapa instruksi yang tidak termasuk dalam dalam suatu group seperti yang terdapat pada ISO/IEC 7816-4, hak akses dapat ditunjukkan menggunakan AM_DO tag '81' sampai '8F'. Nilai tag yang mendefinisikan AM_DO menunjukkan deskripsi apa yang terdapat pada suatu command pada definition list yang diikuti pada nilai data object. Coding ari bit b4 ke b1 pada tag AM_DO didefinisikan pada ISO/IEC 7816.

Kondisi security untuk bit yang tidak diset ke 1 pada byte AM diset ke NEVer secara default.

9.2.3 Security Condition

Security condition (SC) menunjukkan prosedur security apa yang harus dilakukan(user PIN verification) sebelum command dieksekusi pada suatu file. SC dikodekan sesuai dengan ISO/IEC 7816-4.

9.2.4 Access Rules

Access rule mendefinisikan kondisi security untuk mengakses suatu file untuk setiap/group command yang terdapat pada AM-byte/AM_DO. Kondisi security ditunjukkan pada SC-bytes/SC_DO yang mengikuti AM-byte/AM_DO. Aturan akses dikodekan menggunakan satu atau dua AM-bytes/AM_DOs yang diikuti satu atau lebih kondisi security yang harus dipenuhi untuk akses yang sesuai/akses yang valid.

Access rule dapat dikodekan dalam format yang padat (default/compact format) ataupun pada expanded format. Selain itu, access rule dapat pula dikombinasi dengan satu atau lebih SC ke satu AM sehingga paling tidak satu SC (OR relation) akan terpenuhi sebelum command dieksekui. Dapat pula mengkombinasi SC sehingga satu atau lebih SC harus terpenuhi dahulu (AND relation).

Access rule adalah kumpulan beberapa persyaratan yang harus dipenuhi agar dapat melakukan suatu operasi pada suatu file. Access rule berisi satu atau lebih atribut securiti, AM byte/AM_DO pada atribut ini menunjukkan command apa yang dapat dilakukan dan SC byte/SC_DO menunjukkan SC yang harus dipenuhi agar dapat mengeksekusi suatu command yang ditunjukkan pada AM byte/AM_DO. Isi dari setiap AM byte (compact format) atau AM_DO (pada expanded format) harus unik dalam access rule yang sama. SC_DO OR atau AND relations akan berisi paling tidak dua kondisi akses. Terminal tidak akan memperhatikan kombinasi AM/SC yang secara sintaks tidak benar atau dengan instruksi yang tidak diketahui.

Tag CRT untuk SC_DO didefinisikan pada ISO/IEC 7816-4. SC yang dibutuhkan untuk mengeksekusi beberapa command yang terdapat pada AM byte/AM_DO dapat berupa simple condition atau logical OR or AND condition dari beberapa SC_DO. Object TLV yang telah dibuat yang berisi AM byte/AM_DO dan SC byte/SC_DO merupakan suatu access rule. Access rule dapat ditunjukkan pada FCP dengan salah satu cara berikut :

• Tag '8C' security attributes: compact format.
• Tag 'AB' security attributes : expanded format.
• Tag '8B' security attributes : rerefenced to expanded format.

9.2.5 Compact Format

Compact format ditunjukkan dengan tag '8C' pada FCP. Pada compact format ini, access rule terdiri dari AM byte dan satu atau lebih SC byte seperti yang terdapat pada ISO/IEC 7816-4.

AM byte membawa dua jenis tipe informasi. Interpretasi dari AM byte (dikodekan pada b8), jumlah SC byte yang mengikutinya, sama dengan jumlah bit yang diset ke 1 pada bit b7 ke b1 pada AM byte. Jika b8 pada AM byte diset ke 0, interpretasi dari b7 ke b1 dapat dilihat pada ISO/IEC 7816-4. Jika b8 pada AM byte diset ke 1, penggunaan b7 ke b4 bersifat proprietary(tergantung pengguna/user).

Ketika terdapat beberapa AM byte dengan satu atau lebih SC byte, hal ini menunjukkan kondisi OR.

9.2.6 Expanded Format

Expanded format ditunjukkan dengan tag 'AB' pada FCP. Tag ini menunjukkan data object yang telah dibuat. Pada expanded format, suatu access rule terdiri dari satu AM_DO yang diikuti oleh rangkaian SC_DO. Isi dari AM_DO didefinisikan oleh tag yang menunjukkannya, lihat ISO/IEC 7816-4. Tag '80' menunjukkan bahwa AM_DO berisi AM byte. Rangkain SC_DO yang mengikuti AM_DO berhubungan untuk semua command yang dispesifikan dalam AM_DO tersebut. Beberapa SC_DO yang berbeda dapat membentuk OR atau AND condition seperti disebutkan pada ISO/IEC 7816-4. Informasi yang mengikuti tag 'AB' pada FCP dapat berisi banyak data jika aturannya rumit. Informasi ini adalah bagian dari FCP yang dikirimkan pada interface sebagai respond dari SELECT atau STATUS command. Struktur securiti atribut pada expanded format seperti terlihat di bawah :

Contoh penggunaan expanded format ini dapat dilihat pada lampiran E pada standar ini.
9.2.7 Access Rules Referencing

Access rule dapat dibagi antara tiap file pada UICC dengan melakukan referenci pada file tersebut. Hal ini dapat dicapai dengan menyimpan security atribut pada expanded format pada liner fixed file, Access Rule Referenced (EF_ARR) pada UICC. Struktur dari EF_ARR seperti terlihat di bawah :

Format yang telah direferensi ditunjukkan pada FCP yang mengikuti tag '8B'. Access rule disimpan pada file, EF_ARR. File ini adalah linear fixed file. Referensinya berdasarkan 2 metode di bawah :

• File ID dan numor record (File ID, record number).
• File ID, SE ID, dan nomor record (File ID, SE ID, record number).

Kemungkinan kedua membolehkan penggunaan dari access rule yang berbeda pada securiti environment yang berbeda. Ketika mereferensi EF_ARR yang berdasarkan pada file ID, aturan dari lokasi access rule adalah sebagai berikut :

• Untuk EF, jika file EF(ARR) dengan ID ditunjukkan pada tag '8B' tidak dapat ditemukan pada current DF, maka parent DF akan dicari untuk EF(ARR) ini. Proses ini akan dilanjutkan sampai EF(ARR) ditemukan atau sampai ADF atau MF telah dicapai.
• Untuk DF, jika file EF(ARR) dengan ID yang ditunjukkan pada tag '8B' tidak dapat ditemukan pada current DF, maka kakek dari DF ini akan dicari untuk EF(ARR). Proses ini akan terus dilakukan sampai EF(ARR) ditemukan atau sampai ADF atau MF telah dicapai.
• Untuk MF atau ADF, file EF(ARR) dengan ID yang ditunjukkan pada tag '8B' akan dicari dibawah MF.

Catatan :  mungkin ada beberapa EF_ARR yang berisi access rule dibawah DF yang sama. Mereka dibedakan dan direferensi dengan file IDnya masing-masing.

Struktur dari access rule yang mereferensi DO seperti terlihat di bawah :

Setiap record pada EF_ARR berisi rangkaian AM_DO yang diikuti oleh beberapa SC_DO. Isi dari record adalah aturan yang berlaku untuk file yang telah dipilih. Contoh isi dari file EF_ARR dapat dilihat pada lampiran F di standard ini. Opsi dengan referensi SE ID akan digunakan pada aplikasi dimana terdapat beberapa security environment.

9.3 Security Environment

Security environment adalah mekanisme untuk menspesifikasikan fungsi-fungsi security untuk card system yang ada untuk menyediakan perlindungan pada commands dari card untuk aplikasi tertentu sesuai dengan ISO/IEC 7816-4. Security environment untuk UICC yang multi-application didefinisikan sebagai wadah untuk setiap aplikasi yang aktif pada UICC tersebut. Untuk kasus single application, security environment valid untuk semua UICC. Pada referenced format, dimungkinkan untuk menunjukkan beberapa access rules yang berbeda sebagai fungsi SE yang sedang digunakan.
9.3.1 Definition of the Security Environment
Dalam kasusu referenced format yang berisi SEID sebagai metode referensi, terminal harus mengevaluasi SEID tersebut dan melakukan user verification yang sesuai.
Properti dibawah dipetakan ke SE01 dan SE00:

Persyaratan diatas diambil dari tabel 9.1. UICC yang multi-application harus mensupport penggunaan dari SE00 dan SE01 agar dapat membolehkan application verification requirement  diganti oleh Universal PIN. Terminal dengan kemampuan multi-application juga harus mensupport referensi SEID pada EF_ARR.

Ketika tidak ada aplikasi yang aktif pada suatu logical channel (SE_No_Active_Application), maka security environment diset sebagai berikut :

• Semua PIN aplikasi yang dimasukkan pada UICC dianggap sebagai APPL_PIN
• Jika terdapat paling tidak satu PIN aplikasi yang didisabled, maka SE adalah SE#00 kecuali untuk kasus dimana Universal PIN dienable tetapi default usage qualifer (lihat 9.5.2) diset ke "do not use" seperti yang terdapat pada table 9.1 (DUUP).

Security environment valid dibawah MF dan dibawah child dari DF/EF selama tidak ada aplikasi yang aktif. Ketika terdapat aplikasi yang aktif pada suatu logical channel (SE_Active_Application) security environment diset sesuai dengan tabel 9.1 dengan APPL_PIN menjadi PIN aplikasi dari aplikasi yang aktif tersebut. Security environment ini juga aktif dibawah ADF/MF dan child DF/EF dari ADF/MF ini.

9.3.2 Logical Channels and Security Environment

UICC yang mensupport suatu logical channel mempunyai security environment yang diset ketika proses aktivasi dari aplikasi tersebut dan valid untuk logical channel tersebut dimana aplikasi diaktivasi. Security environment tetap sama pada logical channel ini selama ada aplikasi baru dipilih atau status dari PIN status DO telah diganti/berubah. Contohnya aplikasi atau status Universal PIN telah diubah dari disabled ke enabled atau sebaliknya.
Security environment dari suatu aplikasi yang berjalan pada suatu logical channel diwarisi ketika ada channel baru yang dibuka dari non-basic channel. Hal ini dievaluasi setelah proses ATR dan diset sebagai SE_No_Active_Application ketika channel baru dibuka dari basic channel.
Suatu command yang dikirimkan melalui suatu logical channel yang mempengaruhi settingan SE hanya mempengaruhi SE pada suatu channel dimana command dikirimkan dan channel lainnya dengan security environment yang diwarisi dari channel ini. SE mengubah suatu channel dengan security yang diwariskan juga mengubah SE pada channel dimana status security diwariskan.

9.4 PIN Definitions

Sub bab dibawah mendefinisikan type-type PIN yang akan ada pada UICC, yaitu Universal PIN dan application PIN, dan juga tipe kondisi akses lain yang dibutuhkan oleh UICC atau suatu aplikasi.
9.4.1 Universal PIN
Universal PIN adalah PIN yang digunakan pada lingkungan multi-application untuk memungkinkan beberapa aplikasi untuk membagi satu PIN umum. Universal PIN adalah global akses yang telah diberi referensi key dengan nilai '11'. Nilai referensi key ini tidak boleh digunakan untuk apapun kecuali menunjukkan Universal PIN.
Untuk memberi akses kepada beberapa aplikasi pada UICC yang multi-application, terminal yang mengikuti aturan pada standard ini harus mensupport penggunaan dari universal PIN. UICC yang multi-application yang mengikuti standard ini juga harus mendukung penggunaan dari Universal PIN.
Jika suatu aplikasi membolehkan kegunaan dari Universal PIN sebagai replacement PIN, maka Universal PIN ini harus merupakan bagian dari kondisi akses untuk aplikasi ini pada UICC multi-aplikasi yang mengikuti standard ini. Dalam kasus UICC yang single verification, Universal PIN tidak dapat digunakan.
Universal PIN tidak dimiliki oleh aplikasi manapun, contohnya status verifikasinya tidak dapat direset oleh aktivasi suatu aplikasi atau termination procedures dari suatu aplikasi.
9.4.2 Application PIN
Application PIN adalah PIN yang menggunakan referensi key global (didefinisikan sebagai level 1 pada tabel 9.2) seperti didefinisikaa pada tabel 9.3. PIN aplikasi memungkinan akses ke file apapun pada UICC dimana dia direferensi pada access rule. Contohnya PIN ini mempunyai hak akses global terhadap suatu file. PIN menjadi application PIN dimana dia dimasukkan, dan dia termasuk ke dalam aplikasi security environmetnnya. Suatu aplikasi, dari sudut pandang security, dapat terdiri dari satu atau lebih ADF/DF. Dalam kasus ini, ADF/DS dilihat sebagai satu aplikasi dalam sudut pandang security dan access rule. Semua operasi yang lakukan pada PIN (enable/diable/replace) yang mengkover beberapa ADF/Df mempengaruhi beberapa aplikasi dimana PIN ini digunakan dan mempengaruhi access rule dimana refensi keynya digunakan.
9.4.3 Local PIN
Local PIN adalah PIN yang menggunakan key reference yang hanya valid pada ADF/DF dimana dia ditunjukkan pada FCP. Ini berarti 2 ADF dapat menggunakan nomor local key reference dengan dua nilai yang berbeda dan dua status yang berbeda (enabled, disabled, verified, blocked), satu untuk tiap ADF. Status verifikasi dari local PIN dijaga ketika melakukan file selection. Local PIN harus ditunjukkan pada FC dari child DF. Local PIN didefinisikan sebagai level 2 seperti yang terdapat pada table 9.2 dan dikodekan seperti pada tabel 9.3. Local PIN yang direferensi pada ADF atau DF, yang bukan merupakan DF_TELECOM, tidak memberikan akses ke DF_TELECOM.
ADF harus menggunakan satu application PIN dan nol, satu atau lebih local PIN. ADF yang menggunakan paling tidak 2 local PIN harus mempunyai 1 local PIN yang berpasangan dengan application PIN. Table 9.3 menunjukkan bagaimana application PIN dan local PIN dipasangkan (referensi global key '01' dipasangkan dengan referensi local key '81', referensi global key '02' dipasangkan dengan referensi local key '82', dsb). Jika penggantian application PIN dengan Universal PIN dimungkinkan, maka ADF juga harus menggunakan Universal PIN tersebut.
Local PIN dapat dimasukkan ke DF apapun. Pada kasus ini, referensi key yang menunjukkan aplikasi PIN kedua seperti didefinisikan pada table 9.3 harus digunakan.
9.4.4 PINs and Logical Channels
Status PIN dari Universal PIN dan application PIN bersifat global pada UICC. Status PIN dari local PIN juga terdapat pada ADF/DF dimana PIN tersebut dispesifikasikan.
Status PIN dari Universal PIN, application PIN, dan local PIN bersifat independet dari logical channel. Artinya ketika PIN diverifikasi pada suatu logical channel, dia juga akan diverifikasi oleh semua channel yang lain. Juga ketika PIN dienabled pada suatu logical channel, maka dia juga dienabled pada semua channel yang lain.

9.5 PIN and Key Reference Relationship
Subab ini akan menjelaskan hubungan antara user verification requirement (PIN) dengan referensi ke suatu PIN pada VERIFY, CHANGE, DISABLE/ENABLE, VERIFICATION dan UNBLOCK commands.
9.5.1 Access Condition Mapping
Access Condition Mapping, yang menggunakan SC_DO, dilakukan dengan menggunakan expaded format dengan entri seperti yang dikodekan pada nilai CRT, contohnya digunakan tag 'A4'. CRT adalah TLV DO yang telah dibuat yang berisi pengguaan qualifier TLV DO (tag '95') dan reference key TLV DO (tag '83').
Group kondisi akses didefinisikan sesuai dengan tabel 9.2. Setiap group dibagi menjadi beberapa reference key. Kegunaan dari reference key harus sesuai dengan group yang didefinisikan pada tabel 9.2 di bawah :

Level yang ditunjukkan pada tabel 9.2 diatas digunakan pada standard ini untuk referensi ke group access condition yang spesifik.
Key reference hanya boleh dimasukkan untuk tujuan seperti yang didefinisikan pada tabel 9.3, contohnya referensi key level 1 selalu digunakan untuk suatu aplikasi atau kumpulan aplikasi yang membagi access condition yang sama. Referensi key level 2 hanya valid digunakan pada ADF/DF dimana dia ditunjukkan.

UICC yang single verification (dari sudut pandang security) harus menggunakan referensi key '01' sebagai PIN dan referensi key '81' sebagai PIN2. UICC yang multi-verification harus menggunakan referensi key yang berada diantara '01' sampai '08' sebagai PIN dan dapat menggunakan referensi key pada rentang '81' sampai '88' sebagai PIN2. Selain itu, UICC yang multi-verification tersebut harus dapat mendukung kegunaan dari key referensi '11' sebagai universal PIN, lihat sub bab 9.3.1 untuk definisi dari Universal PIN. Multiple application (dari sudut pandang security) yang terdapat pada UICC tidak boleh membagi referensi key apapun kecuali untuk key referensi '11', yang digunakan sebagai Universal PIN.
9.5.2 PIN Status Indication
Status PIN yang digunakan oleh aplikasi untuk user verification disimpan pada PS Template DO dan harus ditunjukkan pada FCP sebagai respon kepada SELECT atau STATUS command yang dikirimkan pada aplikasi atau DF level. Informasi status PIN ini ditunjukkan pada FCP pada PS template DO menggunakan tag 'C6'. PS template DO membawa 2 jenis data, PS_DO yang pertama ditunjukkan oleh tag '90' yang menandakan bahwa status PIN sedang dienabled/disabled. PS_DO diikuti satu atau lebih key reference data object yang ditunjukkan dengan tag '83'. Status PIN dapat dikodekan dengan beberapa byte. Untuk setiap bit diset ke '1', maka key referencenya(PIN) sedang di enabled. PS_DO dikodekan dengan menggunakan bitmap list. Bit b8 pada MSB yang terhubung ke key reference yang pertama ditunjukkan dengan tag '83' yang mengikuti PS_DO. Bit b7 sampai b1 dipetakan ke key reference yang sesuai yang ditunjukkan dengan tag '83'. Key reference data object dapat didahului oleh penggunaan qualifier data object. Penggunaan qualifier data object yang ditunjukkan dengan tag '95' sifatnya mandatory untuk Universal PIN (lihat 9.4.1) dan sifatnya optional untuk PIN yang lainnya. Penggunaan qualifier ini menunjukkan apakah PIN yang dienable membutuhkan verifikasi untuk aksesnya. Jika tidak ada penggunaan qualifier, atau data objectnya kosong, yang berada diawal referensi key, ini menunjukkan bahwa referensi key ini tidak mendukung fitur ini, dan dia sebaiknya diverifikasi jika sedang dienabled. Isi dari PS_DO usage qualifier didefinisikan pada tabel 9.4 di bawah. Dari tabel tersebut, nilai yang digunakan untuk verifikasi PIN user adalah '08'. Usage qualifier dari Universal PIN didefinisikan pada conteks aplikasi dan dapat mempunyai nilai yang berbeda pada aplikasi yang berbeda.
Usage qualifier yang default dari Universal PIN setelah proses ATR diset ke "do not use" jika semua PIN aplikasi dienabled atau jika terdapat paling tidak 1 aplikasi dengan PINnya didisabled mempunyai Universal PIN yang diset ke "do not user". Ketika tidak ada aplikasi yang aktif pada suatu logical channel, maka Universal PIN usage qualifier akan dievaluasi setelah proses ATR.

PS template DO dibuat seperti ditunjukkan pada tabel 9.5 dan 9.6 di bawah :