نظرة عامة على محاكاة البطاقة المستنِدة إلى المضيف

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

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

محاكاة البطاقة مع عنصر آمن

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

رسم توضيحي لقارئ NFC يمر عبر وحدة تحكّم NFC لاسترداد المعلومات من عنصر آمن
الشكل 1. محاكاة بطاقة NFC مع عنصر آمن

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

محاكاة البطاقة المستنِدة إلى المضيف

عند محاكاة بطاقة NFC باستخدام محاكاة البطاقة المستندة إلى المضيف، يتم توجيه البيانات مباشرةً إلى وحدة المعالجة المركزية المضيفة بدلاً من توجيهها إلى عنصر آمن. يوضح الشكل 2 كيف تعمل محاكاة البطاقة المستندة إلى المضيف:

رسم بياني لقارئ NFC يمر عبر وحدة تحكُّم NFC لاسترداد المعلومات من وحدة المعالجة المركزية
الشكل 2. محاكاة بطاقة NFC بدون عنصر آمن

بطاقات وبروتوكولات NFC المتوافقة

رسم بياني يعرض حزمة بروتوكول HCE
الشكل 3. حزمة بروتوكول HCE على Android

تتوافق معايير NFC مع العديد من البروتوكولات المختلفة، كما تتوفر أنواع مختلفة من البطاقات التي يمكنك محاكاتها.

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

على وجه التحديد، يتيح الإصدار Android 4.4 والإصدارات الأحدث محاكاة البطاقات التي تستند إلى مواصفات ISO-DEP الخاصة بمنتدى NFC (استنادًا إلى 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 النوع ب) اختياري. يوضح الشكل 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 الخاصة بك. يتم تحديد إجراء التسجيل لمعرّفات الإيدز في مواصفات ISO/IEC 7816-5. ننصح بتسجيل معرّف AID وفق المعيار 7816-5 إذا كنت تنشر تطبيق HCE لنظام التشغيل Android، لأنّه يتجنّب الاصطدامات مع التطبيقات الأخرى.

مجموعات AID

في بعض الحالات، قد تحتاج خدمة HCE إلى تسجيل عدة معرّفات AID وضبطها كمعالج تلقائي لجميع معرّفات AID من أجل تنفيذ تطبيق معيّن. بعض حالات مرض الإيدز في المجموعة التي تنتقل إلى خدمة أخرى غير متاحة.

يُطلق على قائمة البطاقات التي يتم الاحتفاظ بها معًا اسم مجموعة AID. بالنسبة إلى جميع مرض الإيدز في مجموعة AID، يضمن Android واحدًا مما يلي:

  • يتم توجيه جميع حالات الإصابة بالمرض الإيدز في المجموعة إلى خدمة HCE هذه.
  • لا يتم توجيه أي من مرض الإيدز في المجموعة إلى خدمة HCE هذه (على سبيل المثال، لأن المستخدم فضّل خدمة أخرى طلبت مرض الإيدز أو أكثر في مجموعتك أيضًا).

بمعنى آخر، ما مِن حالات متفرقة حيث يمكن توجيه بعض حالات الإصابة بالإيدز في المجموعة إلى إحدى خدمات HCE، وبعضها إلى خدمة أخرى.

مجموعات وفئات AID

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

يدعم الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث فئتين:

  • CATEGORY_PAYMENT (التي تشمل تطبيقات الدفع المتوافقة مع المعايير المتّبعة في المجال)
  • CATEGORY_OTHER (لجميع تطبيقات HCE الأخرى)

تنفيذ خدمة HCE

لمحاكاة بطاقة NFC باستخدام محاكاة البطاقة المستندة إلى المضيف، يجب إنشاء مكوِّن Service يعالج معاملات NFC.

التأكّد من توفّر تقنية HCE

يمكن لتطبيقك التحقّق مما إذا كان الجهاز متوافقًا مع تقنية HCE من خلال البحث عن ميزة FEATURE_NFC_HOST_CARD_EMULATION. عليك استخدام علامة <uses-feature> في بيان تطبيقك للإشارة إلى أنّ تطبيقك يستخدم ميزة HCE، وما إذا كانت هذه الميزة مطلوبة كي يعمل التطبيق أم لا.

تنفيذ الخدمات

يوفّر نظام التشغيل Android 4.4 والإصدارات الأحدث فئة Service مريحة يمكنك استخدامها كأساس لتنفيذ إحدى خدمات HCE، وهي فئة HostApduService.

تتمثّل الخطوة الأولى في تمديد نطاق HostApduService، كما هو موضّح في نموذج الرمز التالي:

Kotlin

class MyHostApduService : HostApduService() {

    override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
       ...
    }

    override fun onDeactivated(reason: Int) {
       ...
    }
}

Java

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 ويحتوي على معرّف AID الذي يريد القارئ التحدث إليه. ويستخرج 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

يجب أن تعلن عن خدمتك في البيان على النحو المعتاد، ولكن عليك أيضًا إضافة بعض الأجزاء الإضافية إلى بيان الخدمة:

  1. لإبلاغ المنصة بأنّها خدمة HCE تنفّذ واجهة HostApduService، أضِف فلتر أهداف لإجراء SERVICE_INTERFACE إلى بيان الخدمة.

  2. لإعلام المنصة بمجموعات AID التي تطلبها هذه الخدمة، عليك تضمين علامة SERVICE_META_DATA <meta-data> في بيان الخدمة مع الإشارة إلى مورد XML يتضمّن معلومات إضافية حول خدمة HCE.

  3. اضبط السمة 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 بشكل مختلف بناءً على الفئة التي ينتمي إليها معرّف AID. قد يكون لكل فئة سياسة مختلفة لحلّ النزاعات.

