Hostbasierte Kartenemulation – Übersicht

Viele Android-Geräte mit NFC-Funktion unterstützen NFC bereits. Kartenemulation. In den meisten Fällen wird die Karte durch einen separaten Chip im Gerät, das als Secure Element bezeichnet wird. Viele SIM-Karten von Mobilfunkanbietern auch ein Secure-Element enthalten.

Android 4.4 und höher bieten eine zusätzliche Methode der Kartenemulation, beinhaltet kein Secure Element, das als hostbasierte Kartenemulation bezeichnet wird. Dieses ermöglicht jeder Android-App, eine Karte zu emulieren und direkt mit der NFC-Schnittstelle zu kommunizieren. Leser. In diesem Thema wird beschrieben, wie die Android-Geräte und wie Sie eine App entwickeln, die eine NFC-Karte emuliert, .

Kartenemulation mit einem Secure Element

Wenn die NFC-Kartenemulation mit einem Secure Element bereitgestellt wird, wird die zu emuliert wird, wird über ein Android-Gerät im Secure Element auf dem Gerät bereitgestellt. . Wenn der Nutzer das Gerät dann über ein NFC-Terminal hält, Der Controller im Gerät leitet alle Daten vom Lesegerät direkt an das sichere -Elements. Abbildung 1 veranschaulicht dieses Konzept:

Abbildung 1: NFC-Kartenemulation mit einem Secure Element.

Das Secure Element selbst führt die Kommunikation mit dem NFC-Terminal aus. an der Transaktion keine Android-Anwendung beteiligt ist. Nach der Transaktion abgeschlossen ist, kann eine Android-App das Secure Element direkt abfragen und den Nutzer benachrichtigen.

Hostbasierte Kartenemulation

Wenn eine NFC-Karte mit hostbasierter Kartenemulation emuliert wird, werden die Daten weitergeleitet direkt an die Host-CPU, anstatt an ein Secure Element weitergeleitet zu werden. Abbildung 2 zeigt, wie die hostbasierte Kartenemulation funktioniert:

Abbildung 2: NFC-Kartenemulation ohne Secure Element.

Unterstützte NFC-Karten und -Protokolle

Abbildung 3: HCE-Protokollstack von Android

Die NFC-Standards unterstützen viele verschiedene Protokolle. verschiedene Kartentypen, die Sie emulieren können.

Android 4.4 und höher unterstützt mehrere auf dem Markt gängige Protokolle. heute. Viele bestehende kontaktlose Karten basieren bereits auf diesen Protokollen, wie Karten für kontaktloses Bezahlen. Diese Protokolle werden auch von vielen NFC-Lesegeräte, die heute auf dem Markt sind, einschließlich Android-NFC-Geräten, die als Lesern selbst (siehe IsoDep . So können Sie eine End-to-End-NFC-Lösung rund um HCE nur auf Android-Geräten.

Android 4.4 und höher unterstützt insbesondere das Emulieren von Karten, die auf der NFC-Forum ISO-DEP-Spezifikation (basierend auf ISO/IEC 14443-4) und dem Verfahren Application Protocol Data Units (APDUs) gemäß ISO/IEC 7816-4. Spezifikation zu ändern. Android verlangt, dass ISO-DEP nur über Nfc-A emuliert wird. (ISO/IEC 14443-3 Typ A). Unterstützung für Nfc-B (ISO/IEC 14443-4 Typ B) ist optional. In Abbildung 3 ist die Schichtung all dieser Komponenten dargestellt. Spezifikationen.

HCE-Dienste

Die HCE-Architektur in Android basiert auf Android Service-Komponenten (HCE genannt) -Dienste) verwenden. Einer der Hauptvorteile eines Dienstes ist, dass er in der ohne Benutzeroberfläche. Das ist für viele HCE wie Kundenkarten oder Fahrkarten für öffentliche Verkehrsmittel, die der Nutzer eine App starten. Wenn Sie das Gerät stattdessen an das NFC-Lesegerät halten, Den richtigen Dienst, wenn er nicht bereits ausgeführt wird, und die Transaktion ausführt im Hintergrund. Natürlich können Sie auch zusätzliche Benutzeroberflächen Nutzerbenachrichtigungen) gegebenenfalls von Ihrem Dienst erhalten.

