برمجة بطاقات MIFARE DESFire EV3 لدخول الأبواب بثلاث طبقات تشفير

أساسيات برمجة DESFire EV3 للوصول الآمن

برمجة بطاقة MIFARE DESFire EV3 لدخول الأبواب بثلاث طبقات تشفير ليست مثل كتابة رقم داخل بطاقة قرب رخيصة ثم اعتبارها آمنة. تنتمي DESFire EV3 إلى بيئات أكثر حساسية: مقرات الشركات، المطارات، المستشفيات، مراكز البيانات، المباني الذكية، الجامعات، الفنادق، الجهات الحكومية والمواقع الصناعية حيث لا يكفي أن تثبت بطاقة الدخول هوية حاملها فقط. يجب أن تثبت أيضاً أن البطاقة أصلية، وأن القارئ موثوق، وأن الاتصال محمي، وأن بيانات الدخول لم تُنسخ أو تُعدّل بسهولة. لذلك فإن المشترين الذين يبحثون عن بطاقات MIFARE DESFire EV3 أو بطاقات RFID للتحكم بالدخول المشفرة أو حلول دخول الأبواب الآمنة عبر NFC يهتمون عادةً بهندسة بيانات الاعتماد كاملة، وليس بسعر البطاقة فقط.

يمكن أن تعني عبارة “دخول الأبواب بثلاث طبقات تشفير” أشياء مختلفة بحسب شركة التكامل، لكنها في مشروع احترافي للتحكم بالدخول باستخدام DESFire EV3 تشير غالباً إلى ثلاث طبقات أمنية تعمل معاً. الطبقة الأولى هي مصادقة قوية بين البطاقة والقارئ، وتكون عادةً مبنية على مفاتيح AES بدلاً من الاعتماد على أرقام ثابتة قديمة. الطبقة الثانية هي اتصال مشفر أو محمي برمز تحقق MAC، بحيث لا تظهر بيانات الدخول الحساسة بشكل مكشوف أثناء تمرير البطاقة. أما الطبقة الثالثة فهي تنويع المفاتيح أو منطق اعتماد مؤمّن من النظام الخلفي، حتى لا تعتمد كل بطاقة أو موقع أو مبنى أو تطبيق على سر مشترك واحد قد يعرّض النظام كله للخطر عند سوء التعامل معه. وعندما تُخطط هذه الطبقات بشكل صحيح، لا تبقى البطاقة مجرد شارة بلاستيكية، بل تصبح عنصراً أمنياً مضبوطاً.

يجب أن تبدأ عملية البرمجة قبل أن يلمس أي شخص جهاز الترميز. يحتاج مشروع بطاقات الدخول الآمنة إلى نموذج بيانات واضح. ما البيانات التي ستُخزن على البطاقة؟ ما الأبواب أو المناطق التي ستدعمها؟ هل ستُستخدم البطاقة للتحكم بالدخول فقط، أم ستدعم أيضاً مواقف السيارات، الخزائن، الدفع في الكافيتريا، إدارة الزوار، التحكم بالمصاعد أو الطباعة الآمنة؟ من يملك المفاتيح داخل المؤسسة؟ من يحق له تخصيص البطاقات؟ من يحق له إلغاؤها؟ كيف ستُحظر البطاقات المفقودة؟ من دون هذه الإجابات، يمكن للفريق أن يبرمج بطاقة DESFire EV3 من الناحية التقنية، ثم ينتهي بنظام ضعيف عملياً.

تعلّم فريق مرافق في شركة خدمات مالية افتراضية في زيورخ هذا الدرس أثناء ترقية مقرها الرئيسي. كانت الشارات القديمة تعتمد على رقم بطاقة ظاهر وبحث بسيط داخل القارئ. أما الخطة الجديدة فكانت استخدام بطاقات دخول MIFARE DESFire EV3 بتشفير أقوى، لكن أول اجتماع في المشروع ركز فقط على تصميم الطباعة ومواعيد تسليم البطاقات. وبعد أن سأل مستشار أمني عن مالك مفتاح التطبيق الرئيسي وكيف سيتم تنويع المفاتيح لكل بطاقة موظف، أدرك الفريق أن الشارة جزء من بنية أمنية وليست مجرد طلب بطاقات هوية. تأخر المشروع أسبوعين، لكن هذا التوقف منع إطلاقاً فوضوياً ربما كان سيجبرهم لاحقاً على إعادة ترميز آلاف البطاقات.

بنية التطبيقات وتخطيط البيانات الآمنة

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

