Ivo Rosol, OKsystem Middleware

Medea+ project 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

Consortium Manpower: 305 MY, number of partners: 17 The 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  middleware implementation is based on the ISO emerging standard, mainly on the application interface represented by ISO  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 Three basic layers SAL layer based on ISO 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

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 GCAL concept)

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

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

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

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

Inputs to ISO: IFD-API Extension of PC/SC IFD-API incorporated in ISO/IEC 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 (ECC) and ISO 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

middleware Thank you! Ivo Rosol Development Director OKsystem