Dienstauswahl

Wenn der Nutzer ein Gerät an ein NFC-Lesegerät hält, muss das Android-System mit welchem HCE-Dienst der NFC-Leser kommunizieren möchte. ISO/IEC 7816-4 definiert eine Möglichkeit, Anwendungen auszuwählen, die um ein Anwendungs-ID (AID). Eine AID besteht aus bis zu 16 Byte. Wenn Sie eine Emulation Karten für eine vorhandene NFC-Leserinfrastruktur, die AIDs, die diese Lesegeräte in der Regel bekannt und öffentlich registriert sind (z. B. der AIDs von Zahlungsnetzwerken wie Visa und MasterCard).

Wenn Sie eine neue Leserinfrastruktur für Ihre eigene Anwendung bereitstellen möchten, müssen Ihre eigenen AIDs registrieren. Das Registrierungsverfahren für AIDs ist definiert in ISO/IEC 7816-5. Wir empfehlen die Registrierung einer AID gemäß 7816-5 wenn Sie eine HCE-Anwendung für Android bereitstellen, da dadurch Konflikte vermieden werden. mit anderen Anwendungen kombinieren.

AID-Gruppen

In einigen Fällen muss ein HCE-Dienst möglicherweise mehrere AIDs registrieren und als Standard-Handler für alle AIDs zur Implementierung eines bestimmten . Einige AIDs in der Gruppe, die an einen anderen Dienst gesendet werden, werden nicht unterstützt.

Eine Liste von zusammengehaltenen AIDs wird als AID-Gruppe bezeichnet. Für alle AIDs in einer AID-Gruppe garantiert, dass Android eines der folgenden Kriterien erfüllt:

• Alle AIDs in der Gruppe werden an diesen HCE-Dienst weitergeleitet.
• Es werden keine AIDs in der Gruppe an diesen HCE-Dienst weitergeleitet (z. B. weil die Nutzer hat einen anderen Dienst bevorzugt, der eine oder mehrere AIDs in deiner Gruppe angefordert hat ebenfalls).

Mit anderen Worten: Es gibt keinen Zwischenstatus, bei dem einige AIDs in der Gruppe an einen HCE-Dienst und einige an einen anderen weitergeleitet werden.

AID-Gruppen und -Kategorien

Sie können jede AID-Gruppe einer Kategorie zuordnen. Dadurch kann Android HCE-Dienste werden nach Kategorie gruppiert. Dadurch kann der Nutzer Standardeinstellungen auf Kategorieebene anstatt auf AID-Ebene. Vermeiden Sie die Erwähnung von AIDs. in allen für Nutzer sichtbaren Bereichen Ihrer Anwendung, da diese nichts bedeuten. für den durchschnittlichen Nutzer.

Android 4.4 und höher unterstützt zwei Kategorien:

• CATEGORY_PAYMENT (für branchenübliche Zahlungs-Apps)
• CATEGORY_OTHER (für alle anderen HCE-Anwendungen)

Hinweis: Es kann nur eine AID-Gruppe in der Kategorie CATEGORY_PAYMENT aktiviert werden in zu einem bestimmten Zeitpunkt in das System ein. Normalerweise ist das eine App, versteht die wichtigsten Kreditkartenzahlungsprotokolle und für Händler.

Bei Closed-Loop-Zahlungs-Apps, die nur mit einem (z. B. Karten mit Guthaben), verwenden Sie CATEGORY_OTHER. AID-Gruppen in Diese Kategorie kann immer aktiv sein und durch NFC priorisiert werden. Lesegeräte während der AID-Auswahl.

HCE-Dienst implementieren