في التطبيق العملي، يتضمن سير العمل الآمن عادةً تهيئة البطاقة، إنشاء التطبيق، تعريف الملفات، إعداد المفاتيح، كتابة بيانات الاعتماد، ضبط صلاحيات الوصول، ثم التحقق باستخدام قرّاء معتمدين. تختلف الأوامر والأدوات الدقيقة بحسب جهاز الترميز، وبرنامج التخصيص، ومنصة التحكم بالدخول، وسياسة الأمان. وفي أي مشروع مشروع، يجب تنفيذ هذه العمليات داخل بيئة إصدار معتمدة، ويفضل استخدام وحدة وصول آمنة، أو وحدة أمان عتادية، أو نظام مضبوط لإدارة المفاتيح. فالهدف ليس مجرد “كتابة بيانات”، بل التأكد من أنه لا يمكن لأي جهة خارج العملية المصرح بها إنشاء بطاقة تبدو مقنعة.

استخدمت جامعة افتراضية في ملبورن بطاقات DESFire EV3 للطلاب لدخول السكن، وبوابات المكتبة، وإطلاق مهام الطباعة، ودخول مختبرات الهندسة. أراد قسم تقنية المعلومات في البداية وضع كل الوظائف داخل ملف بسيط واحد لأنه بدا أسهل. اعترض مورّد نظام التحكم بالدخول واقترح تطبيقات منفصلة بمجموعات مفاتيح مختلفة. وعندما فقد أحد الطلاب بطاقته، استطاعت الجامعة إلغاء دخول المباني فوراً من دون التأثير في سجلات حساب المكتبة أو رصيد الطباعة. أصبح برنامج البطاقات أسهل إدارة لأن تخطيط الذاكرة عكس طريقة عمل الحرم الجامعي فعلياً.

مصادقة AES وسوء استخدام UID

في دخول الأبواب بثلاث طبقات تشفير، تكون مصادقة AES غالباً هي الأساس. تعتمد البطاقات القديمة منخفضة التردد والأنظمة البسيطة القائمة على UID عادةً على أرقام يمكن قراءتها وإعادة استخدامها بسهولة أكبر من اللازم. تدعم DESFire EV3 مصادقة متبادلة أقوى، ما يسمح للبطاقة والقارئ بإثبات معرفتهما بالمفاتيح التشفيرية المشتركة قبل الوثوق بأي بيانات حساسة. في نظام مصمم جيداً، لا يمنح القارئ إذن الدخول لمجرد أنه رأى UID البطاقة. بل يرسل تحدياً للبطاقة، ويفحص الاستجابة التشفيرية، ثم يقرأ أو يتحقق من بيانات اعتماد محمية عبر قناة آمنة.

هنا يحتاج كثير من مشتري أنظمة التحكم بالدخول إلى تغيير طريقة التفكير. UID ليس اعتماداً أمنياً. قد يكون UID مفيداً للجرد أو التسجيل أو مرجعية البطاقة، لكن دخول الأبواب لا ينبغي أن يعتمد عليه وحده. يجب أن تستخدم بطاقة MIFARE DESFire الآمنة بيانات تطبيق محمية ومصادقة تشفيرية. كما يجب ضبط قارئ الباب لرفض التطبيقات غير المعروفة، والبيانات غير المصادق عليها، والاعتمادات التي تقع خارج بنية المُصدر المتوقعة. فإذا اشترى الموقع بطاقات DESFire EV3 متقدمة ثم ضبط القرّاء لقبول رقم ظاهر أو ثابت فقط، فإن معظم القيمة الأمنية للبطاقة تضيع.

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

تنويع المفاتيح والاتصال المحمي

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

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

الجزء الثاني من الوصول المشفر هو الاتصال المحمي. عندما يتواصل قارئ مع بطاقة DESFire EV3، يمكن ضبط النظام بحيث تُقرأ البيانات في وضع آمن بدلاً من إرسالها بشكل مكشوف. وبحسب إعدادات الملف والتطبيق، قد يكون الاتصال عادياً أو محمياً برمز MAC أو مشفراً. وفي دخول الأبواب، لا ينبغي التعامل مع بيانات الاعتماد الحساسة كأنها نص عام. يجب أن يتحقق القارئ من أن البيانات جاءت من بطاقة تمت مصادقتها، وأنها لم تُعدّل بين البطاقة والقارئ. يساعد ذلك على منع الهجمات التي يحاول فيها شخص تغيير بيانات الدخول أو إعادة تشغيلها.

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

قواعد النظام الخلفي ودخول الأبواب دون اتصال

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

