استخدام Mifare Ultralight C مع RC522 على Arduino: 3 خطوات

2024 مؤلف: John Day | [email protected]. آخر تعديل: 2024-01-30 07:36

يعد استخدام تقنية RFID لتحديد حاملي البطاقات أو الإذن بعمل شيء ما (افتح الباب وما إلى ذلك) نهجًا شائعًا إلى حد ما. في حالة تطبيق DIY ، يتم استخدام وحدة RC522 على نطاق واسع لأنها رخيصة جدًا وهناك الكثير من الرموز لهذه الوحدة.

في معظم الحالات ، يتم استخدام UID الخاص بالبطاقة "لتحديد" حامل البطاقة ، ويتم استخدام بطاقات Mifare Classic لأنها رخيصة الثمن وغالبًا ما يتم تضمينها عند شراء وحدة RC522.

ولكن كما تعلم ، تم اختراق نظام Mifare Classic لعدة سنوات ولم يعد يعتبر آمنًا بعد الآن. يمكن التغلب على نظام التشفير Crypto1 الذي تستخدمه البطاقات الكلاسيكية وهي بطاقات قابلة لإعادة الكتابة حيث يمكن إعادة برمجة البيانات مع UID (البطاقات السحرية).

لذلك لا يوصى باستخدام بطاقات Mifare Classic لأي تطبيق متعلق بالأمان! الأمر نفسه ينطبق على (معظم) أنظمة NTAG و Mifare Ultralight

لذا فإن الخيار هو إما استخدام نظام احترافي أو محاولة استخدام نظام RFID أكثر أمانًا. الأنظمة المتاحة هي Mifare Ultralight C و Mifare DESFire و Mifare Plus. نظرًا لوجود العديد من الأنظمة الاحترافية التي تستخدم هذه الأنظمة الأكثر أمانًا ، لا توجد حلول تقريبًا لمجتمع DIY (يوجد حل DESFire واحد قائم على Teensy ، والذي يستند إلى لوحة الاختراق PN523 الأكثر تكلفة). بالإضافة إلى ذلك ، فإن بطاقات DESFire باهظة الثمن. لذلك كان التحدي هو إيجاد حل أفضل وأرخص.

يوفر الحل المقدم وصولاً كاملاً إلى بطاقات Mifare Ultralight “C” الرخيصة باستخدام وحدة RC522 الصينية الرخيصة. بناءً على هذا الرمز ، يمكن استخدام Mifare Ultralight C الآمن في تطبيقات DIY.

الخطوة 1: الشروط المسبقة

على الرغم من أن RC522 مصمم جيدًا ، إلا أنه في معظم الحالات لا يتم بناؤه بشكل جيد نظرًا لأن بعض المكونات ذات أبعاد رديئة. يؤدي هذا إلى السمعة السيئة للوحدة حيث أنها ذات حساسية منخفضة ولن يتم تحديد جميع أنواع البطاقات. على وجه الخصوص ، لن يتم تحديد Mifare Ultralight C ولن يكون من الممكن قراءة البطاقات.

المشكلة الرئيسية هي مواصفات المحاثات L1 و L2. كما هو موضح في https://ham.marsik.org/2017/04/using-cheap-rc522-nfc-reader-to-read.html. فقط عن طريق استبدال هذه المحرِّضات بأخرى مناسبة ، على سبيل المثال يظهر FERROCORE CW1008-2200 فجأة RC522 ما هي إمكاناته الحقيقية.

لذا قبل تجربة الكود المحدد ، يجب عليك استبدال المحاثات. انها فقط لن تعمل مع المحاثات المثبتة مسبقا!

خلفية كل هذا هي أن بطاقات Ultralight C متعطشة تمامًا للطاقة. يتم توفير هذه الطاقة من خلال مجال RC522 RF. نظرًا للتيار المنخفض للمحثات ، فإن مجال الطاقة ليس قويًا بما يكفي لتشغيل Ultralight C. وتحتاج البطاقات الأخرى مثل Mifare Classic إلى طاقة أقل وبالتالي تعمل بشكل مستقر.

