Menggunakan Mifare Ultralight C With RC522 di Arduino: 3 Steps

2025 Pengarang: John Day | [email protected]. Diubah suai terakhir: 2025-01-23 15:00

Menggunakan teknologi RFID untuk mengenal pasti pemegang kad atau memberi kebenaran untuk melakukan sesuatu (membuka pintu dll) adalah pendekatan yang agak biasa. Sekiranya aplikasi DIY modul RC522 digunakan secara meluas kerana ia cukup murah dan banyak kod ada untuk modul ini.

Dalam kebanyakan kes, UID kad digunakan untuk "mengenal pasti" pemegang kad, dan kad Mifare Classic digunakan kerana harganya murah dan sering disertakan ketika membeli modul RC522.

Tetapi seperti yang anda ketahui, sistem Mifare Classic telah diretas selama beberapa tahun dan tidak lagi dianggap selamat. Sistem penyulitan Crypto1 yang digunakan oleh kad Klasik dapat diatasi dan kad yang dapat ditulis semula di mana data yang UID dapat diprogramkan semula (kad sihir).

Oleh itu, untuk sebarang aplikasi yang berkaitan dengan keselamatan, penggunaan kad Mifare Classic tidak digalakkan! Perkara yang sama berlaku untuk (kebanyakan) sistem NTAG dan Mifare Ultralight

Jadi pilihannya adalah menggunakan sistem profesional atau cuba menggunakan sistem RFID yang lebih selamat. Sistem yang ada ialah Mifare Ultralight C, Mifare DESFire dan Mifare Plus. Oleh kerana terdapat banyak sistem profesional yang menggunakan sistem yang lebih selamat ini, bagi komuniti DIY hampir tidak ada penyelesaian (terdapat satu penyelesaian DESFire berasaskan Teensy, yang berdasarkan pada papan pemecah PN523 yang lebih mahal). Selain itu kad DESFire cukup mahal. Jadi cabarannya adalah mencari jalan keluar yang lebih baik dan lebih murah.

Penyelesaian yang diberikan memberikan akses penuh ke kad Mifare Ultralight “C” yang murah menggunakan modul DIY RC522 Cina yang murah. Berdasarkan kod ini, Mifare Ultralight C yang selamat dapat digunakan dalam aplikasi DIY.

Langkah 1: Prasyarat

Walaupun RC522 dirancang dengan baik, dalam kebanyakan kes tidak dapat dibina dengan baik kerana beberapa komponen kurang dimensi. Ini membawa kepada reputasi buruk modul bahawa ia mempunyai kepekaan yang rendah dan tidak semua jenis kad akan dikenal pasti. Terutama Mifare Ultralight C tidak akan dapat dikenalpasti dan juga tidak boleh membaca kad.

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 dengan yang sesuai mis. FERROCORE CW1008-2200 tiba-tiba RC522 menunjukkan apa potensi sebenarnya.

Jadi sebelum mencuba kod yang diberikan, anda HARUS MENGGANTI induktor. Ini tidak akan berfungsi dengan induktor yang telah dipasang sebelumnya!

Latar belakang semua ini adalah bahawa kad Ultralight C cukup haus tenaga. Tenaga ini disediakan oleh bidang RF522 RF. Kerana amperage rendah dari induktor, medan tenaga tidak cukup kuat untuk menghidupkan Ultralight C. Kad lain seperti Mifare Classic hanya memerlukan lebih sedikit kuasa dan oleh itu berfungsi dengan cukup stabil.

Langkah 2: Bagaimana Ia Berfungsi?

Oleh itu, setelah mengubah modul RC522, bagaimana anda boleh menggunakan Mifare Ulralight C untuk aplikasi anda?

Caranya ialah, bahawa Mifare Ultralight C menyokong pengesahan kata laluan berdasarkan 3DES cipher. Dengan menggunakan kata laluan ini, kandungan kad dapat dibuat "baca sahaja" atau tidak dapat dilihat sepenuhnya oleh pengguna yang tidak sah.

Untuk menggunakan perlindungan kata laluan ini kata laluan perlu ditulis ke kad dan halaman perlu dilindungi. Setelah selesai, anda boleh mengesahkan kad dalam aplikasi anda dengan hanya meminta pengesahan berdasarkan kata laluan atau data siap dari kawasan yang dilindungi. Hanya jika ini berjaya, anda tahu bahawa anda boleh mempercayai UID yang diberikan pada kad.

Hati-hati: tanpa pengesahan berdasarkan kata laluan, anda masih tidak boleh mempercayai kad Mifare Ultralight C, kerana terdapat juga "kad sihir" yang mensimulasikan Ultralight C.

