برنامج التحقق من صحة الشريحة

برنامج مصادقة الشريحة ( CAP) هو مبادرة من ماستركارد ومواصفات فنية لاستخدام البطاقات الذكية المصرفية بتقنية EMV لمصادقة المستخدمين والمعاملات في الخدمات المصرفية عبر الإنترنت والهاتف . وقد اعتمدته فيزا أيضًا تحت مسمى مصادقة رمز المرور الديناميكي (DPA). ^{[ 1 ]} تحدد مواصفات CAP جهازًا محمولًا ( قارئ CAP ) مزودًا بفتحة للبطاقة الذكية، ولوحة مفاتيح رقمية، وشاشة عرض قادرة على عرض 12 حرفًا على الأقل (مثل شاشة عرض على شكل نجمة ). يمكن لعملاء البنوك الذين حصلوا على قارئ CAP من بنوكهم إدخال بطاقة الشريحة والرقم السري ( EMV ) الخاصة بهم في قارئ CAP للمشاركة في أحد بروتوكولات المصادقة المدعومة . يُعد CAP شكلًا من أشكال المصادقة الثنائية ، حيث يجب وجود كل من البطاقة الذكية والرقم السري الصحيح لإتمام المعاملة بنجاح. تأمل البنوك أن يقلل هذا النظام من مخاطر قيام العملاء غير المتنبهين بإدخال بياناتهم في مواقع ويب احتيالية بعد قراءة رسائل البريد الإلكتروني التي تُعرف باسم رسائل التصيد الاحتيالي . ^{[ 2 ]}

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

تحديد الكود

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

إجابة

يطبق هذا الوضع مصادقة التحدي والاستجابة ، حيث يطلب موقع البنك الإلكتروني من العميل إدخال رقم "التحدي" في قارئ CAP، ثم نسخ رقم "الاستجابة" الذي يعرضه قارئ CAP إلى موقع الويب.

لافتة

هذا الوضع هو امتداد للوضع السابق، حيث لا يقتصر الأمر على إدخال قيمة "تحدي" عشوائية فحسب، بل يجب أيضًا إدخال تفاصيل المعاملة المهمة مثل القيمة المحولة والعملة ورقم حساب المستلم في قارئ CAP.

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

الوضع 1

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

الوضع 2

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

باستخدام توقيع بيانات المعاملات (TDS)

يمكن استخدام هذا النمط للمعاملات الأكثر تعقيدًا، مثل تحويل الأموال بين الحسابات. يتم دمج حقول البيانات المتعددة المتعلقة بالمعاملة ثم تشفيرها باستخدام رمز تشفير من النمط الثاني (Mode2) كمفتاح لخوارزمية التشفير. يُستخدم التشفير الناتج بدلاً من رمز التشفير المحسوب في عملية النمط الثاني (Mode2) غير المعتمدة على TDS. ^{[ 3 ]}

يبدو الوضع 1 مشابهًا جدًا لاستخدام محدد للوضع 2 مع TDS، لكن ثمة فرق جوهري. في الوضع 1، تُستخدم بيانات المعاملة (المبلغ ونوع العملة) في حساب التشفير بالإضافة إلى جميع القيم المستخدمة في الوضع 2 بدون TDS، بينما يُدرج الوضع 2 بيانات معاملته في خطوة لاحقة بدلًا من إدراجها في خطوة حساب التشفير. لولا هذا الفرق، لأمكن تعميم جميع العمليات كعملية واحدة مع بيانات معاملات اختيارية متغيرة.

في جميع الأوضاع الثلاثة، يطلب قارئ CAP من بطاقة EMV إرسال حزمة بيانات تؤكد إلغاء عملية دفع وهمية باستخدام EMV، تتضمن البيانات التي أدخلها المستخدم. تحتوي رسالة التأكيد هذه على رمز مصادقة (عادةً CBC-MAC / Triple DES ) يتم إنشاؤه باستخدام مفتاح سري خاص بالبطاقة ومخزن بشكل آمن داخل البطاقة الذكية. لا تشكل رسائل الإلغاء هذه أي خطر أمني على تطبيق الدفع EMV العادي، ولكن يمكن التحقق منها تشفيرياً، ولا يتم إنشاؤها بواسطة بطاقة EMV إلا بعد إدخال رقم التعريف الشخصي (PIN) الصحيح. وقد وفر هذا لمصممي CAP طريقة لإنشاء دليل تشفيري قوي على وجود بطاقة EMV مُفعّلة برقم التعريف الشخصي (PIN) وأنها اطلعت على بيانات مُدخلة، دون الحاجة إلى إضافة أي وظائف برمجية جديدة إلى بطاقات EMV المستخدمة بالفعل.

تحتوي البطاقة الذكية EMV على عداد معاملات (عادةً 16 بت) يتم زيادته مع كل عملية دفع أو معاملة CAP. تتكون الاستجابة التي يعرضها قارئ CAP بشكل أساسي من أجزاء مختلفة من استجابة البطاقة (عداد معاملات التطبيق، رمز المصادقة MAC، إلخ)، والتي يتم اختزالها إلى بتات محددة وفقًا لسجل مؤشر مصادقة المُصدر (IAI) المخزن في البطاقة (يتم تعيين هذا المؤشر لكل مُصدر على حدة، ولكن يمكن للمُصدر تعيينه عشوائيًا لكل بطاقة إذا رغب في ذلك، شريطة الاحتفاظ بقاعدة بيانات لمؤشرات مصادقة كل بطاقة). بعد ذلك، وبعد تجاهل البتات غير المرغوب فيها (لا يهم الموضع المطلق للبتات، فالبت الذي قيمته 0 في مؤشر مصادقة المُصدر يعني حذف البت المقابل له في استجابة البطاقة بدلاً من مجرد تعيينه إلى 0)، يتم تحويل القيمة من النظام الثنائي إلى النظام العشري وعرضها للمستخدم. مثال مختصر موضح أدناه:

