2015-07-04 12 views
9

Istnieją różne karty inteligentne obsługujące ISO 14443-4. Na przykład Mifare Plus z natywnym zestawem poleceń. Lub inne karty z różnymi zestawami poleceń (tj. 7816-4 APDU).Jak odróżnić różne karty ISO 14443-4?

Zajmuję się tworzeniem oprogramowania dla czytnika kart i muszę określić, które polecenia obsługuje karta (na przykład, czy obsługuje polecenia w strukturze ISO 7816-4, czy nie).

Jaki jest zalecany sposób ich rozróżnienia? Czy powinienem po prostu wypróbować niektóre polecenia z zestawu poleceń Mifare Plus i sprawdzić, czy otrzymam poprawne odpowiedzi? Czy jest jakiś mądrzejszy sposób to zrobić?

Odpowiedz

8

Podczas protokołu połączenia wymieniane są niektóre parametry, które można wykorzystać do określenia możliwości karty. Na przykład bajt SAK poinformuje czytelnika, czy karta ma numer ISO 14443-4, a nawet jeśli jest to MIFARE Plus (istnieje dokument NXP wyjaśniający, które z bitów należy przeczytać). Następnie masz ATS (Answer To Select), który zawiera wiele przydatnych informacji o karcie. Spójrz na ISO 14443-4 i ISO 7816-4.

+1

Tak, wiem o tym, ale ATS można zmienić w kartach Mifare Plus, więc nie jest on w 100% niezawodny. I podejrzewam, że mogą istnieć inne karty (nie rodzina Mifare), które mają to samo SAK. NXP zaleca, aby ocenić tylko bit 6 SAK, aby sprawdzić, czy karta obsługuje standard ISO 14443-4 i zignorować inne bity. –

+1

Prawdopodobnie najlepszym sposobem działania będzie wdrożenie "pragmatycznego" podejścia: najpierw używaj SAK i ATS (aby pokryć większość kart) oraz kilka poleceń testowych dla przypadków narożnych. Czy oprogramowanie czytnika musi obsługiwać wszystkie ogólne karty Mifare Plus lub tylko spersonalizowane dla określonej aplikacji lub usługi? – mictter

+0

Myślę, że wystarczy obsłużyć spersonalizowane i nowe puste karty do personalizacji. –

2

Nigdy nie używaj ATQ! Używaj SAK tylko dla kart innych niż 14443-4 (np. Mifare Classic)! ATS to także zła praktyka, ponieważ inny sprzedawca kart może ustawić to inaczej.

Teraz jak to zrobić:

Jedyny sposób, jak myśleć o karcie i nie dostać szału to sobie wyobrazić, jak to jest pełny stos komunikacyjny (patrz modelu OSI).

Należy pamiętać, że celem jest połączenie dwóch aplikacji, jednej na karcie i jednej w komputerze. 14443-4 zapewnia mechanizm wysyłania wiadomości i nie przejmuje się jego zawartością.

Na wierzchu są zaimplementowane interfejsy różnych kart i jeśli obie strony: karta - Carddriver są kompatybilne, będą się komunikować. Jeśli nie, pojawią się błędy na tym poziomie. Więc wiesz, że będziesz musiał użyć innego sterownika karty.

pełna komunikacja stos będzie wyglądać następująco:

Your Application 
    | CardProtocol/7816-4 
    | | 14443-4 
    | | | 14443 
    | | | | radio waves 
    | | | 14443 (in card) 
    | | 14443-4 (in card) 
    | CardProtocol/7816-4 (in card) 
    Application/Appdata (in card) 

Oczywiście od każdej warstwy musi być jakiś interfejs.

Jeśli masz dwie aplikacje, które chcą się komunikować, wypróbuj jedną, a następnie spróbuj sekund.

błąd na poziomie aplikacji => nie jest kompatybilny aplikacji na karcie

błąd na poziomie CardProtocol => nie jest kompatybilna karta

Point jest twoja komunikacja musi succed na wszystkich poziomach tak nie martwić się próbą komunikowania się z kartą przez niezgodny protokół - jeśli (przez jakiś cud) nie dostaniesz błędu na poziomie CardProtocol, na pewno dostaniesz go na poziomie aplikacji, a wynik będzie taki sam. Powodzenia!

P.S. Istnieją bardziej złożone sytuacje, takie jak "jedna aplikacja na dwa protokoły/typy kart", ale można je łatwo obsługiwać.

Powiązane problemy