Ivo Rosol, OKsystem

1
Onom_at_Topic Middleware

• Ivo Rosol, OKsystem
• rosol_at_oksystem.cz

2
Medea project Onom_at_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_at_Topic Consortium

• Manpower 305 MY, number of partners 17
• The Onom_at_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_at_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 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_at_Topic middleware

• Thank you!
• Ivo Rosol
• Development Director
• OKsystem
• rosol_at_oksystem.cz
• www.oksystem.cz