استخدمت شبكة مستشفيات في تورونتو بطاقات DESFire EV3 عبر عدة مبانٍ، بما في ذلك مناطق الطوارئ، والصيدليات، والمختبرات، ومواقف الموظفين. كانت بعض الأبواب تتطلب قرارات فورية من النظام الخلفي، بينما كان على أبواب أخرى أن تعمل أثناء انقطاع الشبكة. تضمنت بنية الاعتماد بيانات بطاقة محمية للتحقق المحلي، لكن نظام إدارة الدخول ظل يتحكم في تغييرات الأدوار، والموظفين المنتهية خدمتهم، وقواعد الإغلاق الطارئ. لم يحاول المستشفى وضع قاعدة بيانات الدخول كاملة على البطاقة، بل استخدم البطاقة كحامل موثوق للهوية والسمات الخاضعة للتحكم.

اختيار البطاقة وتوافق القرّاء وخطة الانتقال

قبل بدء البرمجة، يكون اختيار البطاقة مهماً. ليست كل طلبية بطاقات DESFire EV3 متشابهة. يجب على المشترين التأكد من حجم الذاكرة، وإصدار الشريحة، وشكل البطاقة، ومادة جسم البطاقة، وطريقة الطباعة، ومتطلبات التردد، وسياسة UID، وخيارات التخصيص، وما إذا كانت البطاقة تحتاج إلى دعم تفاعلات NFC مع الهاتف أو قرّاء الدخول الفعلية فقط. قد تكون خيارات ذاكرة 2K أو 4K أو 8K مناسبة بحسب عدد التطبيقات والملفات المطلوبة. وقد لا تحتاج شارة مكتب بسيط في موقع واحد إلى الذاكرة نفسها التي تحتاجها بطاقة جامعية متعددة التطبيقات. زيادة الذاكرة ليست ضارة دائماً، لكن التقليل من تقديرها قد يقيّد التوسع مستقبلاً.

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

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

واجه حرم مؤسسي في شيكاغو هذا التحدي أثناء اندماج شركتين. كان أحد المباني يستخدم قرّاء قرب قديمة، وآخر يستخدم MIFARE Classic، بينما كان البرج الأحدث يدعم DESFire. أرادت الشركة بطاقة RFID مشفرة واحدة لكل الموظفين. قرر فريق الأمن عدم خفض تصميم DESFire ليتوافق مع أضعف قارئ. وبدلاً من ذلك، وضع جدول انتقال، ورقّى المداخل الأعلى خطورة أولاً، وأصدر بطاقات ثنائية التقنية خلال فترة التحول فقط. وبعد استبدال القرّاء القديمة، عُطلت التقنية الضعيفة. نجح المشروع لأن قرارات البرمجة ارتبطت باستراتيجية القرّاء، ولم تُعامل كمهمة شارات منفصلة.

الترميز الآمن والاختبار وضبط الإصدار

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

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

التحقق خطوة لا ينبغي تخطيها أبداً. بعد البرمجة، يجب فحص كل بطاقة بواسطة برنامج الإصدار واختبارها أيضاً مع قرّاء تمثل الواقع التشغيلي. يجب أن يتأكد النظام من وجود التطبيق الصحيح، وأن الملفات المطلوبة موجودة، وأن المفاتيح مضبوطة كما ينبغي، وأن البيانات المحمية لا تُقرأ إلا بعد المصادقة، وأن البطاقة تفتح فقط الأبواب المصرح بها. من الأخطاء الشائعة اختبار عمل البطاقة عند قارئ واحد ثم افتراض أن البنية كلها صحيحة. يجب أن يختبر البرنامج الآمن أيضاً السلوك السلبي: ألا تكشف البطاقة بيانات محمية دون مصادقة، وألا تعمل في منطقة خاطئة، وألا تبقى فعالة بعد إلغائها.

استخدم مصنع في مونتيري بطاقات DESFire EV3 لدخول الموظفين، والتحكم بمخزن الأدوات، ومناطق تخزين المواد الخطرة. أثناء الإطلاق، فتح نوع من البطاقات المداخل الرئيسية بشكل صحيح لكنه فشل عند قارئ منطقة تخزين كيميائي مقيدة. لم تكن المشكلة في شريحة البطاقة. كانت المنطقة المقيدة تستخدم ملف تعريف قارئ مختلفاً يتوقع إعداداً محدداً لملف التطبيق. ولأن المصنع اختبر عدة أنواع من الأبواب قبل الإصدار الكامل، اكتُشف عدم التطابق مبكراً. لو أصدروا كل البطاقات بعد اختبار ردهة الاستقبال فقط، لسبب الفشل تأخيرات في المناوبات وإعادة برمجة طارئة.

