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 ) PHASE B:CWA (approved ) White Paper
Med-e-Tel, April 2 nd, 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 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, ISO & CEN provision of standards for eEHIC design ISO/IEC Part 2: Generic card Interface. ISO/IEC Part 3: Application Interface. ISO/IEC Part 4: API Administration. European Citizen Card series – CEN/TS : –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, Why referring to ISO/IEC 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 to facilitate HCP implementation : HCP middleware becomes shareable by all Member States deploying eEHIC. ISO to harmonize the service interface (unique SAL-API for HCP applications) ISO to harmonize and complete the reader interface (unique IFD- API for enhanced terminals. While PC/SC version 2.01 is not deployed yet) ISO to fulfill the need for a technology-agnostic middleware (non vendor-specific) ISO to support legacy-cards : personalization of logical data structures (discovery information) onto/for the cards enables them for ISO framework
Med-e-Tel, April 2 nd, ISO : 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 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, 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, Schematic view of middleware layout for eEHIC
Med-e-Tel, April 2 nd, eEHIC cards Types ISO/IEC 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 cards : Existing (legacy) card that does not support ISO/IEC and that stores the required data in a remote repository, referred to as Type 4.
Med-e-Tel, April 2 nd, 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, 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, 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 Annex C) Step 5 –DER-TLV encoding of the eEHIC Services Step 6 –Nesting of encoded values within ISO card containers Step 7
Med-e-Tel, April 2 nd, eEHIC personalization : main steps eEHICHCP DID eEHICADMIN DID new card ? eEHIC Data ? Legacy card ? ? ? ? ?..300C0405….
Med-e-Tel, April 2 nd, Reminder : « Discovery information » management SAL-API ASN.1 definition acc. ISO Part 2 DER-TLV encoding personalization ACD Service Access Layer (SAL) application ACD DataSet, DSI DID ACD ACL Shareable e-Service ISO/IEC DataSet, DSI DID ACL ISO container ISO/IEC
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 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 compliant Client application MS Authentication Proxy MSs DB HCP Application SAL GCAL Network ISO Application interface ISO Generic card interface ACD CCD CIA CardInfo eCard Legacy § 5 Card discovery, dataset read § 7 Optional Card authentication § 6 functional messages SOAP Webservices ISO 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 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, 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 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