European Citizen Card przyszłość rozwiązań eid Dariusz Lewicki dariusz.lewicki@cryptotech.com.pl
CryptoTech Dostawca specjalistycznych rozwiązań i usług z zakresu esecurity Główne obszary zainteresowania: Karty i tokeny elektroniczne aplikacje, middleware, zarządzanie, personalizacja Model PKI i podpis cyfrowy Sprzętowe rozwiązania kryptograficzne Systemy eid VAD, VAR, Integrator czołowych dostawców technologii esecurity Producent i integrator własnych rozwiązań (security software & hardware) Od 1999 roku pod nazwą CryptoTech; obecnie w grupie Asseco Wybrane sukcesy: systemy PKI dla 3 z 4 kwalifikowanych CA w PL + w Centrast (TSA i VA) systemy PKI dla centralnej administracji rządowej CryptoCard PKI/multiSIGN - wiodące rozwiązanie kartowe dla PKI w Polsce wiodący producent rozwiązań typu crypto hardware middleware
Skąd pomysł ECC? Manchester Ministerial Declaration (Grudzień 2005) WIDELY AVAILABLE, TRUSTED ACCESS TO PUBLIC SERVICES ACROSS THE EU, THROUGH MUTUALLY RECOGNISED ELECTRONIC IDENTIFICATIONS By 2010 European citizens and businesses shall be able to benefit from secure means of electronic identification that maximize user convenience while respecting data protection regulations. Such means shall be made available under the responsibility of the Member States but recognised across the EU By 2010 Member States will have agreed a framework for reference to and where appropriate the use of authenticated electronic documents across the EU, as appropriate in terms of necessity and applicable law
Uzasadnienie dla ECC Wg Manchester Ministerial Declaration (Grudzień 2005): Usługi egovernment stają się bardziej transakcyjne, dlatego podstawową staje się potrzeba stosowania bezpiecznej i zaufanej metody elektronicznej identyfikacji przy dostępie do usług publicznych i jest to potrzeba zarówno obywateli jak i organizacji/firm oraz jest to niezbędne dla zapewnienia efektywności administracji publicznej. Podstawą przyszłego rozwoju egovernment jest akceptacja różnych from eid dla osiągnięcia interoperacyjności Interoperacyjne eid bazujące na ugruntowanych standardach międzynarodowych i sprawdzonych technologiach powinny być podstawą bezpiecznych, transgranicznych usług egovernment Innymi kluczowymi składnikami rozwoju egovernment powinny być: uznawanie dokumentów elektronicznych elektroniczne archiwa dokumentów eid, oparte uzgodnionych standardach bezpieczeństwa, mogą być wydawane i zarządzane na poziomie narodowym, regionalnym lub lokalnym, wspierając mobilność obywateli i elastyczność rynków pracy
Dokument identyfikacyjny vs eid ID (identity of an entity) tożsamość dynamiczny zestaw wszystkich atrybutów opisujących osobę, organizację lub system eid elektroniczna tożsamość egzystuje tylko w świecie systemów informatycznych Dokument identyfikacyjny służy do identyfikacji osoby w świecie realnym nawet jeśli posiada układ elektroniczny! (to pewne uproszczenie ) Źródło Konstantin Hyppönen
Dlaczego karta elektroniczna dla eid? Rosnące znaczenie transakcji H2H (Human-to-Human) lub H2M (Human-to- Machine) będzie wymagało lokalnej weryfikacji tożsamości użytkownika w trybie offline Rozwój technologii bezkontaktowych dodatkowo otwiera drogę dla wielu nowych aplikacji skoncentrowanych na prędkości i mobilności realizacji transakcji (w dowolnym miejscu i dowolnym czasie) Przyszłe aplikacje klasy M2M będą bazowały na osadzonych modułach bezpieczeństwa (np. TPM) wymuszających realizację odpowiednich reguł i podejmujących określone działania ochronne Optymalne połączenie bezpieczeństwa i kosztów Oparte na sprawdzonych standardach aktywne urządzenie zabezpieczające funkcje eid Konstantin Hyppönen
Bazowe cele zdefiniowania ECC Identyfikacja i zaufanie do zdalnych procedur w ramach C2G Powstanie komponentów sprzętowych i programowych obsługujących zestaw funkcji IAS ogólnego przeznaczenia zdefiniowanych w ramach stosownych specyfikacji/standardów Przygotowania szerokiego rynku układów elektronicznych wspierających wymagania aplikacji kart realizujących wymagane w ramach ECC zadania Wsparcie dla wielu opcji implementacji: High speed USB Contactless lub Dual Interfaces Biometric Identification Interfejsy WebService Zarządzanie prywatnością Opcjonalne użycie kwalifikowanych certyfikatów Połączenie z dokumentem podróżnym ICAO
Bazowe cele zdefiniowania ECC c.d. Wsparcie dla wielu usług zgodnie z uprawnieniami/ograniczeniami określanymi przez wydawców ECC Platforma ECC przygotowana dla wspierania nowych serwisów realizowanych przez otoczenie ECC Dynamiczne dostosowywanie się karty i terminala do wymagań bezpieczeństwa konkretnych, realizowanych aktualnie transakcji Zdefiniowanie zaleceń i specyfikacji dla interfejsów i otoczenia IT integrującego się z platformą ECC i jej usługami Przygotowanie odpowiednich procesów oceny bezpieczeństwa elementów systemu ECC na bazie istniejących lub rozszerzonych Profili Zabezpieczeń (wg Common Criteria) Zachowanie narodowej autonomii w zakresie wydawania narodowych dokumentów identyfikacyjnych i tożsamości elektronicznych (eid)
Czym jest European Citizen Card? Karta elektroniczna wydana i zarządzana przez instytucję rządową (centralną lub lokalną), która zawiera dane identyfikacyjne w celu realizacji wszystkich lub wybranych usług: Weryfikacja tożsamości Dokument podróżny w ramach EU Ułatwienie dostępu logicznego do usług administracji centralnej lub lokalnej Administracja publiczna może upoważnić organizację prywatną do zapewnienia wszystkich lub wybranych usług ECC ECC jest jedną z metod realizacji eid na bazie technologii karty elektronicznej ECC zawiera/realizuje eid poza innymi zadaniami (np. dokument podróżny zgodny z ICAO)
Cechy ECC Powody polityczne dla powstania ECC (nie tylko techniczne) User centric model karta ECC pod kontrolą posiadacza Interoperacyjność dzięki elastycznemu modelowi middleware i oparciu na otwartych standardach: Wspólny zestaw komend karty i struktur danych ECC część 2 Middleware wyrównujący zewnętrzny wygląd usług kart ECC część 3 Definicja podstawowych profili ECC ECC część 4 Znacząca zgodność z istniejącymi systemami eid w EU przez wysoko adaptacyjną warstwę middleware Pozwala używać w aplikacjach różnych karty z eid poza ECC i stopniową migrację do szerokiego używania kart zgodnych z ECC Zgodność z dyrektywą EU dotyczącą podpisu elektronicznego
Standaryzacja European Citizen Card standard CEN/TS 15480 ECC part 1 : Physical -> opublikowana w maju 2007 Physical, electrical andtransport protocol characteristics ECC part 2 : IAS -> opublikowana w maju 2007 Logical data structures and card services ECC part 3 : Middleware -> w przygotowaniu ECC part 4 : ECC Profiles -> w przygotowaniu Wprowadzana wprost w Polsce przez PKN (norma CEN/TS ma od razu status dokumentu normalizacyjnego PKN) Aktualnie opublikowane części 1 i 2 ECC Part 3 = bazuje na i praktycznie wprowadza ISO 24727 dla ECC
Standaryzacja c.d. ECC CEN/TS 15480 Part2 bazuje na CWA 14890/prEN 14890 z pewnymi dodatkami + konkretny profil zamiast wielu opcji pren 14890-1:2007 Appplication Interface for smart cards used as Secure Signature Creation Devices: Part 1: Basic requirements Part 2: Additional Services ISO/IEC 7816-4:2005, Identification cards Integrated circuit(s) cards Part 4: Organization, security and commands for interchange ISO/IEC 7816-8, Identification cards Integrated circuit cards Part 8: Commands for security Operations ISO/IEC 7816-15, Identification cards Integrated circuit cards with contact Part 15: Cryptographic information application ICAO 9303, Part 1, Machine Readable Passports ICAO 9303, Part 3, Machine Readable Official Documents of Identity
Zakres ECC Wieloczęściowy standard EU (CEN) Implementuje warstwę uwierzytelniania systemów zarządzania eid Uwierzytelnianie bazujące na współdziałaniu karty elektronicznej i oprogramowania middleware Udotępnia usługi bezpieczeństwa realizowane przez kartę dla zewnętrznych aplikacji Specyfikuje: Cechy fizyczne, elektryczne i bezpieczeństwa karty (na bazie ISO 7816) Sposób implementacji middeware Typowe profile zbudowane na bazie głównych usług karty (ICAO traveling card, National ID card, e-government card ) Middleware ukrywa specyficzne detale i technologię ECC przed światem zewnętrznym (aplikacjami) Nie potrzeb znać dokładnie ECC by budować nowe aplikacje Dostawcy usług nie muszą znać detali implementacyjnych kart tym się zajmuje i to unifikuje warstwa middleware
Związek ECC z innymi modelami eidm ECC dostosowuje się naturalnie do dowolnego modelu eidm bazującego na middleware (np. TLS) Zapewnia usługi uwierzytelniania dla dowolnego schematu eidm zawierającego związek ról ID Agenta, ID Provider i Dostawcy Usług Trwają prace nad powiązaniem ECC z istniejącymi schematami eidm takimi jak Liberty Alliance, TLS, Card Space.
Przykładowy profil ECC Usługi świadczone przez kartę/z użyciem karty ICAO Passive Authentication ICAO Basic Access Control EAC Chip Authentication (na bazie Elliptic Curves) EAC Terminal Authentication (na bazie Elliptic Curves) Lokalne uwierzytelnianie urządzenia (offline) Secure messaging do/z karty opcjonalnie: Digital Signature uwierzytelnianie urządzenia Online z/bez uwierzytelnienia użytkownika
Czym jest ECC middleware? Kluczowy element dla osiągnięcia wymaganego poziomu zgodności i współpracy, łączący karty, usługi kartowe, urządzenia akceptujące karty (np. czytniki), sieci i aplikacje Oprogramowanie pomiędzy aplikacjami a kartą Standardowo prezentuje dwa interfejsy API Otwarty interfejs, który umożliwia aplikacjom egovernment połączyć się z warstwą middleware i poprosić o realizację usługi Interfejs karty, który łączy warstwę middleware z konkretną kartą ECC Warstwa uwierzytelniania systemów zarządzania elektroniczną tożsamością (eidm) jest zaimplementowana z użyciem ECC+Middleware Warstwa uwierzytelniania postrzegana jest przez dostawców usług egovernemnt po prostu jako zdefiniowany otarty interfejs programistyczny
ECC middleware Middleware (np. CryptoCard Suite for ECC)
ISO/IEC 24727 ISO/IEC 24727 Identification Cards - Integrated circuit cards programming interfaces Zbudowany na bazie ISO/IEC 7816 Skupia się na usługach i interfejsach Neutralny dla typu karty Niezależny od interfesju karty (stykowy/bezstykowy) eid: usługi identyfikacji, uwierzytelnienia i podpisu cyfrowego Cel: Niezależne i wymienne implementacje middleware
Dlaczego opracowano ISO/IEC 24727? Istniejące standardy middleware: Zbyt wiele opcji Skupiają się na fizycznej karcie elektronicznej Brak standaryzacji interfejsów API Upraszczanie: Uproszczenie życia developerów Polepszenie przenoszalności Interoperacyjność: Wszechstronna interoperacyjność: to co wszyscy próbujemy osiągnąć ale musi być upraszczane na każdym kroku
ISO/IEC 24727-4 Security & API Administration ISO 24727 standard w 5 częściach Client App 1 Client App 2 Client App 3 Client App 4 Test Client- App Testing ISO/IEC 24727-3 cf ISO/IEC 24727-5 Card Service APIs cf ISO/IEC 24727-3 Interface Connectivity Card Service APIs cf ISO/IEC 24727-3 Application API Layer Implementation Part 1 - Architecture Generic Card Interface cf ISO/IEC 24727-2 Testing ISO/IEC 24727-2 cf ISO/IEC 24727-5 Interface Connectivity Generic Card Interface cf ISO/IEC 24727-2 GCI Layer Implementation ISO/IEC 24727-1 Architecture Part 2 - Generic Card Interface Physical Card Services Interface Connectivity Part 3 - Application Programming Interface Interface Device Access Mechanism Interface Device Configuration Selection Part 4 - API Adminstration Card App 1 Card App 2 Card App 3 Test Card App Testing Multi-application ICCs Teresa Schwarzhoff
Card Service API rodzaje usług
Card Service API model obliczeniowy
Card Service API przykład realizacji usługi IAS Initialize() --initialize the interface Path( IAS, request, 0, result) -- get a path to cardapplication. CardApplicationConnect(result, TRUE, handle) -- open a connection Read(PIN) IdentityAuthenticate(handle, GustawPINIdentity, PIN) challengeincertout = <create challenge> IdentityAuthenticate(handle, GustawPKIIdentity, challengeincertout) certificate = challengeincertout Identyfikacja i uwierzytelnienie posiadacza karty Gustaw przez weryfikację PIN a następnie następuje projekcja tożsamości przez użycie mechanizmu PKI
Przykład użycia ECC Gisela_Meister
Przykład transakcji z użyciem ECC Gisela_Meister
MF MF EF.ATR EF.DIR EF.ATR EF.DIR EF.SN DF ESIGN EF.ARR EF.C.CH. AUT EF.C.CH. DS EF.C.CH. ENC EF.C.ICC. AUT EF.DM DF SIG DF eid EF.ARR EF.C.CH. AUT EF.C.CH. QES EF.C.ICC. AUT EF.DM DF QES DF CIA EF.ARR EF.C.CH. QES DF ICAO DF CIA DF.CIA (ISO 7816-15) On-Card Application EF.DIR ACD 24727-2 DF.CIA (ISO 7816-15) On-Card Application EF.DIR ACD 24727-2 France e-government ECC Application DF.CIA Data for Middleware EF.DIR List of Applications + ECC profile ACD Compliance with ISO 24727 Spain e-government ECC Application DF.CIA Data for Middleware EF.DIR List of Applications + ECC profile ACD Compliance with ISO 24727 Lorenzo Gaston
ECC middleware obsługuje wprost kartę Service Provider Data Specific France ECC DF. CIA EF. DIR ACD / CCD ID Provider ( Gov CA) Identification Layer Authentication Layer Middleware Open Interface Commands and responses described in the ECC part 3 standard Open Interface Card Interface DF.CIA (ISO 7816-15) On-Card Application EF.DIR ACD 24727-2 DF.CIA (ISO 7816-15) On-Card Application EF.DIR ACD 24727-2 Data Specific Spain ECC DF. CIA EF. DIR ACD / CCD Lorenzo Gaston
ECC middleware adaptuje się do karty (używając informacji odczytanych z karty) Service Provider ID Provider ( Gov CA) Identification Layer Interface Commands and responses described on ECC part 3 standard Middleware adapted to A Authentication Layer Middleware adapted to B Middleware DF.CIA (ISO 7816-15) On-Card Application EF.DIR ACD 24727-2 DF.CIA (ISO 7816-15) On-Card Application EF.DIR ACD 24727-2 Card Commands and responses described on ECC part 2 standard Lorenzo Gaston
Identification Layer Client application Service Provider 10: ID OK 5: Verify ID e-id Issuer 1: Get ID Request 4 6: Auth ECC Request 9: Auth Resp Standard API Connection/Discovery Services Authentication Services Middleware Libraries: API request into ECC APDU Middleware Card Instruction Layer (Native APDU generation) Middleware Stack 3 2: APDU Get 7: APDU Auth 8: APDU Resp ECC Compliant Card Card Interface Authentication Layer 04/12/2008 Lorenzo Gaston
Pytania dariusz.lewicki@cryptotech.com.pl www.cryptotech.com.pl
Informacje publiczne i prywatne Wymaga PIN Nie wymaga PIN Authentication ID ADDRESS Digital signature MSWiA SIGN MSWiA SIGN
Dokument ICAO np. paszport elektroniczny Fizyczny dokument Datapage Machine Readable Zone (MRZ) Zdjęcie właściciela Zabezpieczenia fizyczne Elektroniczny dokument (RFID) MRZ Dane biometryczne (zdjęcie, odcisk palca, itp.) Zabezpieczenia kryptograficzne
Dokument identyfikacyjny część fizyczna Kontynuacja tradycyjnego dokumentu tożsamości Szereg zabezpieczeń fizycznych niezależnych od dokumentu elektronicznego w układzie stykowym lub bezstykowym karty/paszportu Dodatkowa funkcja zabezpieczająca (czy aby na pewno?) prywatność i dostęp do danych elektronicznych
Dokument identyfikacyjny część elektroniczna Stopniowa migracja w kierunku eid Szereg zabezpieczeń zapewniających: Autentyczność, Integralność, Uwierzytelnienie, Poufność Coraz częściej aplikacja zgodna z ICAO jest tylko jedną z wielu aplikacji na karcie, kolejne to np.: IAS Kwalifikowany podpis elektroniczny Zaawansowany układ elektroniczny dokumentu może obsługiwać także inne aplikacje kartowe (karta zdrowia, płatności, fizyczna kontrola dostępu) Coraz większe znaczenie roli dokumentu identyfikacyjnego dla transakcji i systemów online -> zmniejszające się znaczenie fizycznego dokumentu tożsamości