قواعد الزوار والمقاولين والشارات المؤقتة

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

أصدر موقع أبحاث دوائية في كامبريدج بطاقات DESFire EV3 قصيرة الأجل لمقاولين يقومون بصيانة غرف نظيفة. استخدمت البطاقات تطبيق دخول محمياً مع حقل انتهاء صلاحية وتحقق من النظام الخلفي. كان بإمكان المقاولين دخول المناطق المجدولة فقط، وكانت البطاقة تتوقف عن العمل بعد انتهاء نافذة الصيانة المعتمدة. وعندما عُثر على شارة داخل مركبة أحد المقاولين بعد أسبوع، كانت قد أصبحت بلا فائدة. دعمت تقنية البطاقة القوية السياسة، لكن السياسة جاءت أولاً.

التصميم المرئي وإدارة دورة حياة الاعتماد

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

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

بالنسبة للمؤسسات الكبيرة، لا تقل إدارة دورة الحياة أهمية عن البرمجة الأولية. ينضم الموظفون ويغادرون، ويغيّرون الأقسام، وينتقلون بين المباني، ويفقدون البطاقات، ويتلفونها، ويطلبون بدائل. يجب أن يتعامل نظام الدخول مع هذه التغييرات من دون إضعاف بنية المفاتيح. لا ينبغي أن تعيد بطاقات الاستبدال استخدام بيانات غير آمنة. ويجب إلغاء البطاقات المفقودة بسرعة. كما يجب إتلاف البطاقات المتقاعدة أو إعادة ضبطها بأمان وفق السياسة. وإذا كانت البطاقات تدعم عدة تطبيقات، فيجب أن يشمل الإلغاء جميعها، وليس دخول الأبواب فقط.

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

اختيار الشريك المناسب لبطاقات DESFire EV3

من منظور الشراء، لا يكون أفضل مورّد هو ببساطة من يقدم أقل سعر للبطاقة. يجب أن يفهم مصنع بطاقات MIFARE DESFire EV3 القوي أو شريك التخصيص تخطيط الذاكرة، والترميز الآمن، وتنويع المفاتيح، وتوافق القرّاء، والطباعة، والتعامل مع UID، واختبارات الجودة، والتغليف. كما يجب أن يسأل عما إذا كان العميل يحتاج إلى بطاقات فارغة، أو مطبوعة مسبقاً، أو مشفرة، أو محقونة بالمفاتيح، أو عينات اختبار، أو تخصيص كامل. ويجب أن يكون قادراً على مناقشة بطاقات التحكم بالدخول الآمنة من دون أن يطلب من العميل كشف مفاتيح رئيسية حساسة عبر قنوات غير آمنة.

هدف البرمجة النهائي بسيط في وصفه لكنه يتطلب انضباطاً في تنفيذه: يجب أن تكشف البطاقة فقط ما يفترض أن تكشفه، ولقارئ يثبت أنه موثوق فقط، وداخل نظام قادر على إدارة الاعتماد طوال عمره. هذا هو المعنى العملي لدخول الأبواب بثلاث طبقات تشفير. ليس عبارة تسويقية تُطبع على بطاقة بلاستيكية، بل تصميم متعدد الطبقات يستخدم قدرات DESFire EV3، ومصادقة قائمة على AES، واتصالاً محمياً، ومفاتيح متنوعة، وإصداراً مضبوطاً، وإعداد قارئ مُتحققاً منه، وإدارة دخول نظيفة.

عند تنفيذ ذلك بشكل صحيح، تخلق برمجة بطاقة MIFARE DESFire EV3 اعتماد دخول يبدو بسيطاً للمستخدم. يمرر الموظف البطاقة فيفتح الباب. يمرر الزائر بطاقته عند بوابة الردهة فيدخل إلى الطابق المعتمد فقط. يمرر المقاول بطاقته عند بوابة الخدمة خلال النافذة المجدولة ولا يحصل على أكثر من ذلك. خلف هذه اللمسة البسيطة توجد سلسلة مخططة بعناية من التطبيقات، والملفات، والمفاتيح، والاتصال الآمن، وقواعد النظام الخلفي، وسجلات التدقيق. هذه هي القيمة الحقيقية لـ DESFire EV3 في دخول الأبواب الحديث: أمان قوي لا يضطر المستخدم العادي إلى التفكير فيه، ويمكن لفرق الأمن الوثوق به كل يوم.