إنّ العديد من الأجهزة التي تعمل بنظام التشغيل Android ومزوَّدة بوظيفة NFC تتوافق حاليًا مع ميزة محاكاة بطاقة NFC. في معظم الحالات، يتم محاكاة البطاقة من خلال شريحة منفصلة في الجهاز، تُسمى العنصر الآمن. كما تحتوي العديد من بطاقات SIM التي تقدمها شركات الاتصالات اللاسلكية على عنصر آمن.
يوفر الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث طريقة إضافية لمحاكاة البطاقة لا تتضمن عنصرًا آمنًا، تُعرف هذه الطريقة باسم محاكاة البطاقة المستندة إلى المضيف. وهذا يسمح لأي تطبيق Android بمحاكاة بطاقة والتحدث مباشرةً إلى قارئ NFC. يتناول هذا الموضوع آلية عمل محاكاة البطاقة المُضيفة (HCE) على Android وكيفية تطوير تطبيق يحاكي بطاقة NFC باستخدام هذا الأسلوب.
وظيفة محاكاة البطاقة باستخدام عنصر آمن
عند توفير محاكاة بطاقة NFC باستخدام عنصر آمن، يتم توفير البطاقة المراد محاكاتها في العنصر الآمن على الجهاز من خلال أحد تطبيقات Android. وعندما يمس المستخدم الجهاز بالجهاز أمام محطة طرفية لتقنية NFC، توجّه وحدة التحكّم في NFC على الجهاز كل البيانات من القارئ مباشرةً إلى العنصر الآمن. يوضح الشكل 1 هذا المفهوم:
الشكل 1. وظيفة محاكاة بطاقة NFC بعنصر آمن.
يتواصل العنصر الآمن مع محطة الدفع NFC بدون تضمين أي تطبيق Android في المعاملة. وبعد اكتمال المعاملة، يمكن لتطبيق Android الاستعلام عن العنصر الآمن مباشرةً عن حالة المعاملة وإشعار المستخدم.
وظيفة محاكاة البطاقة المستندة إلى المضيف
عند محاكاة بطاقة NFC باستخدام محاكاة البطاقة المعتمدة على المضيف، يتم توجيه البيانات مباشرةً إلى وحدة المعالجة المركزية (CPU) المضيف بدلاً من توجيهها إلى عنصر آمن. يوضح الشكل 2 كيفية عمل محاكاة البطاقة المستندة إلى المضيف:
الشكل 2. وظيفة محاكاة بطاقة NFC بدون عنصر آمن
بطاقات وبروتوكولات NFC المتوافقة
الشكل 3. هي حزمة بروتوكول HCE على Android.
تتوافق معايير NFC مع العديد من البروتوكولات المختلفة، وهناك أنواع مختلفة من البطاقات التي يمكنك محاكاتها.
يدعم Android 4.4 والإصدارات الأحدث عدة بروتوكولات شائعة في السوق حاليًا. يعتمد عدد كبير من بطاقات الدفع بدون تلامس الأجهزة حاليًا على هذه البروتوكولات،
مثل بطاقات الدفع بدون تلامس الأجهزة. وهذه البروتوكولات متاحة أيضًا في العديد من أجهزة قراءة
NFC في السوق اليوم، بما في ذلك أجهزة Android NFC التي تعمل
كأجهزة القراءة (يمكنك الاطّلاع على الفئة IsoDep). يتيح لك ذلك إنشاء حلّ شامل لإدارة الاتصالات التفاعلية (NFC) ونشره حول
HCE باستخدام الأجهزة التي تعمل بنظام التشغيل Android فقط.
على وجه التحديد، يتيح الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث محاكاة البطاقات المستندة إلى مواصفات ISO-DEP المتعلقة بمنتدى NFC-Forum (بناءً على ISO/IEC 14443-4) ومعالجة وحدات بيانات بروتوكول التطبيقات (APDUs) على النحو المحدّد في مواصفات ISO/IEC 7816-4. يفرض Android محاكاة لمعيار ISO-DEP على تقنية Nfc-A (ISO/IEC 14443-3 Type A). دعم تكنولوجيا Nfc-B (ISO/IEC 14443-4 Type B) اختياري. يوضح الشكل 3 طبقات كل هذه المواصفات.
خدمات محاكاة البطاقة المُضيفة (HCE)
تستند بنية HCE في Android إلى مكوّنات Service Android (المعروفة باسم خدمات
HCE). تتمثل إحدى المزايا الرئيسية للخدمة في أنه يمكن تشغيلها في
الخلفية بدون أي واجهة مستخدم. وهذا يتناسب بشكل طبيعي مع العديد من تطبيقات HCE، مثل بطاقات الولاء أو بطاقات النقل العام، والتي من المفترض ألا يحتاج المستخدم إلى تشغيل التطبيق لاستخدامها. بدلاً من ذلك، يؤدي النقر على الجهاز في مواجهة قارئ NFC
إلى بدء الخدمة الصحيحة إذا لم يكن قيد التشغيل حاليًا وتنفيذ المعاملة
في الخلفية. وبالطبع، لك مطلق الحرية في تشغيل واجهة مستخدم إضافية (مثل
إشعارات المستخدمين) من خدمتك عند اللزوم.
اختيار الخدمة
عندما يضغط المستخدم على جهاز بقارئ NFC، يحتاج نظام Android إلى معرفة خدمة HCE التي يريد قارئ NFC الاتصال بها. تحدّد مواصفات ISO/IEC 7816-4 طريقة لاختيار التطبيقات، بحيث تتمحور حول معرّف التطبيق (AID). يتألف معرّف AID من 16 بايت كحد أقصى. إذا كنت تحاكي البطاقات لبنية أساسية حالية لقارئ تكنولوجيا NFC، تكون عادةً معرّفات AID التي يبحث عنها هؤلاء القرّاء معروفة ومسجّلة بشكل علني (على سبيل المثال، معرّفات AID لشبكات الدفع مثل Visa وMasterCard).
إذا أردت نشر بنية أساسية جديدة للقارئ لتطبيقك الخاص، عليك تسجيل معرّفات AID الخاصة بك. يتم تعريف إجراء التسجيل لمعرّفات AID في مواصفات ISO/IEC 7816-5. نوصي بتسجيل معرّف مساعد (AID) وفق المعيار 7816-5 إذا كنت تنشر تطبيق HCE لنظام التشغيل Android، لتفادي الاصطدامات مع التطبيقات الأخرى.
مجموعات AID
في بعض الحالات، قد تحتاج خدمة HCE إلى تسجيل عدّة معرّفات AID وضبطها كمعالج تلقائي لكل معرّفات AID من أجل تنفيذ تطبيق معيّن. بعض من مرض AID في المجموعة التي تنقل المستخدم إلى خدمة أخرى غير متاح.
تُسمى قائمة AID التي يتم الاحتفاظ بها معًا مجموعة AID. بالنسبة إلى جميع الأجهزة التي تحتوي على معرّفات AID في أي مجموعة، يضمن Android أيًا مما يلي:
- يتم توجيه جميع مرض الإيدز في المجموعة إلى خدمة HCE هذه.
- لا يتم توجيه أي من فيروسات مرض AID في المجموعة إلى خدمة HCE هذه (على سبيل المثال، لأن المستخدم يفضل خدمة أخرى طلبت واحدًا أو أكثر من مرض AID في مجموعتك أيضًا).
بعبارة أخرى، لا توجد حالات وسيطة، حيث يمكن توجيه بعض من مرض الإيدز في المجموعة إلى إحدى خدمات HCE، والبعض الآخر إلى خدمة أخرى.
مجموعات وفئات AID
يمكنك ربط كل مجموعة من مجموعات AID بفئة معيّنة. ويسمح هذا لنظام التشغيل Android بتجميع خدمات HCE معًا حسب الفئة، ما يسمح للمستخدم بضبط الإعدادات التلقائية على مستوى الفئة بدلاً من مستوى معرّف AID. تجنب ذكر AID في أي أجزاء تواجه المستخدمين في تطبيقك، لأنها لا تعني أي شيء للمستخدم العادي.
يدعم Android 4.4 والإصدارات الأحدث فئتين:
CATEGORY_PAYMENT(تشمل تطبيقات الدفع المتوافقة مع المعايير المتّبعة في المجال)CATEGORY_OTHER(لجميع تطبيقات HCE الأخرى)
تنفيذ خدمة محاكاة البطاقة المُضيفة (HCE)
لمحاكاة بطاقة NFC باستخدام وظيفة محاكاة البطاقة المعتمدة على المضيف، يجب إنشاء
مكوِّن Service يعالج معاملات NFC.
التحقّق من توفّر التوافق مع HCE
يمكن للتطبيق التحقّق مما إذا كان الجهاز متوافقًا مع تقنية HCE من خلال البحث عن الميزة
FEATURE_NFC_HOST_CARD_EMULATION. استخدِم علامة <uses-feature>
في ملف بيان تطبيقك للإشارة إلى أنّ تطبيقك يستخدم ميزة HCE،
وما إذا كانت مطلوبة لكي يعمل التطبيق أم لا.
تنفيذ الخدمة
يوفّر الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث فئة Service ملائمة يمكنك استخدامها كأساس لتنفيذ إحدى خدمات HCE: وهي فئة
HostApduService.
تتمثّل الخطوة الأولى في إطالة HostApduService، على النحو الموضّح في نموذج الرمز
التالي:
لغة Kotlin
class MyHostApduService : HostApduService() {
override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
...
}
override fun onDeactivated(reason: Int) {
...
}
}
جافا
public class MyHostApduService extends HostApduService {
@Override
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
...
}
@Override
public void onDeactivated(int reason) {
...
}
}
يعلن HostApduService عن طريقتين مجردة يجب إلغاءهما وتنفيذهما. ويُسمّى processCommandApdu() عندما يرسل قارئ NFC وحدة بيانات بروتوكول التطبيق (APDU) إلى خدمتك. يتم تحديد وحدات APDU في مواصفات ISO/IEC 7816-4. وAPDU هي حزم على مستوى التطبيق يتم تبادلها بين قارئ NFC وخدمة HCE. هذا البروتوكول على مستوى التطبيق نصف مزدوج: يرسل إليك قارئ NFC
أمر APDU وينتظر منك إرسال APDU للاستجابة في المقابل.
كما ذكرنا سابقًا، يستخدم نظام Android معرّف AID لتحديد خدمة HCE التي يريد القارئ التحدّث إليها. إنّ مقياس APDU الأوّل الذي يرسله قارئ NFC إلى جهازك هو SELECT AID APDU، ويحتوي هذا التقرير على معرّف الجهاز الذي يريد القارئ التحدُّث إليه. ويستخرج Android أداة AID من APDU، وتحوّلها إلى خدمة HCE، ثم يعيد توجيه APDU إلى الخدمة التي تم حلّها.
يمكنك إرسال APDU للاستجابة من خلال عرض وحدات البايت الخاصة بوحدة APDU الخاصة بالاستجابة من processCommandApdu(). لاحظ أن هذه الطريقة تستدعي سلسلة التعليمات الرئيسية
لتطبيقك، والتي يجب عليك عدم حظرها. إذا لم تتمكن من حساب وعرض APDU للاستجابة على الفور، يمكنك عرض قيمة فارغة. يمكنك بعد ذلك تنفيذ العمل اللازم على سلسلة محادثات أخرى واستخدام الطريقة
sendResponseApdu()
المحددة في الفئة HostApduService لإرسال الرد عند
الانتهاء.
يواصل Android إعادة توجيه وحدات APDU الجديدة من القارئ إلى خدمتك إلى أن يحدث أي مما يلي:
- ويرسل قارئ NFC APDU لجهاز
SELECT AIDآخر، والذي يحوّله نظام التشغيل إلى خدمة مختلفة. - رابط NFC بين قارئ NFC وجهازك غير صالح.
في كلتا الحالتين، يتم استدعاء تنفيذ
onDeactivated()
لصفك باستخدام وسيطة تشير إلى أيهما حدث.
إذا كنت تستخدم بنية أساسية حالية للقراءة، عليك تنفيذ البروتوكول الحالي على مستوى التطبيق الذي يتوقعه القرّاء في خدمة HCE.
إذا كنت تنشر بنية أساسية جديدة للقارئ يمكنك التحكّم فيها أيضًا، يمكنك تحديد البروتوكول الخاص بك وتسلسل APDU. حاوِل الحد من وحدات APDU وحجم البيانات المراد تبادلها، لأنّ ذلك يضمن ألا يضطر المستخدمون إلى وضع أجهزتهم أمام قارئ NFC لفترة قصيرة سوى على الشاشة. يبلغ الحد الأعلى المعقول حوالي 1 كيلوبايت من البيانات، والتي يمكن عادةً تبادلها في غضون 300 ملي ثانية.
بيان بيان الخدمة وتسجيل AID
يجب أن تعلن عن خدمتك في البيان على النحو المعتاد، ولكن عليك أيضًا إضافة بعض الأجزاء الإضافية إلى بيان الخدمة:
لإعلام المنصة بأنّها خدمة HCE تنفّذ واجهة
HostApduService، أضِف فلتر أهداف لإجراءSERVICE_INTERFACEإلى بيان الخدمة.لإعلام النظام بمجموعات AIDs التي تطلبها هذه الخدمة، ضمِّن علامة
SERVICE_META_DATA<meta-data>في بيان الخدمة، مع الإشارة إلى مورد XML مع معلومات إضافية حول خدمة HCE.اضبط السمة
android:exportedعلىtrue، واطلب الحصول على إذنandroid.permission.BIND_NFC_SERVICEفي بيان الخدمة. يضمن الأول إمكانية ربط الخدمة بالتطبيقات الخارجية. بعد ذلك، يفرض الخيار الأخير فقط التطبيقات الخارجية التي لديها إذنandroid.permission.BIND_NFC_SERVICEللربط بخدمتك. بما أنّandroid.permission.BIND_NFC_SERVICEهو أحد أذونات النظام، سيفرض ذلك بشكل فعّال أنّه لا يمكن الربط بخدمتك إلا نظام التشغيل Android.
في ما يلي مثال على بيان البيان HostApduService:
<service android:name=".MyHostApduService" android:exported="true"
android:permission="android.permission.BIND_NFC_SERVICE">
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
</intent-filter>
<meta-data android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/apduservice"/>
</service>
تشير علامة البيانات الوصفية هذه إلى ملف apduservice.xml. فيما يلي مثال على هذا الملف مع بيان واحد لمجموعة AID يحتوي على اثنين من معرّفات AID الخاصة:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc"
android:requireDeviceUnlock="false">
<aid-group android:description="@string/aiddescription"
android:category="other">
<aid-filter android:name="F0010203040506"/>
<aid-filter android:name="F0394148148100"/>
</aid-group>
</host-apdu-service>
يجب أن تحتوي العلامة <host-apdu-service> على السمة <android:description> التي تحتوي على وصف سهل الاستخدام للخدمة يمكنك عرضه في واجهة مستخدم التطبيق. يمكنك استخدام السمة requireDeviceUnlock لتحديد إلغاء قفل الجهاز قبل استدعاء هذه الخدمة للتعامل مع وحدات APDU.
يجب أن يحتوي <host-apdu-service> على علامة <aid-group> واحدة أو أكثر. يجب أن تؤدي كل
علامة <aid-group> الإجراءات التالية:
- تحتوي على السمة
android:descriptionالتي تتضمّن وصفًا سهل الاستخدام لمجموعة AID، ما يجعلها مناسبة للعرض في واجهة المستخدم. - ضبط السمة
android:categoryللإشارة إلى الفئة التي تنتمي إليها مجموعة AID، مثل ثوابت السلسلة المحدّدة فيCATEGORY_PAYMENTأوCATEGORY_OTHER - ضمِّن علامة
<aid-filter>واحدة أو أكثر، تحتوي كل منها على معرّف AID واحد. حدِّد AID بتنسيق سداسي عشري، وتأكّد من أنه يحتوي على عدد زوجي من الأحرف.
يجب أن يحصل تطبيقك أيضًا على إذن NFC للتسجيل كخدمة HCE.
حل نزاعات AID
يمكن تثبيت عدة مكوّنات من HostApduService على جهاز واحد، ويمكن
تسجيل معرّف AID نفسه من خلال أكثر من خدمة واحدة. يحل Android تعارضات AID بشكل مختلف اعتمادًا على الفئة التي ينتمي إليها هذا النوع من المساعدة. قد يكون لكل فئة سياسة مختلفة لحل النزاع.
بالنسبة إلى بعض الفئات، مثل الدفع، قد يتمكن المستخدم من اختيار خدمة تلقائية في واجهة مستخدم إعدادات Android. بالنسبة للفئات الأخرى، قد تتمثل السياسة في سؤال المستخدم
دائمًا عن الخدمة التي يجب استدعاؤها في حالة التعارض. للحصول على معلومات
حول كيفية طلب البحث عن سياسة حل التعارضات لفئة معيّنة، يُرجى الاطّلاع على
getSelectionModeForCategory().
التحقّق مما إذا كانت الخدمة هي الخدمة التلقائية
يمكن للتطبيقات التحقّق مما إذا كانت خدمة HCE هي الخدمة التلقائية لفئة معيّنة باستخدام واجهة برمجة التطبيقات isDefaultServiceForCategory().
إذا لم تكن خدمتك هي الخدمة التلقائية، يمكنك طلب ضبطها كخدمة تلقائية
باستخدام
ACTION_CHANGE_DEFAULT.
طلبات الدفع
يعتبر Android خدمات HCE التي أعلنت عن مجموعة AID مع فئة الدفع على أنها تطبيقات للدفع. يحتوي الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث على إدخال قائمة إعدادات ذات مستوى أعلى يسمى النقر والدفع، والذي يسرد جميع تطبيقات الدفع هذه. في قائمة الإعدادات هذه، يمكن للمستخدم اختيار تطبيق الدفع التلقائي للاستدعاء عند النقر على محطة الدفع.
مواد العرض المطلوبة لطلبات الدفع
لتوفير تجربة مستخدم أكثر جاذبية من الناحية المرئية، يجب أن توفّر تطبيقات الدفع في HCE بانر للخدمة.
الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث
لضبط قائمة خيارات الدفع التلقائية في واجهة مستخدم الإعدادات بشكل أفضل، اضبط متطلبات البانر على رمز مربّع. من الناحية المثالية، يجب أن يكون مطابقًا لتصميم أيقونة مشغّل التطبيقات. يخلق هذا التعديل المزيد من الاتساق ومظهرًا أنظف.
الإصدار 12 من نظام التشغيل Android والإصدارات الأقدم
يجب ضبط حجم إعلان بانر الخدمة على 260×96 بكسل مستقل الكثافة، ثم ضبط حجم بانر الخدمة في ملف XML الخاص بالبيانات الوصفية من خلال إضافة السمة android:apduServiceBanner إلى
العلامة <host-apdu-service> التي تشير إلى المورد القابل للرسم. فيما يلي مثال:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc"
android:requireDeviceUnlock="false"
android:apduServiceBanner="@drawable/my_banner">
<aid-group android:description="@string/aiddescription"
android:category="payment">
<aid-filter android:name="F0010203040506"/>
<aid-filter android:name="F0394148148100"/>
</aid-group>
</host-apdu-service>
سلوك الشاشة التي يتم إغلاقها وشاشة القفل
يختلف سلوك خدمات HCE حسب إصدار Android الذي يعمل على الجهاز.
الإصدار 12 من نظام التشغيل Android والإصدارات الأحدث
في التطبيقات التي تستهدف Android 12 (المستوى 31 لواجهة برمجة التطبيقات) والإصدارات الأحدث، يمكنك تفعيل الدفعات عبر NFC
بدون تفعيل شاشة الجهاز من خلال ضبط
requireDeviceScreenOn على
false.
الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث
تتوافق الأجهزة التي تعمل بنظام التشغيل Android 10 (المستوى 29 لواجهة برمجة التطبيقات) أو الإصدارات الأحدث مع
تقنية
الاتصال القصير المدى (NFC). أثناء تفعيل تقنية NFC
الآمن، تصبح جميع أدوات محاكاة البطاقات (التطبيقات المضيفة والتطبيقات غير المضيفة)
غير متاحة عندما تكون شاشة الجهاز مطفأة. وأثناء إيقاف ميزة "تقنية الاتصال القصير المدى (NFC) الآمنة"،
تتوفّر التطبيقات خارج المضيف
عندما تكون شاشة الجهاز مطفأة. يمكنك التحقّق من
إتاحة استخدام NFC الآمن باستخدام
isSecureNfcSupported().
على الأجهزة التي تعمل بالإصدار 10 من نظام التشغيل Android والإصدارات الأحدث، تنطبق الوظائف نفسها لضبط
android:requireDeviceUnlock على "true" كما هو الحال في
الأجهزة
التي تعمل بالإصدار 9 من Android أو الإصدارات الأقدم، ولكن فقط في حال إيقاف تقنية NFC الآمنة. بمعنى أنّه في حال تفعيل
تقنية NFC الآمنة، لن تتمكّن خدمات HCE من العمل من شاشة القفل
بغض النظر عن ضبط android:requireDeviceUnlock.
الإصدار 9 من Android والإصدارات الأقدم
على الأجهزة التي تعمل بنظام التشغيل Android 9 (مستوى واجهة برمجة التطبيقات 28) والإصدارات الأقدم، يتم إيقاف وحدة التحكم NFC ومعالج التطبيقات تمامًا عند إطفاء شاشة الجهاز. ولذلك لا تعمل خدمات HCE عند إطفاء الشاشة.
وعلى الإصدار 9 من نظام Android والإصدارات الأقدم أيضًا، يمكن أن تعمل خدمات HCE من شاشة القفل.
مع ذلك، يتم التحكّم في ذلك من خلال السمة android:requireDeviceUnlock في العلامة <host-apdu-service> الخاصة بخدمة HCE. افتراضيًا، لا يكون فتح قفل الجهاز
مطلوبًا، ويتم استدعاء الخدمة حتى إذا كان الجهاز مقفلاً.
إذا ضبطت السمة android:requireDeviceUnlock على true في خدمة HCE، سيطلب Android من المستخدم فتح قفل الجهاز في الحالات التالية:
- ينقر المستخدم على قارئ NFC.
- يختار قارئ تقنية NFC معرّفًا يتمّ تطبيقه على خدمتك.
بعد فتح القفل، يعرض Android مربّع حوار يطالب المستخدم بالنقر مرة أخرى لإكمال المعاملة. هذا الإجراء ضروري لأنّ المستخدم ربما أبعد الجهاز عن قارئ NFC لفتح قفله.
التعاون مع بطاقات العناصر الآمنة
يهتم هذا القسم المطورين الذين نشروا تطبيقًا يعتمد على عنصر آمن لمحاكاة البطاقة. إنّ آلية تنفيذ محاكاة البطاقة المُضيفة (HCE) في Android مصمَّمة للعمل جنبًا إلى جنب مع الطرق الأخرى لتنفيذ محاكاة البطاقات، بما في ذلك استخدام عناصر آمنة.
ويستند هذا التواجد المشترك إلى مبدأ توجيه AID. ويحتفظ وحدة التحكم في NFC بجدول توجيه يتكون من قائمة (محدودة) من قواعد التوجيه. تحتوي كل قاعدة توجيه على معرّف AID ووجهة. قد تكون الوجهة إما وحدة المعالجة المركزية (CPU) المضيف أو حيث تعمل تطبيقات Android أو عنصر آمن متصل.
عندما يرسل قارئ تقنية NFC وحدة تحكُّم في الوصول إلى البيانات (APDU) باستخدام SELECT AID، تحلّل وحدة التحكّم في NFC
وحدة التحكّم في NFC وتتحقّق مما إذا كانت معرّفات AID تتطابق مع أي معرّف AID في جدول التوجيه. في حال تطابُق الرمز، يتم إرسال APDU وكل وحدات APDU اللاحقة إلى الوجهة المرتبطة بـ AID، وذلك إلى أن يتم استلام SELECT AID APDU آخر أو تعطل رابط NFC.
يوضح الشكل 4 هذه البنية:
الشكل 4. يعمل نظام التشغيل Android مع كل من محاكاة العناصر الآمنة وبطاقة المضيف.
تحتوي وحدة التحكم في NFC عادةً أيضًا على مسار افتراضي لوحدات التحكم في الوصول (APDU). عندما لا يتم العثور على AID في جدول التوجيه، يتم استخدام المسار الافتراضي. على الرغم من أنّ هذا الإعداد قد يختلف من جهاز لآخر، يجب استخدام أجهزة Android لضمان توجيه معرّفات AID التي يسجّلها تطبيقك إلى المضيف على نحو صحيح.
أمّا تطبيقات Android التي تستخدم خدمات HCE أو التي تستخدم عنصرًا آمنًا، فلا داعي للقلق بشأن إعداد جدول التوجيه الذي يتعامل معه Android تلقائيًا. يحتاج Android فقط إلى معرفة حالات الإيدز التي يمكن معالجتها بواسطة خدمات HCE وتلك التي يمكن معالجتها باستخدام العنصر الآمن. يتم ضبط جدول التوجيه تلقائيًا استنادًا إلى الخدمات التي يتم تثبيتها والخدمات التي ضبطها المستخدم على أنها مفضَّلة.
يوضّح القسم التالي كيفية تعريف معرّفات AID للتطبيقات التي تستخدم عنصرًا آمنًا لمحاكاة البطاقة.
تسجيل معرّف AID للعنصر الآمن
يمكن للتطبيقات التي تستخدم عنصرًا آمنًا لمحاكاة البطاقة أن تعرض في ملف البيان خدمة خارج المضيف. ويتطابق إعلان هذه الخدمة تقريبًا مع إعلان خدمة HCE. في ما يلي الاستثناءات:
- يجب ضبط الإجراء المستخدَم في فلتر الأهداف على
SERVICE_INTERFACE. - يجب ضبط سمة اسم البيانات الوصفية على
SERVICE_META_DATA. يجب أن يستخدم ملف XML للبيانات الوصفية العلامة الجذر
<offhost-apdu-service>.<service android:name=".MyOffHostApduService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/> </intent-filter> <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service" android:resource="@xml/apduservice"/> </service>
في ما يلي مثال على ملف apduservice.xml المقابل الذي يسجل
معرّفَي AID:
<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc">
<aid-group android:description="@string/subscription" android:category="other">
<aid-filter android:name="F0010203040506"/>
<aid-filter android:name="F0394148148100"/>
</aid-group>
</offhost-apdu-service>
لا تنطبق السمة android:requireDeviceUnlock على الخدمات غير المضيفة،
لأن وحدة المعالجة المركزية (CPU) المضيفة غير مشاركة في المعاملة وبالتالي لا يمكنها
منع العنصر الآمن من تنفيذ المعاملات عند قفل الجهاز.
تكون السمة android:apduServiceBanner مطلوبة للخدمات غير المضيفة
التي تتمثل في تطبيقات الدفع ويمكن اختيارها كتطبيق
دفع تلقائي.
استدعاء خدمة خارج المضيف
لا يبدأ Android خدمة تم الإعلان عنها على أنها "غير مضيفة" أو يرتبط بها مطلقًا، لأن المعاملات الفعلية يتم تنفيذها بواسطة العنصر الآمن وليس عن طريق خدمة Android. ويتيح بيان الخدمة فقط للتطبيقات تسجيل معرّفات AID الموجودة على العنصر الآمن.
وظيفة محاكاة البطاقة المُضيفة (HCE) والأمان
توفّر بنية HCE جزءًا أساسيًا من الأمان: بما أنّ
الخدمة محمية بإذن نظام
BIND_NFC_SERVICE، لا يمكن إلا لنظام التشغيل فقط الربط بالخدمة والتواصل معها.
هذا يعني أنّ أي APDU تتلقاه هو في الواقع وحدة وصول إلى البيانات يتم استلامها بواسطة نظام التشغيل من وحدة تحكم NFC، وأن أي APDU ترسله أنت لا تنتقل إلا إلى نظام التشغيل، الذي بدوره يعيد توجيه APDU مباشرة إلى وحدة تحكم NFC.
المشكلة الأخيرة هي كيفية حصولك على البيانات التي يرسلها تطبيقك إلى قارئ تقنية NFC. يتم فصل هذا عن قصد في تصميم وظيفة محاكاة البطاقة المُضيفة (HCE)، وليس من أين تأتي البيانات، بل يكفي فقط التأكّد من نقلها بأمان إلى وحدة تحكُّم NFC وإخراجها إلى قارئ NFC.
لتخزين واسترداد البيانات التي تريد إرسالها من خدمة HCE بشكل آمن، يمكنك مثلاً الاعتماد على "وضع حماية تطبيقات Android" الذي يعزل بيانات تطبيقك عن التطبيقات الأخرى. لمزيد من التفاصيل حول أمان Android، يمكنك الاطّلاع على نصائح الأمان.
مَعلمات البروتوكول وتفاصيله
يهمّ هذا القسم المطوّرين الذين يريدون التعرّف على معلمات البروتوكولات التي تستخدمها أجهزة HCE خلال مرحلتي مكافحة الاصطدام وتفعيل بروتوكولات NFC. ويتيح هذا إنشاء بنية أساسية للقارئ متوافقة مع أجهزة Android HCE.
بروتوكول Nfc-A (ISO/IEC 14443 النوع A) ضد الاصطدام والتفعيل
ويتم تبادل عدة إطارات كجزء من تفعيل بروتوكول Nfc-A.
في الجزء الأول من عملية التبادل، يعرض جهاز HCE المعرّف الفريد له، وينبغي افتراض أنّ أجهزة HCE لها رقم تعريف فردي عشوائي. وهذا يعني أنه عند كل نقرة، يكون المعرّف الفريد الذي يتم تقديمه للقارئ هو UID يتم إنشاؤه عشوائيًا. نتيجةً لذلك، يجب ألّا تعتمد أجهزة قراءة NFC على المعرّف الفريد لأجهزة HCE كشكل من أشكال المصادقة أو التعريف.
بعد ذلك، يمكن لقارئ NFC اختيار جهاز HCE من خلال إرسال أمر SEL_REQ. تتضمّن استجابة SEL_RES لجهاز HCE مجموعة بت 6 (0x20) على الأقل، ما يشير إلى أنّ الجهاز متوافق مع ISO-DEP. وتجدر الإشارة إلى أنّه قد يتم ضبط وحدات بت أخرى في SEL_RES أيضًا، ما يشير إلى التوافق مثلاً مع بروتوكول NFC-DEP
(p2p). وبما أنّه قد يتم ضبط وحدات بت أخرى، على القرّاء الذين يريدون التفاعل مع أجهزة HCE التحقّق صراحةً من استخدام وحدة بت 6 فقط، وعدم مقارنة
SEL_RES الكامل بقيمة 0x20.
تفعيل ISO-DEP
بعد تفعيل بروتوكول Nfc-A، يبدأ قارئ NFC عملية تفعيل بروتوكول ISO-DEP. يرسل أمر RATS (طلب إجابة للتحديد). تنشئ وحدة التحكّم في NFC استجابة RATS، أي ATS، ولا يمكن ضبط ATS بواسطة خدمات HCE. ومع ذلك، يجب أن تستوفي عمليات تنفيذ HCE متطلبات منتدى NFC لاستجابة ATS، لذلك يمكن لقرّاء تقنية NFC الاعتماد على هذه المعلمات في حال ضبطها وفقًا لمتطلبات منتدى NFC لأي جهاز HCE.
يوفّر القسم أدناه مزيدًا من التفاصيل حول وحدات البايت الفردية لاستجابة ATS التي توفّرها وحدة التحكّم في NFC على جهاز HCE:
- TL: طول استجابة ATS. يجب ألا تشير إلى طول أكبر من 20 بايت.
- T0: يجب ضبط البت 5 و6 و7 على جميع أجهزة HCE، مع الإشارة إلى تضمين TA(1) وTB(1) وTC(1) في استجابة ATS. تشير البتات من 1 إلى 4 إلى FSCI، مع الترميز الأقصى لحجم الإطار. على أجهزة HCE، يجب أن تتراوح قيمة FSCI بين 0 و8 ساعات.
- T(A)1: يحدد معدلات نقل البيانات بين القارئ والمحاكي، وما إذا كان من الممكن أن تكون غير متماثلة. ما مِن متطلبات أو ضمانات لمعدل نقل البيانات لأجهزة HCE.
- T(B)1: تشير وحدات البت من 1 إلى 4 إلى العدد الصحيح لوقت واقي إطار التشغيل (SFGI). وعلى أجهزة HCE، يجب أن تكون دقة SFGI <= 8h. تشير البتات من 5 إلى 8 إلى العدد الصحيح لوقت انتظار الإطار (FWI) وترمز إلى وقت انتظار الإطار (FWT). على أجهزة HCE، يجب أن تكون قيمة FWI أقل من <= 8h.
- T(C)1: يشير البت 5 إلى دعم "ميزات البروتوكول المتقدمة". قد تدعم أجهزة HCE "ميزات البروتوكول المتقدمة" أو لا تتوافق معها. يشير البت 2 إلى التوافق مع DID. قد تكون أجهزة HCE متوافقة مع تقنية DID أو لا تتوافق معها. يشير البت 1 إلى دعم NAD. يجب ألا تتوافق أجهزة HCE مع NAD وأن يتم ضبط البت 1 على صفر.
- وحدات البايت السابقة: قد تعرض أجهزة HCE ما يصل إلى 15 بايت من البيانات السابقة. ويجب ألا يضع القرّاء الذين يستخدمون تقنية NFC على استعداد للتفاعل مع خدمات HCE أي افتراضات حول محتوى وحدات البايت السابقة أو وجودها.
تجدر الإشارة إلى أنّ العديد من أجهزة HCE متوافقة مع متطلبات البروتوكول التي حدّدتها شبكات الدفع الموحّدة في EMVCo في مواصفات "بروتوكول الاتصال بدون تلامس الأجهزة". ويتضمن ذلك على وجه الخصوص:
- يجب أن تتراوح قيمة FSCI في T0 بين ساعتَين و8 ساعات.
- يجب ضبط T(A)1 على 0x80، للإشارة إلى معدل نقل بيانات يبلغ 106 كيلوبت/ثانية فقط، ولا يمكن استخدام معدلات نقل البيانات غير المتماثلة بين القارئ والمحاكي.
- يجب أن تكون FWI في T(B)1 <= 7h.
تبادل بيانات APDU
وكما أشرنا سابقًا، لا تدعم عمليات تنفيذ HCE إلا قناة منطقية واحدة. فمحاولة تحديد التطبيقات على قنوات منطقية مختلفة لا تعمل على أجهزة HCE.