SIST-TS CEN/TS 15480-3:2014

SLOVENSKI STANDARD
01-julij-2014
Nadomešča:
SIST-TS CEN/TS 15480-3:2011
Sistemi z identifikacijskimi karticami - Kartica evropskih državljanov - 3. del:
Interoperabilnost kartice evropskih državljanov z uporabo aplikacijskega vmesnika
Identification card systems - European Citizen Card - Part 3: European Citizen Card
Interoperability using an application interface
Identifikationskartensysteme - Europäische Bürgerkarte - Teil 3:
Anwendungsschnittstelle für die Interoperabilität von Europäischen Bürgerkarten
Systèmes de carte d’identification - Carte Européenne du Citoyen - Partie 3 :
Interopérabilité de la Carte européenne du Citoyen utilisant une interface applicative
Ta slovenski standard je istoveten z: CEN/TS 15480-3:2014
ICS:
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 15480-3
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
April 2014
ICS 35.240.15 Supersedes CEN/TS 15480-3:2010
English Version
Identification card systems - European Citizen Card - Part 3:
European Citizen Card Interoperability using an application
interface
Systèmes de carte d'identification - Carte Européenne du Identifikationskartensysteme - Europäische Bürgerkarte -
Citoyen - Partie 3 : Interopérabilité de la Carte européenne Teil 3: Anwendungsschnittstelle für die Interoperabilität von
du Citoyen utilisant une interface applicative Europäischen Bürgerkarten
This Technical Specification (CEN/TS) was approved by CEN on 14 October 2013 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 15480-3:2014 E
worldwide for CEN national Members.

