Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Onom@Topic+ Middleware Ivo Rosol, OKsystem [email protected] 1 25.5.2017 Medea+ project Onom@Topic+ European Smartcard Platform for Citizenship and Mobile Multimedia Applications Project Strategic Objectives: Develop complete HW/SW smart-card platform and a framework enabling the European Governments to issue interoperable documents (Citizen Card, Electronic Identity, Visas or Passport documents) for electronic identification, authentication and for access to e-Services Onom@Topic+ Consortium Manpower: 305 MY, number of partners: 17 The Onom@Topic+ consortium incorporates key players from the European smart-card industry: • smart-card manufacturers (Axalto, Gemplus, Oberthur CS) • silicon founders (STMicroelectronics, Philips Semiconductors) • electronic design companies (ID3 semiconductors) • biometrics specialists (Precise Biometrics) • software and services companies (OKsystem, Esterel Technologies, CompuWorx) • security laboratories (CEA-Leti) • consumer electronics laboratories (Innovation Lab of Philips CE). Project Organisation Project start: April 1st, 2005, end: December 2007 Workpackage structure • • • • • • • • • WP1: project management and dissemination WP2: Market and system requirements, interaction with standards, related use cases WP3: architecture and specification, determination of interoperability features WP4: technical studies WP5: infrastructure & embedded interfaces WP6: biometrics architecture & interfaces WP7: platform development WP8: Tools & methodology WP9: demonstrators Middleware definition Middleware is key interoperability element, connecting cards, card services, card accepting devices (readers), networks and applications. Basic design requirements • Interoperability: well established standards are key drivers of interoperability. We need standards on both edges of middleware block – app side and card services edge. • Easy to use: high level API for software developers, to free their hands from the dirty work with complex low level card protocols • Security: end-to-end security between application and card • Extensibility: Open design, 3rd party shoud be able to add support to new cards and CAD Interoperability decisions Onom@Topic middleware implementation is based on the ISO 24727 emerging standard, mainly on the application interface represented by ISO 24727-3. CEN TC224/WG15 ECC-2 compatible smart card is enabled to provide IAS services required by a Client Application laid on ISO Part 3 interface. General architecture Application Service Access Layer (SAL) Card Instruction Layer (CIL) Card Transport Layer (CTL) Three basic layers • SAL layer based on ISO 24727-3 • CIL internal layer for APDU generation • CTL extensible card transport layer Key features • Network communication Achieved through extensible CTL layer • End-to-end security architecture Application does not share encryption keys with middleware • Modular CAD support Achieved by IFD implementation for secure biometric readers, VHDR contactless readers • Extensible card support Feasible API implementation instead of generic APDU mapping Service Access Layer • SAL implements high level interfaces for applications (both server and local), masking complexity of lower layers – card diversity, APDUs, readers and transport mechanisms • SAL API brings all selected card services to applications, including end to end security between card and application SAL card app discovery PKCS#15 Service Access Layer (SAL) Card Application 1 Data Objects ... Differential Identities Card Application N Representataion of an authentication protocol - Name - Protocol - Marker - Scope Card Instruction Layer • CIL defines generic card API interfaces. By implementing those interfaces, any 3rd party can easily add new card into the portfolio. Implementation of API is much easier task in comparison to APDU mapping (ISO 24727 GCAL concept) End-to end security architecture KENC KMAC HSM Callback functions Application Trusted environment Plain data Request for APDU encryption Service Access Layer (SAL) Card Instruction Layer (CIL) CTL Proxy Secured APDUs Network Untrusted environment CTL Broker Encryption keys never leave secure storage • Encryption keys stay in secure HSM module and application does not share them with middleware • Application need not operate on APDU level • APDUs are secured before transmitting to unsecured environment Card Transport Layer • CTL define interfaces (and implements some important technologies) with respect to the transport path from the middleware to the reader and (ECC compliant) card. • Implementing those interfaces, any 3rd party can easily add new transport technology and/or new reader/CAD Card Transport Layer modules Application CTL uses plug-in IFD modules • Built-in PC/SC module • Additional modules can be implemented by 3rd party Service Access Layer (SAL) Card Instruction Layer (CIL) Card Transport Layer (CTL) CTL Resource Manager PCSC IFD Module Biometric IFD Module PC/SC Implementation PC/SC Reader Remote IFD Module Network Biometric Reader Remote Reader • Secure biometric reader support • Contact-less reader support (NFC, VHDR...) • Network reader- remote communication support Network Stack implementation Client Server Server Application SAL IFD Module (PCSC) CIL CTL Broker CTL CTL Remote IFD Module (Proxy) IFD Module (PCSC) • Proxy IFD module communicates with CTL Broker • CTL Broker retransmits CTL calls • Protocol between IFD Proxy and CTL Broker is up to the implementator Inputs to ECC-3 INTERFACE DEVICE LAYER INTERFACE DEVICE API (IFD-API) RESOURCE MANAGER - Data types definition - Status code values - C prototype of each API - utility macros PC/SC IFD HANDLER NON PC/SC IFD HANDLER REMOTE IFD HANDLER TCP/IP ECC-3 Annex D (normative) IFD-API C-Language Binding ECC-3 Annex B (informative) IFD-API EXISTING PC/SC IMPLEMENTATION IFD PROXY IFD 1 IFD 2 IFD 3 IFD 4 IFD 5 Remote Machine ECC-3 Annex C (normative) CENCommon.XSD CENIFD.XSD CENIFD.WSDL Inputs to ISO: IFD-API • Extension of PC/SC IFD-API incorporated in ISO/IEC 24727-4 • Networking : remote IFD-handler • Management of terminals equipped with biometric sensors, accoustic unit, optical unit, display • User verification • Multi-slot device management Middleware main achievements • Middleware implementation follows and also provide feedback inputs to CEN TS 15480-3 (ECC) and ISO 24727-4 development • Open design – 3rd party standard can easily add new cards, new readers and transport technologies • Brings proof of the concept and pioneer the middleware market, based on proposed European and international standards Onom@Topic middleware Thank you! Ivo Rosol Development Director OKsystem [email protected] www.oksystem.cz