Menggunakan Mifare Ultralight C Dengan RC522 di Arduino: 3 Langkah

2024 Pengarang: John Day | [email protected]. Terakhir diubah: 2024-01-30 09:53

Menggunakan teknologi RFID untuk mengidentifikasi pemegang kartu atau memberi wewenang untuk melakukan sesuatu (membuka pintu, dll.) adalah pendekatan yang cukup umum. Dalam kasus aplikasi DIY modul RC522 banyak digunakan karena cukup murah dan banyak kode ada untuk modul ini.

Dalam kebanyakan kasus, UID kartu digunakan untuk “mengidentifikasi” pemegang kartu, dan kartu Mifare Classic digunakan karena harganya murah dan sering disertakan saat membeli modul RC522.

Tetapi seperti yang mungkin Anda ketahui, sistem Mifare Classic telah diretas selama beberapa tahun dan tidak dianggap aman lagi. Sistem enkripsi Crypto1 yang digunakan oleh kartu Klasik dapat diatasi dan ada kartu yang dapat ditulis ulang di mana data UID dapat diprogram ulang (kartu ajaib).

Jadi, untuk aplikasi terkait keamanan apa pun, penggunaan kartu Mifare Classic tidak disarankan! Hal yang sama berlaku untuk (sebagian besar) sistem NTAG dan Mifare Ultralight

Jadi pilihannya adalah menggunakan sistem profesional atau mencoba menggunakan sistem RFID yang lebih aman. Sistem yang tersedia adalah Mifare Ultralight C, Mifare DESFire dan Mifare Plus. Karena ada banyak sistem profesional yang menggunakan sistem yang lebih aman ini, untuk komunitas DIY hampir tidak ada solusi (ada satu solusi DESFire berbasis Teensy, yang berbasis di papan breakout PN523 yang lebih mahal). Selain itu, kartu DESFire cukup mahal. Jadi tantangannya adalah menemukan solusi yang lebih baik dan lebih murah.

Solusi yang disajikan memberikan akses penuh ke kartu Mifare Ultralight “C” murah menggunakan modul RC522 DIY China yang murah. Berdasarkan kode ini, Mifare Ultralight C yang aman dapat digunakan dalam aplikasi DIY.

Langkah 1: Prasyarat

Meskipun RC522 dirancang dengan baik, dalam banyak kasus pembuatannya buruk karena beberapa komponen memiliki dimensi yang buruk. Ini mengarah pada reputasi buruk modul yang memiliki sensitivitas rendah dan tidak semua jenis kartu akan diidentifikasi. Khususnya Mifare Ultralight C tidak akan teridentifikasi dan tidak mungkin untuk membaca kartu.

Masalah utama adalah spesifikasi induktor L1 dan L2. Seperti yang dijelaskan di https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. Hanya dengan mengganti induktor ini ke yang sesuai mis. FERROCORE CW1008-2200 tiba-tiba RC522 menunjukkan apa potensi sebenarnya.

Jadi sebelum mencoba kode yang diberikan, Anda HARUS MENGGANTI induktor. Itu tidak akan bekerja dengan induktor yang sudah diinstal sebelumnya!

Latar belakang dari semua ini adalah, bahwa kartu Ultralight C cukup haus energi. Energi ini disediakan oleh medan RF RC522. Karena arus listrik induktor yang rendah, medan energi tidak cukup kuat untuk memberi daya pada Ultralight C. Kartu lain seperti Mifare Classic hanya membutuhkan lebih sedikit daya dan oleh karena itu bekerja dengan cukup stabil.

Langkah 2: Bagaimana Cara Kerjanya?

Jadi setelah memodifikasi modul RC522, bagaimana Anda bisa menggunakan Mifare Ulralight C untuk aplikasi Anda?

Caranya adalah, bahwa Mifare Ultralight C mendukung otentikasi kata sandi berdasarkan cipher 3DES. Dengan menggunakan kata sandi ini, isi kartu dapat dibuat “hanya baca” atau sama sekali tidak terlihat oleh pengguna yang tidak berwenang.

Untuk menggunakan perlindungan kata sandi ini, kata sandi perlu ditulis ke kartu dan halaman harus dilindungi. Setelah selesai, Anda dapat memverifikasi kartu di aplikasi Anda baik dengan hanya meminta otentikasi berbasis kata sandi atau data tambahan siap dari area yang dilindungi. Hanya jika ini berhasil, Anda tahu bahwa Anda dapat mempercayai UID yang disediakan pada kartu.

