Omówienie emulacji kart opartych na serwerze

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)

.

Uwaga: w kategorii CATEGORY_PAYMENT można włączyć tylko jedną grupę AID w kategorii CATEGORY_PAYMENT w danym systemie. Zazwyczaj jest to aplikacja, która rozumie najważniejsze protokoły płatności kartą kredytową i rozumie, które z nich sprzedawcy.

W przypadku aplikacji do płatności closed loop, które działają tylko w jednym sprzedawcy (np. karty ze środkami przedpłaconymi), użyj CATEGORY_OTHER. Grupy AID w ta kategoria może być zawsze aktywna i może mieć priorytet przez NFC podczas wyboru systemu AID.

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 .

Uwaga: specyfikacja ISO/IEC 7816-4 definiuje też koncepcję wielu kanałów logicznych, co pozwala utworzyć kilka równoległych wartości ADU. giełd na osobnych kanałach logicznych. wdrożenie technologii HCE na Androidzie, jednak obsługuje tylko jeden kanał logiczny, więc jednowątkową wymianę punktów APDU.

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:

1. Aby poinformować platformę, że jest to usługa HCE implementująca HostApduService, dodaj filtr intencji dla pola SERVICE_INTERFACE. do deklaracji dotyczącej usługi.

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

3. Ustaw atrybut android:exported na true i wymagaj parametru android.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ć uprawnienie android.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 element CATEGORY_PAYMENT lub CATEGORY_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.

Uwaga: Android nie oferuje interfejsów API do bezpośredniej komunikacji z i samego elementu.

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.

Uwaga: standard ISO/IEC 7816-4 definiuje również koncepcję dopasowań częściowych, ta funkcja nie jest obsługiwana na urządzeniach z Androidem HCE.

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.