materiały konferencyjne - Międzyuczelniane Centrum Personalizacji

Transkrypt

Sponsor główny konferencji
Międzyuc
Legityma
Międzyuczelniane Centrum Personalizacji
Legitymacji Studenckiej
I Krajowa Konferencja
Użytkowników Systemów
Elektronicznej Legitymacji Studenckiej
z warsztatami
12 czerwca 2008 r.
Centrum Wykładowo Konferencyjne Politechniki Poznańskiej,
60-965 POZNAŃ, ul. Piotrowo 2
O MCPLS słów kilka
Międzyuczelniane Centrum Personalizacji Legitymacji Studenckiej (MCPLS) jest jednostką organizacyjną Politechniki Poznańskiej, powołaną w 2005 roku przez siedem poznańskich uczelni publicznych,
w celu koordynowania wprowadzenia do obiegu elektronicznej legitymacji studenckiej.
Do podstawowego zadania MCPLS należy personalizacja graficzna i elektroniczna legitymacji, czyli
nadanie karcie elektronicznej zewnętrznych indywidualnych cech jej użytkownika oraz zapisanie w układach elektronicznych danych dotyczących uczelni i studenta.
MCPLS znajduje się na terenie kampusu Politechniki „Wilda”. Personalizacja legitymacji odbywa się
w silnie strzeżonych systemami telewizji przemysłowej, sygnalizacji napadu i włamania oraz kontroli dostępu w pomieszczeniach wyposażonych w specjalistyczne drukarki oraz niezbędny sprzęt komputerowy, obsługiwany przez dwoje wykwalifikowanych pracowników.
KONFERENCJA IKKuSELS
Realizacja postawionego zadania jest możliwa dzięki korzystaniu ze stworzonego specjalnie w tym celu,
napisanego od podstaw przez pracowników Politechniki Poznańskiej, systemu zarządzania cyklem życia
karty. Dzięki zastosowanym rozwiązaniom unikalny w skali kraju system potrafi dopasować się do wymagającego, stosującego różne środowiska informatyczne użytkownika jakim są uczelnie wyższe. Z Systemu
Elektronicznej Legitymacji Studenckiej korzystają już nie tylko uczelnie zawiązujące porozumienie. MCP
w krótkim czasie stało się centrum personalizacji o zasięgu wojewódzkim. Politechnika Poznańska umożliwiła
także utworzenie odrębnego centrum personalizacji działającego w oparciu o stworzone oprogramowanie.
MCPLS obsługuje 14 uczelni, spersonalizowało prawie sto tysięcy elektronicznych legitymacji studenckich, oraz udzieliło jednej licencji na oprogramowanie umożliwiając tym samym stworzenie uczelni
jej własnego centrum. MCPLS umożliwia personalizację do 1500 legitymacji dziennie co odpowiada aktualnemu zapotrzebowaniu oraz prognozie potrzeb w tym zakresie na najbliższe lata.
MCPLS postawiło bardzo wysoko poprzeczkę technologiczną. W centrum personalizowane są nowoczesne karty elektroniczne o ogromnych możliwościach, począwszy od identyfikacji, poprzez kontrolę
dostępu, bilet komunikacji miejskiej, a skończywszy na nośniku podpisu kwalifikowanego. Użyte drukarki wykorzystują najnowsze rozwiązania druku oparte o technologię termosublimacyjną retransferową.
MCPLS cały czas koordynuje tworzenie nowych rozwiązań wykorzystujące kartę elektroniczną, zarówno
tych praktycznych (uniwersalna aplikacja biblioteczna, kontrola dostępu do zasobów informatycznych)
jak i takich, których wdrożenie jest odleglejsze (bilet komunikacji miejskiej „drugiej generacji”, indeks elektroniczny). W najbliższych planach jest także rozpoczęcie eksploatacji drukarek z certyfikatem VISA, co
otworzy drogę do umieszczenia w ELS aplikacji umożliwiającej realizację płatności.
2
Program konferencji
od 8.30
Rejestracja uczestników – kawa
10.00
10.15 - 10.45
10.45 - 11.15
11.15 - 11.45
11.45 - 12.00
Sesja I
Powitanie uczestników,
prof. dr hab. inż. Tomasz Łodygowski,
Prorektor ds. kształcenia Politechniki Poznańskiej
„Dotychczasowa działalność MCP oraz kierunki rozwoju”,
Andrzej Tadych, Marek Gosławski, Tomasz Kokowski, Politechnika Poznańska
„Współpraca MCP z USOS”, prof. dr hab. Marek Kręglewski,
Uniwersytet im. Adama Mickiewicza w Poznaniu
Dyskusja z udziałem przedstawiciela MNiSzW „Potrzeba zmian
w rozporządzeniu w sprawie dokumentacji przebiegu studiów”
Podsumowanie
Sesja II
12.30 - 13.00
13.00 - 13.30 13.30 - 14.00 14.00 - 14.30 14.30 - 15.00 15.00 - 15.30
15:30 - 16:00
Visa Europe Services Inc.
Bank Zachodni WBK S.A
Sputnik Software Sp. z o.o.
CONTROL SYSTEM FMN Sp. z o.o.
Krajowa Izba Rozliczeniowa S.A.
Oberthur Card Systems POLAND Sp. z o.o.
e-ja
Warsztaty
12.15 - 13.00
13.00 - 13.45
13:45 - 14:30
14.30 - 15.15
15.15 - 16.00
16.00
„Programowanie kart elektronicznych na przykładzie kart Zeit Control”,
Piotr Płusa, Instytut Informatyki PP
„Aplikacja biblioteczna” – Marek Gosławski, MCP LS PP
Visa Europe Services Inc.
„KD z wykorzystaniem protokołu T=CL”, Sputnik Software Sp. z o.o.
„Technologia druku termosublimacyjnego retransferowego
od podszewki” – CONTROL SYSTEM FMN Sp. z o.o.
Poczęstunek
3
Międzyuczelniane Cent
Legitymacji Studenckie
Sesja II
4
Sputnik Software
Sputnik Software jest spółką technologiczną specjalizującą się w wytwarzaniu oprogramowania oraz
świadczeniu kompleksowych usług integratorskich. Głównym obszarem działania firmy jest sektor publiczny. Od kilku lat Sputnik Software realizuje politykę zakładającą ciągły rozwój oprogramowania oraz
budowanie specjalistycznych kompetencji. Sputnik Software posiada wieloletnie doświadczenie w tworzeniu oprogramowania. Od 2004 roku jest Złotym Partnerem Microsoft w linii kompetencji ISV/Software Solutions. Jest autorem systemu obsługi jednostek samorządu terytorialnego „Nowoczesny urząd”
w którego skład wchodzą aplikacje wspomagające pracę urzędów administracji publicznej. Swój sukces
firma zawdzięcza wysokiej jakości produktom, doskonałej znajomości technologii oraz wykwalifikowanej
kadrze.
Bezpieczeństwo i zarządzanie
W 2005 roku Sputnik Software stworzył dział zajmujący się bezpieczeństwem IT oraz rozwiązaniami
związanymi z cyfrową tożsamością. Obejmuje ona takie elementy jak infrastruktura klucza publicznego,
kryptografia, identyfikacja cyfrowa czy kontrola dostępu. Szybki rozwój usług elektronicznych istotnie
wpływa na zapotrzebowanie na tego rodzaju usługi, których celem jest podwyższenie bezpieczeństwa
oraz umożliwienie sprawnego zarządzania użytkownikami w środowisku IT.
Usługi świadczone przez Sputnik Software w zakresie cyfrowej tożsamości:
• Budowanie Urzędów Certyfikacji,
• Planowanie polityki bezpieczeństwa oraz tworzenie środowisk sieciowych zorientowanych na
łatwość zarządzania i wygodę użytkowników,
• Usługi integratorskie oraz szkoleniowe związane z Infrastrukturą Klucza Publicznego oraz podpisem elektronicznym,
• Systemy zarządzania tożsamością cyfrową,
• Dostawy komponentów technicznych-kart mikroprocesorowych, tokenów, sprzętowych modułów bezpieczeństwa (Hardware Security Module).
• Instalacja zintegrowanych systemów kontroli dostępu,
Elektroniczna Legitymacja Studencka
W roku 2007 współpracując z firmą Oberthur Card Cystem, jednym z światowych dostawców kart mikroprocesorowych Sputnik Software dostarczył 150,000 tysięcy kart dla kilku wiodących uczelni w Polsce.
Karta ID One Cosmo v64 jest nowoczesną kartą oparta jest o system operacyjny JavaCard w najnowszej
wersji 2.2. Dla zapewnienia większej elastyczności karta została wyposażona w dwa interfejsy: stykowy
spełniający normy ISO 7816 i zbliżeniowy zgodny z ISO 14443-4.
Architektura karty ID-One Cosmo 64 predysponuje ją do zastosowania w rozwiązaniach wykorzystujących tożsamość cyfrową, gdzie bezpieczeństwo i niezawodność stoją na pierwszym miejscu. Karta
posiada certyfikat bezpieczeństwa FIPS 140-2 Level 3.
ID-One Cosmo 64 oferuje pełne 64KB pamięci EEPROM do wykorzystania na potrzeby użytkownika,
co razem z apletami zawartymi na karcie daje dużą uniwersalność i możliwość dostosowania do potrzeb
użytkownika.
5
Control System FMN









Różnica między drukarkami termosublimacyjnymi i termosublimacyjno-retransferowymi
Zasada działania drukarek do kart plastykowych wykorzystuje zjawisko termosublimacji, a więc fizycznego przejścia substancji, pod wpływem wysokiej temperatury, ze stanu stałego w stan gazowy,
z pominięciem fazy pośredniej – ciekłej. Resublimacja jest procesem odwrotnym – a więc bezpośrednim
przejściem ze stanu gazowego w stały.


          
             
            




           


            




             


              
           
             

             
           
              
              
              


               


 
        





Na rynku są używane dwa typy drukarek:
Drukarki bezpośrednio tworzące obraz na karcie – opiera się na zjawisku termosublimacji barwnika bezpośrednio na kartę. Te drukarki nazywamy krótko termosublimacyjnymi.
Drukarki tworzące obraz na filmie – opiera się na zjawisku termosublimacji barwnika najpierw na
nośnik pośredni (film) i przeniesienie obrazu na kartę. Ten typ drukarek dla odróżnienia nazywamy termosublimacyjno-retransferowymi. Dokładne omówienie zasady działania oraz zalet i wad obydwu technik
znajduje się poniżej.






 


 
 