Hati-hati: tanpa otentikasi berbasis kata sandi, Anda masih tidak dapat mempercayai kartu Mifare Ultralight C, karena ada juga “kartu ajaib” yang mensimulasikan Ultralight C.

Setiap kartu yang tidak bergantung pada teknologi (jika dalam frekuensi yang benar) akan merespons dengan UID mereka saat diberi daya oleh medan RF dan meminta untuk mengidentifikasi diri mereka sendiri. Selain itu, mereka memberikan nilai SAK yang memberikan informasi minimal tentang jenis kartu yang ada. Sayangnya semua Mifare Ultralight dan NTAG mengidentifikasi sebagai tipe syme (SAK=0x00), termasuk Mifare Ultralight C. Jadi saat polling kartu, setidaknya nilai SAK 0x00 akan memberikan petunjuk bahwa mungkin ada Ultralight C pada pembaca.

Untuk memastikan itu adalah Ultralight C, permintaan untuk otentikasi terenkripsi dapat dikirim ke kartu. Jika ini BUKAN kartu Ultralight C, permintaan ini tidak akan dipahami, dan responsnya adalah NAK (bukan pengakuan).

Jika ini adalah kartu Ulralight C, Anda akan mendapatkan jawaban 8 byte. 8 Bytes ini adalah nomor acak "B" (RndB) yang dienkripsi oleh kunci yang tersimpan di kartu menggunakan cipher 3DES.

RndB terenkripsi ini harus didekripsi menggunakan kunci yang sama dalam program. Angka acak ini kemudian sedikit dimodifikasi (diputar satu byte → byte 1 akan dipindahkan ke byte 8 dan semua byte lainnya didorong satu byte lebih rendah, kemudian disebut RndB’). Program kemudian menghasilkan angka acak 8 Byte "A" itu sendiri (RndA) dan menempelkan RndA ini ke RndB’ yang dimodifikasi. Ini sekali lagi dienkripsi menggunakan kunci dan dikirim ke kartu.

Kartu mendekripsi pesan dan memeriksa apakah RndB’ cocok dengan RndB yang dibuat sebelumnya pada kartu. Jika cocok, kartu sekarang tahu, bahwa program mengetahui kuncinya.

Pada titik ini, program masih belum mengetahui apakah kartu tersebut mengetahui kuncinya dan karena itu dapat dipercaya atau tidak. Untuk mencapai ini, kartu sekarang memutar RndA yang didekripsi sebanyak satu byte, kemudian mengenkripsi byte ini menggunakan kunci dan mengirimkannya kembali.

Program kemudian akan mendekripsi balasan kartu dan memeriksa apakah RndA asli dan RndA yang dibalas cocok. HANYA MAKA kedua entitas (program dan kartu) tahu bahwa mereka berbagi pengetahuan tentang kunci yang sama.

Proses ini hanya digunakan untuk otentikasi. Semua komunikasi lebih lanjut selalu dalam "teks yang jelas".

Meskipun ada kartu "Ultralight C ajaib" di mana UID dapat dimodifikasi, kuncinya sendiri tidak dapat diperoleh dari kartu dan cipher 3DES cukup aman. Kuncinya adalah kunci 16 Byte, jadi pendekatan brute force untuk mendapatkan kunci akan memakan waktu.

Seperti yang dinyatakan, komunikasi sebelum otentikasi dan setelah otentikasi selalu dalam teks yang jelas (alias tidak dienkripsi). Saat menulis kunci baru ke kartu, isi kunci dapat diendus dengan menggunakan peralatan yang tepat. Jadi tolong tulis kuncinya hanya di lingkungan yang aman dan jaga kerahasiaannya.

Saat menggunakan kartu Ultralight C

Kartu Ultralight C memiliki beberapa fitur keamanan bawaan:

1. Memori Pemrograman Satu Kali (OTP). Di area ini bit dapat ditulis, bus tidak dihapus.
2. Penghitung satu arah 16 bit. Penghitung ini hanya dapat bertambah, ketika diakses.
3. Perlindungan “tulis” atau “baca/tulis” halaman di memori. Hanya jika diautentikasi dengan kunci, halaman ini dapat dibaca atau dimodifikasi.
4. Pembekuan / pemblokiran halaman individual untuk melindungi dari modifikasi apa pun.

Baik penggunaan OTP, penghitung 16 bit maupun penggunaan bit pemblokiran tidak diterapkan dalam kode yang diberikan, tetapi dapat dengan mudah diimplementasikan berdasarkan informasi yang diberikan di https://www.nxp.com/docs/en/data- lembar/MF0ICU2.pd…

Karena perlindungan dengan kunci sangat penting untuk menggunakan Mifare Ultralight C, semua fungsi yang relevan hadir.