الخطوة الثانية: كيف تعمل؟

إذن بعد تعديل وحدة RC522 ، كيف يمكنك استخدام Mifare Ulralight C لتطبيقك؟

الحيلة هي أن Mifare Ultralight C يدعم مصادقة كلمة المرور بناءً على تشفير 3DES. باستخدام كلمة المرور هذه ، يمكن جعل محتوى البطاقة "للقراءة فقط" أو غير مرئي تمامًا لمستخدم غير مصرح له.

من أجل استخدام حماية كلمة المرور هذه ، يجب كتابة كلمة المرور على البطاقة ويجب حماية الصفحات. بمجرد الانتهاء من ذلك ، يمكنك التحقق من البطاقة في التطبيق الخاص بك إما عن طريق طلب مصادقة تستند إلى كلمة مرور أو بيانات جاهزة إضافية من منطقة محمية. فقط إذا كان هذا ناجحًا ، فأنت تعلم أنه يمكنك الوثوق بالرقم التعريفي المميز (UID) المقدم على البطاقة.

احذر: بدون المصادقة القائمة على كلمة المرور ، ما زلت لا تثق في بطاقة Mifare Ultralight C ، حيث توجد "بطاقات سحرية" بالإضافة إلى من يحاكي Ultralight C.

ستستجيب كل بطاقة مستقلة عن التقنية (إذا كانت بالتردد الصحيح) مع UID الخاص بها عندما يتم تشغيلها بواسطة مجال RF وتطلب تعريف نفسها. بالإضافة إلى ذلك ، فإنها توفر قيمة SAK توفر الحد الأدنى من المعلومات حول نوع البطاقة الموجودة. لسوء الحظ ، يتم تحديد كل من Mifare Ultralight و NTAG على أنهما نوع syme (SAK = 0x00) ، بما في ذلك Mifare Ultralight C. لذلك عند الاستقصاء عن البطاقات ، فإن قيمة SAK البالغة 0x00 ستعطي تلميحًا إلى أنه قد يكون هناك Ultralight C على القارئ.

للتأكد من أنه Ultralight C ، يمكن إرسال طلب للمصادقة المشفرة إلى البطاقة. إذا لم تكن هذه بطاقة Ultralight C ، فلن يتم فهم هذا الطلب ، وسيكون الرد NAK (ليس acknolege).

إذا كانت هذه بطاقة Ulralight C ، فستحصل على إجابة 8 بايت. هذه 8 بايت عبارة عن رقم عشوائي "B" (RndB) مشفر بواسطة المفتاح المخزن على البطاقة باستخدام تشفير 3DES.

