LAPORAN AKHIR PENELITIAN DANA DIKS TAHUN 2004/2005


LAPORAN AKHIR PENELITIAN
DANA DIKS TAHUN 2004/2005

IMPLEMENTASI DOMPET ELEKTRONIK (e-purse) MENGGUNAKAN TEKNOLOGI SMART CARD

Oleh :
F.X. Arunanto

Dibiayai dengan Dana DIKS
Tahun Angaran 2004/2005
Nomor Kontrak: 299.2/K03.6/PL/05 Tanggal 10 Mei 2005

JURUSAN TEKNIK INFORMATIKA
FAKULTAS TEKNOLOGI INFORMASI

LEMBAGA PENELITIAN DAN
PENGABDIAN KEPADA MASYARAKAT
INSTITUT TEKNOLOGI SEPULUH NOPEMBER
TAHUN 2005

LEMBAR IDENTITAS DAN PENGESAHAN
PROGRAM PENELITIAN DANA DIKS TAHUN 2004/2005

1. a. Judul Penelitian : IMPLEMENTASI DOMPET ELEKTRONIK (e-purse) MENGGUNAKAN
TEKNOLOGI SMART CARD
b. Disiplin Ilmu : Komputasi Berbasis Jaringan
c. Kategori Penelitian : Pengembangan Ilmu Pengetahuan
2. Peneliti Utama :
a. Nama : Ir. F.X. Arunanto, M.Sc.
b. Jenis Kelamin : Laki-laki
c. Pangkat/Golongan/NIP : Penata Muda Tk. I/ III B / 131 285 253
d. Jabatan Fungsional : Lektor
e. Jabatan Struktural : Ketua Program Magister Teknik Informatika
f. Jurusan/Fakultas : Teknik Informatika / FTIF
3. Jumlah Anggota Peneliti : 2 (dua) orang
1. Daniel Oranova Siahaan
2. Ahmad Hoirul Basori
4. Lokasi Penelitian : Laboratorium, Jurusan Teknik Informatika, FTIf, ITS
5. Jangka Waktu Penelitian : 6 bulan
6. Biaya Penelitian : Rp 4.970.000,00

Mengetahui, Surabaya, 1 September 2005
Ketua Jurusan Teknik Informatika Ketua Peneliti,

Yudhi Purwananto, S.Kom., M.Kom. Ir. F.X. Arunanto, M.Sc.
NIP. 132 172 210 NIP. 131 285 253

Menyetujui,
Dekan Fakultas Teknologi Informasi ITS

Prof. Dr. Ir. Arif Djunaidy, M.Sc.
NIP. 131 633 403

ABSTRAK

Smart Card merupakan miniatur komputer yang terbatas namun dapat melakukan pemrosesan suatu instruksi dengan mudah dan aman. Dengan karakteristik seperti itu, teknologi ini banyak digunakan untuk aplikasi perbankan maupun mobile phone. Pada penelitian ini, akan dikembangkan suatu teknologi smart card untuk system dompet elektronik (e-purse). Sistem ini akan meniru fungsi dompet sebagai penyimpan uang secara fisik. Dengan aplikasi ini, pengguna dapat menyimpan uang secara elektronik dan menggunakannya untuk bertransaksi selayaknya menggunakan uang secara fisik.
Sistem e-purse ini dibangun dengan menggunakan teknologi JCOP smart card dari IBM yang mendukung OCF (Open Card Framework) serta teknologi Java Card sebagai Application Programming Interface-nya.
Hasil dari penelitian ini adalah sistem e-purse yang komponenen utamanya adalah e-purse applet yang tersimpan dalam smart card, terminal Point of Sales, dan terminal Reload. Sistem ini telah diverifikasi dan divalidasi terhadap spesifikasi kebutuhan sistem dan menggunakan unit testing.

Kata-kata kunci: e-purse, smart card, java card, OCF

ABSTRACT

Smart Card is a miniatur of computer with limited resource but can process an instruction easily and safely. Given this characteristics, this technology is widely use for banking application and mobile phone. This research is developing smart card technology for e-purse system. This system mimics the functions of traditionally purse or wallet to store physical money. With this application, the user can save their money electronically and use it to interact as it is physicial money.
This e-purse system is developed using JCOP smart card from IBM that supports OCF (Open Card Framework) and Java Card technology as its Application Programming Interface.
There are three components build for this system, i.e. e-purse applet, which is stored in the smart card, the Point of Sales and Reload terminal. This system has been verified against its requirements and validated using unit testing.

Keywords: e-purse, smart card, java card, OCF

PRAKATA

Syukur kepada Tuhan Yang Maha Esa akhirnya penelitian dengan judul IMPLEMENTASI DOMPET ELEKTRONIK (e-purse) MENGGUNAKAN TEKNOLOGI SMART CARD ini dapat diselesaikan dengan baik. Hal ini tidak lepas dari kerja keras dari semua anggota dari tim penelitian ini dan juga pertolonganNya.
Laporan penelitian ini disusun guna memenuhi persyaratan kegiatan penelitian yang dilakukan pada Lembaga Penelitian dan Pengabdian kepada Masyarakat, ITS dengan menggunakan alokasi dana DIKS 2004/2005.
Akhir kata, penulis berharap semoga penelitian ini dapat memberikan sumbangan yang bermanfaat bagi khazanah ilmu komputer dan teknologi informatika khususnya yang terkait dengan bidang rekayasa perangkat lunak.

Tim Peneliti

DAFTAR ISI

Prakata ………………………………………….
Abstrak ………………………………………….
Daftar Isi …………………………………………
Daftar Gambar …………………………………….
Daftar Tabel ………………………………………
I. Pendahuluan …………………………………….
II. Tinjauan Pustaka ………………………………….
III. Tujuan dan Manfaat ……………………………….
IV. Metode Penelitian …………………………………
V. Hasil dan Pembahasan ……………………………..
V.1. Perancangan Sistem …………………………….
V.2. Protokol Keamanan …………………………….
V.3. Implementasi Sistem …………………………….
V.4. Skenario Peluncuran Aplikasi ………………………
V.5. Uji Coba …………………………………….
VI. Kesimpulan dan Saran ……………………………..
Daftar Pustaka …………………………………….
Lampiran A. Perintah-Perintah APDU untuk Sistem E-Purse ……….
Lampiran B. Spesifikasi Kebutuhan ……………………….
Lampiran C. Test List …………………………………
Lampiran D. Pengelolaan Sumber Daya …………………….
Lampiran E. Test Casper ……………………………… ii
iv
vi
vii
viii
1
2
4
5
7
7
12
16
18
22
23
25
26
30
34
35
40

a

DAFTAR TABEL

Tabel 1. Fungsi dari kelas-kelas pada komponen POS Terminal ……..
Tabel 2. Fungsi dari metode pada applet ePurse ……………….
Tabel 3. Fungsi dari kelas-kelas pada komponen Reload Terminal ……
Tabel 4. Protokol untuk autorisasi pada iterasi 0 untuk pengiriman 1 data .
Tabel 5. Protokol untuk autorisasi pada iterasi 0 untuk pengiriman n data .
Tabel 6. Protokol untuk autorisasi pada iterasi 1 untuk pengiriman n data .
Tabel 7. Protokol untuk autorisasi pada iterasi 1 untuk pengiriman 1 data .
Tabel 8. Test Case untuk Uji Coba Sistem dan hasilnya ………….. 9
10
12
14
14
15
15
23

DAFTAR GAMBAR

