Omówienie emulacji kart opartych na serwerze

Wiele urządzeń z Androidem i obsługujących komunikację NFC obsługuje już emulację karty NFC. W większości przypadków karta jest emulowana przez osobny układ scalony, nazywany elementem zabezpieczonym. Wiele kart SIM oferowanych przez operatorów bezprzewodowych zawiera również elementy zabezpieczające.

Android 4.4 i nowsze oferują dodatkową metodę emulacji kart, która nie obejmuje bezpiecznego elementu, tzw. emulacji karty opartej na hosta. Pozwala to dowolnej aplikacji na Androida emulować kartę i komunikować się bezpośrednio z czytnikiem NFC. W tym temacie opisujemy, jak działa HCE (host-based card emulation) na Androidzie oraz jak można stworzyć aplikację, która emuluje kartę NFC za pomocą tej metody.

Emulacja karty z bezpiecznym elementem

Jeśli emulacja karty NFC jest zapewniana za pomocą bezpiecznego elementu, emulowana karta jest udostępniana w bezpiecznym elemencie na urządzeniu za pomocą aplikacji na Androida. Następnie, gdy użytkownik zbliży urządzenie do terminala NFC, kontroler NFC w urządzeniu kieruje wszystkie dane z czytnika bezpośrednio do bezpiecznego elementu. Tę koncepcję ilustruje Rysunek 1:

Rysunek 1. Emulacja karty NFC z bezpiecznym elementem.

Sam element zabezpieczony komunikuje się z terminalem NFC, a żadna aplikacja na Androida nie uczestniczy w transakcji. Po zakończeniu transakcji aplikacja na Androida może bezpośrednio wysyłać do bezpiecznego elementu zapytanie o stan transakcji i powiadamiać użytkownika.

Emulacja karty hostowana

Gdy karta NFC jest emulowana za pomocą emulacji karty opartej na hoście, dane są kierowane bezpośrednio do procesora hosta, a nie do bezpiecznego elementu. Rysunek 2 obrazuje, jak działa emulacja kart opartych na hoście:

Rysunek 2. Emulacja karty NFC bez bezpiecznego elementu.

Obsługiwane karty i protokoły NFC

Rysunek 3. Stos protokołów HCE na Androida.

Standardy NFC obsługują wiele różnych protokołów. Istnieją też różne typy kart, które możesz emulować.

Android 4.4 i nowsze obsługują kilka protokołów powszechnie dostępnych na rynku. Wiele dotychczasowych kart zbliżeniowych korzysta już z tych protokołów, np. kart do płatności zbliżeniowych. Protokoły te są również obsługiwane przez wiele czytników NFC dostępnych obecnie na rynku, w tym urządzenia z Androidem NFC, które same w sobie działają jak czytniki (patrz: IsoDep). Umożliwia to opracowanie i wdrożenie kompleksowego rozwiązania NFC w technologii HCE, używając wyłącznie urządzeń z Androidem.

Android 4.4 i nowsze obsługują emulację kart opartych na specyfikacji ISO/IEC 14443-4 (NFC-Forum) (zgodnie ze specyfikacją ISO/IEC 14443-4) oraz procesów z użyciem jednostek APDU (Application Protocol Data Unit) zgodnie ze specyfikacją ISO/IEC 7816-4. Android wymaga emulacji ISO-DEP tylko w technologii Nfc-A (ISO/IEC 14443-3 typu A). Obsługa technologii Nfc-B (ISO/IEC 14443-4 typu B) jest opcjonalna. Rysunek 3 przedstawia nakładanie się wszystkich tych specyfikacji.

Usługi HCE

Architektura HCE na Androidzie opiera się na komponentach Service Androida (nazywanych usługami HCE). Jedną z najważniejszych zalet usługi jest to, że może ona działać w tle, bez użycia interfejsu użytkownika. Przydaje się to w przypadku wielu aplikacji HCE, takich jak karty lojalnościowe lub transportowe, w przypadku których użytkownik nie powinien uruchamiać aplikacji. Zamiast tego dotknięcie urządzenia do czytnika NFC uruchamia odpowiednią usługę (o ile nie jest jeszcze uruchomiona) i wykona transakcję w tle. Oczywiście możesz włączyć w swojej usłudze dodatkowy interfejs (np. powiadomienia dla użytkowników).

