👂🏾 🆚 🦃 Kartu pintar. Bagian 4. JavaCard 🎈 🏕️ ✒️

Halo Giktayms!

Hari ini saya ingin berbicara tentang JavaCard. Artikel ini akan fokus pada konsep JavaCard dan tinjauan arsitekturnya. Jika ada minat pada topik ini, maka saya bisa menulis serangkaian artikel terpisah di mana semua aspek JavaCard akan dibahas secara rinci. Saya akan segera mengatakan bahwa saya tidak akan mengajari Anda cara menulis aplikasi pertama Anda di JavaCard, karena sudah ada terlalu banyak artikel di internet tentang ini. Hari ini kita akan berbicara tentang cara kerja JavaCard.

Jadi, kartu pintar berbasis JavaCard adalah kartu tempat aplikasi berjalan pada JavaCard Virtual Machine (versi terbatas Java Virtual Machine yang disesuaikan untuk kartu pintar) dalam apa yang disebut JavaCard Runtime Environment (yang memiliki sedikit kesamaan dengan Java Runtime Environment) .

Dalam hal terminologi, aplikasi disebut Applet dan terkandung dalam Paket. Paket didistribusikan dalam file CAP (bukan file Jar). Paket dan aplikasi memiliki AID (Application Identifier) mereka sendiri. Ini diperlukan agar mereka dapat diidentifikasi secara unik dalam perintah seperti: SELECT, INSTALL, DELETE, dll. (SELECT dijelaskan dalam ISO7816-4, dan JavaCard dan perintah lain dijelaskan dalam Platform Global).

Siklus hidup Applet sedikit berbeda dari siklus hidup aplikasi komputer yang biasa. Applet adalah setiap kelas yang mewarisi dari kelas dasar Applet. Saat memasang aplikasi, metode pemasangan statisnya disebut. Metode ini harus membuat objek dari kelas yang sesuai dan memanggil metode register di atasnya. Selanjutnya, objek akan disimpan dalam sistem dan akan menerima AID sendiri, yang akan digunakan untuk komunikasi lebih lanjut dengan aplikasi. Objek dan bidang datanya disimpan dalam NVM (Non-Volatile Memory). Setiap objek atau array yang dibuat oleh aplikasi menggunakan operator "baru" juga akan berada di NVM. Ini berarti, tidak seperti program komputer tradisional, keadaan aplikasi JavaCard adalah konstan dan tidak hilang bahkan ketika kartu dimatikan.

Komunikasi dengan aplikasi

Setiap saat, setiap saluran logis terbuka memiliki satu aplikasi aktif. Aplikasi aktif adalah aplikasi yang menerima semua APDU yang dikirim oleh terminal. Ketika APDU diterima, JavaCard memanggil metode proses aplikasi aktif, yang menjadikan APDU yang diterima sebagai satu-satunya parameter. Metode ini adalah inti dari Applet, karena memproses permintaan dari terminal. APDU yang dihasilkan juga digunakan untuk mengirim tanggapan.

Applet dapat diaktifkan dengan dua cara:

saat mengatur ulang kartu atau ketika membuka saluran logis, sistem biasanya mengaktifkan aplikasi yang ditandai sebagai Aplikasi Default
menggunakan perintah SELECT dengan P1 = 0x04 dan AID (penuh atau sebagian) dari aplikasi dalam Data

Ketika aplikasi diaktifkan menggunakan perintah SELECT, segera setelah aktivasi metode proses dengan APDU yang berisi perintah ini akan dipanggil. Dengan demikian, Applet dapat mengirim informasi sebagai respons terhadap perintah SELECT ketika diaktifkan. Kelas Applet menyediakan metode pemilihanApplet () untuk menentukan apakah perintah yang diterima menyebabkan aplikasi untuk diaktifkan.

Aplikasi ini juga memiliki kemampuan untuk menulis ulang metode select () dan deselect () agar masing-masing diinisialisasi selama aktivasi dan de-inisialisasi selama de-aktivasi. Metode-metode ini akan dipanggil terlepas dari bagaimana aplikasi itu diaktifkan.

Saluran logis dapat dibuka dan ditutup menggunakan perintah MANAGE CHANNEL. Melalui saluran logis terbuka, Anda dapat mengirim perintah apa pun, termasuk SELECT. Ini adalah SELECT dan MANAGE CHANNEL yang merupakan satu-satunya perintah yang diproses langsung oleh sistem, dan bukan oleh aplikasi yang aktif. Meskipun dalam kasus perintah SELECT, kita dapat mengatakan bahwa itu diproses oleh sistem dan aplikasi yang aktif.

Aturan lengkap untuk menjalankan aplikasi dan memproses perintah SELECT cukup kompleks, dan ada sedikit kontradiksi antara JavaCard dan Platform Global. Namun, saya akan membahas topik ini di salah satu artikel saya berikutnya. Sekarang perlu dikatakan bahwa kartu sering mengikuti aturan yang dijelaskan dalam Platform Global.

Manajemen memori