Gambar 1. Penggunaan smart card pada umumnya …………….
Gambar 2. Ilustrasi sistem e-purse ………………………..
Gambar 3. Arsitektur sistem Java Card ……………………..
Gambar 4. Alur Penelitian ……………………………..
Gambar 5. Arsitektur sistem e-purse ……………………….
Gambar 6. Diagram kelas POS Terminal ……………………
Gambar 7. Diagram applet ePurse ………………………..
Gambar 8. Diagram kelas Reload terminal …………………..
Gambar 9. Interface-interface untuk perangkat lunak …………….
Gambar 10. Interface-interface untuk perangkat keras ……………
Gambar 11. Applet e-Purse yang diluncurkan pada suatu smartcard ….
Gambar 12. Tahap Pembangunan applet e-Purse ………………
Gambar 13. Tahap Konversi applet e-Purse ………………….
Gambar 14. Tahap Testing dan Pemasukan Applet e-Purse pada suatu smartcard ………………………………………..
Gambar 15. Alur proses pembangunan ePurse dengan Gemplus RAD III SDK …………………………………………… 1
2
3
5
8
9
10
11
12
13
17
19
20

21

22

I. PENDAHULUAN

Smart card adalah suatu miniatur komputer yang memiliki Input/Output yang terbatas (tidak ada keyboard, mouse, layar, harddisk, dan seterusnya) dan juga resource-resource yang terbatas pula (10MHz, 16K ROM, 1K RAM, 16K EEPROM). Teknologi ini di negara-negara maju sudah banyak digunakan untuk membangun suatu sistem-sistem berteknologi multiguna, contohnya adalah bank card, mobile phone SIM, TV membership, dan seterusnya. Pada dasarnya, smart card adalah suatu microprocessor yang mampu menyimpan dan memproses informasi secara aman. Hal ini yang membedakan antara smart card dengan jenis-jenis kartu lainnya, seperti kartu magnetic stripe dan memory-only chip.
Smart card dianggap lebih aman karena informasi dan program pada suatu smart card tidak dapat (dengan mudah) dibaca atau diubah. Hal ini berbeda dengan komputer pribadi pada umumnya. Pada smartcard, pengguna dapat menyimpan kunci cryptographic sehingga memampukan smartcard untuk melakukan enkripsi maupun dekripsi terhadap data yang dipertukarkan.

Gambar 1 Penggunaan smart card pada umumnya.

Dengan melihat fitur-fitur yang disediakan dan karakteristik yang dimiliki oleh teknologi smart card, dapat dibangun suatu aplikasi dompet elektronik (e-purse). Aplikasi ini merupakan suatu aplikasi yang cukup sederhana, akan tetapi menawarkan tingkat keamaan yang lebih tinggi dari teknologi kartu lain, seperti magnetic tape.

Gambar 2 Ilustrasi sistem e-purse.

Aplikasi e-purse sendiri adalah suatu aplikasi yang memungkinkan pemilik kartu (yang biasanya sekaligus kartu Automatic Teller Machine, ATM) untuk memasukkan sejumlah besar uang secara elektronik kedalam “dompet” dari bank account yang bersangkutan. Kemudian, dompet tersebut dapat digunakan untuk melakukan transaksi dengan perangkat bertransaksi tanpa perangkat tersebut terhubung ke jaringan ATM bank yang bersangkutan (off-line). Gambar 2 menunjukkan ilustrasi dari sistem e-purse ini.

II. TINJAUAN PUSTAKA
Aplikasi smart card seperti e-purse terdiri dari suatu aplikasi card-external yang berinteraksi dengan suatu komponen card-resident [7]. Teknologi perangkat lunak yang akan digunakan untuk membangun komponen card-resident adalah Java Smart Card [5][6]. Java Card adalah suatu generasi bahasa pemrograman smart card yang baru. Dimana suatu java applet ditulis dalam bahasa tingkat tinggi, dikompilasi kedalam bytecode, disimpan kedalam EEPROM, dan dijalankan pada suatu smart card. Hal lain yang membedakan dengan kartu dari generasi sebelumnya adalah kemampuan smart card untuk menampung lebih dari satu aplikasi (applet) dan menambah atau menghapus applet ke dan dari smart card.

Gambar 3. Arsitektur sistem Java Card [6].
Gambar 3 menunjukkan sistem arsitektur Java Card. Java card merupakan subset dari Java dengan sejumlah keterbatasan, yaitu:
– tidak ada real, double, string, dan multi-dimensi array
– tidak ada threads
– opsi untuk melakukan garbage collection
Java Card menggunakan 16 bit aritmatika dan class file yang telah dioptimisasi, yang disebut cap-files. API untuk Java Card mendukung I/O smart card dengan menggunakan APDU’s menggunakan ISO 7816. API Java Card juga mendukung persistensi, transient data dan transaksi.
Sedangkan untuk aplikasi card-external, yang merupakan suatu program yang berjalan pada suatu platform komputer, seperti PC, jaringan komputer, ATM, atau personal digital assistant, teknologi yang akan digunakan untuk membangun perangkat lunaknya adalah Open Card Framework (OCF) [7]. OCF merupakan API berbasis java yang digunakan untuk membangun aplikasi eksternal dan memungkinkannya untuk berinteraksi dengan API tingkat tinggi java lainnya.
Interaksi antara keduanya, aplikasi card-external dan komponen card-internal, terjadi dengan mempertukarkan pasangan APDU (Application Protocol Data Unit) dan diinisiasi oleh aplikasi eksternal. Komunikasi dengan smart card terjadi melalui suatu card reader, yang merupakan perangkat Input/Output yang disambungkan ke perangkat external. Aplikasi eksternal mengiriman suatu CommandAPDU ke smart card dengan menyerahkannya kepada perangkat card reader, yang kemudian meneruskannya ke smart card. Kemudian smart card mengirim balik suatu ResponseAPDU, yang diteruskan oleh card reader ke aplikasi eksternal.

III. TUJUAN DAN MANFAAT
Tujuan yang ingin dicapai dari penelitian ini adalah membangun suatu prototipe aplikasi e-purse menggunakan teknologi smart card, dengan batasan-batasan seperti disebutkan pada bagian batasan masalah, untuk kemudian digunakan untuk penelitian-penelitian berikutnya.
Hasil penelitian ini dapat menjadi alternatif program perbankan baru yang diharapkan dapat menarik minat pengguna jasa perbankan untuk lebih lagi melakukan transaksi-transaksi melalui jasa-jasa yang disediakan oleh perbankan. Terlebih lagi, hasil penelitian ini dapat digunakan untuk mengembangkan apliksai-aplikasi lain yang menggunakan teknologi smart card, seperti airmiles system, loyalty card, quota card, dan sebagainya.

IV. METODE PENELITIAN

Gambar 4 Alur Penelitian

Penelitian ini akan dilaksanakan dalam beberapa tahapan dimana beberapa metode digunakan untuk mendekati domain permasalahan guna mencari pemecahannya. Tahapan-tahapan ini menggunakanan metodologi berorientasi obyek. Diharapkan dengan penggunaan metodelogi ini, aplikasi yang dibuat dapat dikembangkan lagi menjadi aplikasi-aplikasi lain dengan menggunakan desain yang telah ada. Gambar 4 menunjukkan alur dari tahapan-tahapan penelitian tersebut.

1. Studi pustaka
Mencari dan menelaah sumber-sumber pustaka yang menjelaskan mengenai teknologi smart card, Open Card Framework, Java Card, dan JCOP smart card dari IBM. Dalam tahapan ini juga diharapkan peneliti dapat mengumpulkan sekelompok kebutuhan sistem. Untuk itu, digunakan beberapa metode, yaitu:
– Ekplorasi dokumen atau petunjuk teknik.
– Braintstorming

