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 :

8. Application and File Structure - 102 221 v8

Berikut akan diterjemahkan/diedit sebagian bab 8 dari ETSI TS 102 221 v8. Beberapa istilah yang perlu diketahui antara lain:

• MF = Master File
• ADF = Application Dedicated File 
• EF = Elementary File
• DF = Dedicated File
• FCP = File Control Parameters
• SE = Security Environment
• PIN = Personal Identification Number

Pada bab ini akan dijelaskan tentang struktur aplikasi dan struktur logical dari UICC.

8.1 UICC Application Structure

Dokument berikut tidak menetapkan batasan apapun terhadap lokasi dari suatu aplikasi. Semua aplikasi sifatnya unik dan diidentifikasi dengan application identifiers yang diperoleh dari EFdir. Aplication ID ini digunakan untuk memilih suatu aplikasi.
EFdir, EFpl dan EFiccid adalah aplikasi yang sifatnya mandatory dan tersimpan secara langsung pada Master File (MF). Lihat bab 13 untuk informasi lebih lanjut.
DFtelecom sifatnya optional. Jika ada, dia akan berada di bawah MF dan menggunakan cadangan FID '7F 10'. DFtelecom berisi informasi aplikasi yang independent.
8.2 Type-Type File
Subbab berikut mendefinisikan beberapa jenis tipe files yang digunakan oleh aplikasi.
8.2.1 Dedicated Files
Dedicated File(DF) memungkinkan pembuatan group dari suatu file. DF dapat bertindak sebagai parent dari beberapa DF dan/atau dari beberapa EF. DF dapat diakses menggunakan file identifiers.
Application DF (ADF) adalah suatu DF spesifik yang berisi semua aplikasi dari DF dan EF.
8.2.2 Elementary Files
8.2.2.1 Transparent EF
Suatu EF dengan struktur transparent terdiri dari beberapa rangkain bytes. Ketika proses pembacaan atau update, rangkaian bytes tersebut dapat bertindak sebagai relative address yang menunjukkan posisi awal dari bytes, dan jumlah byte yang akan dibaca atau diupdate. Byte pertama dari transparent EF ini mempunyai relative address '00 00'. Panjang datanya ditunjukkan pada respon SELECT dari EF.
8.2.2.2 Linear Fixed EF
EF dengan struktur linear fixed terdiri dari rangkain records yang semuanya mempunyai panjang yang sama (fixed length). Record pertama adalah record nomor 1. Panjang record dan nilainya dikali dengan jumlah records ditunjukkan pada respon SELECT dari EF ini.

Ada beberapa metode untuk mengakses record dalam linear fixed EF ini yaitu :

• Menggunakan nomor record
• Ketika pointer record tidak diset, maka memungkinkan untuk mengakses record pertama atau record terakhir dengan mode NEXT atau PREVIOUS;
• Ketika pointer record diset, maka memungkinkan untuk memberikan aksi pada record ini, record berikutnya (kecuali jika pointer recordnya diset ke record terakhir) atau record sebelumnya (kecuali jika pointer recordnya diset ke record pertama);
• Dengan mengidentifikasi suatu record menggunakan pattern search;

Jika aksi memilih suatu record dibatalkan (e.g karena command gagal dieksekusi), maka pointer record tetap berada pada record sebelumnya ketika command select record tersebut belum dieksekusi.

Sekarang ini dapat dibuat sampai 254 records dalam file type ini. Dan tiap record tidak lebih besar dari 255 bytes.

8.2.2.3 Cyclic EF

Cyclic file digunakan untuk menyimpan records yang berurutan (chronological order). Ketika semua record telah digunakan untuk penyimpanan data, maka data berikutnya dapat simpan pada record yang lama sehingga record yang lama ini akan dioverwrite oleh data yang baru.
Suatu EF dengan cyclic structure terdiri dari sejumlah record dengan ukuran yang sama (fixed length). Pada file strukturnya terdapat link antara record terakhir dengan record pertama seperti terlihat pada gambar di bawah :

Ketika pointer record diset ke record n yang terakhir, maka record berikutnya adalah record nomor 1. Dengan cara yang sama, ketika pointer record diset ke nomor 1, maka record sebelumnya pasti adalah record n. Update terakhir record yang berisi data terbaru adalah record 1, dan data tertua dipegang pada record n.
Untuk operasi update, hanya record sebelumnya yang akan digunakan. Untuk operasi read, metode addressing yaitu Next, Previous, Current dan Record Number.
Jika aksi memilih suatu record dibatalkan (e.g karena commandnya gagal diekseskusi), maka pointer recordnya tetap berada pada record sebelumnya sebelum command aksi tersebut dieksekusi.
Sekarang ini dapat 254 records dalam file type ini, dan tiap record tidak lebih besar dari 254 bytes.
8.2.2.4 BER-TLV Structure EF
Struktur BER-TLV dari EF dilihat pada interface sebagai kumpulan data object yang dapat diakses oleh suatu command untuk menghandle data. Type dari object data pada EF adalan BER-TLC. Tag hanya dapat muncul sekali dalam EF ini.

8.3 File Referencing
File IDentifier (FID) digunakan untuk menemukan atau mengidentifikasi file tertentu. FID terdiri dari 2 bytes dan dikodekan dalam notasi hexadecimal.
FID harus memenuhi/tunduk pada aturan berikut :

• FID harus dibuat ketika suatu file pertama kali dibuatl;
• Tidak boleh ada 2 file dalam parent yang sama yang mempunyai FID yang sama;
• Cabang dari DF, parent DF atau cabang dari parent DF tidak boleh mempunyai FID yang sama.

Suatu path adalah penggabungan dari beberapa FID. Path berawal dari MF atau current DF, dan berakhir pada identifier dari filenya. Urutan FID selalu berarah dari father ke child.

Short File Identifier (SFI) disimbolkan dalam 5 bit dengan rentang nilai dari 1 sampai 30. Tidak boleh ada 2 file dalam parent yang sama yang mempunyai SFI yang sama. 

Nama dari DF dikodekan dari 1 sampai 16 bytes. Nama dari DF adalah AID dan harus unik dalam setiap card.

Cadangan FID '7FFF' dapat digunakan sebagai FID untuk ADF pada aplikasi yang aktif sekarang pada logical channel yang digunakan.

8.4 Methods for Selecting a File

Setelah proses aktivasi UICC dan proses Answer To Reset (ATR), Master File (MF) secara tidak langsung akan dipilih dan menjadi directory aktif saat ini. Setiap file dapat dipilih dengan menggunakan SELECT command, menggunakan 1 dari 3 metode file referencing yang didefinisikan dalam bab ini.
8.4.1 SELECT by File IDentifier Referencing
Memilih suatu DF, suatu ADF atau MF akan mengeset direktory yang aktif saat ini. Setelah suatu pemilihan EF akan hilang. Memilih suatu EF mengeset EF dan direktory sekarang tetap pada DF, ADF, atau MF yang merupakan parent dari EF ini. EF sekarang selalu menjadi child dari direktory saat ini. Hanya ADF dari aplikasi saat ini yang dapat dipilih menggunakan FID.
Suatu command aplikasi yang spesifik hanya dapat beroperasi pada suatu direktory yang spesifik pula. File-file dibawah dapat dipilih, oleh File IDentifier (FID), dari file yang terakhir dipilih :

• File yang merupakan child langsung dari direktory saat ini;
• DF yang merupakan child langsung dari parent DF saat ini;
• Parent dari direktory aktif saat ini;
• DF saat ini;
• ADF dari aplikasi yang aktif saat ini;
• MF

Gambar dibawah memberikan contoh dari struktur suatu aplikasi yang sesuai/tunduk dalam standar ini :

Tabel 8.1 dibawah memperlihatkan semua valid selection yang sesuai dalam standard ini untuk struktur logical pada gambar 8.4, jika FID digunakan. Reselection dari file terakhir yang dipilih juga diperboleh cuman tidak ditunjukkan. Pada contoh ini, aplikasi saat ini (ADF1) dianggap telah dipilih sebelumnya oleh DF name. Maka ADF1 dapa dipilih dengan menggunakan FID '7FFF'.

8.4.2 SELECT by Path Referencing
Suatu file, DF atau EF, dapat direferensi dengan path, seperti disebutkan pada 8.3. Table 8.2 dibawah berisi contoh-contoh dari selection by path dari gambar 8.4.