بالنسبة إلى بعض الفئات، مثل الدفع، قد يتمكن المستخدم من اختيار خدمة تلقائية في واجهة مستخدم إعدادات Android. بالنسبة للفئات الأخرى، قد تتمثل السياسة في سؤال المستخدم دائمًا عن الخدمة التي يستدعيها في حالة حدوث تعارض. للحصول على معلومات حول كيفية طلب البحث عن سياسة حل النزاعات لفئة معيّنة، يُرجى الاطّلاع على getSelectionModeForCategory().

التحقق مما إذا كانت الخدمة هي الخدمة التلقائية

يمكن للتطبيقات التحقّق مما إذا كانت خدمة HCE هي الخدمة التلقائية لفئة معيّنة من خلال استخدام واجهة برمجة التطبيقات isDefaultServiceForCategory().

إذا لم تكن الخدمة هي الخدمة التلقائية، يمكنك طلب أن تكون هي الخدمة التلقائية باستخدام ACTION_CHANGE_DEFAULT.

طلبات الدفع

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

مواد العرض المطلوبة لتطبيقات الدفع

لتوفير تجربة مستخدم أكثر جاذبية من الناحية المرئية، يجب استخدام تطبيقات الدفع في HCE لتوفير بانر الخدمة.

الإصدار 13 من نظام التشغيل Android والإصدارات الأحدث

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

الإصدار 12 من نظام التشغيل Android والإصدارات الأقدم

اضبط حجم بانر الخدمة على 260x96 بكسل مستقل الكثافة، ثم اضبط حجم بانر الخدمة في ملف 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 والإصدارات الأحدث

في التطبيقات التي تستهدف الإصدار 12 من نظام التشغيل Android (المستوى 31 لواجهة برمجة التطبيقات) والإصدارات الأحدث، يمكنك تفعيل الدفعات عبر NFC بدون تفعيل شاشة الجهاز من خلال ضبط requireDeviceScreenOn على false.

الإصدار 10 من نظام التشغيل Android والإصدارات الأحدث

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

على الأجهزة التي تعمل بنظام التشغيل Android 10 أو الإصدارات الأحدث، تسري الوظيفة نفسها لضبط android:requireDeviceUnlock على true كما هو الحال في الأجهزة التي تعمل بالإصدار 9 من Android أو الإصدارات الأقدم، ولكن فقط عند إيقاف هذه التقنية. ويعني ذلك أنّه في حال تفعيل هذه الميزة، لن تتمكّن خدمات HCE من العمل من شاشة القفل بغض النظر عن إعدادات android:requireDeviceUnlock.

الإصدار 9 من نظام Android والإصدارات الأقدم

على الأجهزة التي تعمل بنظام التشغيل Android 9 (المستوى 28 لواجهة برمجة التطبيقات) والإصدارات الأقدم، يتم إيقاف وحدة التحكّم NFC ومعالج التطبيقات تمامًا عندما تكون شاشة الجهاز مطفأة. وبالتالي، لا تعمل خدمات HCE عند إيقاف الشاشة.

على نظام التشغيل Android 9 والإصدارات الأقدم أيضًا، يمكن أن تعمل خدمات HCE من شاشة القفل. ومع ذلك، يتم التحكّم في ذلك من خلال السمة android:requireDeviceUnlock في العلامة <host-apdu-service> الخاصة بخدمة HCE. افتراضيًا، لا يلزم فتح قفل الجهاز، ويتم استدعاء الخدمة حتى إذا كان الجهاز مقفلاً.

إذا ضبطت السمة android:requireDeviceUnlock على true لخدمة HCE، سيطلب Android من المستخدم فتح قفل الجهاز في الحالات التالية:

  • ينقر المستخدم على قارئ NFC.
  • ويختار قارئ NFC معرّف AID يتم حله لخدمتك.

بعد فتح القفل، يعرض Android مربّع حوار يطلب من المستخدم النقر عليه مرة أخرى لإكمال المعاملة. يُعدّ هذا الإجراء ضروريًا لأنّ المستخدم ربما يكون قد أبعد الجهاز عن قارئ NFC لفتح قفله.

العمل المشترك مع بطاقات العناصر الآمنة

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

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

عندما يرسل قارئ NFC وحدة تحكّم APDU باستخدام SELECT AID، تحلّلها وحدة تحكّم NFC وتتحقّق مما إذا كانت معرّفات AID تتطابق مع أي معرّف AID في جدول التوجيه. وفي حال التطابق، يتم إرسال APDU وجميع وحدات APDU اللاحقة إلى الوجهة المرتبطة بـ AID، وذلك إلى أن يتم استلام SELECT AID APDU آخر أو تعطل رابط NFC.

يوضح الشكل 4 هذه البنية:

رسم بياني لقارئ NFC يتصل بكل من عنصر آمن ووحدة المعالجة المركزية (CPU)
الشكل 4. يعمل بنظام التشغيل Android مع محاكاة العناصر الآمنة وبطاقات المضيف.

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

أمّا تطبيقات Android التي تستخدم خدمة HCE أو التي تستخدم عنصرًا آمنًا، فلا داعي للقلق بشأن إعداد جدول التوجيه، لأنّه يتم التعامل معه من خلال Android تلقائيًا. لا يحتاج Android سوى إلى معرفة AID الذي يمكن معالجته من خلال خدمات 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 تتلقّاه هو وحدة 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 رقم تعريف فردي عشوائيًا. هذا يعني أنّه عند كل نقرة، يكون المعرّف الفريد الذي يتم تقديمه للقارئ هو معرّف فريد يتم إنشاؤه عشوائيًا. نتيجةً لذلك، يجب ألا تعتمد أجهزة قراءة 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 أقل من 8 ساعات. تشير البتات من 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.