Setiap kad yang bebas dari teknologi (jika dalam frekuensi yang betul) akan bertindak balas dengan UID mereka ketika dikuasakan oleh medan RF dan meminta untuk mengenal pasti diri mereka sendiri. Selain itu mereka memberikan nilai SAK yang memberikan sedikit maklumat mengenai jenis kad yang ada. Malangnya semua Mifare Ultralight dan NTAG dikenal pasti sebagai jenis syme (SAK = 0x00), termasuk Mifare Ultralight C. Oleh itu, semasa mengundi kad, sekurang-kurangnya nilai SAK 0x00 akan memberi petunjuk bahawa mungkin ada Ultralight C pada pembaca.

Untuk memastikannya adalah Ultralight C, permintaan untuk pengesahan yang dienkripsi dapat dikirim ke kad. Sekiranya ini BUKAN kad Ultralight C, permintaan ini tidak akan difahami, dan jawapannya adalah NAK (not-acknolege).

Sekiranya ini kad Ulralight C, anda akan mendapat jawapan 8 bait. 8 Byte ini adalah nombor rawak "B" (RndB) yang dienkripsi oleh kunci yang disimpan pada kad menggunakan cipher 3DES.

RndB yang disulitkan ini mesti didekripsi menggunakan kunci yang sama dalam program ini. Nombor rawak ini kemudian sedikit diubah (dipusingkan oleh satu bait → bait 1 akan dipindahkan ke bait 8 dan semua bait lain ditolak satu bait lebih rendah, kemudian disebut RndB’). Program ini kemudian menghasilkan nombor rawak "A" 8 Byte itu sendiri (RndA) dan melampirkan RndA ini ke RndB yang diubah suai. Ini sekali lagi disulitkan menggunakan kunci dan hantar ke kad.

Kad mendekripsi mesej dan memeriksa apakah RndB sesuai dengan RndB yang dihasilkan sebelumnya pada kad. Sekiranya mereka sepadan, kad sekarang tahu, bahawa program mengetahui kuncinya.

Pada ketika ini, program ini masih tidak mengetahui sama ada kad itu mengetahui kunci dan oleh itu boleh dipercayai atau tidak. Untuk mencapai ini, kad kini memutar RndA yang didekripsi oleh satu bait, kemudian menyulitkan bait ini menggunakan kunci dan menghantarnya kembali.

Program kemudian akan menyahsulit balasan kad dan memeriksa sama ada RndA yang asal dan RndA yang sesuai. HANYA KEMUDIAN kedua-dua entiti (program dan kad) mengetahui bahawa mereka berkongsi pengetahuan mengenai kunci yang sama.

Proses ini hanya digunakan untuk mengesahkan. Semua komunikasi selanjutnya sentiasa dalam "teks yang jelas".

Walaupun terdapat kad "magic Ultralight C" di mana UID dapat diubah suai, kunci itu sendiri tidak dapat diperoleh dari kad dan cipher 3DES cukup selamat. Kuncinya adalah kunci 16 Byte, jadi pendekatan brute force untuk mendapatkan kunci akan memerlukan sedikit masa.

Seperti yang dinyatakan, komunikasi sebelum pengesahan dan selepas pengesahan selalu dalam teks yang jelas (aka tidak disulitkan). Semasa menulis kunci baru pada kad, kandungan kunci dapat dihidu dengan menggunakan peralatan yang betul. Oleh itu, sila tulis kunci hanya dalam persekitaran yang selamat dan rahsiakan kunci.

Semasa menggunakan kad Ultralight C

Kad Ultralight C mempunyai pelbagai ciri keselamatan yang dibina:

1. Memori Satu Kali Pengaturcaraan (OTP). Di kawasan ini bit boleh ditulis, bas tidak dipadamkan.
2. Kaunter sehala 16 bit. Kaunter ini hanya boleh bertambah, apabila diakses.
3. Perlindungan "tulis" atau "baca / tulis" halaman dalam memori. Hanya jika disahkan dengan kunci, halaman ini dapat dibaca atau diubah suai.
4. Pembekuan / penyekat halaman individu untuk melindungi daripada sebarang pengubahsuaian.

Baik penggunaan OTP, penghitung 16 bit atau penggunaan bit penyekat dilaksanakan dalam kod yang diberikan, tetapi dapat dilaksanakan dengan mudah berdasarkan maklumat yang diberikan di https://www.nxp.com/docs/en/data- helaian / MF0ICU2.pd…

Oleh kerana perlindungan dengan kunci sangat penting untuk menggunakan Mifare Ultralight C, semua fungsi yang berkaitan ada.

Semua arahan digunakan dalam monitor Serial dengan "barisan baru sahaja" dan dengan 115200 Baud

