Co można znaleźć w plikach?

W pliku z danymi (w tym artykule nazwany „dane.bin”, zrzucany za pomocą polecenia „./elsr > dane.bin”) można znaleźć imiona i nazwisko studenta, numer albumu, kod serii albumów, nazwę uczelni, PESEL oraz datę ważności legitymacji. Dodatkowo znajduje się tam numer seryjny układu karty (do weryfikacji czy dane znajdują się na oryginalnym nośniku) oraz wersja formatu pliku (na razie istnieje tylko wersja 1). Oczywiście wszystkie powyższe dane są otoczone strukturą podpisu elektronicznego, o czym później.
W pliku z certyfikatem (u mnie nazwany „cert.bin”, zrzucany poleceniem „./elsr cert > cert.bin”) znajduje się certyfikat, którego użyto do podpisania pliku z danymi. Wystawiony jest na pracownika uczelni odpowiedzialnego za podpisywanie legitymacji (wśród danych opisujących posiadacza certyfikatu oprócz imienia i nazwiska, znajduje się numer PESEL, nazwa uczelni, adres e-mail). Według informacji na mojej legitymacji „Certyfikat powstał w oparciu o Polityki PCCE dla Certyfikatów Kwalifikowanych. Treść Polityki oraz Regulamin PCCE znajduje się pod adresem http://www.sigillum.pl/repozytorium CPS: http://www.sigillum.pl/PolitykaCA.htm”.

Jak wyciągnąć czyste dane?

W danych zakodowanych przy pomocy Distinguished Encoding Rules, zgodne z Basic Encoding Rules w przypadku odczytu (Uwaga! BER są ogólniejsze od DER – dopuszczają kilka rzeczy niedostępnych w DER) opisanych w rekomendacji ITU-T X.690. Sam podpis jest zgodny z formatem PKCS7 (stosowany w tzw. „bezpiecznej poczcie” SMIME oraz przez naszych dostawców „kwalifikowanego podpisu elektronicznego”).
Zawartość pliku dane.bin jak i cert.bin można przeglądać w formie czytelnej dla ludzi za pomocą komendy „openssl asn1parse -inform DER -in nazwapliku -i” spowoduje to wyświetlenie wszystkich struktur zapisanych za pomocą DER wraz z wcięciami porządkującymi układ dokumentu.
Typy obiektów możemy określić po Object ID (OID). Obiekty znanych typów pakuje się w sekwencję, w której pierwszym elementem jest OID, a następnie zawartość obiektu. W przypadku danych ELS OID=1.2.616.1.101.4.1.1. Niestety dane nie są kontynuacją w hierarchii, a elementem OCTET STRING (ciąg bajtów) zawierającym ciąg danych zakodowanych przy pomocy BER (tym razem już dane zgodnie z opisem w rozporządzeniu).

Co z certyfikatem i weryfikacją?

Certyfikat w pliku cert.bin, jest zwykłym plikiem zgodnym z PKCS1 (w przypadku mojej legitymacji kluczem publicznym do szyfrowania/podpisywania SHA1 z RSA wydanym przez Sigillum). Wszystko oczywiście w formacie DER. Niestety nie udało mi się jeszcze skompletować weryfikowalnego łańcucha certyfikatów od certyfikatu CA Sigillum do certyfikatu osoby podpisującej ELS. Prace trwają, ale niestety nie są priorytetem (minus bezdochodowego hobby).

Oprogramowanie

Program elsextractor.py wyciągnie dane z pliku dane.bin i przepisze je do wygodnego w użyciu słownika. Kod nie jest jeszcze dopasowany i nie wyszukuje obiektów po OID, tylko polega na stałej lokalizacji obiektu w hierarchii PKCS7 (oczywiście zostanie to poprawione w przyszłych wersjach). Do tego stosuje niezbyt uniwersalny sposób wczytywania danych (ze względu na uproszczenie kodu).

Epilog?