2. Perancangan Sistem
Proses perancangan sistem akan didasarkan kepada perancangan dan pemodelan berorientasi objek. teknologi Java Card sendiri. Melalui pendekatan ini diharapkan sistem ini dapat dikembangan lebih lanjut, dan terlebih lagi dimungkinkan untuk dipergunakan untuk sistem-sistem berorientasi objek lainnya. Pada bagian perancangan sistem, mula-mula diawali dengan pengumpulan kebutuhan, baik fungsional maupun non-fungsional dari sistem yang dibuat. Proses pengumpulan ini menggunakan teknik scenario. Kemudian dari scenario ini dipetakan kedalam beberapa use-case, yang merupakan gambaran penggunaan sistem oleh user. Dari use-case, dibangun logical view dari sistem, yang berupa class diagram dan sequance diagram, yang merupakan gambaran arsitektur dari sistem kemudian Melalui pendekatan ini diharapkan sistem ini dapat dikembangan lebih lanjut, dan terlebih lagi dimungkinkan untuk dipergunakan untuk sistem-sistem berorientasi objek lainnya.

3. Pengimlementasian Sistem
Disain maupun data model sistem yang dihasilkan kemudian direalisasikan dalam bentuk perangkat lunak. Bahasa pemrograman yang digunakan adalah Java. Bahasa pemrograman ini dipilih karena mendukung pemrograman berorientasi obyek.

4. Uji Coba dan Validasi
Sistem akan diuji coba atas aspek-aspek perancangan sistem berorientasi objek dan divalidasi atas kesesuaian implementasi dengan kebutuhan sistem. Untuk jenis pengujian pertama, beberapa test case dibuat sesuai dengan use case yang telah ditetapkan pada tahap perancangan sistem. Untuk melakukan pengujian ini menggunakan suatu peralatan pengujian yang disebut Unit Testing [1][3]. Untuk jenis pengujian kedua, dibuat suatu matrik pengecekan antara kesesuaian kebutuhan fungsional dan non-fungsional sistem dengan arsitektur dan implementasinya. Diharapkan dengan pengujian seperti ini maka verifikasi dan validasi sistem dapat dilakuakan dengan spesifik dan terukur.

5. Penulisan Naskah Laporan Penelitian
Hasil penelitian, baik yang berkaitan dengan studi kepustakaan, perancangan sistem, perancangan dan pembuatan program, dan hasil uji coba dituangkan dalam satu laporan penelitian sesuai dengan format yang telah ditetapkan oleh Lembaga Penelitian dan Pengabdian kepada Masyarakat, ITS.

V. HASIL DAN PEMBAHASAN
Seperti yang telah disebutkan sebelumnya, aplikasi e-purse ini ditargetkan untuk perbankan yang hendak menyediakan layanan kepada pelanggannya untuk menggunakan uang tunai secara elektronik. Dalam artian, e-purse merupakan aplikasi yang menyerupai dompet yang biasa digunakan sehari-hari. Hasil dari penelitian ini adalah pembangunan sejumlah komponen yang diperlukan bagi sistem e-purse ini.

V.1. Perancangan Sistem

Gambar 5 menggambarkan beberapa pihak atau komponen dalam model sistem e-purse yang kami bangun. Komponen-komponen yang berada dalam persegi empat bertanda “Developed” dibangun dalam proyek penelitian ini, yakni Point of Sale Terminal (POS), aplikasi di dalam Smart Card, dan Reload Terminal. Obyek berbentuk lingkaran sejumlah 5 buah pada Gambar 5 merepresentasikan interface antar komponen yang harus aman dan dibatasi agar memenuhi kebutuhan dari sistem, dalam hal ini adalah keamanan dan integritas data.

Gambar 5. Sistem Arsitektur e-purse

POS Terminal
Pada komponen POS Terminal, ada sejumlah kelas yang perlu dibangun, yaitu: POSTerminalMain, POSTerminal, GUIPOSTerminal, dan CardReaderListener. Gambar 6 di bawah ini menunjukkan diagram kelas dari keempat kelas pada komponen POS Terminal.

Gambar 6. Diagram kelas POS Terminal
Tabel 1 berikut akan menjelaskan fungsi dari masing-masing kelas tersebut.

Tabel 1 Fungsi dari kelas-kelas pada komponen POS Terminal.
Nama Deskripsi
POSTerminal Kelas utama dari komponen POSTerminal
GUI Menangani interaksi pengguna dengan aplikasi POSTerminal dan kartu ePurse
GUIObserver CardReader menggunakan kelas ini untuk menotifikasi kelas kelas GUI.
CardReader Menangani perangkat cardReader yang mengakses kartu ePurse

Smart Card
Pada komponen Smart Card, ada satu buah applet yang perlu dibangun untuk sistem e-Purse ini, yaitu ePurse applet. Gambar 7 di bawah ini menunjukkan diagram dari applet ePurse.

Gambar 7. Diagram applet ePurse
Applet ePurse merupakan instansiasi dari javacard.framework.Applet. Pada applet ini terdapat sejumlah metodel. Tabel 2 di bawah ini menerangkan fungsi dari masing-masing metode di dalam applet ePurse.

Tabel 2 Fungsi dari metode pada applet ePurse.
Nama Deskripsi
personalizedCard(APDU) Mempersonalisasi kartu pengguna dengan mennginisialisasi private dan publik key sebagai mekanisme autorisasi kartu, serta pin sebagai mekanisme autorisasi pengguna.
verifyPin(APDU) Mengautorisasi pengguna berdasarkan pin yang dimasukkan.l
getBalance(APDU) Menampilkan nilai terakhir dari simpanan pengguna di dalam kartu.
debit(APDU) Mengurangi simpanan pengguna sejumlah nilai tertentu.
credit(APDU Menambah simpanan pengguna sejumlah nilai tertentu.
log(APDU) Menampilkan 10 transaksi terakhir yang dilakukan pengguna.
select() Memilih applet ePurse sebagai applet aktif.
deselect() Menonaktifkan applet ePurse
Process(APDU) Memproses setiap pesan APDU yang masuk, untuk kemudian diseleleksi berdasarkan nilai OFFSET_INS untuk menentukan aksi yang harus dilakukan kartu. Beberapa pilihan aksi adalah sebagai berikut:
– INS_PERSONALIZED_CARD: memanggil metode personalizedCard(APDU).
– INS_VERIFY_PIN: memanggil metode verifyPin(APDU).
– INS_GET_BALANCE: memanggil metode getBalance(APDU).
– INS_DEBIT: memanggil metode credit(APDU).
– INS_CREDIT: memanggil metode credit(APDU).
– INS_LOG: memanggil metode log(APDU).

Reload Terminal
Pada komponen Reload Terminal, ada sejumlah kelas yang perlu dibangun, yaitu: ReloadTerminalMain, ReloadTerminal, GUIReloadTerminal, dan CardReaderListener. Gambar 8 di bawah ini menunjukkan diagram kelas dari keempat kelas pada komponen Reload Terminal.

Gambar 8. Diagram kelas Reload Terminal
Tabel 3 berikut akan menjelaskan fungsi dari masing-masing kelas tersebut.

Tabel 3 Fungsi dari kelas-kelas pada komponen Reload Terminal.
Nama Deskripsi
ReloadTerminal Kelas utama dari komponen ReloadTerminal
GUI Menangani interaksi pengguna dengan aplikasi ReloadTerminal dan kartu ePurse
GUIObserver CardReader menggunakan kelas ini untuk menotifikasi kelas kelas GUI.
CardReader Menangani perangkat cardReader yang mengakses kartu ePurse

V.2. Protokol Keamanan

Protokol keamanan yang diteliti pada penelitian ini adalah untuk komunikasi antar komponen dalam sistem e-purse, yakni POS dengan Smart Card, Amount Repository, Maintainer System, dan Cash Register; dan Reload Terminal dan Smart Card.

Interface-Interface
Dalam sistem e-purse ini, interface-interface antara perangkat lunak dan perangkat keras dapat dilihat seperti gambar yang ditunjukkan pada Gambar 9 dan Gambar 10.

Gambar 9 Interface-interface untuk perangkat lunak

Sistem terminal terdiri dari suatu personal computer yang terhubung pada suatu Chip Drive melalui port USB.

Gambar 10 Interface-interface untuk perangkat keras

Verification Tool
Untuk memverifikasi apakah protokol komunikasi yang digunakan pada semua interface benar-benar aman, kami menggunakan suatu alat verifikasi. Ada sejumlah alat verifikasi yang masing-masing mengimplementasikan metode verifikasi yang berbeda-beda, seperti Casper/FDR, Isabelle, dan CSP [1][3][4][8][10]). Dalam implementasi sistem e-purse ini, kami menggunakan Casper/FDR sebagai alat verifikasi. Alat ini menyediakan suatu mekanisme yang sederhana bagi pengguna untuk mengecek autentifikasi dan kerahasiaan suatu protokol komunikasi. Alat ini menggunakan bahasa input yang telah disesuaikan yang khusus dirancang untuk mengecek protokol keamanan. Alat ini juga telah berhasil dites pada sejumlah besar protokol keamanan [8][9][10][11].
POS – Smart Card
Untuk komunikasi antara Point of Sales (POS) dan smart card, kedua belah pihak perlu diautentifikasi. Sebagai tambahan suatu sesi yang aman perlu dibangun sedemikian rupa sehingga pesan-pesan dapat dikirim dengan semestinya.
Iteration 0
Pada pendekatan pertama, kami menggunakan algoritma BKE (Bilateral Key Exchange) [2]. Smart card (direpresentasikan oleh B) dan terminal POS (direpresentasikan oleh A), keduanya memiliki suatu pasangan kunci publik dan privat ((P(A), S(A)) dan (P(B),S(B))). Masing-masing pihak mengetahui kunci publik yang lainnya. Pertama, kedua pihak mengauntentifikasi dan kemudian menyetujui suatu kunci sesi yang simentrik (kab). Kunci sesi ini digunakan untuk komunikasi seterusnya sampai sesi tersebut berakhir.
Tabel 4 Protokol untuk autorisasi pada iterasi 0 untuk pengiriman 1 data.
A  B {na,A}{P(B)}
A  B {na,nb,B,kab}{P(A)}
A  B {nb}{kab}
A  B {OK/NOK}{kab}