Technika termosublimacyjna
Ten rodzaj nadruku polega na wysublimowaniu barwnika z kolorowej taśmy (którą zakłada się do
drukarki) bezpośrednio na kartę. Podczas tego procesu głowica drukarki, która steruje sublimacją, pobiera z poszczególnych kolorowych paneli taśmy (CMYK – trzy kolory: cyjan C, magenta M, żółty Y, i panel
czarny K) kolejne porcje barwnika i nakłada je warstwami na dany piksel, aż do osiągnięcia założonego
koloru. Uzyskana barwa jest wypadkową wszystkich warstw barwników przesublimowanych na ten piksel. Jakość obrazu jest więc standardowa, ale może być niewystarczająca np. w bardzo szczegółowych
projektach. Jednocześnie głowica drukarki przejeżdża przez całą kartę mocno dociskając taśmę do powierzchni karty. Jeśli karta ma nierówną powierzchnię (co się zdarza) wówczas występują niedodruki.
Jeśli karta posiada nawet minimalnie wystający chip, wówczas następuje trwałe uszkodzenie głowicy.
Głowica jest do wymiany. Ewentualne zostawianie w projekcie karty okienka na chip nic tu nie zmienia,
ponieważ głowica musi dojechać do końca karty, czyli zakończyć proces. Karty stosowane w tych drukarkach muszą mieć idealnie równą powierzchnię, a więc drukarki te nie nadają się do nadruku na kartach
z zewnętrznym chipem.
Zalety: drukarki są stosunkowo niedrogie i to jest ich podstawowa zaleta. Te w metalowej obudowie są
wytrzymałe, przeznaczone do bardzo dużej ilości wydruków. Przewidziane zostały do wykonywania prostych identyfikatorów, kart lojalnościowych, wejściówek itp.
Wady: drukarki pracujące w tej technice powinny być stosowane tylko do kart o równej powierzchni,
bez chipów zewnętrznych. Nadruk projektów graficznych zawierających mocne, nasycone kolory wypada blado, karty posiadają białą obwódkę.
Drukarki pracujące w tej technice mają wszyscy producenci i dystrybutorzy drukarek w naszym kraju.
W Fargo są to serie Persony i DTC
Technika termosublimacyjno-retransferowa
Ten rodzaj nadruku jest bardziej skomplikowany. Do drukarki zakłada się dwie taśmy: kolorową CMYK
oraz film retransferowy, który jest nośnikiem pośrednim. Film ten stanowi taśma PCV powleczona specjalnym przezroczystym laminatem, który zabezpiecza kartę przed ścieraniem.
6


