1 / 20

Ivo Rosol, OKsystem rosol@oksystem.cz

Onom@Topic + Middleware. Ivo Rosol, OKsystem rosol@oksystem.cz. Medea + p roject Onom@Topic+. E uropean S martcard P latform for C itizenship and M obile M ultimedia A pplications Project Strategic Objectives:

bell-webb
Download Presentation

Ivo Rosol, OKsystem rosol@oksystem.cz

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Onom@Topic+ Middleware Ivo Rosol, OKsystem rosol@oksystem.cz

  2. Medea+ project Onom@Topic+ EuropeanSmartcard Platform for CitizenshipandMobile 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

  3. 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).

  4. 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

  5. Middleware definition Middleware is key interoperability element, connecting cards, card services, card accepting devices (readers), networks and applications.

  6. 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

  7. 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.

  8. General architecture Three basic layers SAL layer based on ISO 24727-3 CIL internal layer for APDU generation CTL extensible card transport layer

  9. 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

  10. 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

  11. SAL card app discovery

  12. 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)

  13. End-to end security architecture 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

  14. 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

  15. Card Transport Layer modules CTL uses plug-in IFD modules Built-in PC/SC module Additional modules can be implemented by 3rd party Secure biometric reader support Contact-less reader support (NFC, VHDR...) Network reader- remote communication support

  16. Network Stack implementation Proxy IFD module communicates with CTL Broker CTL Broker retransmits CTL calls Protocol between IFD Proxy and CTL Broker is up to the implementator

  17. Inputs to ECC-3 ECC-3 Annex B (informative) IFD-API ECC-3 Annex D (normative) IFD-API C-Language Binding - Data types definition - Status code values - C prototype of each API - utility macros ECC-3 Annex C (normative) CENCommon.XSDCENIFD.XSD CENIFD.WSDL

  18. 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

  19. Middleware main achievements Middleware implementation follows and also provide feedback inputs to CENTS 15480-3 (ECC) and ISO 24727-4development Open design – 3rd party standardcan 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

  20. Onom@Topic middleware Thank you! Ivo Rosol Development Director OKsystem rosol@oksystem.cz www.oksystem.cz

More Related