Presentation on theme: "Med-e-Tel, April 2 nd, 2009 CEN ISSS eEHIC CWA Pantelis Angelidis – on behalf of the CEN/ISSS/WS & PT."— Presentation transcript:
Med-e-Tel, April 2 nd, 2009 CEN ISSS eEHIC CWA Pantelis Angelidis – on behalf of the CEN/ISSS/WS & PT
Med-e-Tel, April 2 nd, 2009 Background Project:"Electronic European Health Insurance Card Documents : PHASE A:Review and validation of the available or required standards for the eEHIC (approved 12-02-2008) PHASE B:CWA (approved 10-03-2009) White Paper
Med-e-Tel, April 2 nd, 2009 3 eEHIC background and context The main features of an electronic EHIC are : –It will carry the same dataset in electronic form that is defined by the data printed on the outside of the EHIC, –it will be electronically read in the premises of the Health Care Providers equipped with appropriate technology –its validity as well as the entitlement of the card holder could, under certain conditions and depending on the Member States, be verified on-line.
Med-e-Tel, April 2 nd, 2009 Phase A decisions CWA guiding principles (1/2) The basis of the work will be the well-known smart card standards (already used as credit/debit cards, phone cards etc., ISO7816 series) The definitions of the health information related standards are used because they already closely reflect the EHIC dataset (e.g. ISO 21549) The use of the Unicode character set where possible. This would practically mean support for all official EU languages and character sets.
Med-e-Tel, April 2 nd, 2009 Phase A decisions CWA guiding principles (2/2) In order to facilitate read-out from new smart cards as well as from already existing smart cards not yet supporting the standardised storage format, the CWA uses the metadata approach. This means that applications use metadata (machine readable card capability descriptions) when accessing an eEHIC. The interoperability framework is provided in this case by the ISO/IEC 24727 series. The CWA provides a mechanism to protect the electronic exchange of the data.
Med-e-Tel, April 2 nd, 2009 eEHIC on-line through EESSI Home Member State EESSI Network Host Member State eEHIC Social Security Institution Health Care Professional National (Social Security) Network Social Security Institution
Med-e-Tel, April 2 nd, 2009 7 ISO & CEN provision of standards for eEHIC design ISO/IEC 24727 Part 2: Generic card Interface. ISO/IEC 24727 Part 3: Application Interface. ISO/IEC 24727 Part 4: API Administration. European Citizen Card series – CEN/TS 15480 : –Physical & Electrical & Transport protocol Characteristics : ECC-1 Published on June 2007 – Logical Data structures & card services: ECC-2 Published on June 2007 and under maintenance –ECC interoperability using an application interface : ECC-3 NWI endorsed by CEN TC224 resolution 770 (Brussels 22nd-23rd Nov 2007) NWI approved on Oct. 21st 2008 : resolution 787
Med-e-Tel, April 2 nd, 2009 8 Why referring to ISO/IEC 24727 and ECC ? ECC for newly designed eEHIC provides interoperability at lower cost (card edge) without need to GCAL implementation for HCP. ECC to provide a set of common security mechanisms ISO 24727 to facilitate HCP implementation : HCP middleware becomes shareable by all Member States deploying eEHIC. ISO 24727 to harmonize the service interface (unique SAL-API for HCP applications) ISO 24727 to harmonize and complete the reader interface (unique IFD- API for enhanced terminals. While PC/SC version 2.01 is not deployed yet) ISO 24727 to fulfill the need for a technology-agnostic middleware (non vendor-specific) ISO 24727 to support legacy-cards : personalization of logical data structures (discovery information) onto/for the cards enables them for ISO 24727 framework
Med-e-Tel, April 2 nd, 2009 9 ISO 24727 : Definition of a card services Application 1 Client-Application ACD Service Access Layer The client-application has a preset view on the card-application : only card services exposed by the ACD are visible. Discovery data
Med-e-Tel, April 2 nd, 2009 eEHIC - Model basics eEHIC from EU Country « B » IFD HCP Application layer EESSI National Repository Member States Front End Token(s) Reader(s) HCP workstation : ISO 24727-based application layer & interface device layer National network EESSI (EU Network) EESSI infrastructure (EU Network) eEHIC Service front- end EU Country « A » EU Country « B »
Med-e-Tel, April 2 nd, 2009 11 Model basics : Discovery mechanism + transaction The messages (SOAP) should provide optional parameters to cover a set of security alternatives The selection of the appropriate security alternative is up to the Member States proxy : a variety of security policies. First step : parameters negociation Member States Proxy Readers HCP workstation EESSI (EU Network) EESSI Infrastructure National Network eEHIC Card discovery SOAP Response (rejection OR entitlement OR selection of a security level) SOAP Request (eEHIC data AND security capabilities) Ref. eEHIC CWA chap. 5 & 7 Ref. eEHIC CWA chap. 6&7
Med-e-Tel, April 2 nd, 2009 12 Schematic view of middleware layout for eEHIC
Med-e-Tel, April 2 nd, 2009 13 eEHIC cards Types ISO/IEC 24727 compliant eEHIC cards : –A completely new implementation, referred to as Type 1. –A Card pointing to an XML-based Card-Info-File where the EHIC data are stored (outside of the card), referred to as Type 2. –An existing Card which adds the eEHIC service to its list, referred to as Type 3. NON-ISO/IEC 24727 cards : Existing (legacy) card that does not support ISO/IEC 24727 and that stores the required data in a remote repository, referred to as Type 4.
Med-e-Tel, April 2 nd, 2009 14 eEHIC card Types : schematic representation SAL ? = eEHIC Data for entitlement (CWA chap. 4) = pointer to eEHIC Data (CWA chap. 5 & 7)
Med-e-Tel, April 2 nd, 2009 15 DIDs respective role eEHIC ACDCCD eEHIC_HCP DID eEHIC_ADMIN DID Card Type & eEHIC service Card Type & Security enhancements for eEHIC service
Med-e-Tel, April 2 nd, 2009 16 Practical example : the eEHIC personalization, main steps Data preparation main steps are : –Selection of eEHIC Type (1, 2, 3 OR 4) Step 1 –eEHIC data encoding (according to CWA clause 4) Step 2 –Definition of the security policy : Differential-Identities Step 3 eEHIC_ADMIN DID : OPTIONAL eEHIC_HCP DID : MANDATORY –Description of the computational model Step 4 –Description of eEHIC Services attributes according to ASN.1 definition (as per 24727-2 Annex C) Step 5 –DER-TLV encoding of the eEHIC Services Step 6 –Nesting of encoded values within ISO 24727 card containers Step 7
Med-e-Tel, April 2 nd, 2009 17 eEHIC personalization : main steps eEHICHCP DID eEHICADMIN DID new card ? eEHIC Data ? Legacy card ? ? ? ? ?..300C0405….
Med-e-Tel, April 2 nd, 2009 18 Reminder : « Discovery information » management SAL-API ASN.1 definition acc. ISO 24727 Part 2 DER-TLV encoding personalization ACD Service Access Layer (SAL) application ACD DataSet, DSI DID ACD ACL Shareable e-Service ISO/IEC 7816-4 DataSet, DSI DID ACL ISO 24727 container ISO/IEC 7816-15
Med-e-Tel, April 2 nd, 2009 Communication: Card to HCP The HCP is definitely the weakest link in the eEHIC chain for obvious reasons (too many of them, too diverse in terms of functionality, but also size and IT sophistication). Thus HCP implementation should be as much terminal independent as possible. ISO/IEC 24727 fulfils the requirements to support card to HCP secure communication for the eEHIC is platform and client application independent
Med-e-Tel, April 2 nd, 2009 Clause 6: Communication flow types (typical/generic use-cases) Registering of a person and verifying entitlement/status Declaring an event Requesting a decision (i.e. authorisation, benefit, exception) Requesting information (i.e. on periods, children …)
Med-e-Tel, April 2 nd, 2009 Communication flow description in CWA clauses eEHIC ISO 24727 compliant Client application MS Authentication Proxy MSs DB HCP Application SAL GCAL Network ISO 24727-3 Application interface ISO 24727-2 Generic card interface ACD CCD CIA CardInfo eCard Legacy § 5 Card discovery, dataset read § 7 Optional Card authentication § 6 functional messages SOAP Webservices ISO 24727 123 Generic Request/Response Action Request/Response Specific Request/Response Generic APDU Specific APDU
Med-e-Tel, April 2 nd, 2009 Loop End to end communication sequence : card type 1, 2, 3 ISO 24727 compliant Card AppHCP Application MS Authentication Proxy eEHIC Card device ReadCardType (1,2,3) (APDUCommand) Execute (APDUCommand) (APDUResponse) FunctionalResponse ReadDataSet (eEHICDataSet) CardDiscovery (eEHICADMIN) (EntitlementSecurityLevel) FunctionalDialog (eEHICDataSet, SecurityLevel) ReadSecurityLevel (SecurityLevel)
Med-e-Tel, April 2 nd, 2009 Clause 6: Generic message format SOAP Envelope Body Functional Body opaque Person Id Body Header ESSI Header SOAP Header Provider Id Body Initiating Institution Id Body Card authentication Body
Med-e-Tel, April 2 nd, 2009 Optional security functionality for future use No authentication functionality is mandated –Neither on server side (Competent institution) –Nor on client side (HCP) eEHIC-Server-communication can be used without any card-based security features –Issuers are not mandated to add any part of it –Service implementors are not mandated to support these features Authentication functionality can be used –If/when security will be needed e.g. for privacy reasons –Service related policy decisions possible
Med-e-Tel, April 2 nd, 2009 Clause 7: Authentication Application on eEHIC 3 possibly relevant authentication policies: Competent institution needs to make sure the right eEHIC is present –Client authentication –E.g. in order to be legally allowed to provide administrative information Both want to know who is at the other end –Client-Server authentication –HCP needs to know (additionally) they are connecting to the right institution Cryptographic means for session protection –Session key –Sequence of messages secured based on single authentication at the beginning
Med-e-Tel, April 2 nd, 2009 Clause 7: Card based functionality Card based authentication function (digital-signature-like) –Client authentication AND Client-Server authentication –Certificate based (national PKI) Card based decryption function –Server provides encrypted session key (using certificate public key) –Client (HCP) decrypts this session key (using certificate private key)
Med-e-Tel, April 2 nd, 2009 27 Reminder : Why additional security features ? Potential security breach : –forged eEHIC token, –Skimming of eEHIC Dataset –dubious HCP workstations that could withdraw, cache and misuse eEHIC data A set of Authentication protocols as per ECC and EN14890 is defined for eEHIC security enhancement Security enhancement is OPTIONAL : the CWA provides a technical provision for future security enablement depending on the EU Member Statess policy.
Med-e-Tel, April 2 nd, 2009 Matrix of mandatory components of an eEHIC system, depending from the scenario to be deployed
Med-e-Tel, April 2 nd, 2009 A new CWA So What? Common EU interoperability Framework CWA describes a profile that can easily be turned into a Technical Specification More Info? The CWA will be published in May A White Paper will be published in April firstname.lastname@example.org What next? Political decisions EU Pilot eEHIC as an ECC profile MS deployment
Med-e-Tel, April 2 nd, 2009 Thank you for your attention