1. يقوم جهاز CAP بتحديد تطبيق EMV، ويقرأ معلومات IAI من البطاقة، ويختار المستخدم إجراءً لتنفيذه (في هذا المثال، سيكون IAI هو 111011011000 ₂ ).
2. بعد إدخال رمز PIN بنجاح، يرسل جهاز CAP تحديًا بقيمة 011100111010 ₂ كمعاملة تشفير طلب التفويض (ARQC).
3. تُعطي البطاقة الذكية استجابة 110101110110 ₂ ويقوم جهاز CAP بإلغاء المعاملة المزيفة.
4. يستخدم جهاز CAP قناع IAI: 111011011000 ₂ لإسقاط البتات؛ يتم إسقاط تلك البتات التي تتوافق مع 0 في القناع.
5. وبالتالي فإن الإجابة النهائية هي 1100110 ₂ أو 102 بالنظام العشري.

إن عملية العالم الحقيقي أكثر تعقيدًا إلى حد ما، حيث يمكن للبطاقة إرجاع ARQC في أحد تنسيقين (إما تنسيق قالب رسالة الاستجابة البسيط من النوع 1 (المعرف 80 ₁₆ ) أو تنسيق قالب رسالة الاستجابة الأكثر تعقيدًا 2 (المعرف 77 ₁₆ ) الذي يقسم بيانات ARQC إلى قيم TLV منفصلة يجب إعادة تجميعها بالتسلسل لتتوافق مع تنسيق النوع 1).

في وضع التحقق من الهوية، تعتمد الاستجابة فقط على البتات المطلوبة من نظام التحقق من الهوية (IAI)، حيث يتم ضبط المبلغ ورقم المرجع على الصفر. هذا يعني أيضًا أن اختيار "استجابة" وإدخال الرقم 00000000 سيؤدي في الواقع إلى توليد استجابة تحقق صحيحة. ولكن الأمر الأكثر إثارة للقلق هو أنه إذا أصدر أحد البنوك طلب استجابة، فإن استخدام وضع التوقيع بنفس الرقم ومبلغ 0.00 يورو سيؤدي مرة أخرى إلى توليد نتيجة صحيحة، مما يتيح للمحتال إمكانية توجيه العميل لإجراء استجابة "اختبارية" بمبلغ 0.00 يورو، والتي سيستخدمها المحتال في الواقع للتحقق من أمر الاستجابة ليتمكن من إضافة نفسه كمستفيد في حساب الضحية. وقد أمكن تنفيذ هذه الهجمات ضد البنوك التي تستخدم أجهزة مصادقة قوية لا تلغي العمليات إلا بعد إدخال مبلغ لا يقل عن 0.01 يورو. ^{[ 4 ]} تمّت معالجة احتمالية وقوع هذا النوع من الهجمات في عام 2009 عند طرح أجيال جديدة من الأجهزة، والتي طبّقت وظيفة فصل النطاقات الآمنة المتوافقة مع مذكرة تطبيق ماستركارد الصادرة في أكتوبر 2010. وبالمثل، فإنّ البنك الذي يطبّق أمر التعريف يمكّن المحتال من مطالبة الضحية بإجراء معاملة "اختبارية" باستخدام 00000000 كمرجع، وبالتالي سيتمكّن من تسجيل الدخول بنجاح إلى حساب الضحية. ^{[ 4 ]}

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

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

ومع ذلك، فإن معظم البنوك البريطانية التي تصدر أجهزة قراءة البطاقات تلتزم بمجموعة فرعية من معايير CAP التي حددتها APACS ، مما يعني أنه في معظم الحالات، يمكن استخدام البطاقات الصادرة عن بنك بريطاني في جهاز قراءة بطاقات صادر عن بنك مختلف.

أجرى باحثون من جامعة كامبريدج، وهم سار دريمر وستيفن مردوخ وروس أندرسون ، بحثًا ^{[ 4 ]} حول تطبيق بروتوكول CAP، مُحددين عددًا من الثغرات الأمنية في البروتوكول وفي النسخة البريطانية من كلٍّ من أجهزة القراءة والبطاقات. وقد تم اكتشاف العديد من نقاط الضعف. كما اكتشف باحثون من جامعة رادبود ثغرة أمنية في جهاز ABN AMRO e.dentifier2 الهولندي ، تسمح للمهاجم بالتحكم في جهاز قراءة متصل عبر منفذ USB لتوقيع معاملات خبيثة دون موافقة المستخدم. ^{[ 5 ]}

يوجد ^{[ 9 ]} تطبيق برمجي مكتوب بلغة بايثون يدعم الوضع 1 والوضع 2 والوضع 2 مع TDS، ويُستخدم لأغراض تعليمية فقط. تتوافق دالة التعريف (بدون تحدٍ) مع دالة m1 مع التحدي "00000000".

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

• نظام الأمان ثلاثي الأبعاد