Wiele urządzeń z Androidem, które oferują tę funkcję, już obsługuje komunikację NFC emulacja karty. W większości przypadków karta jest emulowana przez osobny układ scalony w tak zwany element zabezpieczony. Wiele kart SIM dostarczanych przez operatorów bezprzewodowych zawierają też bezpieczny element.
Android 4.4 i nowsze oferują dodatkową metodę emulacji karty, nie obejmuje bezpiecznego elementu nazywanego emulacją kart hosta. Ten pozwala dowolnej aplikacji na Androida emulować kartę i komunikować się bezpośrednio z NFC . W tym artykule opisujemy, jak działa HCE (Host-based Card Emulation, HCE) jak stworzyć aplikację, która emuluje kartę NFC za pomocą za pomocą tej metody.
Emulacja karty z bezpiecznym elementem
Jeśli w emulacji karty NFC jest używany bezpieczny element, karta, jest udostępniana do bezpiecznego elementu na urządzeniu za pomocą interfejsu Androida aplikacji. Gdy użytkownik zbliży urządzenie do terminala z modułem NFC, kontroler w urządzeniu kieruje wszystkie dane z czytnika bezpośrednio do . Tę koncepcję przedstawia Ilustracja 1:
()
Rysunek 1. Emulacja karty NFC z zabezpieczonym elementem.
Sam bezpieczny element komunikuje się z terminalem NFC. żadna aplikacja na Androida nie jest zaangażowana w transakcję. Po zakończeniu transakcji aplikacja na Androida może wysyłać zapytania do bezpiecznego elementu bezpośrednio o stanie transakcji i powiadomić użytkownika.
Emulacja karty host-based
Gdy karta NFC jest emulowana przy użyciu emulacji karty opartej na hoście, dane są kierowane bezpośrednio do procesora hosta, a nie do bezpiecznego elementu. Rysunek 2 ilustruje sposób działania emulacji kart hosta:
()
Rysunek 2. Emulacja karty NFC bez zabezpieczenia.
Obsługiwane karty i protokoły NFC
()
Rysunek 3. Stos protokołów HCE na Androida.
Standardy NFC obsługują wiele różnych protokołów. różne typy kart, które możesz emulować.
Android 4.4 i nowszy obsługuje kilka protokołów popularnych na rynku
dzisiaj. Wiele istniejących kart zbliżeniowych jest już opartych na tych protokołach:
takich jak płatności zbliżeniowe. Protokoły te są również obsługiwane przez wiele
Czytniki NFC dostępne na rynku, w tym urządzenia z Androidem NFC działające jako
samych czytelników (zobacz IsoDep
)
zajęcia). Dzięki temu możesz stworzyć i wdrożyć kompleksowe rozwiązanie NFC
HCE dotyczy wyłącznie urządzeń z Androidem.
W szczególności Android 4.4 i nowsze obsługują emulację kart opartych na specyfikacja NFC-Forum ISO-DEP (wg normy ISO/IEC 14443-4) oraz proces Jednostki danych protokołu aplikacji (APDU) zgodne z normą ISO/IEC 7816-4 specyfikacji. Android wymaga emulacji ISO-DEP tylko na telefonie Nfc-A (ISO/IEC 14443-3 typu A). Obsługa standardu Nfc-B (ISO/IEC 14443-4 typu B) jest opcjonalna. Na rys. 3 przedstawiono nakładanie się wszystkich tych elementów specyfikacji.
Usługi HCE
Architektura HCE w Androidzie bazuje na Androidzie
komponenty Service
(znane jako HCE),
usługi). Jedną z głównych zalet usługi jest to, że może ona działać
w tle bez żadnego interfejsu użytkownika. W przypadku wielu technologii HCE jest to naturalne
aplikacji, takich jak karty lojalnościowe lub transportowe, których użytkownik nie powinien
uruchom aplikację, której chcesz użyć. Zamiast tego rozpoczyna się zbliżenie urządzenia do czytnika NFC.
odpowiednią usługę, jeśli jeszcze nie jest uruchomiona i wykonuje transakcję,
w tle. Możesz oczywiście uruchomić dodatkowy interfejs (np.
powiadomień użytkownika) z usługi.
Wybór usługi
Gdy użytkownik zbliży urządzenie do czytnika NFC, system Android musi wiedzieć, Z którą usługą HCE chce się komunikować czytnik NFC. ISO/IEC 7816-4 określa sposób wyboru aplikacji skoncentrowanych na Application ID (AID). Identyfikator AID składa się z maksymalnie 16 bajtów. Jeśli korzystasz z emulacji istniejących czytników NFC, czyli identyfikatorów AID używanych przez te czytniki są zwykle dobrze znane i zarejestrowane publicznie (na przykład identyfikatory sieci płatniczych (np. Visa i Mastercard).
Jeśli chcesz wdrożyć nową infrastrukturę czytnika dla swojej aplikacji, musi zarejestrować własne środki AID. Procedura rejestracji w przypadku AID jest zdefiniowana w zgodnie ze specyfikacją ISO/IEC 7816-5. Zalecamy zarejestrowanie identyfikatora AID zgodnie z wytycznymi 7816-5 jeśli wdrażasz aplikację HCE na Androida, ponieważ pozwala ona uniknąć kolizji z innymi aplikacjami.
Grupy AID
W niektórych przypadkach może być konieczne zarejestrowanie wielu identyfikatorów AID w usłudze HCE i ustawienie jej jako domyślnego modułu obsługi wszystkich identyfikatorów AID, aby zaimplementować określone aplikacji. Niektóre identyfikatory AID w grupie przekazywane do innej usługi nie są obsługiwane.
Lista identyfikatorów AID, które są przechowywane razem, nosi nazwę grupy AID. W przypadku wszystkich pogorszenia stanu zdrowia grupy AID, Android gwarantuje jeden z tych elementów:
- Wszystkie identyfikatory AID w grupie są kierowane do tej usługi HCE.
- Żadne AID z grupy nie są kierowane do tej usługi HCE (na przykład dlatego, że użytkownik wybrał inną usługę, która zażądała co najmniej jednego identyfikatora AID w grupie ).
Inaczej mówiąc, nie ma „elementu pośredniego”, w którym niektóre identyfikatory AID w grupie mogą może być kierowana do jednej usługi HCE, a część do drugiej.
Grupy i kategorie AID
Każdą grupę AID możesz powiązać z kategorią. Dzięki temu Android może grupować usług HCE podzielonych według kategorii, co z kolei umożliwia użytkownikowi określenie jest domyślnie ustawiana na poziomie kategorii, a nie na poziomie AID. Nie wspominaj o AID w żadnych częściach aplikacji dla użytkowników, ponieważ nie mają one żadnego znaczenia dla przeciętnego użytkownika.
Android 4.4 i nowszy obsługuje dwie kategorie:
CATEGORY_PAYMENT
(dotyczy to standardowych aplikacji płatniczych)CATEGORY_OTHER
(w przypadku wszystkich pozostałych aplikacji HCE)
Wdrażanie usługi HCE
Aby emulować kartę NFC za pomocą emulacji karty opartej na hoście, musisz utworzyć
Komponent Service
, który obsługuje transakcje NFC.
Sprawdzanie obsługi HCE
Aplikacja może sprawdzić, czy urządzenie obsługuje HCE, sprawdzając
FEATURE_NFC_HOST_CARD_EMULATION
funkcji. Korzystanie z <uses-feature>
w pliku manifestu aplikacji zadeklaruj, że korzysta ona z technologii HCE.
i o tym, czy jest wymagana do działania.
Implementacja usługi
Android 4.4 i nowszy zapewnia wygodną klasę Service
, której możesz używać
jako podstawę wdrożenia usługi HCE:
Zajęcia: HostApduService
.
Pierwszym krokiem jest rozszerzenie usługi HostApduService
, jak pokazano w poniższym kodzie
przykład:
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
deklaruje 2 abstrakcyjne metody, które musisz zastąpić,
do wdrożenia. Jeden z nich,
processCommandApdu()
jest wywoływana, gdy czytnik NFC wysyła jednostkę danych protokołu aplikacji (APDU).
do Twojej usługi. Jednostki reklamowe (APDU) są zdefiniowane w specyfikacji ISO/IEC 7816-4. APDU
to pakiety na poziomie aplikacji wymieniane między czytnikiem NFC
z usługi HCE. Protokół na poziomie aplikacji jest w połowie dupleksu: czytnik NFC
wysyła polecenie APDU i czeka na wysłanie odpowiedzi
.
Jak już wspomnieliśmy, Android używa AID do określania, która usługa HCE
z którymi czytelnik chce rozmawiać. Zazwyczaj jest to pierwszy identyfikator ADU, który czytnik NFC wysyła do
urządzenie jest urządzeniem typu „APDU” na poziomie SELECT AID
; ten identyfikator aplikacji zawiera identyfikator wymagany przez czytelnika
z którymi chcesz porozmawiać. Android wyodrębnia ten identyfikator z APDU i przekształca go w technologię HCE
usługę, a następnie przekazuje tę kartę do odpowiedniej usługi.
Możesz wysłać odpowiedź APDU, zwracając bajty odpowiedzi APDU z
processCommandApdu()
Zwróć uwagę, że ta metoda jest wywoływana w wątku głównym.
aplikacji, co nie należy blokować. Jeśli nie możesz obliczyć i zwrócić
natychmiast zwróci odpowiedź APDU, zwraca wartość null. Następnie możesz wykonać te czynności na
w innym wątku i użyj
sendResponseApdu()
zdefiniowaną w klasie HostApduService
do wysyłania odpowiedzi, gdy
gotowe.
Android przekazuje nowe jednostki APK z czytnika do Twojej usługi, dopóki: zachodzą następujące sytuacje:
- Czytnik NFC wysyła kolejny punkt APDU
SELECT AID
, który system operacyjny przypisuje inną usługę. - Połączenie NFC między czytnikiem NFC a urządzeniem nie działa.
W obu tych przypadkach atrybut zajęć
onDeactivated()
implementacja jest wywoływana z argumentem wskazującym, która z tych sytuacji miała miejsce.
Jeśli korzystasz z istniejącej infrastruktury czytnika, musisz wdrożyć obecny protokół na poziomie aplikacji, którego czytelnicy oczekują w usłudze HCE.
Jeśli wdrażasz nową infrastrukturę czytelników, nad którą również masz kontrolę, może zdefiniować własny protokół i sekwencję APDU. Spróbuj ograniczyć liczbę licencji na aplikacje i rozmiaru danych do wymiany. Dzięki temu użytkownicy będą mieli przytrzymuje urządzenie przez krótki czas nad czytnikiem NFC. O rozsądna górna granica to około 1 KB danych, które zwykle są wymieniane w ciągu 300 ms.
Deklaracja w pliku manifestu usługi i rejestracja AID
Swoją usługę musisz zadeklarować w pliku manifestu jak zwykle, ale konieczne jest dodanie oraz dodatkowe części deklaracji dotyczącej usługi:
Aby poinformować platformę, że jest to usługa HCE implementująca
HostApduService
, dodaj filtr intencji dla polaSERVICE_INTERFACE
. do deklaracji dotyczącej usługi.Aby wskazać platformie, które grupy AID są żądane przez tę usługę, dodaj w
SERVICE_META_DATA
<meta-data>
w deklaracji usługi, który wskazuje na kod XML. zasób z dodatkowymi informacjami o usłudze HCE.Ustaw atrybut
android:exported
natrue
i wymagaj parametruandroid.permission.BIND_NFC_SERVICE
w deklaracji dotyczącej usługi. Pierwszy zapewnia powiązanie usługi przez aplikacje zewnętrzne. W drugim przypadku powstaje zasada, że tylko zewnętrzne aplikacje przechowujące Z Twoją usługą można powiązać uprawnienieandroid.permission.BIND_NFC_SERVICE
.android.permission.BIND_NFC_SERVICE
jest uprawnieniem systemowym, więc skutecznie wymusza powiązanie z usługą tylko systemu operacyjnego Android.
Oto przykład deklaracji pliku manifestu 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>
Ten tag metadanych wskazuje plik apduservice.xml
. Oto
przykład takiego pliku z pojedynczą deklaracją grupy AID zawierającą 2 grupy
zastrzeżone identyfikatory 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>
Tag <host-apdu-service>
musi zawierać atrybut <android:description>
który zawiera zrozumiały opis usługi, którą możesz wyświetlać;
interfejsu aplikacji. Możesz użyć atrybutu requireDeviceUnlock
, aby określić, że
urządzenie zostanie odblokowane przed wywołaniem tej usługi w celu obsługi produktów powiązanych z APDU.
Element <host-apdu-service>
musi zawierać co najmniej 1 tag <aid-group>
. Każdy
Tag <aid-group>
jest wymagany do tych działań:
- Zawierają atrybut
android:description
, który jest łatwy w użyciu opis grupy AID odpowiedni do wyświetlenia w interfejsie. - Mają ustawiony atrybut
android:category
wskazujący kategorię, do której należy AID grupa, do której należy, np. stałe ciągu znaków zdefiniowane przez elementCATEGORY_PAYMENT
lubCATEGORY_OTHER
. - Zawierają co najmniej 1 tag
<aid-filter>
, z których każdy zawiera pojedynczy identyfikator AID. Podaj identyfikator AID w formacie szesnastkowym i upewnij się, że zawiera on równomierny liczby znaków.
Aplikacja musi również zawierać
NFC
do zarejestrowania się jako
i usług HCE.
Rozwiązywanie konfliktu AID
Na jednym urządzeniu może być zainstalowanych wiele komponentów HostApduService
.
ten sam AID może być zarejestrowany przez więcej niż 1 usługę. Android eliminuje AID
konflikty różnią się w zależności od kategorii, do której należy identyfikator AID. Każdy
mogą mieć inne zasady rozwiązywania konfliktów.
W przypadku niektórych kategorii, takich jak płatność, użytkownik może mieć możliwość wyboru domyślnej
w interfejsie ustawień Androida. W przypadku innych kategorii zasadą może być
w przypadku wystąpienia konfliktu zawsze pytaj użytkownika, którą usługę ma zostać wywołany. Informacje na temat
na temat wysyłania zapytań dotyczących zasad rozwiązywania konfliktów w przypadku określonej kategorii można znaleźć w artykule
getSelectionModeForCategory()
Sprawdzanie, czy usługa jest domyślna
Aplikacje mogą sprawdzić, czy ich usługa HCE jest usługą domyślną dla
określonej kategorii za pomocą funkcji
isDefaultServiceForCategory()
API.
Jeśli Twoja usługa nie jest domyślna, możesz poprosić o jej ustawienie jako domyślne
za pomocą
ACTION_CHANGE_DEFAULT
Aplikacje płatnicze
Android uwzględnia usługi HCE, które zadeklarowały grupę AID za pomocą parametru payment (płatności). Android 4.4 i nowszy zawiera pozycja menu Ustawienia najwyższego poziomu o nazwie dotknij & pay, który zawiera wszystkie takich aplikacji płatniczych. W tym menu użytkownik może wybrać domyślna aplikacja płatnicza, która ma być wywoływana po dotknięciu terminala płatniczego.
Zasoby wymagane w przypadku aplikacji płatniczych
Aplikacje do płatności HCE są bardziej atrakcyjne wizualnie są wymagane, aby udostępnić baner usługi.
Android 13 i nowszy
Aby lepiej dopasować domyślną listę opcji płatności w interfejsie ustawień, dostosuj wymagane dodanie banera do kwadratowej ikony. Najlepiej, gdyby był taki sam jak ikona menu z aplikacjami. To dostosowanie pozwala zachować większą spójność i bardziej przejrzysty wygląd.
Android 12 i starsze
Ustaw rozmiar banera usługi na 260 x 96 dp, a następnie ustaw rozmiar banera usługi
w pliku XML metadanych, dodając atrybut android:apduServiceBanner
do
tag <host-apdu-service>
, który wskazuje zasób rysowalny.
Oto przykład:
<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>
Wyłączanie ekranu i działanie ekranu blokady
Działanie usług HCE różni się w zależności od wersji Androida urządzenia.
Android 12 lub nowszy
W aplikacjach kierowanych na Androida 12 (poziom interfejsu API 31) i nowsze wersje można włączyć komunikację NFC
płatności bez włączonego ekranu urządzenia przez ustawienie
requireDeviceScreenOn
do
false
Android 10 lub nowszy
Obsługa urządzeń z Androidem 10 (poziom interfejsu API 29) lub nowszym
Bezpieczeństwo
NFC. Bezpieczna
NFC jest włączone, wszystkie emulatory kart (aplikacje hosta i aplikacje spoza hosta) są
niedostępne, gdy ekran urządzenia jest wyłączony. Przy wyłączonej obsłudze NFC poza hostem
aplikacje są dostępne przy wyłączonym ekranie urządzenia. Możesz sprawdzić
Zabezpiecz obsługę NFC za pomocą
isSecureNfcSupported()
Na urządzeniach z Androidem 10 lub nowszym te same funkcje
Od android:requireDeviceUnlock
do true
stosowa się tak samo jak w przypadku urządzeń
z Androidem 9 lub starszym, ale tylko wtedy, gdy bezpieczne NFC są wyłączone. Oznacza to, że jeśli
Zabezpieczenie NFC jest włączone, usługi HCE nie mogą działać na ekranie blokady
bez względu na ustawienie opcji android:requireDeviceUnlock
.
Android 9 i starsze
Na urządzeniach z Androidem 9 (poziom interfejsu API 28) lub starszym kontroler NFC procesor aplikacji zostaje całkowicie wyłączony, gdy ekran Urządzenie jest wyłączone. W związku z tym usługi HCE nie działają przy wyłączonym ekranie.
Również na Androidzie 9 i starszych wersjach usługi HCE mogą działać na ekranie blokady.
Zależy to jednak od atrybutu android:requireDeviceUnlock
w
tag <host-apdu-service>
usługi HCE. Domyślnie odblokowywanie urządzenia jest
nie jest wymagane, a usługa zostanie wywołana nawet wtedy, gdy urządzenie jest zablokowane.
Jeśli ustawisz atrybut android:requireDeviceUnlock
na true
w urządzeniu HCE
Android prosi użytkownika o odblokowanie urządzenia w następujących sytuacjach:
za:
- użytkownik dotyka czytnika NFC.
- Czytnik NFC wybiera identyfikator AID, który jest rozpoznawany przez Twoją usługę.
Po odblokowaniu Androida prosi użytkownika o ponowne kliknięcie w celu sfinalizować transakcję. Jest to konieczne, ponieważ użytkownik mógł przenieść urządzenia z dala od czytnika NFC, aby je odblokować.
Współistnienie z kartami z bezpiecznymi elementami
Ta sekcja jest przeznaczona dla deweloperów, którzy wdrożyli aplikację który korzysta z bezpiecznego elementu do emulacji karty. Implementacja technologii HCE na Androidzie ma działać równolegle z innymi metodami implementacji kart m.in. z użyciem bezpiecznych elementów.
To współistnienie opiera się na zasadzie routingu AID. NFC kontroler przechowuje tabelę routingu, która składa się z (skończonej) listy routingu reguł. Każda reguła routingu zawiera identyfikator AID i miejsce docelowe. Miejsce docelowe może może to być procesor hosta, na którym działają aplikacje na Androida, lub .
Gdy czytnik NFC wysyła urządzenie PDU z urządzeniem SELECT AID
, kontroler NFC analizuje kontroler NFC
i sprawdza, czy identyfikatory AID pasują do dowolnego z nich w tabeli routingu. Jeśli
że wszystkie powiązane z nim punkty dostępu (APDU) i wszystkie kolejne są wysyłane do miejsca docelowego
powiązane z AID, do czasu otrzymania kolejnego SELECT AID
APDU lub
Link jest uszkodzony.
Rysunek 4 ilustruje tę architekturę:
()
Rysunek 4. Android działający z obsługą zarówno bezpiecznego elementu, jak i emulacji karty hosta.
Kontroler NFC zwykle zawiera też domyślną trasę dla urządzeń APK. Gdy W tabeli routingu nie znaleziono identyfikatora AID. Używana jest trasa domyślna. Choć w tym roku ustawienie może się różnić w zależności od urządzenia, wymagane są urządzenia z Androidem , aby zapewnić, że identyfikatory AID rejestrowane przez aplikację są prawidłowo kierowane do hosta.
Aplikacje na Androida, które implementują usługę HCE lub używają bezpiecznych elementów nie musisz się martwić skonfigurowaniem tabeli routingu; która jest obsługiwana przez Android automatycznie. Android musi tylko wiedzieć, z którymi profilami AID można obsłużyć przez usługi HCE, oraz które z nich mogą być obsługiwane przez bezpieczny element. Trasa jest konfigurowana automatycznie na podstawie zainstalowanych usług wybrany przez użytkownika.
W tej sekcji dowiesz się, jak zadeklarować AID w przypadku aplikacji, które korzystają bezpiecznego elementu do emulacji karty.
Rejestracja AID bezpiecznego elementu
Aplikacje korzystające z bezpiecznego elementu do emulacji karty mogą zadeklarować usługa poza hostem w pliku manifestu. Deklaracja takiej usługi jest są prawie identyczne z deklaracją usługi HCE. Wyjątki: następujące:
- Działanie używane w filtrze intencji musi być ustawione na
SERVICE_INTERFACE
- Atrybut meta-data name musi być ustawiony na
SERVICE_META_DATA
Plik XML metadanych musi zawierać tag główny
<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>
Oto przykład odpowiedniego pliku apduservice.xml
rejestracji 2 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>
Atrybut android:requireDeviceUnlock
nie ma zastosowania do usług poza hostem,
ponieważ procesor hosta nie jest zaangażowany w transakcję, więc nie może
zapobiegać wykonywaniu transakcji przez element bezpieczny, gdy urządzenie
zablokowany.
Atrybut android:apduServiceBanner
jest wymagany w przypadku usług poza hostem
to aplikacje płatnicze, które można wybrać jako domyślną
aplikacji.
Wywołanie usługi poza hostem
Android nigdy się nie uruchamia ani nie tworzy powiązania z usługą zadeklarowaną jako „poza hostem”, ponieważ rzeczywiste transakcje są realizowane przez element bezpieczny, a nie przez z usługi Android. Deklaracja dotycząca usługi pozwala jedynie rejestrują AID obecne w bezpiecznym elemencie.
HCE i zabezpieczenia
Architektura HCE zapewnia jeden podstawowy element zabezpieczeń:
jest chroniona przez
BIND_NFC_SERVICE
uprawnienia systemowe, tylko system operacyjny może powiązać usługę z usługą i się z nią komunikować.
Dzięki temu każda z nich jest w rzeczywistości APDU otrzymanym od
systemu operacyjnego od kontrolera NFC i że wszystkie wysyłane aplikacje są wysyłane tylko do
w systemie operacyjnym, który z kolei przekazuje je bezpośrednio do kontrolera NFC.
Ostatnią kwestią jest to, skąd pochodzą dane wysyłane przez aplikację do czytnika NFC. Jest to celowo rozdzielone w projekcie HCE. działa niezależnie od tego, skąd pochodzą dane, tylko upewnia się, że są bezpieczne. przesyłanych do kontrolera NFC, a na zewnątrz do czytnika NFC.
Bezpieczne przechowywanie i pobieranie danych, które chcesz wysyłać z urządzenia HCE możesz korzystać np. z Piaskownicy aplikacji na Androida, która – izoluje dane aplikacji od innych aplikacji. Więcej informacji o Androidzie przeczytaj artykuł Wskazówki dotyczące bezpieczeństwa.
Parametry i szczegóły protokołu
Ta sekcja jest przeznaczona dla deweloperów, którzy chcą się dowiedzieć, jaki protokół parametrów wykorzystywanych przez urządzenia HCE podczas faz zapobiegania kolizji i aktywacji protokoły NFC. Dzięki temu możemy zbudować infrastrukturę czytelników zgodnych z urządzeniami HCE z Androidem.
Protokół Nfc-A (ISO/IEC 14443 typu A) antykolizji i aktywacja
W ramach aktywacji protokołu Nfc-A jest wymienianych wiele klatek.
W pierwszej części wymiany urządzenie HCE przedstawia swój identyfikator UID. Urządzenia HCE należy przyjąć, że ma losowy identyfikator UID. Oznacza to, że po każdym kliknięciu identyfikator UID jest przedstawiany czytelnikowi losowo wygenerowanym identyfikatorem UID. Z tego powodu Czytniki NFC nie powinny polegać na identyfikatorze UID urządzeń HCE jako uwierzytelniania lub identyfikacji.
Czytnik NFC może następnie wybrać urządzenie HCE, wysyłając SEL_REQ
. Odpowiedź SEL_RES
urządzenia HCE ma co najmniej 6 bit
(0 x 20), co oznacza, że urządzenie obsługuje ISO-DEP. Pamiętaj, że pozostałe bity
Można również ustawić SEL_RES
, co wskazuje na przykład obsługę NFC-DEP
(p2p). Mogą być ustawione inne elementy, więc czytelnicy chcący wejść w interakcję
Urządzenia HCE powinny wyraźnie sprawdzać tylko 6-bitowy klucz, a nie porównywać go
pełny element SEL_RES
o wartości 0 x 20.
Aktywacja ISO-DEP
Po aktywowaniu protokołu Nfc-A czytnik NFC inicjuje protokół ISO-DEP. aktywacji protokołu. Wysyła ono żądanie RATS (prośby o wybór odpowiedzi). . Kontroler NFC generuje odpowiedź RATS, czyli ATS. to nie jest ATS które można skonfigurować za pomocą usług HCE. Implementacje HCE muszą jednak spełniać wymagania NFC Forum wymagania dotyczące odpowiedzi ATS, więc czytelnicy NFC mogą liczyć na te parametry skonfigurować zgodnie z wymaganiami Forum NFC dla dowolnego urządzenia HCE.
Poniżej znajdziesz więcej informacji o poszczególnych bajtach ATS. odpowiedź dostarczana przez kontroler NFC urządzenia HCE:
- TL: długość odpowiedzi ATS. Nie może wskazywać długości większej niż 20 B.
- T0: na wszystkich urządzeniach HCE należy ustawić bity 5, 6 i 7, co oznacza TA(1), TB(1) i TC(1) są uwzględnione w odpowiedzi ATS. Bity 1–4 wskazują na FSCI. przez kodowanie maksymalnego rozmiaru klatki. W urządzeniach HCE wartość FSCI musi być od 0 do 8 godzin.
- T(A)1: określa szybkości transmisji bitów między czytnikiem i emulatorem oraz określa, czy jest asymetryczna. W przypadku urządzeń HCE nie ma żadnych wymagań ani gwarancji dotyczących szybkości transmisji bitów.
- T(B)1: bity od 1 do 4 wskazują liczbę całkowitą określającą czas wczytywania ramki (ang. start-Frame Guard). Wł. urządzenia HCE, SFGI muszą wynosić mniej niż 8 godzin. Bity 5–8 wskazują oczekiwanie ramki Liczba całkowita czasu (FWI) i koduje czas oczekiwania ramki (FWT). Na urządzeniach HCE, FWI musi wynosić mniej niż 8 godzin.
- T(C)1: bit 5 wskazuje obsługę funkcji „Advanced Protocol”. Urządzenia HCE może nie obsługiwać „funkcji zaawansowanych protokołu”. Bit 2 wskazuje obsługę dla DID. Urządzenia HCE mogą nie obsługiwać DID. Bit 1 wskazuje obsługę NAD. Urządzenia HCE nie mogą obsługiwać NAD i muszą ustawić bit 1 na 0.
- Bajty historyczne: urządzenia HCE mogą zwracać do 15 bajtów historycznych. NFC czytelnicy chcący korzystać z usług HCE nie powinni podejmować żadnych założeń zawartość bajtów historycznych lub ich obecność.
Pamiętaj, że wiele urządzeń HCE jest prawdopodobnie zgodnych z wymaganiami dotyczącymi protokołów które organizacje płatnicze zrzeszone w EMVCo wskazały w sekcji „Płatności zbliżeniowe” Communication Protocol” specyfikacji. W szczególności:
- FSCI w momencie T0 musi mieścić się w zakresie od 2 do 8 godzin.
- T(A)1 musi mieć wartość 0 x 80, co oznacza, że tylko 106 kb/s , a asymetryczne szybkości transmisji bitów między czytnikiem a emulatorem nie są obsługiwane.
- FWI w T(B)1 musi wynosić mniej niż 7 godzin.
Wymiana danych APDU
Jak już wspomnieliśmy, implementacje HCE obsługują tylko jeden kanał logiczny. Próba wybrania aplikacji na różnych kanałach logicznych nie działa urządzenia HCE.