Artykuł ten znajduje się w fazie beta, ale postanowiłem go opublikować, po tym jak przeleżał w tym stanie pół roku. Zainteresowanie odczytywaniem ELSki wzrosło, a te kilka uwag i kod do rozbijania DER na obiekty może się komuś przydać. Dokończenie przewiduję w bliżej nieokreślonej przyszłości po obronie pracy magisterskiej (2009).

Załączniki

ELS Extractor (tar.gz)

Podziel się wpisem

Co to jest ELS?

ELS, czyli Elektroniczna Legitymacja Studencka jest kartą chipową zawierającą informacje o studencie podpisane kwalifikowanym podpisem elektronicznym przez wydawcę. Dokładne informacje na temat wyglądu nośnika jak i zawartości można znaleźć w odpowiednim rozporządzeniu. O samej legitymacji i przygodach związanych z jej wdrażaniem można przeczytać na stronie VaGli:

• ELS: w jedności, neutralności i kompatybilności siła – VaGla o dodatkowej funkcjonalności ELS w Warszawie
• Rozmiękczanie plastiku czyli komu bije ELS – Tomasz Kokowski, osoba odpowiedzialna za wdrożenie ELS w Poznaniu i nie tylko, o tym, jakie trudności napotkano podczas pierwszego przetargu (w odpowiedzi na artykuł w Rzeczypospolitej)
• Jaka karta ELS? – Jacek Biskupski, opinia vice prezesa jednej z firm dystrybuujących karty i startujących w przetargu, polecam szczególnie dyskusję w komentarzach.
• Komu bije ELS v2.0 – Tomasz Kokowski, co jeszcze można było (można by) zrobić przy okazji wdrażania ELS

Karta powinna być zgodna ze standardem ISO 7816, a dane na niej zawarte powinny być zapisane w formacie ASN.1 Basic Encoding Rules zgodnie ze specyfikacją w załączniku nr 3 do rozporządzenia. Nie znalazłem szczegółowych informacji na temat interfejsu bezstykowego, ale z wiarygodnego źródła wiem, że ELSki wyposażone w interfejs Mifare pozwalają na odczytanie danych związanych z legitymacją (imię, nazwisko, nr albumu, PESEL) każdemu bez żadnego uwierzytelniania. Nie mam jeszcze sprzętu do czytania kart RFID 13,56MHz (w tym Mifare), ale w najbliższym czasie powinienem mieć dostęp do odpowiednich czytników.

Sprzęt

Do zabaw z kartami chipowymi używam bardzo starego czytnika do kart stykowych Schlumberger Reflex USB, który nabyłem okazyjnie na allegro. PCSC-lite pozwala mi rozmawiać z tym sprzętem na odpowiednio wysokim poziomie i do tego ma API niemal identyczne z Windowsowym PCSC (łatwiej będzie przeportować).

Zawartość karty

Pierwsza wersja programu odczytującego służyła do skanowania karty w poszukiwaniu wybieralnych plików. Dane na każdej karcie stykowej zgodnej z ISO 7816 są ułożone w strukturę drzewiastą. Odpowiednikami katalogów są pliki DF (Dedicated File – czasami nazywane Directory File), rolę plików zwykłych pełnią pliki EF (Elementary File), każdy plik ma 2 bajtowy adres. Korzeniem drzewa jest plik 0x3F00, oznaczony jako MF (Master File). Oprócz tego zarezerwowane są adresy 0x3F00 (obecny katalog, odpowiednik ‘.’) i 0xFFFF. Wszystkie DFy dostępne z MF muszą być zarejestrowane (aby uniknąć kolizji w przypadku więcej niż jednej aplikacji na jednej karcie) i szczerze mówiąc nie wiem gdzie znaleźć ich spis (najprawdopodobniej jest dostępny za drobną opłatą u podmiotu rejestrującego).

Przeskanowanie ujawniło następujące pliki DF:

• 0×0101 (DF.SELS) – Elektroniczna Legitymacja Studencka
  • 0×0001 TRANSPARENT (EF.CERT) – kwalifikowany certyfikat emitenta
  • 0×0002 TRANSPARENT (EF.ELS) – plik z danymi legitymacji + podpis
