10. Structure of Commands and Responses - 102 221 v8

Berikut diterjemahkan bab 10 dari ETSI TS 102 221. Beberapa istilah yang penting untuk diketahui pada bab 10 ini antara lain :

• APDU = Application Protocol Data Unit
• CLA = CLAss
• INS = INStruction
• P1 = Parameter 1
• P2 = Parameter 2
• Lc = Length cmd
• Le = Length expected
• UICC = card, simcard
• Terminal = HP atau reader

Bab ini akan menjelaskan atau mendefinisikan commands dan responses APDU yang disupport oleh UICC.

10.1 Command APDU Structure

Sub bab ini menjelaskan struktru umum dari suatu Aplication Protocol Data Unit (APUD) yang digunakan oleh protokol aplikasi diatas protokol transmisi ketika mengirimkan command ke card.

APDU command terdiri dari header dan bagian body. Isi dari APDU command digambarkn pada tabel 10.1 di bawah. Header terdiri dari CLA, INS, P1, dan P2 yang merupakan bagian mandatory dan bagian optional adalah bagian body yang terdiri dari Lc, data, dan Le. Parameter-parameter ini akan dijelaskan lebih lanjut pada 10.1.1 sampai 10.1.6.

Ada empat kasus dari struktur C-APDU yang memungkinkan seperti didefinisikan pada table 10.2

10.1.1 Coding of Class Byte

Standard ini mendukung CLA seperti yang didefinisikan pada tabel 10.3 dan tabel 10.4a. Selain itu, pada command chaining, yang menggunakan b5 pada class byte, seperti didefinisikan pada ISO/IEC 7816-4 tidak didukung pada standard ini. Jika card mendukung mekanisme logical channel, jumlah maksimum logical channel yang tersedia ditunjukkan pada data object kapabilitas card dari historical bytes pada ATR (lihat ISO/IEC 7816-4). Jika data object kapabilitas card tidak ada, hanya basic logical channel yang disupport.

Aplikasi pada UICC yang mendukung penggunaan secure messaging pada logical channel harus membuang byte kelas dari perhitungan signature untuk verifikasi message atau mengeset kelas byte tersebut ke nilai default. Terminal dapat mengganti logical channel dimana aplikasi dieksekusi terhadap logical channel yang digunakan oleh secure messaging untuk signature verification.

Tabel 10.3 menspesifikasikan format byte kelas untuk standard logical channel. Bit b5 selalu diset ke 0. Bit b4 dan b3 digunakan untuk indikasi secure messaging (lihat tabel 10.4a). Bit b2 dan b1 menunjukkan logical channel yang digunakan. Logical channel diberi nomor dari 1 sampai 3 (untuk standar logical channel).

Tabel 10.4a menspesifikasikan format dari byte kelas untuk extended logical channel. Bit b6 menunjukkan secure messaging (lihat tabel 10.4b). Bit b5 selalu diset ke 0. Bit b4 sampai bb1 menunjukkan nomor dari 0 sampai 15; nomor ditambah 4 menunjukkan nomor logical channel dari 4 sampai 19 (extended logical channels).

Secara default, tidak ada secure messaging yang disupport oleh card (i.e b3=b4=0 pada tabel 10.3, dan b6=0 pada tabel 10.4a) kecuali jika disebutkan oleh suatu aplikasi.
10.1.2 Coding of Instruction Byte

Tabel 10.5 dibawah menggambarkan format INStruction byte dari suatu commands.

10.1.3 Coding of Parameter Bytes
Nilai dari parameter P1 dan P2 tergantung dari commannya. Jika parameter ini tidak digunakan, nilainya diset ke '00'. Format dari parameter bytes ditunjukkan pada subbab command definition.
10.1.4 Coding of Lc Byte
Jumlah byte data yang terdapat pada data field dari command APDU ditunjukkan pada parameter Lc. Lc sifatnya optional pada command APDU. Namun demikan, jika terdapat Lc pada command APDU, data field terdiri dari Lc pada byte berikutnya. Terminal dapat mengirim 1 sampai 255 byte dari command data.
10.1.5 Coding of Data Part

Struktur dari data field spesifik untuk tiap command jika memang ada dalam command tersebut atau dalam respon APDU.
10.1.6 Coding of Le Byte

Maksimum jumlah byte yang diharapkan pada respon APDU ditunjukkan oleh parameter Le, yang sifatnya optional. Artinya jika terminal tidak mengharapkan suatu data pada respon APDU, Le tidak ada pada command APDU. Namun begitu, jika ternyata terdapat Le pada command APDU, data field pada respon APDU diharapkan untuk berisi Le bytes.
Le diset ke '00' menunjukkan bahwa terminal mengharapkan untuk menerima jumlah maksimum dari byte yaitu 256 pada respond APDU. UICC dapat mengembalikan beberapa byte dari respond APDU dari 1 sampai 256 byte, dengan catatan Le diset ke '00'.

10.2 Response APDU Structure

Respon APDU terdiri dari data field yang sifatnya optional dan bagian status yang sifatnya mandatory dan dibagi kedalam 2 bytes yaitu SW1 dan SW2. Jumlah byte yang diterima pada respon APDU disimbolkan sebagai Lr (length of response data field). Struktur pada respond APDU ditunjukkan pada tabel 10.6 dibawah :

Penjelasan lebih pada SW1 dan SW2 terdapat pada sub bab berikutnya.
10.2.1 Status Conditions Returned by the UICC
Status dari card setelah memproses suatu command ditunjukkan pada byte SW1 dan SW2. Sub bab ini menspesifikasikan coding of status bytes.
10.2.1.1 Normal Processing

10.2.1.2 Postponed Processing

10.2.1.3 Warnings

10.2.1.4 Execution Errors

10.2.1.5 Checking Errors

10.2.1.5.1 Functions in CLA not Supported

10.2.1.5.2 Command not Allowed

10.2.1.5.3 Wrong Parameters

10.2.1.6 Application Errors

10.2.2 Status Words of Commands
Tabel 10.16 dibawah menunjukkan kemungkinan status yang kembalikan untuk suatu command (kemungkinan yang dapat terjadi ditandai dengan arsiterik *)

Respon dengan '91 XX' dan '93 XX' hanya dapat diberikan oleh UICC ketermina yang mendukung CAT (lihat 102 223).
Aksi yang dilakukan terminal ketika menerima respon APDU dari ENVELOPE command dengan status word '6F XX', '62 XX', dan '63 XX' didefinisikan pada sub bab 7.4.2.2.

10.2 Logical Channels
Command yang mengacu pada suatu logical channel tertentu membawa nomor logical channel dengan :

• Dua LSB dari CLA byte yang didefinisikan pada tabel 10.3. Logical channel dinomori dari 1 sampai 3. Basic logical channel (nomor 0) selalu ada secara permanent.
• Empat LSB dari CLA byte yang didefinisikan pada tabel 10.4a. Logical channel dinomori dari 4 sampai 19 (extended logical channel).

MANAGE CHANNEL command harus digunakan untuk  membuka dan menutup suatu logical channel. Nomor channel dimasukkan oleh UICC.

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 :