Dimana na, nb: Nonce; kab: kunci sesi, P(L): kunci publik untuk L;
Pada titik ini, kedua pihak diautentifikasi dan suatu kunci sesi tersedia. Diharapkan dengan menggunakan kunci sesi tidak muncul masalah ketika diverifikasi menggunakan key Casper.

Tabel 5 Protokol untuk autorisasi pada iterasi 0 untuk pengiriman n data.
A  B {na,A}{P(B)}
A  B {na,nb,B, kab}{P(A)}
A  B {nb}{kab}
A  B {OK/NOK}{kab}
A  B {m1}{kab}
A  B {m2}{kab}

Dimana na, nb: Nonce; kab: kunci sesi, P(L): kunci publik dari L; m1,m2: pesan (suatu pesan menggandung fungsi – dengan argumen – untuk melakukan eksekusi, misalnya “Add(25)”)
Analisa Casper menunjukkan bahwa seseorang yang berada ditengah dapat mengirimkan berulang-ulang pesan yang terkirim, walaupun sudah terenkripsi dengan menggunakan kunci sesi.

Iteration 1
Untuk menghindari hal ini, kami memutuskan untuk juga mengirimkan nomor urut pesan untuk setiap pesan. Dengan cara ini, penggunaan pesan lebih dari 1 kali dapat dideteksi. Kelihatannya cara ini sangat sederhana untuk memodelkannya dalam Casper. Ini juga mungkin dikarenakan kemungkinan bahwa nomor urut tak terhingga (sehinga sulit bagi Casper untuk mengecek state space sampai sejauh itu). Sebagai hasilnya, kami memodelkan setiap nomor urut sebagai tipe yang berbeda.
Kali ini, tidak ada masalah yang muncul. Sebagai tambahan, kami melakukan sedikit perubahan terhadap algoritma tersebut, sehingga kunci-kunci sesi dibangun pada sisi terminal (dengan asumsi bahwa terminal memiliki kemampuan komputasi yang lebih besar dibanding smart card).
Tabel 6 Protokol untuk autorisasi pada iterasi 1 untuk pengiriman n data.
A  B {na,A,kab}{P(B)}
A  B {na,nb,B}{P(A)}
A  B {nb}{kab}
A  B {OK/NOK}{kab}
A  B {message,0}{kab}
A  B {response,1}{kab}
A  B {message,2}{kab}
A  B {response,3}{kab}
… …

Dimana na, nb: Nonce; kab: kunci sesi, P(L): kunci publik dari L; message, response: pesan.

Environment – POS
Pendekatan yang sama kami juga gunakan untuk POS – Amount Repository dan Reload Terminal – Smart Card (dimana POS dan Reload Terminal berfungsi sebagai A and Amount Repository dan Smart Card sebagai B).
Cash Register (direpresentasikan oleh A) – POS (direpresentasikan oleh B) dan Maintainer System (direpresentasikan oleh A) – POS (direpresentasikan oleh B) menggunakan protokol yang lain, karena mereka tidak memerlukan pengiriman pesan lebih dari satu kali pada satu sesi. Baik A dan B, keduanya memiliki suatu pasangan kunci publik dan privat. Masing-masing mengetahui kunci publik dari yang lain. Pertama, kedua pihak mengautentifikasi dan menyetujui suatu kunci sesi simetrik.
Tabel 7 Protokol untuk autorisasi pada iterasi 1 untuk pengiriman 1 data.
A  B {na,A,kab}{P(B)}
A  B {na,nb,B}{P(A)}
A  B {nb,message}{kab}
A  B {response}{kab}

Dimana na, nb: Nonce; kab: kunci sesi, P(L): kunci publik dari L; message,response: pesan.
Seperti komunikasi sebelumnya, kami juga memverifikasi protokol keamana ini dengan menggunakan Casper. Kami tidak menemukan suatu masalah apapun.
V.3. Implementasi Sistem
Sebagaimana sudah dijelaskan sebelumnya, ada tiga komponen yang dibangun pada sistem ini, yaitu POS Terminal, Smart Card, dan Reload Terminal. Interaksi antara POS Terminal dengan Smart Card maupun Reload Terminal dengan Smart Card dilakukan dengan cara Terminal mengirimkan perintah kepada Smart Card untuk kemudian Smart Card memanggil metode yang bersesuaian. Seterusnya, Smart Card mengembalikan pesan staus keberhasilan pelaksanaan perintah dan mungkin disertai data kembalian. Perintah dan data tersebut dikirimkan menggunakan suatu protokol pesan yang disebut APDU. Implementasi dari protokol APDU ini dapat dilihat pada Appendix A. Berikut ini penjelasan mengenai implementasi dari masing-masing komponen.

POS Terminal
Komponen POS Terminal pada umumnya diimplementasikan pada sebuah Personal Computer (PC) yang dilengkapi dengan sebuah interface card reader (pembaca kartu).

Smart Card
Aplikasi applet yang kami bangun diluncurkan pada tipe kartu GemExpresso 211 yang merupakan fabrikasi dari GemPlus. Gambar 11 di bawah ini menunjukkan bagaimana applet ePurse diluncurkan pada kartu tersebut.