يجب فك تشفير RndB المشفر باستخدام نفس المفتاح في البرنامج. ثم يتم تعديل هذا الرقم العشوائي بشكل طفيف (يتم تدويره بمقدار بايت واحد ← بايت 1 سيتم نقله إلى بايت 8 ويتم دفع جميع البايتات الأخرى بمقدار بايت واحد أقل ، ثم يسمى RndB '). يقوم البرنامج بعد ذلك بإنشاء رقم عشوائي 8 بايت "A" نفسه (RndA) وإرفاق RndA هذا بـ RndB المعدل. يتم تشفير هذا مرة أخرى باستخدام المفتاح وإرساله إلى البطاقة.

تقوم البطاقة بفك تشفير الرسالة والتحقق مما إذا كان RndB مناسبًا لـ RndB الذي تم إنشاؤه مسبقًا على البطاقة. إذا كانتا متطابقتين ، فإن البطاقة تعرف الآن أن البرنامج يعرف المفتاح.

في هذه المرحلة ، لا يزال البرنامج لا يعرف ما إذا كانت البطاقة تعرف المفتاح وبالتالي يمكن الوثوق بها أم لا. لتحقيق ذلك ، تقوم البطاقة الآن بتدوير RndA الذي تم فك تشفيره بمقدار بايت واحد ، ثم تشفير هذه البايتات باستخدام المفتاح وإرسالها مرة أخرى.

سيقوم البرنامج بعد ذلك بفك تشفير رد البطاقة والتحقق من تطابق RndA الأصلي مع RndA الذي تم الرد عليه. عندئذٍ فقط يعرف كلا الكيانين (البرنامج والبطاقة) أنهما يشتركان في معرفة نفس المفتاح.

هذه العملية تستخدم فقط للمصادقة. تكون جميع الاتصالات الإضافية دائمًا في "نص واضح".

على الرغم من وجود بطاقات "Magic Ultralight C" حيث يمكن تعديل UID ، لا يمكن الحصول على المفتاح نفسه من البطاقة كما أن تشفير 3DES آمن إلى حد ما. المفتاح هو مفتاح 16 بايت ، لذا فإن نهج القوة الغاشمة للحصول على المفتاح سيستغرق بعض الوقت.

كما هو مذكور ، يكون الاتصال قبل المصادقة وبعد المصادقة دائمًا بنص واضح (ويعرف أيضًا باسم غير مشفر). عند كتابة مفتاح جديد على البطاقة ، يمكن شم محتوى المفتاح باستخدام المعدات المناسبة. لذا يرجى كتابة المفتاح في بيئة آمنة فقط واحتفظ بسر المفتاح.

عند استخدام بطاقة Ultralight C

تتميز بطاقة Ultralight C بميزات أمان متعددة مدمجة في:

1. ذاكرة البرمجة لمرة واحدة (OTP). في هذه المنطقة يمكن كتابة البتات ، ولا يتم حذف الحافلة.
2. عداد أحادي الاتجاه 16 بت. هذا العداد يمكن أن يزيد فقط ، عند الوصول إليه.
3. حماية "كتابة" أو "قراءة / كتابة" للصفحات الموجودة في الذاكرة. يمكن قراءة هذه الصفحات أو تعديلها فقط إذا تمت المصادقة عليها باستخدام المفتاح.
4. تجميد / حجب الصفحات الفردية للحماية من أي تعديل.

لا يتم تنفيذ استخدام OTP أو عداد 16 بت أو استخدام بت الحظر في الكود المحدد ، ولكن يمكن تنفيذه بسهولة بناءً على المعلومات الواردة في https://www.nxp.com/docs/en/data- ورقة / MF0ICU2.pd …

نظرًا لأن الحماية بالمفتاح ضرورية لاستخدام Mifare Ultralight C ، فإن جميع الوظائف ذات الصلة موجودة.

يتم استخدام جميع الأوامر في الشاشة التسلسلية مع "خط جديد فقط" ومع 115200 Baud

• سوف تطلب "المصادقة 49454D4B41455242214E4143554F5946" مصادقة بالمفتاح المحدد (في هذه الحالة مفتاح Mifare Ultralight C القياسي)
• ستؤدي كلمة "تفريغ" إلى تفريغ محتوى البطاقة بقدر ما تكون مرئية. في حالة حماية الصفحات بواسطة المفتاح ، قد لا تكون هذه الصفحات مرئية حتى مصادقة سابقة بالمفتاح. يشار في العمودين الأولين إلى ما إذا كانت الصفحات مقفلة أو تم تقييد الوصول إليها.
• سيكتب "newKey 49454D4B41455242214E4143554F5946" مفتاحًا جديدًا على البطاقة. المفتاح مكتوب على الصفحات من 44 إلى 47. لن يعمل هذا إلا إذا لم تكن هذه الصفحات مقفلة أو محمية بدون مصادقة سابقة.
• سيكتب "wchar 10 hello world" "hello world" بدءًا من الصفحة 10. مرة أخرى ، هذه الأعمال فقط للصفحات ليست مقفلة أو محمية بدون مصادقة سابقة. عند محاولة الكتابة فوق الصفحة 39 أو أقل من الصفحة 4 ، فإن هذا سيطلب منك خطأ أو يتم تجاهل البيانات لأن هذه الصفحات ليست ذاكرة مستخدم.
• ستكتب "Whex 045ACBF44688" قيم سداسية عشرية مباشرة إلى الذاكرة ، تطبق الشروط السابقة.
• "حماية 30" تحمي جميع الصفحات من الصفحة 30 وما فوق. بناءً على الإذن ، لا يمكن تعديل هذه الصفحات أو قراءتها إلا بعد مصادقة مسبقة باستخدام المفتاح. سيؤدي استخدام "حماية" بقيم أعلى من 47 إلى تعيين جميع الصفحات على "غير محمية" بما في ذلك المفتاح في الصفحات 44-47 (والتي يمكن تعديلها فقط ولكن لا يمكن قراءتها). من أجل منع تغيير المفتاح ، يجب أن تبدأ الحماية على الأقل في الصفحة 44.
• يحدد "setpbit 0" بت الحماية ويقرر ما إذا كانت الصفحات المحمية للقراءة فقط ("setpbit 1") أو لا يمكن قراءة أي منهما غير مكتوبة ("setpbit 0") بدون مصادقة مسبقة باستخدام المفتاح.

لا يمكن استخدام جميع الأوامر فور اكتشاف البطاقة. يساعد "تفريغ" سابقًا إلى أمر آخر دائمًا.

الخطوة 3: هام

1. يميز البرنامج بين أنواع Ultralight من خلال قراءة الصفحة 43 و 44. إذا كانت الصفحة 43 قابلة للقراءة والصفحة 44 غير قابلة للقراءة ، فمن المحتمل أن تكون Ultralight C. ولكن إذا كنت تقرأ / تكتب حماية الصفحة 43 ، فلن يتم التعرف على البطاقة على أنها Ultralight C (ليس له أي تأثير على أي شيء) يجب أن يتم التحديد الصحيح لـ Ultralight من خلال المصادقة باستخدام المفتاح (لم أقم بتطبيق ذلك لأسباب تتعلق بالاستقرار).
2. قبل استخدام الأمرين "setpbit" و "Protect" يجب استخدام الأمر "dump" ، وإلا فلن تكون حالة حماية الصفحات معروفة.
3. إذا كنت "تقرأ / تكتب" تحمي الصفحات الأولى من بطاقتك ، فلن تعمل بعد الآن مع هذا البرنامج حيث تتم قراءة الصفحة الأولى باستمرار لمعرفة ما إذا كان لا يزال هناك بطاقة موجودة. نظرًا لأن الصفحتين الأوليين تتم قراءتهما فقط على أي حال (يتم تخزين UID هناك) ، فلا معنى لحمايتهما.

قضايا الاستقرار

يستخدم هذا الرمز مكتبة RC522 "القياسية" لـ Arduino ومكتبة 3DES من https://github.com/Octoate/ArduinoDES. في حين أن مكتبة RC522 شائعة الاستخدام ، لا تبدو مكتبة 3DES منتشرة جدًا ويجب تثبيتها يدويًا.

تم اختبار الكود على Arduino Uno. لكن أثناء كتابته ، واجهت العديد من المشكلات الغريبة فيما يتعلق بالاستقرار. بطريقة ما إما أن مهاراتي في البرمجة ليست جيدة ، إحدى المكتبات المستخدمة غير مستقرة أو أن خلط المكتبات ليس فكرة جيدة.

من فضلك ضع ذلك في الاعتبار عند استخدام الكود !!!

يمكن أن يؤدي تغييرها أو استخدام أجزاء منها فقط إلى سلوك غريب مثل التعطل أو طباعة أشياء غريبة أو الحصول على مهلات أو NAK عند القراءة من البطاقة. يمكن أن يحدث هذا في أي مكان في الكود (كلفني ذلك عدة ساعات من تصحيح الأخطاء). إذا وجدت السبب (الأسباب) لذلك ، من فضلك أعطني تلميحًا.