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)
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.
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:
Um der Plattform mitzuteilen, dass es sich um einen HCE-Dienst handelt, der ein
HostApduService
-Schnittstelle einen Intent-Filter für dieSERVICE_INTERFACE
Aktion zu Ihrer Dienstdeklaration hinzu.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.Legen Sie das Attribut
android:exported
auftrue
fest und verlangen Sie, dass dieandroid.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 Berechtigungandroid.permission.BIND_NFC_SERVICE
kann an Ihren Dienst gebunden werden. Daandroid.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 durchCATEGORY_PAYMENT
definierten Stringkonstanten oderCATEGORY_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.
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.
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.