Seperti yang saya katakan di atas, objek dan array disimpan secara default di NVM. Selain NVM, JavaCard juga memungkinkan untuk membuat array dalam RAM menggunakan sejumlah metode dari kelas JCSystem. Ada 2 jenis memori sementara: Clear on Reset dan Clear on Deselect. Yang pertama dihapus ketika kartu dimatikan atau diatur ulang. Yang kedua dihapus ketika Applet tidak lagi aktif (yaitu: ketika SELECT aplikasi lain, shutdown, reset, dll.). Perlu dicatat bahwa meskipun isi array dihapus (mis., Semua nol atau salah ditulis di sana), array itu sendiri tetap ada, dan itu dapat, misalnya, disimpan dalam bidang data objek.

Apa yang disimpan dalam NVM:

Semua objek dan bidang datanya.
Semua array.
Isi dari array yang dibuat oleh operator baru.

Apa yang disimpan dalam RAM (CLEAR_ON_RESET atau CLEAR_ON_DESELECT):

, JCSystem.makeTransient<>Array. , , , JCSystem.makeTransientObjectArray(), NVM. RAM.
Global Arrays: (APDU Install Parameters ), Global Arrays, JCSystem.makeGlobalArray().
. .

Suatu aplikasi, sebagai suatu peraturan, harus membuat semua objek dan array yang dibutuhkan selama instalasi, dan tidak secara dinamis. Alasan untuk ini terutama dua faktor:

1) Keinginan untuk memastikan bahwa setelah instalasi aplikasi berhasil, ia tidak akan berhenti bekerja jika beberapa aplikasi lain mengambil semua memori bebas.
2) Pengumpul sampah - fungsi opsional (walaupun sangat umum). Ini berarti bahwa ketika membuat objek secara dinamis, ada risiko bahwa objek yang dibuat tidak akan pernah dihapus. Seiring waktu, ini akan menyebabkan kurangnya memori bebas. Bahkan jika ada pengumpul sampah, prosedur ini tidak terjadi secara otomatis, tetapi atas permintaan aplikasi (JCSystem.requestObjectDeletion ()).

Selanjutnya, kode aplikasi jarang diperoleh "bersih" dalam hal pemrograman berorientasi objek. Menggunakan byte umum [] untuk banyak operasi berbeda adalah praktik yang sangat umum. Kelas yang hanya terdiri dari metode statis dan berjalan pada byte [] juga tidak jarang. Selain itu, pembuatan kelas dan objek diminimalkan. Memori kecil dan harus dilindungi di semua biaya.

Perlu juga diperhatikan peran objek APDU. Buffer yang terletak di RAM dihapus sebelum menerima setiap perintah. Merupakan kebiasaan untuk menggunakannya tidak hanya untuk membentuk jawaban, tetapi seringkali bahkan sebagai penyangga sementara. Ukurannya setidaknya 256 byte atau lebih besar jika kartu mendukung Panjang yang Diperpanjang.

Firewall applet

Fitur penting dari JavaCard yang dapat membingungkan programmer adalah keberadaan yang disebut Applet Firewall. Tujuan Firewall adalah untuk mencegah Applet mengakses data orang lain. Saya harus mengatakan segera bahwa JavaCard memungkinkan komunikasi antara aplikasi menggunakan Shareable Interfaces, dan juga bahwa paket adalah pustaka kelas dan fungsi yang dapat digunakan dalam aplikasi yang berbeda. Itu sebabnya ada kebutuhan untuk firewall. Prinsip dasar dari Applet Firewall adalah sebagai berikut:

Setiap aplikasi milik satu konteks. Semua aplikasi dari paket yang sama milik konteks yang sama.
Setiap objek milik satu aplikasi atau sistem.
Paket tanpa aplikasi (perpustakaan) tidak memiliki konteks. Objek dari kelasnya milik aplikasi yang membuatnya.
Selalu ada satu konteks aktif dalam sistem.
(/ ) , .
.
. . , , firewall.
CLEAR_ON_DESELECT , .

Menggunakan Shareable Interface, seorang programmer dapat memungkinkan metode tertentu dari satu objek tersedia untuk aplikasi dari konteks yang berbeda. Ketika salah satu dari metode ini dipanggil, sistem akan mengalihkan konteks ke konteks di mana objek yang menyediakan Shareable Interface. Ini berarti bahwa metode ini hanya memiliki akses ke objek yang termasuk dalam konteksnya, dan jika, misalnya, Anda melewatkan byte metode ini [] sebagai parameter dari konteks asli, kesalahan akan terjadi selama akses. Setelah menyelesaikan eksekusi metode, konteks beralih kembali ke yang asli.

Aplikasi ini juga memiliki akses ke objek tertentu yang termasuk dalam sistem. Objek semacam itu disebut Entry Points. Ada dua jenis Entry Point: sementara dan permanen. Titik Masuk Permanen sederhana, akses ke sana diizinkan dari konteks apa pun. Contoh dari ini adalah objek dari kelas AID. Sementara Entri Sementara, memiliki batasan yang mencegah mereka disimpan dalam bidang data objek atau bidang statis kelas. Contoh dari Entry Point sementara adalah objek APDU.