Wybór usługi

Gdy użytkownik zbliży urządzenie do czytnika NFC, system Android musi wiedzieć, z którą usługą HCE ma się komunikować czytnik NFC. Specyfikacja ISO/IEC 7816-4 określa sposób wyboru aplikacji oparty na identyfikatorze aplikacji (AID). Identyfikator AID może mieć do 16 bajtów. Jeśli emulujesz karty używane w istniejącej infrastrukturze czytnika NFC, urządzenia AI, których szukają odbiorcy, są zwykle dobrze znane i zarejestrowane publicznie (np. identyfikatory AI dostępne w sieciach płatniczych, takich jak Visa i Mastercard).

Jeśli chcesz wdrożyć nową infrastrukturę czytnika dla swojej aplikacji, musisz zarejestrować własne identyfikatory AID. Procedura rejestracji identyfikatorów AID jest zdefiniowana w specyfikacji ISO/IEC 7816-5. W przypadku wdrażania aplikacji HCE na Androida zalecamy rejestrowanie identyfikatora AID w standardzie 7816-5, ponieważ pozwala to uniknąć kolizji z innymi aplikacjami.

Grupy AID

W niektórych przypadkach usługa HCE może wymagać zarejestrowania wielu identyfikatorów AID i ustawić jako domyślny moduł obsługi tych identyfikatorów w celu wdrożenia określonej aplikacji. Niektóre osoby z grupy AI, które przechodzą do innej usługi, nie są obsługiwane.

Lista przechowywanych identyfikatorów AID jest nazywana grupą AI. W przypadku wszystkich identyfikatorów AID w grupie AI Android gwarantuje jeden z tych warunków:

• Wszystkie identyfikatory AID w grupie są kierowane do tej usługi HCE.
• Żadne identyfikatory AID w grupie nie są kierowane do tej usługi HCE (na przykład dlatego, że użytkownik preferował inną usługę, która również zażądała co najmniej jednego identyfikatora AID w grupie).

Inaczej mówiąc, nie ma stanu, w którym niektóre identyfikatory AIID w grupie mogą być kierowane do jednej usługi HCE, a inne do drugiej.

Grupy i kategorie AID

Każdą grupę AID możesz powiązać z kategorią. Dzięki temu Android może grupować usługi HCE według kategorii, a użytkownik może ustawiać wartości domyślne na poziomie kategorii, a nie na poziomie AID. Nie wspominaj o AID w miejscach, w których widzą go użytkownicy – nie mają one znaczenia dla przeciętnego użytkownika.

Android 4.4 lub nowszy obsługuje 2 kategorie:

• CATEGORY_PAYMENT (obejmuje aplikacje do płatności zgodne ze standardami branżowymi)
• CATEGORY_OTHER (w przypadku wszystkich innych aplikacji HCE)

Uwaga: w danym momencie w systemie może być włączona tylko 1 grupa AID z kategorii CATEGORY_PAYMENT. Zazwyczaj jest to aplikacja, która rozumie najważniejsze protokoły płatności kartą kredytową i może zadziałać u każdego sprzedawcy.

W przypadku aplikacji płatniczych closed loop, które działają tylko u jednego sprzedawcy (np. kart ze środkami przedpłaconymi), użyj CATEGORY_OTHER. Grupy AID w tej kategorii mogą być zawsze aktywne i w razie potrzeby mogą mieć priorytet przez czytniki NFC podczas wyboru 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 funkcję FEATURE_NFC_HOST_CARD_EMULATION. Użyj tagu <uses-feature> w pliku manifestu aplikacji, aby zadeklarować, że korzysta ona z funkcji HCE i czy jest ona wymagana do działania.

Implementacja usługi

Android 4.4 i nowsze obejmują wygodną klasę Service, której możesz używać jako podstawy do implementacji usługi HCE: klasy HostApduService.