Contents Page
Foreword .5
1 Scope .7
2 Normative references .7
3 Terms and definitions .8
4 Symbols and abbreviations .8
5 ECC fitting in ISO/IEC 24727 model . 10
5.1 ISO/IEC 24727 main features . 10
5.2 General security issues – Applicable ISO/IEC 24727-4 Stack Configurations for the ECC
environment . 12
5.3 ECC-3 Middleware Architecture . 16
5.3.1 General . 16
5.3.2 Service Access Layer (SAL) . 17
5.3.3 Generic Card Access Layer (GCAL) . 17
5.3.4 Interface Device Layer and API (IFD API) . 17
5.3.5 ECC-3 Stack Distribution and Connection Handling . 17
5.3.6 Multi-stack composed configuration . 20
5.3.7 A Web Service based architecture for ECC-3 framework . 22
5.3.8 XML-based SAL interface . 27
6 Card Discovery Mechanisms . 28
6.1 General . 28
6.2 Discovery decision tree . 29
6.3 Migration path towards ECC and provision for legacy cards . 29
6.3.1 General . 29
6.3.2 Interoperable access to the Repository . 30
6.4 Set of data for interoperability . 30
6.5 Application and Card Capability Descriptors . 31
6.6 ISO/IEC 7816-15 implementation . 34
6.6.1 General . 34
6.6.2 Profile designation within EF.DIR . 34
6.6.3 ISO/IEC 24727-3 data structures mapping . 35
6.6.4 ISO/IEC 24727-3 data structures storage onto the card . 35
6.6.5 General discovery mechanism . 37
6.7 Other data descriptor . 39
7 Authentication protocols . 39
7.1 General . 39
7.2 Authentication Mechanisms based on ISO/IEC 24727 SAL-API . 39
7.3 Asymmetric internal authentication. 40
7.4 Asymmetric external authentication . 40
7.5 Symmetric internal authentication . 41
7.6 Symmetric external authentication . 41
7.7 Mutual authentication with key establishment . 41
7.8 Device authentication with non traceability . 41
7.9 Key transport protocol based on RSA . 41
7.10 Terminal Authentication . 42
8 IFD-API Web Service Binding . 42
9 Card-Info Structure — Introduction . 42
10 XML-based Service Access Layer Interface . 43
11 Federative Framework-wise Authenticate API . 43
11.1 General . 43
11.2 Authenticate method . 44
11.3 Web Service Binding for Authenticate API . 47
11.3.1 General . 47
11.3.2 Authenticate.XSD definition . 47
11.3.3 Authenticate.WSDL definition . 48
Annex A (informative) Interface Device Layer Architecture and Management . 51
A.1 Scope . 51
A.2 IFD-Layer Architecture . 51
A.3 Resource Manager . 52
A.3.1 General . 52
A.3.2 IFD-Handlers . 52
A.3.3 Card transactions . 52
A.3.4 Application threads . 52
A.4 Administrative functions . 52
A.4.1 IFD-Handler related functions . 52
A.4.2 Interface Device related functions . 53
Annex B (informative) IFD-API – C Language Binding . 54
Annex C (informative) SAL-API Post-issuance personalisation requests . 60
C.1 General . 60
C.2 Post-issuance personalisation requests . 60
C.3 Canonical protocol . 60
C.3.1 General . 60
C.3.2 DataSetCreate . 61
C.3.3 DSICreate. 68
C.3.4 DIDCreate . 70
C.3.5 DIDUpdate . 71
C.3.6 CardApplicationServiceCreate . 72
C.4 General recommendation and conclusion . 74
Annex D (informative) Additional features versus ISO/IEC 24727 (all parts) . 75
D.1 General . 75
D.2 Discovery Mechanism . 75
D.3 General Procedures (SAL) . 75
D.4 Architecture . 77
D.5 Differences between IFD-API in ISO/IEC 24727-4 and ECC-3 . 77
D.5.1 More generale SlotCapabilityType . 77
D.5.2 Transmit with support for batch processing . 80
D.5.3 Additional error code for SignalEvent . 82
Annex E (informative) C-Language Binding for ExecuteSAL function . 83
Annex F (informative) Java-Language Binding for ExecuteSAL function . 84
Annex G (informative) Application Discovery Profile: card requirements to access/offer services
in ISO/IEC 24727 framework .
G.1 General . 85
G.2 OID . 85
G.3 General . 85
G.4 interfaces / transport protocols . 85
G.5 Data elements and data structures . 86
G.6 Command set . 88
G.7 Data structure of Card Applications . 89
G.7.1 General . 89
G.7.2 DF/ADF content . 89
G.7.3 EF DCOD content . 89
G.7.4 EF AOD content . 90
G.7.5 EF SKD content . 90
G.7.6 Ef PrKD content . 90
Bibliography . 91