• "Auth 49454D4B41455242214E4143554F5946" akan meminta pengesahan dengan kunci yang diberikan (dalam hal ini kunci Mifare Ultralight C standard)
• "Dump" akan membuang kandungan kad sejauh yang kelihatan. Sekiranya halaman dilindungi oleh kunci, halaman ini mungkin tidak dapat dilihat sehingga pengesahan sebelumnya dengan kunci. Dalam dua lajur pertama ditunjukkan jika halaman dikunci atau akses dibatasi.
• "NewKey 49454D4B41455242214E4143554F5946" akan menulis kunci baru untuk kad. Kunci ditulis ke halaman 44 hingga 47. Ini hanya akan berfungsi, jika halaman ini tidak dikunci atau dilindungi tanpa pengesahan sebelumnya.
• "wchar 10 hello world" akan menulis "hello world" bermula dari halaman 10. Sekali lagi, ini hanya karya halaman yang tidak dikunci atau dilindungi tanpa pengesahan sebelumnya. Semasa cuba menulis di atas halaman 39 atau di bawah halaman 4 ini akan mendorong ralat atau data diabaikan kerana halaman ini bukan memori pengguna.
• "Whex 045ACBF44688" akan menulis nilai Hex terus ke memori, syarat sebelumnya berlaku.
• "Melindungi 30" melindungi semua halaman dari halaman 30 ke atas. Bergantung pada kebenaran, halaman ini hanya dapat diubah atau dibaca setelah pengesahan sebelumnya dengan kunci. Menggunakan "melindungi" dengan nilai yang lebih tinggi dari 47 akan menetapkan semua halaman menjadi "tidak dilindungi" TERMASUK KUNCI di halaman 44-47 (yang hanya boleh diubah tetapi tidak dapat dibaca). Untuk mengelakkan perubahan kunci, perlindungan sekurang-kurangnya bermula dari halaman 44.
• "Setpbit 0" menetapkan bit perlindungan dan memutuskan apakah halaman yang dilindungi hanya dapat dibaca ("setpbit 1") atau tidak boleh dibaca tidak ditulis ("setpbit 0") tanpa pengesahan sebelumnya dengan kunci.

Tidak semua perintah dapat digunakan segera setelah kartu itu terdeteksi. "Dump" sebelumnya kepada arahan lain selalu membantu.

Langkah 3: Penting

1. Program ini membezakan antara jenis Ultralight dengan membaca halaman 43 dan 44. Sekiranya halaman 43 dapat dibaca dan halaman 44 tidak, kemungkinan itu adalah Ultralight C. TETAPI, jika anda membaca / menulis melindungi halaman 43 kad tersebut tidak lagi dikenali sebagai Ultralight C (tidak memberi kesan pada apa-apa) Pengenalan Ultralight yang betul harus dilakukan melalui pengesahan dengan kunci (saya tidak melaksanakannya kerana alasan kestabilan).
2. Sebelum menggunakan perintah "setpbit" dan "protect", perintah "dump" mesti digunakan, jika tidak, status perlindungan halaman tidak akan diketahui.
3. Sekiranya anda "membaca / menulis" melindungi halaman pertama kad anda, ia tidak akan berfungsi lagi dengan program ini kerana halaman pertama selalu dibaca untuk melihat sama ada kad masih ada. Oleh kerana dua halaman pertama hanya dibaca (UID disimpan di sana), tidak ada gunanya melindungi mereka.

Masalah kestabilan

Kod ini menggunakan perpustakaan RC522 "standard" untuk Arduino dan pustaka 3DES dari https://github.com/Octoate/ArduinoDES. Walaupun perpustakaan RC522 biasa digunakan, perpustakaan 3DES nampaknya tidak begitu meluas dan mesti dipasang secara manual.

Kod tersebut telah diuji pada Arduino Uno. Tetapi semasa menulisnya, saya menghadapi banyak masalah pelik berkaitan dengan kestabilan. Entah bagaimana kemahiran pengaturcaraan saya tidak begitu baik, salah satu perpustakaan yang digunakan tidak stabil atau mencampurkan perpustakaan bukanlah idea yang baik.

Ingatlah perkara ini semasa menggunakan kod !!!

Mengubahnya atau hanya menggunakan bahagiannya boleh menyebabkan tingkah laku pelik seperti mogok, mencetak perkara yang pelik atau mendapat waktu tamat atau NAK semasa membaca dari kad. Ini boleh berlaku di mana-mana tempat dalam kod (saya memerlukan debugging berjam-jam). Sekiranya anda menjumpai alasan untuk ini, tolong beri saya petunjuk.