Pada contoh ini, applikasi saat ini (ADFI) dianggap telah dipilih sebelumnya oleh DF. Secara implisit FID dari ADF1 '7FFF' digunakan pada table 8.2 (lihat 8.3).
Dalam kasus 'select by path dari MF', terminal dapat menggunakan file-id '7FFF' (lihat 8.3) pada permulaan dari path. Ini menunjukkan bahwa path berawal dari ADF pada aplikasi yang aktif saat ini pada logical channel.
Terdapat beberapa batasan sebagai berikut :

• Dalam kasus 'select by path from MF', terminal tidak boleh menggunakan identitas file dari MF (contohnya '3F00') pada permulaan path.
• Dalam kasus 'select by path from current DF', terminal tidak boleh menggunakan file-ID '7FFF' pada permulaan path.
• Dalam kasus 'select by path from MF' atau 'select by path from current DF', terminal tidak boleh menggunakan identitas file dari DF yang sekarang.
• Dalam kasus 'select by path from MF' atau 'select by path from current DF', terminal tidak boleh menggunakan data yang kosong.

8.4.3 Short File Identifier (SFI)

EF apa saja yang terdapat dalam DF dapat secara implisit dipilih tanpa memberikan SELECT command dengan melakukan satu dari beberapa command di bawah pada DF atau ADF dan memberikan Short File Identifier (SFI) sebagai bagian dari command :

• READ BINARY;
• UPDATE BINARY;
• READ RECORD;
• UPDATE RECORD;
• INCREASE;
• SEARCH RECORD;
• RETRIEVE DATA; atau 
• SET DATA.

Support terhadap SFI untuk suatu file dapat terlihat jika FCP dari file berisi TLV Do dengan tag '88'. Jika panjangnya 0, berarti file tidak mendukung referensi dengan menggunakan SFI. Jika TLV DO tidak ada pada FCP, berarti 5 bit terakhir dari FID digunakan sebagai SFI.

Ketika READ RECORD command berisi SFI yang valid, command ini akan mengeset file sebagai EF sekarang dan mereset pointer record. Record berikutnya dibaca dengan READ RECORD command tanpa menggunakan SFI.

Ketika UPDATE RECORD command berisi SFI yang valid, command ini akan mengeset file menjadi EF sekarang dan mereset pointer record. Record berikutnya dapat diupate dengan UPDATE RECORD command tanpa menggunakan SFI.

Ketika INCREASE command berisi SFI yang valid, command ini akan mengeset file menjadi EF dan mereset pointer record. Record berikutnya dapat ditambah/dinaikkan dengan INCREASE command tanpa menggunakan SFI.

Ketika SEARCH RECOD command berisi SFI yang valid, command ini akan mengeset file menjadi sebagai EF dan mereset record pointer. Record berikutnya dapat dicari dengan SEARCH RECORD command tanpa menggunakan SFI.

Ketika RETRIEVE DATA command berisi SFI yang valid, command ini mengeset file menjadi EF dan mereset tag pointer yang sekarang digunakan. Jika segmentasi pada beberapa APDU digunakan untuk mengambil struktur yang panjang, RETRIEVE DATA command berikutnya dapat digunakan tanpa menggunakan SFI.

Ketika SET DATA command berisi SFI yang valid, command ini mengeset file sebagai EF dan mereset tag pointer yang sekarang. Jika segmentasi pada beberapa APDU digunakan untuk mengeset struktur yang panjang, SET DATA command berikutnya dapat digunakan tanpa menggunakan SFI.

8.5 Application Characteristics

Suatu aplikasi dapat direferensi secara explisit atau implisit. Suatu aplikasi dapat diaktivasi secara explisit dengan memilih AIDnya. Hal ini mengeset ADF aplikasi tersebut sebagai ADF sekarang. Current ADF dapat direferensi dengan FID dengan nilai implisist referensi '7FFF'.
8.5.1 Explicit Application Selection
8.5.1.1 SELECT by DF Name
Aplikasi yang dapat dipilih akan direpresentasikan sebagai UID dalam UICC dan akan diakses dengan nama DF yang dikodekan dalam 1 byte sampai 16 byte. Setiap nama harus unik dalam UICC. Nama DF dapat digunakan pada SELECT command untuk memilih aplikasi tersebut.
8.5.1.2 SELECT by Partial DF Name
Suatu aplikasi dapat pula dipilih dengan menggunakan sebagian dari nama DF (partial DF name) ketika P1 = '04' menggunakan parameter P2 first and only occurence, next, previous, atau last seperti didefinisikan pada ISO/IEC 7816-4. Pada kasus ini, DF name telah terpotong/sebagian saja. Jika terdapat beberapa aplikasi yang berawal dengan isi byte yang sama pada AID di card, maka aplikasi yang terpilih bergantung pada nilai pada P2. Jika "last" ditunjukkan pada P2, maka aplikasi yang terpilih adalah aplikasi terakhir yang aktif yang sama dengan partial DF name, meskipun hal tersebut berasal dari sesi card sebelumnya.
Pemilihan aplikasi menggunakan partial DF name ini sifatnya optional pada mono application card, tetapi seharusnya multi application dapat mensupport fitur ini. Kartu harus memperlihatkan bahwa fitur ini disupport pada "card service data" dan pada "card capabilities" di object compact-TLV pada historical di ATR seperti yang terdapat pada ISO/IEC 7816-4.
Penerjemahan dari next, previous, dan first akan dispesifikasikan oleh applikasi itu sendiri. Aplikasi yang dipilih menggunakan parameter ini akan saam dengan partial DF name yang disediakan pada SELECT command. Jika UICC tidak mendukung select aplikasi dengan partial DF name, maka UICC harus merespond dengan respon yang sesuai misalnya dengan parameter command not supported '6A86'.
8.5.2 Application Session Activation
Sesi suatu aplikasi diawali ketika terminal mengirimkan SELECT command, dengan AID aplikasi, yang menunjukkan bahwa aplikasi ini akan diaktivasi.
Suatu aplikasi mungkin butuh diinisalisasi dengan prosedur tertentu ketika aktivasinya selesai. Prosedur ini diluar ruang lingkup pada standard ini tetapi akan dijelaskan pada spesifikasi dari suatu aplikasi. Prosedur digunakan untuk membuat terminal dan aplikasi pada UICC ke state yang telah diketahui/disepakati bersama.
Setelah aplikasi tersebut dipilih, maka UICC akan mengevaluasi variabel-variabel security dari aplikasi tersebut. SE diset sesuai dengan persyaratan yang dibutuhkan untuk aplikasi ini, lihat table 9.1.
PIN verifikasi status dari aplikasi diupdate sesuai dengan prosedur sesi aktivasi aplikasi ini.
Terminal dapat mengirim STATUS command spesifik ke UICC yang menunjukkan prosedur inisialisasi dari aplikasi telah berhasil dilakukan.
Hanya boleh terdapat 1 aplikasi yang aktif untuk setiap logical channel. Oleh sebab itu, untuk mengaktifkan sesi aplikasi yang baru yang paralel dengan aplikasi yang lainnya, maka logical channel yang baru harus dibuat dulu.
Sesi aplikasi dapat terjadi beberapa kali pada beberapa sesi channel.
8.5.3 Application Session Termination
Suatu aplikasi dapat mempunyai prosedur tertentu sebelum aplikasi tersebut dihentikan. Prosedur tersebut akan disebutkan pada spesifikasi aplikasi tersebut. Sebelum prosedur itu dilakukan, terminal dapat mengirim spesifik STATUS command ke UICC yang menandakan bahwa prosedur untuk menghetikan aplikasi ini akan dimulai. Setelah prosedur penghetian tersebut selesai terminal dan aplikasinya berada pada state yang telah diketahui bersama.
Sesi aplikasi akan dihentikan jika beberapa event dibawah terjadi pada setiap logical channel dimana sesi aplikasi aktif :