Um eine NFC-Karte mithilfe der hostbasierten Kartenemulation zu emulieren, müssen Sie eine Die Service-Komponente, die die NFC-Transaktionen verarbeitet.

HCE-Unterstützung prüfen

Ihre Anwendung kann prüfen, ob ein Gerät HCE unterstützt, indem sie nach dem FEATURE_NFC_HOST_CARD_EMULATION . Verwenden Sie den <uses-feature>. im Manifest Ihrer Anwendung, um zu deklarieren, dass Ihre App das HCE verwendet und ob dies erforderlich ist, damit die App funktioniert.

Dienstimplementierung

Android 4.4 und höher bietet eine praktische Service-Klasse, die Sie verwenden können als Grundlage für die Implementierung eines HCE-Dienstes verwendet: Klasse HostApduService.

Im ersten Schritt wird HostApduService erweitert, wie im folgenden Code gezeigt: Beispiel:

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 deklariert zwei abstrakte Methoden, die überschrieben werden müssen. umsetzen. Eine davon: processCommandApdu(), wird aufgerufen, wenn ein NFC-Lesegerät eine APDU (Application Protocol Data Unit) sendet für Ihren Dienst. APDUs sind in der ISO/IEC 7816-4-Spezifikation definiert. APDUs sind die Pakete auf Anwendungsebene, die zwischen dem Ihren HCE-Dienst. Dieses Protokoll auf Anwendungsebene ist halbduplex: das NFC-Lesegerät sendet Ihnen eine Befehls-APDU, die darauf wartet, dass Sie eine Antwort-APDU senden: zurückgeben.

Hinweis :Die ISO/IEC 7816-4-Spezifikation definiert auch das Konzept mehrerer logische Kanäle, sodass Sie mehrere parallele APDU verwenden können auf separaten logischen Channels. die HCE-Implementierung von Android, unterstützt jedoch nur einen einzigen logischen Channel, sodass nur ein Single-Threaded-Austausch von APDUs.

Wie bereits erwähnt, bestimmt Android anhand der AID, welcher HCE-Dienst mit denen Leser sprechen möchten. Normalerweise sendet die erste APDU, die ein NFC-Lesegerät an Ihren Gerät ist eine SELECT AID-APDU. Diese APDU enthält die AID, die der Leser mit denen Sie sprechen können. Android extrahiert diese AID aus der APDU und löst sie in ein HCE auf und leitet diese APDU an den aufgelösten Dienst weiter.

Sie können eine Antwort-APDU senden, indem Sie die Byte der Antwort-APDU von processCommandApdu() Beachten Sie, dass diese Methode im Hauptthread aufgerufen wird. die Sie nicht blockieren sollten. Wenn Sie nicht berechnen und keine sofort eine APDU-Antwort, geben Sie null zurück. Anschließend können Sie die notwendigen Schritte in einem anderen Thread sendResponseApdu() in der Klasse HostApduService definiert, um die Antwort zu senden, wenn Sie fertig.

Android leitet neue APDUs vom Lesegerät an deinen Dienst weiter, bis entweder passiert Folgendes:

• Das NFC-Lesegerät sendet eine weitere SELECT AID-APDU, die das Betriebssystem in einen unterschiedlichen Diensts.
• Die NFC-Verbindung zwischen dem NFC-Lesegerät und Ihrem Gerät ist defekt.

In beiden Fällen onDeactivated() -Implementierung mit einem -Argument aufgerufen wird, das angibt, was der beiden Fälle aufgetreten ist.

Wenn du mit der bestehenden Leser-Infrastruktur arbeitest, musst du die ein vorhandenes Protokoll auf Anwendungsebene, das die Leser in Ihrem HCE-Dienst erwarten.