• 0×5011 DF – nieznany
  • 0×8001
  • 0×8002
  • 0×8003
  • 0×8004 hic sunt dracones
  • 0×8005
  • 0×8006
  • 0×8007

Skanowanie wszystkich 65535 możliwości trwało około 4h. Jeżeli chodzi o DF 0×5011 jest on najprawdopodobniej interfejsem do wgrywania aplikacji na kartę.

Wyjaśnienie kodu programu

Nie będę tutaj opisywać inicjalizacji komunikacji z kartą, szczegóły można znaleźć w dokumentacji ISO. Kod załączony do artykułu wywołuje wszystkie funkcje potrzebne do połączenia i pracy z kartą przez interfejs PCSC. Pozwala też na łatwą modyfikację i automatyzację niektórych działań (licencja GNU GPLv3).

Ogólna struktura komend wysyłanych do karty chipowej ma następującą postać (kolejne bajty numerowane od 0):

gdzie CLA to klasa komend (przyjąłem 0×00 – patrz ISO 7816-4 5.4.1), INS to bajt wskazujący instrukcję, a P1 i P2 to dwa parametry komendy. W przypadku, gdy komenda wymaga wysłania więcej niż dwóch bajtów danych (np. zapis do pliku) stosuje się pola opcjonalne, z których pierwszy bajt opisuje długość, a pozostałe zawierają konkretne dane. Ostatnim polem jest Le, które najczęściej podaje liczbę bajtów jaką jest w stanie przyjąć nasz czytnik kart.

Aby odczytać zawartość pliku na karcie, musimy go najpierw wybrać przy pomocy komendy SELECT FILE (0xA4), która przyjmuje 2 parametry określające sposób wyboru pliku (my wybieramy na podstawie identyfikatora i nie interesuje nas na razie jakie informacje zwróci komenda – P1 = 0×00 i P2 = 0×00). Następnie podajemy długość danych (0×02) i same dane, czyli identyfikator pliku (np. 0×0101), bajt Le zostawiamy pusty (nie wysyłamy go).

Po wybraniu odpowiedniego pliku odczytujemy jego zawartość za pomocą komendy READ BINARY (0xB0), która przyjmuje przesunięcie danych w pliku jako jeden parametr zajmujący P1 i P2 (2 bajty), a bajt Le wskazuje liczbę danych jakie jesteśmy w stanie przetworzyć.

Jeżeli kod nadal nie jest czytelny proszę o kontakt. Zaznaczam jednak, że nie udzielam lekcji z podstaw programowania w języku C, ani nie zajmuję się tłumaczeniami standardów ISO na polski . W następnym artykule na temat ELS postaram się opisać strukturę samego pliku danych i certyfikatu oraz zaprezentować weryfikację podpisu legitymacji.

Uaktualnienie

Jak się okazuje same dwubajtowe identyfikatory plików (FID) nie muszą być globalnie takie same. Poniższą, uniwersalną metodę selekcji DF.SELS przesłał Krzysztof Rutecki z Wrocławia, za co serdecznie dziękuję. Preferowanym sposobem wyboru DF.SELS (najprawdopodobniej także DFów innych aplikacji) jest AID (Application ID), który to właśnie znajduje się w odpowiednim załączniku do piątej części ISO7816 i jest zarezerwowany tylko dla danej aplikacji. Pełna komenda wybierająca DF.SELS przez AID znajduje się w funkcji „selectDfselsByAID” nowego kodu źródłowego. Jest to zwykły SELECT FILE, tyle że P1=0×04, a P2=0×00, później znajdziemy długość AIDu w bajtach i sam AID. Ten sposób powinien zagwarantować zgodność oprogramowania z legitymacjami innymi niż te z Poznania.

Linki

Załącznik do artykułu: els_reader.tar.gz

Łukasz Kulasek napisał klasę w Javie służącą do odczytywania zawartości ELS.