Pierwszym krokiem jest rozszerzenie HostApduService, jak widać na tym przykładowym kodzie:

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ć i zaimplementować. Jeden z nich, processCommandApdu(), jest wywoływany za każdym razem, gdy czytnik NFC wysyła jednostkę danych protokołu aplikacji (ang. Application Protocol Data Unit, APDU) do Twojej usługi. Urządzenia APDU są zdefiniowane w specyfikacji ISO/IEC 7816-4. Punkty APDU to pakiety na poziomie aplikacji wymieniane między czytnikiem NFC a usługą HCE. Ten protokół na poziomie aplikacji jest półdupleksowy: czytnik NFC wysyła polecenie APDU i oczekuje na wysłanie z powrotem APDU.

Uwaga: specyfikacja ISO/IEC 7816-4 definiuje również koncepcję wielu kanałów logicznych, które umożliwiają stosowanie wielu równoległych giełd APDU w osobnych kanałach logicznych. Implementacja HCE na Androidzie obsługuje jednak tylko 1 kanał logiczny, więc możliwe jest tylko jednowątkowe wymienianie APDU.

Jak już wspomnieliśmy, Android używa AID do określenia, z którą usługą HCE chce rozmawiać czytelnik. Zazwyczaj pierwszy APDU wysyłany do urządzenia przez czytnik NFC to APDU SELECT AID. Zawiera on identyfikator, z którym czytnik chce się komunikować. Android wyodrębnia ten identyfikator z APDU, przekształca go w usługę HCE, a następnie przekazuje ten APDU do tej usługi.

Możesz wysłać APDU odpowiedzi, zwracając bajty APDU odpowiedzi z processCommandApdu(). Ta metoda jest wywoływana w głównym wątku aplikacji, którego nie należy blokować. Jeśli nie możesz od razu obliczyć i zwrócić odpowiedzi APDU, ustaw wartość null. Następnie możesz wykonać niezbędną pracę w innym wątku i użyć metody sendResponseApdu() zdefiniowanej w klasie HostApduService, aby wysłać odpowiedź po zakończeniu.

Android przekazuje nowe APDU z czytnika do usługi, dopóki nie wydarzy się któraś z tych sytuacji:

• Czytnik NFC wysyła kolejny APDU SELECT AID, który system operacyjny łączy się z inną usługą.
• Połączenie NFC między czytnikiem NFC a urządzeniem jest uszkodzone.

W obu tych przypadkach implementacja onDeactivated() klasy jest wywoływana z argumentem wskazującym, która z tych sytuacji wystąpiła.

Jeśli korzystasz z istniejącej infrastruktury czytnika, musisz wdrożyć istniejący protokół na poziomie aplikacji, którego oczekują odbiorcy w Twojej usłudze HCE.

Jeśli wdrażasz nową infrastrukturę czytnika, którą również kontrolujesz, możesz zdefiniować własny protokół i sekwencję APDU. Postaraj się ograniczyć ilość APDU oraz rozmiar danych do wymiany: dzięki temu użytkownicy będą musieli trzymać urządzenie przy czytniku NFC tylko przez krótki czas. Rozsądna górna granica to około 1 KB danych, które zwykle można wymienić w ciągu 300 ms.

Deklaracja w pliku manifestu usługi i rejestracja AID

Usługę musisz zadeklarować w pliku manifestu w zwykły sposób, ale musisz też dodać do niej kilka dodatkowych elementów:

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

2. Aby poinformować platformę, których grup identyfikatorów AID żąda ta usługa, uwzględnij w deklaracji usługi tag SERVICE_META_DATA <meta-data>, który wskazuje zasób XML z dodatkowymi informacjami o usłudze HCE.

3. Ustaw atrybut android:exported na true i wymagaj uprawnienia android.permission.BIND_NFC_SERVICE w deklaracji usługi. Pierwszy zapewnia, że usługa może być powiązana z aplikacjami zewnętrznymi. Powoduje ona, że tylko aplikacje zewnętrzne, które mają uprawnienie android.permission.BIND_NFC_SERVICE, mogą tworzyć powiązania z Twoją usługą. Ponieważ android.permission.BIND_NFC_SERVICE to uprawnienie systemowe, w efekcie wymusza powiązanie z Twoją usługą tylko system operacyjny Android.

Oto przykład deklaracji w 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. Poniżej znajduje się przykład pliku z pojedynczą deklaracją grupy AID zawierającą 2 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> z łatwym w użyciu opisem usługi, który możesz wyświetlać w interfejsie aplikacji. Możesz użyć atrybutu requireDeviceUnlock, aby określić, że urządzenie jest odblokowane przed wywołaniem tej usługi w celu obsługi jednostek APDU.

