Skrót dla osób odciętych od świata: Portal wykop.pl ustawił serwer testowy nowej wersji serwisu w taki sposób, że był on dostępny z Internetu. Testowy serwer bazy danych został wypełniony prawdziwymi danymi z produkcyjnej wersji wykopu i niezabezpieczony żadnym hasłem. Po kilku tygodniach od zdarzenia (szantaż ze strony nieznanego sprawcy) odkrył to użytkownik gimbus1xD, który opublikował informacje na ten temat na samym wykopie. Błędy techniczne popełnione na wykopie zostały już wymienione na innych blogach i portalach, błędy PRowe w komentarzach pod oficjalnym wpisem i oficjalną przemową. Na razie cicho jest w sprawie odpowiedzialności za ewentualne szkody.

Jedyną metodą postępowania w sprawie szkód wynikłych z opublikowania danych, która przychodzi mi na myśl, są indywidualne pozwy cywilne. Pytania o inny sposób załatwiania tego typu spraw pozostają bez odpowiedzi. Do tego polskie prawo nie sprzyja poszukiwaniom osoby odpowiedzialnej za taki stan rzeczy, a nawet ją chroni (vide art.267 ust.2 kodeksu karnego). Karnie odpowiada nie administrator, który poprzez zaniedbanie opublikował dane swoich użytkowników, ale niecny “hakier”, który na tę publikację trafił. Nie ma też obowiązku informowania użytkowników o tym, że ich dane wyciekły, a szybkie poinformowanie użytkowników mogłoby zapobiec wykorzystaniu ich danych. Brakuje w tym wszystkim równowagi pomiędzy odpowiedzialnością użytkownika, a odpowiedzialnością zarządcy systemu informatycznego.

W sieci zaczęły już pojawiać się komentarze mówiące, że przecież każdemu mogło się to zdarzyć, nikt nie jest nieomylny. W branży informatycznej, a konkretniej w webdesignie istnieje jednak zbiór dobrych praktyk, które często okazują się wiedzą tajemną. Te dobre praktyki nie są jakimiś nieżyciowymi wymaganiami o stosowaniu drutu kolczastego w serwerowni, ale prostymi regułami do których należy się stosować, jeżeli nasz serwis przyjmuje dane z zewnątrz (sprawdzaj każdy input, najlepiej przy pomocy gotowych mechanizmów) lub ma przechowywać hasła (hashuj hasła z tzw. solą, możliwie długą – tu pozdrowienia dla Allegro). Usprawiedliwianie administratorów, że “tak dużego portalu nie da się w 100% zabezpieczyć” przy tego typu zaniedbaniach jest równie trafne, co stwierdzenie, że malowanie pojazdów wojskowych w jaskrawożółte i czerwone naprzemienne pasy to nic złego, bo i tak nie można ich uczynić w 100% niewidzialnymi.

Na razie użytkownikom portali pozostaje tylko siedzieć cicho i mieć nadzieję, że w ulubionych portalach pracują ludzie, którzy wiedzą co robią. Niestety prawo nie daje możliwości wyciągnięcia szybkich i automatycznych (bez siedzenia w sądzie przez kilka lat) konsekwencji wobec administratora serwisu internetowego. Może czas zacząć bezwzględnie wymagać rozsądku od użytkowników Internetu?

Niedawno kupiłem nowy czytnik do kart chipowych. Szukałem czegoś do laptopa (interfejs ExpressCard), znalazłem nowy czytnik za około 100PLN i jestem z niego zadowolony. Czytnik jest zgodny z CCID, w związku z tym działa pod Linuxem (było to dla mnie kluczowe), przedstawia się jako urządzenie USB (wbudowany host USB na ExpressCard).

Dodatkowym atutem tego czytnika jest to, że nie wystaje poza obudowę laptopa. Co oznacza, że nie muszę go demontować na czas transportu komputera. Obecnie dostępnych jest jeszcze 9 czytników i całkiem możliwe, że nie zostaną sprzedane do końca aukcji.

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)

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 0×3F00, oznaczony jako MF (Master File). Oprócz tego zarezerwowane są adresy 0×3F00 (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.