Dimulai dengan JavaCard 3.0.4, dimungkinkan juga untuk membuat Global Array menggunakan metode JCSystem.makeGlobalArray (). Perilaku mereka persis sama dengan perilaku Titik Masuk sementara. Mereka terutama diperlukan sebagai parameter untuk metode yang disebut menggunakan teknik Shareable Interface.

Atomicity dan transaksi

JavaCard menjamin operasi atom ketika mengubah bidang data objek atau kelas. Atomicity juga disediakan oleh metode yang bekerja pada array (kecuali untuk mereka yang memiliki akhiran NonAtomic dalam namanya). Ini berarti bahwa, misalnya, Util.arrayCopy akan menyalin semua byte (jika dijalankan dengan sukses) atau membiarkan array tidak berubah jika terjadi kesalahan atau kehilangan energi.

Jika Anda perlu melakukan perubahan di beberapa bidang konstan dan array dalam satu operasi atom, maka JavaCard juga menyediakan fungsi JCSystem.beginTransaction () untuk memulai transaksi dan JCSystem.commitTransaction () untuk menyelesaikannya. Semua perubahan yang terjadi dalam array dan bidang konstan antara panggilan ke JCSystem.beginTransaction () dan JCSystem.commitTransaction () akan secara otomatis menjadi bagian dari transaksi. Jika transaksi dibatalkan karena kesalahan, kehilangan energi, atau panggilan ke metode JCSystem.abortTransaction (), sistem akan mengembalikan keadaan semula. Perlu diingat bahwa implementasi teknis transaksi menggunakan buffer sistem tambahan. Jika buffer penuh, maka sistem memberikan kesalahan TransactionException.

Rmi

JavaCard mendukung teknologi RMI (Remote Metod Invocation). Dalam artikel ini saya tidak akan mendedikasikan teknologi ini. Saya hanya dapat mengatakan bahwa fungsi ini tidak umum, dan banyak kartu tidak mendukungnya.

API

Sebagian besar JavaCard API didedikasikan untuk kriptografi. Ada kelas untuk mengenkripsi, membuat dan memverifikasi tanda tangan digital, menghasilkan kunci dan angka acak, menghitung checksum dan hash, dan juga untuk menerapkan skema pertukaran kunci. Selain kriptografi, JavaCard juga menyediakan kelas untuk menyimpan dan memverifikasi PIN dan bahkan data biometrik. Kelas-kelas yang tersisa menyediakan akses ke fungsionalitas yang dijelaskan dalam bab-bab lain atau tambahan untuk bekerja dengan string, angka, TLV, dll. Adapun API, itu akan ditafsirkan dalam seri artikel lain.

Keterbatasan JavaCard utama dibandingkan dengan Java

Bahasa pemrograman aplikasi JavaCard adalah Java. Hampir di Jawa. Jadi, tipe char, float, double, long dan enum tidak didukung. Tipe int adalah opsional untuk kartu (biasanya kartu modern mendukungnya) dan penggunaannya, jika tidak diaktifkan oleh opsi yang sesuai, akan menyebabkan kesalahan ketika mengkonversi aplikasi ke file CAP. Lupakan, iterator dan lambda. Generik, impor statis, dan anotasi (hanya Runtime Invisible) didukung oleh konverter sejak versi 3.0.0 mereka tidak mempengaruhi eksekusi kode.

Untuk mengkompilasi kode, kompiler JDK biasa digunakan. Kesalahan inkompatibilitas hanya akan terlihat saat mengonversi ke file CAP atau saat menggunakan IDE pintar untuk JavaCard.

Masalah terbesar bagi pemrogram, pada kenyataannya, adalah kurangnya int secara default. Biasanya, mereka benar-benar tidak diperlukan, jadi saya tidak ingin mengaktifkannya secara tidak perlu. Namun, kompiler Java memiliki kebiasaan untuk secara otomatis menampilkan hasil dari semua operasi aritmatika ke int. Untuk menghindari hal ini, Anda harus menggunakan tipe gips eksplisit untuk pendek atau byte dalam kode, yang membuat kode kurang dibaca.

Keterbatasan lain terjadi dalam inisialisasi bidang statis, yaitu, bahwa mereka dapat diinisialisasi hanya dengan konstanta dan array yang mengandung konstanta, tetapi tidak dengan objek.

Kesimpulan

Jadi ini adalah pengantar saya ke JavaCard. Jika Anda menemukan artikel ini menarik atau, setidaknya, membangkitkan minat Anda pada topik ini, maka Anda dapat menulis di komentar apa yang secara khusus ingin Anda ketahui lebih lanjut. Jadi saya bisa memutuskan dalam urutan apa dan berapa banyak detail untuk menulis tentang fungsi dan aplikasi JavaCard tertentu. Bagaimanapun, artikel Platform Global berikutnya akan menyimpulkan seri ini.

Kartu pintar. Bagian 4. JavaCard