<host-apdu-service> musi zawierać co najmniej 1 tag <aid-group>. Każdy tag <aid-group> musi:

• Zawiera atrybut android:description zawierający łatwy w użyciu opis grupy AID odpowiedni do wyświetlenia w interfejsie.
• Mieć atrybut android:category ustawiony w sposób wskazujący kategorię, do której należy grupa AID, np. stałe ciąg znaków zdefiniowane przez CATEGORY_PAYMENT lub CATEGORY_OTHER.
• Zawierają co najmniej 1 tag <aid-filter>, z których każdy zawiera jeden identyfikator AI. Podaj identyfikator AID w formacie szesnastkowym i upewnij się, że zawiera on parzystą liczbę znaków.

Aby aplikacja mogła zostać zarejestrowana jako usługa HCE, musi też mieć uprawnienie NFC.

Rozwiązanie konfliktu związanego z AID

Na jednym urządzeniu można zainstalować wiele komponentów HostApduService, a ten sam identyfikator AID może zostać zarejestrowany w więcej niż 1 usłudze. Android w różny sposób rozwiązuje konflikty AID w zależności od kategorii, do której należy ten identyfikator. Każda kategoria może mieć inne zasady rozwiązywania konfliktów.

W przypadku niektórych kategorii, takich jak płatności, użytkownik może wybrać usługę domyślną w ustawieniach Androida. W przypadku innych kategorii zasada może zawsze wskazywać użytkownikowi, którą usługę wywołać w przypadku konfliktu. Informacje o tym, jak wysyłać zapytania dotyczące zasad rozwiązywania konfliktów w określonej kategorii, znajdziesz w artykule getSelectionModeForCategory().

Sprawdzanie, czy dana usługa jest domyślna

Za pomocą interfejsu API isDefaultServiceForCategory() aplikacje mogą sprawdzić, czy ich usługa HCE jest usługą domyślną w określonej kategorii.

Jeśli Twoja usługa nie jest domyślna, możesz poprosić o ustawienie jej jako domyślnej, korzystając z metody ACTION_CHANGE_DEFAULT.

Aplikacje płatnicze

Android traktuje usługi HCE, które zadeklarowały grupę AID z kategorią płatności jako aplikacje do płatności. Android 4.4 i nowsze zawierają pozycję w menu Ustawienia najwyższego poziomu o nazwie Zbliż i zapłać, w której wymienione są wszystkie takie aplikacje do wykonywania płatności. W tym menu użytkownik może wybrać domyślną aplikację płatniczą, która ma być wywoływana po dotknięciu terminala płatniczego.

Wymagane zasoby dla aplikacji do obsługi płatności

Aby zwiększyć atrakcyjność wizualną użytkowników, aplikacje płatnicze HCE muszą mieć baner usługi.

Android 13 lub nowszy

Aby lepiej dopasować do domyślnej listy wyboru płatności w interfejsie ustawień, dopasuj wymagania dotyczące banera do kwadratowej ikony. Idealnie powinna być taka sama jak ikona programu uruchamiającego aplikacje. Ta korekta zapewnia większą spójność i czytelniejszy wygląd.

Android 12 i starsze

Ustaw rozmiar banera usługi na 260 x 96 dp, a następnie ustaw go w pliku XML metadanych, dodając do tagu <host-apdu-service> atrybut android:apduServiceBanner, 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>

Działanie wyłączenia i blokady ekranu

Działanie usług HCE różni się w zależności od wersji Androida na urządzeniu.

Android 12 lub nowszy

W aplikacjach kierowanych na Androida 12 (poziom interfejsu API 31) lub nowszego możesz włączyć płatności NFC bez włączonego ekranu urządzenia, ustawiając parametr requireDeviceScreenOn na false.

Android 10 lub nowszy

Urządzenia z Androidem 10 (poziom interfejsu API 29) lub nowszym obsługują bezpieczną komunikację NFC. Gdy ekran Bezpiecznego NFC jest włączony, wszystkie emulatory kart (aplikacje hosta i aplikacje zewnętrzne) są niedostępne, gdy ekran urządzenia jest wyłączony. Gdy zabezpieczona komunikacja NFC jest wyłączona, aplikacje spoza hosta są dostępne przy wyłączonym ekranie urządzenia. Obsługę bezpiecznej komunikacji NFC możesz sprawdzić, klikając isSecureNfcSupported().

