قبل فترة ظللت أقرأ الادّعاء نفسه عرَضًا: العلامات الفاخرة تضع شرائح NFC في منتجاتها كي تلمس حقيبة أو حذاءً رياضيًا بهاتفك فتعرف أنه الأصلي لا المزيّف. كانت كل مقالة تردّد الجملة اللامعة نفسها، ولم تقل أيٌّ منها كيف. ما الذي يمنع المزوّر فعلًا من نسخ الشريحة مع الحقيبة؟
لذا فعلت ما أفعله دائمًا حين يثير فضولي وسمٌ ما. دخلت إلى AliExpress، ووجدت إعلانًا لوسوم «NTAG 424 DNA»، وطلبت دفعة صغيرة، وانتظرت وصول الظرف. بضعة يوروهات وأسبوعان، وصار السيليكون نفسه الذي تُبنى عليه أنظمة حماية العلامات على مكتبي. ثم لمست واحدًا لأرى ما يفعله.
ما هو وسم NTAG 424 DNA فعليًّا
من الخارج هو وسم NFC عادي. لن تستطيع تمييزه من كومة من الوسوم الرخيصة، وأيّ هاتف يقرأه دون تذمّر. وإن قرأت دليلي لأنواع وسوم NFC، فهو يندرج كوسم Type 4 آخر يسعد iPhone بقراءته.
الجزء «DNA» هو المختلف. ففي الداخل تحمل الرقاقة بضعة مفاتيح AES-128 ومحرّكًا تشفيريًّا صغيرًا، وتستطيع أن تفعل ما لا يستطيعه NTAG215 عاديّ ولا ملصق من عبوة متعددة: تستطيع أن تُوقّع كل لمسة على حدة. ذلك التوقيع هو بيت القصيد كله. إنه الفرق بين وسم يقول «إليك رابطًا» ووسم يقول «إليك رابطًا، وإليك إثباتًا تشفيريًّا بأنني، هذه الرقاقة الأصلية بعينها، هي من يقدّمه، الآن».
هذا ما تدفع العلامات الفاخرة مقابله فعلًا - ليس الرابط، بل الإثبات بأن رقاقة أصلية هي من يقدّمه.
كيف تعمل SUN وSDM: رابط يعيد كتابة نفسه مع كل لمسة
اللحظة التي اتّضح فيها لي الأمر جاءت حين نظرت إلى ما كان الوسم يرسله فعلًا: عندها أدركت أنني سبق أن بنيت معظم الآلية اللازمة لفهمه.
في وقت سابق من هذا العام أطلقت ميزة NFC Tap Counter: وسم يحصي كم مرة قُرئ ويضع ذلك الرقم في رابط URL، كي يعرف الرابط أنها المرة الـ٤٧ التي يمسحه فيها أحدهم. ووسم NTAG 424 DNA هو الفكرة نفسها، مع طبقة تشفير ملتفّة حولها تجعل تزييفه مستحيلًا.
تُسمّى الآلية SUN (Secure Unique NFC)، أو SDM (Secure Dynamic Messaging) إن كنت تقرأ ورقة بيانات NXP. تخزّن رابطًا عاديًّا على الوسم، شيئًا مثل https://example.com. لكنك تُملي على الرقاقة أن تعيد كتابة أجزاء من ذلك الرابط لحظيًّا في كل مرة يُلمس فيها. فما يستقبله هاتفك فعليًّا أقرب إلى:
https://example.com/?picc_data=A1B2...&cmac=9F3C...
هاتان القيمتان ليستا زينةً. فـpicc_data نسخة مشفّرة من المعرّف الحقيقي للوسم مضافًا إليه عدّاد لمسات، مُشوَّشة بمفتاح لا يغادر الرقاقة أبدًا. وcmac توقيع تشفيري على تلك البيانات. وكلتاهما تتغيّران مع كل لمسة. المس الوسم نفسه مرتين فتحصل على رابطين مختلفين تمامًا، كلٌّ منهما موقّع بختم جديد من الرقاقة.
أتخيّل وسم NFC العادي كلافتة مطبوعة في واجهة متجر. يستطيع أيّ أحد أن يصوّرها ويطبع نسخةً مطابقة. أما وسم SUN فأشبه بحارس أمن يسلّمك في كل مرة تدخل فيها إيصالًا جديدًا مرقّمًا ومختومًا على حدة. ونسخُ إيصال الأمس لا ينفعك، لأن رقم اليوم مختلف وختم الحارس وحده هو الحقيقي.
لماذا يُكشف وسم NTAG 424 DNA المستنسخ
هذا هو الجزء الذي يجيب عن سؤالي الأصلي. يستطيع المزوّر بلا شك أن يستنسخ محتوى الوسم. يقرأ الرابط، وينسخه بايتًا بايتًا، ويبرمجه على رقاقة فارغة. لطالما كان هذا صحيحًا.
ما لا يستطيعه هو إنتاج التوقيع الصالح التالي. فمفتاح التوقيع يعيش داخل الرقاقة الأصلية ولا يخرج منها أبدًا، ولا حتى أثناء اللمسة. وهذا يعني أن اللمسة لا قيمة لها إلا لدى ما يملك المفتاح فعلًا. في إعداد حقيقي لحماية العلامة، يشير رابط الوسم إلى خادم يديره الصانع، وذلك الخادم هو ما يفكّ تشفير كل لمسة، ويعيد حساب التوقيع للتأكد من تطابق المفتاح، ويتتبّع العدّاد وهو يتصاعد.
ذلك الجزء الأخير هو ما يكشف النسخة المقلّدة. فالرابط الوحيد الذي يمكن للمزوّر وضعه على مزيّف هو رابط التقطه من لمسة أصلية، مجمّدًا مع العدّاد الذي صادف أن حملته تلك اللمسة. أعِد تشغيله فيرى الخادم رقمًا سبق أن رآه، وعدّاد الرقاقة الحقيقية لا يتحرك إلا إلى الأمام، فالتكرار أو التراجع خطوةً إلى الوراء يفضح إعادة التشغيل. ولإرسال عدّاد جديد أعلى بتوقيع لا يزال صحيحًا، سيحتاج إلى المفتاح، وللحصول على المفتاح سيحتاج إلى كسر AES أو نزع غطاء الرقاقة فيزيائيًّا. ولن يحدث أيٌّ منهما من أجل حقيبة يد مزيّفة.
تلك هي النسخة الصادقة من جملة التسويق. فالرقاقة لا تجعل نسخ المنتج مستحيلًا. بل تجعل نسخ إثبات الأصالة مستحيلًا، وتنقل ذلك الإثبات إلى شيء لا يستطيع المزوّر إعادة إنتاجه.
ماذا يوجد داخل الرقاقة
كل ما يفعله NFC.cool مع هذه الوسوم يصبح أوضح بكثير حين تكون بنية الرقاقة حاضرة في ذهنك، لذا إليك الخريطة التي اضطررت إلى رسمها قبل أن أكتب سطرًا واحدًا من الكود.
وسم NTAG 424 DNA هو وسم NFC Forum من النوع Type 4 بذاكرة سعتها ٤١٦ بايت، منظّمة على هيئة تطبيق واحد يضمّ ثلاثة ملفات ثابتة. لا يمكنك إنشاء ملفات أو حذفها كما تفعل على رقاقة MIFARE DESFire. هذه الملفات الثلاثة هي كل ما لديك:
| الملف | الحجم | ما يحويه |
|---|---|---|
| File 01 | ٣٢ بايت | حاوية الإمكانات التي تدلّ الهاتف على مكان بيانات NDEF |
| File 02 | ٢٥٦ بايت | رسالة NDEF، وهي رابطك في العادة. يعكس SUN قيمه الحيّة إلى هذا الملف مع كل قراءة |
| File 03 | ١٢٨ بايت | ملف خاص تستطيع الرقاقة إبقاءه مشفّرًا. يستخدمه NFC.cool خزنةً، والمزيد عن ذلك أدناه |
إلى جانب الملفات تقبع خمسة مفاتيح AES-128، مرقّمة من Key 0 إلى Key 4. Key 0 هو المفتاح الرئيسي للتطبيق: به تتوثّق حين تريد تغيير الرابط، أو تفعيل SUN، أو تغيير أيّ مفتاح آخر، أو المساس بتكوين الرقاقة. أما المفاتيح من Key 1 إلى Key 4 فلا تفعل شيئًا بمفردها، ولا تكتسب أهميتها إلا حين تشير إليها صلاحيات الوصول إلى ملف ما أو إعداد SUN. وفي الوسم الجديد تكون المفاتيح الخمسة كلها ستة عشر بايتًا من الأصفار، ويستطيع أيّ أحد الكتابة في ملف NDEF، ولهذا يقبل الوسم الجديد تمامًا رابطًا عاديًّا دون أيّ تكلّف.
كل أمر يغيّر شيئًا يُنفَّذ داخل جلسة موثَّقة: يتبادل الهاتف والرقاقة تحدّيًا واستجابة بأحد تلك المفاتيح، ويشتقّان منه مفاتيح الجلسة، ومن تلك اللحظة يحمل كل أمر رمز MAC أو يُشفَّر بالكامل. هذه هي المراسلة الآمنة التي سيعود إليها هذا المنشور مرارًا. وNFC.cool ينفّذها كاملةً، على iPhone وعلى Android، وكل كتابة موصوفة أدناه تمرّ عبرها.
ما تكشفه لك لمسة واحدة
ألصق وسمًا بهاتفك فيُجري NFC.cool Tools على iPhone أو Android قراءة عميقة دون أن يطلب منك شيئًا: هوية الرقاقة وما إذا كانت من طراز TagTamper، والرابط، وإعدادات كل ملف وصلاحيات الوصول إليه، وأيّ خانات المفاتيح غُيّرت عن ضبط المصنع، ونتائج ثلاثة فحوص مستقلة.
هل هذا سيليكون NXP أصلي؟
كل وسم NTAG 424 DNA يغادر المصنع حاملًا توقيع أصالة: توقيع ECDSA على معرّف UID الخاص بالرقاقة المكوّن من سبعة بايتات، مصنوع بمفتاح NXP الخاص على المنحنى P-224. يقرؤه NFC.cool ويتحقق منه مقابل مفتاح NXP العام المنشور، على الهاتف مباشرةً، دون أيّ مفتاح منك. فإن اجتاز الفحص، يعرض التطبيق «NXP الأصلية». وهذا يجيب عن السؤال الأول: هل هذا سيليكون NXP حقيقي، أم رقاقة شبيهة لا تحمل منه سوى الاسم؟
هل هذه اللمسة أصلية؟
هذا هو فحص SUN. يأخذ التطبيق picc_data وcmac من الرابط الذي قدّمه الوسم للتوّ، ويفكّ تشفير بيانات PICC ليستخرج معرّف UID وعدّاد القراءات، ويعيد حساب CMAC، ويقارنه بما أرسله الوسم. فإن تطابقا، ترى «أصلي» ويظهر لك الرقم في خانة عداد القراءات.
هذا الفحص يحتاج إلى مفتاح الوسم، فذلك جوهر الفكرة كلها. الوسم الذي لا يزال على مفاتيح المصنع يُتحقق منه بالمفتاح الصفري. والوسم الذي أقفلته بمفتاحك أنت يُتحقق منه بالمفتاح الذي حفظه NFC.cool حين عيّنته. والوسم الذي أقفله شخص آخر بمفتاح لا تملكه يعرض «غير مُتحقّق»، وهي الإجابة الصحيحة.
هل كُسر الختم؟
إحدى نسخ هذه الرقاقات، وهي NTAG 424 DNA TagTamper، مصنوعة لتكون ختمًا يكشف العبث. إنها ملصق تمرّ عبره حلقة موصلة رفيعة. تلصقه فوق ما تريد حمايته، على لسان صندوق أو حول غطاء زجاجة، الوظيفة نفسها التي تؤدّيها اليوم ملصقات «يبطل الضمان إن كُسر». افتح العنصر فتمزّق الملصق، فتنقطع الحلقة.
تتتبّع الرقاقة أمرين بشأن تلك الحلقة: مزلاجًا دائمًا يسجّل ما إذا كانت قد فُتحت يومًا، والحالة الحيّة في هذه اللحظة. يقرأ NFC.cool كليهما مع كل لمسة ويخبرك بالنتيجة: «مغلق»، أو «تم فتحه»، أو النتيجة الأهمّ على الإطلاق «تم فتحه، ثم أُعيد إغلاقه»: أي أن أحدهم قطع الحلقة ثم أغلقها بعناية من جديد. والمزلاج أحادي الاتجاه، فالصندوق الذي أُعيد ختمه يظلّ يُقرأ على أنه مفتوح طوال عمر الرقاقة. التشفير يُثبت أن الرقاقة أصلية. وهذا يُثبت أن لا أحد دخل الصندوق.
برمجة وسومك بنفسك: النسخة المختصرة
القراءة نصف الأمر. والنصف الآخر أن تلك الوسوم الفارغة من AliExpress ملكك تبرمجها كما تشاء، والحدّ الأدنى من الإعداد ثلاث خطوات.
اكتب رابطك. كتابة NDEF عادية، كما على أيّ وسم.
فعّل SUN. يكتب التطبيق رابطك مع مواضع محجوزة، ويُملي على الرقاقة أن تعكس معرّفها المشفّر وعدّاد اللمسات والتوقيع في تلك المواضع مع كل قراءة. ومن الآن فصاعدًا تنتج كل لمسة رابط URL فريدًا وموقّعًا.
عيّن Key 0 الخاص بك. يستبدل هذا أصفار المصنع بمفتاح لا يعرفه سواك، فلا يستطيع أحد غيرك إعادة تهيئة الوسم.
في تلك الخطوة الأخيرة تكتب عبارة مرور، لا مفتاحًا. يشتقّ NFC.cool مفتاح AES منها بأخذ أول ١٦ بايتًا من تجزئة SHA-256 لعبارة المرور، بالطريقة نفسها على iPhone وAndroid، فالوسم الذي تجهّزه على أحدهما يُفتح بعبارة المرور نفسها على الآخر. وإن فضّلت مفتاحًا مولَّدًا في مكان آخر، على خادمك أنت مثلًا، فبإمكانك بدلًا من ذلك لصق ٣٢ حرفًا ست عشريًّا.
ضياع المفتاح يعني وسمًا لن تستطيع إعادة تهيئته أبدًا، لذا يحرص التطبيق على المكان الذي يذهب إليه. على iPhone يُحفظ في سلسلة المفاتيح ويتزامن عبر iCloud Keychain. وعلى Android يُشفَّر بمفتاح مدعوم بالعتاد ويُنسخ إلى Block Store، فينجو من إعادة تثبيت التطبيق أو الانتقال إلى هاتف جديد. ويُحفظ المفتاح الجديد قبل إرسال التغيير، فإن انقطعت اللمسة في منتصف التغيير بقيت القيمتان القديمة والجديدة متاحتين حتى يؤكّد الوسم أيّهما يحمل. كما يمكنك إدخال عبارة مرور عيّنتها على جهاز آخر، ويفحصها التطبيق مقابل الوسم قبل حفظها.
ثمة شيء واحد يرفضه التطبيق عمدًا: كتابة رابط عادي على وسم مفعَّل فيه SUN عبر شاشة الكتابة العادية. فمواضع الانعكاس ثابتة على الرابط الذي هُيّئت له، ورابط بطول مختلف سيترك الرقاقة تعكس قيمها في منتصف محتواك الجديد مع كل لمسة. أما شاشة NTAG 424 فتوقف SUN أولًا، ثم تكتب.
ما تبقّى من الرقاقة
عند تلك النسخة المختصرة تتوقف معظم الشروحات، وحتى الآن كان السبيل إلى ما بعدها هو أداة TagXplorer من NXP على حاسوب مكتبي بقارئ USB. أردت أن تكون ورقة البيانات كلها في متناول الهاتف، فتتبّعتها قسمًا قسمًا.
المفاتيح الخمسة كلها
لـKey 0 شاشته الخاصة، أما المفاتيح من Key 1 إلى Key 4 فتقبع تحت «متقدم». يمكن تعيين كلٍّ منها من عبارة مرور أو قيمة ست عشرية، أو إعادته إلى ضبط المصنع، أو إدخاله بعد أن عُيّن على جهاز آخر. وكل تغيير يتوثّق بـKey 0، صاحب سلطة التغيير على الخانات الخمس جميعًا.
SUN بالمفاتيح التي تختارها
تفعيل SUN ليس مجرّد زرّ واحد تضغطه. فأنت تختار الوضع: مشفّرًا، حيث ينتقل معرّف UID داخل picc_data ولا يقرؤه إلا من يحمل المفتاح، أو صريحًا، حيث يظهر المعرّف والعدّاد في الرابط على المكشوف ولا يبقى سرًّا سوى التوقيع. وتختار أيّ المفاتيح يؤدّي العمل: مفتاح القراءة الوصفية الذي يشفّر بيانات PICC، ومفتاح قراءة الملف الذي يحسب التوقيع. ويمكن أن يكونا الخانة نفسها أو خانتين مختلفتين، وبهذه الطريقة تستطيع علامة تجارية أن تسلّم شريكًا المفتاح الذي يتحقق من اللمسات دون أن تسلّمه المفتاح الذي يفكّ تشفير المعرّفات.
ينبّهك التطبيق إن اخترت خانة لا تزال على أصفار المصنع، لأن توقيعًا مصنوعًا بمفتاح معروف لا يحمي شيئًا. وجانب التحقق يفهم التنوّع نفسه: فاللمسة الموقّعة بـKey 3 والمشفّرة بـKey 1 يُتحقق منها بشكل صحيح ما دام هذان المفتاحان مخزّنين على الهاتف.
صلاحيات الوصول إلى الملفات
يحمل كل ملف أربع صلاحيات: القراءة، والكتابة، والقراءة والكتابة معًا، والتغيير، والأخيرة تحكم من يجوز له تعديل الثلاث الأخرى. وتشير كل صلاحية إلى أحد المفاتيح الخمسة، أو إلى «حر» (أيّ أحد)، أو إلى «أبدًا» (لا أحد، على الإطلاق). فبإمكانك أن تقول «يجوز لأيّ أحد قراءة File 02، ولا يكتب فيه سوى Key 2، ولا يغيّر هذه القواعد سوى Key 0»، وتفرض الرقاقة ذلك دون أيّ تطبيق في المعادلة.
يعرض NFC.cool الصلاحيات الحالية لكل ملف ويتيح لك تعديلها، مع تحذيرين مدمجين. فهو يخبرك حين تشير صلاحية إلى مفتاح لا يحمله هذا الهاتف، لأنك قد تقفل الباب على نفسك. ويجعلك تؤكّد عبر خطوة منفصلة قبل ضبط التغيير على «أبدًا»، لأنه ما إن يُكتب ذلك حتى تتجمّد قواعد الملف طوال عمر الرقاقة.
تكوين الرقاقة
تحت الملفات يقبع تكوين الرقاقة نفسها، الذي تتيحه NXP عبر أمر واحد هو SetConfiguration. ويغطّي NFC.cool هذه الخيارات:
المعرّف العشوائي. في العادة تبلّغ الرقاقة كل قارئ بمعرّف UID الثابت نفسه، ما يتيح لأيّ أحد تتبّع الوسم عبر اللمسات. ومع تفعيل المعرّف العشوائي، تردّ في كل مرة بمعرّف عشوائي جديد ولا تكشف الحقيقي إلا بعد أن تتوثّق. مكسب حقيقي للخصوصية، ودائم. ولأن التطبيق يميّز الوسوم بمعرّفاتها، فإنه يستعيد المعرّف الحقيقي لاحقًا بتجربة كل Key 0 يعرفه عبر أمر GetCardUID موثَّق، فيبقى الوسم قابلًا للإدارة على الهاتف الذي جهّزه.
حدّ محاولات التوثّق الفاشلة. كم محاولة بمفتاح خاطئ تحتملها الرقاقة قبل أن تقفل Key 0. إنه حماية من تخمين المفاتيح، لكن اضبطه منخفضًا أكثر من اللازم فقد تقفل حفنة من اللمسات الفاشلة المفتاح الرئيسي إلى الأبد.
قوة التضمين الراجع. قوية أو قياسية. القياسية قد تتعذّر قراءتها على الهوائيات الصغيرة، لذا فمن الحكمة إبقاؤها على الإعداد الافتراضي.
الكتابة المتسلسلة. يمكن تعطيلها بحيث تُحدّ الكتابة الواحدة بإطار واحد. دائم.
بايتات الإمكانات. بايتان حرّان تتركهما NXP لاستخدامك الخاص.
LRP. زرّ تبديل المراسلة الآمنة، وله قسمه الخاص أدناه.
الخزنة
File 03 ملف خاص بحجم ١٢٨ بايت تستطيع الرقاقة إبقاءه مشفّرًا، ويحوّله NFC.cool إلى مخزن خاص صغير على الوسم نفسه. في أول مرة تحفظ فيها شيئًا، يحوّل التطبيق الملف إلى الوضع المشفّر بالكامل ويقفل كل صلاحيات الوصول على Key 0. بعدها تتّسع الخزنة لما يصل إلى ١٢٦ بايتًا من النص لا يستطيع قراءتها سوى مفتاحك، والقراءة العميقة من أيّ هاتف آخر لا تحصل إلا على خطأ في الصلاحية ولا شيء غيره.
إنها مخصّصة لسرّ ينبغي أن يرافق الشيء نفسه بدلًا من أن يقبع في قاعدة بيانات لدى أحدهم: رقم تسلسلي، أو ملاحظة لنفسك في المستقبل، أو رمز يتوقّعه خادمك أنت. وإعادة Key 0 إلى ضبط المصنع تمحوها، وهذه هي الطريقة الوحيدة التي تزول بها الخزنة.
وضع LRP
في العادة تحمي الرقاقة مفاتيحها بـAES عاديّ، وسرقة مفتاح تعني كسر AES نفسه. لكن هناك خطّ هجوم أكثر مكرًا. ضع الرقاقة على طاولة اختبار، وقِس التغيّرات الخفيفة في سحبها للطاقة وانبعاثاتها الكهرومغناطيسية بينما تُجري التشفير، ومع ما يكفي من تلك الآثار تستطيع إعادة بناء المفتاح من التسرّب وحده، دون أن تمسّ الرياضيات إطلاقًا. أما LRP، أي Leakage-Resilient Primitive، فقناة آمنة أُعيد بناؤها لتترك ذلك التسرّب بلا شيء يتمسّك به. توثّقها NXP في المستند AN12304، وهي مبالغة حقيقية لأجل ملصق على زجاجة نبيذ، ولهذا لا تفعّلها معظم الوسوم أبدًا ولا تتعلّم معظم الأدوات التحدّث بها.
في ملاحظات تصميمي للنسخة الأولى، بجانب «وضع LRP» مباشرةً، كنت قد كتبت «غير مخطّط له». لكنه ظلّ يلحّ عليّ، فبنيته. يستطيع NFC.cool أن يحوّل وسمًا إلى وضع LRP، والأهمّ أنه لا يزال قادرًا بعد ذلك على التوثّق معه وإدارته: المفاتيح، وصلاحيات الملفات، والخزنة، وتكوين الرقاقة، كلها عبر قناة LRP بدلًا من AES.
أمران عليك معرفتهما قبل أن تُقدِم على تلك الخطوة. الأول أنه دائم: ما إن يدخل الوسم وضع LRP حتى تتعطّل مراسلته الآمنة بـAES إلى الأبد، ولن تستطيع أيّ أداة لا تتحدّث سوى AES مخاطبته من جديد. والثاني أن SUN غير متاح على وسم LRP، فالوسم الذي مهمّته توقيع اللمسات ينبغي أن يبقى في وضع AES.
ما لا يمكن التراجع عنه
كثير من هذه الأوامر دائم، والتطبيق ينبّهك إلى ذلك بوضوح شديد في حينه: فكل إجراء لا رجعة فيه يجعلك تؤكّد عبر تحذير يوضّح العاقبة بالضبط. ويجدر سردها هنا أيضًا.
تفعيل LRP.
تفعيل المعرّف العشوائي.
تعطيل الكتابة المتسلسلة.
ضبط صلاحية التغيير لملف على «أبدًا».
ضياع مفتاح. فليس في الرقاقة إعادة ضبط إلى حالة المصنع. وإن ذهب Key 0، ذهبت معه قدرتك على إعادة تهيئة الوسم.
حدّ منخفض أكثر من اللازم لمحاولات التوثّق الفاشلة، فقد يقفل Key 0 بعد بضع لمسات خاطئة.
تمرّن على وسم احتياطي قبل أن تمسّ وسمًا يهمّك.
أين تُستخدم وسوم NFC المضادة للتزوير فعلًا
بصراحة؟ معظم من يلمسون وسم NFC لا يحتاجون أيًّا من هذا أبدًا، ولا بأس بذلك. فالملصق الذي يفتح رابطًا شيء رائع وممل ومفيد.
لكن بمجرد أن تمسك واحدًا منها، تصبح الاستخدامات بديهية. الحقيبة الفاخرة تستطيع أن تُثبت أنها أصلية. وزجاجة نبيذ أو ويسكي تستطيع أن تُظهر أنها لم تُفتح خفيةً وتُملأ من جديد، فيحمل ختم العبث ذلك النصف. وعلبة دواء تضمن كلًّا من الدواء الحقيقي بداخلها وختمًا لم يكسره أحد. وتذاكر الفعاليات تكفّ عن كونها شيئًا يمكنك التقاط صورة له وتمريره، والوسم عند باب يُثبت أن أحدهم وقف هناك فعلًا بدلًا من إعادة تشغيل رابط محفوظ من أريكته. إنها مشكلة الأصالة نفسها التي يدور حولها جواز المنتج الرقمي في الاتحاد الأوروبي من جهة التنظيم، محلولةً على مستوى الشيء المفرد.
لم أبنِ هذا لأن ألف مستخدم طلبوه. بنيته لأنني اشتريت بعض الوسوم الغريبة من الإنترنت بدافع الفضول، وفهمت كيف تعمل، ثم عجزت عن ترك صفحة واحدة من ورقة البيانات دون أن أقلبها. هكذا تبدأ الميزات الجيّدة عادةً.
خلاصة القول في وسوم NTAG 424 DNA
وسوم NTAG 424 DNA هي أقرب ما لدى NFC إلى ختم مقاوم للعبث. لا تستطيع منع أحد من نسخ منتج، لكنها تجعل إثبات أنه أصلي مستحيل التزييف، لأن ذلك الإثبات توقيع تشفيري جديد لا تستطيع إنتاجه إلا الرقاقة الحقيقية.
يقرأها NFC.cool Tools، ويتحقق من الرقاقة واللمسة وختم العبث، ويسلّمك الرقاقة كاملةً لتهيّئها: كل مفتاح، وصلاحيات كل ملف، وإعدادات الرقاقة نفسها، وحتى LRP، كل ذلك من هاتفك. وإن سبق أن تساءلت كيف تستطيع لمسة أن تميّز الحقيقي من المزيّف، فاحصل عليه على iPhone أو Android، واطلب اثنين من هذه الوسوم ببضعة يوروهات، والمس واحدًا بنفسك. إنه موضوع شيّق يستحقّ الغوص فيه.