Semua perintah digunakan di monitor Serial dengan "hanya baris baru" dan dengan 115200 Baud

• “auth 49454D4B41455242214E4143554F5946” akan meminta otentikasi dengan kunci yang diberikan (dalam hal ini kunci standar Mifare Ultralight C)
• "dump" akan membuang konten kartu sejauh terlihat. Jika halaman dilindungi oleh kunci, halaman ini mungkin tidak terlihat hingga autentikasi sebelumnya dengan kunci. Dalam dua kolom pertama ditunjukkan jika halaman dikunci atau akses dibatasi.
• "newKey 49454D4B41455242214E4143554F5946" akan menulis kunci baru ke kartu. Kunci ditulis ke halaman 44 hingga 47. Ini hanya akan berfungsi, jika halaman ini tidak dikunci atau dilindungi tanpa autentikasi sebelumnya.
• "wchar 10 hello world" akan menulis "hello world" mulai dari halaman 10. Sekali lagi, ini hanya berfungsi pada halaman yang tidak dikunci atau dilindungi tanpa otentikasi sebelumnya. Saat mencoba menulis di atas halaman 39 atau di bawah halaman 4 ini akan meminta kesalahan atau data diabaikan karena halaman ini bukan memori pengguna.
• “whex 045ACBF44688” akan menulis nilai Hex langsung ke memori, kondisi sebelumnya berlaku.
• “protect 30” melindungi semua halaman dari halaman 30 ke atas. Bergantung pada izinnya, halaman-halaman ini kemudian hanya dapat dimodifikasi atau dibaca setelah autentikasi sebelumnya dengan kunci. Menggunakan "protect" dengan nilai lebih tinggi dari 47 akan mengatur semua halaman menjadi "unprotected" TERMASUK KUNCI pada halaman 44-47 (yang hanya dapat dimodifikasi tetapi tidak dapat dibaca). Untuk mencegah perubahan kunci, perlindungan setidaknya harus dimulai dari halaman 44.
• "setpbit 0" mengatur bit perlindungan dan memutuskan apakah halaman yang dilindungi hanya dapat dibaca ("setpbit 1") atau tidak dapat dibaca tidak ditulis ("setpbit 0") tanpa otentikasi sebelumnya dengan kunci.

Tidak semua perintah dapat digunakan segera setelah kartu terdeteksi. Sebuah "dump" sebelumnya ke perintah lain selalu membantu.

Langkah 3: Penting

1. Program membedakan antara jenis Ultralight dengan membaca halaman 43 dan 44. Jika halaman 43 dapat dibaca dan halaman 44 tidak, kemungkinan besar adalah Ultralight C. TAPI, jika Anda membaca/menulis melindungi halaman 43 kartu tidak lagi dikenali sebagai Ultralight C (tidak berpengaruh pada apa pun) Identifikasi Ultralight yang tepat harus dilakukan melalui otentikasi dengan kunci (saya tidak menerapkannya karena alasan stabilitas).
2. Sebelum menggunakan perintah "setpbit" dan "protect" perintah "dump" harus digunakan, jika tidak, status perlindungan halaman tidak akan diketahui.
3. Jika Anda “membaca/menulis” melindungi halaman pertama kartu Anda, program ini tidak akan berfungsi lagi karena halaman pertama terus dibaca untuk melihat apakah masih ada kartu. Karena dua halaman pertama hanya dapat dibaca (UID disimpan di sana), tidak ada gunanya melindunginya.

Masalah stabilitas

Kode ini menggunakan pustaka RC522 “standar” untuk Arduino dan pustaka 3DES dari https://github.com/Octoate/ArduinoDES. Sedangkan library RC522 cukup umum digunakan, library 3DES tampaknya tidak begitu luas dan harus diinstal secara manual.

Kode telah diuji pada Arduino Uno. Namun saat menulisnya, saya menemukan banyak masalah aneh terkait stabilitas. Entah bagaimana keterampilan pemrograman saya tidak begitu baik, salah satu perpustakaan yang digunakan tidak stabil atau mencampur perpustakaan bukanlah ide yang baik.

Harap diingat ini saat menggunakan kode!!!

Mengubahnya atau hanya menggunakan sebagian saja dapat menyebabkan perilaku aneh seperti mogok, mencetak hal-hal aneh atau mendapatkan batas waktu atau NAK saat membaca dari kartu. Ini dapat terjadi di mana saja dalam kode (saya menghabiskan banyak waktu untuk debugging). Jika Anda menemukan alasan untuk ini, tolong beri saya petunjuk.