W pierwszym etapie (termosublimacji - takim jak w poprzedniej technice) głowica drukarki steruje
procesem sublimacji barwnika z taśmy kolorowej (CMYK). Jednak barwnik osadza się nie bezpośrednio
na karcie, ale na filmie. Przenoszenie obrazu na piksele odbywa się w ten sposób, że odpowiednia ilość
barwnika pobierana jest z każdego panela CMYK i syntezowana jednocześnie na powierzchni nośnika
pośredniego. Piksel obrazu na filmie składa się więc z jednolitej, wymieszanej barwy, co stanowi o wysokiej jakości uzyskiwanego obrazu. Uzyskany na filmie gotowy obraz jest wlaminowywany na gorąco
(drugi etap - retransfer) w kartę i dociskany do niej przez specjalny elastyczny wałek. Razem z obrazem na
kartę przenoszona jest warstwa laminująca. W tej technice głowica nie dotyka karty w żadnym momencie, dlatego też producent tych drukarek informuje o możliwości wykonania przez głowicę nadruku na
nieograniczonej ilości kart. Jest to drukarka skonstruowana specjalnie do nadruku na kartach z zewnętrznym chipem.
Zalety: technika ta pozwala zadrukować powierzchnię dowolnie nierówną, również z wystającym chipem. Jednocześnie karta jest laminowana, a więc nadruk jest zabezpieczony przed ścieraniem
i blaknięciem. Warstwa laminatu jest dobrym przewodnikiem i nie przeszkadza w przekazaniu
sygnału do czytnika. Zaletą jest również doskonała, fotograficzna jakość nadruku, możliwość
uzyskiwania nawet mocno nasyconych barw oraz trwałość urządzenia.
Wady: jedyną wadą do tej pory była wysoka cena. Nadal konkurencyjne drukarki retransferowe posiadają ceny wielokrotnie przewyższające ceny zwykłych drukarek termosublimacyjnych. Obecnie
cena drukarki retransferowej Fargo HDP5000 jest porównywalna z ceną zwykłej drukarki termosublimacynej. A więc jedyna wada znika.
Informacje dodatkowe.
Drukarka pracująca technice retransferu produkowana przez amerykańską firmę FARGO, nazywa się
HDP (High Definition Printing) np. HDP600, HDP5000.
Control System FMN jest jedynym autoryzowanym dystrybutorem Fargo w Polsce, posiada Autoryzowane Centrum Serwisowe Fargo, które opiekuje się drukarkami przez cały czas ich życia.
HDP600, jest nowoczesną drukarką (weszła do produkcji listopad 2004) i w tej grupie drukarek, najtańszą. HDP5000 została wprowadzona do sprzedaży w 2007, posiada wszystkie zalety HDP600 ale jest
niemal połowę od niej tańsza. Obydwa typy drukarek posiadają wiele opcji do wyboru.
KOMPLEKSOWA PROPOZYCJA FIRMY CONTROL SYSTEM FMN
Podstawowe informacje o firmie:
- Firma założona w 1994 roku;
- Wyłączny / autoryzowany dystrybutor i autoryzowany serwis:
• Fargo,
• HID,
• Synel,
• Adams Rite;
- Integrator systemów kontroli dostępu i identyfikacji personalnej;
- Ponad tysiąc systemów do wydruku kart plastikowych sprzedanych w Polsce;
- Ponad 50 uczelni wyższych skorzystało z naszych usług przy wdrażaniu systemu ELS;
- Koncesja MSWiA.
7
ELEKTRONICZNA LEGITYMACJA STUDENCKA
Informacje o Systemie Elektronicznej Legitymacji Studenckiej oferowanym przez Control System FMN:
Oferujemy kompletny system dziekanatowy, wraz z modułem bibliotecznym zawierający pełną obsługę Systemu Elektronicznej Legitymacji Studenckiej, którego elementami są:
- Oprogramowanie do wydruku, kodowania i wydawania legitymacji;
- Drukarki do wydruku i kodowania blankietów;
- Czytniki/kodery do przedłużania ważności legitymacji i obsługi studentów w dziekanatach, bibliotece etc;
- Oprogramowanie do przedłużania ważności legitymacji;
- Hologramy semestralne z nadrukowaną datą ważności;
Blankiety ELS wykonane zgodnie z rozporządzeniem ministra, z procesorami dostosowanymi do wymagań Uczelni. Powyższe elementy tworzą pełny i kompletny system obsługi Elektronicznej Legitymacji
Studenckiej dla Uczelni. Co ważne, jesteśmy w stanie wdrażać je modułowo, czyli w ramach potrzeb
Uczelni możemy dostarczać i instalować jeden, kilka, lub wszystkie z powyższych elementów. Control
System jest jedynym autoryzowanym dystrybutorem oraz centrum serwisowym FARGO w Polsce. Dysponujemy ponad 15-letnim doświadczeniem w dziedzinie integracji systemów i oprogramowania. Gwarantujemy profesjonalną obsługę i pełna pomoc przy wdrażaniu i podczas użytkowania naszego systemu.
HDP 5000 ELS
Specyfikacja techniczna:
Rozdzielczość: 300 dpi
Ilość kolorów: 16,7 mln
Druk: jednostronny (opcja: moduł do obracania karty)
Dostępne rodzaje taśm: YMCK-500, YMCKK-500,
Dostępne rodzaje filmów HDP: Przezroczysty - 1500
wydruków,
Dostępne folie do laminacji: Folia laminacyjna przezroczysta, grubość 0,006mm
Szybkość druku karty: 46s YMCK, 70s YMCKK
Akceptowane standardy kart (wymiary): CR-80 (85,6mm x 54mm)
Akceptowane grubości kart: 0,762-1,778 mm
Akceptowane typy kart: ABS, PCV, PET, PETG, zbliżeniowe, chipowe, magnetyczne
Pojemność zasobnika: 100 szt.
Pamięć RAM: 16 MB
Wyświetlacz (LCD): 4 linijkowy
Sterowniki: Win9x/Me/NT4.0/2000/XP/Server2003/Vista
Minimalne wymagania sprzętowe: Pentium 133, 32 MB RAM, 200 MB wolnego miejsca na dysku, port USB
Złącza: USB oraz Ethernet z wewnętrznym serwerem wydruku
Temperatury pracy: 18-27ºC
Wilgotność powietrza: 20-80 % (bez kondensacji)
Standardy bezpieczeństwa: UL 1950, CSA C2. 2 No. 950-95, TuV-GS (EN 60950 A1-A4, A11) EMC:
CE Mark, CRC c1374, BSMI, ITS (EN 55022 Class B: 1995),FCC Class B, EN 50082-1:1997
Wymagane napięcie: 100-240 VAC, 4,25A
Wymagana częstotliwość: 50Hz / 60Hz
8
Opcje: Moduł do laminacji kart – jednostronnie lub dwustronnie (laminacja równoczesna obu stron
karty), kodery kart mikroprocesorowych (stykowych i bezstykowych), Zamki do podajników drukarki, Zestaw czyszczący do drukarki, Podajnik na 200 kart, Moduł do obracania karty
Istotne cechy warte podkreślenia:
• modułowa budowa – możliwość rozbudowy drukarki w trakcie użytkowania (dodanie modułu do
obracania karty, modułu laminacyjnego, koderów);
• dwa złącza w standardzie: USB oraz złącze Ethernetowe (+ wbudowany wewnętrzny serwer wydruku)
• możliwość dodania podczas użytkowania drukarki modułu do obracania karty oraz modułu laminacyjnego jednostronnego, lub dwustronnego (laminuje obie strony karty w tym samym czasie,
w jednym przebiegu)
• dedykowane oprogramowanie zarządzające pracą drukarek w sieci i zabezpieczające dostęp osobom niepowołanym
• zapewnienie gwarancyjnego serwisu drukarki w Autoryzowanym Serwisie Fargo
HDP 600 ELS
Specyfikacja techniczna:
Rozdzielczość: 300 dpi
Ilość kolorów: 16,7 mln
Dostępne rodzaje taśm: YMCK-500, YMCKK-400,
Dostępne rodzaje filmów HDP: Przezroczysty - 1250 wydruków,
przezroczysty z hologramem
Dostępne folie do laminacji: Folia laminacyjna przezroczysta, grubość
0,006mm
Szybkość druku karty: 54s YMCK, 79 s YMCKK
Akceptowane standardy kart (wymiary): CR-80 (85,6mm x 54mm)
Akceptowane grubości kart: 0,762-1,778 mm
Akceptowane typy kart: ABS, PCV, PET, PETG, zbliżeniowe, chipowe, magnetyczne
Pojemność zasobnika: 200 szt.
Pamięć RAM: 8 MB
Wyświetlacz (LCD): 4 linijkowy
Sterowniki: Win9x/Me/NT4.0/2000/XP/Vista
Minimalne wymagania sprzętowe: Pentium 133, 32 MB RAM, 200 MB wolnego miejsca na dysku, port USB
Złącza: USB (opcjonalnie Ethernet z wewnętrznym serwerem wydruku)
Temperatury pracy: 18-27oC
Wilgotność powietrza: 20-80 % (bez kondensacji)
Standardy bezpieczeństwa: UL 1950, CSA C2. 2 No. 950-95, TuV-GS (EN 60950 A1-A4, A11) EMC:
CE Mark,
CRC c1374, BSMI, ITS (EN 55022 Class B: 1995),FCC Class B, EN 50082-1:1997
Wymagane napięcie: 100-240 VAC, 4,25A
Wymagana częstotliwość: 50Hz / 60Hz
Opcje: Wewnętrzny serwer wydruku i łącze Ethernet, Zestaw czyszczący do drukarki, Moduł laminujący,
Moduły kodujące: (karty mikroprocesorowe, MIFARE)
9
Istotne cechy warte podkreślenia przy opracowaniu specyfikacji:
• opcja: wbudowany wewnętrzny serwer wydruku i złącze Ethernetowi (dla drukarek sieciowych)
• możliwość dodania podczas użytkowania drukarki modułu laminacyjnego, który po podłączeniu
będzie stanowił integralną część drukarki i który będzie w stanie nanosić na całą powierzchnię
karty folię laminacyjną
• dedykowane oprogramowanie zarządzające pracą drukarek w sieci i zabezpieczające dostęp osobom niepowołanym
• Zapewnienie gwarancyjnego serwisu drukarki w Autoryzowanym Serwisie Fargo
10
Krajowa Izba Rozliczeniowa S.A.
Krajowa Izba Rozliczeniowa S.A. została powołana w 1991 r. z inicjatywy 16 największych banków,
w tym Narodowego Banku Polskiego oraz Związku Banków Polskich.
Swoje usługi kieruje przede wszystkim do instytucji bankowych, finansowych, dużych przedsiębiorstw
z sektora telekomunikacyjnego i energetycznego, firm działających w obszarze e-commerce oraz administracji publicznej.
KIR S.A. od ponad 15 lat opracowuje i wprowadza na rynek innowacyjne rozwiązania z dziedziny wymiany informacji elektronicznej. Izba sprawnie i bezpiecznie realizuje międzybankowe, bezgotówkowe
transakcje płatnicze. Do tej pory za pośrednictwem systemów ELIXIR® (dla płatności w walucie krajowej)
i EuroELIXIR (dla płatności krajowych i transgranicznych w euro), Izba zrealizowała blisko 6 mld transakcji. W 2007 r. KIR S.A. po raz pierwszy rozliczyła ponad 1 mld transakcji płatniczych. Tym samym dołączyła
do grona największych europejskich izb rozliczeniowych.
Dzięki dostosowaniu systemu EuroELIXIR do obsługi instrumentów SEPA Credit Transfer, Izba umożliwiła uczestniczącym w tym systemie bankom z polskiego obszaru płatniczego stosowanie nowych paneuropejskich instrumentów płatniczych w nowym, jednolitym standardzie, w ramach funkcjonującego
od 28 stycznia 2008 r. Jednolitego Obszaru Płatności w Euro.
Krajowa Izba Rozliczeniowa S.A. jest godnym zaufania partnerem dla banków oraz przedsiębiorstw.
Zgodnie ze swoją misją, KIR S.A. od początku istnienia firmy wprowadza zaawansowane technologicznie,
innowacyjne rozwiązania teleinformatyczne. Dlatego kiedy w 1993 roku polskie banki wyraziły zapotrzebowanie na usługi podpisu elektronicznego, to właśnie Izba jako pierwsza w Polsce i jedna z pierwszych
firm w Europie zaoferowała usługę podpisu elektronicznego SZAFIR. Dzięki zdobytej w tym czasie wiedzy
i doświadczeniu, Izba stała się na mocy decyzji Ministra Gospodarki z 2003 roku jednym z trzech centrów
uprawnionych do wydawania certyfikatów kwalifikowanych. Rosnąca popularność usługi sprawiła, że
obecnie e-podpis jest - obok rozliczeń międzybankowych, usług masowych płatności i elektronicznej
archiwizacji dokumentów - jednym z filarów rozwoju KIR S.A.
Szybkość, prostota, bezpieczeństwo
Wraz z rozwojem rynku i ewolucją usługi zmienia się także rola podpisu elektronicznego w nowoczesnej firmie. Przedsiębiorcy dostrzegli jego funkcjonalność, a sam e-podpis przestał być ciekawym gadżetem stając się pełnoprawnym narzędziem ułatwiającym codzienne funkcjonowanie przedsiębiorstwa.
Kwalifikowany podpis elektroniczny jest równoważny pod względem skutków prawnych z podpisem
własnoręcznym, jednak zdecydowanie od niego bezpieczniejszy. Podpis elektroniczny zapobiega wprowadzeniu zmian w treści zabezpieczonego dokumentu. Jakakolwiek ingerencja w treść dokumentu jest
widoczna i możliwa do natychmiastowej identyfikacji. Połączenie e-podpisu z usługą znakowania czasem zabezpiecza także przed antydatowaniem dokumentów. Dodatkowym atutem stosowania podpisu
elektronicznego jest oszczędność czasu i możliwość obniżenia kosztów funkcjonowania przedsiębiorstwa. Elektroniczne dokumenty można szybciej i taniej przesłać do adresata. Niższe są także koszty archiwizacji i przechowywania cyfrowej dokumentacji, a proces wyszukiwania informacji ulega diametralnemu skróceniu. Pomimo technologicznej złożoności i zaawansowania zarówno korzystanie z podpisu
elektronicznego jak i jego instalacja w systemie jest prosta i niezwykle intuicyjna. Dołączone do zestawu
oprogramowanie poprowadzi użytkownika krok po kroku przez cały proces.
11
Jeden certyfikat - wiele zastosowań
Rozwój polskiej gospodarki sprawia, że przyszłość podpisu elektronicznego rysuje się optymistycznie.
Już teraz e-podpis rozwija się w bardzo szybkim tempie. W 2007 roku liczba certyfikatów sprzedanych
przez KIR S.A. wzrosła w porównaniu do roku 2006 o 66%. Dynamika wzrostu w pierwszym kwartale 2008
roku jest jeszcze wyższa i przekroczyła 160% w porównaniu do analogicznego okresu w roku ubiegłym.
Już teraz e-podpis można wykorzystać do:
• elektronicznego rozliczenia się z urzędem skarbowym
• przesyłania dokumentów do ZUS
• podpisywania umów, ofert i innych prawnie wiążących dokumentów elektronicznych
• podpisywania faktur elektronicznych
• podpisywania danych na elektronicznych legitymacjach studenckich
• podpisywania elektronicznej dokumentacji medycznej
• zgłaszania zmian w KRS
• rejestracji baz danych w GIODO
• uczestniczenia w elektronicznych aukcjach i przetargach
• kontaktów z urzędami administracji publicznej
Perspektywy rozwoju
Wyniki te mają szansę jeszcze się poprawić, ponieważ od podpisu elektronicznego nie ma obecnie
odwrotu. Dzięki kolejnym zmianom prawnym wachlarz zastosowań, a także liczba klientów zainteresowanych e-podpisem stale rośnie. Wychodząc naprzeciw zapotrzebowaniu rynku, KIR S.A. stale rozwija usługę i usprawnia proces dystrybucji. Już teraz podpis elektroniczny można nabyć w 17 placówkach KIR S.A.
zlokalizowanych we wszystkich miastach wojewódzkich oraz w Koszalinie a także w 109 oddziałach
Banku Ochrony Środowiska.
Elżbieta Włodarczyk
Dyrektor Działu Usług Certyfikacyjnych Krajowej Izby Rozliczeniowej S.A.
E-legitymacje są bezpieczne
Możliwość stosowania elektronicznych legitymacji studenckich wprowadziło rozporządzenie Ministra
Edukacji Narodowej i Sportu z dnia 18 lipca 2005 r. E-legitymacja studencka przypomina rozmiarami
nowy dowód osobisty. Zawiera standardowe informacje, takie same jak tradycyjna legitymacja papierowa: imię i nazwisko studenta, nr albumu, adres zamieszkania, data urodzenia, etc. Jest jednak od niej
znacznie bardziej odporna na uszkodzenia, a dzięki wykorzystaniu technologii podpisu elektronicznego
jest też odporna na wszelkie próby fałszowania legitymacji. Jakakolwiek zmiana danych, a także przedłużenie ważności legitymacji musi odbywać się z wykorzystaniem kwalifikowanego certyfikatu, za wiedzą
jego posiadacza. Jest więc niemożliwe np. podrobienie pieczątki czy wystawienie legitymacji na fikcyjną
osobę, co zdarzało się czasami w przypadku legitymacji papierowej.
12
Informacja prasowa
UMCS I KUL wprowadzają elektroniczne legitymacje studenckie
Katolicki Uniwersytet Lubelski oraz Uniwersytet Marii Curie Skłodowskiej zakupiły od
Krajowej Izby Rozliczeniowej kilkadziesiąt zestawów do składania podpisu elektronicznego.
E-podpis będzie wykorzystywany do przygotowywania i wydawania elektronicznych legitymacji studenckich.
Rozporządzenie Ministra Edukacji Narodowej i Sportu z 18 lipca 2005 roku wprowadziło możliwość
wydawania przez uczelnie elektronicznych legitymacji studenckich. - Dla uczelni jest to okazja do zastąpienia tradycyjnych legitymacji papierowych nowymi – elektronicznymi, które oferują znacznie więcej możliwości niż tylko przechowywanie danych studenta – wyjaśnia Elżbieta Włodarczyk,
dyrektor Działu Usług Certyfikacyjnych Krajowej Izby Rozliczeniowej S.A., firmy dostarczającej zestawy
do składania podpisu elektronicznego, niezbędne do potwierdzania autentyczności zawartych na
e-legitymacjach danych.
W tej sytuacji uczelnie coraz częściej decydują się – tak jak UMCS i KUL – na wprowadzenie nowocześniejszego rozwiązania. Na KUL z e-legitymacji korzysta obecnie 5 tysięcy studentów. - Na razie otrzymali je studenci pierwszego roku oraz studenci starszych roczników, którzy chęć otrzymania takiej
legitymacji wcześniej zgłosili. Kolejne roczniki będą otrzymywać legitymacje wyłącznie w formie
elektronicznej – zapewnia Wojciech Moniuszko, kierownik działu teleinformatycznego na KUL.
Elektroniczne legitymacje studenckie, choć droższe od standardowych legitymacji papierowych, są - zdaniem przedstawicieli uczelni – lepszym rozwiązaniem. Według nich wprowadzenie
e-legitymacji upraszcza czasochłonne procedury związane z wystawianiem papierowych legitymacji. - Nie musimy przybijać pieczątek i podpisywać blankietów legitymacji. Dodatkowo oprogramowanie dostarczone wraz z e-podpisem pozwala na „podpisanie” dowolnej liczby blankietów jednocześnie. To znacznie przyśpiesza proces przygotowania legitymacji – przekonuje Wojciech Widelski
z Sekcji Technicznej UMCS.
Przedstawiciele uczelni zwracają także uwagę na zalety samej elektronicznej legitymacji. Można na niej zakodować oprócz danych osobowych studenta, nr pesel i nr albumu, również wiele
innych informacji. - Za pomocą e-legitymacji można np. uzyskać dostęp do pomieszczeń uczelni, akademika, sali komputerowej. Elektroniczna legitymacja może też z powodzeniem pełnić rolę karty bibliotecznej lub biletu miesięcznego na komunikację miejską – wylicza Wojciech Moniuszko, kierownik
działu teleinformatycznego na KUL.
Uczelnie, które wprowadziły elektroniczne legitymacje studenckie zapowiadają kolejne inwestycje
w nowe technologie. KUL chce zakupić dla pracowników dziekanatu 100 certyfikatów kwalifikowanych
niezbędnych do składania tzw. bezpiecznego podpisu elektronicznego. UMCS korzystający obecnie
z blisko 80 certyfikatów kwalifikowanych zamierza wykorzystywać e-podpis jako jeden ze składników
wprowadzanego systemu informatycznego SAP. Podpis ma być również stosowany do weryfikacji autentyczności przesyłanych dokumentów elektronicznych na uczelni.
13
Oberthur Technologies
1. Informacja o Oberthur Technologies
Osiągając sprzedaż na poziomie 733.4 milionów Euro w 2007, Oberthur Technologies jest światowym
liderem na polu bezpiecznych technologii. Innowacyjność i wysoki poziom świadczonych usług zapewniają Oberthur Technologies silną pozycję na jego głównych rynkach:
• Card Systems (Smart cards): czołówka światowa w dostawie kart inteligentnych i powiązanych z nimi
usług, jak personalizacja, telefonia komórkowa, płatności, identyfikacja, telewizja cyfrowa i transport.
• Druk bezpieczny: Trzecia światowa co do wielkości prywatna firma specjalizująca się w bezpiecznych drukach, jak banknoty, paszporty i inne dokumenty identyfikacyjne. Obecna w ponad 50 krajach świata.
• Oberthur Cash Protection: światowy lider na rynkach wschodzących. Produkcja wyposażenia do
przewozu wartości pieniężnych (“inteligentne” kontenerki) oraz zabezpieczenia bankomatów.
Atutem Oberthur Technologies jest zdolność rozumienia i przewidywania trendów rynkowych oraz
dwuścieżkowość podejścia do Klientów: dostarczanie globalnych rozwiązań z jednoczesnym wsparciem
lokalnym, dostosowanym do wyspecjalizowanych potrzeb danego Klienta. Oberthur Technologies jest
notowana na paryskiej giełdzie. Adres: www.oberthur.com
2. Profil Firmy
Oberthur Technologies Card Systems – poprzednio Oberthur Card Systems – plasuje się pośród światowych liderów w sektorze producentów kart inteligentnych, zajmując wśród nich 3 miejsce. W 2007
roku Oberthur Technologies Card Systems osiągnął obrót w wysokości 591.4 M€ - co stanowi wzrost
o 13% w porównaniu do 2006.
Oberthur oferuje szerokie portfolio produktów i usług, od pomysłu do końcowego produktu, w tym rozwój oprogramowania, wydawnictwo spersonalizowanych kart oraz całościowe zarządzanie projektem.
Oberthur Technologies Card Systems jest czołowym światowym graczem w zakresie innowacyjności
oraz świadczonych usług w sektorach: płatności, gsm I bezpieczeństwa/identyfikacji.
• Płatności I usługi: jeden z wiodących dostawców kart Visa i MasterCard, niekwestionowany
lider w dostawie kart bezstykowych.
• GSM: Otwarte i interoperabilne rozwiązania oparte na technologii Java™, w tym karty SIM
o wysokiej pojemności pamięci (od16k do 1Go).
• Identyfikacja: silna pozycja w projektach ID na całym świecie.
• Multimedia: wiodąca pozycja na rynku płatnej telewizji.
• Transport: zogniskowanie na wymagającym i rozwiniętym segmencie rynku, oferta oparta na
rozwiązaniach mikroprocesorowych.
Największym atutem Oberthur jest jego zdolność rozumienia i przewidywania światowych trendów
oraz połączenie globalnego myślenia z jednoczesnym zindywidualizowanym podejściem do Klienta, dostosowanym do jego unikatowych potrzeb.
2.1. Oberthur Technologies na świecie
Na koniec grudnia 2007, Oberthur Technologies Card Systems zatrudniał 4,000 osób na całym świecie. Oberthur jest obecny w ponad 30 krajach na 6 kontynentach, posiadając 9 centrów produkcyjnych,
20 centrów personalizacyjnych, 3 ośrodki R&D oraz 35 biur handlowych.
W obszarach, gdzie Oberthur nie posiada własnych biur, działamy na zasadach joint venture z lokalnymi firmami, aby zapewnić w każdym miejscu jednolitą, opartą na tych samych standardach obsługę.
14


  
   
 
 

  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

  

 

