22.04.231

Ivo Rosol, OKsystem

rosol@oksystem.cz

Onom@Topic+ Middleware

MedeaMedea+ p+ project roject Onom@Topic+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

Service Access Layer (SAL)

Card Instruction Layer (CIL)

Card Transport Layer (CTL)

Application

Three basic layers• SAL layer based on ISO 24727-3• CIL internal layer for APDU

generation• CTL extensible card transport layer

Key features

• Network communicationAchieved through extensible CTL layer

• End-to-end security architectureApplication does not share encryption keys with middleware

• Modular CAD supportAchieved 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

Service Access Layer (SAL)

PKCS#15

...Card Application

1Card Application

N

Data ObjectsDifferential Identities

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

• 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

Service Access Layer (SAL)

Application

Plain data

HSMKENC

KMAC

Callbackfunctions

CTL Broker

Untrusted environment

Trusted environment Request for APDU

encryption

Card Instruction Layer (CIL) Encryption keys never leave secure

storageCTL Proxy

Secured APDUs

Network

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 3rd party• Secure biometric reader support• Contact-less reader support

(NFC, VHDR...)• Network reader- remote

communication support

Card Transport Layer (CTL)

Remote IFDModule

Service Access Layer (SAL)

Card Instruction Layer (CIL)

CTL Resource Manager

PCSC IFDModule

Application

PC/SCImplementation

BiometricIFD Module

PC/SCReader

Biometric Reader

Remote Reader

Network

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

SAL

CIL

CTL

Remote IFD Module (Proxy)

CTL Broker

CTL

IFD Module(PCSC)

IFD Module (PCSC)

Server Application

Client

Server

INTERFACE DEVICE LAYER

RESOURCE MANAGER

IFD 5

IFD PROXY

EXISTING PC/SC IMPLEMENTATION

INTERFACE DEVICE API (IFD-API)

TC

P/IP

Remote Machine

PC/SC IFD HANDLER

NON PC/SC IFD HANDLER

REMOTE IFD HANDLER

IFD 3 IFD 4IFD 1 IFD 2

ECC-3 Annex C(normative)

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

rosol@oksystem.cz

www.oksystem.cz