Transcript Document

Onom@Topic+ Middleware
Ivo Rosol, OKsystem
[email protected]
1
16.7.2015
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
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
Application
Service Access Layer (SAL)
Card Instruction Layer (CIL)
Card Transport Layer (CTL)
Three basic layers
• SAL layer based on ISO 24727-3
• 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
PKCS#15
Service Access Layer
(SAL)
Card Application
1
Data Objects
...
Differential
Identities
Card Application
N
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
KENC
KMAC
HSM
Callback
functions
Application
Trusted
environment
Plain data
Request for APDU
encryption
Service Access Layer (SAL)
Card Instruction Layer (CIL)
CTL Proxy
Secured APDUs
Network
Untrusted
environment
CTL Broker
Encryption keys
never leave secure
storage
• 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
Application
CTL uses plug-in IFD modules
• Built-in PC/SC module
• Additional modules can be
implemented by 3rd party
Service Access Layer (SAL)
Card Instruction Layer (CIL)
Card Transport Layer (CTL)
CTL Resource Manager
PCSC IFD
Module
Biometric
IFD Module
PC/SC
Implementation
PC/SC
Reader
Remote IFD
Module
Network
Biometric
Reader
Remote
Reader
• Secure biometric reader
support
• Contact-less reader support
(NFC, VHDR...)
• Network reader- remote
communication support
Network Stack implementation
Client
Server
Server Application
SAL
IFD Module
(PCSC)
CIL
CTL Broker
CTL
CTL
Remote IFD
Module (Proxy)
IFD Module
(PCSC)
• Proxy IFD module
communicates with CTL
Broker
• CTL Broker retransmits
CTL calls
• Protocol between IFD
Proxy and CTL Broker is
up to the implementator
Inputs to ECC-3
INTERFACE DEVICE LAYER
INTERFACE DEVICE API (IFD-API)
RESOURCE MANAGER
- Data types definition
- Status code values
- C prototype of each
API
- utility macros
PC/SC IFD
HANDLER
NON PC/SC IFD
HANDLER
REMOTE IFD
HANDLER
TCP/IP
ECC-3 Annex D
(normative)
IFD-API
C-Language Binding
ECC-3 Annex B
(informative)
IFD-API
EXISTING PC/SC
IMPLEMENTATION
IFD PROXY
IFD 1
IFD 2
IFD 3
IFD 4
IFD 5
Remote Machine
ECC-3 Annex C
(normative)
CENCommon.XSD
CENIFD.XSD
CENIFD.WSDL
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
[email protected]
www.oksystem.cz