Cały proces inicjalizacji oraz wymiany danych opiera się o działanie dwóch maszyn stanów: jednej po stronie czytnika i drugiej po stronie karty identyfikacyjnej. Grafy stanów i przejść dla obydwu maszyn stanów przedstawia rys. 4. Do konkretnego protokołu komunikacyjnego wrócimy jeszcze, teraz należy zrozumieć, czym jest tajemnicza odpowiedź na sygnał zerowania ATR oraz w jaki sposób są kodowane przesyłane bajty.

Standard nie określa, czy interpretacja logiczna potencjału linii danych ma być prosta, czy odwrotna. Oznacza to, że poziom wysoki na linii I/O może być zinterpretowany jako logiczne 0 lub logiczna 1. To, w jaki sposób przebiega interpretacja zależy od karty, a informację na ten temat zawiera w sobie pierwszy z bajtów sekwencji Answer to Reset – bajt TS. Różne możliwości interpretacji poziomów logicznych są też ściśle związane z kolejnością pojawiania się bitów na linii danych.

Jeśli wybrane jest kodowanie proste, czyli logiczna 1 odpowiada linii I/O w stanie wysokim, to wtedy pierwszy wysyłany będzie bit najmniej znaczący (LSB). W interpretacji odwrotnej, czyli takiej, w której potencjał wysoki będzie oznaczał logiczne 0, na linię danych wystawiany jest jako pierwszy najbardziej znaczący bit (MSB).

Każdy bajt jest rozpoczynany przez znacznik START, a kończy się bitem parzystości, pozwalającym zweryfikować, czy odebrany bajt nie został przekłamany podczas transmisji. Zawartość odebranego bajta jest uznawana za poprawną wtedy, gdy wraz z bitem parzystości ilość logicznych jedynek będzie parzysta.

Ramka odpowiedzi na sygnał zerowania ATR może być zbudowana maksymalnie z 33 bajtów podzielonych na pięć grup:

• znak inicjalizujący TS – jak wyżej wspomniano, niesie ze sobą informację o sposobie kodowania bitów oraz kolejności ich wysyłania,
• znacznik T0 – informuje, czy ramka Answer to Reset zawiera opcjonalne znaki (będące zaszłością historyczną),
• bajty niosące informację o szczegółach implementacji interfejsu,
• bajty o znaczeniu historycznym, mogą zawierać informacje dodatkowe, specyficzne dla danej aplikacji ( ich format nie jest definiowany w żaden sposób przez standard),
• bajt kontrolny.

Protokół komunikacyjny

Dane przesyłane podczas komunikacji z kartą identyfikacyjną są dzielone na pakiety ADPU (z ang. Application Protocol Data Units). Można rozdzielić dwie grupy pakietów ADPU: pakiety komend wysyłane do karty, oraz pakiety odpowiedzi wysyłane przez kartę do czytnika.

Pakiety komend wysyłane do karty składają się z nagłówka oraz pozostałej części nazwanej ciałem (z ang. body). Budowa pakietu danych, wysyłana do karty został przedstawiona na rys. 5. Popularnym, a więc i często wykorzystywanym, jest protokół ‘T0’. W tym protokole jednostki informacji nazwane zostały TDPU (z ang. Transmission Protocol Data Units). Pakiety ADPU są w tym przypadku identyczne w budowie z TDPU, dzięki czemu warstwy nie są dodatkowo komplikowane i możemy omówić tylko pakiety ADPU, ponieważ w przykładowa aplikacja będzie operować właśnie na nich.

Rys. 5. Budowa pakietu komendy ADPU

Nagłówek komendy ADPU zawiera cztery pola, które pozwalają określić między innymi, jaka komenda ma zostać wykonana. Poszczególne pola nagłówka to:

• CLA – Pole określające klasę komendy. Przykładowo wartość szesnastkowa 0y, gdzie y jest dowolne z przedziału 0h do Fh, oznacza, że przesyłana komenda będzie dotyczyć operacji na plikach lub będzie wykorzystywać system zabezpieczeń.
• INS – Pole klasyfikuje, jaka dokładnie komenda jest wysyłana. Jeśli klasą komendy są operacje na plikach, wówczas wartości bajta INS oznaczają akcję, jaka ma być podjęta w systemie plików
• P1, P2 – Zawierają dodatkowe informacje potrzebne do wykonania instrukcji określonej przez pola CLA oraz INS. Jeśliby przytoczyć tutaj konkretny przykład w postaci funkcji wykonujących operacje na systemie plików karty, to pola P1 oraz P2 mogą definiować, w jaki sposób ma być uzyskany dostęp do pliku.

Ciało komendy APDU składa się z trzech pól: Lc, Data field oraz Le. Pole Lc określa z ilu bajtów składa się pole danych (z ang. Data field), natomiast pole Le mówi o tym, ilu bajtów czytnik spodziewa się od karty identyfikacyjnej w odpowiedzi na wysłaną komendę.

Wszystkie trzy pola są opcjonalne. Oznacza to, że jeśli komenda nie wymaga przesłania do karty dodatkowych danych oraz nie spodziewa się żadnej odpowiedzi, to cały pakiet ADPU będzie się składał jedynie z nagłówka. Druga możliwość wystąpi wtedy, kiedy dane są przesyłane do karty (pola Lc oraz Data field są zawarte w pakiecie), ale czytnik nie oczekuje odpowiedzi, czyli ciało komendy nie będzie zawierać pola Le. Ostatnia wariacja ma miejsce, gdy żadne dane nie są przesyłane do karty identyfikacyjnej wraz z komendą (brak pól Lc i Data field), ale oczekiwana jest odpowiedź ze strony karty, czyli ciało komendy składa się tylko z pola Le. Wszystkie trzy przypadki zilustrowane zostały na rys. 6.

Rys. 6. Różne postacie ciała komendy ADPU

Pakiet odpowiedzi na komendę również jest podzielony na dwie części, pierwsza to ciało (body), które jest w całości polem danych, natomiast na drugą (tzw. Trailer) składają się dwa pola SW1 i SW2. Ostatnie pola mogą zawierać informację przykładowo o klasie błędu oraz jego konkretny kod.

Wiemy już, jak są zbudowane podstawowe jednostki wymiany informacji pomiędzy kartą identyfikacyjną, a czytnikiem, warto się teraz lepiej przyjrzeć, jak właściwie wygląda komunikacja z wykorzystaniem interfejsu Smart Card. Na rys. 7 przedstawiono diagram ilustrujący przepływ danych i poszczególne elementy interfejsu Smart Card. Aplikacja używa pakietów ADPU, które są przez warstwę łącza danych tłumaczone na pakiety TDPU. Te po stronie mikroprocesora karty identyfikacyjnej są z powrotem kodowane do postaci ADPU, by następnie mogły zostać wykonane żądane operacje w systemie plików karty.

Rys. 7. Elementy łańcucha komunikacji z kartą Smart Card