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

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

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 3 rd 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. ECC-3 Annex C (normative) CENCommon.XSD CENIFD.XSD CENIFD.WSDL 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 Inputs to ECC-3

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

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