Na urządzeniach z Androidem 10 lub nowszym ustawienie opcji android:requireDeviceUnlock na true jest stosowane tak samo jak na urządzeniach z Androidem 9 lub starszym, ale tylko wtedy, gdy Bezpieczne NFC jest wyłączone. Oznacza to, że usługi HCE nie mogą działać na ekranie blokady przy włączonym Bezpiecznym NFC, niezależnie od ustawienia android:requireDeviceUnlock.

Android 9 i starsze

Na urządzeniach z Androidem 9 (poziom interfejsu API 28) lub starszym kontroler NFC i procesor aplikacji są całkowicie wyłączone po wyłączeniu ekranu urządzenia. Usługi HCE nie działają przy wyłączonym ekranie.

Na Androidzie 9 i starszych usługi HCE mogą też działać z poziomu ekranu blokady. Kontroluje to jednak atrybut android:requireDeviceUnlock w tagu <host-apdu-service> usługi HCE. Domyślnie odblokowywanie urządzenia nie jest wymagane, a usługa jest wywoływana nawet wtedy, gdy urządzenie jest zablokowane.

Jeśli w usłudze HCE ustawisz wartość atrybutu android:requireDeviceUnlock na true, Android poprosi użytkownika o odblokowanie urządzenia w tych sytuacjach:

• użytkownik dotyka czytnika NFC.
• czytnik NFC wybierze identyfikator AID obsługiwany przez usługę.

Po odblokowaniu Android wyświetli okno z prośbą o ponowne dotknięcie urządzenia w celu sfinalizowania transakcji. Jest to konieczne, ponieważ użytkownik mógł odsunąć urządzenie od czytnika NFC w celu odblokowania.

Współistnienie z kartami bezpiecznych elementów

Ta sekcja jest przeznaczona dla programistów, którzy wdrożyli aplikację zależną od bezpiecznego elementu do emulacji karty. Implementacja HCE na Androidzie została zaprojektowana tak, aby działać równolegle z innymi metodami implementacji emulacji kart, w tym z używaniem bezpiecznych elementów.

Uwaga: Android nie oferuje interfejsów API służących do bezpośredniej komunikacji z samym bezpiecznym elementem.

Współistnienie to jest oparte na zasadzie routingu AID. Kontroler NFC przechowuje tabelę routingu, która składa się z (skończonej) listy reguł routingu. Każda reguła routingu zawiera identyfikator AID i miejsce docelowe. Miejscem docelowym może być procesor hosta, uruchomione aplikacje na Androida lub połączony bezpieczny element.

Gdy czytnik NFC wysyła APDU z urządzeniem SELECT AID, kontroler NFC go analizuje i sprawdza, czy identyfikatory AID są zgodne z jakimkolwiek AID w tabeli routingu. Jeśli jest zgodny, APDU i wszystkie powiązane z nim APDU są wysyłane do miejsca docelowego powiązanego z AID, dopóki nie otrzyma kolejnego APDU SELECT AID lub połączenie NFC zostanie uszkodzone.

Uwaga: standard ISO/IEC 7816-4 definiuje również dopasowanie częściowe, jednak urządzenia z Androidem HCE nie obsługują takich dopasowań.

Tę architekturę ilustruje Rysunek 4:

Rysunek 4. Android działający zarówno z bezpiecznymi elementami, jak i z emulacją karty hosta.

Kontroler NFC zwykle zawiera też domyślną trasę dla urządzeń APDU. Jeśli nie znajdziemy identyfikatora AI w tabeli routingu, używana jest trasa domyślna. To ustawienie może się różnić w zależności od urządzenia, ale urządzenia z Androidem muszą mieć pewność, że identyfikatory AID zarejestrowane przez aplikację będą prawidłowo kierowane do hosta.

