تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

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

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

محاكاة البطاقات باستخدام عنصر آمن

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

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

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

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

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

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

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

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

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

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

وعلى وجه التحديد، يتوافق الإصدار 4.4 من نظام التشغيل Android والإصدارات الأحدث مع محاكاة البطاقات المستندة إلى مواصفات ISO-DEP لمنتدى NFC (بناءً على ISO/IEC 14443-4) وعملية وحدات بيانات بروتوكول التطبيق (APDU) كما هو محدّد في ISO/IEC 7816-4 المواصفات. عمليات تفويض Android التي يحاكي ISO-DEP فقط في الجزء العلوي من ذاكرة الوصول العشوائي (Nfc-A) (ISO/IEC 14443-3 النوع أ). دعم معيار Nfc-B (وفقًا لمعيار ISO/IEC 14443-4 Type B) والتكنولوجيا الاختيارية. يوضح الشكل 3 طبقات كل هذه والمواصفات.

خدمات محاكاة البطاقة المُضيفة

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

اختيار الخدمة

عندما ينقر المستخدم على جهاز لقراءة NFC، يحتاج نظام Android إلى معرفة خدمة HCE التي يريد قارئ NFC التواصل معها. ISO/IEC 7816-4 طريقة لاختيار التطبيقات، التي تتمحور حول معرّف التطبيق (AID). يصل حجم AID إلى 16 بايت. إذا كنت تقوم بالمحاكاة بطاقات للبنية الأساسية الحالية لقارئ تقنية NFC، أو معرفات AID التي يستخدمها هؤلاء القراء البحث عنها معروفة ومُسجَّلة بشكل عام (على سبيل المثال، AID لشبكات الدفع، مثل Visa وMasterCard).

إذا أردت نشر بنية أساسية جديدة للقارئ لتطبيقك، يجب أن تسجِّل معلوماتك الخاصة بالإيدز. يتم تحديد إجراء التسجيل في حالات مرض الإيدز في بمواصفات ISO/IEC 7816-5. ننصحك بتسجيل رقم AID وفقًا للرقم 7816-5. إذا كنت تنشر تطبيق HCE على نظام Android، لأنّه يتم تجنُّب الاصطدامات مع التطبيقات الأخرى.

مجموعات AID

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

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

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

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

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

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

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

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

ملاحظة: لا يمكن تفعيل أكثر من مجموعة AID واحدة في الفئة CATEGORY_PAYMENT في النظام في أي وقت معين. عادةً ما يكون هذا تطبيقًا بروتوكولات الدفع الرئيسية عبر بطاقة الائتمان والتي يمكنها العمل على أي تاجر.

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

تنفيذ خدمة 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) {
       ...
    }
}

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

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

يواصل Android إعادة توجيه معرّفات APDU الجديدة من القارئ إلى خدمتك حتى ما يلي:

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

وفي كلتا الحالتين، لا يمكن اعتبار صف onDeactivated() تنفيذ مع وسيطة تشير إلى أي من الاثنين حدث.

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

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

بيان الخدمة والتسجيل في AID

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

لإبلاغ النظام الأساسي بأنّها خدمة HCE HostApduService، أضِف فلتر أهداف SERVICE_INTERFACE على بيان الخدمة.
لإعلام المنصة بمجموعات AID التي تطلبها هذه الخدمة، يجب تضمين CANNOT TRANSLATE 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 يحتوي على معرّفات الأجهزة الجوّالة المملوكة:

<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 باستخدام payment باعتبارها تطبيقات دفع. يحتوي الإصدار 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 والإصدارات الأحدث

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

على الأجهزة التي تعمل بنظام التشغيل Android 10 والإصدارات الأحدث، سيتم تنفيذ الوظيفة نفسها لإعداد ينطبق android:requireDeviceUnlock إلى true كما هو الحال مع الأجهزة. يعمل بنظام التشغيل Android 9 أو الإصدارات الأقدم، ولكن فقط عند إيقاف "تقنية الاتصال القصير المدى (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 أحد أدوات AID التي تم حلها لخدمتك.

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

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

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

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

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

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

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

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

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

يوضح القسم التالي كيفية تعريف التطبيقات التي تستخدم العنصر الآمن لمحاكاة البطاقة.

التسجيل الآمن للعنصر 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 المقابل تسجيل اثنين من أنواع الإيدز:

<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 على الخدمات غير المضيفة، وذلك لأنّ وحدة المعالجة المركزية المضيفة لا تشارك في العملية، وبالتالي لا يمكنها منع العنصر الآمن من تنفيذ المعاملات عندما يكون الجهاز مُقفل.

يجب توفير السمة 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 type A)

يتم تبادل عدة إطارات في إطار تفعيل بروتوكول Nfc-A.

في الجزء الأول من التبادل، يقدّم جهاز HCE المعرّف الفريد الخاص به. أجهزة HCE يُفترض أن يحتوي على معرّف فريد عشوائي. وهذا يعني أنه عند كل نقرة، لن يتمكن المستخدم من الوصول إلى يتم تقديمه للقارئ من خلال معرِّف فريد يتم إنشاؤه عشوائيًا. لهذا السبب، يجب ألا تعتمد قارئات NFC على المعرّف الفريد (UID) لأجهزة HCE كشكل من أشكال بالمصادقة أو تحديد الهوية.

يمكن لقارئ NFC بعد ذلك اختيار جهاز HCE من خلال إرسال SEL_REQ الأمر. استجابة SEL_RES لجهاز HCE تحتوي على وحدة بت 6 على الأقل (0x20) تشير إلى أن الجهاز يتوافق مع ISO-DEP. لاحظ أن البت الأخرى في قد يتم ضبط SEL_RES أيضًا، للإشارة مثلاً إلى إمكانية استخدام NFC-DEP البروتوكول (p2p). ونظرًا لأنه قد يتم تعيين وحدات بت أخرى، فإن القراء الذين يرغبون في التفاعل مع يجب أن تبحث أجهزة HCE بشكل صريح عن البت السادس فقط، ولا تقارنها 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 في نموذج "عمليات الدفع بروتوكول الاتصال" المواصفات. ويشمل ذلك على وجه الخصوص:

يجب أن تتراوح FCI في T0 بين ساعتَين و8 ساعات.
يجب ضبط T(A)1 على 0x80، مع الإشارة إلى أنّ معدّل نقل البيانات البالغ 106 كيلوبت/ثانية فقط هو كما أنّ معدّلات نقل البيانات غير المتماثلة بين القارئ والمحاكي
يجب أن تكون قيمة FWI في T(B)1 <= 7h.

تبادل بيانات APDU

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