• Secara implisit; jika SELECT command oleh DF name dengan AID berbeda dengan AID pada aplikasi yang saat ini aktif di UICC, yang ditunjukkan pada parameter command bahwa aplikasi baru ini akan diaktifkan.
• Secara Explisit; jika aplikasi dipilih kembali menggunakan SELECT dengan DF name command dengan AID yang sama dengan AID aplikasi yang aktif sekarang, dan ditunjukkan pada parameter command bahwa aplikasi ini akan ditutup; Direktory saat ini, current EF, dan aplikasi saat ini tetap sama setelah ATR pada logical channel menjadi nol.
• Jika logical channel ditutup.

Sesi suatu aplikasi juga akan dihentikan ketika terminal melakukan fungsi reset pada UICC.

PIN status verifikasi dari aplikasi diupdate sesuai dengan prosedure penutupan dari sesi aplikasinya sebagaimana ditetapkan dalam aplikasi.

8.5.4 Application Session Reset

Suatu aplikasi akan tereset jika aplikasi tersebut dipilih kembali menggunakan SELECT by DF name command dengan AID yang sama dengan AID aplikasi yang aktif saat ini. Reset tersebut memulai prosedur aktivasi dari sesi suatu aplikasi. Status security dari aplikasi ini diupdate sesuai dengan prosedure aktivasi dari sesi aplikasi yang bersangkutan.

8.6 Reservation of File IDs
FID dibawah adalah FID cadangan sesuai dengan standard ini.

• ADF :
• Penggunaan operational (implicit FID untuk current ADF) :
• '7FFF'
• Dedicated Files (DF):
• Penggunaan administrative :
• '7F4X', '5F1X', '5F2X'.
• Penggunaan operational :

catatan :

• Reserved under '7F10' :

• Elementary Files (EF) :
• Penggunaan administrative :
• '6F XX' pada DFs '7F 4X'; '4F XX' pada DFs '5F 1X', '5F2X'.
• '6F 1X' pada DFs '7F 10', '7F 20', '7F 21';
• '4F 1X' pada semua level kedua dari DFs;
• '2F EX' pada MF '3F 00'.
• Penggunaan operational :
• '6F 2X', '6F 3X', '6F 4X' pada '7F 10' dan '7F 2X';
• '4F YX', dimana Y dapat bernilai dari '2' sampai 'F' pada semua level kedua DFs;
• '2F 05', '2F 06' dan '2F 1X' pada MF '3F 00'.
• Penggunaan operational di ISO/IEC 7816-4 :

Catatan : rentang nilai X yaitu dari '0' sampai 'F', kecuali disebutkan yang lain.