Aplikacje na Androida, które implementują usługę HCE lub używają bezpiecznego elementu, nie muszą martwić się o konfigurowanie tabeli routingu – jest ona obsługiwana przez Androida. Android potrzebuje tylko informacji o tym, które identyfikatory AI są obsługiwane przez usługi HCE, a które za pomocą bezpiecznego elementu. Tabela routingu jest konfigurowana automatycznie na podstawie tego, które usługi są zainstalowane i które użytkownik skonfigurował zgodnie z preferencjami.

W sekcji poniżej wyjaśniamy, jak deklarować identyfikatory AID w przypadku aplikacji, które korzystają z bezpiecznego elementu na potrzeby emulacji karty.

Rejestracja AID dla zabezpieczenia urządzenia

Aplikacje używające bezpiecznego elementu do emulacji karty mogą zadeklarować w pliku manifestu usługę spoza hosta. Deklaracja takiej usługi jest prawie taka sama jak deklaracja usługi HCE. Wyjątki:

• Działanie używane w filtrze intencji musi być ustawione na SERVICE_INTERFACE.
• Atrybut nazwy metadanych musi mieć wartość 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>
  

Poniżej znajdziesz przykład odpowiedniego pliku apduservice.xml, który rejestruje 2 identyfikatory 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 spoza hosta, ponieważ procesor hosta nie uczestniczy w transakcji i dlatego nie może uniemożliwić bezpiecznemu elementowi realizowania transakcji, gdy urządzenie jest zablokowane.

Atrybut android:apduServiceBanner jest wymagany w przypadku usług zewnętrznych, które są aplikacjami płatniczymi i można je wybrać jako domyślną aplikację płatniczą.

Wywoływanie usług poza hostem

Android nigdy nie uruchamia się ani nie wiąże z usługą zadeklarowaną jako „poza hostem”, ponieważ rzeczywiste transakcje są wykonywane przez element bezpieczny, a nie przez usługę Androida. Deklaracja usługi pozwala jedynie aplikacjom rejestrować identyfikatory AID obecne w bezpiecznym elemencie.

HCE i bezpieczeństwo

Architektura HCE zapewnia jeden podstawowy element zabezpieczeń: ponieważ Twoja usługa jest chroniona przez uprawnienie systemowe BIND_NFC_SERVICE, tylko system operacyjny może powiązać się z Twoją usługą i się z nią komunikować. Dzięki temu każdy otrzymany APDU jest w rzeczywistości APDU otrzymanym z kontrolera NFC oraz że każdy odsyłany APDU trafia tylko do systemu operacyjnego, który z kolei przekazuje je bezpośrednio do kontrolera NFC.

Ostatni problem dotyczy miejsca, z którego otrzymujesz dane, które aplikacja wysyła do czytnika NFC. Ta wartość jest celowo odłączona w konstrukcji HCE. Nie ma znaczenia, skąd pochodzą dane, ale istotne jest, aby bezpiecznie przenieść je do kontrolera NFC i do czytnika NFC.

Aby bezpiecznie przechowywać i pobierać dane, które chcesz wysyłać z usługi HCE, możesz na przykład użyć piaskownicy aplikacji na Androida, która izoluje dane aplikacji od innych aplikacji. Więcej informacji o zabezpieczeniach Androida znajdziesz w artykule Wskazówki dotyczące bezpieczeństwa.

Parametry i szczegóły protokołu

Ta sekcja jest przeznaczona dla programistów, którzy chcą się dowiedzieć, jakich parametrów protokołów używają urządzenia HCE na etapie zapobiegania kolizji i aktywacji protokołów NFC. Pozwala to zbudować infrastrukturę czytnika zgodną z urządzeniami Android HCE.

Protokół Nfc-A (ISO/IEC 14443 typu A) chroniący przed kolizjami i aktywacją

W ramach aktywacji protokołu Nfc-A wymienianych jest wiele klatek.

W pierwszej części wymiany urządzenie HCE prezentuje swój identyfikator UID, a urządzenia HCE należy przyjąć, że mają losowy identyfikator UID. Oznacza to, że przy każdym kliknięciu identyfikator UID wyświetlany czytelnikowi jest losowo wygenerowanym identyfikatorem UID. Z tego powodu czytniki NFC nie powinny polegać na identyfikatorze UID urządzeń HCE jako metody uwierzytelniania lub identyfikacji.

