> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # الشريحة EMV والدفع اللاتلامسي: ماذا يحدث في ثانيتين؟ - URL: https://arabroot.io/articles/الشريحة-emv-والدفع-اللاتلامسي-contactless/ - Published: 2026-10-27T16:45:37.000Z - Updated: 2026-10-27T19:06:41.000Z - Description: نفك بيانات الشريحة في الحقل 55 من عينة منشورة، ونعيد حساب رمز ARQC منشور خطوة خطوة، ونرى كيف يقرر الجهاز الاتصال بالبنك أو الموافقة دونه. - Author: فريق عرب رووت - Tags: الأدلة التقنية, التقنية المالية والمدفوعات لنفرض أن شركة ناشئة تبني نظام نقاط بيع لسلسلة مقاه، والدفع فيه بالبطاقة والجوال دون تلامس عبر أجهزة يوفرها المستحوذ Acquirer. وفي أسبوعها الثالث وصلتها رسالة من عميل غاضب: «دفعت قهوة بـ 15 ريالاً مرة واحدة، فخصمت مرتين في ثلاث ثوان». وفي الأسبوع نفسه وصلتها من المستحوذ ملاحظة تقنية تقول إن بعض العمليات «رفضها المصدر لأن بيانات الشريحة لا تتحقق»، ومعها سطر طويل من الحروف والأرقام الست عشرية في الحقل 55 لا يفهم منه الفريق شيئاً. والسؤالان في الحقيقة سؤال واحد: ما الذي تقوله البطاقة للبنك في كل نقرة، وكيف يعرف البنك أن هذه النقرة حقيقية وجديدة، لا نسخة من نقرة سابقة؟ والإجابة كلها في ذلك السطر الطويل. فقد رأينا في [مقال رسائل البنوك](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/) أن الحقل 55 في رسالة ISO 8583 «رسالة صغيرة داخل الرسالة» تحمل بيانات الشريحة، ورأينا في [مقال عملية الدفع بالبطاقة](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/) أطراف العملية والتفويض والتسوية، وفي [مقال الصراف الآلي](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%B5%D8%B1%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D9%84%D9%8A-atm-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/) أن رمز التحقق MAC بين الجهاز والمضيف يحمي الرسالة في الطريق. وهذا المقال يفتح ما لم نفتحه هناك: ماذا تفعل الشريحة نفسها في الثانيتين اللتين تلمس فيهما البطاقة الجهاز، وما الرمز الذي تحسبه، ولماذا لا يستطيع أحد أن ينسخه. وسوف نقرأ في الطريق عينة حقيقية منشورة لبيانات الحقل 55 من دليل تكامل رسمي، ونفكها يدوياً وبمكتبة، ثم نعيد حساب رمز بطاقة منشور بمفاتيح اختبار خطوة خطوة حتى نصل إلى الرقم نفسه. وسوف نناقش في هذا المقال ما يلي: - لماذا جاءت الشريحة بعد الشريط الممغنط، ومن يضع مواصفات EMV. - الفرق بين الشريحة بالتلامس واللاتلامسي، والنواة Kernel، وما يحدث في الثانيتين أمراً أمراً. - صيغة TLV التي تحمل كل شيء، وتجربة عملية تفك عينة الحقل 55 المنشورة. - الرمز ARQC: كيف تشتق البطاقة مفاتيحها وتوقع العملية، وتجربة تعيد حسابه حتى القيمة المنشورة. - القرار دون اتصال أو بالاتصال: نتائج الفحص TVR ورموز القرار، وحدود اللاتلامسي، وتجربة لكل حالة. - التحقق من حامل البطاقة CVM، وما يفحصه البنك والجهاز، وحالة موثقة من بحث جامعة Cambridge. - ما يلمسه فريق منتج فعلاً، والأخطاء الشائعة، وقائمة تحقق. ## لماذا جاءت الشريحة؟ مشكلة البيانات الثابتة الشريط الممغنط خلف البطاقة يحمل بيانات ثابتة: رقم البطاقة وتاريخ الانتهاء ورمز تحقق محسوباً مرة واحدة عند الإصدار. وكل قراءة له تعطي البيانات نفسها بالضبط، فمن نسخها مرة واحدة يستطيع أن يكتبها على شريط آخر، ولن يجد البنك فرقاً بين البطاقة الأصلية والنسخة، لأن الطلبين متطابقان حرفاً بحرف. وهذه المشكلة لا تحلها كلمة مرور أطول ولا شريط أفضل، لأن أصلها أن البطاقة «تقول» شيئاً ولا «تحسب» شيئاً. والشريحة تغير هذا من الأساس: فهي حاسب صغير فيه مفتاح سري لا يخرج منها، وفي كل عملية تحسب بهذا المفتاح رمزاً من بيانات العملية نفسها، المبلغ والتاريخ ورقم عشوائي من الجهاز وعداد يزيد مع كل عملية. فالرمز يختلف في كل مرة، ومن ينسخه لا يستطيع أن يستعمله لعملية أخرى. وتصف EMVCo ذلك في [صفحة الشريحة بالتلامس](https://www.emvco.com/emv-technologies/emv-contact-chip/?ref=arabroot.io) بأن الشريحة تولد رمز أمان يستخدم مرة واحدة لكل عملية، فيساعد على منع الاحتيال بالبطاقات المزورة والمفقودة والمسروقة، وتذكر الصفحة نفسها أن أكثر من 15.6 مليار بطاقة دفع بالشريحة مستخدمة اليوم، وأنها تشغل 96% من عمليات الشراء داخل المتاجر عالمياً. ![صورة مقربة جداً لشريحة بطاقة دفع: مربع ذهبي فاتح مقسم إلى نقاط تلامس معدنية، وبجانبه رمز الدفع دون تلامس بأربعة أقواس، وتحته أرقام بارزة من رقم البطاقة](https://arabroot.io/content/images/2026/10/emv-contactless-07-photo-card-chip.webp) شريحة بطاقة دفع عن قرب: ما تراه هو نقاط التلامس المعدنية التي يلمسها القارئ، أما الحاسب الصغير الذي يحفظ المفتاح ويحسب الرمز فمدفون تحتها، وبجانبها رمز الدفع دون تلامس. الصورة: kuhnmi، بترخيص [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Credit%5FCard%5FChip%5F%2834684294971%29.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP). ومن يضع هذه المواصفات؟ تقول [صفحة التعريف بـ EMVCo](https://www.emvco.com/about-us/?ref=arabroot.io) إنها تأسست في 1999 لمعالجة التشغيل البيني بين الدول ومكافحة الاحتيال، وتملكها ست شبكات معاً: American Express وDiscover وJCB وMastercard وUnionPay وVisa. وتذكر صفحة الشريحة أن المواصفات تحدد متطلبات الشريحة وجهاز القبول معاً، وأنها مبنية على معايير ISO/IEC 7816 للبطاقة بالتلامس وISO/IEC 14443 للبطاقة دون تلامس، وعلى ISO 8583 للرسائل. أي أن EMV لا تخترع كل شيء، بل ترتب ما فوق هذه المعايير: ماذا يسأل الجهاز البطاقة، وبأي ترتيب، وماذا تحسب البطاقة، وكيف يتحقق البنك. ## الشريحة بالتلامس واللاتلامسي: ما الفرق؟ في الشريحة بالتلامس تدخل البطاقة في الجهاز، فتلمس نقاطها النحاسية نقاط القارئ، وتبقى في الجهاز حتى ينتهي كل شيء، بما فيه رد البنك. أما في اللاتلامسي فالبطاقة أو الجوال يقترب من الجهاز، فيتكلمان عبر الحقل اللاسلكي القريب NFC، ويجب أن ينتهي الحوار في وقت قصير جداً، لأن العميل لن يبقي يده ثابتة فوق الجهاز. وهذا الفرق في الوقت هو مصدر أغلب الفروق التقنية بين النوعين، كما سنرى في التسلسل. ![ظهر بطاقة دفع مضاءة من الخلف بحيث يظهر داخلها: سلك نحاسي رفيع يدور حول حافة البطاقة كلها ويتصل بالشريحة، والبيانات الشخصية مغطاة بمستطيلات سوداء](https://arabroot.io/content/images/2026/10/emv-contactless-08-photo-nfc-antenna.webp) بطاقة مضاءة من الخلف يظهر فيها ما لا تراه عادة: هوائي نحاسي يدور حول حافة البطاقة ويتصل بالشريحة، ومنه تأخذ الشريحة الطاقة من مجال القارئ وتتحدث معه دون تلامس. الصورة: iToms، بترخيص [CC BY-SA 3.0 DE](https://creativecommons.org/licenses/by-sa/3.0/de/deed.en?ref=arabroot.io)، المصدر: [Wikimedia Commons](https://commons.wikimedia.org/wiki/File:Maestro%5FEMV%5FPaypass%5FNFC.jpg?ref=arabroot.io) (تم تصغيرها وتحويلها إلى WebP، والنسخة متاحة بالرخصة نفسها). وتقول EMVCo في [صفحة الشريحة دون تلامس](https://www.emvco.com/emv-technologies/emv-contactless-chip/?ref=arabroot.io) إنها تدعم الدفع بالبطاقات دون تلامس وبالأجهزة الجوالة التي فيها NFC، وإن مواصفاتها هي الكتب A وB وC-X: الكتاب B نقطة الدخول Entry Point، وهي الجزء من الجهاز الذي يختار التطبيق والنواة المناسبة، والكتاب C-X مواصفة النواة Kernel، وتنشر كل شبكة دفع نواتها الخاصة ككتاب C برقم. والنواة كما تعرفها الصفحة مجموعة وظائف لتطبيق الدفع في جهاز القبول، أي البرنامج الذي يدير الحوار مع البطاقة بقواعد تلك الشبكة. وتذكر الصفحة أن الإصدار 2.12 من الكتاب B والإصدار 1.2 من الكتاب C-8 نشرا في 6 يوليو 2026، والكتاب C-8 نواة جديدة موحدة تقدمها EMVCo بدل أن يكون لكل شبكة نواة مختلفة. وقد يتساءل البعض: لماذا يحتاج الجهاز أكثر من نواة؟ والإجابة أن كل شبكة طورت قواعد الحوار اللاتلامسي لبطاقاتها في وقت مختلف وبتفاصيل مختلفة، فالجهاز الذي يقبل عدة شبكات يحمل عدة أنوية، ونقطة الدخول تختار الصحيحة بحسب التطبيق الذي اختارته البطاقة. ولفريق المقاهي معنى عملي لهذا: الجهاز الذي يوفره المستحوذ معتمد لأنوية محددة بإصدارات محددة، وهذا الاعتماد هو ما تسميه EMVCo اختبارات المستوى الثاني Level 2، فلا يكتب الفريق نواة بنفسه، ولا يغير شيئاً في الحوار مع البطاقة، بل يستقبل نتيجته من مجموعة أدوات المطور SDK التي مع الجهاز. ## ماذا يحدث في الثانيتين؟ الحوار بين الجهاز والبطاقة أوامر وردود قصيرة تسمى APDU، كل أمر له اسم ورقم، والبطاقة ترد ببيانات ورمز حالة. والصورة التالية تبين التسلسل المبسط من لمس البطاقة حتى رد البنك: ![مخطط تسلسل بين البطاقة أو الجوال والجهاز والمستحوذ والشبكة والبنك المصدر: 1 الجهاز يرسل SELECT للسؤال عن تطبيقات الدفع PPSE ثم AID فترد البطاقة بالقائمة ومعها PDOL، 2 GET PROCESSING OPTIONS ومعه المبلغ والرقم العشوائي 9F37 فترد بـ AIP 82 وأماكن السجلات AFL، 3 READ RECORD للرقم وتاريخ الانتهاء والشهادات، 4 الجهاز يفحص التاريخ وقائمة الاستثناء والحدود والتحقق دون اتصال، 5 GENERATE AC لطلب ARQC فترد بـ ARQC 9F26 مع ATC 9F36 وCID 9F27 وIAD 9F10، 6 طلب تفويض والحقل 55 يحمل هذه الوسوم، 7 رد 00 ومعه الوسم 91 أي ARPC، 8 في التلامس يعطي الجهاز ARPC للبطاقة لتتحقق منه، وفي اللاتلامسي تنتهي البطاقة عند الخطوة 5](https://arabroot.io/content/images/2026/10/emv-contactless-01-two-seconds.webp) البطاقة تنهي عملها عند الخطوة 5 في اللاتلامسي، ثم يتكلم الجهاز مع البنك وحده وكل خطوة لها سبب: 1. **اختيار التطبيق SELECT**: البطاقة الواحدة قد تحمل أكثر من تطبيق دفع، فيسأل الجهاز أولاً عن القائمة، ثم يختار تطبيقاً بمعرفه AID. وترد البطاقة ومعها قائمة البيانات التي تريدها من الجهاز في الخطوة التالية، وتسمى PDOL. 2. **بدء المعالجة GET PROCESSING OPTIONS**: يعطي الجهاز البطاقة ما طلبته، مثل المبلغ والعملة والرقم العشوائي، وترد البطاقة بملف تعريف التطبيق AIP الذي يقول ماذا تدعم، وبأماكن السجلات التي يقرؤها الجهاز. 3. **قراءة السجلات READ RECORD**: رقم البطاقة وتاريخ الانتهاء والشهادات اللازمة للتحقق دون اتصال، وغيرها. 4. **فحوص الجهاز**: هل التطبيق منتهي الصلاحية؟ هل البطاقة في قائمة استثناء عند الجهاز؟ هل المبلغ فوق حد معين؟ هل تحقق توقيع البيانات دون اتصال؟ ويسجل الجهاز نتيجة كل فحص بخانة في نتائج فحص الجهاز TVR. 5. **طلب الرمز GENERATE AC**: يطلب الجهاز من البطاقة رمزاً، فتقرر البطاقة بقواعدها هل ترفض أم توافق دون اتصال أم تطلب الاتصال بالبنك، وتحسب الرمز المناسب. 6. **التفويض بالاتصال**: إذا كان الرمز طلباً للاتصال، يضع الجهاز الوسوم في الحقل 55 ويرسلها مع طلب التفويض، كما في مقال رسائل البنوك. 7. **رد البنك**: يحمل رمز الرد، ومعه غالباً بيانات تحقق المصدر في الوسم 91، وأحياناً أوامر للبطاقة نفسها. ولاحظ الفرق في الخطوة الأخيرة. ففي الشريحة بالتلامس البطاقة ما زالت في الجهاز حين يصل رد البنك، فيعطيها الجهاز رد البنك لتتحقق أنه من بنكها فعلاً، ثم تحسب رمزاً نهائياً. أما في اللاتلامسي فالبطاقة ابتعدت غالباً بعد الخطوة 5، فلا تعرف ما قاله البنك. وهذا ليس ضعفاً في التصميم، بل اختيار مقصود لتقصير الحوار، ونتيجته أن أوامر البنك للبطاقة، مثل تحديث عداد أو حد، لا تصل إليها في كل عملية لاتلامسية، فتصلها في عملية بالتلامس لاحقاً أو بطرق أخرى تحددها الشبكة. ## صيغة TLV: لغة البطاقة كل ما تقوله البطاقة وكل ما يرسله الجهاز إلى البنك من بياناتها مكتوب بصيغة واحدة: وسم Tag يقول ما هذا الحقل، ثم طول Length يقول كم بايتاً قيمته، ثم القيمة Value نفسها. وهذه الصيغة مأخوذة من ترميز BER المعروف في ASN.1، وفكرتها قريبة من فكرة الخريطة Bitmap في ISO 8583: لا تحتاج أن ترسل كل الحقول، بل ترسل ما عندك، وكل حقل يحمل اسمه معه. والفرق أن الخريطة تقول أي الحقول موجودة دفعة واحدة في البداية، أما TLV فكل حقل يعرف بنفسه، فيمكن أن تأتي الوسوم بأي ترتيب، وأن يتجاهل القارئ وسماً لا يعرفه ويكمل. والصورة التالية تفك وسماً واحداً من العينة التي سنقرؤها بعد قليل، وهو الرمز الذي حسبته البطاقة: ![تشريح TLV: الوسم 9F26 من بايتين، ثم الطول 08، ثم القيمة 79B5FCD1DAE1BA29. والقارئ يعرف أن الوسم بايتان لأن 9F بالثنائي 1001 1111 وآخر خمس خانات كلها 1، ثم 26 بالثنائي 0010 0110 والخانة العليا صفر فهو آخر بايت. والطول 08 أقل من 80 فهو الطول نفسه، و81 أو 82 تعني أن الطول في البايتات التالية، وفي العينة 9F10 طوله 20 أي 32 بايتاً. والوسم المركب 71 خانته السادسة 1 فبداخله وسوم أخرى: 9F18 معرف النص و86 أمر للبطاقة من البنك](https://arabroot.io/content/images/2026/10/emv-contactless-02-tlv.webp) ثلاث قواعد صغيرة تكفي لقراءة أي سلسلة TLV في EMV والقواعد الثلاث كما يلي: - **الوسم بايت أو أكثر**: إذا كانت الخانات الخمس الدنيا في البايت الأول كلها 1، كما في `9F` و`5F`، فالوسم يكمل في البايت التالي، وكل بايت تال خانته العليا 1 يعني أن بعده بايتاً آخر. ولهذا `9F26` وسم واحد من بايتين، و`82` وسم من بايت واحد. - **الطول بايت أو أكثر**: إذا كان أقل من `80` فهو الطول مباشرة، وإذا كان `81` فالطول في البايت التالي، و`82` في البايتين التاليين. - **الوسم المركب Constructed**: إذا كانت الخانة السادسة في البايت الأول من الوسم 1، فقيمته ليست بيانات بل سلسلة TLV أخرى، مثل القالب `71` الذي سنراه في رد البنك. ## تجربة عملية: نفك عينة الحقل 55 المنشورة أردنا لهذه التجربة بيانات لم نكتبها نحن، حتى لا نقرأ ما نعرفه مسبقاً. ووجدنا في [دليل تكامل البطاقات الحاضرة لدى Cybersource](https://developer.cybersource.com/docs/cybs/en-us/cp-retail/integration/eftpos/rest/cp-retail.html?ref=arabroot.io)، وهي من شركات Visa، مثالاً لطلب دفع ببطاقة eftpos بالتلامس فيه بيانات الشريحة كاملة في الحقل `pointOfSaleInformation.emv.tags`، ومثالاً لرد فيه بيانات البنك. وهذه بيانات عينة منشورة للمطورين، لا بطاقة حقيقية لشخص. فكتبنا سكربتاً يفك السلسلتين بطريقتين: بدالة كتبناها بالقواعد الثلاث أعلاه، وبالدالة `tlv.decode` في مكتبة [pyemv](https://github.com/knovichikhin/pyemv?ref=arabroot.io)، وهي مكتبة Python بترخيص MIT للتشفير في EMV، ثم يقارن النتيجتين. وهذه دالة الفك اليدوية: ```python def parse(data: bytes, depth=0, out=None): """BER-TLV as EMV uses it: tag (1-3 bytes), length (short or 81/82 long form), value.""" out = [] if out is None else out i = 0 while i < len(data): t0 = i first = data[i]; i += 1 if first & 0x1F == 0x1F: # low 5 bits all ones: the tag continues while data[i] & 0x80: # high bit set: one more tag byte follows i += 1 i += 1 tag = data[t0:i].hex().upper() n = data[i]; i += 1 if n & 0x80: # long form: low bits say how many length bytes follow k = n & 0x7F n = int.from_bytes(data[i:i + k], "big"); i += k value = data[i:i + n] if len(value) != n: raise ValueError(f"tag {tag}: length {n} but only {len(value)} bytes left") i += n constructed = bool(first & 0x20) # bit 6 of the first byte: value is more TLV out.append((depth, tag, n, value.hex().upper(), constructed)) if constructed: parse(value, depth + 1, out) return out ``` ولاحظ السطر الذي يرفع خطأ إذا كان الطول أكبر مما بقي من البيانات، فبدونه يقرأ الكود أقل مما يقوله الطول بصمت ويكمل، وهذا هو العطل نفسه الذي رأيناه في مقال رسائل البنوك حين قطعت الرسالة. وشغلناه في Container مؤقت من `python:3.13.17-slim` مع pyemv 1.5.0، بـ Dockerfile فيه سطر واحد للتثبيت: ```dockerfile FROM python:3.13.17-slim RUN pip install --no-cache-dir --root-user-action=ignore pyemv==1.5.0 WORKDIR /lab COPY tlv_lab.py crypto_lab.py decide.py un_check.py ./ ``` ```bash docker build -t sfa-emv-lab:1 . docker run --rm --name sfa-emv sfa-emv-lab:1 python tlv_lab.py ``` والمخرج سوف يكون كما يلي: ```text == request (terminal to issuer): 145 bytes 9F33 3 E0F0D0 Terminal Capabilities 95 5 0000000000 Terminal Verification Results (TVR) 9F37 4 5AB3314A Unpredictable Number 9F10 32 0FA501000000000000000000000000000F0E21C106100000002F000000000000 Issuer Application Data 9F26 8 79B5FCD1DAE1BA29 Application Cryptogram 9F36 2 01FA Application Transaction Counter 82 2 5C00 Application Interchange Profile (AIP) 9C 1 00 Transaction Type 9F1A 2 0036 Terminal Country Code 9A 3 170823 Transaction Date 5F2A 2 0036 Transaction Currency Code 9F03 6 000000000000 Amount, Other 9F27 1 80 Cryptogram Information Data 9F34 3 020000 CVM Results 9F35 1 22 Terminal Type 9F02 6 000000000700 Amount, Authorised 9F6E 10 0121C106100000002F82 Form Factor Indicator / Third Party Data 9F66 4 00004000 Terminal Transaction Qualifiers (TTQ) same as pyemv.tlv.decode: True (18 primitive tags) == response (issuer to terminal): 40 bytes 91 8 4B4E9D7600800000 Issuer Authentication Data 71 24 (constructed) Issuer Script Template 1 9F18 4 00000002 Issuer Script Identifier 86 15 8C1800000A8E0855D9DDEF76515D2C Issuer Script Command 8A 2 3936 Authorisation Response Code same as pyemv.tlv.decode: True (4 primitive tags) ``` الطلب 145 بايتاً فيها ثمانية عشر وسماً، والرد 40 بايتاً فيها قالب مركب واحد بداخله وسمان، والفك اليدوي طابق المكتبة في الاثنين. والصورة التالية ترتب الوسوم الثمانية عشر بحسب مصدرها، وهذا الترتيب هو أول ما يحتاجه من يقرأ الحقل 55 في سجل: ![وسوم عينة الحقل 55 مقسمة إلى ثلاث مجموعات: من البطاقة 82 AIP 5C00 و9F36 ATC 01FA أي 506 و9F26 ARQC و9F27 CID 80 أي ARQC و9F10 IAD 32 بايتاً و9F6E Form Factor، ومن الجهاز 9F33 القدرات E0F0D0 و9F35 النوع 22 و9F37 الرقم العشوائي 5AB3314A و95 TVR أصفار و9F34 CVM 020000 و9F66 TTQ 00004000، ومن العملية 9F02 المبلغ 7.00 و9F03 مبلغ آخر صفر و5F2A العملة 0036 و9F1A البلد 0036 و9A التاريخ 170823 و9C النوع 00 شراء. وملاحظة أن المبلغ في 9F02 هو 7.00 بينما مبلغ الطلب 1002.12، والوسم 8A في الرد 96 بينما رمز الرد 00](https://arabroot.io/content/images/2026/10/emv-contactless-05-field55.webp) ثلثها من البطاقة، وثلثها من الجهاز، وثلثها وصف للعملية نفسها ### ماذا تقول هذه الوسوم؟ بعد الفك يقرأ الجزء الثاني من السكربت أهم الوسوم خانة خانة، والمخرج: ```text == reading the request AIP 82 : 5C00 ['SDA supported', 'cardholder verification supported', 'terminal risk management', 'issuer authentication'] CID 9F27 : 80 ARQC (go online) TVR 95 : 0000000000 no check failed CVM 9F34 : 020000 enciphered PIN verified online Terminal 9F35 : 22 attended, offline with online capability, merchant Amount 9F02 : 7.0 | currency 5F2A 0036 | country 9F1A 0036 | date 9A 170823 | ATC 9F36 506 ARQC 9F26 : 79B5FCD1DAE1BA29 | UN 9F37 5AB3314A == reading the response ARPC + CSU 91 : 4B4E9D76 00800000 8A as ASCII : 96 script 86 : CLA 8C INS 18 P1P2 0000 Lc 0A ``` في المخرج أعلاه لاحظ التالي: - **ملف التطبيق AIP بقيمة `5C00`**: يقول إن البطاقة تدعم التحقق الثابت من بياناتها SDA، والتحقق من حامل البطاقة، وإدارة المخاطر في الجهاز، وتحقق البطاقة من البنك. ولا يقول إنها تدعم التحقق الديناميكي DDA أو المدمج CDA، وهما الأقوى لأن البطاقة فيهما توقع بيانات تتغير في كل عملية بمفتاح خاص بها، لا بيانات ثابتة وقعها البنك عند الإصدار. - **معلومات الرمز CID بقيمة `80`**: الخانتان العلويتان `10` تعنيان أن الرمز ARQC، أي أن البطاقة تطلب الاتصال بالبنك. ولو كانتا `01` لكان TC، أي موافقة دون اتصال، و`00` لكان AAC، أي رفض. - **نتائج الفحص TVR كلها أصفار**: لم يفشل أي فحص في الجهاز. - **نتيجة التحقق من حامل البطاقة `020000`**: الطريقة 02، أي رقم سري مشفر يتحقق منه البنك بالاتصال، وهي ما يتوقع في عملية بالتلامس بهذا المبلغ. - **العداد ATC بقيمة 506**: هذه العملية رقم 506 في حياة هذا التطبيق على البطاقة، وسنرى بعد قليل لماذا هو أهم وسم في قصة العميل الذي خصم مرتين. - **البلد والعملة `0036`**: الرمز الرقمي لأستراليا ودولارها في ISO 3166 وISO 4217، وهذا منطقي لأن eftpos شبكة أسترالية. ولو كانت عملية في السعودية لكان الرمز `0682` في الاثنين، كما رأينا رمز الريال 682 في مقال رسائل البنوك. - **في الرد الوسم `91`**: أول أربعة بايتات `4B4E9D76` هي رمز رد المصدر ARPC، والأربعة الباقية بيانات حالة يرسلها البنك للبطاقة. وهذا ما تتحقق منه البطاقة لتعرف أن الرد من بنكها، كما سنرى في التجربة التالية. - **القالب `71`**: نص للبطاقة Issuer Script، أي أمر يريد البنك أن تنفذه البطاقة بعد العملية، وفيه أمر واحد يبدأ بالبايتين `8C 18`. وهذه الأوامر محمية بمفاتيح خاصة بالرسائل الآمنة Secure Messaging، فلا يستطيع الجهاز ولا أحد في الطريق أن يغيرها. ### ما الذي لم يتطابق في العينة؟ حين قرأنا الوسوم بجانب حقول JSON في المثال نفسه، ظهر شيئان لم نتوقعهما. الأول أن المبلغ في الوسم `9F02` هو 7.00، بينما مبلغ الطلب في حقل `totalAmount` هو 1002.12 دولاراً أسترالياً. والثاني أن الوسم `8A` في الرد قيمته `3936`، وهي بالنص «96»، بينما حقل `responseCode` في الرد نفسه قيمته «00». فالعينة إذن ليست عملية واحدة متسقة، بل أجزاء من أمثلة مختلفة جمعت لتوضيح الشكل، وهذا مقبول في دليل للمطورين. لكن الدرس منها مهم لفريق المقاهي: لا تبن اختبارات قبول على عينات التوثيق وكأنها عمليات حقيقية، ولا تستنتج من وسم واحد قاعدة. فلو كتب الفريق اختباراً يقول «المبلغ في 9F02 يجب أن يساوي مبلغ الطلب» ثم جربه على هذه العينة لفشل، ولظن أن الكود خاطئ. والصحيح أن تأتي بيانات الاختبار من بيئة اختبار المستحوذ نفسه، ببطاقات اختبار معروفة، فتكون كل وسومها من عملية واحدة. ومع ذلك فالقاعدة نفسها صحيحة في الإنتاج: إذا اختلف المبلغ في `9F02` عن مبلغ الرسالة في عملية حقيقية، فالرمز الذي حسبته البطاقة لا يغطي المبلغ الذي يطلبه التاجر، والبنك المصدر يعرف ذلك. ## الرمز ARQC: كيف توقع البطاقة العملية؟ الآن نصل إلى قلب الشريحة. فالرمز `9F26` الذي رأيناه في العينة ليس رقماً عشوائياً، بل توقيع من نوع MAC حسبته البطاقة على بيانات العملية بمفتاح لا يعرفه إلا هي وبنكها. والسؤال: كيف يعرف البنك مفتاح كل بطاقة من ملايين البطاقات دون أن يحفظ ملايين المفاتيح؟ والإجابة في الاشتقاق Key Derivation على ثلاث طبقات، كما في الصورة التالية: ![سلسلة حساب ARQC: مفتاح المصدر الرئيسي IMK AC في HSM البنك فقط، يشتق منه مفتاح البطاقة ICC MK من الرقم وPSN بقيمة 2A93983529419196E49094141398C32C، ومنه مفتاح الجلسة من العداد ATC بقيمة 02B14655332488DE5B6AF4C9135BD227، ثم MAC بالخوارزمية 3 من ISO 9797-1 على بيانات العملية 40 بايتاً وهي المبلغ 9F02 والمبلغ الآخر 9F03 والبلد 9F1A وTVR 95 والعملة 5F2A والتاريخ 9A والنوع 9C والرقم العشوائي 9F37 وAIP 82 والعداد 9F36 وبيانات المصدر 9F10، والناتج ARQC 769577B5ABE9FE62، والبنك يعيد الحساب ويقارن، والمبلغ 99.98 بدل 99.99 يعطي 4B5963280C3FFC4D، والعداد 1000 بدل 0FFF يعطي 782288F26F7A3D89](https://arabroot.io/content/images/2026/10/emv-contactless-03-arqc.webp) مفتاح للبنك، ومفتاح لكل بطاقة، ومفتاح لكل عملية 1. **مفتاح المصدر الرئيسي Issuer Master Key**: واحد للبنك لكل غرض، يعيش داخل وحدة أمن العتاد HSM ولا يخرج منها، وهذا موضوع مقال HSM في هذه المرحلة. 2. **مفتاح البطاقة ICC Master Key**: يشتقه البنك عند إصدار البطاقة من مفتاحه الرئيسي ورقم البطاقة PAN ورقم تسلسلها PSN، ويكتبه في الشريحة. والطريقة المعروفة باسم الخيار A في الملحق A1.4.1 من الكتاب 2 لمواصفات EMV: تأخذ آخر 16 رقماً من رقم البطاقة مع رقم التسلسل، وتشفرها بالمفتاح الرئيسي فيكون النصف الأول، وتشفر عكس خاناتها فيكون النصف الثاني. فالبنك لا يحفظ مفتاح كل بطاقة، بل يعيد اشتقاقه عند الحاجة من رقمها. 3. **مفتاح الجلسة Session Key**: تشتقه البطاقة في كل عملية من مفتاحها والعداد ATC، فيكون لكل عملية مفتاح مختلف، ولو انكشف مفتاح جلسة واحدة لما كشف شيئاً عن غيرها. ثم تحسب البطاقة الرمز بمفتاح الجلسة على بيانات العملية مرتبة بترتيب تحدده الشبكة، وتسمى هذه الطريقة نسخة الرمز Cryptogram Version Number. ورقم النسخة يقول أي اشتقاق وأي بيانات وأي إكمال، وهو مكتوب داخل بيانات المصدر `9F10` بصيغة تحددها كل شبكة. ## تجربة عملية: نعيد حساب رمز منشور حتى آخر خانة أصعب ما في هذا الموضوع أن تصدق أن هذه الخطوات هي فعلاً ما يحدث، فأغلب الشروح تتوقف عند «البطاقة تحسب رمزاً». ولهذا بحثنا عن رمز منشور بكل مدخلاته، فوجدناه في التوثيق المرفق بمكتبة pyemv نفسها: مثال لنسخة Visa رقم 18 بمفاتيح اختبار، كل بايت فيها `AA`، ورقم بطاقة اختبار `1234567890123456`، وبيانات عملية كاملة، والرمز الناتج `769577B5ABE9FE62`، ورمز رد المصدر `76503F48`. فكتبنا الحساب كله بأنفسنا بتشفير 3DES من مكتبة cryptography، دون أن نستدعي أي دالة EMV من pyemv، ثم قارنا بالمكتبة وبالقيمة المنشورة. وهذه الدوال الثلاث التي تطابق الخطوات الثلاث في الصورة: ```python def icc_mk(iss_mk, pan, psn): """EMV Book 2 Annex A1.4.1, option A: the card's own key from the issuer key, the PAN and the PSN.""" y = bytes.fromhex((pan + psn)[-16:]) return tdes(iss_mk, y) + tdes(iss_mk, xor(y, b"\xff" * 8)) def session_key(mk, atc): """EMV common session key derivation: a new key for every ATC value.""" r = atc + b"\x00" * 6 return tdes(mk, r[:2] + b"\xf0" + r[3:]) + tdes(mk, r[:2] + b"\x0f" + r[3:]) def mac_alg3(key, data): """ISO 9797-1 MAC algorithm 3 with padding method 2 (80 then zeros), 8-byte result.""" data += b"\x80" data += b"\x00" * (-len(data) % 8) h = bytes(8) for i in range(0, len(data), 8): h = des(key[:8], xor(h, data[i:i + 8])) return des(key[:8], des(key[8:], h, decrypt=True)) ``` ولماذا الإكمال بالبايت `80` ثم أصفار، لا بأصفار فقط كما فعلنا في مقال الصراف؟ لأن الإكمال بالأصفار وحدها يجعل الرسالتين «AB» و«AB00» متطابقتين بعد الإكمال، فيكون لهما الرمز نفسه، أما البايت `80` فيعلم نهاية البيانات الحقيقية. ونسخة Visa 18 تستخدم هذا الإكمال، وهو الطريقة 2 في ISO 9797-1\. والمخرج عند التشغيل: ```bash docker run --rm --name sfa-emv sfa-emv-lab:1 python -W ignore crypto_lab.py ``` ```text data for the MAC : 0000000099990000000000000840800004800008409912310152BF458518000FFF06011203A0B800 (40 bytes) ICC master key : 2A93983529419196E49094141398C32C session key : 02B14655332488DE5B6AF4C9135BD227 ARQC by hand : 769577B5ABE9FE62 ARQC with pyemv : 769577B5ABE9FE62 published value : 769577B5ABE9FE62 ARPC (method 2) : 76503F48 (published 76503F48) ``` في المخرج أعلاه لاحظ التالي: - **البيانات الموقعة 40 بايتاً**: هي الوسوم الأحد عشر متلاصقة بلا وسم ولا طول، القيم فقط، بالترتيب الذي تحدده النسخة 18\. فالبنك يجب أن يعرف الترتيب مسبقاً، تماماً كما يجب أن يعرف أطوال الحقول في ISO 8583. - **الحساب اليدوي والمكتبة والقيمة المنشورة متطابقة** حتى الخانة الأخيرة: `769577B5ABE9FE62`. أي أن الخطوات الثلاث في الصورة هي الحساب كله، لا تبسيطاً له. - **رمز رد المصدر ARPC** بالطريقة 2 طابق القيمة المنشورة `76503F48`. وهذا ما يرسله البنك في الوسم 91، فتتحقق البطاقة أن الرد جاء ممن يملك مفتاحها، لا من جهاز يدعي أن البنك وافق. ### المشكلة التي واجهناها: تحذيرات 3DES في التشغيل الأول امتلأت الشاشة بتحذيرات قبل النتيجة، اثنا عشر سطراً مثل هذا: ```text CryptographyDeprecationWarning: Two-key TripleDES (16-byte keys) is deprecated and support will be removed in a future release. Use 24-byte keys instead (e.g., key + key[:8]). ``` والسبب أن مكتبة cryptography في إصدارها 50.0.2، وهو ما ثبت مع pyemv، تعلم 3DES بمفتاح من 16 بايتاً بأنه سيزال، ومفاتيح EMV كلها بهذا الطول. فأصلحنا كودنا بأن نمرر المفتاح بطول 24 بايتاً بتكرار النصف الأول `key + key[:8]`، وهذا يعطي النتيجة نفسها بالضبط لأن 3DES بمفتاحين يعني K1 ثم K2 ثم K1\. فبقيت ستة أسطر من داخل pyemv نفسها، لأنها تستخدم الطريقة القديمة، فشغلناها بالخيار `-W ignore` لإخفاء التحذيرات في العرض. والدرس العملي أكبر من التحذير: الخوارزميات التي تعيش عليها البطاقات اليوم توصف في مكتبات التشفير العامة بأنها قديمة، فإذا كان عندك كود يتعامل مع EMV فثبت إصدار مكتبة التشفير، وراقب ملاحظات إصداراتها، لأن تحديثاً واحداً قد يزيل دالة يعتمد عليها نظام دفع يعمل. ### ماذا لو تغير بايت واحد؟ ثم غيرنا في بيانات العملية شيئاً واحداً كل مرة، وأعدنا الحساب: ```text == what if one field changes? amount 99.99 -> 99.98 ARQC 4B5963280C3FFC4D unpredictable number changed ARQC 25C1CB802A18AA0F ATC 0FFF -> 1000 ARQC 782288F26F7A3D89 ``` هللة واحدة في المبلغ، أو خانة واحدة في الرقم العشوائي، أو زيادة العداد واحداً، تعطي رمزاً مختلفاً تماماً لا يشبه الأول في أي خانة. وهذه خاصية الـ MAC الجيد: لا يمكن أن تعرف من الرمز القديم شيئاً عن الرمز الجديد. ثم كتبنا جهة البنك في الدالة `issuer`، وهي تتحقق من شيئين: أن الرمز يتحقق بإعادة الحساب، وأن العداد أكبر من آخر عداد رآه البنك لهذه البطاقة: ```text == the issuer side: verify the cryptogram and the counter genuine ARQC : approve same message sent again : decline: ATC 0x0fff not above last seen 0x0fff (replay?) amount edited, old ARQC : decline: cryptogram does not verify ``` والآن نعود إلى العميل الذي خصم مرتين. فالسؤال الذي يجب أن يجيب عنه الفريق ليس «هل هناك عمليتان؟»، بل «هل حسبت البطاقة رمزين؟». فإذا كان في العمليتين عدادان مختلفان، مثل 506 و507، فالبطاقة نفسها حسبت رمزين، أي أن الجهاز طلب منها مرتين، والعميل لمس مرتين أو أن تطبيق نقاط البيع أعاد الطلب من البطاقة بعد انتهاء مهلة. أما إذا كان العداد نفسه والرمز نفسه في العمليتين، فالبطاقة لمست مرة واحدة، والتكرار في الرسالة بعد ذلك، عند الجهاز أو المستحوذ، والبنك الذي يتحقق من العداد كما في المختبر سيرفض الثانية. وحين فتح الفريق السجلات وجد عدادين متتاليين، أي أن تطبيقه أعاد بدء العملية مع البطاقة حين لم يصله رد الجهاز في الوقت، والعميل ما زال يقرب جواله، فدفع مرتين فعلاً. فالخطأ في تطبيقه هو، لا في البطاقة ولا في البنك، والإصلاح أن لا يبدأ عملية جديدة مع البطاقة قبل أن يعرف مصير الأولى، وهو الدرس نفسه الذي رأيناه في [مقال Idempotency](https://arabroot.io/articles/idempotency-%D9%83%D9%8A%D9%81-%D8%AA%D8%AC%D8%B9%D9%84-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%85%D9%86%D8%A9-%D8%B9%D9%86%D8%AF-%D8%AA%D9%83%D8%B1%D8%A7%D8%B1%D9%87%D8%A7/) ومقال الصراف عن المهلة. ## دون اتصال أم بالاتصال؟ كيف يقرر الجهاز رأينا أن البطاقة ترد على أمر GENERATE AC بأحد ثلاثة رموز: AAC للرفض، وTC للموافقة دون اتصال، وARQC لطلب الاتصال. لكن الجهاز هو من يطلب أولاً ما يريده، ويطلبه بناء على قرار يسمى تحليل قرار الجهاز Terminal Action Analysis: يقارن نتائج فحوصه في TVR بثلاثة أزواج من الرموز، رموز يضعها البنك في البطاقة نفسها تسمى IAC، ورموز يضعها المستحوذ في الجهاز تسمى TAC، لكل منها ثلاثة أنواع: رفض Denial، واتصال Online، وافتراضي Default. فإذا كانت خانة فاشلة في TVR مذكورة في رموز الرفض، رفض الجهاز دون اتصال، وإذا كانت في رموز الاتصال، ذهب إلى البنك، وإلا وافق دون اتصال. وفي اللاتلامسي تضاف قبل ذلك حدود يضعها القارئ نفسه: حد أعلى للعملية اللاتلامسية، فوقه يطلب الجهاز إدخال البطاقة، وحد للتحقق من حامل البطاقة، فوقه يطلب رقماً سرياً أو بصمة على الجوال، وحد أرضية Floor Limit، فوقه لا يوافق الجهاز دون اتصال. وكتبنا هذا المنطق مبسطاً في السكربت `decide.py` بحدود ورموز من عندنا، وهذا مهم: القيم في المختبر توضيحية، والحدود الحقيقية تضعها الشبكة والمستحوذ لكل بلد ونوع جهاز، فلا تأخذها من هنا. والمخرج: ```text limits (halalas): {'floor': 0, 'cvm_required': 30000, 'contactless_max': 100000} coffee 15.00 no CVM TVR 0000008000 ARQC: go online to the issuer groceries 250.00 no CVM TVR 0000008000 ARQC: go online to the issuer electronics 450.00 CVM required (on-device or online PIN) TVR 0000008000 ARQC: go online to the issuer furniture 1,200.00 above contactless limit: insert or swipe the card TVR - card on exception file, 15.00 no CVM TVR 0800008000 ARQC: go online to the issuer what if the floor limit were 50.00 (an offline-capable terminal)? coffee 15.00 no CVM TVR 0000000000 TC: approve offline groceries 250.00 no CVM TVR 0000008000 ARQC: go online to the issuer what if the issuer's IAC-Denial covers the exception file bit? card on exception file, 15.00 no CVM TVR 0800000000 AAC: decline offline ``` والصورة التالية تجمع منطق القرار والنتائج معاً: ![منطق القرار: حدود القارئ ثم نتائج الفحص TVR 95 ثم تحليل قرار الجهاز بمقارنة TVR مع IAC وTAC، والنتيجة أحد ثلاثة: AAC رفض دون اتصال، أو ARQC اذهب إلى المصدر، أو TC موافقة دون اتصال. ونتائج decide.py بحدود المختبر: قهوة 15.00 مع حد أرضية 0 تذهب ARQC، وبقالة 250.00 دون تحقق ARQC، وأجهزة 450.00 مع تحقق مطلوب ARQC، وأثاث 1,200.00 فوق حد اللاتلامسي أدخل البطاقة، وقهوة مع حد أرضية 50 TVR كله أصفار TC، وبطاقة في قائمة الاستثناء مع IAC-Denial يغطيها TVR 0800000000 AAC](https://arabroot.io/content/images/2026/10/emv-contactless-04-offline-online.webp) حد الأرضية صفر يجعل كل عملية تذهب إلى البنك، وهذا هو الوضع الشائع في الأجهزة المتصلة دائماً في المخرج أعلاه لاحظ التالي: - **حد الأرضية صفر يرسل كل شيء إلى البنك**: لأن أي مبلغ أكبر من صفر يرفع خانة «العملية تتجاوز حد الأرضية» في البايت الرابع من TVR، فتطابق رمز الاتصال. وهذا وضع أغلب أجهزة نقاط البيع المتصلة دائماً بالشبكة، ومنها أجهزة المقاهي في قصتنا: كل نقرة تصل إلى البنك المصدر. - **المبلغ يحدد التحقق لا الاتصال**: 450 ريالاً فوق حد التحقق في المختبر، فيطلب الجهاز رقماً سرياً أو تحققاً على الجوال، لكنه يذهب إلى البنك مثل غيره. - **فوق حد اللاتلامسي** لا يحدث تحليل أصلاً، فالجهاز يطلب إدخال البطاقة قبل أن يبدأ. - **حد أرضية 50 ريالاً** جعل القهوة توافق دون اتصال برمز TC، وهذا ما تفعله أجهزة في أماكن الاتصال فيها غير مضمون، مثل بعض وسائل النقل. والثمن أن البنك لا يرى العملية إلا لاحقاً، فلا يستطيع أن يرفضها لرصيد غير كاف في لحظتها. - **البطاقة في قائمة الاستثناء**، وهي قائمة بطاقات محظورة يحملها الجهاز: ذهبت إلى البنك في البداية، لأن رموز الرفض في المختبر لا تغطي تلك الخانة. فلما جعلنا رمز الرفض من البنك يغطيها رفضها الجهاز دون اتصال برمز AAC. أي أن البنك يستطيع أن يقرر مسبقاً، عبر رموز يكتبها في البطاقة، كيف يتصرف أي جهاز في العالم مع بطاقته حين تفشل فحوص معينة. ## التحقق من حامل البطاقة CVM: الرقم السري والجوال الرمز ARQC يثبت أن البطاقة حقيقية، لكنه لا يثبت أن من يحملها صاحبها. وهذا عمل طرق التحقق من حامل البطاقة Cardholder Verification Method، واختصاراً CVM. وفي الشريحة بالتلامس تحمل البطاقة قائمة بالطرق التي تقبلها وترتيبها، مثل رقم سري يتحقق منه البنك بالاتصال، أو رقم سري تتحقق منه البطاقة نفسها دون اتصال، أو توقيع، أو بلا تحقق. والجهاز يختار أول طريقة يدعمها ويسجل نتيجتها في الوسم `9F34`، وقد رأينا في العينة `020000`، أي رقم سري مشفر يتحقق منه البنك. وفي اللاتلامسي يختلف الأمر بحسب حامل الأداة. فالبطاقة البلاستيكية لا تملك شاشة ولا لوحة، فإذا تجاوز المبلغ حد التحقق طلب الجهاز رقماً سرياً يرسله إلى البنك مشفراً. أما الجوال فيستطيع أن يتحقق من صاحبه بنفسه، ببصمة أو وجه أو رمز القفل، قبل أن يقترب من الجهاز، وهذا ما يسمى التحقق على الجهاز Consumer Device CVM، واختصاراً CDCVM، وفي أنوية اللاتلامسي خانة في ملف التطبيق AIP تقول إن التطبيق يدعمه، وهي الخانة التي طبعها السكربت باسم on-device CVM. ولهذا لا يطلب منك الجهاز رقماً سرياً حين تدفع بالجوال مبلغاً كبيراً غالباً: التحقق حدث قبل اللمس، والنتيجة وصلت للجهاز ضمن البيانات. وقد ذكرنا في مقال عملية الدفع بالبطاقة اسم مدى للدفع اللاتلامسي وخدمة القبول على أجهزة Android، والمبادئ نفسها تنطبق عليها. وفي الجوال طبقة أخرى لم تكن في البطاقة: رقم البطاقة نفسه لا يكون في الجوال غالباً، بل رقم بديل خاص بالجهاز يسمى توكن الشبكة Network Token، والشبكة تعرف ما يقابله. فإذا سرق أحد بيانات الجوال لا يحصل على رقم البطاقة، وإذا فقد العميل جواله يوقف البنك التوكن دون أن يغير بطاقته. وقد شرحنا الترميز وأنواع التوكن في [مقال أمن بيانات البطاقات PCI DSS والترميز](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-pci-dss-%D9%88%D8%A7%D9%84%D8%AA%D8%B1%D9%85%D9%8A%D8%B2-tokenization/). ## ما الذي يفحصه البنك والجهاز في كل عملية؟ جمعنا ما رأيناه في التجارب في صورة واحدة من وجهة المدافع، أي البنك المصدر والمستحوذ ومن يكتب برنامج الجهاز: ![ما يتحقق منه المدافع ونتيجته في المختبر: الرمز ARQC يتحقق بمفتاح المصدر ومع مبلغ معدل وARQC قديم النتيجة decline cryptogram does not verify، والعداد ATC يجب أن يزيد ومع الرسالة نفسها مرة ثانية النتيجة decline ATC not above last seen، والرقم العشوائي 9F37 عشوائي فعلاً ومع سجل صراف من بحث Cambridge النتيجة 17 خانة ثابتة من 32، ومولد آمن للأرقام secrets.token_hex النتيجة 0 خانات ثابتة، ورد البنك يحمل ARPC في الوسم 91 بقيمة 4B4E9D76 ثم 00800000](https://arabroot.io/content/images/2026/10/emv-contactless-06-defense.webp) كل فحص من هذه يغلق طريقاً، وغياب أي منها يفتحه - **البنك يتحقق من الرمز في كل عملية**: إذا لم يعد حسابه، فالرمز مجرد ثمانية بايتات لا معنى لها، والبطاقة المزورة تستطيع أن تضع أي قيمة. وتنبيه FASTCash الذي ذكرناه في مقال الصراف يوصي البنوك صراحة بالتحقق من الرموز التي تولدها البطاقة في طلبات التفويض. - **البنك يتحقق من العداد**: يحفظ آخر عداد لكل بطاقة، ويرفض ما لا يزيد عليه، أو يراقب القفزات الكبيرة غير المعتادة فيه. - **الجهاز يولد الرقم العشوائي من مولد آمن**: وهذا ما تبينه الحالة التالية. - **البطاقة تتحقق من رد البنك** في عمليات التلامس بالرمز ARPC، فلا تقبل «موافقة» من جهاز يدعيها. 💡 في 2012 نشر باحثون من جامعة Cambridge، Mike Bond وزملاؤه، [بحث «Chip and Skim»](https://www.cl.cam.ac.uk/~rja14/Papers/unattack.pdf?ref=arabroot.io). وبدأ البحث من قضية عميل لبنك HSBC رفض البنك تعويضه عن عمليات سحب في يونيو 2011، فطلب سجلات العمليات، فلاحظ الباحثون أن الرقم «غير المتوقع» 9F37 في سجل الصراف يزيد بانتظام: 17 خانة ثابتة، و15 خانة عداد يزيد كل بضعة أجزاء من الثانية. والرقم الذي يمكن توقعه يسمح نظرياً بأن يحصل أحد على رموز صالحة لعمليات مستقبلية، فتبدو للبنك كأنها من البطاقة نفسها. ووجد البحث أن بعض الصرافات وأجهزة نقاط البيع من شركات كبرى تولد هذا الرقم بعداد أو وقت أو خوارزمية بسيطة، وناقش الإجراءات المضادة، ومنها أن يولد الجهاز الرقم من مولد آمن، وأن يراقب البنك أنماط هذا الرقم في سجلاته. والفحص الثاني يستطيع أي فريق أن يجريه على سجلاته، وكتبناه في السكربت `un_check.py`: يأخذ عدة قيم للرقم العشوائي من سجل جهاز، ويحسب كم خانة عليا متطابقة بينها كلها. وأدخلنا فيه القيم الأربع المنشورة في البحث نفسه، ثم أربع قيم من مولد Python الآمن: ```text ATM log from the paper: ['F1246E04', 'F1241354', 'F1244328', 'F1247348'] identical high bits across all values: 17 of 32 low 15 bits: [28164, 4948, 17192, 29512] 4 values from secrets.token_hex: ['48EC66B5', 'F6131B01', '774BF8EA', '5C6B586C'] identical high bits across all values: 0 of 32 low 15 bits: [26293, 6913, 30954, 22636] ``` والنتيجة تطابق ما وصفه البحث: 17 خانة ثابتة في قيم الصراف، وصفر في قيم المولد الآمن. وأربع قيم لا تكفي لحكم إحصائي، لكنها تكفي لتنبيه: إذا كانت قيم 9F37 من جهاز واحد تتشابه في نصفها الأعلى، فهذا الجهاز يحتاج فحصاً. ولاحظ أن هذا الخطأ لا يظهر في أي اختبار وظيفي، فكل العمليات تنجح والرموز صحيحة، ولا يظهر إلا لمن ينظر إلى القيم نفسها عبر الوقت. ## ما الذي يلمسه فريق منتج فعلاً؟ بعد التحقيق كتب فريق المقاهي ما تعلمه في قائمة قصيرة، وهي تصلح لأي فريق يبني على أجهزة قبول لا يصنعها: - **الحقل 55 صندوق مغلق يمر ولا يعدل**: يأخذه التطبيق من SDK الجهاز كما هو ويرسله، لأن أي تغيير في بايت واحد من البيانات التي حسب عليها الرمز يجعل الرمز لا يتحقق عند البنك، وهذه بالضبط رسالة «بيانات الشريحة لا تتحقق» التي وصلت الفريق من المستحوذ. فقد اكتشف أن مكوناً في تطبيقه كان يعيد بناء الوسوم ويرتبها أبجدياً قبل الإرسال، وهذا يغير البايتات دون أن يغير المعنى في نظر المطور. - **الحقل 55 قد يحمل بيانات بطاقة**: بعض الأجهزة تضع فيه وسوماً تحمل رقم البطاقة أو ما يعادل الشريط، فيعامل كبيانات بطاقة في السجلات، ولا يطبع كاملاً، كما شرحنا في مقال أمن بيانات البطاقات. - **العداد ATC والرمز في السجل**: يحفظهما التطبيق مع كل عملية، مع آخر أربعة أرقام من البطاقة، لأنهما ما يجيب عن سؤال «هل لمس العميل مرتين؟» بعد أسبوع. - **لا عملية جديدة مع البطاقة قبل معرفة مصير السابقة**: إذا انتهت المهلة، يسأل المستحوذ عن حالة العملية بمرجعها، ثم يقرر. - **الحدود من المستحوذ**: حد اللاتلامسي وحد التحقق وحد الأرضية إعدادات في الجهاز يديرها المستحوذ بحسب قواعد الشبكة في البلد، والتطبيق يقرؤها ولا يفرضها. - **رسالة الرفض للعميل**: كما في مقال الدفع بالبطاقة، رسالة عامة مفيدة، لأن الرمز AAC أو رفض البنك لا يقول السبب دائماً. وقد يتساءل البعض: إذا كانت كل هذه التفاصيل في الجهاز وعند البنك، فلماذا يحتاج فريق منتج أن يفهمها؟ والإجابة في القصة نفسها: المشكلتان اللتان واجهتا الفريق، الخصم المزدوج والرمز الذي لا يتحقق، كانتا في كوده هو، ولم يكن ليجدهما لو بقي الحقل 55 عنده سطراً لا يقرأ. وفهم الوسوم ليس لكتابة نواة، بل لقراءة سجل والإجابة عن سؤال عميل. ## أخطاء شائعة Common Mistakes | الخطأ | لماذا يضر | البديل | | ----------------------------------- | ---------------------------------------- | ------------------------------------- | | إعادة بناء وسوم الحقل 55 أو ترتيبها | البايتات تتغير فلا يتحقق الرمز عند البنك | تمرير البيانات كما خرجت من SDK الجهاز | | بدء عملية جديدة مع البطاقة بعد مهلة | رمزان وعدادان، أي دفعتان حقيقيتان | السؤال عن حالة العملية الأولى أولاً | | عدم حفظ ATC والرمز في السجل | لا جواب عن «هل لمس مرتين؟» | ATC و9F26 مع كل عملية | | اختبار القبول على عينات التوثيق | العينات ليست عمليات متسقة، كما رأينا | بطاقات اختبار في بيئة المستحوذ | | رقم «عشوائي» من عداد أو وقت | رموز يمكن توقعها، كما في بحث Cambridge | مولد آمن، ومراقبة أنماط 9F37 | | فك TLV دون التحقق من الطول | قراءة صامتة لبيانات ناقصة | رفض أي طول أكبر مما بقي | | طباعة الحقل 55 كاملاً في السجلات | قد يحمل رقم البطاقة | إخفاء الوسوم الحساسة | | تحديث مكتبة التشفير دون اختبار | 3DES موصوف بأنه سيزال | تثبيت الإصدار ومتابعة ملاحظاته | ## قائمة تحقق لمن يبني على أجهزة قبول الشريحة - الحقل 55 يمر من الجهاز إلى المستحوذ دون أي تعديل في البايتات. - كل عملية في السجل تحمل ATC والرمز 9F26 ونتيجة CVM وآخر أربعة أرقام، دون الوسوم الحساسة كاملة. - لا يبدأ التطبيق عملية جديدة مع البطاقة قبل أن يعرف مصير السابقة. - بيانات الاختبار من بيئة المستحوذ ببطاقات اختبار، لا من عينات التوثيق ولا من بطاقات حقيقية. - الحدود والرموز إعدادات من المستحوذ، والتطبيق يقرؤها ولا يفرض غيرها. - من يكتب برنامج جهاز يولد 9F37 من مولد آمن، ومن يدير مضيفاً يراقب أنماطه. - البنك أو المعالج يتحقق من الرمز والعداد في كل عملية، ويرسل ARPC في الرد. - إصدار مكتبة التشفير مثبت، وأي تحديث يمر على اختبارات الرموز المعروفة. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - الشريط الممغنط يقول بيانات ثابتة يمكن نسخها، والشريحة تحسب في كل عملية رمزاً بمفتاح لا يخرج منها، وتقول EMVCo إنها تشغل 96% من عمليات الشراء داخل المتاجر عالمياً. - في اللاتلامسي تنتهي البطاقة عند طلب الرمز، والنواة Kernel في الجهاز تدير الحوار بقواعد كل شبكة، والكتاب C-8 نواة موحدة جديدة. - كل شيء مكتوب بصيغة TLV، وفككنا عينة Cybersource المنشورة، 145 بايتاً في الطلب و40 في الرد، يدوياً وبالمكتبة بالنتيجة نفسها، ووجدنا أن العينة ليست عملية متسقة. - الرمز ARQC توقيع MAC بمفتاح جلسة مشتق من مفتاح البطاقة والعداد، وأعدنا حساب القيمة المنشورة `769577B5ABE9FE62` يدوياً حتى آخر خانة. - تغيير هللة أو خانة يغير الرمز كله، والبنك الذي يتحقق من الرمز والعداد يرفض الرسالة المعدلة والمكررة. - الجهاز يقرر الاتصال أو الرفض أو الموافقة بمقارنة TVR برموز البنك والمستحوذ، وحد الأرضية صفر يرسل كل عملية إلى البنك. - الرقم العشوائي يجب أن يكون عشوائياً فعلاً، وسجل الصراف في بحث Cambridge كان فيه 17 خانة ثابتة من 32. وفي المقال التالي من هذه المرحلة بإذن الله نفتح الصندوق الذي يحفظ مفتاح المصدر الرئيسي ويفك كتل الرقم السري: وحدة أمن العتاد HSM. وبقية مقالات قسم التقنية المالية والمدفوعات: [![](https://arabroot.io/content/images/2026/10/card-payment-flow-cover-cover.webp)دليلكيف يعمل الدفع بالبطاقة؟ التفويض Authorization والتسويةمن ضغطة «ادفع» إلى آخر اعتراض: التفويض و3D Secure والتحصيل والتسوية والاسترداد والاعتراض، مع مختبر لأحداث مزود الدفع ومطابقتها.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D8%AA%D8%B9%D9%85%D9%84-%D8%B9%D9%85%D9%84%D9%8A%D8%A9-%D8%A7%D9%84%D8%AF%D9%81%D8%B9-%D8%A8%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A9-%D8%A7%D9%84%D8%AA%D9%81%D9%88%D9%8A%D8%B6-%D9%88%D8%A7%D9%84%D8%AA%D8%B3%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D8%B1%D8%A7%D8%B6/)[![](https://arabroot.io/content/images/2026/10/iso8583-iso20022-cover-cover.webp)دليلرسائل البنوك: ISO 8583 للبطاقات وISO 20022 للتحويلاتنفكك رسالة تفويض بطاقة بايتاً بايتاً، ونبني أمر تحويل بأسماء عربية ونتحقق منه بالمخطط الرسمي، ونرى ما يتعطل في كل معيار.](https://arabroot.io/articles/%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D9%86%D9%88%D9%83-iso-8583-%D9%84%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%88-iso-20022-%D9%84%D9%84%D8%AA%D8%AD%D9%88%D9%8A%D9%84%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/atm-inside-cover-cover.webp)دليلكيف يعمل الصراف الآلي ATM من الداخل؟نفتح الصراف: الموزع والأدراج ولوحة الرقم السري ومعيار XFS ورسائل المضيف، ونحاكي سحباً يتعطل فيه الموزع وكيف يصحح العكس الخصم.](https://arabroot.io/articles/%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D8%A7%D9%84%D8%B5%D8%B1%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D9%84%D9%8A-atm-%D9%85%D9%86-%D8%A7%D9%84%D8%AF%D8%A7%D8%AE%D9%84/)[![](https://arabroot.io/content/images/2026/10/hsm-pin-cover-cover.webp)دليلوحدات أمن العتاد HSM والرقم السري PIN وإدارة المفاتيحنبني كتلة الرقم السري بمثال Mastercard المنشور داخل SoftHSM، ونرى مكونات المفاتيح وKCV والصيغة 4 وكتل TR-31، ولماذا لا يكفي HSM عام للرقم السري.](https://arabroot.io/articles/%D9%88%D8%AD%D8%AF%D8%A7%D8%AA-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B9%D8%AA%D8%A7%D8%AF-hsm-%D9%88%D8%A7%D9%84%D8%B1%D9%82%D9%85-%D8%A7%D9%84%D8%B3%D8%B1%D9%8A-pin-%D9%88%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%85%D9%81%D8%A7%D8%AA%D9%8A%D8%AD/)[![](https://arabroot.io/content/images/2026/10/payment-switch-cover-cover.webp)دليلالمحول المالي Payment Switch: توجيه رسائل البطاقات مع jPOSنبني محولاً بـ jPOS يوجه طلبات مستحوذ إلى مصدرين، ونعيد قصة رفض ظهر معه حجز، ونرى ماذا يحدث حين يتأخر المصدر أو يتوقف أو يتكرر رقم التتبع.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%AD%D9%88%D9%84-%D8%A7%D9%84%D9%85%D8%A7%D9%84%D9%8A-payment-switch-%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%B1%D8%B3%D8%A7%D8%A6%D9%84-%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-%D9%85%D8%B9-jpos/)[![](https://arabroot.io/content/images/2026/10/pci-tokenization-cover-cover.webp)دليلأمن بيانات البطاقات PCI DSS والترميز Tokenizationنطاق PCI DSS v4.0.1 وما يمنع حفظه من بيانات البطاقة، وكيف يعمل الترميز، مع مختبر لفحص السجلات وخطر التجزئة دون مفتاح.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%A8%D9%8A%D8%A7%D9%86%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B7%D8%A7%D9%82%D8%A7%D8%AA-pci-dss-%D9%88%D8%A7%D9%84%D8%AA%D8%B1%D9%85%D9%8A%D8%B2-tokenization/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال وتشغيل المختبر يوم 27 أكتوبر 2026 في Container من python:3.13.17-slim (Python 3.13.17) مع pyemv 1.5.0 وcryptography 50.0.2، على عينة الحقل 55 المنشورة في دليل Cybersource ومثال مفاتيح الاختبار في توثيق pyemv، ومراجعة صفحات EMVCo وبحث Chip and Skim في التاريخ نفسه.