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.

Standard untuk Single Wire Protocol (SWP)

Beberapa standard ETSI yang digunakan untuk Single Wire Protocol (SWP), yaitu :

1. ETSI TS 101 220; Smart Cards; ETSI numbering system for telecommunication application providers
2. ETSI TS 102 221; Smart Cards; UICC-Terminal interface; Physical & logical characteristics
3. ETSI TS 102 222; Integrated Circuit Cards (ICC); Administrative commands for telecommunications applications
4. ETSI TS 102 223; Smart Cards; Card Application Toolkit (CAT)
5. ETSI TS 102 225; Smart Cards; Secured packed structure for UICC based applications
6. ETSI TS 102 226; Smart Cards; Remote APDU structure for UICC based applications
7. ETSI TS 102 230; Smart Cards; UICC-Terminal interface; Physical, electrical, and logical test specification
8. ETSI TS 102 240; Smart Cards; UICC Application Programming Interface and Loader Requirements; Service description
9. ETSI TS 102 241; Smart Cards; UICC Application Programming Interface (UICC API) for Java Card (TM)
10. ETSI TS 102 267; Smart Cards; Connection Oriented Service API for the Java Card (TM) platform
11. ETSI TS 102 268; Smart Card; Test specification for the UICC Application Programming Interface (API) for Java Card (TM)
12. ETSI TS 102 412; Smart Cards; Smart Card Platform Requirements Stage 1
13. ETSI TS 102 127; Smart Cards; Transport protocol for CAT applications; Stage 2
14. ETSI TS 102 483; Smart Cards; UICC-Terminal interface; Internet Protocol connectivity between UICC and terminal
15. ETSI TS 102 484; Smart Cards; Secure channel between a UICC and an end-point terminal
16. ETSI TS 102 600; Smart Cards; UICC-Terminal interface; Characteristics of the USB interface
17. ETSI TS 102 613; Smart Cards; UICC-Contactless Frond-end (CLF) Interface; Part 1: Physical and data link layer characteristic
18. ETSI TS 102 622; Smart Cards; UICC-Contactless Frond-End (CLF) Interface; Host Controller Interface (HCI)
19. ETSI TS 102 694-1; Smart Cards; Test speficication for the Single Wire Protocol (SWP) interface; Part 1: Terminal features
20. ETSI TS 102 694-2; Smart Cards; Test specification for the Single Wire Protocol (SWP) interface; Part 2: UICC features
21. ETSI TS 102 695-1; Smart Cards; Test specification for the Host Controller Interface (HCI); Part 1: Terminal features
22. ETSI TS 102 695-2; Smart Cards; Test specification for the Host Controller Interface (HCI); Part 2: UICC features
23. ETSI TS 102 695-3; Smart Card; Test specification for the Host Contrller Interface (HCI); Part 3: Host Controller features
24. ETSI TS 102 705; Smart Card; UICC Application Programming Interface for Java Card for Contactless Applications
25. ETSI TS 103 115; Smart Cards; Test specification for UICC Application Programming Interface for Java Card for Contactless Applications; Test Environment and Annexes
26. ETSI TS 103 383; Smart Cards; Embedded UICC; Requirements Specification
27. ETSI TS 103 484-1; Smart Cards; Test specification for the Secure Channel Interface; Part 1: Terminal Features
28. ETSI TS 103 484-2; Smart Cards; Test specification for the Secure Channel Interface; Part 2: UICC features

Untuk standard ISO :

1. ISO/IEC 14443-2 : "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - Part 2 : Radio frequency power and signal interface"
2. ISO/IEC 14443-3 : "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - Part 3 : Initialization and anticollision"
3. ISO/IEC 14443-4 : "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - Part 4 : Transmission protocol"
4. ISO/IEC 7810 : "Identification cards - Physical characteristics"
5. ISO/IEC 7811-1 : "Identification cards - Recording technique - Part 1 : Embossing"
6. ISO/IEC 7816-1 : "Identification cards - Integrated circuit(s) cards with contacts - Part 1: Physical characteristics"
7. ISO/IEC 7816-2 : "Identification cards - Integrated circuit cards - Part 2 : Cards with contacts - Dimensions and location of the contacts"
8. ISO/IEC 7816-3 : "Identification cards - Integrated circuit cards - Part 3 : Cards with contacts - Electrical interface and transmission protocols"
9. ISO/IEC 7816-4 : "Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange"

Standard lain :

1. GlobalPlatform : "Java Card API and Export File for Card Specification", see https://www.globalplatform.org
2. GlobalPlatform : "Security Upgrade for Card Content Management - GlobalPlatform Card Specification v2.2 - Amendment E", see https://www.globalplatform.org
3. GlobalPlatform : "Card Specification Version 2.2, Amendment B & C: Contactless Services", see https://www.globalplatform.org
4. GlobalPlatform : "Card UICC Configuration"
5. GlobalPlatform : "Confidental Card Content Management Card Specification v2.2 - Amendment A V1.0.1"
6. NIST Special Publication 800-38A (2001) : "Recommendation for Block Cipher Modes of Operation - Methods and Tecniques"
7. NIST Special Publication 800-38B (2001) : "Recommendation for Blcok Cipher Modes of Operation : The CMAC Mode For Authentication"
8. FIPS-197 (2001) : "Advanced Encryption Standard (AES)", see http://csrc.nist.gov/publications/fips/index.html