Czytnik NFC może następnie wybrać urządzenie HCE, wysyłając polecenie SEL_REQ. Odpowiedź SEL_RES urządzenia HCE ma co najmniej ustawiony poziom 6-bitowy (0x20), co oznacza, że urządzenie obsługuje ISO-DEP. Pamiętaj, że w SEL_RES można też ustawić inne bity, co wskazuje na przykład obsługę protokołu NFC-DEP (p2p). Można ustawić inne bity, więc czytelnicy, którzy chcą wejść w interakcję z urządzeniami HCE, powinni wyraźnie sprawdzać tylko 6 bit i nie porównywać pełnej wartości SEL_RES z wartością 0 x 20.

Aktywacja ISO-DEP

Po aktywowaniu protokołu Nfc-A czytnik NFC inicjuje aktywację protokołu ISO-DEP. Wysyła polecenie RATS (Request for Answer To Select). Kontroler NFC generuje odpowiedź RATS, czyli ATS. Usługi HCE nie mogą konfigurować tego kontrolera. Jednak implementacje HCE muszą spełniać wymagania forum NFC dotyczące odpowiedzi ATS, aby czytniki NFC mogły liczyć na te parametry zostały ustawione zgodnie z wymaganiami platformy NFC dla dowolnego urządzenia HCE.

W sekcji poniżej znajdziesz więcej informacji na temat poszczególnych bajtów odpowiedzi ATS dostarczanych przez kontroler NFC na urządzeniu HCE:

• TL: długość odpowiedzi ATS. Nie może przekraczać 20 bajtów.
• T0: bity 5, 6 i 7 muszą być ustawione na wszystkich urządzeniach HCE, co oznacza, że odpowiedź ATS zawiera klucze TA(1), TB(1) i TC(1). Bity od 1 do 4 wskazują FSCI, kodując maksymalny rozmiar klatki. W przypadku urządzeń HCE wartość FSCI musi mieścić się w przedziale od 0 do 8 godz.
• T(A)1: określa szybkość transmisji bitów między czytnikiem a emulatorem oraz określa, czy mogą być one asymetryczne. W przypadku urządzeń HCE nie ma żadnych gwarancji i wymagań dotyczących szybkości transmisji bitów.
• T(B)1: bity od 1 do 4 wskazują wartość całkowitą SFGI (Start-up Frame Guard Time Integer). W przypadku urządzeń HCE wartość SFGI musi wynosić mniej niż 8 godz. Bity od 5 do 8 wskazują liczbę całkowitą liczby klatek (FWI) i czas oczekiwania klatki (FWT). W przypadku urządzeń HCE wartość FWI musi wynosić mniej niż 8 godzin.
• T(C)1: bit 5 oznacza obsługę „zaawansowanych funkcji protokołu”. Urządzenia HCE mogą, ale nie muszą obsługiwać „zaawansowanych funkcji protokołu”. Bit 2 oznacza obsługę DID. Urządzenia HCE mogą, ale nie muszą obsługiwać DID. Bit 1 oznacza obsługę NAD. Urządzenia HCE nie mogą obsługiwać NAD i ustawiać bit 1 na 0.
• Bajty historyczne: urządzenia HCE mogą zwrócić do 15 bajtów historycznych. Czytniki NFC gotowe do interakcji z usługami HCE nie powinny podejmować żadnych założeń dotyczących zawartości historycznych bajtów ani ich obecności.

Wiele urządzeń HCE jest prawdopodobnie zgodnych z wymaganiami protokołów, które sieci płatności zjednoczone w EMVCo określiły w specyfikacji „Contactless Communication Protocol”. W szczególności:

• Wartość FSCI w T0 musi mieścić się w przedziale od 2 godzin do 8 godzin.
• T(A)1 musi mieć wartość 0 x 80, co oznacza, że obsługiwana jest tylko szybkość transmisji bitów 106 kb/s, a asymetryczne szybkości transmisji między czytnikiem a emulatorem nie są obsługiwane.
• FWI w T(B)1 musi mieć wartość <= 7h.

Wymiana danych APDU

Jak już wspomnieliśmy, implementacje HCE obsługują tylko jeden kanał logiczny. Próba wyboru aplikacji w różnych kanałach logicznych nie działa na urządzeniu HCE.