Politechnika
Uczelnia
Patrycja Thomas
Patrycja Thomas
2008.06.12
123456
77010112345
Warszawa, ul. Sienna 93
2008.06.12
123456
77010112345



  

15
 
Politechnika
Uczelnia
Patrycja
Thomas
2008.06.12
123456
Patrycja
Thomas
77010112345
2008.06.12
77010112345
93
Dane osobowe
- Dane studenta
- imi i nazwisko
- adres
- data urodzenia
- płe
- inne
PKI
Dane
biometryczne

  

  

 
 
 
 
 
 
 
 
 



 
  

 
 
 
  
 
 
  
   
   
16

  



 
  


 



 
 
 

 

  

 

  

 
EE
PROM
R
O
M
Struktura
Struktura
plików
plikówAA
Struktura
Struktura
plików
plikówBB
Aplikacja
AplikacjaAA
Aplikacja
AplikacjaBB
Funkcje dostpne
specyficzne dla
aplikacji
Zaleno
sprztowa
System
Systemoperacyjny
operacyjny
Podstawowe
funkcje
(zarzdzanie
plikami,…)
CPU
CPU++crypto
crypto

  

 
 
 
 
R
O
M
Elekt.
Aplikacja
Application
Application
Application
Application
portmonetka
biblioteczna
AA
BB
Operating
OperatingSystem
System
System Operacyjny

Aplikacja
Application
Application
Applicationbiblioteczna
Application
Aplikacja
AA
BB
ELS
Operating
OperatingSystem
System
System Operacyjny
Chip
CPU
--Producent
+
Chip
Producent
CPU
+crypto
crypto XX
Chip
CPU
––Producent
+
Chip
Producent
CPU
+crypto
crypto YY
Karta A
Karta B
  

17
 





 
 
  

 
 

 
  
 

  

 
EE
PROM
Struktura
Struktura
plików
plikówAA
Aplikacja
AplikacjaAA
Struktura
Struktura
plików
plikówBB
Niezaleno
sprztowa
Aplikacja
AplikacjaBB
przez Java Card API
JAVA
JAVACard
CardAPI
API
R
O
M
Interpreter
JAVA
InterpreterJAVA
System
SystemOperacyjny
Operacyjny
CPU
CPU++crypto
crypto

Architektura
Virtual Machine
  

 
EE
PROM
R
O
M
Elektr.
portmonetka
Aplikacja
biblioteczna
Aplikacja
biblioteczna
Access
Control
Application
Application
Interpreter
Java
Application
Application
AA
BB
Application
Application
Interpreter
Java
Application
Application
AA
BB
Operating
OperatingSystem
System
System Operacyjny
Operating System
System
Operacyjny
Chip
CPU
--Producent
+
Chip
Producent
CPU
+crypto
crypto XX
Chip
CPU
--Producent
++crypto
Chip
Producent
CPU
crypto YY
Karta A
18
Access
Control

Operating System
Karta B
  

 








 
 
   
 

 
  
     

  


  
 

  

  
  
    

   
 
 
 

  

 
Classic
 
    
  
  
 
 
  
  
 
 
 
 

Common Criteria
EAL 4+ PP SSCD
UnitedUnited-States NIST
FIPS 140140-2 Level 3
  

19

  
 
 
    
 
 
 
 
 
 
  
 
 

  

   

  

 

Monika Paszko
Area Sales Manager
tel: +48 604 144 034
[email protected]
Tomasz Rzd
Wsparcie techniczne
tel: +48 604 401 577
[email protected]
20

  