Gambar 11 Applet e-Purse yang diluncurkan pada suatu smartcard.
GemExpresso 211 adalah bagian dari Visa’s open platform (OP). OP ini adalah suatu kerangka generik untuk mengelola jenis smart card yang mendukung aplikasi ganda (multi-applications). OP ini memperluas lingkungan Java Card dengan menambahkan mekanisme untuk pengelolaan yang aman dari suatu aplikasi pada suatu kartu. OP ini meliputi beberapa komponen:
• Sekumpulan perintah untuk mengelola daur hidup dari suatu kartu dan aplikasi-aplikasinya, memasukkan dan meng-install aplikasi-aplikasi pada kartu, dan mengelola keamanan dari kartu, misalnya dengan melakukan pembaharuan kunci dan menset suatu kanal yang aman antara kartu dan terminal
• Suatu API, yang terdiri dari suatu paket Java tunggal, visa.openplatform, yang dapat digunakan oleh pembangun aplikasi untuk mengakses fitur-fitur dari OP, dan khususnya daur hidup aplikasi dan mengamankan mekanisme pengiriman pesan.
• Suatu spesifikasi dokumen yang secara lengkap mendefinisikan perintah-perintah yang tersedia dan prinsip-prinsip kerja antara Java Card dan lingkungan kartu OP.

Reload Terminal
Sebagaimana komponen POS Terminal, Reload Terminal diimplementasikan pada sebuah Personal Computer (PC) yang dilengkapi dengan sebuah interface card reader (pembaca kartu).
V.4. Skenario Peluncuran Aplikasi
Untuk menluncurkan aplikasi ini diperlukan beberapa perangkat, yaitu:
• Kartu GemExpresso 211
• GemPC Card Reader
• GemExpresso RAD III SDK
• PC Intel dengan spesifikasi minimum sebagai berikut:
o Pentium 166MHz (direkomendasikan Pentium II 350Mhz)
o Memori RAM 128 MB (rekomendasi 256MB)
o Ruang penyimpan tersisa 20-30MB
o Mendukung Super VGA resolusi 800×600 (rekomendasi 1024×768)
• PC Intel yang berfungsi sebagai POS Terminal dan Reload Terminal.

Tahap Pembangunan
Untuk pembangunan prototipe dari applet, kami menggunakan Project Template dari GemExpresso RAD III SDK yang menghasilkan kode skeleton dan suatu definisi proyek di dalam Jbuilder. Kemudian beberapa fungsi sebagaimana disebutkan pada sub bagian sebelumnya ditambahkan ke dalam kode applet tersebut untuk kemudian dikompilasi untuk menghasilkan file dengan ekstensi class. Gambar 12 di bawah ini menunjukkan secara umum bagaimana tahapan pembangunan applet sehingga siap untuk dikonversi.

Gambar 12 Tahap Pembangunan applet e-Purse.

Tahap Konversi
Setelah proses debugging selesai, file class dikonversi menjadi format yang dapat dimasukkan ke dalam target-target ganda. Dengan menggunakan Project Editor dari GemExpresso RAD III SDK paket, AID dari applet, dan lokasi konversi didefinisikan, sehingga dihasilkan file dengan ekstensi CAP. Gambar 13 di bawah ini menunjukkan bagaiman tahap konversi suatu class applet.

Gambar 13 Tahap Konversi applet e-Purse.