8.7 Logical Channels
Logical channel didefinisikan pada ISO/IEC 7816-4. Standar ini mendukung nilai interindustri pertama (i.e CLA dikodekan pada table 10.3) dan interindustri berikutnya (CLA dikodekan pada `0.4a) seperti yang disebutkan pada ISO/IEC 7816-4, yang mendukung sampai 19 logical channel selain basic channel 0. Channel 0 selalu ada dan selalu terbukan untuk semua sesi card.
UICC yang mendukung beberapa logical channel menunjukkan hal ini pada ATRnya, bersaam dengan metode dan maksimum jumlah logical channel yang dapat disupport. UICC yang mendukung beberapa logical channel akan mendukung :

• Paling tidak satu channel selain basic channel; dan
• Nomor logical channel yang ditetapkan oleh UICC.

Command interpendencies pada satu logical channel sifatnya independent dari command interindependencies pada logical channel yang lain.

Tidak ada interleaving command dan responnya antar logical channel; antara penerimaan command APDU tersebut dan pengiriman respon APDU ke command tersebut, hanya satu logical channel yang aktif.

Agar dapat diakses dari beberapa logical channel pada saat bersamaan, file (EF, DF, ADF) akan ditunjukkan sebagai "shareable" pada file descriptornya.

Aplikasi bertanggung jawab untuk menjaga konsistensi data (pada card dan terminal) ketika mengakses file yang sama dengan logical channel yang berbeda.

Note : Perlakuan khusus harus diberikan ke cyclic files, contohnya ketika file dibaca dengan satu channel dan diupdate dengan channel berbeda yang lain.

Logical channel dibuka dengan menggunakan MANAGE CHANNEL command, dimana card menentukan nomor channel dan mengembalikannya pada respon.

Logical channel tetap terbuka sampai dia secara explisit ditutup dengan MANAGE CHANNEL command, atau jika UICC dideaktivasi.

Ketika open funcation dieksekusi pada basic channel dan eksekusinya berhasil, MF secara implisit dipilih sebagai current DF. Ketika open function dieksekusi pada logical channel yang bukan merupakan basic channel, maka setelah eksekusinya berhasil, current DF dari logical channel dimana command dieksekusi akan dipilih sebagai current DF. Dalam kedua kasus, tidak ada current DF dipilih pada logical channel yang baru.

Ketika chanel baru terbuka, maka current DF dan current EF bersifat independent untuk tiap logical channel.
Jika MANAGE CHANNEL command dieksekusi pada suatu DF atau ADF yang tidak shareable, maka card akan merespon dengan error message yang sesuai. Respon tersebut harus menunjukkan bahwa command ini tidak diperbolehkan dan tidak ada chanel baru yang terbuka.

8.8 Shareable versus not-Shareable Files

Suatu file (dapat berupa EF, DF, atau ADF) dapat diakses (selected, read, updated, deleted, deactivated, activated, incrased, searched, etc) dengan beberapa aplikasi yang berbeda yaitu :

• Melalui aplikasi pada terminal dengan logical chanel yang berbeda
• Melalui aplikasi pada UICC seperti remote file management dan toolkit applications.

Keluaran dari akses tersebut ditentukan oleh shareable/not-shareable bit pada byte deskripsi file pada FCP yang filenya diakses adalah sebagai berikut :

• Jika file ditunjukkan sebagai shareable, maka aplikasi dapat melakukan operasi autentikasi pada file tanpa memperhatikan apakah file tersebut merupakan file dari aplikasi lain atau tidak.
• Jika file ditunjukkan sebagai not-shareable dan merupakan current file dari suatu aplikasi, maka aplikasi yang lain tidak dapat melakukan operasi-operasi pada file ini termasuk operasi autentikasi

Akibat dari aturan pertama adalah jika terjadi perubahan pada shareable file diperbolehkan kondisi security dari file, maka file dapat diubah oleh suatu aplikasi sekalipun file tersebut sedang dipilih dan menjadi current file dari aplikasi yang lain. Deskripsi dari masing-masing command termasuk dalam detail informasi interasiknya terdapat dalam shareable case.

Akibat dari aturan kedua adalah suatu aplikasi butuh akses exclusive pada not-shareable file jika ingin memilih file tersebut. Akses dari aplikasi lain, termasuk upaya untuk memberikan SELECT command pada file tersebut akan mendapatkan status word '6985' (Conditions of use not satisfied).

Untuk saat ini, akses pada suatu file dengan 2 instances dari satu aplikasi dianggap sebagai akses dari 2 aplikasi yang berbeda.

Untuk shareable files, akses file diatur secara independent untuk setiap akses dari suatu aplikasi. Pada prinsipnya, struktur record-based file dan BER-TLV akan mempunyai pointer yang berbeda untuk setiap akses dari suatu aplikasi.

8.9 Secure Channels

Secure channel dijelaskan lebih detail pada 102 484. Terdapat 2 type APDU yang berdasarkan pada secure channel yaitu : Application to Application APDU secure channels dan Platform to Platform APDU secure channels.
Support kepada secure channels ditunjukkan pada ATR dan FCP tempelate.
Secure channel adalah logical channel dengan versi yang telah secure. Secure channel dibuat ketika pembukaan suatu logical channel, dan kemudian menggunakan MANAGE SECURE CHANNEL command untuk membuat logical channel tersebut menjadi secure. Logical channel 0 tidak dapat dijadikan secure channel untuk Application to Application secure channel.
Platform to Platform APDU secure channel dapat digunakan pada logical channel 0. Penggunaan logical channel yang lain juga diperbolehkan untuk Platform to Platform secure channel. Semua command selain MANAGE SECURE CHANNEL, TRANSACT DATA, dan GET RESPONSE dapat dibuat secure menggunakan Platform to Platform secure channel, termasuk proactive commands.

7. Transmission Protocols - 102 221 v8

Berikut akan diterjemahkan/diedit sebagian standard ETSI TS 102 221 v8 untuk bab 7 saja. Ummm...mungkin +Pena Hijau  mau berbaik hati untuk ikut membatu menerjemahkan hehhee.... :D,

Ok....Beberapa istilah yang perlu diketahui sebelum melangkah lebih jauh :

• Terminal = handphone
• UICC =  simcard
• PPS = Protocol and Parameter Selection
• ATR = Answer To Reset
• IFSC = Information Field Size for the UICC
• IFSD = Information Field Size for the terminal
• NAD = Node ADress byte
• PCB = Protocol Control Byte
• INF = INFormation field
• EDC = Error Detection Code byte
• DAD = Destination ADdress
• SAD = Source ADdress
• CAT =

Bab 7 ini menjelaskan tentang transmisi protocol yang digunakan selama proses komunikasi data antara terminal dan UICC. Akan dijelaskan pula struktur dan pemrosesan perintah yang diinisialisi oleh terminal untuk transmission control dan spesific control pada transmisi protocol dengan mode asynchronous half dulplex. 

Ada dua jenis protocol yang akan dijelaskan, yaitu character based protocol T = 0 dan block based protocol T = 1.

Kedua jenis protocol ini, T=0 dan T=1, sifatnya mandatory untuk terminal. UICC harus dapat mendukung salah satu atau kedua dari protocol T=0 dan T=1 tersebut.

Penggunaan protocol ini akan dimulai setelah ATR atau PSS telah sukses dilaksanakan.

Protocol ini menggunakan konsep layer OSI, setidaknya ada 4 layer yaitu:

1. Physical layer. Definisi yang terkandung valid untuk T=0 dan T=1
2. Data link layer, yang terdiri dari
1. komponen character
2. komponen block
3. identifikasi block
4. pengiriman block
5. deteksi transmisi dan pengecekan error
6. handle errors
7. protokol synchronize
3. Transport layer, yang mendefinisikan transmisi pesan application-oriented yang sifatnya spesifik untuk tiap protocol.
4. Application layer, yang mendefinisikan pergantian pesan yang sesuai untuk setiap protokol aplikasi

Ilustrasinya seperti terlihat di bawah :

7.1 Physical Layer

Protocol T=0 dan T=1 akan menggunakan physical layer dan character frame seperti yang akan disebutkan pada subbab 7.2.1

7.2 Data Link Layer

Subbab ini menjelaskan tentang timing, specific option dan error handling untuk protocol T=0 dan T=1.

7.2.1 Character Frame

Karakter yang dikirimkan melalui I/O line dimasukkan pada character frame. Sebelum transmisi dari suatu karakter, I/O line akan berada pada state H. Berdasarkna kesepakatan yang digunakan, logika '1' pada karakter dapat direpresentasikan oleh state H pada I/O line (direct convention) atau state L pada I/O line (inverse convention).

Setiap karakter terdiri dari 10 bit, yaitu :

• 1 buah start bit pada state L
• 8 bit yang merupakan data byte
• 1 bit untuk even parity checking

Parity bit diset dengan suatu cara sehingga jumlah bit 1 pada karakter frame menjadi genap. Waktu awal ditetapkan diantara akhir state H dan awal dari state L, penerima harus dapat memastikan keberadaan start bit sebelum 0,7 etu(receiver time). Kemudian bit berikutnya akan diterima pada interval (n+0,5 +-0,2)etu (n adalah nomor bit). Start bit adalah 1. 

Dalam suatu karakter, waktu dari leading edge untuk start bit sampai trailing edge untuk bit yang ke-n adalah (n+-0,2)etu. Periode antara leading edge dari start bit dari 2 karakter yaitu (10+-0,2)etu, ditambah guardtime. Dalam kasus transmisi yang tidak ada error, selama guardtime, UICC dan terminal akan berada pada reception mode (baik itu I/O line pada state H), kecuali disebutkan kasus yang lain.

Data pertama yang dikirimkan melalu I/O line adalah most significant byte. Urutan bit dalam byte (apakah LSB atau MSB yang dikirimkan pertama kali) diterangkan lebih lanjut pada character TS yang dikembalikan pada ATR seperti yang terdapat pada ISO/IEC 7816-3.

7.2.1.1 Low Impedance I/O Line Behaviour

Jika low impedance pada I/O line telah dipilih, sebagai hasil dari PPS exchange yang sukses, protocol yang dijelaskan pada subbab ini akan berlaku.

State transmisi didefinisikan sebagai awal periode dari bit pertama dari karakter pertama sampai akhir pada guardtime dari karakter terakhir yang dikirim. Selama state transmisi, pengirim akan mengatur I/O line pada level yang sesuai menggunakan pengatur low impedance, kecuali periode error indication, contohnya karakter guardtime dari T = 0.

Setelah penerimaan karakter terakhir dari suatu command atau response ketika arah komunikasi berubah, pihak yang mempunyai giliran untuk transmit data (terminal atau UICC) harus dapat mengatur I/O line ke level yang lebih tinggi menggunakan low impedance driver selama periode inteface inactivity. Selama periode clock stop, terminal akan mengatur I/O line ke state yang lebih tinggi lagi.

Periode interface inacitivity  berakhir ketika pengiriman command yang baru telah dimulai atau response command tersebut telah dimulai.

7.2.2 Transmission protocol T=0

T=0 adalah karakter half-duplex asynchronous yang berdasarkan transmission procotol. Semua commands yang menggunakan protocol T=0 diawali dari terminal yang mengirimkan 5 byte header, yang menginformasikan UICC apa yang harus dilakukan. Terminal akan selalu bertindak sebagai master dan UICC akan selalu bertindak sebagai slave. Arah transmisi data dianggap telah diketahui oleh masing-masing UICC dan terminal.

7.2.2.1 Timing and Specific Options for Characters in T = 0

Interval minimum antara leading edge dari start bit dari dua karakter yang berurutan paling tidak adalah 12 etu. Interval maksimum antara start leading edge dari suatu karakter yang dikirim oleh UICC dan start leading edge dari karakter sebelumnya yang dikirim baik oleh UICC ataupun terminal adalah WWT. Nilai dari WWT tidak boleh melebihi 960xWIxFi/f. WI adalah bilangan yang diterima pada specific interface byte pada TC2. Jika tidak ada TC2, nilai default dari WI adalah 10. Faktor konversi clock rate, Fi, dan faktor konversi baud rate, Di, dapat/mungkin ditunjukkan pada TA1. Jika TA1 tidak ada maka nilai default yang digunakan adalah 372 dan 1 masing-masing digunakan. Jika nilai WWT telah dilewati, terminal harus mengawali proses deaktivasi dalam 960 etu.

7.2.2.2 Command Header

Command akan selalu diawali oleh terminal yang mengirimkan suatu instruksi ke UICC dalam bentuk 5 byte header yang disebut command header. Command header terdiri dari 5 byte, CLA, INS, P1, P2, dan P3. Byte-byte tersebut dengan datanya dikirimkan dalam bentuk Command-Transport Protocol Data Unit (C-TPDU) untuk T=0. Pemetaan C-APDU ke C-TPDU akan dijelaskan pada sub 7.3. Jika terminal mengirimkan header ke UICC, maka dia akan menunggu procedure byte atau status byte.

7.2.2.3 Command Processing

Ketika UICC telah menerima command header, respond yang berisi procedure byte atau status byte akan dikirimkan ke terminal. Terminal dan UICC dapat menjaga track dari data flow dan siapa yang dapat mengakses I/O-line.

7.2.2.3.1 Procedure Bytes

Procedure byte menunjukkan aksi apa berikutnya yang akan dilakukan oleh terminal. Procedure bytes digunakan untuk menjaga komunikasi antara terminal dan UICC. Procedure bytes ini tidak boleh dikirimkan ke application layer. Koding dari procedure byte dan aksi yang dilakukan oleh terminal ditunjukkan pada tabel 7.1 di bawah :

Setelah aksi tersebut dilakukan, terminal akan menunggu procedure byte atau status word berikutnya.

7.2.2.3.2 Statys Bytes

Status bytes, SW1 SW2, membentuk suatu end sequence yang menunjukkan kondisi dari UICC pada state akhir dari suatu command. Secara normal, akhir dari suatu command ditunjukkan dengan SW1 SW2 = '90 00' (bilangan hex).

7.2.2.4 Error Detection and Correction

Prosedur error detection and correction sifatnya mandatory untuk protocol T=0 kecuali jika terminal berada pada proses ATR. Suatu error, dilihat dari sisi penerima, didefinisikan sebagai parity yang salah. Error ditunjukkan pada I/O line, yang di set ke state L pada (10,5+-0,2)etu setelah leading edge dari start bit untuk setiap karakter. I/O line akan berada pada state L dengan durasi maksimum 2 etu dan minimum 1 etu. Pengirim akan mengecek I/O line untuk indikasi parity error pada (11+-0,2)etu yang berawal dari leading edge dari bit pertama pada karakter yang sedang dikirimkan.

Jika UICC atau terminal yang bertindak sebagai penerima mendeteksi adanya parity error pada karakter yang diterima, maka dia akan mengeset I/O line ke state L pada (10,5+-0,2)etu setelah leading edge dari bit pertama pada suatu karakter selama maksimum 2 etu untuk menunjukkan adanya error ke pengirim data (lihat gambar 7.2). Jika pengirim mendeteksi suatu error yang ditunjukkan pada (11+-0,2)etu yang berawal dari leading edge di bit pertama pada suatu karakter yang sedang dikirim, maka karakter tersebut harus dikirimkan kembali setelah minium delay 2 etu.

7.2.3 Transmission Protocol T = 1

Protocol T=1 adalah protocol transmisi dengan sifat half-duplex asynchronous block. Protocol tersebut dapat diawali dengan kondisi sebagai berikut :

• Setelah proses ATR karena cold reset
• Setelah proses ATR karena warm reset
• Setelah berhasil melakukan proses PSS

Komunikasi akan dimulai ketika suatu block yang dikirimkan oleh terminal ke UICC. Pihak yang mengirimkan data berselang-seling antara terminal dan UICC. Block adalah unit data terkecil yang dapat dikirim dan dapat berisi data aplikasi atau transmission control. Pengecekan terhadapat data yang diterima dapat dilakukan sebelum data berikutnya diterima.
7.2.3.1 Timing and Specific Options for Blocks Sent with T = 1

Pada sub bab ini akan dijelaskan pilihan yang berhubungan dengan waktu, ukuran field informasi dan parameter deteksi error untuk suatu blok yang dikirimkan dengan protocol T = 1.
7.2.3.1.1 Information Field Size

IFSC mendefinisikan panjang maksimum field informasi yang terdapat dalam suatu block yang dapat diterima oleh UICC. Nilai default dari IFSC adalah 32 bytes, nilai yang lain dapat ditunjukkan pada TA3 dari ATR. IFSC juga mendefinisikan panjang maksimum field informasi dalam suatu block yang dapat diterima oleh terminal. IFSD mempunyai nilai default 32 bytes juga untuk terminal dan dapat diubah selama suatu sesi card masih berlangsung. Nilai maksimumnya adalah 254 bytes.
7.2.3.1.2 Character Waiting Integer

Character Waiting Integer (CWI) digunakan untuk menghitung Character Waiting Time (CWT). CWI berkisar antara 0 sampai 5. Nilainya diset pada bit ke b4 sampai b1 pada TB3.
7.2.3.1.3 Character Waiting Time

CWT menunjukkan maksimum delay pada leading edges di 2 karakter berurutan dalam suatu block seperti ditunjukkan pada gambar 7.3 di bawah :

Nilai dari CWT dapat dihitung dari persamaan: CWT = (11+2^CWI)etu. 

7.2.3.1.4 Block Waiting Time

BWT didefinisikan sebagai maksimum delay antara leading edge dari karakter terakhir pada suatu block yang diterima oleh card dengan leading edge karakter pertama pada block berikutnya yang dikirim oleh card. Ilustrasi seperti terlihat :

BTW ini juga digunakan untuk mendeteksi card yang tidak responsive.
7.2.3.1.5 Block Guard Time

BGT didefinisikan sebagai delay minimum antara leading edge dari 2 karakter berurutan yang dikirim dengan arah yang berlawanan. Nilai BGT harus 22 etu.

Delay antara karakter terakhir dari suatu block yang diterima UICC dengan karakter pertama pada block berikutnya yang dikirim oleh UICC harus berada dalam interval :

• BGT < delay < BWT

7.2.3.1.6 Waiting Time Extension

WTX adalah parameter yang digunakan untuk meminta tambahan waktu untuk memproses suatu command.
7.2.3.1.7 Error Detection Code
Parameter TCi pada ATR digunakan untuk mendefinisikan error deteksi yang mana yang akan digunakan. LRC harus digunakan (b1 = 0). Semua bit pada TCi adalah RFU dan akan diset ke 0.
7.2.3.2 Block Frame Structure
Suatu protocol terdiri dari beberapa block, yang dikirimkan antara terminal dan UICC. Setiap block mempunyai struktur seperti yang terlihat di bawah :

Prologue field dan epilogue field sifatnya mandatory, sedangkan information field optional.

7.2.3.2.1 Prologue Field
Prologue field dibagi menjadi 3 bagian mandatory yaitu :

• Node ADress byte (NAD), 1 byte;
• Protocol Control Byte (PCB), 1 byte;
• Length (LEN), 1 byte;

7.2.3.2.1.1 Node Address Byte

NAD menunjukkan sumber dan tujuan dari suatu block. NAD dapat pula digunakan untuk membedakan beberapa logical connection jika memang terdapat beberapa logical channel. NAD juga dapat digunakan untuk menyediakan Vpp control state (bit b8 dan b4). Karena b8 dan b4 tidak digunakan, maka kedua bit tersebut harus diset ke 0. Struktur NAD seperti terlihat pada gambar di bawah :

Pada block pertama yang dikirim terminal, logical connection dibuat berdasarkan pengalamatan di SAD dan DAD. Block berikutnya dalam NAD yang berisi pasangan address yang sama mempunyai logical connection yang sama pula. Hanya nilai default SAD = DAD = 0 yang disupport. Kombinasi yang lain adalah RFU.
7.2.3.2.1.2 Protocol Control Byte
Semua informasi yang dibutuhkan mengontrol transmisi dikirimkan pada Protocol Control Byte (PCB). Koding dari PCB menspesifikasikan type dari setiap block. Pada protocol T=1, terdapat 2 jenis block yang disupport, yaitu :

• Information block (I-block): digunakan untuk mengirimkan command dan respon APDU;
• Receive-ready block(R-block): digunakan untuk mengirimkan ACK
• Supervisory block(S-block): digunakan untuk mengirimkan control information

Tabel 7.4 sampai 7.9 dibawah memperlihatkan format dari PCB untuk setiap tipe-tipe block yang dimulai dari I-block.

Bit b6 menunjukkan apakah block ini berupa request (b6=0) atau response (b6=1).

7.2.3.2.1.3 Length

Byte length menunjukkan jumlah byte pada field information dari suatu block. Jumlah byte dapat berkisar antara 0 byte sampai 254 byte, tergantung dari type blocknya. Nilai LEN = '00' menunjukkan bahwa field information tidak ada dan nilai 'FF' adalah RFU.
7.2.3.2.1.4 Information Field
Information field, INF, sifatnya optional dan tergantung pada type block dimana field akan digunakan.

7.2.3.2.2 Epilogue Field
Epilogue field berisi byte Error Detection Code (EDC). EDC ini digunakan untuk mengirimkan deteksi error dari block yang telah dikirimkan. LRC yang didefinisikan pada ISO/IEC 7816 harus digunakan.
7.2.3.2.3 Block Notations
7.2.3.2.3.1 I-block
I-blocks dinyatakan sebagai : I(N(S),M) dimana :

• N(S) adalah nomor send-sequence dari block
• M adalah mode-data yang digunakan pada chaining function

7.2.3.2.3.2 R-block

R-block dinyatakan sebagai : R(N(R)), dimana :

• N(R) adalah jumlah I-block yang harapkan

7.2.3.2.3.3 S-block

S-block selalu digunakan secara berpasangan. S(request) selalu diikuti oleh S(response) block. S-block dinyatakan sebagai berikut:

• S(RESYNCH request), digunakan untuk permintaan resynchronization
• S(RESYNCH response), digunakan untuk memberikan ACK resynchronization
• S(IFS request), digunakan untuk menawarkan ukuran maksimum dari information field
• S(IFS response), digunakan untuk memberikan ACK pada information field
• S(ABORT request), digunakan untuk permintaan pembatalan dari chain function
• S(ABORT response), sebagai ACK dari S(ABORT request)
• S(WTX request), digunakan untuk permintaan penambahan waktu dari waiting time
• S(WTX response), digunakan sebagai ACK untuk S(WTX request)

7.2.3.3 Error Free Operation

Aturan dibawah menjelaskan tentang operasi error free dengan T = 1.

• Block pertama yang dikirim ke UICC harus merupaka I-block dengan N(S)=0 atau S-block.
• Jika pengirim S mengirimkan I(Ns(S),0), block tersebut diberikan ACK oleh receiver R dengan I(Nr(S),M). Isi dari I(Nr(S)) menunjukkan transfer data dan penerima telah siap untuk menerima block selanjutnya dari pengirim.
• Jika pengirim S mengirim I(Ns(S),1), block tersebut harus diberikan ACK oleh penerima dengan R(Nr(R)), dimana Ns(S) != Nr(R), untuk menunjukkan bahwa block yang diterima telah benar dan penerima telah siap untuk menerima block berikutnya.
• UICC dapat menggunakan lebih dari BWT untuk memproses block sebelumnya yang diterima, yaitu dengan mengirimkan S(WTX request). Kemudian terminal memberikan ACK dengan S(WTX response). Periode waktu yang baru ini dimulai dari leading edge dari karakter terakhir pada S(WTX response).
• Untuk mengganti nilai IFSD, terminal mengirimkan S(IFS request). Request tersebut akan di ACK oleh UICC dengan S(IFS response) dengan INF yang sama. IFSD yang baru ini dianggap valid selama tidak ada S(IFS request) yang diterima oleh UICC.
• Ketika penerima telah menerima sejumlah karakter seperti ditunjukkan pada LEN dan EDC, maka kini giliran penerima untuk mengirimkan block data selanjutnya.

7.2.3.4 Error Handling untuk T = 1

Komponen block dari data link layer dapat mengatasi error seperti :

• BWT time-out;
• Menerima block data yang tidak valid, contohnya block dengan parity errors, EDC errors, invalid PCB, invalid length, kehilangan sinkronisasi atau gagal menerima S(... response) setelah mengirimkan S(... request).

Resinkronisasi dari protocol dapat dilakukan dengan 3 level. Jika satu level tidak berhasil, maka dapat digunakan level berikutnya.

• Untuk terminal, 3 level tersebut adalah :
• Retransmisi blocks
• Penggunaan S(RESYNCH request)
• Card reset atau deactivation
• Untuk UICC, 3 level tersebut adalah
• Retransmisi blocks
• Penggunaan S(RESYNCH response)
• Tanpa aktivitas/aksi dari terminal, UICC menjadi tidak responsif

7.2.3.4.1 Protocol Initialization

Setelah proses ATR karena warm reset atau prosedur PPS yang berhasil, komunikasi antara terminal dan UICC dapat dilakukan kembali. Tetapi jika terminal gagal menerima block yang error-free, pada permulaan prosedur protokol, maka boleh dilakukan 2 kali usaha berikutnya dalam menerima block yang error-free sebelum UICC tersebut direset kembali atau dideactive.
Jika respond block pertama yang dikirim terminal tidak dikirim dalam BTW, terminal harus mengirim sebuah R(0).
Ketika protokol telah diinisialisasi dan block pertama yang diterima oleh UICC tidak valid, UICC memberikan respond dengan R(0).
Jika terminal gagal untuk menerima block yang error-free selama card-session, maka boleh melakukan 2 usaha lagi dalam hal penerimaan block error-free sebelum S(RESYNCH request) dikirim.
7.2.3.4.2 Block Dependent Errors
Ketika sebuah I-block telah dikirim dan terjadi BWT time-out atau invalid block telah diterima (oleh terminal), sebuah R-block dikirim, dengan meminta N(R)nya untuk I-block yang diharapkan dengan N(S)=N(R).
Ketika R-block telah dikirim dan invalid block diterima atau BWT time-out, maka R-block harus dikirimkan kembali.
Ketika sebuah S(... request) telah dikirim dan terjadi BWT time-out atau response yang diterima bukan S(... response), maka S(... request) tadi harus dikirimkan kembali. Tetapi jika S(... response) telah dikirim dan terjadi BWT time-out atau invalid block diterima oleh terminal, maka R-block yang dikirim. Terminal tidak boleh mengirim S(IFS request) sebelum R-block meng-ACK penerimaan I-block sebelumnya dikirim oleh card.
Ketika UICC mengirimkan S(IFS request) dan menerima block yang invalid, S(IFS request) harus dikirim kembali (sekali saja dalam extra time) untuk menerima S(IFS response). Setelah gagal dua kali untuk menerima S(IFS response), UICC harus tetap berada dalam reception mode.
7.2.3.5 Chaining
Chaining memungkinkan terminal atau UICC untuk mengirimkan data/informasi yang lebih besar dari IFSC atau IFSD. Jika informasi yang lebih besar dari IFSC atau IFSD dikirimkan, maka informasi tersebut harus dibagi dalam beberapa bagian, setiap bagian mempunyai panjang <= IFSC atau IFSD. Setiap bagian harus dikirim dalam I-block menggunakan chaining function.
Nilai M-bit pada PCB di I-block mengontrol chaining function sesuai dengan :

• M = 0, block yang sekarang tidak terhubung(chained) dengan block berikutnya
• M = 1, block yang sekarang terhubung dengan block berikutnya

Ketika penerima menrima lebih banyak I-block, R(N(R)) harus dikirim. N(R) = N(S) dari I-block yang diharapkan. Paling tidak ada satu block berantai yang mengikuti.

Suatu physical error, contonya kelebihan buffer, pada UICC dapat menyebabkan error pada proses chaining ini. Untuk membatalkan proses chaining, S(ABORT request) dapat dikirim oleh transmitter atau receiver. Request tersebut harus dijawab dengan S(ABORT response). ketika S(ABORT response) telah diterima, R-block dapat dikirim oleh terminal ataupun UICC untuk memberikan giliran siapa berikutnya yang akan mengirim data.

7.2.3.5.1 Aturan Chaining 

• Ketika terminal bertindak sebagai penerima, terminal akan menerima rangkaian I-block yang dikirim dari UICC. Panjang setiap block tersebut adalah <= IFSD.
• Ketika UICC bertindak sebagai penerima, UICC akan menerima rangkain I-block yang dikirim dari terminal. Panjang tiap block harus sama dengan IFSC kecuali block terakhir yang mempunyai panjang antara 0 sampai IFSC.
• Ketika terminal bertindak sebagai pengirim, semua I-block yang sifatnya chained harus mempunya panjang LEN=IFSC bytes kecuali I-block yang terakhir yang dapat mempunyai panjang antara 0 sampai IFSC.
• Ketika UICC bertindak sebagai pengirim, semua chained I-block harus mempunyai panjang LEN <= IFSD byte untuk setiap block.
• Ketika UICC yang bertindak sebagai penerima dan menerima block dengan LEN > IFSC, maka block tersebut harus dibuang dan di-ACK dengan R-blcok dengan bit b1 sampai b4 yang mempunyai nilai 2 pada PCB.

Untuk alasan efisiensi, tidak dianjurkan untuk mengirim I-block yang kosong.

7.3 Transport Layer

Pada bagian ini akan dijelaskan tentang bagaimana APDu dikirimkan antara terminal dan UICC.
7.3.1 Transport of an APDU using T = 0
Berikut akan dijelaskan tentang mapping C-APDU ke R-APDU untuk protokol T = 0, pertukaran APDU dan penggunaan dari GET RESPONSE command untuk kasus 2 dan kasus 4.
7.3.1.1 Mapping of APDUs to TPDUs
Mapping C-APDU ke header command T=0 bergantung kepada kasus command tersebut. Mapping data (jika ada) dan status yang dikembalikan oleh UICC atas R-APDU juga tergantung pada panjang data yang dikembalikan.
Procedure bytes '61XX' dan '6CXX' dikembalikan oleh UICC untuk mengontrol pertukaran data antara transport layer pada terminal dan UICC dan sebaiknya tidak pernah dikirimkan ke application layer dari terminal. Pemroresan command pada UICC tidak sempurna jika dia telah mengembalikan procedure bytes '61XX' atau '6CXX'.
Status normal pada penyelesaian suatu command ditandai dengan UICC yang mengembalikan status words '9000' ke transport layer terminal. Transport layer terminal tidak akan melanjutkan suatu command (sebagai contoh melewatkan R-APDU ke application layer dan menunggu C-APDU dari application layer) pada penerimaan suatu status words (tetapi tidak pada penerimaan procedure bytes '61XX' atau '6CXX') dari UICC. Dalam kasus 4 command, segera setelah diikuti transmisi command data yang sukses ke UICC, transport layer dari terminal akan melanjutkan pemroresan command jika warning status bytes ('62XX' atau '63XX') atau status byte yang berhubungan dengan applikasi ('9XXX' kecuali '9000') diterima.
Mapping data di bawah dan status yang dikembalikan UICC atas R-APDU adalah untuk informasi dan hanya berlaku setelah UICC menyelesaikan pemroresan dari command, sukses atau tidak, dan semua data (jika ada) telah dikembalikan oleh UICC dalam kontrol procedure bytes '61XX' dan '6CXX'. Informasi lebih detail untuk penggunaan procedure bytes INS, __INS, dan '60' tidak dijelaskan.
Status yang dikembalikan oleh UICC harus berhubungan dengan command yang terbaru yang diterima saat ini. Dalam hal GET RESPONSE yang digunakan untuk menyelesaikan pemroresan command untuk kasus 2 atau kasus 4, status yang dikembalikan oleh UICC setelah menerima GET RESPONSE harus berhubungan dengan perintah GET RESPONSE, bukan dalam kasus 2 atau 4 dimana dia diselesaikan.
7.3.1.1.1 Case 1
C-APDU dimapping ke C-TPDU dengan memasukkan nilai '00' ke bagian body (P3='00').

Alurnya sebagai berikut :

• Transport layer terminal mengirimkan T = 0 command header ke UICC.
• Pada penerimaan command header tersebut pada UICC, dalam kasus pemroresasn normal atau abnormal, UICC akan mengembalikan status ke transport layer terminal. UICC akan menganilisa T = 0 command header untuk menentukan apakah pemroresannya termasuk dalam kasus 1 atau kasus 2 yang meminta semua data sampai panjang maksimum yang tersedia.
• Pada penerimaan status dari UICC, transport layer terminal tidak akan melanjutkan pemroresan dari command tersebut.

Lihat lampiran C untuk informasi lebih detail pada pertukaran data antara transport layer pada terminal dan UICC.

Status word yang dikembalikan ke transport layer terminal dari UICC setelah penyelsaian dari suatu command dipetakan ke mandatory trailoer R-APDU tanpa perubahan apapun.

7.3.1.1.2 Case 2

C-APDU dipetakan ke C-TPDU tanpa perubahan apapun.

Alurnya sebagai berikut :

1. Transport layer terminal akan mengirim T = 0 command header ke UICC.
2. Pada penerimaan command header di UICC:
1. Pada pemroresan normal akan mengembalikan data dan satus ke transport layer termianl. UICC akan menggunakan procedure bytes '6CXX' (dan jika dibutuhkan, procedure bytes '61XX') untuk mengontrol data yang dikembalikan (lihat di bawah); atau
2. Pada pemroresan abnormal, UICC hanya akan mengembalikan status saja ke transport layer terminal
3. Pada penerimaan data (jika ada) dan status dari UICC, transport layer terminal akan menghentikan pemroresan dari command tersebut.

Lihat lampiran C untuk informasi lebih detail tentang pertukaran data antara transport layer terminal dan UICC, termasuk penggunaan procedure bytes '61XX' dan '6CXX'.

R-TPDU dipetakan pada R-APDU tanpa perubahan apapun.

Data (jika ada) dan status yang dikembalikan ke transport layer terminal dari UICC setelah selesainya pemroresan suatu command dipetakan ke R-APDU dengan cara sebagai berikut :

• Data yang dikembalikan (jika ada) dipetakan ke conditional body dari R-APDU. Jika tidak ada yang dikembalikan, conditional body dari R-APDU dibiarkan kosong saja.
• Status yang dikembalikan dipetakan ke mandatory trailer pada R-APDU tanpa perubahan apapun.

7.3.1.1.3 Case 3

C-APDU dipetakan ke C-TPDU tanpa perubahan apapun. Lc adalah suatu nilai antara 1 sampai 255.

Alurnya sebagai berikut :

1. Transport layer terminal akan mengirimkan T = 0 command header ke UICC.
2. Pada penerimaan command header tersebut, jika UICC :
1. Mengembalikan procedure byte, transport layer dari terminal akan mengirimkan porsi data dari conditional body C-APDU ke UICC dengan aturan dari procedure byte yang dikembalikan UICC
2. Mengembalikan status, transport layer dari terminal akan menghentikan pemroresan dari command tersebut.
3. Jika pemroresan tidak dilanjutkan/dihentikan pada step 2.b, UICC akan mengembalikan status yang diterima dari conditional body C-APDU dan penyelesaian dari pemroresan command.
4. Pada penerimaan status dari UICC, transport layer terminal akan menghentikan pemroresan dari command tersebut.

Lihat lampiran C untuk informasi lebih detail mengenai pertukaran data antara UICC dan terminal. 

Status word yang diterima oleh transport layer terminal setelah menyelesaikan pemroresan dari suatu command, atau status word yang dikembalikan UICC yang menyebabkan transport layer menghetikan pemroresan command tersebut dipetakan ke R-APDU tanpa perubahan apapun.

7.3.1.1.4 Case 4

C-APDU dipetakan ke C-TPDU dengan menghilangkan byte terakhir (Le).

Alur pertukaran datanya sebagai berikut :

1. Transport layer terminal akan mengirimkan T=0 command header ke UICC.
2. Pada penerimaan command header tersebut, jika UICC :
1. Mengembalikan procedure byte, transport layer terminal akan mengirimkan porsi data pada conditional body C-APDU ke UICC dengan kontrol dari procedure byte yang dikirimkan UICC sebelumnya.
2. Mengembalikan status, transport layer terminal akan menghentikan pemroresan command tersebut.
3. Jika pemroresan tidak dihentikan pada step 2.b, conditional body C-APDU yang diterima, UICC akan :
1. Pada normal processing, akan mengembalikan procedure bytes '61XX' ke transport layer terminal yang meminta untuk memberikan GET RESPONSE command agar dapat menerima data dari UICC; atau
2. Pada abnormal processing, hanya mengembalikan status saja ke transport layer terminal.
4. Pada penerimaan procedure bytes atau status pada step 3, jika UICC :
1. Mengembalikan procedure bytes '61XX' seperti pada 3.a, maka transport layer terminal akan mengirimkan GET RESPONSE command header ke UICC dengan P3 yang nilainya diset ke nilai yang kurang dari atau sama dnegan nilai yang terdapat pada byte 'xx' di '61XX' tersebut; atau
2. Mengembalikan status seperti pada 3.b yang menunjukkan warning ('62XX' atau '63XX'), atau status yang berhubungan dengan applikasi ('9XXX' tetapi bukan '9000'), maka transport layer dari terminal akan mengirimkan perintah GET RESPONSE dengan Le = '00'; atau
3. Mengembalikan status seperti pada step 3.b yang tidak termasuk dalam step 4.b, maka transport layer terminal akan menghentikan pemroresan dari command tersebut.
5. Jika pemroresan command tersebut tidak dihentikan pada 4.c, GET RESPONSE command akan diproses sesuai dengan aturan pada command case 2.

R-TPDU dari UICC yang menunjukkan bahwa UICC telah melakukan perintah yang betul dan yang menunjukkan bawah UICC mempunyai data lebih untuk dikirimkan dengan panjang Luicc bytes. R-TPDU ini dipetakan ke R-APDU tanpa perubahan apapun.

Lihat lampiran C untuk informasi lebih detail tentang pertukaran data antara terminal dan UICC, termasuk penggunaan dari procedure bytes '61XX' dan '6CXX'.

7.3.1.1.5 Penggunaan Procedure bytes '61XX' dan '6CXX'

UICC mengembalikan procedure bytes '61XX' dan '6CXX' ke transport layer terminal untuk menunjukkan cara yang digunakan untuk memperoleh data yang diminta oleh command yang sedang diproses. Procedure tersebut hanya digunakan ketika melakukan pemroresan command pada kasus 2 atau 4 menggunakan T = 0.
Procedure '61XX' memerintahkan transport layer terminal untuk mengeluarkan GET RESPONSE command ke UICC. P3 dari GET RESPONSE tersebut di set ke 'XX'.
Procedure '6CXX' memerintahkan transport layer terminal untuk segera mengirimkan command header sebelumnya dengan P3 = 'XX'.
Penggunaan procedure byte tersebut selama pemroresan error free pada kasus 2 dan 4 dijelaskan di bawah. Dalam kasus terdapat error, UICC dapat mengembalikan status yang menunjukkan error atau warning selain mengembalikan response '61XX' atau '6CXX'.
7.3.1.1.5.1 Case 2 Commands

1. Jika UICC menerima command header untuk case 2 dan Le='00' (dengan Luicc < 256 bytes) atau Le > Luicc, maka UICC akan mengembalikan :
1. Procedure bytes '6C Luicc' yang memerintahkan transport layer terminal untuk segera mengirimkan kembali command header dengan P3 = Luicc; atau
2. Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00')
2. Jika UICC menerima command header untuk case 2 dan Le='00' (dengan Luicc=256 bytes) atau Le=Luicc, maka UICC akan mengembalikan :
1. Data dengan panjang Le (=Luicc) dengan kontrol dari procedure bytes INS, __INS, atau '60' yang diikuti oleh yang status yang berhubugan; atau
2. Procedure bytes '61XX' yang memerintahkan transport layer terminal untuk segera mengirimkan GET RESPONSE command dengan panjang maksimum 'xx', dimana 'xx' lebih kecil dari Luicc (hal ini dapat terjadi jika buffer data dari card lebih kecil dari Luicc); atau
3. Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00').
3. Jika UICC menerima command header untuk case 2 dan Le < Luicc, UICC akan mengembalikan :
1. Data yang panjangnya Le dengan kontrol dari procedure bytes INS, __INS, atau '60' yang diikuti oleh procedure bytes '61XX' yang memerintahkan transport layer terminal untuk mengirimkan GET RESPONSE command degan panjang maksimum 'xx'; atau
2. Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00').

7.3.1.1.5.2 Case 4 commands

Jika UICC menerima command case 4, setelah pemroresan data yang dikirim dengan C-APDU, UICC akan mengembalikan :

1. Procedure bytes '61XX' yang memerintahkan transport layer terminal untuk mengirimkan GET RESPONSE command dengan panjang maksimum 'xx'; atau
2. Status yang menunjukkan warning atau kondisi error (tetapi bukan SW1 SW2 = '90 00').

GET RESPONSE command yang kirimkan akan diperlakukan seperti yang disebukan pada kasus 2 di atas.

7.3.2 Transporation of a APDU using T = 1

C-APDU dikirim dari application layer dari terminal ke transport layer terminal yang sama. Transport layer memetakan C-APDU pada INF I-block tanpa perubahan apapun. I-block selanjutnya dikirim ke UICC. Respond data (jika ada) dan status selanjutnya dikembalikan oleh UICC ke transport layer terminal pada INF I-block. Jika UICC mengembalikan status yang menunjukkan :

• Warning ('62XX' atau '63XX');
• Application condition ('9XXX'); atau
• Kondisi berhasil dari command yang bersangkutan ('9000');

Maka UICC juga harus mengembalikan data (jika memang ada) yang berhubungan dengan command tersebut. Tidak ada data yang harus oleh UICC jika UICC mengembalikan status.

Isi dari INF pada I-block dipetakan ke R-APDu tanpa perubahan apapun dan dikirimkan ke application layer dari terminal. Pengiriman pesan APDU dengan T = 1 dipetakan ke I-block sesuai dengan 4 kasus yang dijelaskan sebagai berikut.

7.3.2.1 Case 1

C-APDU dipetakan ke INF pada I-block tanpa perubahan apapun.

Response yang diterima dari INF pada I-block ini dipetakan ke R-APDU tanpa perubahan apapun.
7.3.2.2 Case 2
C-APDU dipetakan ke INF pada I-block tanpa perubahan apapun.

R-APDU terdiri dari INF I-block atau rankaian INF dari I-block yang diterima pada respon yang sama yang di-chained.
7.3.2.3 Case 3
C-APDU dipetakan tanpa perubahan apapun ke INF atau rangkain dari beberapa I-block yang di-chained.

INF dari I-block dipetakan ke R-APDU tanpa perubahan apapun.
7.3.2.4 Case 4
C-APDU dipetakan tanpa perubahan apapun ke INF atau rangkain beberapa I-block yang berantai.

Response terdiri dari INF I-block atau rangkaian INF I-block yang berantai.

7.4 Application Layer
Protocol application terdiri dari kumpulan pertukaran data antara application layer dan transport layer dari terminal.
Setiap langkah pada pertukaran data application layer terdiri dari pasangan command-response, dimana application layer terminal mengirim perintah ke UICC melalui transport layer terminal, dan UICC memproses command tersebut dan mengirimkan respon ke application layer terminal menggunakan application layer UICC dan transport layer terminal. Setiap command yang spesifik (C-APDU) mempunyai respon yang spesifik pula (R-APDU). Command dan respon disebut sebagai command message dan responsed message. Struktur dari C-APDU dan R-APDU dapat dilihat pada sub bab 10.2.
Command dan response message dapat berisi data. Oleh sebab itu, terdapat 4 kasus yang harus diatur dengan protocol transmisi melalui transport layer, seperti terlihat pada tabel di bawah :

7.4.1 Exchange of APDUs
Gambar 7.14 menunjukkan prinsip dalam pertukaran command dan responsenya

7.4.2 CAT Layer
Layer CAT menggunakan status word dari application untuk menunjukkan :

• Keberadaan proactive command ke terminal ('91XX');
• Kegunaan dari respon data ke envelope command oleh terminal (normal '9000', warning '62XX', atau '63XX', pengecekan error '6FXX');
• Tidak adanya CAT secara sementara untuk menghandle envelope command ('9300'), lihat sub bab 14.6.6.

7.4.2.1 Proactive Command

Dalam kasus status word SW1-SW2 sama dengan '9000', card dapat menjawab dengan '91XX' untuk menunjukkan bahwa proactive command sedang pending. Terminal menggunakan FETCH-APDU untuk mendapatkan pending proactive command tersebut. Terminal mengirimkan respon dari proactive command ke UICC dengan TERMINAL RESPONSE C-APDU.
Jika command dimana card menjawab dengan '91XX' dikirim pada logical channel yang berbeda dengan basic channel, maka terminal akan mengirim  FETCH dan TERMINAL RESPONSE commands ke basic channel.
Mekanisme, yang dijelaskan kemudian untuk kasus 4 C-APDU, yang digunakan bersifat independent dari transport protocol.

7.4.2.2 ENVELOPE Commands
ENVELOPE C-APDU digunakan untuk mengirimkan data ke CAT. Untuk beberapa BER-TLV (contohnya SMS-PP Data Download) yang terletak pada body dari command ini, card dapat mengirim data ke terminal pada ACK channel (e.g RP-ACK) atau pada error channel (RP-ERROR). BER-TLV didefinisikan pada TS 102 223 dan pada access technology dependent specifications.
Command ini termasuk dalam kasus 3 atau 4 dan dijelaskan sebagai berikut.
Case 3 : Negative Acknowledgement

Terminal akan mengangap status word yang diterima sebagai negatif ACK dan menggunakan error ACK channel (e.g RP-ERROR), ketika terdapat status word '6FXX' di R-APDU.
Case 4 : Positive Acknowledgement

Terminal akan menganggap data yang diterima sebagai positive ACK and menggunakan normal ACK channel (RP-ACK), ketika terdapat status word '9000' di R-APDU.
Case 4 : Negative Acknowledgement

Terminal akan menganggap data yang diterima sebagai negative ACK and menggunakan error ACK channel (e.g RP-ERROR), ketika terdapat status word '62XX' atau '63XX' pada R-APDU.