Foreword
This document (CEN/TS 15480-3:2014) has been prepared by Technical Committee CEN/TC 224 “Personal
identification, electronic signature and cards and their related systems and operations”, the secretariat of
which is held by AFNOR.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TS 15480-3:2010.
CEN/TS 15480, Identification card systems — European Citizen Card, is composed of the following parts:
— Part 1: Physical, electrical and transport protocol characteristics;
— Part 2: Logical data structures and security services;
— Part 3: European Citizen Card Interoperability using an application interface (the present document);
— Part 4: Recommendations for European Citizen Card issuance, operation and use;
— Part 5: General Introduction.
The following technical changes have been made in this new edition of CEN/TS 15480-3:
— addition of mention of SAL Lite component, abstraction of GCI and GCAL through Registry processed at
SAL level, decision tree update, scope update, etc (5.3.5.3);
— removal of all subclauses under 6.6.3 (Data structures mapping) that were already incorporated in
ISO/IEC 24727-4;
— removal of Annex J dedicated to ECC-3 API (handling ISO/IEC 7816-15 objects) considered not
appropriate in ECC-3 because implementation-specific and not fundamental to interoperability;
— removal of XML Binding details for SAL API from Clause 10 and Annex G (removal of Annex G); it was
incorporated in ISO/IEC 24727-3:2008/DAmd 1, Annex F;
— maintainance of the annex investigating SAL post-issuance personalisation;
— removal of Annex H describing XML binding for Authentication protocols since these protocols are now
part of ISO/IEC 24727-3:2008/DAmd 1, i.e. EACv2 protocol binding doesn’t need to be reflected in ECC-3
since it is incorporated in ISO/IEC 24727-3:2008, Annex E;
— removal of Annex D “example of CIA implementation for Card –Application Service description” since it is
updated and incorporated in ISO/IEC 24727-4:2008/DAmd 1;
— removal of XML-based CardInfo Types (XML Registry) since it is incorporated in
ISO/IEC 24727-3:2008/DAmd 1, Annex D, Clause D.3;
— IFD-API shows enhancements in comparison with ISO/IEC 24727 (e.g. SlotCapabilityType with support of
transmission protocol descriptor, Transmit command with support of batch APDU, SignalEvent error
coding with additional error code), therefore IFD API Annex B are removed from ECC-3 and the clauses
describing enhancements are reflected in ECC-3, Annex D amongst the differences with ISO/IEC 24727;
— addition of Annex D, Additional features versus ISO/IEC 24727 (all parts), to incorporate the description
of IFD API extensions in terms of API definition and binding;
— removal of 6.2.1.1, Definition for CardInfoRepository.XSD, and 6.2.1.2, Definition for
CardInfoRepository.WSDL, since these binding descriptions are now part of
ISO/IEC 24727-4:2008/DAmd, 1;
— addition of a new Clause 11 dedicated to Authenticate API: the Authenticate() call makes the service
layer module transparent to the Service Provider, it occurs above SAL layer;
— provision of an introductory text describing the layout where Authenticate API fits;
— IFD API C-Language Binding remains in ECC-3 till its endorsement in ISO/IEC 24727 if deemed useful;
— maintainance of ExecuteSAL API in ECC-3 (both C-language binding and java binding);
— incorporation under Annex G of “Application Discovery Profile” for the purposes of integration in
ISO/IEC 24727 framework.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus,
Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany,
Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.
1 Scope
This Technical Specification provides an Interoperability Model, which will enable an eService compliant with
technical requirements, to interoperate with different implementations of the European Citizen Card.
This Interoperability model will be developed as follows:
— starting from the ECC Part 2, Part 3 of the ECC series provides additional technical specifications for a
middleware architecture based on ISO/IEC 24727 (all parts); this middleware will provide an API to an
eService as per ISO/IEC 24727-3.
— a set of additional API provides the middleware stack with means to facilitate ECC services.
— a standard mechanism for the validation of the e-ID credential is stored in the ECC and retrieved by the
eService.
In order to support the ECC services over an ISO/IEC 24727 middelware configuration, this part of the
standard specifies the following:
— a set of mandatory requests to be supported by the middleware implementation based on ISO/IEC 24727
(all parts).
— data set content for interoperability to be personalised in the ECC.
— three middleware architecture solutions: one based on a stack of combined ISO/IEC 24727 configurations
and the other based on Web Service configuration whereas the third one is relying on a SAL Lite
component.
— an Application DiscoveryProfile featuring the guidelines for card-applications to fit in ISO/IEC 24727
framework.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
CEN/TS 15480-2:2012, Identification card systems — European Citizen Card — Part 2: Logical data
structures and security services
CEN/TS 15480-4, Identification card systems — European Citizen Card — Part 4: Recommendations for
European Citizen Card issuance, operation and use
ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 7816-15, Identification cards — Integrated circuit cards — Part 15: Cryptographic information
application
ISO/IEC 24727-1, Identification cards — Integrated circuit card programming interfaces — Part 1: Architecture
)
ISO/IEC 24727-2:2008 , Identification cards — Integrated circuit card programming interfaces — Part 2:
Generic card interface
)
ISO/IEC 24727-3:2008 , Identification cards — Integrated circuit card programming interfaces — Part 3:
Application interface
)
ISO/IEC 24727-4:2008 , Identification cards — Integrated circuit card programming interfaces — Part 4:
Application programming interface (API) administration
ISO/IEC 24727-5, Identification cards — Integrated circuit card programming interfaces — Part 5: Testing
procedures
ISO/IEC 24727-6, Identification cards — Integrated circuit card programming interfaces — Part 6: Registration
authority procedures for the authentication protocols for interoperability
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
descriptive elements
information nested in data objects and intended for the discovery mechanism and encapsulated along with
procedural elements in the ACD and CCD
3.2
procedural elements
translation code to process any request at the Generic Card Interface (GCI) and every relevant card response
Note 1 to entry: The translation has one entry point, theTranslationCode() function as per ISO/IEC 24727-2.
3.3
middleware
set of abstraction layers which serves as the intermediate between a client-application and an application
resident in the ECC.and behind which the actual pieces of software running these abstraction layers are
implementation-specific and out of the scope of this document
3.4
eService
application based locally on the client PC or based somewhere in the internet (eg government eService,
eBuisness eService,…) which offers in combination with the ECC smart card the execution of a task
4 Symbols and abbreviations
ADF Application Dedicated File
AID Application Identifier
AJAX Asynchronous JavaScript and XML
AMB Access Mode Byte
AT Authentication Template
1) This document is currently impacted by the draft amendment ISO/IEC 24727-2:2008/DAmd 1.
2) This document is currently impacted by the draft amendment ISO/IEC 24727-3:2008/DAmd 1.
3) This document is currently impacted by the draft amendment ISO/IEC 24727-4:2008/DAmd 1.
ATR Answer to Reset
ATS Answer to Select
BER Basic Encoding Rules
BHT Biometric Header Template
BIT Biometric Information Template
CA Certification Authority
CAPICOM Cryptographic API COM Object (http://msdn.microsoft.com)
CAR Certification Authority Reference
CBC Cipher Block Chaining
CCT Cryptographic Checksum Template
CED Certificate Effective Date
CHA Certificate Holder Authorization
CHR Certificate Holder Reference
CIA Cryptographic Information Application
CPI Certificate Profile Identifier
CRT Control Reference Template
CryptoAPI Cryptographic Application Programming Interface (http://msdn.microsoft.com)
CSP Crytographic Service Provider
CT Confidentiality Template
CV Card Verifiable
CXD Certificate Expiration Date
DES Data Encryption Standard
DF Dedicated File
DH Diffie Hellman
DOCP Data Object Control Parameters
DST Digital Signature Template
ECDH Elliptic Curve DH
ELC Elliptic Curve Cryptosystem
ECDSA Elliptic Curve Digital Signature Algorithm
EF Elementary File
FCI File Control Information
FCP File Control Parameters
GCAL Generic Card Access Layer
HT Hash Template
ICC Integrated Circuit Card
DID Differential Identity according to ISO/IEC 24727-3
IFD Interface Device
IFDH Interface Device Handler
JSON Java Script Object Notation (http://www.json.org)
KAT Control reference template for key agreement
LSB Least Significant Byte
MAC Message Authentication Code
MF Master File
M.U.S.C.L.E Movement for the Use of Smart Card in Linux Environment
MSE Manage Security Environment
OID Object Identifier
PAN Primary Account Number
PIN Personal Identification Number
PUK unblocking password
PK – DH Public key – Diffie Hellman (asymmetric key base algorithm)
PSO Perform Security Operation
RFU Reserved for Future Use
RSA Rivest Shamir Adleman
SAL Service Access Layer
SAL Lite Service Access Layer Lite
SDO Security Data Object
SCB Security Condition Byte
SE Security Environment
SEID Security Environment IDentifier byte
SM Secure Messaging
SSD Security Service Descriptor
TLV Tag Length Value
UQB Usage Qualifier Byte
5 ECC fitting in ISO/IEC 24727 model
5.1 ISO/IEC 24727 main features
This standardization initiative (ISO/JTC1/SC17 WG4/TF9) aims to design a new framework for interoperability
based on a discovery mechanism of which the following paradigm:
The low level implementation features of the smart card, including proprietary specific features and
characteristics based on ISO standards (i.e. ISO/IEC 7816-4) are hidden to the client-application through a
high-level description provided to the terminal and processed by the middleware stack.
The middleware stack is defined by abstraction layers ensuring the interoperability. These layers are
sustained by applicative components of which the implementation is up to the integrator and may vary
according to the environment. For instance, the use of CAPICOM, CryptoAPI, CSP, proprietary API or DLL,
ActiveX objects, Applets, PKCS#11 interface, JCE, M.U.S.C.L.E PC/SC emulation on Linux environment, etc,
are all possible solutions upon which the ISO/IEC 24727 abstraction layers may run.
The middleware abstraction layers are of two kinds:
— The Service Access Layer (SAL) is in charge of interpreting the requests addressed by the client-
application to the card via a high-level API (the SAL-API). The SAL translates the requests in terms of
sequences of APDU that are sent out to the underlying abstraction layer (the GCAL). This translation is
performed according to the rules defined by a set of interoperability data reflecting the rules governing the
card-applications. The SAL shall generate on the fly these interoperability data out of the
ISO/IEC 7816-15 information available in the card. This ISO/IEC 7816-15 information is either provided
within the CardApplicationServiceDescription data, or within the DF.CIA files, or both. Upon request from
the eService, the SAL may surface the interoperability data to the eService.The SAL is specified in Part 3
of the ISO/IEC 24727 series.
— The Generic Card Access Layer (GCAL) is in charge of translating the APDU handed on by the SAL in
terms of APDU understandable to the smart card. This translation is applied according to the rules
defined in the ACD (Application Capability Descriptor) and/or in the CCD (Card Capability Descriptor)
templates. These templates are read out of the card by the GCAL. The GCAL performs a bootstrap
mechanism upon card detection in order to retrieve the ACD and CCD containers from the card. The
bootstrap operation is the first step of the discovery mechanism. The GCAL functionality is specified in
Part 2 of the ISO/IEC 24727 series.

Figure 1 — CEN/TS 15480 compliant smart card in ISO/IEC 24727 framework
The smart card hosts a set of interoperability data that are DER-TLV encoded according to an ASN.1
definition. This ASN.1 specification provided in ISO/IEC 24727-2 describes all the information items required
by a terminal to access the services offered by the card (resources, actions) and to allow as well the end-user
to access services running on terminal side. This ASN.1 specification is built upon the computational model
specified in ISO/IEC 24727-3. Therefore, the ASN.1 definition encompasses the descriptors of the services
hosted on-card per application, the card application list, the access control rules applying to each on-card
action or resource, and the description of each modular authentication item (called Differential-Identity or DID).
This latter item (Figure 2 — Differential-Identity structure according to ISO/IEC 24727-3) is the modular
descriptor of each authentication procedure. DID comprises five fields among which an optional element, the
dIDQualifier, that conveys further information to clear ambiguities whenever required by cryptographic
requests.
Figure 2 — Differential-Identity structure according to ISO/IEC 24727-3
The relationship between the elements constituting a DID is such as a Marker applied in a given Scope feeds
the algorithm of a given Authentication Protocol that is applied to authenticate a given named DID.
The rules controlling the access to a card resource or authorising a card action are expressed has a boolean
combination of Differential-Identities. If the boolean expression evaluates to “TRUE”, the requested card
resources are made available or the card action is executed, otherwise the request is rejected.
The DifferentialIdentityQualifier may serve to convey to the SAL the OID related to a cryptographic operation
or authentication protocol. The DIDQualifier type depends on the Authentication Protocol to which it applies.
Details of DIDQualifiers are given in ISO/IEC 24727-3:2008, Annex A.
5.2 General security issues – Applicable ISO/IEC 24727-4 Stack Configurations for the ECC
environment
The abstraction layers defined by ISO/IEC 24727 (all parts) are intended to hide seamlessly the
implementation differences that may occur between smart cards from different vendors even when their
respective implementation is based on the same standard or specification (i.e. CEN/TS 15480-2).
A high level description (according to ISO/IEC 24727 (all parts)) of the security rules governing the services
hosted by the card allows an extension of the information provided by ISO/IEC 7816-15 implementation,
ensuring thereby a more comprehensive interoperability protocol based on ISO/IEC 7816-15.
By personalising the necessary data sets for interoperability as per ISO/IEC 24727-2 and ISO/IEC 24727-3, a
European Citizen Card can fit in the ISO/IEC 24727 framework with the following limitations:
a) The GCAL being assumed to translate APDU handed on by the SAL, these command APDU cannot be
secured (integrity, confidentiality) otherwise any change in the command header according to the ACD
procedural elements will cause a rejection of the command by the smart card. Therefore, if the translation
function of the GCAL is performed, end-to-end Secure Messaging cannot be applied between the client-
application and the card-application in the ISO/IEC 24727 framework. With this respect, the European
Citizen Card needs to discard the GCAL translation function except for use cases where no Secure
Messaging is envisioned. This issue was solved by the first amendment to ISO/IEC 24727-4 as follows:
1) Execution of Procedural Element (PE) functionality directly in the Service Access Layer
implementation; the PE consume the Registry that is either XML-based CardInfo file or
[ISO/IEC 7816-15]-based DER-TLV Data Object. The PE translate the SAL API calls into card-
specific APDUs according the instructions brought by the Registry; consequently, the former process
in two stages i.e. first generation of generic APDU commands conforming to GCI, and second the
translation by the GCAL of the commands so obtained into card-specific APDUs is no longer useful
and is replaced by one-step process handled by PE with Registry input. The GCAL implementation
becomes abstract and the PE is enabled for a variety of card managements through SAL API
including Global Platform.
b) The Loyal-stack configuration (Figure 3 — ISO/IEC 24727-4 excerpt: Loyal-Stack configuration), the
Remote-ICC-stack configuration (Figure 4 — ISO/IEC 24727-4 excerpt: Remote-ICC-Stack
configuration), and the Remote-Loyal-Stack configuration (Figure 5 — ISO/IEC 24727-4 excerpt: Remote-
Loyal-Stack configuration) are considered in the present document. A generic depiction of ISO/IEC 24727
middleware stack lying over different platforms is represented on Figure 6 — ISO/IEC 24727-4 excerpt:
Generic elements of ISO/IEC 24727 MW stack).
c) The implementation of Part-3 Layer (SAL) and Part-2 Layer (GCAL), if any, on separate machines raises
the communication channel security issue to bridge the two layers. The use of a TLS session in between
to prevent eavesdropping, tampering or message forgery, raises further constraints:
1) For the client-application to keep control on the intermediate TLS secured communication channels it
requires a handle on the TLS secure session and it needs to share the secrets involved in the secure
session establishment. Such control is not provided by ISO/IEC 24727-4, nevertheless a parameter
denoting the available routes between the client-application and the card-application is backed up to
the client-application for awareness then path selection. During the first phase of the SSL session,
the client and server negotiate which cryptographic algorithms will be used. In typical use, only the
server is authenticated while the client remains unauthenticated. For the purposes of mutual
authentication, a public key infrastructure (PKI) deployment to clients is required.
2) ISO/IEC 24727-3 and ISO/IEC 24727-4 do not provide to the client-application control over the
secure messaging features and therefore require session keys sharing, which raises different
security issues. It is preferable for the session keys and more generally for the host security module
functions and keys to remain the property of the eService.
3) SSL runs on layers beneath HTTP, SMTP and NNTP application protocols, and above TCP or UDP
transport protocol. SSL can be exploited to add security to any protocol using reliable connections
like TCP. Therefore, to avoid using separate ports for encrypted communications and to enable the
application protocols to upgrade to TLS from a plaintext connection, the client should support SSL
natively instead of relying on standalone SSL products.
d) The implementation of client-application and Part 3 Layer (SAL) on separate machines entails securing
the requests between the SAL Proxy and the SAL Agent on both sides, and requires the marshallised
requests to be transported over TLS. The marshalling protocol may be based on DER-TLV encoding
according ASN.1 definition and encapsulation into ENVELOPE APDU command, or on WSDL-based
XML messages transported over SOAP binding. Both methods are described in ISO/IEC 24727-4.
Figure 3 — ISO/IEC 24727-4 excerpt: Loyal-Stack configuration