Wenn Sie eine neue Leser-Infrastruktur bereitstellen, die Sie ebenfalls steuern, können Sie Ihr eigenes Protokoll und Ihre eigene APDU-Sequenz definieren. Die Anzahl der APDUs begrenzen und die Menge der ausgetauschten Daten. So wird sichergestellt, um das Gerät für kurze Zeit über das NFC-Lesegerät zu halten. A angemessene Obergrenze liegt bei etwa 1 KB an Daten, die in der Regel innerhalb von 300 ms ausgetauscht.

Deklaration des Dienstmanifests und AID-Registrierung

Sie müssen Ihren Dienst wie gewohnt im Manifest deklarieren, aber auch einige zusätzliche Teile der Service-Deklaration:

1. Um der Plattform mitzuteilen, dass es sich um einen HCE-Dienst handelt, der ein HostApduService-Schnittstelle einen Intent-Filter für die SERVICE_INTERFACE Aktion zu Ihrer Dienstdeklaration hinzu.

2. Um der Plattform mitzuteilen, welche AIDs-Gruppen von diesem Dienst angefordert werden, fügen Sie eine SERVICE_META_DATA <meta-data>-Tag in der Deklaration des Dienstes, das auf eine XML-Datei verweist Ressource mit zusätzlichen Informationen zum HCE-Dienst.

3. Legen Sie das Attribut android:exported auf true fest und verlangen Sie, dass die android.permission.BIND_NFC_SERVICE. Mit Ersteren wird sichergestellt, dass der Dienst an externe Anwendungen gebunden werden kann. Die zweite erzwingt dann, dass nur externe Anwendungen, die den Die Berechtigung android.permission.BIND_NFC_SERVICE kann an Ihren Dienst gebunden werden. Da android.permission.BIND_NFC_SERVICE eine Systemberechtigung ist, gilt Folgendes: erzwingt effektiv, dass sich nur das Android-Betriebssystem an Ihren Dienst binden kann.

Das folgende Beispiel zeigt die Deklaration des Manifests 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>

Dieses Metadaten-Tag verweist auf eine apduservice.xml-Datei. Im Folgenden finden Sie Beispiel für eine solche Datei mit einer einzelnen AID-Gruppendeklaration, die zwei proprietäre AIDs:

<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>

Das <host-apdu-service>-Tag muss ein <android:description>-Attribut enthalten. die eine nutzerfreundliche Beschreibung der Dienstleistung enthält, der App-Benutzeroberfläche. Mit dem Attribut requireDeviceUnlock können Sie festlegen, Gerät entsperrt wird, bevor Sie diesen Dienst zum Verarbeiten von APDUs aufrufen.

<host-apdu-service> muss mindestens ein <aid-group>-Tag enthalten. Jedes Das <aid-group>-Tag ist für Folgendes erforderlich:

• ein android:description-Attribut enthalten, das eine nutzerfreundliche Beschreibung der AID-Gruppe, die in der UI angezeigt werden kann.
• Das Attribut android:category muss so festgelegt sein, dass die Kategorie der AID angegeben wird. Gruppe gehört, z. B. die durch CATEGORY_PAYMENT definierten Stringkonstanten oder CATEGORY_OTHER.
• Ein oder mehrere <aid-filter>-Tags enthalten, von denen jedes eine einzelne AID enthält. Geben Sie die AID im Hexadezimalformat an und achten Sie darauf, dass sie eine gerade Anzahl von Zeilen enthält Anzahl der Zeichen.

Ihre Anwendung muss außerdem die Berechtigung für NFC, sich als HCE-Dienst.

AID-Konfliktlösung

Es können mehrere HostApduService-Komponenten auf einem einzigen Gerät installiert sein. kann eine AID von mehr als einem Dienst registriert werden. Android löst AID auf je nachdem, zu welcher Kategorie eine AID gehört. Jedes haben möglicherweise andere Richtlinien zur Konfliktlösung.

Für einige Kategorien, z. B. Zahlungen, kann der Nutzer möglicherweise eine Standardkategorie auswählen, in den Android-Einstellungen. Für andere Kategorien könnte die Richtlinie lauten, den Nutzer im Falle eines Konflikts immer fragen, welchen Dienst er aufrufen soll. Weitere Informationen Informationen zum Abfragen der Richtlinie zur Konfliktlösung für eine bestimmte Kategorie finden Sie unter getSelectionModeForCategory()