Elektroniczna Legitymacja Studencka
jako Otwarta Karta Obywatelska
e-Ja to przedsięwzięcie pozwalające na koncentrację usług sieciowych na samym odbiorcy tych
usług, w efekcie, pozwalające na ich wysoką efektywność, wygodną integrację oraz bezbolesną przenośność. e-Ja pozwala na integrację pojęć jak e-student, e-pacjent, e-podatnik, e-pracownik, czy nawet
e-obywatel w jeden spójny obiekt informatyczny, indywidualnie reprezentujący każdego z nas w różnych
wymiarach życia. Elektroniczna Legitymacja Studencka, elektroniczny indeks oraz inne aspekty studiów
też leżą w tych wymiarach.
1. karta jako klucz do bezpiecznie przechowywanych i udostępnianych danych sieciowych
a. bezpieczne schowki sieciowe – zasady i cechy, bezpieczny outsourcing
b. sposoby i miejsca dostępu
2. elektroniczne dokumenty osobiste oraz ich manifestacje w świetle istniejących przepisów
a. elementy elektronicznego dokumentu osobistego
b. Elektroniczna Legitymacja Studencka
c. dokument podróży według International Civil Aviation Organisation
d. dostęp on-line, off-line z automatycznym uaktualnianiem zwartości karty
3. otwarta gama zastosowań
a. budowa dla własnych potrzeb
b. zastosowania ogólnodostępne i komercyjne
c. programy partnerskie: ośrodki, przedsiębiorstwa, administracje
4. połaczenie z innymi inicjatywami informatycznymi
a. aglomeracyjne oparte na interfejsie zbliżeniowym karty
b. płatności
c. dostęp
21
Międzyuczelniane Cent
Legitymacji Studenckie
Warsztaty
22
mgr inż. Piotr Płusa
Instytut Informatyki Politechniki Poznańskiej
ul. Piotrowo 2, Poznań
PROGRAMOWANIE KART ELEKTRONICZNYCH
W JĘZYKU ZC-BASIC
Elektroniczna legitymacja studencka i karta aglomeracyjna to przykłady zastosowania kart elektronicznych na szeroką skalę. Upowszechnieniu kart elektronicznych towarzyszy rosnące zainteresowanie
ze strony programistów, dostrzegających w kartach zarówno ciekawą technologię wartą poznania, jak
i rynek potencjalnych projektów informatycznych. W artykule przedstawiono technologię BasicCard firmy ZeitControl i propozycję zajęć dydaktycznych wprowadzających tę technologię dla studentów informatyki.
1. Cykl życia karty elektronicznej
Wyprodukowanie karty elektronicznej nie tworzy jeszcze gotowego produktu. Mikroprocesorowa
karta elektroniczna wymaga personalizacji, czyli przystosowania do indywidualnych potrzeb klienta.
Karta otrzymuje nadruk zawierający nazwę firmy, jej logo oraz dane identyfikacyjne konkretnego użytkownika – właściciela karty. Ponadto na kartę kopiowana jest dedykowana aplikacja oraz zapisywane są
indywidualne dane użytkownika. Personalizacja odbywa się po opuszczeniu przez kartę fabryki ale przed
rozpoczęciem używania karty, czyli dokonywana jest przez instytucję posiadającą wymagane urządzenia
i oprogramowanie oraz potrzebną wiedzę informatyczną.
Programiści tworzący aplikacje na karty mają aktualnie do wyboru 2 główne rozwiązania: programowanie w języku JAVA lub ZC-Basic. Wybór języka uzależniony jest od wyboru karty, ponieważ rodzaj karty,
tj. producent karty, determinuje docelowy system operacyjny karty i tym samym akceptowalne rozwiązanie programistyczne. Karty „javowe” to następujące systemy operacyjne [9]:
• Cyberflex,
• GemExpresso,
• MULTOS.
Karty „zc-basic” to karty niemieckiej firmy ZeitControl, identyfikującej swoje produkty kartowe jako
BasicCard.
2. Firma ZeitControl i jej produkty BasicCard
Produkty BasicCard firmy ZeitControl stanowią kompletne rozwiązanie na rynku kart elektronicznych.
Producent oferuje zarówno blankiety kart, jak i czytniki umożliwiające komunikację pomiędzy kartą
a komputerem. W ramach kompleksowej oferty klient otrzymuje także bezpłatne środowisko programistyczne, umożliwiające tworzenie indywidualnych rozwiązań przeznaczonych na karty BasicCard [7].
2.1 Karty
Producent oferuje kilka rodzajów kart, różniących się wielkością pamięci EEPROM i RAM, protokołem
transmisji z urządzeniami zewnętrznymi, posiadanymi funkcjami kryptograficznymi i dostępnością systemu plików. Różnice pomiędzy nimi prezentuje tabela 1.
23
Rodzina
Compact
Enhanced
Enhanced
Enhanced
Enhanced
Enhanced
Enhanced
Enhanced
Enhanced
Enhanced
Professional
Professional
Wersja
1.1
3.1
3.2
3.31
3.4
3.5
3.6
3.7
3.8
3.9
4.5A
4.5D
EEPROM (kB)
1
2
4
8
16
6
14
2
4
8
30
30
RAM (kB)
0,25
0,25
0,25
0,25
0,25
0,25
0,25
0,25
0,25
0,25
1
1
Protokół
1
1
1
1
1
1
1
1
1
1
0,1
0,1
Professional
5.4
16
2
0,1
Professional
5.5
32
2
0,1
Professional
5.6
60.5
2
0,1
MultiApplication
6.5
31
1,7
0,1
Funkcje
DES
DES
DES
DES
DES, EC-FSA
DES, EC-FSA
DES
DES
DES
AES, SHA-1, RSA
DES, SHA-1, RSA
DES, AES, SHA256, EC-211
DES, AES, SHA-1,
EC-211
DES, AES, SHA-1,
EC-211
DES, AES, SHA-1,
EC-211
System plików
NIE
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
TAK
Tab. 1 Rodzaje kart BasicCard.
2.2. Czytniki
Podstawowym czytnikiem w ofercie jest CyberMouse.
Rys. 1 Czytnik CyberMouse
Czytnik ten jest zgodny ze standardem ISO 7816 i PC/SC. Niegodnością w użyciu z komputerem, np.
laptopem, może okazać się fakt, że wymaga jednoczesnego podłączenia do portu szeregowego i portu
klawiatury(PS). Dlatego używając go warto przemyśleć zaopatrzenie się w tzw. przejściówki COM/PS <->
USB, dostępne w sklepach komputerowych.
Dostępny jest także Balance Reader, kieszonkowy czytnik zasilany baterią. Posiada dziesięcioznakowy
wyświetlacz prezentujący 4 znaki alfanumeryczne i 6 znaków numerycznych. Czytnik po włożeniu do
niego karty wykonuje zaimplementowaną komendę czytania z karty: Command &HC8 &H00 PRDisplay().
Tym samym, aby używać go do własnych zastosowań, należy tę właśnie komendę zaimplementować
w kodzie programu przeznaczonego na kartę.
Rys 2 Czytnik Balance Leader
24
POS, czyli Point Of Sale, to czytnik terminal do obsługi kart w zastosowaniach płatniczych. Posiada
wyświetlacz o rozdzielczości 128x64, klawiaturę zawierającą cyfry i przyciski programowalne oraz 60mm
drukarkę termiczną.
Rys 3 Czytnik POS
Można do niego podłączyć kablem klawiaturę Pin Pad.
Rys 4 Klawiatura Pin Pad
2.3 Oprogramowanie
ZeitControl przygotował ZeitControl Professional IDE, środowisko programistyczne służące do obróbki kodu: edycji, kompilacji, debugowania, symulacji i przegrywania na karty. Jest ono bezpłatne i można je
pobrać ze stron WWW producenta [8]. Po instalacji pakietu w katalogu BasicCardPro znajdują się m.in.:
• katalog Inc – biblioteki (kod źródłowy, można samodzielnie tworzyć takie biblioteki),
• katalog Lib – biblioteki (prekompilowane, nie można samodzielnie tworzyć takich bibliotek),
• pojedyncze programy narzędziowe: ZCMBasic.exe (kompilator), ZCMDCard.exe (debugger
kodu karty), ZCMDTerm.exe (debugger kodu terminala), ZCMSIM.exe (symulator terminala),
BCLOAD.exe (program przegrywający programy na karty elektroniczne).
Dłuższe korzystanie z tego środowiska jest jednak męczące. Pomimo grupowania plików źródłowych
w projekty, brakuje w nim funkcji przydatnych programistom takich jak kolorowanie składni, zawijanie
kodu, czy automatyczne podpowiadanie. Po instalacji pakietu, w podkatalogu Examples znaleźć można
przykładowe projekty napisane w języku ZC-Basic. Analiza ich zawartości, tj. zarówno kodów źródłowych
jak i wielu plików wsadowych *.bat, prowadzi do wniosku, że aby sprawnie programować w ZC-Basic
warto użyć innego IDE jako edytora kodu, a z ZeitControl Professional IDE używać tylko programów
narzędziowych. W kontekście używania na zajęciach laboratoryjnych, godnym polecenia wydaje się bezMiędzyuczelniane Centrum Personalizacji
25
płatny i niewielki edytor Notepad++, który w połączeniu z „batami” kompilującymi i przegrywającymi pliki
źródłowe stanowi szybkie i elastyczne narzędzie.
3. Przykłady zastosowań BasicCard
Karty BasicCard mogą zostać użyte do wielu profesjonalnych zastosowań i w niczym nie ustępują
konkurencji. Potwierdzają to istniejące produkty wielu firm, przeznaczone do użycia w rozmaitych dziedzinach.
Już od dawna m.in. we Francji i w Niemczech w służbie zdrowia wykorzystywane są karty elektroniczne. Ułatwiają przepływ informacji, przyspieszają obsługę pacjentów, zapobiegają nadużyciom. Ponieważ
rząd niemiecki zamierza unowocześnić działający system kart elektronicznych w służbie zdrowia, firma
ZeitControl przygotowała własną propozycję nowej wersji tego systemu [2]. Jej prototyp został zaakceptowany i jest aktualnie testowany. ZeitControl przyznaje, że ich system został zbudowany przez „2,5 programisty”, co w kontekście otrzymanego certyfikatu TÜV pozwala w pełni zaufać technologii BasicCard.
Na rynku amerykańskim firma ALMEX oferuje system HealthONE [1]. Opiera się on na kartach wersji
3.7 i 3.9, na których przechowywane są imię i nazwisko pacjenta, nr jego ubezpieczenia, podstawowe
dane medyczne potrzebne w razie wypadku takie jak grupa krwi czy chroniczne choroby i alergeny,
poza tym przebyte choroby, zalecenia lekarza, a nawet recepty do realizacji w aptece. System zakłada,
że dostęp do danych na karcie jest uzależniony od rodzaju autoryzacji wynikającej z funkcji pełnionej
przez osobę odczytującą kartę: inne dane widzi ratownik w karetce, inne lekarz, inne farmaceuta. Każda
z wymienionych osób posiada własną kartę, tak więc dostęp do danych karty pacjenta jest niemożliwy
bez drugiej karty pracownika medycznego.
ALMEX oferuje także: SMARTFARE jako system mikropłatności w publicznym transporcie, ePurseONE jako uniwersalny system mikropłatności, SMARTGYM do obsługi klientów centrów rekreacji
i wypoczynku oraz SMARTGOLF dla klubów golfowych [3].
Polska firma INEX wykorzystała technologię BasicCard do autoryzacji logowania do systemu Windows
[4].
Niektóre firmy po prostu dają klientowi możliwość wyboru technologii i na równi z apletami Java
proponują aplety BasicCard, np. francuska firma SOLIATIS oferuje technologię BasicCard w szkoleniach,
testach i rozwoju dedykowanych aplikacji [5], a amerykańska firma SnakeCard oferuje GINQ SOLO BC jako
demonstrator BasicCard [6].
4. Charakterystyka języka ZC-Basic
ZC-Basic jest językiem proceduralnym opartym na języku Basic. Posiada funkcje i procedury, definicje
typów i zmiennych, obsługę plików, a przede wszystkim mechanizm komunikacji z kartami elektronicznymi. Poleceń nie trzeba kończyć znakiem kropki lub średnika, a komentarz rozpoczyna się słowem REM
lub znakiem ‘.
Cechą charakterystyczną programowania w środowisku kart jest tworzenie par: kod przeznaczony
na urządzenie odczytujące kartę i kod przeznaczony na kartę. Ten pierwszy ZeitControl określa jako terminal, a ten drugi jako aplikację BasicCard. Aplikacje przegrywane na karty często nazywa się apletami
[6] lub kardletami [9]. W ZC-Basic tworzy się pary terminal i aplet, następnie kompiluje w celu uzyskania
pliku wykonywalnego *.exe dla terminala i kodu pośredniego *.img dla karty.
Aby zapewnić komunikację pomiędzy kartą a terminalem, spełnione muszą być następujące warunki:
• w programie karty muszą być zaimplementowane komendy obsługi, tj. odczytu i zapisu danych,
• program terminala musi wywoływać dokładnie te komendy, które implementuje karta.
26
Mechanizm komunikacji kart elektronicznych polega na tym, że terminal odpytuje kartę, a karta
udziela odpowiedzi (wykonuje polecenie). To terminal zawsze pierwszy inicjuje połączenie. W ZC-Basic
spełnione są powyższe warunki, a każdy kod terminala powinien na początku zawierać:
• Call WaitForCard() – odczekanie na włożenie karty,
• ResetCard – standardowe polecenie rozpoczęcia komunikacji,
• Call CheckSW1SW2() – przykładowa komenda sprawdzająca błędy.
Kolejne polecenia terminala często znajdują się w pętli, w której użytkownik ma możliwość wyboru
różnych opcji z menu, powodujących wywołanie odpowiednich komend na karcie, a zakończenie pracy
jest powodowane świadomym wybraniem w menu opcji wyjścia z programu.
4.1. Narzędzia i rodzaje plików
Pliki źródłowe terminala i apletu posiadają rozszerzenie *.bas. Po kompilacji powstaje plik *.exe terminala i plik *.img apletu. Następnie aplet zapisywany jest na karcie za pomocą narzędzia bcload.exe.
Producent dołącza kod źródłowy bcload.bas i z jego analizy wynika, że program ten wykorzystuje predefiniowaną komendę WRITEEEPROM. Tak więc teoretycznie możliwe jest samodzielne i bezpośrednie
zapisywanie danych w pamięci EEPROM na karcie, ale producent tego nie poleca i szyfruje tę komendę.
Aby móc symulować działanie terminala i karty bez wykorzystania fizycznego czytnika i karty, również
terminal musi być skompilowany do postaci *.img. Należy wtedy uruchomiać zcmsim.exe i jako parametry podawać nazwę terminala i apletu (ZCMSim -Ckarta -W -L terminal). Co ważne, zmiany zawartości
EEPROM są przechowywane pomiędzy kolejnymi symulowanymi uruchomieniami.
Istnieje również możliwość debugowania kodu terminala i karty, tak ważna z punktu widzenia programisty i analizy działania kodu na karcie. W tym celu jednoczenie używany jest zcmdcard.exe dla apletu
i zcmdterm.exe dla terminala. Po uruchomieniu terminala i wywołaniu komendy, śledzenie może przejść
do apletu i pozwala na krokowe wykonywanie poleceń z jednoczesnym podglądem wartości zmiennych.
4.2. Typy
Istnieje 5 typów prostych:
• Byte – długość 1 bajt, zakres 0-255,
• Integer – długość 2 bajty, zakres od -32768 do 32767,
• Long – długość 4 bajty, zakres –2147483648 do +2147483647,
• Single – długość 4 bajty, zmiennoprzecinkowy,
• String – długość do 254 bajtów, aby sprecyzować długość można używać String*n, gdzie n to
liczba od 1 do 254.
Zmienne tych typów możemy albo deklarować, np.: Private rozmiar As Integer, Public system As String*24, albo używać bez deklaracji dodając na końcu nazwy odpowiednie oznaczenie typu, tj.: @ dla Byte,
% dla Integer, & dla Long, ! dla Single, $ dla String, np.: rozmiar%, system$.
Statyczną zmienną tablicową deklarujemy następująco: zmienna_tab (rozmiar1[,rozmiarn]) As typ_
prosty, gdzie rozmiarn to rozmiary w poszczególnych wymiarach. Dodanie Dynamic w deklaracji tablicy
powoduje zadeklarowanie tablicy dynamicznej.
Jeśli zmienne w kodzie apletu zadeklarujemy jako zmienne Eeprom, np.: Eeprom namessize As Integer,
zmienne te będą trwale zapamiętane i ich wartość dostępna podczas każdej komunikacji z terminalem.
Niestety, w przypadku dynamicznych tablic Eeprom, podczas zmiany ich rozmiaru funkcją ReDim, następuje utrata dotychczasowej zawartości. Tym samym, aby trwale przechowywać na karcie zbiory informacji, należy wykorzystać tablice statyczne lub pliki.
27
4.3. Wyrażenia
Instrukcja podstawienia i porównania to znak „=”. Instrukcja warunkowa to konstrukcja If warunek
Then … Else … End If. Pętla typu for ma postać For i = x To y … Next i. Pętla typu do ma postać Do …
Loop While warunek, a pętla typu while ma postać While warunek …. Wend.
4.4. Funkcje, procedury, komendy
W BasicCard, jak w innych językach programowania, funkcja to fragment kodu, którego wykonanie
powoduje otrzymanie konkretnej wartości. Definicja funkcji ma postać Function nazwa_funkcji (parametry) As typ_zwracany … End Function. Procedura tylko wykonuje fragment kodu i jej definicja ma
postać: Sub nazwa_procedury (parametry) … End Sub. Odmienność w stosunku do innych języków
programowania stanowi w BasicCard komenda. Z punktu widzenia kodu źródłowego jest to procedura,
która zwraca wartość. Komendy używane są do komunikacji terminal <-> aplet. Definiowane są w apletach, a deklarowane i wywoływane w terminalach. Definicja komendy wygląda następująco: Command
bajt_CLA bajt_INS nazwa_komendy (parametry) … End Command. Podane heksadecymalnie bajty CLA
i INS muszą być unikalne i wykorzystywane są w komunikacji terminal<-> karta. Wszystkie predefiniowane komendy w BasicCard mają wartość CLA równą „&HC0”. Deklaracja komendy wygląda następująco:
Declare Command bajt_CLA bajt_INS nazwa_komendy (parametry).
Aby wywołać funkcję, „tradycyjnie” używamy jej nazwy. Aby wywołać procedurę, używamy konstrukcji Call nazwa_procedury(parametry) albo tylko nazwy procedury. Aby wywołać komendę, używamy
konstrukcji Call nazwa_komendy(parametry) albo tylko nazwy komendy. W pierwszym przypadku, po
wykonaniu, sprawdzamy wartość predefiniowanych zmiennych SW1 i SW2 (lub SW1SW2), w drugim
przypadku, po wykonaniu, sprawdzamy wartość zmiennej, do której przekazujemy wynik wywołania komendy. Oba sposoby mają na celu przechwycić błędne wykonanie komendy, np.: błąd w komunikacji
z kartą.
Obsługa plików
System plików opiera się na katalogach. Bezwzględne nazwy plików mogą mieć maksymalnie 254
znaki. Dysk karty oznaczony jest jako „@”. Dostępne są 3 sytuacje operacji plikowych: terminala na komputerze, terminala na karcie, apletu na karcie. Dostępne są m.in. następujące polecenia:
• MkDir – utworzenie,
• RmDir – usunięcie katalogu,
• ChDir – zmiana katalogu bieżącego,
• ChDrive – zmiana bieżącego dysku,
• CurDir – odczyt katalogu bieżącego,
• Name – zmiana nazwy pliku/katalogu,
• Open – otwarcie(utworzenie) pliku,
• Close – zamknięcie pliku,
• Print – zapis do pliku,
• Write – binarny zapis do pliku,
• Input, Line Input – odczyt z pliku,
• Get – odczyt z pliku binarnego.
Pliki, dzięki możliwości przechowywania zmiennej ilości informacji, stanowią elastyczne rozwiązanie
zapisu danych na karcie, czyli w pamięci EEPROM.
28
5. Przykładowe ćwiczenia
Wymienione poniżej zagadnienia mają na celu opanowanie przez studentów metodologii programowania kart elektronicznych i poznania możliwości języka ZC-Basic.
5.1. System plików
Ważne, aby uczący się zdecydowanie rozróżniali aplikacje terminala i apletu. W tym celu proponuje
się, aby na początku przygotować programy wykonujące podstawowe operacje na systemie plików zarówno po stronie terminala jak i apletu. Program terminala może mieć postać menu z wyborem tworzenia i usuwania katalogów i plików, na karcie i na komputerze. Należy zwrócić uwagę na sprawdzanie błędów wykonania, przede wszystkim użycie predefiniowanych standardowych procedur CheckSW1SW2()
i CheckFileError() oraz przekazywanie kodu błędu z apletu do terminala.
5.2. EEPROM
Kolejnym etapem powinno być wprowadzenie zmiennych typu Eeprom jako sposobu na trwałe przechowywanie danych na karcie. Warto sprawdzić zwłaszcza tablice i poznać ograniczenie tablic dynamicznych. Jednocześnie to samo zadanie wykorzystujące zmienne Eeprom można porównać z zadaniem
wykorzystującym pliki. Ten etap pokazuje, jak szybko można zapełnić dostępną pamięć, ponieważ już na
etapie kompilacji kompilator wyświetla procent zajętej pamięci.
5.3. Bezpieczeństwo
W momencie, gdy studenci potrafią tworzyć terminale i aplety, powinni zastanowić się na bezpieczeństwem przechowywanych danych. Należy zaproponować prosty mechanizm autoryzacji użytkownika, np. hasło zapisane w zmiennej Eeprom i blokowanie użycia karty po błędnych kilku logowaniach.
Wszystkie dane użytkownika przechowywane na karcie powinny być zapisane w postaci zaszyfrowanej.
Dla hasła należy użyć funkcji skrótu SHA-1(256), dla innych danych algorytmu DES(DES3). Oba algorytmy
dostępne są w zc-basic jako funkcje, odpowiednio ShaHash() i Des().
Po opanowaniu powyższych zagadnień w sposób naturalny pojawia się u studentów pytanie, czy
dane karty można zmodyfikować lub chociaż odczytać bez konieczności użycia dedykowanej aplikacji
terminala i komend wzajemnej komunikacji z apletem karty. Dlatego warto w tym momencie przedstawić predefiniowane komendy systemu operacyjnego karty oraz stany karty, w jakich może się ona
znaleźć. W przypadku BasicCard wyróżniamy następujące stany:
• NEW – stan zanim ZeitControl skonfiguruje kartę, np. uaktualni system operacyjny,
• LOAD – po konfiguracji przez ZeitControl, w takim stanie kartę otrzymuje programista,
• PERS – stan występuje w kartach Professional i MultiApplication, można tworzyć pliki, bez uruchamiania kodu,
• TEST – przeznaczony do testowania kodu, identyczny z RUN, można go zmienić,
• RUN – stan, w którym niemożliwe staje się dalsze programowanie karty, nie można go zmienić.
W poszczególnych stanach dostępne tylko wybrane predefiniowane komendy, co przedstawia tabela
2 zawierająca najbardziej przydatne komendy.
29
Komenda
GET STATE
EEPROM SIZE
CLEAR EEPROM
WRITE EEPROM
READ EEPROM
SET STATE
START ENCRYPTION
END ENCRYPTION
FILE IO
Opis komendy
Poznanie stanu
NEW
X
LOAD
X
Poznanie rozmiaru EEPROM
X
X
Wyczyszczenie EEPROM
X
X
Zapis w EEPROM
X
X
Odczyt EEPROM
X
X
Zmiana stanu
X
X
PERS
X
Rozpoczęcie automatycznego
szyfrowania komunikacji
Zakończenie automatycznego
szyfrowania komunikacji
Wydanie polecenia plikowego
X
X
TEST
X
RUN
X
X
X
X
X
X
X
X
Tab. 2 Przydatne predefiniowane komendy systemu operacyjnego
Jak widać, po zmianie stanu karty już na PERS/TEST niemożliwy jest odczyt, zapis i zerowanie pamięci
EEPROM. Producent pozwala na awaryjny odczyt szyfrowany kluczem zerowym. Proponuje się przetestowanie przez studentów kilku niewielkich terminali wykorzystujących predefiniowane komendy.
5.4. Projekt
Poszczególne ćwiczenia powinny zakończyć się miniprojektem. Studenci mogą zaimplementować
indywidualną aplikację przechowującą hasła jednorazowe do posiadanego konta w banku lub przechowującą hasła do kont pocztowych. Innym pomysłem jest system obsługi klientów klubu fitness, w którym
symuluje się wykorzystanie przyznanego limitu na karcie.
Podsumowanie
Karty elektroniczne BasicCard firmy ZeitControl stanowią przejrzyste i elastyczne narzędzie pracy dla
programisty i wydają się być wystarczającą pomocą naukową dla studentów poznających zasady programowania procesorowych kart elektronicznych. Aby zapewnić studentom pełną wiedzę z tej dziedziny,
można zaprezentować Java Card Framework i wykonać analogiczne ćwiczenia jak dla BasicCard. Warto
w obu technologiach wprowadzić Public Key Infrastructure. Przydatnym wydaje się stworzenie przejrzystego zestawienia wszystkich producentów kart, ich systemów operacyjnych oraz dostępnych API i IDE.
Bibliografia
[1]Almex Ltd., HealthONE-Health Smart Card Presentation,
http://www.smartcardsource.com/pdf/HealthONE_Presentation.ppt
[2]Almex Ltd., „Health smart cards – medical cards” – http://www.smartcardsource.com/health.htm
[3]Almex Ltd., „Smart Card Software – out of the box software solutions” –
http://www.smartcardsource.com/software.htm
[4]ZeitControl, „Products and Applications using BasicCard”,
http://www.basiccard.com/index.html?basicapp.htm
[5]Soliatis, „Personalization Smart card Solutions, Development offering smart card application, Security smart card application”, http://www.soliatis.com/index.php?page=services&localisation=gb
[6]SnakeCard, „SnakeCard home – Source Code”,
http://www.snakecard.com/Source/Applets/BasicCard/GINQ%20SOLO%20BC/
[7]ZeitControl, „Overview”, http://www.basiccard.com/
[8]BasicCard Development Software, http://www.basiccard.com/index.html?instkit.htm
[9]Nazimek, P. Inżynieria programowania kart inteligentnych. Warszawa: Politechnika Warszawska, 2004
30
mgr inż. Marek Gosławski
Międzyuczelniane Centrum Personalizacji Legitymacji Studenckiej Politechniki Poznańskiej
Pl. Marii Skłodowskiej-Curie 5, Poznań
Uniwersalna aplikacja biblioteczna
na Elektronicznej Legitymacji Studenckiej
1 Wstęp
Identyfikacja czytelników jest podstawową funkcjonalnością systemów wspomagających pracę bibliotek (dla uproszczenia nazywanych dalej „systemami bibliotecznymi”). W większości przypadków odbywa
się ona na podstawie odczytanego, nadrukowanego na kawałku tektury lub karcie, kodu kreskowego stanowiącego identyfikator czytelnika w danej bibliotece. I chociaż pojawiły się już „jaskółki” w postaci zapisu
identyfikatora w strukturze plików karty elektronicznej, co stanowi krok milowy w postępie technologicznym, nadal nie wykorzystują one możliwości, jakie oferuje przejście na nowy nośnik informacji. W niniejszej
pracy przedstawiono propozycję realizacji elektronicznej karty bibliotecznej o rozszerzonej funkcjonalności.
W rozdziale 2 przedstawiono założenia funkcjonalne aplikacji. Wykorzystywane standardy, strukturę plików
aplikacji i ich zawartość oraz zagadnienia związane z prawami dostępu i rozmiarem plików zawarto w rozdziale 3. Dotychczasowe działania podjęte w celu wdrożenia aplikacji opisano w rozdziale 4.
2 Założenia funkcjonalne
Rozważając możliwe zastosowania aplikacji bibliotecznej należy postawić pytanie: co zatem nowego
powinna wnieść identyfikacja czytelnika na podstawie karty elektronicznej? O ile jeszcze kilka lat temu
wyraźnie widoczna była skłonność użytkowników do „kolekcjonowania” kart plastikowych wszelkiego rodzaju, obecnie, po zapełnieniu często pokaźnych rozmiarów portfeli kartami, występuje tendencja do
zmniejszenia ich liczby do niezbędnego minimum. Najlepiej by jedna karta była przepustką do wielu
miejsc. W omawianym rozwiązaniu proponuje się taką funkcję aplikacji bibliotecznej.
Karta elektroniczna, w której umieszczono oprogramowanie służące do identyfikacji
czytelnika powinna umożliwiać jej użycie w wielu bibliotekach.
Prostą konsekwencją posiadania jednej karty używanej w wielu bibliotekach jest zaistnienie potencjalnej drogi przenoszenia informacji między miejscami, które nie są ze sobą połączone i w żaden automatyczny sposób nie komunikują się między sobą. Znany jest mechanizm „karty obiegowej” wypełnianej
przez studenta kończącego studia. Wypożyczając tylko jedną książkę w tylko jednej bibliotece jest on
zmuszony do odwiedzenia wszystkich miejsc, w których potencjalnie mógł się pojawić i zaistnieć jako
„niesolidny” czytelnik. Wiadomo również jaka jest reakcja studenta, gdy się o tym dowiaduje. Proste rozwiązanie polegające na wymianie informacji między bibliotekami, a najlepiej ich systemami, wyeliminuje
konieczność potwierdzania przez studenta we wszystkich miejscach swojej „niewinności”. Pojawienie się
karty elektronicznej w ilościach masowych (100 tysięcy Elektronicznych Legitymacji Studenckich w Wielkopolsce) umożliwia zapoczątkowanie takiej wymiany już dziś. Ponadto sytuacja, w której w jednej z bibliotek następują okoliczności powodujące, że użytkownik karty nie powinien wypożyczać więcej pozycji
może być ostrzeżeniem dla innych bibliotek. Oczywiście ostateczna decyzja nie powinna zależeć wprost
od tych informacji, ale stanowić ważną przesłankę do jej podjęcia.
Karta elektroniczna powinna być nośnikiem, na którym zapisane
są informacje przydatne przy obsłudze czytelnika.
31
Czytelnicy, którzy nie pamiętają o wypożyczonych pozycjach i nie dotrzymują terminów zwrotów
są dla bibliotek znanym problemem. Także tutaj karta elektroniczna może znaleźć zastosowanie. Skoro
wszystkie wypożyczenia i zwroty następują w obecności czytelnika, to ich historia może zostać na karcie
zapisana, a następnie odczytana w dowolnym momencie i miejscu. Te informacje mogą skłonić czytelnika do swoistej refleksji: „gdzie te książki mam i dlaczego jeszcze ich nie oddałem”?
Karta elektroniczna powinna czytelnikowi umożliwiać sprawdzenie historii ostatnich
wypożyczeń i zwrotów niezależnie od miejsca wypożyczenia i zwrotu.
3 Specyfikacja
Założenia funkcjonalne przedstawione w rozdziale 2 można zrealizować na wiele sposobów. Jedną
z najszybszych i najskuteczniejszych dróg prowadzących do celu jest ta, która wykorzystuje przetestowane rozwiązania znane z Systemu Elektronicznej Legitymacji Studenckiej: aplikacja o określonym identyfikatorze, realizowana w strukturze plikowej, zapisująca dane kodowane w standardzie ASN.1 chronione
za pomocą mechanizmów dostępnych w tych systemach. Przedstawiona poniżej specyfikacja obejmuje
omówienie standardów, struktury plików, zawartości plików oraz praw dostępu. Ponadto zaproponowano alternatywny zestaw plików i oszacowano maksymalny rozmiar aplikacji.
3.1 Standardy
3.1.1 ISO/IEC 7816-4
W normie określono zawartość komunikatów, poleceń i odpowiedzi przesyłanych przez urządzenie
interfejsowe do karty i odwrotnie, strukturę i zawartość bajtów historycznych, strukturę plików (zbiorów)
i danych, metody dostępu do plików (zbiorów) i danych w karcie, architekturę zabezpieczeń określającą
prawa dostępu do plików (zbiorów) i danych w karcie [4].
Z punktu widzenia aplikacji bibliotecznej szczególnie istotne są elementy związane ze strukturą plików oraz sposobami dostępu do nich. Norma rozróżnia plik dedykowany (DF) i plik elementarny (EF) jako
dwie podstawowe kategorie plików występujące w logicznej organizacji plików na karcie (Rysunek 1).
Rysunek 1 Przykład logicznej organizacji plików na karcie wg ISO/IEC 7816-4
Każdy z plików elementarnych może posiadać jedną z czterech określonych w normie struktur (Rysunek 2). Każda ze struktur została szczegółowo opisana w przywołanej normie.
Rysunek 2 Struktury pliku elementarnego
Dostęp i manipulowanie informacjami zawartymi w plikach jest możliwy dzięki poleceniom i odpowiedziom przesyłanym przez urządzenie interfejsowe do karty i odwrotnie – jednostkom danych pro32
tokołu aplikacji (ang. APDU, Aplication Protocol Data Unit). Polecenia zdefiniowane w normie składają
się z obligatoryjnego, czterobajtowego nagłówka i opcjonalnej części głównej (Rysunek 3). Nagłówek
zawiera informacje o klasie instrukcji (CLA) określającej m.in. w jakim stopniu polecenie jest zgodne z opisywaną normą, o instrukcji (INS) oraz o jej parametrach (P1, P2). Opcjonalna część główna może zawierać
informację o liczbie bajtów występujących w polu danych (Lc), pole danych (Data field) oraz informację
o maksymalnej liczbie bajtów oczekiwanych w polu danych odpowiedzi (Le).
Rysunek 3 Struktury polecenia i odpowiedzi APDU
Norma określa także jakie mogą być stosowane mechanizmy zabezpieczenia. Jedną z nich jest uwierzytelnianie podmiotu za pomocą klucza, w której uwierzytelniany podmiot powinien udowodnić znajomość klucza w procedurze uwierzytelniania. Dopuszczane jest również stosowanie szyfrowania danych
zawartych w polu danych.
W trakcie działania aplikacji bibliotecznej wykorzystywane będzie niewielki podzbiór poleceń zawartych w normie. Głównie będą to operacje polegające na wybraniu pliku (SELECT FILE) i odczytaniu jego
zawartości (READ BINARY), polegające na zapisaniu informacji w pliku (UPDATE BINARY), a także związane z uwierzytelnieniem (GET CHALLENGE i EXTERNAL AUTHENTICATE).
3.1.2 ISO/IEC 7816-5
W normie podano definicje podstawowych pojęć związanych z systemem numeracji identyfikatorów
aplikacji. Ustalono kategorie rejestracji rozszerzające zbiór kategorii wprowadzonych normą ISO/IEC 7812.
Określono sposób kodowania identyfikatorów aplikacji, a także sposób wykorzystania elementów danych
do wyboru zidentyfikowanej na karcie elektronicznej aplikacji. Określono wstępnie zasady organizacyjne
rejestracji identyfikatorów aplikacji akceptowanych w międzynarodowej wymianie informacji [5].
Rysunek 4 przedstawia znaczenie poszczególnych pozycji numeru identyfikujące dostawcę karty i dostawcę aplikacji. Litera D (4 bity) będąca pierwszym znakiem identyfikatora wskazuje numerację w systemie krajowym, trzy kolejne cyfry (12 bitów) wskazują kraj (np. 616 to kod Polski), który rejestruje wydawcę
karty i dostawcę aplikacji a kolejne (24 bity) są określane przez operatora narodowego. Identyfikator może
zawierać także 11 bajtów określonych przez dostawcę aplikacji.
Rysunek 4 Zapis AID
3.1.3 ASN.1 (Abstract Syntax Notation number One)
„Abstrakcyjna Notacja Składniowa numer Jeden jest standardem służącym do opisu struktur przeznaczonych do reprezentacji, kodowania, transmisji i dekodowania danych. Dostarcza zbiór formalnych zasad
pozwalających na opis struktur obiektów w sposób niezależny od konkretnych rozwiązań sprzętowych.” [3]
Każdy obiekt zdefiniowany jest za pomocą trzech podstawowych elementów: typu – określającego zbiór
potencjalnych wartości jakie może przyjmować obiekt, długości – określającej liczbę bajtów danych oraz
wartości – stanowiącej określone wystąpienie danego typu. [1]
33
Przedstawienie całości norm składających się na ASN.1 nie jest w tym miejscu możliwe i celowe, warto
jednak przynajmniej przybliżyć typy, które zostały użyte w specyfikacji.
ENUMERATED
określa zbiór wartości nadany różnym identyfikatorom
INTEGER
reprezentuje wartości całkowite liczbowe bez ograniczeń co do ich wielkości
PrintableString
zawiera małe i duże litery, cyfry, znaki interpunkcyjne oraz odstęp
SEQUENCE
modeluje uporządkowaną kolekcję zmiennych różnych typów
SEQUENCE OF
modeluje uporządkowaną kolekcję zmiennych tego samego typu
SET
modeluje nieuporządkowaną kolekcję zmiennych różnych typów
SET OF
modeluje nieuporządkowaną kolekcję zmiennych tego samego typu
UTCTime
czas uniwersalny
UTF8String
zawiera znaki całego alfabetu
Tabela 1 Wykorzystywane typy ASN.1
3.2
Struktura plików
Rysunek 5 Struktura plików aplikacji bibliotecznej
W ramach aplikacji bibliotecznej została zaproponowana struktura plików przedstawiona na rysunku
5. Korzeniem aplikacji jest plik dedykowany DF.ELIB, możliwy do wskazania przez jego nazwę stanowiącą
unikalny identyfikator aplikacji zgodny z częścią piątą normy ISO/IEC 7816, zarejestrowany w Krajowym
Rejestrze Kart Identyfikacyjnych.
Niżej w strukturze katalogowej umieszczono transparentne pliki elementarne zawierające informacje
konfiguracyjne (EF.CONFIG), identyfikatory czytelnika w kolejnych bibliotekach (EF.ID), historię wypożyczeń i zwrotów (EF.EVENT) oraz informacje przydatne przy obsłudze czytelnika (EF.LOCK).
Aplikacja biblioteczna powinna być umieszczona w katalogu głównym (MF). Dopuszcza się jednak jej
umieszczenie w innym katalogu, na przykład DF.SELS. Wówczas będzie ona miała tylko lokalny zasięg.
3.3 Zawartość plików
3.3.1 EF.CONFIG
Plik EF.CONFIG o krótkim identyfikatorze 00 01 zawiera parametry konfiguracyjne aplikacji takie jak rodzaj aplikacji (FILE lub APPLET) oraz jej wersja. Założono, że plik może zawierać do dziesięciu parametrów
konfiguracyjnych zapisanych jako para składająca się z nazwy parametru i jego wartości. Maksymalny
założony rozmiar pliku to 262 bajty.
34
EF.CONFIG :: = SET SIZE (1..10) OF Param
Param ::= SEQUENCE {
param_name
param_value
}
PrintableString (SIZE (1..10)),
PrintableString (SIZE (1..10))
3.3.2 EF.ID
Plik EF.ID o krótkim identyfikatorze 01 00 zawiera identyfikatory czytelnika w kolejnych bibliotekach.
Przy założeniu, że czytelnik będzie korzystał z 10 bibliotek rozmiar pliku nie przekroczy 412 bajty.
Id ::= SEQUENCE {
library
id
}
EF.ID :: = SET OF Id
PrintableString (SIZE (1..20))
3.3.3 EF.EVENT
Plik EF.EVENT o identyfikatorze 02 00 zawiera historię wypożyczeń i zwrotów dokonanych w poszczególnych bibliotekach. Założono, że zawarte w pliku informacje dotyczą ostatnich dziesięciu zdarzeń. Maksymalny założony rozmiar pliku to 2152 bajty.
EF.EVENT :: = SET SIZE (1..10) OF Event
Event ::= SEQUENCE {
library
date
book
event
}
UTCTime,
Book,
INTEGER
Book ::= SEQUENCE {
book
book_title
book_author
}
UTF8String (SIZE (1..50)),
UTF8String (SIZE (1..25))
3.3.4 EF.LOCK
Plik EF.LOCK o identyfikatorze 03.00 zawiera informacje przydatne przy obsłudze czytelnika. W strukturze pliku występuje niezależna od biblioteki informacja o założonych blokadach działająca na zasadzie
semafora. Biblioteka zakładająca określona blokadę zwiększa wartość licznika na określonej pozycji o jeden, biblioteka zdejmująca blokadę zmniejsza wartość tego licznika o jeden. Plik zawiera również szczegółową informację pochodzącą z danej biblioteki: datę ważności konta, datę pojawienia się czytelnika
w bibliotece, szczegółowe informacje o założonych grupach blokad oraz liczbę wypożyczonych książek.
Przy korzystaniu z nie więcej niż dziesięciu bibliotek rozmiar pliku nie przekroczy 2387 bajtów.
EF.LOCK :: = SEQUENCE {
lock_vector
SEQUENCE SIZE (1..7) OF INTEGER,
SET SIZE (1..10) OF Lock
}
Lock ::= SEQUENCE {
library
expire_date
use_date
lock_info
books_count
}
LockInfo ::= SEQUENCE
lock_type
lock_id
lock_date
}
UTCTime,
UTCTime,
SET SIZE (1..7) OF LockInfo,
INTEGER
{
LockType,
INTEGER,
UTCTime
35
LockType ::= ENUMERATED {
nocko (1),
-– blokada główna („ogólna”)
od (2),
-– przeterminowanie
l (3),
-– (lost) zagubienie materiałów
damage (4), -– zwrócił uszkodzone materiały
suspens (5), -– zawieszenie
fee (6),
-– nieuregulowana opłata
fine (7) -– nieuregulowana kara
}
3.4 Prawa dostępu
Każda biblioteka korzystająca z aplikacji bibliotecznej przed uzyskaniem możliwości korzystania z informacji zawartych w karcie powinna się uwierzytelnić. Biblioteka powinna mieć indywidualny klucz
(lub zestaw kluczy) umożliwiający wykonywanie operacji w strukturach aplikacji bibliotecznej. Oczywiście operując na tych samych strukturach biblioteki muszą mieć do siebie nawzajem zaufanie, bo każda
z nich będzie zastępować wpisy innych.
Przygotowanie karty do używania w bibliotece może nastąpić na dwa sposoby. Pierwszym z nich
jest przygotowanie odpowiednich struktur w trakcie personalizacji, drugim jest wykonanie tych samych
czynności w terminalu biblioteki. Druga opcja wymaga połączenia z Centrum Personalizacji w trakcie
przygotowywania karty. Dalsze działania są wykonywane w bibliotece bezpośrednio przez oprogramowanie danej biblioteki i nie jest wymagane połączenie z Centrum Personalizacji.
System plików kart Gemalto (GemXPresso Pro) każdemu z plików pozwala przypisać do ośmiu kluczy,
co ogranicza zastosowanie tej karty do ośmiu bibliotek, w których czytelnik może być zapisany. Karty
Oberthur (ID-One) umożliwiają łączenie kluczy warunkami logicznymi co praktycznie zapewnia możliwość dołączenia dowolnej liczby bibliotek.
3.5 Alternatywny zestaw plików
Rozważany był również inny układ plików. Każda z bibliotek dysponowałaby „własnym” katalogiem ze
strukturą zbliżoną do opisanej powyżej. Z jednej strony organizację i zarządzanie bezpieczeństwem takiej
karty jest łatwiejsza, bo każda biblioteka operuje w udostępnionym sobie obszarze, z drugiej utrudniony
jest dostęp do informacji i ich wymianę między bibliotekami oraz użytkownikiem. Rozważając wszystkie
wady i zalety obu rozwiązań zdecydowano się rozwiązanie przedstawione w punkcie 3.3.
3.6 Maksymalny rozmiar aplikacji
Bardzo istotne jest określenie maksymalnej wielkości aplikacji. Nie wszystkie implementacje systemu
plików na karcie umożliwiają jego rozszerzanie w miarę przybywania danych. Może to prowadzić do sytuacji, w której niewłaściwe oszacowanie rozmiarów plików uniemożliwi pełne korzystanie z aplikacji.
Maksymalny rozmiar aplikacji w wersji pierwszej może wynieść 5213 bajtów. Oczywiście w trakcie
„normalnego” działania, gdzie użytkownik będzie identyfikowany przez dwa, może trzy systemy biblioteczne rozmiar plików będzie wynosił mniej niż połowę podanego.
Dodatkowo należy uwzględnić konieczność utworzenia plików zawierających klucze uwierzytelniające poszczególnych bibliotek i ich rozmiar. Jest on jednak uzależniony od zastosowanego nośnika.
4 Wdrożenie
Przedstawiona w rozdziale 3 specyfikacja może zostać poddana praktycznej weryfikacji. Wcześniej
jednak należy uzyskać numer jednoznacznie określający, że struktura umieszczona w pamięci karty elektronicznej jest aplikacją biblioteczną.
36
Na podstawie „Wniosku o przydzielenie identyfikatora zarejestrowanego dostawcy aplikacji” [2] złożonego przez Politechnikę Poznańską przydzielony został identyfikator aplikacji bibliotecznej opisanej jako
„aplikacja umożliwiająca identyfikację zarejestrowanego czytelnika Biblioteki prowadzącej czasowe wypożyczenia woluminów oraz odczytanie z bufora zdarzeń przechowywanego w pamięci układu elektronicznego karty elektronicznej od trzech do pięciu ostatnich wypożyczeń dokonanych przez użytkownika
karty – zarejestrowanego czytelnika biblioteki”. Rejestracja nastąpiła w Krajowym Rejestrze Kart Identyfikacyjnych pod numerem D6 16 00 00 40 (dla przypomnienia aplikacja ELS został przydzielony numer D6
16 00 00 30). Nadanie numeru identyfikacyjnego kosztuje wg stanu aktualnego 250 zł netto i takie też są
koszty jego utrzymania przez każdy kolejny rok.
Po złożeniu wniosku i uzyskaniu numeru AID przystąpiono do implementacji obsługi aplikacji w wybranym systemie bibliotecznym. Jest ona w trakcie realizacji
5 Podsumowanie
Konieczność stworzenia uniwersalnej aplikacji bibliotecznej wydaje się oczywista. Zalety jej wdrożenia mogą przynieść wymierne korzyści zarówno dla bibliotek jak i ich czytelników.
Prace związane z wdrożeniem obsługi aplikacji bibliotecznej są już dalece zaawansowane. W niedługim czasie powinna pojawić się możliwość dołączenia jej do profilu podstawowego dla Elektronicznej
Legitymacji Studenckiej. Plany wykorzystania przydzielonego identyfikatora aplikacji bibliotecznej są dalej idące. Do pełni szczęścia brakuje wykonania „wersji drugiej” aplikacji w oparciu o technologię JavaCard,
określenie zestawu poleceń i odpowiedzi APDU operujących na danych przechowywanych w pamięci
karty, a także opracowanie generalnej metody umożliwiającej przejście z aplikacji wykonanych w strukturze plikowej do tych wykonanych w technologii JavaCard. Rozważane jest także „otwarcie źródeł” oraz
certyfikacja stworzonego rozwiązania.
5 Podziękowania
Autor dziękuje Andrzejowi Tadychowi (Politechnika Poznańska, Międzyuczelniane Centrum Personalizacji Legitymacji Studenckiej), Tomaszowi Kokowskiemu (Politechnika Poznańska, Centrum Zarządzania
Siecią Komputerową), Krzysztofowi Oberowi (Politechnika Poznańska, Biblioteka Główna) oraz Marcinowi
Majorkowskiemu (INFORMA) za czas poświęcony na dyskusje oraz przyczynienie się do ustalenia ostatecznego formatu pierwszej wersji aplikacji bibliotecznej.
6 Literatura
1. Kosmulska–Bochenek E., Wymiana informacji w heterogenicznych systemach sieciowych - język
ASN.1, wyd. 1, Wrocław, Wydawnictwa Politechniki Wrocławskiej 2002
2. Krajowy Rejestr Kart Identyfikacyjnych, http://www.krki.pl/
3. Wikipedia, wolna encyklopedia, http://pl.wikipedia.org/
4. PN-EN ISO/IEC 7816-4:1998, Technika informatyczna. Karty identyfikacyjne. Elektroniczne karty
stykowe. Struktury danych i poleceń komunikacyjnych.
5. PN-EN ISO/IEC 7816-5+A1:1998, Karty identyfikacyjne. Elektroniczne karty stykowe. System numeracji i procedura rejestracji identyfikatorów aplikacji
37
Notatki
38
Notatki
39
Międzyuczalniane Centrum Personalizacji
60-965 Poznań, pl. M. Skłodowskiej - Curie 5
www.mcp.poznan.pl

materiały konferencyjne - Międzyuczelniane Centrum Personalizacji

Transkrypt

Podobne dokumenty

folder wersja pdf - Międzyuczelniane Centrum Personalizacji

pOSzUkiwany naStĘpca! - Gazeta Studencka

Katalog Produktów - Karty Lojalnościowe Bard