Figure 4 — ISO/IEC 24727-4 excerpt: Remote-ICC-Stack configuration

Figure 5 — ISO/IEC 24727-4 excerpt: Remote-Loyal-Stack configuration

Figure 6 — ISO/IEC 24727-4 excerpt: Generic elements of ISO/IEC 24727 full-network stack
5.3 ECC-3 Middleware Architecture
5.3.1 General
On overview of the architectural parts of ECC-3 is given in Figure 7 — ECC-3 Middleware Architecture. The
ECC-3 Middleware consists of the Service Access Layer (SAL), either the Generic Card Access Layer (GCAL)
or the Procedural Elements and the Interface Device Layer (IFD-API). A detailed description of the different
parts of the ECC-3 Middleware can be found in the subsequent sections.
Figure 7 — ECC-3 Middleware Architecture
5.3.2 Service Access Layer (SAL)
The ECC-3 Service Access Layer is based on the Service Access Layer of ISO/IEC 24727-3.
5.3.3 Generic Card Access Layer (GCAL)
The Generic Card Access Layer is responsible for mapping the SAL functionality to card application specific
functions and protocols. To allow an easy adaptation within the GCAL, the GCAL uses ACD, CCD and
CardInfo files. ISO/IEC 24727-4 abstract the GCAL implementation and rely on the Procedural Elements
hosted in Service Access Layer for the mapping of SAL API calls onto card-specific functions.
5.3.4 Interface Device Layer and API (IFD API)
The Interface Device API is responsible for the APDU based communication with the IFD / card application.
5.3.5 ECC-3 Stack Distribution and Connection Handling
5.3.5.1 General
If the eService is located on a server somewhere on the network and the ECC is used by a user at home, the
Remote-ICC-Stack, the Remote-Loyal-Stack, or the Opaque-ICC-Stack (as per ISO/IEC 24727-4), further to
the Loyal-Stack configuration of ISO/IEC 24727-4, will be used within the ECC-3 middleware architecture.
Within this distributed system it is necessary that the eService will communicate directly with the card
application. Additionally, the service embedded application on user machine may perform an authentication
process with the card application or may interact by other means with the card application. APDUs generated
at service side in a Remote-ICC-Stack like layout may be addressed directly to the card through the IFD-API,
and marshallised requests generated at server side in a Remote-Loyal-Stack like layout may be addressed to
the SAL implementation on user machine. This implies that the complete ECC-3 middleware stack shall be
available on the user machine (client machine) and on the server side (see Figure 8 — ECC-3 Middleware
Architecture in the Remote-ICC-Stack environment), and that a mix of different ISO/IEC 24727 configurations
shall be deployed together to achieve electronic service delivery in the real life.
5.3.5.2 ICC-Resident-Stack specifics
The present standard aims at providing guidelines for legacy card support to facilitate migration towards ECC-
compliant cards. In this view, the ICC-Resident-Stack (ISO/IEC 24727-4:2008, 5.5) is a particular
configuration such as the service layer processing the high-level calls from the eService application is
embedded onto the card: The card-application emulating stack has an interface APDU exposing the
ENVELOPE command. The eService application calls the SAL-API requests; the SAL-API requests are
marshalled by a proxy according a transmission protocol based on ASN.1 (ASN.1-Binding) as follows: the
SAL-API calls are encoded in DER-TLV. The DER-TLV payload is enc
...