Prüfen, ob es sich um den Standarddienst handelt

Anwendungen können prüfen, ob ihr HCE-Dienst der Standarddienst für ein bestimmte Kategorie mithilfe des isDefaultServiceForCategory() der API erstellen.

Wenn es sich bei Ihrem Dienst nicht um den Standarddienst handelt, können Sie beantragen, dass er als Standarddienst festgelegt wird. mit ACTION_CHANGE_DEFAULT

Zahlungsanwendungen

Android berücksichtigt HCE-Dienste, die eine AID-Gruppe mit der payment als Zahlungsanwendung. Android 4.4 und höher enthält eine Menüeintrag Einstellungen namens Tap & Pay, die alle wie Zahlungsanwendungen. In diesem Einstellungsmenü kann der Nutzer Standard-Zahlungsanwendung, die aufgerufen wird, wenn ein Zahlungsterminal an das Terminal gehalten wird.

Erforderliche Assets für Zahlungsanwendungen

Um eine optisch ansprechendere Nutzererfahrung zu bieten, werden HCE-Zahlungsanwendungen sind erforderlich, um ein Servicebanner bereitzustellen.

Android 13 und höher

Passen Sie den Bereich in ein quadratisches Symbol zu ändern. Idealerweise sollten sie identisch mit dem Symboldesign für den App Launcher Diese Anpassung sorgt für mehr Konsistenz und saubererer Look.

Android 12 und niedriger

Legen Sie die Größe des Servicebanners auf 260 x 96 dp und anschließend die Größe des Servicebanners fest. in der Metadaten-XML-Datei durch Hinzufügen des Attributs android:apduServiceBanner zu Das <host-apdu-service>-Tag, das auf die Drawable-Ressource verweist. Die Hier ist ein Beispiel:

<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>

Verhalten bei ausgeschaltetem Display und Sperrbildschirm

Das Verhalten von HCE-Diensten variiert je nach Android-Version auf dem Gerät.

Android 12 und höher

In Apps, die auf Android 12 (API-Level 31) und höher ausgerichtet sind, kannst du NFC aktivieren ohne dass der Bildschirm des Geräts eingeschaltet ist, indem du requireDeviceScreenOn bis false.

Android 10 und höher

Geräte mit Android 10 (API-Level 29) oder höher werden unterstützt Sicher NFC. Sicher NFC ist aktiviert, alle Kartenemulatoren (Host-Anwendungen und Off-Host-Anwendungen) werden nicht verfügbar, wenn der Bildschirm des Geräts ausgeschaltet ist. Wenn sichere NFC-Funktion deaktiviert ist und sich außerhalb des Hosts befindet Apps sind bei ausgeschaltetem Gerätebildschirm verfügbar. Sie können nach Sichere NFC-Unterstützung mit isSecureNfcSupported()

Auf Geräten mit Android 10 und höher kann die Einstellung android:requireDeviceUnlock für true gilt wie für Geräte mit Android 9 oder niedriger, aber nur, wenn sichere NFC deaktiviert ist. Das heißt, wenn Sichere NFC ist aktiviert, HCE-Dienste können auf dem Sperrbildschirm nicht verwendet werden unabhängig von der Einstellung von android:requireDeviceUnlock.

Android 9 und niedriger

Auf Geräten mit Android 9 (API-Level 28) und niedriger können der NFC-Controller und wird der Application Processor vollständig ausgeschaltet, wenn der Bildschirm des Gerät ausgeschaltet ist. HCE-Dienste funktionieren daher bei ausgeschaltetem Bildschirm nicht.