Tahap Testing
Sebelum applet yang telah dikonversikan tersebut dimasukkan ke dalam suatu smart card, perlu dilakukan tes terlebih dahulu untuk memastikan validasi dari setiap fungsi yang dibangun dalam applet. Tes ini dilakukan pada suatu lingkungan smart card virtual di dalam GemExpresso RAD III SDK yang disebut GSE (card simulator.

Tahap Pemasukan Applet
Dengan menggunakan JCardManager dari GemExpresso RAD III SDK, file CAP yang hasil konversi dapat dimasukkan ke target kartu yang diinginkan untuk diinstall dan dijalankan. Segera setelah file dimasukkan dan diinstall, suatu perintah APDU dapat dikirimkan ke kartu untuk melakukan test fungsionalitas dan menganalisa respon dari applet. Utilitas CapDump yang berada di dalam JCardManager dapat digunakan untuk melihat isi dari file CAP terkonversi tersebut dalam bentuk yang lebih dapat dibaca. Gambar 14 di bawah ini menunjukkan bagaiman tahap tes dan pemasukan applet ke dalam kartu dilakukan.

Gambar 14 Tahap Testing dan Pemasukan Applet e-Purse pada suatu smartcard.

Gambar 15 di bawah ini menunjukkan alur proses pembangunan applet ePurse secara keseluruhan dengan menggunakan Gemplus RAD III SDK.

Gambar 15 Alur proses pembangunan ePurse dengan Gemplus RAD III SDK.

V.5. Uji Coba
Untuk mengujicoba sistem yang kami buat, kami telah menyusun sejumlah test case. Tabel 8 di bawah ini menunjukkan deskripsi singkat dari sejumlah test case dan hasil dari uji coba tersebut.

Tabel 8 Test Case untuk Uji Coba Sistem dan hasilnya
Id Deskripsi Hasil
TC01 Mengetes fungsi personalisasi kartu (personalizedCard) OK
TC02 Mengetes fungsi autorisasi pengguna (verifyPin) OK
TC03 Mengetes fungsi penampilan nilai simpanan (getBalance) OK
TC04 Mengetes fungsi pengurangan nilai simpanan (debet) dengan jumlah X, dimana nilai simpanan adalah > X dan X>0 OK
TC05 Underflow. Mengetes fungsi pengurangan nilai simpanan (debet) dengan jumlah X, dimana nilai simpanan X OK
TC07 Overflow. Mengetes fungsi penambahan nilai simpanan (credit) dengan jumlah X, dimana nilai simpanan sudah maksimum dan X > 1 OK
TC08 Mengetes fungsi penampilan log (log) OK
TC09 Mengetes sistem logging transaksi pengguna setelah pertama kali diinisialisasi OK
TC10 Mengetes sistem logging transaksi pengguna setelah transaksi debet pertama OK
TC11 Mengetes sistem logging transaksi pengguna setelah transaksi credit pertama OK
TC12 Mengetes sistem logging transaksi pengguna setelah transaksi debet ke-11 OK
TC13 Mengetes sistem logging transaksi pengguna setelah transaksi credit ke-11 OK

Dari tabel tersebut dapat disimpulkan bahwa sistem telah berjalan sesuai dengan spesifikasi yang telah ditentukan.

VI. KESIMPULAN DAN SARAN
Dari serangkaian uji coba yang dilakukan terhadap sistem e-Purse yang telah dibuat dapat ditarik kesimpulan bahwa sistem e-purse ini dibangun dan bekerja sesuai dengan spesifikasi yang telah ditentukan pada awal pembangunan sistem.
Karena representasi dari suatu protokol cukup singkat dalam Casper/FDR, pendeteksian kelemahan dari protokol komunikasi dapat dipercepat. Walaupun protokol-protokol berhasil lolos verfikasi dengan Casper/FDR, tetap tidak ada jaminan penuh bahwa hal ini juga berlaku pada saat implementasi. Ini dikarenakan bahwa suatu perintah yang dianggap atomik dalam Casper mungkin tidaklah demikian dalam implementasinya.
Dengan menggunakan protokol komunikasi yang kami ajukan, BKE dan corrected BKE, kami membangun suatu interface-interface yang aman untuk sistem e-purse. Dan sebagai usulan penelitian berikutnya, kami berencana untuk mengintegrasikan sistem e-purse dengan sistem-sistem berbasis smart card lainnya, seperti loyalty card, freeway card, petrol-rationing card, dan rent-a-car card.

DAFTAR PUSTAKA

[1] Casper: A Compiler for the Analysis of Security Protocols. Computing Laboratory. Oxford University.
http://web.comlab.ox.ac.uk/oucl/work/gavin.lowe/Security/Casper/index.html
[2] Siu-Cheung Charles Chan, An Overview of Smart Card Security, 1997. http://home.hkstar.com/~alanchan/papers/smartCardSecurity/
[3] J.A. Clark and J.L. Jacob. A survey of authentication protocol literature. Technical Report 1.0, 1997.
[4] EPSRC, Verifying Security Protocols Using Isabelle. http://www.cl.cam.ac.uk/users/lcp/papers/protocols.html
[5] Java Card Open Platform.
http://www.zurich.ibm.com/jcop
[6] Java Card Technology.
http://java.sun.com
[7] Open Card Framework Workgroup.
http://www.opencard.org
[8] A.W. Roscoe, Modelling and Verifying key-exchange protocols using CSP and FDR, Proceedings of The Eight IEEE Computer Security Foundations Workshop (CSFW ’95), 1995
[9] Schneider et.al., Modelling and Analysing of Security Protocols. Addison-Wesley Professional, 2000.
[10] S. Schneider, Verifying Authentication protocols in CSP, IEEE Transaction on Software Engineering. Vol.24, Issue 9. 1998.
[11] Dinoj Surendran, Smart Card Technology and Security. http://people.cs.uchicago.edu/~dinoj/smartcard/security.html
[12] PC/SC Workgroup.
http:/www.pcscworkgroup.com
[13] Cpp Unit.
http://cppunit.sourceforge.net/cgi-bin/moin.cgi

LAMPIRAN A. PERINTAH-PERINTAH APDU UNTUK SISTEM E-PURSE.

Select APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0x0 0xA4 0x04 0x0 0x08 Applet ID N/A

Respond APDU
Field Data Status Word Arti dari setiap status word
N/A 0x9000 Proses berhasil
0x6999 Seleksi applet gagal: applet tidak dapat ditemukan atau dipilih

A.1 Keamanan (BKE-like)
Authenticate APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x10 0x0 0x0 4+8+32=44 (Nterminal,TID,SessionKey) 4+4+8=16
4 Nterminal N/A
Nterminal = Nonce sent by Terminal
TID = Terminal’s ID
Respond APDU
Field Data Status Word Arti dari setiap status word
(Ncard,Nterminal,CID) 0x9000 Proses berhasil
N/A 0x6982 Kondisi keamanan tidak terpenuhi
0x6700 Salah ukuran
Ncard = Nonce sent by Terminal
CID = Card’s ID

SetPrivateKey APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x60 SizeOfExp SizeOfMod P1 + P2 (Exp, Mod) N/A

Respond APDU
Field Data Status Word Arti dari setiap status word
N/A 0x9000 Proses berhasil
0x6700 Salah ukuran
0x6A86 Parameter salah (P1,P2)

SetTerminalPublicKey APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x61 SizeOfExp SizeOfMod P1 + P2 (Exp, Mod) N/A

Respond APDU
Field Data Status Word Arti dari setiap status word
N/A 0x9000 Proses berhasil
0x6700 Salah ukuran
0x6A86 Parameter salah (P1,P2)

A.2 Balance
Credit APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x30 0x0 0x0 8+10+1+1 =20 (TID,Date,Amount,SeqNo) 1
Respond APDU
Field Data Status Word Arti dari setiap status word
SeqNo 0x9000 Proses berhasil
0x6A83 Jumlah tidak valid
0x6A84 Melewati jumlah maksimum
0x6982 Kondisi keamanan tidak terpenuhi
0x6700 Salah ukuran

Debit APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x40 0x0 0x0 8
10
1
1
=20 TID
Date
Amount
SeqNo 1
Respond APDU
Field Data Status Word Arti dari setiap status word
SeqNo 0x9000 Proses berhasil
0x6A83 Jumlah tidak valid
0x6A85 Balance negatif
0x6982 Kondisi keamanan tidak terpenuhi
0x6700 Salah ukuran

GetBalance APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x50 0x10 0x0 1 SeqNo 1+2=3
Respond APDU
Field Data Status Word Arti dari setiap status word
Amount
SeqNo 0x9000 Proses berhasil
0x6700 Salah ukuran

A.3 Personal Info
GetPersonalInfo APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x50 0x20 0x0 1 SeqNo 95+1 = 96

Respond APDU
Field Data Status Word Arti dari setiap status word
Name
Address
Phone
Date
Location
UserID
SeqNo 0x9000 Proses berhasil
0x6982 Kondisi keamanan tidak terpenuhi
0x6700 Salah ukuran

SetPersonalInfo APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x62 0x0 0x0 30
35
12
10
4
4
=95 Name
Address
Phone
Date
Location
UserID N/A
Respond APDU
Field Data Status Word Arti dari setiap status word
N/A 0x9000 Proses berhasil
0x6700 Salah ukuran
0x6A86 Parameter salah (P1,P2)

ResetPersonalInfo APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x63 0x0 0x0 95+1=96 Name
Address
Phone
Date
Location
UserID
SeqNo SeqNo
Respond APDU
Field Data Status Word Arti dari setiap status word
seqNo 0x9000 Proses berhasil
0x6700 Salah ukuran
0x6A86 Parameter salah (P1,P2)

A.4 Log
GetLog APDU Command
Command APDU
CLA INS P1 P2 Lc Field Data Le
0xB0 0x50 0x30 0x0 1 SeqNo 1+19*10+1 = 192
Respond APDU
Field Data Status Word Arti dari setiap status word
Number Of Records In the Log
Log
SeqNo 0x9000 Proses berhasil
0x6982 Kondisi keamanan tidak terpenuhi
0x6700 Salah ukuran

LAMPIRAN B. SPESIFIKASI KEBUTUHAN

I. Introduksi
Dokumen ini ditujukan untuk mendefinisikan kebutuhan-kebutuhan dari system e-purse. Kebutuhan-kebutuhan fungsional, non-fungsional, dan model use-case secara bersaam menangkap sekumpulan kebutuhan dari system.
I.1. Tujuan
Spesifikasi kebutuhan-kebutuhan diturunkan dari kebutuhan-kebutuhan yang disebutkan pada deskripsi permasalahan seperti telah disebutkan pada bagian pendahuluan .
I.2. Definitions, Acronyms and Abbreviations

Istilah Definisi
Terminal Aplikasi perangkat lunak yang berinteraksi dengan smart card-smart card
DoS Denial of Service. – serangan terhadap ~: percobaan untuk menghancurkan ~

I.3. Referensi

Identifikasi Referensi
OCF OpenCard Framework, OpenCard Workgroup,
http://www.opencard.org/
PC/SC Personal Computer Smart Card, PC/SC Workgroup,
http://www.pcscworkgroup.com/

II. Kebutuhan – Kebutuhan
II.1. Kebutuhan-Kebutuhan Fungsional
(a) Card + Applet
ID Nama Deskripsi Kepentingan
1.1 Ada Balance Applet e-purse memiliki suatu balance dalam smart card. Balance tersebut haruslah suatu bilangan integer non-negatif. Must
1.2 Penambahan ekslusif Balance dapat ditambah hanya bila menggunakan terminal. Must
1.3 Pengurangan ekslusif Balance dapat dikurangi hanya bila menggunakan terminal Must
1.4 Spesifikasi balance Balance dapat di-update dengan jumlah tertentu. Must
1.5 Spesfikasi balance awal Balance awal dari smart card diset pada jumlah tertentu. Must
1.6 Non-repudiasi Ada log pada kartu untuk melacak 16 transaksi terakhir. Optional

(b) Terminal
ID Nama Deskripsi Kepentingan
2.1 Fungsi penambahan pada Terminal Terminal dapat menambah balance pada smart card dan menangani kasus overflow. Must
2.2 Fungsi pengurangan pada Terminal Terminal dapat mengurangi balance pada smart card dan menangani kasus underflow. Must
2.3 Akses balance pada Terminal Terminal dapat membaca jumlah dari balance pada kartu Must
2.4 Akses log pada Terminal Terminal dapat membaca log pada kartu. Optional
II.2. Kebutuhan-Kebutuhan Non-Fungsional
(a) Card + Applet
ID Nama Deskripsi Kepentingan
3.1 Performa Transaksi kartu harus cepat, dimana setiap transaksi dapat dilakukan dalam 1 detik. Must

(b) Terminal
ID Nama Deskripsi Kepentingan
4.1 Keamanan Transaksi kartu aman (seperti 3DES) Must
4.2 Performa Setiap transaksi kartu harus cepat (dalam 1 detik) Must

II.3. Komponen yang Digunakan
(a) Perangkat Keras untuk Terminal
For the terminal the following hardware is used:
• Windows XP compatible computer dengan konektor USB
• Contact Smart Card Reader (GempPC Twin)

(b) Smart card
Smart-card berikut ini yang digunakan:
• JCOP id21
• JCOP bio31

II.4. Interface-Interface
(c) Perangkat Keras

Sistem terminal terdiri dari suatu PC yang terhubung pada CHIPdrive (GempPC Twin) melalui port USB.
(d) Perangkat lunak

PC/SC menjadi interface terhadap perangkat keras [12]. OCF menyediakan suatu framework untuk solusi bagi smart card yang inter-operable yang digunakan oleh perangkat lunak dari Terminal. Applet java yang berjalan pada smart card menggunakan framework JCOP. IBM JCOP adalah suatu implementasi dari sejumlah standard smart card terbuka seperti JavaCard™, GlobalPlatform dan ISO (7816, 14443).

LAMPIRAN C. TEST LIST

Id Deskripsi Hasil
TC01 Mengetes fungsi personalisasi kartu (personalizedCard) OK
TC02 Mengetes fungsi autorisasi pengguna (verifyPin) OK
TC03 Mengetes fungsi penampilan nilai simpanan (getBalance) OK
TC04 Mengetes fungsi pengurangan nilai simpanan (debet) dengan jumlah X, dimana nilai simpanan adalah > X dan X>0 OK
TC05 Underflow. Mengetes fungsi pengurangan nilai simpanan (debet) dengan jumlah X, dimana nilai simpanan X OK
TC07 Overflow. Mengetes fungsi penambahan nilai simpanan (credit) dengan jumlah X, dimana nilai simpanan sudah maksimum dan X > 1 OK
TC08 Mengetes fungsi penampilan log (log) OK
TC09 Mengetes sistem logging transaksi pengguna setelah pertama kali diinisialisasi OK
TC10 Mengetes sistem logging transaksi pengguna setelah transaksi debet pertama OK
TC11 Mengetes sistem logging transaksi pengguna setelah transaksi credit pertama OK
TC12 Mengetes sistem logging transaksi pengguna setelah transaksi debet ke-11 OK
TC13 Mengetes sistem logging transaksi pengguna setelah transaksi credit ke-11 OK

LAMPIRAN D. PENGELOLAAN SUMBER DAYA

Dalam suatu Java Card, semua jenis sumber daya sangatlah terbatas. Hal ini dikarenakan oleh ukuran fisik dari kartu yang relatif kecil, walaupun pada dasarnya teknologi ini sudah sangat berkembang sehingga memungkinkan ukuran memory dan sumber daya lainnya menjadi lebih besar. Sebagai akibatnya, semua pembangun applet harus menyadari hal ini dan selalu berusaha untuk mengawai konsumsi sumber daya dari applet yang ia bangun. Bagian ini akan menjelaskan beberapa topik sebagai berikut:
– Pengelolaan EEPROM secara umum
– Pengelolaan dan pengalokasian obyek
– Pengelolaan RAM
Secara khusus beberapa strategi untuk mengelola sumber daya akan diilustrasikan disini.
I. Pengelolaan EEPROM
I.1. Pengorganisasi EEPROM
EEEPROM dalam suatu Java Card umunya memiliki hal-hal berikut ini:
– Data sistem global, data seperti ini meliputi antara lain buffer-buffer yang digunakan sebagai backup untuk integritas, atau informasi global lainnya tentang kartu itu sendiri. Data ini juga mungkin meliputi sejumlah data yang dikelola kode native (contohnya file-file yang ditangani oleh file system native)
– Bytecode, kode yang didownload oleh semua aplikasi dan library disimpan dalam EEPROM. Pada kebanyakan aplikasi, kode mengkonsumsi relatif cukup banyak ruang EEPROM.
– Obyek-obyek Java, semua obyek-obyek java disimpan di dalam EEPROM. Ini meliputi obyek-obyek yang dibuat oleh aplet ROM dan juga applet-aplet yang di-download.
I.2. Paket-Paket dan Kode
Paket-paket dan kode dapat disimpan baik di dalam ROM maupun di dalam EEPROM. Disini kita hanya membicarakan tentang kode yang disimpan EEPROM. Ada dua jenis paket seperti ini, yaitu:
– Library packages, suatu paket library yang tidak mengandung komponen applet. Ini berarti bahwa paket ini tidak mengandung kelas applet apapun yang dapat diinstansiasi. Dalam paket seperti ini semua kelas yang dideklarasikan sebagai publik dimungkinkan untuk dilink.
– Application packages, suatu paket aplikasi adalah suatu paket yang mengandung suatu komponen applet. Ini berarti bahwa paket ini mengandung setidaknya satu kelas applet yang dapat diinstansiasi, dan kelas ini telah diasosiasikan dengan suatu AID applet. Dalam paket seperti hanya antarmuka yang mengekstensi antarmuka yang di-share yang dibuat publik.
Untuk kedua jenis paket ini dimungkinkan untuk menghitung jumlah memory yang diperlukan untuk menyimpan suatu paket maupun memasukkan paket untuk suatu platform tertentu. Nilai yang terakhir biasanya lebih tinggi sedikit dibanding yang pertam. Ini dikarenakan proses memasukkan paket membutuhkan pengalokasian buffer sementara. Akan tetapi, hal ini jarang memunculkan masalah karena biasanya ukuran overhead cukup kecil, khususnya dibandingkan dengan jumlah data yang dibutuhkan oleh suatu applet atau dibandingkan dengan ukuran dari applet itu sendiri.
I.3. Obyek
Obyek-obyek dapat disimpan baik di dalam EEPROM maupun dalam RAM. Akan tetapi, kebanyakan obyek disimpan di dalam EEPROM. Ada sejumlah strategi untuk pengalokasian dan pengelolaan obyek yang dapat sangat mempengaruhi total jumlah ruang yang diperlukan oleh suatu obyek.

II. Pengelolaan dan Pengalokasian Obyek
II.1. Biaya dari Suatu Obyek
Suatu obyek melingkupi ruang memory karena dua alasan utama, yaitu:
– Ruang untuk menyimpan komponen-komponennya (elemen-elemen field, array)
Ruang ini bergantung pada tipe dari komponen, dan akan dijelaskan lagi kemudian.
– Ruang overhead dibutuhkan oleh sistem pengelola memory.
Overhead ini mencakup setidaknya satu header, dan kadang-kadang lebih, sebagaimana dijelaskan kemudian.

Dalam obyek-obyek instan dari kelas, semua field melingkupi setidaknya 2 byte memory, termasuk field-field byte dan Boolean. Pada suatu platform yang tidak mendukung integer 32 bit, semua field melingkupi 2 byte. Sebagai akibatnya, sangatlah mahal untuk mendefinisikan banyak field byte dan Boolean dalam suatu obyek. Dimungkinkan untuk mengurangi ukuran dari obyek-obyek dengan cara mengelompokkan field-field ini kedalam field short 16 bit. Untuk array, situasinya sedikit berbeda. Pada suatu array dari byte, setiap elemen hanya melingkupi 1 byte. Satu-satunya pengecualian disini adalah tipe data Boolean, dimana untuk semua impelementasi Gemplus, suatu array dari nilai Boolean membutuhkan satu byte untuk setiap elemen (kebanyakan dikarenakan instruksi bytecode yang digunakan untuk array ini sama dengan array byte).
II.2. Mengatasi Pengalokasian Obyek
Pada platform Java Card 2.1., pengalokasian obyek perlu dibatasi dengan dua alasan, yaitu:
– Memory yang ada sangat terbatas
– Tidak ada cara untuk mendaur ulang memory yang digunakan oleh obyek-obyek yang terhilang. Memory yang digunakan oleh suatu applet dan obyek-obyeknya hanya akan dilepas ketika baik applet maupun keseluruhan paket dihapus.
Ada 3 strategi yang dapat dilakukan untuk mengatasi pengalokasian obyek, yaitu:
– Alokasikan semua obyek pada saat instalasi applet.
Strategi ini sering direkomendasikan, khususnya oleh Sun. Untuk applet sederhana dengan jumlah data yang tetap, strategi ini sangatlah aman. Hal yang paling penting adalah bahwa proses instalasi akan gagal ketika memory tidak cukup tersedia pada kartu untuk mengalokasikansemua obyek-obyek, yang berarti memudahkan untuk menemukan kembali semua ruang memory yang dilingkupi oleh instansiasi dari suatu applet.
– Alokasi semua obyek pada saat instalasi dan personalisasi applet
Pada applet yang lebih kompleks, pengguna applet ditawari dengan fleksibilitas yang terlalu besar, dan tidaklah beralasan untuk mengalokasikan semua obyek-obyek pada saat instalasi applet. Akan tetapi, sangat sering, pengalokasian dapat dibatasi pada fase personalisasi (pada saat semua obyek diinisialisasi). Kelemahan dari pendekatan ini adalah jika applet kekurangan memory pada akhir fase personalisasi, ada ruang-ruang yang terhilang. Kelemahan yang lain adalah suatu perintah yang mengalokasikan obyek-obyek mungkin tidak sengaja tersedia bagi user untuk digunakan setelah fase personalisasi.
– Alokasi obyek-obyek ketika mereka dibutuhkan
Pendekatan ini sangatlah berbahaya, karena applet mungkin kekurangan memory pada suatu saat. Hal ini hanya dipersiapkan untuk applet yang sangat terbuka, dan harus diasosiasikan kepada suatu tindakan jaga-jaga tertentu. Contohnya, semua perintah yang boleh men-trigger suatu proses pengalokasian hanya tersedia pada mode dengan kepemilikan khusus.

III. Pengelolaan RAM
III.1. Obyek Transient
Obyek yang transient memiliki dua buah properti yang membuatnya sangat praktis untuk applet-applet, yaitu:
– Field-fieldnya dapat diakses dengan cepat dan berulang-ulang (sangat berguna untuk informasi yang sering dimodifikasi, seperti suatu referensi pada ‘file terkini’ atau ‘record terkini’).
– Field-field direset ketika suatu even tertentu muncul, sehingga obyek-obyek tersebut dapat digunakan untuk menyimpan status keamanan.
Akan tetapi, kedua properti ini membutuhkan field-field dari obyek-obyek tersebut tersimpan dalam RAM, yang sangatlah terbatas. Oleh karena itu, pengalokasian obyek-obyek ini haruslah sangat terkotrol.
Pada Java Card 2.1., obyek-obyek transient hanya boleh dalam bentuk array. Suatu aturan standard dapat digunakan untuk menentukan ukuran yang dilingkupi oleh suatu array transient: Object descriptor disimpan di EEPROM, dan elemen-elemen dari array yang disimpan di RAM. Hal ini membuat penghitungan jumlah RAM yang dikonsumi menjadi lebih mudah.
Akan tetapi, ada dua jenis obyek transient, yaitu:
– Obyek transient CLEAR_ON_DESELECT dihapus setiap kali suatu applet di-deselect ( yakni, ketika applet lain yang dipilih, atau ketika kartu direset). Obyek-obyek ini digunakan untuk semua field-field standard.
– Obyek transient CLEAR_ON_RESET dihapus hanya ketika kartu direset. Fitur ini dapat menjadi sangat berguna untuk mempertahankan suatu nilai atas beberapa pemilihan applet.
Obyek transient CLEAR_ON_RESET biasanya adalah obyek-obyek yang di-share, karena obyek ini adalah satu-satunya obyek untuk applet yang diakses melalui mekanisme shareable. Obyek transient CLEAR_ON_DESELECT adalah overlaid, dan karenanya hanya applet yang terpilih pada satu saat yang dapat mengaksesnya.
III.2. Obyek Sementara
Obyek sementara (temporary object) adalah suatu tipe obyek yang tidak wajib, yang saat ini sedang dibahas dalam Java Card Forum, dan akan distandardisasi pada spesifikasi Java Card berikutnya. Obyek ini hanya digunakan untuk applet-applet yang akan dimasukkan pada kartu GemExpresson 211 karena interoperabilitas tidak dapat dijamin pada saat ini.

LAMPIRAN E. TEST CASPER

Iterasi ke-0
— Bilateral Key Exchange

— abstract protocol

#Free variables
A, B : Agent
na, nb, nc, nd : Nonce
pk : Agent -> PublicKey
sk : Agent -> SecretKey
kab : SessionKey
InverseKeys = (pk,sk), (kab,kab)

#Processes
INITIATOR(A,na,nc) knows pk, sk(A)
RESPONDER(B,nb,kab,nd) knows pk, sk(B)

#Protocol description
0. -> A : B
1. A -> B : { na, A }{ pk(B) }
2. B -> A : { na, nb, B, kab }{ pk(A) }
3. A -> B : { nb }{ kab }
4. B -> A : B
5. A -> B : { nc }{ kab }
6. B -> A : { nd }{ kab }

#Specification
Agreement(A,B,[na,nb])
Agreement(B,A,[na,nb])
— Secret(A,kab,[B])
— Secret(B,kab,[A])
Secret(A,nc,[B])
Secret(B,nd,[A])

— concrete protocol

#Actual variables
Alice, Bob, Mallory : Agent
Na, Nb, Nm , Nc, Nd: Nonce
Kab : SessionKey
InverseKeys = (Kab,Kab)

#Functions
symbolic pk, sk

#System
INITIATOR(Alice,Na,Nc)
RESPONDER(Bob,Nb,Kab,Nd)

#Intruder Information
Intruder = Mallory
IntruderKnowledge = { Alice, Bob, Mallory, Nm, pk, sk(Mallory) }

Iterasi ke-1
— Bilateral Key Exchange with sequence numbers during the session

— abstract protocol

#Free variables
A, B : Agent
na, nb, nc, nd : Nonce
pk : Agent -> PublicKey
sk : Agent -> SecretKey
kab : SessionKey
nr1: Number1
nr2: Number2
InverseKeys = (pk,sk), (kab,kab)

#Processes
INITIATOR(A,na,kab,nc,nr1) knows pk, sk(A)
RESPONDER(B,nb,nd,nr2) knows pk, sk(B)

#Protocol description
0. -> A : B
1. A -> B : { na, A,kab }{ pk(B) }
2. B -> A : { na, nb, B }{ pk(A) }
3. A -> B : { nb }{ kab }
4. B -> A : B
5. A -> B : { nc,nr1 }{ kab }
6. B -> A : { nd,nr2 }{ kab }

#Specification
Agreement(A,B,[na,nb,kab])
Agreement(B,A,[na,nb,kab])
Secret(A,nc,[B])
Secret(B,nd,[A])

— concrete protocol

#Actual variables
Alice, Bob, Mallory : Agent
Na, Nb, Nm , Nc, Nd: Nonce
Nr1: Number1
Nr2: Number2
Kab : SessionKey
InverseKeys = (Kab,Kab)

#Functions
symbolic pk, sk

#System
INITIATOR(Alice,Na,Kab,Nc,Nr1)
RESPONDER(Bob,Nb,Nd,Nr2)

#Intruder Information
Intruder = Mallory
IntruderKnowledge = { Alice, Bob, Mallory, Nm, Nr1, Nr2, pk, sk(Mallory) }

Tinggalkan Balasan

Please log in using one of these methods to post your comment:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s