Unter Android 9 und niedriger können HCE-Dienste auch über den Sperrbildschirm ausgeführt werden. Dies wird jedoch durch das Attribut android:requireDeviceUnlock gesteuert, <host-apdu-service> Ihres HCE-Dienstes. Standardmäßig ist die Geräteentsperrung nicht erforderlich, und Ihr Dienst wird auch dann aufgerufen, wenn das Gerät gesperrt ist.

Wenn Sie das Attribut android:requireDeviceUnlock für Ihr HCE auf true festlegen wird der Nutzer in den folgenden Fällen aufgefordert, das Gerät zu entsperren: Folgendes passieren:

• tippt der Nutzer auf ein NFC-Lesegerät.
• wählt das NFC-Lesegerät eine AID aus, die Ihrem Dienst zugeordnet wird.

Nach dem Entsperren wird ein Dialogfeld angezeigt, in dem der Nutzer aufgefordert wird, noch einmal zu tippen, um die Transaktion abzuschließen. Das ist notwendig, da der Nutzer in der Nähe des NFC-Lesegeräts, um es zu entsperren.

Secure Element-Karten nebeneinander vorhanden

Dieser Abschnitt ist für Entwickler interessant, die eine Anwendung bereitgestellt haben, das für die Kartenemulation ein Secure Element verwendet. HCE-Implementierung von Android wurde entwickelt, um parallel zu anderen Methoden der Kartenimplementierung zu funktionieren. Emulation, einschließlich der Verwendung von sicheren Elementen.

Hinweis: Android bietet keine APIs für die direkte Kommunikation mit einem sicheren Element selbst.

Diese Koexistenz basiert auf dem Prinzip des AID-Routings. Die NFC Controller unterhält eine Routingtabelle, die aus einer (endlichen) Liste von Routing- Regeln. Jede Routingregel enthält eine AID und ein Ziel. Das Ziel kann entweder die Host-CPU, auf der Android-Apps ausgeführt werden, oder eine -Elements.

Wenn das NFC-Lesegerät eine APDU mit einer SELECT AID sendet, parst der NFC-Controller und überprüft, ob die AIDs mit einer AID in der Routingtabelle übereinstimmen. Wenn es stimmt, werden APDU und alle darauffolgenden APDUs an das Ziel gesendet. die mit der AID verknüpft sind, bis eine andere SELECT AID-APDU empfangen wird oder die NFC defekter Link.

Hinweis :ISO/IEC 7816-4 definiert auch das Konzept teilweiser Übereinstimmungen. wird von Android HCE-Geräten nicht unterstützt.

In Abbildung 4 ist diese Architektur dargestellt:

Abbildung 4: Android arbeitet mit Secure Element und Hostkartenemulation.

Der NFC-Controller enthält normalerweise auch eine Standardroute für APDUs. Wenn ein AID wurde in der Routingtabelle nicht gefunden. Die Standardroute wird verwendet. Während dies kann sich von Gerät zu Gerät unterscheiden, Android-Geräte sind erforderlich damit die von Ihrer App registrierten AIDs ordnungsgemäß an den Host.

Android-Anwendungen, die einen HCE-Dienst implementieren oder ein Secure Element verwenden Sie müssen sich nicht um die Konfiguration der Routingtabelle kümmern, das von der Android automatisch. Android muss lediglich wissen, welche AIDs verarbeitet werden können. von HCE-Diensten und welche vom Secure Element verarbeitet werden können. Das Routing wird automatisch konfiguriert, je nachdem, welche Dienste installiert und die der Nutzer als bevorzugt konfiguriert hat.

Im folgenden Abschnitt wird erläutert, wie AIDs für Anwendungen deklariert werden, die eine Secure Element für die Kartenemulation.

Secure Element-AID-Registrierung

Anwendungen, die ein Secure Element für die Kartenemulation verwenden, können ein Service außerhalb des Hosts in ihrem Manifest. Die Deklaration eines solchen Dienstes fast identisch mit der Deklaration eines HCE-Dienstes. Ausnahmen sind folgt:

• Für die im Intent-Filter verwendete Aktion muss folgender Wert festgelegt sein: SERVICE_INTERFACE
• Das Attribut „Metadatenname“ muss auf SERVICE_META_DATA

• Die Metadaten-XML-Datei muss das Stamm-Tag <offhost-apdu-service> verwenden.

  <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>
  

Im Folgenden finden Sie ein Beispiel für die entsprechende apduservice.xml-Datei: Registrierung von zwei AIDs:

<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>

Das Attribut android:requireDeviceUnlock gilt nicht für Dienste außerhalb des Hosts. da die Host-CPU nicht an der Transaktion beteiligt ist und Verhindert, dass das Secure Element Transaktionen ausführt, wenn das Gerät gesperrt.

Das Attribut android:apduServiceBanner ist für Dienste außerhalb des Hosts erforderlich Zahlungsanwendungen, die als Standardzahlungsmittel ausgewählt werden können, .

Dienstaufruf außerhalb des Hosts

Android wird nie mit einem Dienst gestartet, der als „außerhalb des Hosts“ deklariert ist, oder sich an ihn zu binden. da die tatsächlichen Transaktionen vom Secure-Element und nicht von den Android-Dienst nutzen. Die Servicedeklaration gestattet Anwendungen lediglich, AIDs registrieren, die auf dem Secure Element vorhanden sind.

HCE und Sicherheit

Die HCE-Architektur bietet ein zentrales Sicherheitsmerkmal: wird geschützt durch die BIND_NFC_SERVICE Systemberechtigung hat, kann nur das Betriebssystem eine Verbindung zu Ihrem Dienst herstellen und mit ihm kommunizieren. Dadurch wird sichergestellt, dass jede APDU, die Sie erhalten, tatsächlich eine APDU ist, die von Ihrem das Betriebssystem vom NFC-Controller übertragen, und dass jede APDU, die Sie zurücksenden, nur an das Betriebssystem, das wiederum die APDUs direkt an den NFC-Controller weiterleitet.

Die letzte Sorge ist, wo Sie die von Ihrer App gesendeten Daten erhalten. zum NFC-Lesegerät. Dies ist im HCE-Design bewusst entkoppelt. Es tut sich Es spielt keine Rolle, woher die Daten stammen, sondern es wird lediglich sichergestellt, dass sie sicher sind. zum NFC-Controller und wieder zum NFC-Lesegerät übertragen werden.

Zum sicheren Speichern und Abrufen der Daten, die Sie von Ihrem HCE senden möchten können Sie sich zum Beispiel auf die Android Application Sandbox verlassen, werden die Daten Ihrer App von anderen Apps isoliert. Weitere Informationen zu Android finden Sie unter Sicherheitstipps.

Protokollparameter und -details

Dieser Abschnitt ist für Entwickler interessant, die wissen möchten, Parameter, die HCE-Geräte während der Antikollisions- und Aktivierungsphase die NFC-Protokolle. So können Sie eine Leserinfrastruktur erstellen, kompatibel mit Android HCE-Geräten.

NFC-A-Protokoll Antikollision und Aktivierung (ISO/IEC 14443 Typ A)

Im Rahmen der Aktivierung des NFC-A-Protokolls werden mehrere Frames ausgetauscht.

Im ersten Teil des Datenaustauschs zeigt das HCE-Gerät seine UID an. HCE-Geräte eine zufällige UID. Das bedeutet, dass die UID bei jedem Tippen die den Lesern angezeigt wird, eine zufällig generierte UID. Aus diesem Grund NFC-Lesegeräte sollten nicht von der UID von HCE-Geräten als Form von Authentifizierung oder Identifizierung.

Das NFC-Lesegerät kann anschließend das HCE-Gerät auswählen, indem es eine SEL_REQ sendet . Die SEL_RES-Antwort des HCE-Geräts hat mindestens das sechste Bit (0x20) festgelegt ist, was bedeutet, dass das Gerät ISO-DEP unterstützt. Beachten Sie, dass andere Teile Der SEL_RES kann ebenfalls festgelegt werden, was beispielsweise auf Unterstützung für NFC-DEP verweist. (p2p)-Protokoll. Da andere Teile gesetzt werden können, möchten Leser HCE-Geräte sollten explizit nur das 6. Bit prüfen und nicht vergleichen die vollständige SEL_RES mit einem Wert von 0x20.

ISO-DEP-Aktivierung

Nachdem das NFC-A-Protokoll aktiviert wurde, initiiert der NFC-Leser den ISO-DEP. Protokollaktivierung. Es wird eine RATS-Anfrage (Request for Answer to Select) gesendet. . Der NFC-Controller generiert die RATS-Antwort, den ATS. ist der ATS nicht kann durch HCE-Dienste konfiguriert werden. HCE-Implementierungen müssen jedoch dem NFC-Forum entsprechen. Anforderungen für die ATS-Antwort, damit NFC-Lesegeräte auf diese Parameter zählen können gemäß den Anforderungen des NFC-Forums für HCE-Geräte festgelegt.

Der folgende Abschnitt enthält weitere Informationen zu den einzelnen Byte des ATS. Antwort des NFC-Controllers auf einem HCE-Gerät:

• TL: Länge der ATS-Antwort. Darf nicht für eine Länge über 20 Zeichen stehen Bytes.
• T0: Die Bits 5, 6 und 7 müssen auf allen HCE-Geräten festgelegt werden, wobei TA(1) und TB(1) angegeben werden. und TC(1) sind in der ATS-Antwort enthalten. Die Bits 1 bis 4 zeigen die FSCI an, Codierung der maximalen Frame-Größe. Auf HCE-Geräten muss FSCI zwischen 0:00 und 8:00 Uhr.
• T(A)1: definiert die Bitraten zwischen Reader und Emulator und ob sie asymmetrisch. Für HCE-Geräte gibt es keine Anforderungen an die Bitrate oder Garantien.
• T(B)1: Die Bits 1 bis 4 geben die Ganzzahl für die Start-Frame Guard-Zeit an. An HCE-Geräte, SFGI muss <= 8 h sein. Die Bits 5 bis 8 zeigen an, dass der Frame gewartet wird. time Integer (FWI) und codiert die Frame Waiting Time (FWT). Auf HCE-Geräten, FWI muss <= 8h sein.
• T(C)1: Bit 5 steht für die Unterstützung von erweiterten Protokollfunktionen. HCE-Geräte unterstützt möglicherweise „Erweiterte Protokollfunktionen“. Bit 2 zeigt Unterstützung an. für DID. HCE-Geräte unterstützen möglicherweise DID. Bit 1 gibt an, dass NAD. HCE-Geräte dürfen NAD nicht unterstützen und Bit 1 auf null setzen.
• Bisherige Byte: HCE-Geräte können bis zu 15 Verlaufsbyte zurückgeben. NFC Leser, die bereit sind, mit HCE-Diensten zu interagieren, den Inhalt der historischen Bytes oder deren Vorhandensein.

Beachten Sie, dass viele HCE-Geräte wahrscheinlich die Protokollanforderungen erfüllen. die die in EMVCo vereinten Zahlungsnetzwerke in ihren Kommunikationsprotokoll“ Spezifikation zu ändern. Insbesondere

• Der FSCI-Wert in T0 muss zwischen 2 Stunden und 8 Stunden liegen.
• T(A)1 muss auf 0 x 80 festgelegt sein, was bedeutet, dass nur die Bitrate von 106 kbit/s unterstützt und asymmetrische Bitraten zwischen Reader und Emulator unterstützt.
• FWI in T(B)1 muss <= 7h sein.

APDU-Datenaustausch

Wie bereits erwähnt, unterstützen HCE-Implementierungen nur einen einzelnen logischen Kanal. Der Versuch, Anwendungen auf verschiedenen logischen Kanälen auszuwählen, funktioniert bei einem HCE-Gerät.