The German eCard-Strategy - Technische Universität Darmstadt

Transcrição

The German eCard-Strategy
February 2011
Moritz Horsch
Martin Stopczynski
Technische Universität Darmstadt
Hochschulstraße 10
64289 Darmstadt, Germany
Technische Universität Darmstadt
Hochschulstraße 10
64289 Darmstadt, Germany
[email protected]
[email protected]
ABSTRACT
The German government introduces various projects to establish a modern eGovernment and eBusiness. The projects
imply or use smart cards for the authentication or verification of citizens’ identities. The qualified electronic signature
and the electronic identification enabled by such eCards increase the security level in electronic processes. The German
eCard-Strategy intends to harmonize these projects and focuses on a ubiquitous and common usage of eCards. The
German Federal Office for Information Security develops
the eCard-API-Framework to achieve these objectives. The
eCard-API-Framework offers a specification of common and
homogeneous interfaces for a standardized usage of different
eCards in various applications.
The paper at hand introduces a brief overview of the projects
involved with the German eCard-Strategy and describes the
general architecture, technical details and an example of the
eCard-API-Framework, highlights possible improvements towards a next generation API and sketches future project
developments.
Keywords
eCard-API-Framework, eCard-Strategy, electronic identity
(eID), ELENA, ELSTER, German identity card, German
electronic health card, ISO/IEC 24727
1.
INTRODUCTION
The foundation of the German eCard-Strategy is set up with
the decision of the German Federal Cabinet on March 9th in
2005 which should support the nationwide introduction of
Federal Government electronic cards [53]. In respect to the
eCard-Strategy, the Federal Government supports a consistent and coordinated usage of smart cards in eGovernment,
eBusiness and electronic legal relations. Common international standards and the wide availability of smart cards for
electronic commerce as well as public administration should
modernize, gain efficiency and trim costs for the benefit of
citizens, business and government. The distribution and the
usage of such smart cards should also enhance the development of electronic business to increase the performance and
competitiveness of the German economy. The utilization of
the latest chip card technology provides more security, reliability and legal liability in the Internet. Moreover, the
eCard-Strategy intends that the proposed Federal electronic
card projects fit together. The German eCard-Strategy includes the following projects:
• German identity card
(nPA, neuer Personalausweis) [30]
• Electronic health card
(eGK, elektronische Gesundheitskarte) [33]
• Electronic proof of income
(ELENA, elektronischer Entgeltnachweis) [19]
• German tax declaration
(ELSTER, elektronische Steuererklärung) [4]
The crucial factors of the German eCard-Strategy are electronic authentication of the card holder, the (qualified) electronic signature which is supported on various smart cards
[55] and secure cryptographic protocols to access personal
and sensitive data, stored on the smart card. Furthermore,
the eCard-Strategy takes existing smart cards and infrastructures into account. The eCard-API-Framework [25] can
be classified as the technical realization of the eCard-Strategy.
The Framework provides applications a simple and uniform
access to various smart card applications through standardized interfaces. Likewise, important international smart card
projects (see [9]) and international standardization efforts,
such as the European Citizen Card [11, 56] and the ISO/IEC
24727 [50] are considered in the eCard-Strategy or even
based on the eCard-API-Framework specifications.
The paper is structured as follows. The projects of the German eCard-Strategy are described in detail in Section 2.
Section 3 points out the key architecture aspects and technical details as well as the basic features of the eCard-APIFramework. The usage of the framework is presented in
Section 4 using the example of the eID scenario realized by
the German identity card. In Section 5 we present improvements towards a next generation eCard-API. In Section 6
we give an outlook on future developments. Finally Section
7 summarizes the presented work and concludes the paper.
2.
PROJECTS
In this section, we briefly describe the individual projects
of the German eCard-Strategy illustrated in Figure 1. The
primary objective of the eCard-Strategy is a consistent usage
of smart cards in eGovernment, eBusiness and electronic
legal relations. Additional goals are simpified, more secure
and constantly available electronic services as well as the
reduction of errors. Hence, with the new German identity
card supporting the following presented electronic signature
as well as authentication functionality, the card is able to
combine existing and future eGovernment projects, such as
ELSTER or ELENA (cf. Section 2.3 and 2.4), on one smart
card.
2.1
identification. The ePassport application stores personal data, a digital photograph and optional two fingerprints.
German identity card
The German identity card [30] is available since November
1st 2010 and represents one of the major smart card projects
within the German eCard-Strategy. Germany’s Federal Ministry of the Interior expectes that more than 60 million cards
are rolled out over the next ten years [57]. The specification
of the new identity card is based on the European Citizen
Card (ECC) [11] and provides common biometric features
like the ePassport [39] application and in particular functions for electronic authentication and qualified electronic
signature. Besides the visual data printed on the smart card
surface, all personal information are stored on an integrated
radio-frequency identification (RFID) chip and can be retrieved through a contactless interface according to ISO/IEC
14443 [43]. The features of the German identity card are:
• Electronic identification
The electronic identification (eID) permits a proof of
identity in electronically controlled environments and
acts as a replacement of the common user name and
password based authentication. The eID application
can be used for web services login and registration as
well as age and address verification. The card holder
confirms the usage of the eID application and the access to the personal data with a secret Personal Identification Number (PIN). Such a two-factor authentication (ownership of a smart card and knowledge of the
corresponding PIN) is more secure than the common
one-factor authentication based on the knowledge of
user name and password.
• Qualified electronic signature
The qualified electronic signature (QES) certifies electronic documents as an equivalent to handwritten signatures [28]. The application is not enabled by default.
The card holder has to obtain a QES certificate by a
Trust Center1 of his own choice.
• ePassport
The ePassport application is equal to the application
on European electronic passports according to the International Civil Aviation Organization (ICAO) Doc
9303 [39]. The application is physically and logically
separated from the eID application and uses different
data groups, which are only accessible for entitled authorities like police and border control for biometric
1
Figure 1: Projects and features of the German
eCard-Strategy
A list of certification service providers is published by the
Federal Network Agency. http://www.bundesnetzagentur.
de/cln_1932/DE/Sachgebiete/QES/QES_node.html
The access control of the German identity card is realized
through different protocols specified in TR-03110 [29] by the
German Federal Office for Information Security. The Password Authenticated Connection Establishment (PACE) protocol performs a user authentication and establishes a secure
connection to protect the contactless interface between card
terminal and smart card. The Chip Authentication (CA)
and Terminal Authentication (TA) perform a mutual authentication between the card terminal and the identity card
to guarantee the authenticity of the smart card chip and the
access restrictions of the terminal. The Restricted Identification (RI) protocol allows creating pseudonyms. The security
proof of PACE and EAC is described in [13, 6].
2.2
Electronic health card
Considering the amount of recipients, the German electronic
health card [33] is the second major project of the eCardStrategy, because the eHealth card replaces approximately
70 million existing health insurance cards. The project started
in 2003 with the objective to modernize the healthcare system. It is intended to increase the efficiency and transparency to healthcare services as well as to optimize the
administrative work process. Further, it offers improved
healthcare-statistical information for healthcare business. The
rollout was planned for 2006, but more and more additional
requirements are responsible for an ongoing delay. Besides
insurant’s personal data, the eHealth card supports electronic prescriptions which are encrypted and stored on the
card to prevent the need of a printed prescriptions. In addition, the eHealth card can be used as an European Health
Insurance Card (EHIC). The benefits of electronically stored
insurant’s data are avoidance of treatment changes, detection of side effects of medicine and offer important information about diseases and pharmaceuticals in case of an emergency. To access the sensible medical information stored on
the card, the compliance of the user and a health professional (Health Professional Card, HPC) is required.
2.3
Electronic proof of income
With the introducing the electronic proof of income (ELENA)
project on January 1st 2010, a central database for about 40
million employees was created, where the employer reports
the monthly wage and payroll. The database stores, manages and delivers the encrypted and pseudonymised records
of the German employees. Thus, the employee’s data and
their personal data are managed separately. The insight
into one’s own data and the data retrieval process for the
appropriate authorities is planned for 2012. ELENA does
not require a particular smart card. In general, smart cards
which support qualified electronic signatures can be used,
such as the German identity card or privately issued smart
cards like the S-TRUST and T-TeleSec Smart Card.
The main benefits for employers are, that electronic messages replace paper documents and no payrolls or wages
need to be archived. Besides that, the automated electronic
transmission and data retrieval requests by employees or the
government agency ensures cost savings in personnel and administrative workflows since the central database takes care
of those requests without involving the employer directly.
The benefits for users result from the fact, that the personal
situation remains private: certificates and the acquisition of
social benefits like unemployment benefit, housing and family allowance can be requested without the knowledge of the
employer. Furthermore, each participant controls access to
its own payment data. Welfare entitlements can be calculated quickly and especially the electronic signature creates
legal security for all requests.
Reducing the bureaucratic effort is an important milestone
to simplify and speed up the application and approval of
certain social benefits. So far, employers issue about 60
million forms per year in paper [19]. Through the ELENA
project, those paper certificates get replaced by electronic
certificates. This avoid media disruptions and decreases the
error rate in forms.
2.4
German tax declaration
The electronic tax declaration (ELSTER) is a project of the
German State tax authorities and the Federal Government
to process the tax declaration via Internet. Since 1999, users
can submit their tax declaration electronically with an appropriate client software, such as the freely available ElsterFormular [5] application. The introduction of electronic signatures in 2002 and the support of various smart cards via
the PKCS#11 [58] interface makes a handwritten signature
and the printed tax declaration obsolete. Additionally, in
2006 electronic authentication using X.509 certificates [12]
was introduced to enable authenticated data transmission
without any smart card. The certificate can be obtained for
free from the tax authorities. However, it does not replace
the electronic or handwritten signature and is only used for
the encrypted submission of tax declarations.
Moreover, since the beginning of 2005 all tax declarations
have to be submitted electronically, the German Treasury
provided the online portal ElsterOnline [5]. ElsterOnline offers the submission of numerous tax forms like the turnover
tax return, income tax application or capital gains tax registration and integrates further tax-related services in near
future. The main advantage of integrating the project to
the eCard-Strategy is the usage of the German identity card
(cf. Section 2.1) for authentication to ELSTER without additional smart cards.
ELSTER offers a secure transmission of the annual paperless tax declaration which reduces errors and enables a faster
processing. The built-in validation supports the user and
avoids unnecessary inquiries. In addition, the software can
auto-complete the forms using previous year’s data and also
calculate the expected tax.
3.
ECARD-API-FRAMEWORK
This section provides an overview of the eCard-API-Framework as specified by the German Federal Office for Information Security in TR-03112 [25] and is structured as follows: Section 3.1 describes the basic features and Section
3.2 the architecture of the framework. Section 3.3 gives a
further description of the layered architecture referring to
the ISO/IEC 24727 [50]. The web service interface of the
framework is presented in Section 3.4.
3.1
Features
The main objective of the eCard-API-Framework is the specification of a common and homogeneous interface for a standardized usage of different eCards in various applications.
3.1.1
Scalability
The scenario of the electronic identification (eID) application using the German identity card (cf. Section 2.1 and
Section 4) includes a local client application, remote service
providers and eID-Servers. A service provider such as an online shop requires web site visitors to login by performing an
authentication using their German identity card. The local
application, launched by a web browser, offers card communication and user interaction like password input and
progress state. Generally, service providers use an external eID-Server which performs the user authentication (cf.
Section 4). The eCard-API-Framework is realized in the local client application which basically handles only one connected eCard. On the remote side, the framework is implemented in server applications which can handle thousands of
authentication requests at the same time. Hence, the eCardAPI-Framework provides a scaleable local deployment on a
single computer system as well as a networked server environment.
3.1.2
Platform independency
The usage of the XML standard and web service interfaces
for the specification of the framework emphasizes simplicity,
generality, and usability and makes it applicable for personal computers, servers and mobile devices. Furthermore,
the framework is independent from operating systems and
programming languages like Java, C# or Python. The use of
web service interfaces for the definition of the eCard-APIFramework makes it easy to integrate the framework into
applications as a high-level API. The web service interfaces
of the eCard-API-Framework are defined in the XML-based
Web Services Definition Language (WSDL) [10]. For example Apache CXF [60] includes a tool which automatically
creates a mapping of the WSDL definitions and data types
according to JSR 224 [59]. That makes it easy to integrate
and update changes of the framework in applications.
3.1.3
Abstraction of hardware functionalities
As described in Section 2 the German eCard-Strategy includes various smart cards which have different functionalities (cf. Figure 1). For example the German identity card
provides an authentication function in the sovereign and private sector whereas eCards for the electronic proof of income
(cf. Section 2.3) are simple signature cards. However, such
a classification does not consider the additional electronic
signature function of the German identity card. It depends
on the decision of the card holder, if this function is enabled
or not. Thus, the eCard-API-Framework provides a common and homogeneous interface to support these different
conditions and abstracts from the current smart card functionalities. Nevertheless, the eCard-API-Framework cannot
classify smart cards in general by their features, because
the same features like electronic authentication do not result in the same protocols: The German ePassport uses the
Basic Access Control (BAC) and EAC protocol [39] for authentication in sovereign areas, whereas the German identity
card uses PACE and EAC [40, 29]. Moreover, smart cards
for electronic authentication or signature purposes have different requirements to the card terminal equipment. For
the authentication function a simple card terminal which
provides the physical and electronic connection is sufficient
whereas a card terminal with a keypad and display is required for the electronic signature function [20]. The eCardAPI-Framework solves these difficulties by providing an abstract interface which offers authentication and (qualified)
signature functions but hides the current protocols and card
terminal functionalities. Hence, the eCard-API-Framework
supports various types:
• Card terminals with different configurations like keypad, display, contact, contactless, and card-specific interfaces
• Smart cards with different physical characteristics such
as contact interfaces according to ISO/IEC 7816-3 [48]
and contactless ISO/IEC 14443 [43] interfaces and features like (qualified) electronic signature and electronic
authentication
• Different protocols for electronic authentication and
(qualified) electronic signature
3.1.4
Generic Card Service
A major objective of the eCard-API-Framework is the ability to easily add additional smart cards without changing
parts of the source code or the framework itself. The framework provides a Generic Card Service which offers an abstract communication with eCards without any application
or card-specific issues. An eCard is represented by an appropriate CardInfo file [23] which defines logical and physical
characteristics such as the value of the ATR/ATS2 , available
files and corresponding file content. A CardInfo file is a XML
or ASN.13 encoded file which contains information about the
characteristics of an eCard and a mapping from eCard-APIFramework generic calls to the card-specific APDUs (Application Protocol Data Unit) according to ISO/IEC 7816-4
[44]. The usage of international standards such as XML offers a platform and application independent description of
eCards. That makes it comfortable to create, change or
view CardInfo files in different applications. To emphasize
the international focus of the eCard-API-Framework CardInfo files can represent by equivalent Application Capability Descriptions (ACD) according to ISO/IEC 24727-2 [51].
2
ATR (Answer To Reset) is a sequence of bytes which defines
card-specific characteristics. The card terminal receives it
after an electronic reset of the smart card. In case of a
contactless smart card it is called ATS (Answer To Select).
3
Abstract Syntax Notation One (ASN.1) is a standard and
flexible notation that describes data structures for representing, encoding, transmitting and decoding data.
The eCard-API-Framework uses a database of CardInfo files
for the card recognition procedure to determine available or
rather connected eCards. The recognition procedure starts
with the analysis of the ATR/ATS by comparing the value to
the stored set of CardInfo files. The next steps are checking
for available files and comparing the file content. This procedure continues until the characteristics of the connected
eCard only match one CardInfo file. If the card recognition
procedure fails with the current set of CardInfo files, it is
possible to contact a remote CardInfo repository server to
request additional CardInfo files. To add a new eCard, the
appropriate CardInfo file is simply added to the eCard-APIFramework database.
3.1.5
International focus
To provide national and international acceptance for the
eCard-API-Framework, the focus of the specification development was to use internationally accepted standards whenever it was possible. Vice versa, the innovative elements of
the eCard-API-Framework, such as the usage of web services
interfaces and CardInfo files are forwarded to the international standardization [38].
3.2
Architecture
The architecture of the eCard-API-Framework is illustrated
in Figure 2. The framework distinguishes between four layers which represent the abstract view of applications down
to the physical connection to smart cards. The general sequence is as follows: Applications use abstract and generic
high-level messages. Requests are mapped in the cycle of
the layers to card-specific low-level APDUs and responses
are transformed vice versa. In the following we present each
layer in detail.
3.2.1
Application-Layer
The Application-Layer contains various applications which
use the interfaces of the eCard-API-Framework to access
applications, functions and services of eCards. Common
application-specific functions may be encapsulated in ”convenience interfaces” which are out of scope of the eCard-APIFramework, but may be useful to merge similar applicationspecific tasks.
3.2.2
Identity-Layer
The Identity-Layer provides the Management-Interface [21]
and the eCard-Interface [24], which can be used by various applications with appropriate permission as a public interface. The Management-Interface offers functions for updating and managing trusted identities, smart cards, card
terminals and default settings of the eCard-API-Framework
to regard client- or application-specific tasks. To manage
the eCard-API-Framework, functions to initialize and update the framework as well as to terminate the framework
and its appropriate sessions are included in this interface.
The access control for the individual functions of the eCardAPI-Framework can be managed by using Access Control
Lists (ACL).
The card recognition procedure of the framework uses CardInfo files which specify characteristics of various eCards (cf.
Section 3.1.4). The Management-Interface offers functions
to add or remove CardInfo files to or from the database.
Figure 2: The architecture of the eCard-API-Framework [25]
The same functions exist for configuration files for card terminals. Configurations are also used to manage trustworthy
display components (trusted viewers) which are used for secure password input or displaying documents for (qualified)
electronic signatures. The Management-Interface allows to
add or remove various trusted viewers. Electronic signatures require certificates for verification, thus the interface
includes functions for identity management to manage a
database of trustworthy identities and services. Additionally, non-trustworthy certificates can be added and be used
for signature verification or encryption. To obtain the revocation status of certificates time stamping, Online Certificate Status Protocol (OCSP) services or Directory Services via Lightweight Directory Access Protocol (LDAP) or
HTTP can be added to the framework configuration.
The eCard-Interface includes the main features of the eCardAPI-Framework and encapsulates cryptographic functions
for encryption and electronic signature. This interface provides functions to request the creation of (qualified) electronic signatures using data formats such as XML Signature
(XML-DSig) [16] or Cryptographic Message Syntax (CMS)
[35]. Besides, verification of signatures, time stamps and
certificates as well as displaying documents in a trustworthy
environment, which can be used for the creation and verification of signatures are part of this interface. Encryption
and decryption of data according to the XML Encryption
Syntax [15] or documents using the Cryptographic Message
Syntax are supported additionally.
3.2.3
Service-Access-Layer
The Service-Access-Layer comprises the Support-Interface
[27] and the ISO24727-3-Interface [23] and provides cryptographic as well as biometric services. The ISO24727-3Interface contains functions to perform cryptographic operations, to manage card applications and key storage, to
establish secure connections and data transmissions. This
layer is a web service-based implementation of the ISO/IEC
24727-3 [52] standard. The Support-Interface contains a set
of supporting functions such as decoding or encoding data
and validating XML documents.
The Card Application Service is initialized or terminated by
corresponding functions of the ISO24727-3-Interface. This
interface also provides a service to connect or disconnect
unauthenticated connections between client and card applications. Furthermore, sessions can be opened or closed between a client and a card application. After the connection
establishment, applications can request a list of available
card applications and services from the framework which
are provided by available smart cards. The ISO24727-3Interface also includes functions to delete or create new card
applications or card services. For card services the interface
additionally offers a function to determine the invocation
parameters and a function to permit the execution of an action of card application’s services.
The file system of an eCard is represented by a data set.
A data set consists of a sequence of information about the
data structure for interoperability (DSI) and related access
control informations. A DSI is indicated by a unique identifier (e.g. file name) and contains a reference to a stored
file on the card and optionally additional information. The
ISO24727-3-Interface supplies functions to get a list of data
sets of a card application and to create, select or delete a
data set. To get information about the connected eCard, the
framework offers a function to receive the associated CardInfo file. Further, the function allows retrieving additional
CardInfo files from a CardInfoRepository server.
The interface offers various cryptographic services such as
encryption and decryption. Notice that the mapping to the
card-specific characteristics (cf. Section 3.1.4) takes place in
this layer. Hence, the cryptographic services are accessed by
APDUs whereas high-level requests are used in the eCardInterface. To support digital signatures and certificates the
interface provides functions for verification and signing binary messages. Additional functions for hashing and generation of random numbers are included. The detailed functionality of the cryptographic service is determined by the
protocol of the Crypto identity (see [26]). As described
in Section 3.2.2 access control for the individual functions
of the eCard-API-Framework can be defined by using the
Management-Interface. The ISO24727-3-Interface additionally allows defining access control rules for accessing a card
application. Limited resources of smart cards cause that
some functions cannot be performed on the card. Due to
performance issues some calculations may be performed on
interface devices or local devices without the assistance of a
smart card. The Support-Interface provides such functions
like decoding and encoding data or compressing and decompressing data. Functions to validate an XML document on
the basis of a schema are also included.
3.2.4
Terminal-Layer
The Terminal-Layer provides a common and homogeneous
interface for arbitrary smart cards and card terminals. The
layer contains the IFD-Interface4 [22] which hides special
characteristics of the underlying hardware. Therefore, the
communication and addressing of an eCard as well as the
physical characteristics like contact or contactless cards are
not important for application development.
The IFD-Interface provides functions to get a list of available
card terminals and their capabilities and status. Terminal
events like communication problems or new detected cards
are notified to layers above the Terminal-Layer. For additional control of the terminal, the interface allows to send
hardware-specific and proprietary commands.
Each connection established by the IFD-Interface to a card
terminal uses a unique identifier to handle the communication. The same manner is used to address different cards.
The identifier of a terminal and a card are used for transmission between applications and cards. The interface supports
sending a set of several commands which decrease the overhead for the communication compared to a common transmission and acknowledgement scheme.
4
IFD is an abbreviation for interface device (e.g. a card
terminal)
Figure 3: Architecture of the ISO/IEC 24727 ICC
Programming Interfaces [49]
For card terminals with a display or keypad the IFD-Interface
allows to present information on the terminal or to send a
verification command which request a password input by the
user. As illustrated in Figure 2, eCards can be addressed by
card-specific interfaces like the SICCT-Interface (Secure Interoperable ChipCard Terminal), CT-API-Interface (CardTerminal Application Programming Interface) or the common
SCard-Interface (PC/SC) [22].
3.3
ISO/IEC 24727
This section provides a brief overview and a comparison between the ISO/IEC 24727 and the eCard-API-Framework.
As shown in Figure 2 and 3 both interfaces assume client
applications on the top layer. Applications send Action Requests to the Service Interface to access the functionality
of smart cards. This interface includes common functions
to connect to card applications, store and retrieve data and
perform cryptographic operations (cf. Figure 3). Additionally, this interface allows managing card applications, access
rights, identities and services. In general, the functionality
corresponds to the Management-Interface and the eCardInterface (cf. Section 3.2.3). An Action Request is a highlevel command which does not consider any card-specific
properties. The Service Access Layer (SAL) maps these request to Generic Request. The mapping may generate one
or more Generic Requests to represent an Action Request.
A Generic Requests is a common APDU which allows a subset of the commands and options defined in ISO/IEC 7816
(Part 4, 8, 9) [42]. If the smart card does not support these
types of APDUs, an additional mapping is performed by
the Generic Card Access Layer before the Specific Request
is send to the card application.
3.4
Web service binding
As described in Section 3.1 the interfaces of the eCard-APIFramework are specified as web service interfaces using the
XML-based Web Services Definition Language (WSDL). For
the data transport between remote systems, such as client
and server application, the SOAP protocol is used. SOAP
is a protocol for exchanging XML structured information in
the implementation of web services. The specification of the
eCard-API-Framework requests at least the following web
service bindings to be supported [25]:
• SOAP over HTTP v1.1 [7]
• Reverse HTTP binding for SOAP (PAOS) v1.1 [2]
• Reverse HTTP binding for SOAP (PAOS) v2.0 [3]
These bindings define the transport protocol to transmit
SOAP messages. The most common SOAP over HTTP
Binding simply adds a HTTP header to a SOAP message.
Therefore the binding uses HTTP requests to send SOAP
requests and SOAP responses with the respective HTTP reply. However, to handle HTTP or rather SOAP requests a
web server is required, though, in general personal computers or mobile devices do not operate a HTTP server. The
reasons are for example limited resources or security policies. Hence, we cannot request information from a device
using the SOAP over HTTP Binding, if incoming HTTP
connections are not feasible.
The Reverse HTTP binding for SOAP (PAOS) sends SOAP
requests with HTTP responses and vice versa [3]. Thus,
the PAOS Binding allows sending (SOAP) requests to a
client which generally cannot handle incoming HTTP connections.
4.
EID SCENARIO
This section demonstrates the eCard-API-Framework in case
of the eID application of the German identity card (cf. Section 2.1). The scenario describes the usage of the German
ID card to authenticate to a web service. Due to the extensive specifications of the eCard-API [25], the eID interface
[31] and the security mechanisms [29] of the German identity card we only focus on the basic functionality and refer
to the specification for further information.
4.1
Overview
Figure 4 shows the participants of the eID scenario. The
eService is a provider that offers a service (e.g. webmail,
online shop, or social network) and generally requires an
authentication by its customers. If a client wants to access
a service (e.g. webmail account), the eService redirects them
to the eID-Server to perform an authentication and informs
the server about an upcoming authentication request from
the respective client. The client uses a credential (eID card)
to authenticate to the eID-Server. After that procedure,
the server provides these information back to the eService.
Finally the eService grants access to the client requested
service.
Figure 4: Scenario of the electronic identification
using the German identity card. The connection
between the client, eService and eID-Server is protected via TLS. The contactless connection between
the client attached card terminal and the eID card
is secured by PACE. The EAC security mechanism
protects the virtual circuit between the eID-Server
and the eID card.
define the data groups (e.g. name, and address) which
should be read from the eID card. The individual data
groups can be labeled as required, allowed or prohibited. The eID-Server application sends a TC_API_Open
command to the local running eCard-API instance to
initialize an upcoming PAOS connection from the client.
The command is handled by the Service-Access-Layer
(SAL) (cf. Section 3.2.3), which generates a random
ephemeral pre-shared key (PSK) and a session identifier (SessionIdentifier) for the upcoming connection from the client. The eID-Server SAL answers
with a TC_API_OpenResponse and delivers the PSK and
the SessionIdentifier to the eID-Server application.
The application uses an useIDResponse message including a status information, the PSK and the SessionIdentifier to confirm the authentication request
by the eService (cf. Section 4.2.1 in [31]). The eService and the eID-Server SAL now share a PSK and a
SessionIdentifier. In the next step these values are
delivered to the client.
This section describes the connection establishment between
the client, eService and the eID-Server in the scenario of
the electronic identification using the German eID card (cf.
Figure 5).
3. The client receives the HTTP response corresponding to the request in Step 1. The response includes
a HTML object tag [36] with additional parameters
such as a refresh address, the eID-Server address, the
PSK and the SessionIdentifier, which instructs the
web browser to run a browser plugin (client side eID
application). The eID application starts an eCard-API
instance and transfers the PSK and the SessionIdentifier to the client SAL.
1. The client application (e.g. web browser) establishes
a TLS connection according to RFC 4346 [14] to the
eService (e.g. web server). Through this channel the
client sends a HTTP request to indicate a service request and a further PAOS connection.
4. The client SAL establishes a PSK based TLS [18] connection to the eID-Server SAL using the PSK and the
SessionIdentifier received by the eService in Step
3. The SessionIdentifier takes place in the ClientKeyExchange message [18] of the TLS protocol to indicate the server which key should be used.
2. The eService uses the useID function of the eID interface [31] of the eID-Server to initialize the authentication request. The parameters of the useIDRequest
5. Through the TLS channel the client sends a StartPAOS
message to establish a PAOS connection to the eIDServer.
4.2
Connection establishment
7. The client application displays information about the
eService and required data groups (CHAT) and asks
for the card holder’s PIN. The user is able to impose
further restrictions on the CHAT. The PACE6 protocol is performed to secure the connection between the
client’s card terminal and the smart card. The client
responses with a DIDAuthenticateReponse containing
user’s modified CHAT and additional data to perform
the EAC protocol in the next step.
8. The next four messages represent the EAC7 protocol
which is performed between the eID-Server and the
eID card. At this stage the EAC protocol establishes
a secure connection between the eID card and the eIDServer. The transmission over the Internet is additionally protected by the TLS channel. Note that the EAC
protected channel is directly established between the
server and the card, hence the client cannot recognize
any further data transmission.
Figure 5: Sequence diagram of the connection between the client, eService and eID-Server.
After Step 5 the client has a TLS protected connection to the
eService and a PSK based TLS connection to the eID-Server.
Through the TLS connection to the eID-Server the client is
now ready to send further web service commands using the
established PAOS connection. As described in Step 2 and 3
every participant shares the PSK and particularly the SessionIdentifier. The SessionIdentifier serves to identify the client request during the connection between client
and eID-Server as well as between eService and eID-Server.
The PSK based TLS binds the connection to the eID-Server
and prevents a man-in-the-middle attack between client and
server (cf. Section 3.3.10 in [26] and [17]).
4.3
Protected channel
In this Section we describe the establishment of a protected
channel between the eID-Server and the German eID card
to access and read the citizen’s personal data. The communication sequence is depicted in the steps 6 to 12 in Figure
5. We assume an established PAOS connection as described
in Section 4.2. See Section 3.3.5 in [26], Section 4.2 in [31]
and Section 4 in [29] for further information.
6. The DIDAuthenticate message send by the server contains the eService certificate, corresponding certificate
descriptions, CHAT5 and additional data for the EAC
protocol.
5
The CertificateHolderAuthorizationTemplate (CHAT)
describes a set of access rights for data groups and special
functions which are required by the eService. See Appendix
C.4 in [29].
9. The Transmit message includes a set of APDUs which
are send sequential to the card (see TransmitAPDUs
in Figure 5). The responses of the APDUs are forwarded to the server in the TransmitResponse message. The client does not know the keys for the encrypted EAC connection, therefore the APDUs are already well formed and encrypted. The client just extracts the APDUs out of the SOAP message and forwards them to the smart card. This step represents
the actual data transmission of the citizen’s personal
data through the secured EAC channel.
10. The eID-Server completes the authentication by sending a StartPAOSResponse message.
11. The eService uses a getResultRequest command to
get the results of the authentication process. The command includes the SessionIdentifier to identify the
corresponding client. The eID-Server answers with a
getResultResponse containing the requested personal
data (cf. Section 4.2.2 in [31]).
12. Finally the client SAL returns a TC_API_OpenResponse
command, which informs the eID application to trigger
the web browser and open the RefreshAddress stored
in the object tag (cf. Step 3).
At last the client can terminate the eCard-API instance,
close the connection to the eID card and the TLS connection
to the eID-Server.
6
Password Authenticated Connection Establishment
(PACE) [29] is a Password-based protocol using a short
and weak password (PIN) to establish a secure connection
between the card terminal and the eID card.
7
Extended Access Control (EAC) [29] is a security mechanism to perform a mutual authentication between the card
terminal and the eID card. EAC contains the Chip Authentication (CA) protocol to establish a secure channel between
the card and the terminal and to guarantee the authenticity of the smart card chip and the Terminal Authentication
(TA) protocol to verify the access restrictions of the terminal
to access sensitive data.
Figure 6: Layers involved in the communication
4.4
Layered transmission
Figure 6 illustrates the layers involved into the communication during the authentication procedure between the client
and the eID-Server. As described in Section 3.2 the applications are located at the top of the framework (cf. Figure 2)
and initialize the eCard-API-Framework instance. In Section 4.2 we described the connection establishment of the
PSK based TLS connection and the enclosed PAOS connection. This stage is illustrated in Figure 6 as the two connected SAL layers. The DIDAuthenticate command is part
of the ISO24727-3 interface and enables a connection establishment between the two eCard-API-Framework instances
running on client and server. Note that in this scenario the
EAC protocol is used. Part 7 of the framework [26] defines
additional protocols to set up an authenticated connection.
The Terminal-Layer or IFD interface addresses the attached
card, hence the Transmit command is part of the IFD interface [22]. The general procedure is as follows: Initialize the
framework and establish a secure and authenticated connection between the SAL layers. Then use commands of the
IFD interface to access the attached card. The eID application running on the server, which tries to access the German
eID card, is suppose to communicate with the local terminal
layer. A so-called dispatcher forwards messages to the local
layers or to a remote eCard-API-Framework instance.
5.
TOWARDS A NEXT GENERATION API
In this section we consider improvements of the eCard-APIFramework. We focus on data transmission between the
eCard-API client and the eID server and the handling of
CardInfo files.
5.1
WebSockets
As presented in Section 3.4, the eCard-API-Framework supports the HTTP Binding and the PAOS Binding for transmitting SOAP messages between client and server. In the
eID scenario (cf. Section 4), where HTTP requests, acknowledges and responses are send between client and server, a
lot of communication traffic, so-called overhead, and time is
needed for data transmission. We cannot suppose that the
client runs a HTTP server and can accept HTTP requests,
hence the PAOS Binding is the only applicable solution for
a communication between the client and server corresponding to the eCard-API-Framework (cf. Section 3.4). Current attempts to provide real-time data transmission without constantly sending requests and manually initiating the
process, web applications largely revolve around long-polling
and other server-side push technologies.
Long-polling describes a technique, where a HTTP request
is kept open for a set period. Once the information becomes
available (or after a suitable timeout), a complete response
is send to the client. The client then is normally re-request
information from the server, so that the server has always
an available waiting request that it can use to deliver data
in response to an event. But for a high message volume,
long-polling does not provide any substantial performance
improvements over traditional polling [54]. However, realtime data is often not that predictable, making unnecessary requests inevitable and as a result, many connections
are opened and closed needlessly in low-message-rate situations. To optimize the process and improve the communication between a server application and any eCard-API client,
we provide a new approach to reduce unnecessary network
traffic and latency by using WebSockets.
The WebSockets protocol [34, 32] is an independent TCPbased protocol that allows bi-directional network communications over a single TCP socket. By using a well-formed
HTTP CONNECT command to start the handshake, it allows HTTP servers to interpret the initial handshake as
a HTTP request and switch to the WebSocket protocol.
Therefore, the WebSocket protocol uses port 80 for unencrypted connections by default and port 443 for secure and
encrypted WebSocket connections tunneled over TLS. Unlike standard HTTP transmissions, the communication channel between client and server must only be established once,
so that data frames can be sent back and forth between the
client and the server in full-duplex mode. Thus, no further
connection handshakes and message packaging has to be set
up which saves time, communication overhead and enables
real-time data exchange. Looking into the amount of header
overhead that is associated with each standard HTTP request/response, the average quantity of bytes is between a
few hundred bytes up to several kilo bytes. Using WebSockets the amount of header information reduces to only two
bytes [32] which minimize the bulk of unnecessary network
throughput. Comparing the latency between polling and
WebSockets, one can see an additional significant reduction
of transmission time. Thus, the message round-trip time
with polling is twice as much as using WebSockets, since the
connection is kept open and new messages can be sent directly instead of a constant request and response procedure
with polling. This performance boost is especially visible
when using mobile devices. As mobile communication has a
higher latency due to slower communication channels, a reduction of message exchange between server and the mobile
device is desirable. Considering the eID scenario (cf. Section
4), where a mobile device with lower bandwidth occupies the
role of the client, the use of the WebSocket technique brings
a significant performance improvement.
One of the more unique features WebSockets provides is its
ability to traverse firewalls and proxies. A WebSocket detects the presence of a proxy server and automatically sets
up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the
proxy server, which requests for the proxy server to open
a TCP/IP connection to a specific host and port. Once
the tunnel is set up, communication can flow unimpeded
through the proxy.
Nonetheless, the protocol is until now (12/2010) still in beta
status and not fully implemented in browsers. Especially
an unresolved security issue [37], where attacks poison the
proxy’s cache, causing all clients of the proxy to receive ma-
licious content supplied by the attacker, prevents the safe
usage of WebSockets in browsers. Nevertheless, WebSockets provides an enormous reduction in unnecessary network
traffic and latency compared to the non-scaleable polling
and long-polling solutions that were used to simulate a fullduplex connection by maintaining two connections. So after
resolving all security problems, the final WebSockets protocol could become the future technology in real-time data
communication over the Internet.
5.2
Generic Card Service
As described in Section 3.1.4 the eCard-API-Framework uses
CardInfo files, which specify the characteristics of an eCard,
to determine attached smart cards. The CardInfo file for
the German eID card has a size of approximately 100 KB
and 2500 lines of data and for the German eHealth card
a size of approximately 375 KB and nearly 12000 lines are
needed8 . The CardInfo files include a <CardIdentification> element, which allows creating a decision tree and
determining the attached card by checking the characteristic features for correctness. The <CardIdentification>
element has approximately 140 lines in the CardInfo file for
the German eID card and 290 lines for the eHealth card
respectively. However a decision tree can be generated on
the CardInfo repository server too. It would be possible
that a repository server provides a calculated decision tree
in a first step (which is permanently stored at the client) and
the whole set of CardInfo files provided only if it is additionally requested. This has the advantage that the calculation
is performed on the server and less traffic and storage on
the client side are required. Particularly in a scenario with
mobile clients, which have limited resources and low bandwidth, this improves the card recognition procedure of the
eCard-API-Framework.
6.
FUTURE WORK
The projects and eCards described in Section 2 are located
in different areas of our life. Another card, which is not
an electronic smart card yet, is the German version of the
current European driving licence. The corresponding European Directive 2006/126/EC [1] already describes an optional microchip and the ISO/IEC 18013 [47] specifies physical characteristics, data sets and access control for machinereadable driving licences. Smart cards like the German eID
card illustrate that official documents are also applicable
in the private sector. It is obvious that a driving licence
with an integrated chip and a contactless interface is suitable to be used as a car key. We expect that the car doors
are equipped with a Near Field Communication (NFC) [45,
46] interface and establish a contactless communication with
the smart card. The driving licence and the car perform a
mutual authentication based on digital signatures according
to ISO/IEC 9798-3 [41] to open the doors. Additionally, a
password-based protocol [8] such as PACE or SPEKE (Simple Password Exponential Key Exchange) may be performed
to start the engine. The fact that similar technologies are
already used by car rental services, point out that such a
scenario is feasible, but requires great efforts for an interoperable solution.
8
The CardInfo files are available at https://www.bsi.bund.
de/ContentBSI/Publikationen/TechnischeRichtlinien/
tr03112/index_htm.html
7.
CONCLUSIONS
In summary, the Federal Government wants to significantly
reduce the administrative costs, modernize management processes, increase efficiency, reduce data storage, enable secure
transmission as well as relieve paper-based certificates and
forms. Moreover, electronic signatures are the key for seamless media, legal security and protected digital processes
such as eBanking, invoices or filling out forms. Through
the authentication function the eBusiness and eGorvernment procedures on the Internet becomes more secure and
more comfortable.
This paper presented the projects of the German eCardStrategy and the technical part of the realization and combination of the projects. The projects are located in different
areas of our life and provide a modern eGoverment as well
as a usage in the private sector. We described the scope,
features and the architecture of the eCard-API-Framework
which is designed to provide a standardized interface for
the different projects, smart cards, applications and future
developments. We used the popular eID scenario to describe the application flow and employment of the eCardAPI-Framework. In focus to the data transmission, we discussed the usage of WebSockets to decrease the communication overhead and the improved handling of CardInfo files.
Finally we considered an enhanced German driving license
as a prospect of a future eCard project.
8.
REFERENCES
[1] Directive 2006/126/EC of the European Parliament
and of the Council of 20 December 2006 on driving
licences (Recast). Official Journal of the European
Union, L403, pp. 18-60, 30.12.2006, 2006. http:
//eur-lex.europa.eu/LexUriServ/LexUriServ.do?
uri=OJ:L:2006:403:0018:0060:EN:PDF.
[2] R. Aarts. Liberty Reverse HTTP Binding for SOAP
Specification. Liberty Alliance Specification, Version
1.1, 2003.
http://www.projectliberty.org/liberty/content/
download/1219/7957/file/liberty-paos-v1.1.pdf.
[3] R. Aarts and J. Kemp. Liberty Reverse HTTP
Binding for SOAP Specification. Liberty Alliance
Specification, Version 2.0, 2006.
http://www.projectliberty.org/liberty/content/
download/909/6303/file/liberty-paos-v2.0.pdf.
[4] Bavarian State Tax Office (Bayrisches Landesamt für
Steuern). ELSTER, Meilensteine eines erfolgreichen
eGovernment-Projektes, 2010.
https://www.elster.de/download/
ELSTER-Strategiepapier_06.05.2010.pdf.
[5] Bayerisches Landesamt fÃijr Steuern. ElsterOnline das Dienstleistungsportal der Finanzverwaltung.
Website, 2011. Available online at
https://www.elster.de visited on February 20th
2011.
[6] J. Bender, M. Fischlin, and D. Kügler. Security
Analysis of the PACE Key-Agreement Protocol. In
Information Security Conference (ISC) 2009, volume
5735 of Lecture Notes in Computer Science, pages
33–48. Springer, Sep 2009.
[7] D. Box, D. Ehnebuske, G. Kakivaya, A. Layman,
N. Mendelsohn, H. F. Nielsen, S. Thatte, and
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
D. Winer. Simple Object Access Protocol (SOAP) 1.1,
2000.
http://www.w3.org/TR/2000/NOTE-SOAP-20000508.
C. Boyd and A. Mathuria. Protocols for Authentication
and Key Establishment. Springer, 2003.
B. P. Bruegger, D. Hühnlein, and M. Kreutzer.
Towards global eID-interoperability. In BIOSIG 2007:
Biometrics and Electronic Signatures, Proceedings of
the Special Interest Group on Biometrics and
Electronic Signatures, pages 127–140, 2007.
E. Christensen, F. Curbera, G. Meredith, and
S. Weerawarana. Web Services Description Language
(WSDL) 1.1, 2001.
http://www.w3.org/TR/wsdl.html.
Comité Européen de Normalisation (CEN).
Identification card systems - European Citizen Card Part 1-4, CEN/TS 15480. Technical Specification,
2008.
D. Cooper, S. Santesson, S. Farrell, S. Boeyen,
R. Housley, and W. Polk. Internet x.509 public key
infrastructure certificate and certificate revocation list
(crl) profile. Request For Comments – RFC 5280, Mai
2008. http://www.ietf.org/rfc/rfc5280.txt.
Ö. Dagdelen and M. Fischlin. Security analysis of the
extended access control protocol for machine readable
travel documents. In 13th Information Security
Conference, Lecture Notes in Computer Science.
Springer, Okt 2010.
T. Dierks and E. Rescorla. The Transport Layer
Security (TLS) Protocol - Version 1.1. Request For
Comments – RFC 4346, April 2006.
http://www.ietf.org/rfc/rfc4346.txt.
D. Eastlake and J. Reagle. XML Encryption Syntax
and Processing. W3C Recommendation, 2002.
http://www.w3.org/TR/xmlenc-core/.
D. Eastlake, J. Reagle, and D. Solo. (Extensible
Markup Language) XML-Signature Syntax and
Processing. Request For Comments – RFC 3275, 2002.
J. Eichholz, D. Hühnlein, and J. Schwenk. SAMLizing
the European Citizen Card. In BIOSIG 2009 Proceedings of the Special Interest Group on
Biometrics and Electronic Signatures, pages 105–116,
2009.
P. Eronen and H. Tschofenig. Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS).
Request For Comments – RFC 4279, December 2005.
Federal Minister of Economics and Technology
(Bundesministerium für Wirtschaft und Technologie).
Das ELENA-Verfahren, 2009.
http://www.bmwi.de/BMWi/Redaktion/PDF/
Publikationen/elena-verfahren-broschuere.pdf.
Federal Office for Information Security (Bundesamt für
Sicherheit in der Informationstechnik). Anforderungen
an Chipkartenleser mit ePA Unterstützung. Technical
Guideline BSI-TR-03119, Version 1.1, 2009. https:
//www.bsi.bund.de/ContentBSI/Publikationen/
TechnischeRichtlinien/tr03119/index_htm.html.
Federal Office for Information Security (Bundesamt
für Sicherheit in der Informationstechnik).
eCard-API-Framework – eCard-Interface. Technical
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
Guideline BSI-TR-03112-2, Version 1.1, 2009.
https://www.bsi.bund.de/cln_156/ContentBSI/
Publikationen/TechnischeRichtlinien/tr03112/
index_htm.html.
eCard-API-Framework – IFD-Interface. Technical
index_htm.html.
eCard-API-Framework – ISO24727-3-Interface.
Technical Guideline BSI-TR-03112-4, Version 1.1,
2009. https://www.bsi.bund.de/cln_156/
ContentBSI/Publikationen/
eCard-API-Framework – Management-Interface.
Technical Guideline BSI-TR-03112-3, Version 1.1,
2009. https://www.bsi.bund.de/cln_156/
ContentBSI/Publikationen/
eCard-API-Framework – Part 1-7. Technical Guideline
BSI-TR-03112, Version 1.1, 2009. https://www.bsi.
bund.de/cln_156/ContentBSI/Publikationen/
eCard-API-Framework – Protocols. Technical
index_htm.html.
eCard-API-Framework – Support-Interface. Technical
index_htm.html.
für Sicherheit in der Informationstechnik). eCards mit
kontaktloser Schnittstelle als sichere
Signaturerstellungseinheit, Version 1.0. Technical
Guideline BSI-TR-03117, 2009. https:
//www.bsi.bund.de/ContentBSI/Publikationen/
für Sicherheit in der Informationstechnik). Advanced
Security Mechanism for Machine Readable Travel
Documents - Extended Access Control (EAC),
Password Authenticated Connection Establishment
(PACE), and Restricted Identification (RI). Technical
Directive BSI-TR-03110, Version 2.05, 2010.
https://www.bsi.bund.de/SharedDocs/Downloads/
EN/BSI/Publications/TechGuidelines/TR03110/
TR-03110_v205_pdf.pdf.
[30] Federal Office for Information Security (Bundesamt
für Sicherheit in der Informationstechnik). Architektur
elektronischer Personalausweis und elektronischer
Aufenthaltstitel. Technical Guideline BSI-TR-03127,
Version 1.13, 2010. https://www.bsi.bund.de/cln_
156/ContentBSI/Publikationen/
TechnischeRichtlinien/tr03127/tr-03127.html.
[31] Federal Office for Information Security (Bundesamt
für Sicherheit in der Informationstechnik). Technische
Richtlinie eID-Server. Technical Directive
BSI-TR-03130, Version 1.4.1, 2010.
https://www.bsi.bund.de/SharedDocs/Downloads/
DE/BSI/Publikationen/TechnischeRichtlinien/
TR03130/TR-03130_TR-eID-Server_V1_4_pdf.pdf.
[32] I. Fette. The WebSocket protocol, 2010.
http://tools.ietf.org/html/
draft-ietf-hybi-thewebsocketprotocol-03.
[33] gematik. The Specification of the German Electronic
Health Card eHC – Part 1-3, Version 2.2.0, 2008.
http://www.gematik.de/cms/de/spezifikation/
wirkbetrieb/release_0_5_2/release_0_5_2_egk/
release_0_5_2_dokumentezuregk.jsp.
[34] I. Hickson. The WebSocket API. Editor’s Draft 1
November 2010.
http://dev.w3.org/html5/websockets/.
[35] R. Housley. Cryptographic Message Syntax (CMS).
Request For Comments – RFC 3369, 2002.
[36] HTML 4.01 Specification. W3C Recommendation,
1999. http://www.w3.org/TR/html4/.
[37] L.-S. Huang, E. Y. Chen, A. Barth, E. Rescorla, and
C. Jackson. Transparent Proxies: Threat or Menace?,
2010. http://www.adambarth.com/experimental/
/websocket.pdf.
[38] D. Hühnlein and M. Bach. From the
eCard-API-Framework towards a comprehensive
eID-framework for Europe. pages 276–286.
ISSE/SECURE 2007, 2007.
[39] International Civil Aviation Organization (ICAO).
Machine Readable Travel Documents, Part 1-3. ICAO
Doc 9303, 2006 - 2008. http:
//www2.icao.int/en/MRTD/Pages/Doc9393.aspx.
[40] International Civil Aviation Organization (ICAO).
Supplemental Access Control for Machine Readable
Travel Documents, 2009.
[41] ISO/IEC. Information technology – Security
techniques – Entity authentication – Part 3:
Mechanisms using digital signature techniques,
ISO9798-3. International Standard, 1998.
[42] ISO/IEC. Identification cards – Integrated circuit
cards – Part 1-13, 15, ISO/IEC 7816. International
Standard, 1998-2008.
[43] ISO/IEC. Identification cards – Contactless integrated
circuit cards – Proximity cards – Part 1-4, ISO/IEC
14443. International Standard, 2001-2010.
[44] ISO/IEC. Identification cards – Integrated circuit
cards – Part 4: Interindustry commands for
interchange, ISO/IEC 7816-4. International Standard,
2004.
[45] ISO/IEC. Information technology –
Telecommunications and information exchange
between systems – Near Field Communication –
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]
[57]
[58]
[59]
[60]
Interface and Protocol (NFCIP-1), ISO/IEC 18092,
2004.
ISO/IEC. Information technology –
Telecommunications and information exchange
between systems – Near Field Communication
Interface and Protocol -2 (NFCIP-2), ISO/IEC 21481,
2005.
ISO/IEC. Information technology – Personal
identification – ISO-compliant driving licence – Part
1-3, ISO/IEC 18013. International Standard,
2005-2009.
ISO/IEC. Identification cards – Integrated circuit
cards – Part 3: Cards with contacts – Electrical
interface and transmission protocols, ISO/IEC 7816-3.
International Standard, 2006.
ISO/IEC. Identification cards – Integrated circuit card
programming interfaces – Part 1: Architecture,
ISO/IEC 24727-1. International Standard, 2007.
programming interfaces – Part 1-4, ISO/IEC 24727.
International Standard, 2007-2008.
programming interfaces – Part 2: Generic card
interface, ISO/IEC 24727-2. International Standard,
2008.
programming interfaces – Part 3: Application
interface, ISO/IEC 24727-3. International Standard,
2008.
B. Kowalski. Die eCard-Strategie der Bundesregierung
im Überblick. In BIOSIG 2007: Biometrics and
Electronic Signatures, Proceedings of the Special
Interest Group on Biometrics and Electronic
Signatures, pages 87–96, 2007.
P. Lubbers and F. Greco. HTML5 Web Sockets: A
Quantum Leap in Scalability for the Web. Kaazing
Corporation, 2010.
http://websocket.org/quantum.html.
G. Meister. Umsetzung der eCard Strategie auf Basis
Europäischer Standards - Korrelation mit der
Gesundheitskarte und dem Deutschen
Personalausweis. Giesecke & Devrient, 2006.
G. Meister and H. Daum. Anwendungsprofile der
European Citizen Card. DACH Security, 2007.
A. Reisen. Ein Personalausweis für die reale und die
elektronische Welt. innovative VERWALTUNG,
Ausgabe 3/2009, 2009.
http://www.cio.bund.de/cae/servlet/
contentblob/559872/publicationFile/32795/
innovative_verwaltung_200903_epa.pdf.
RSA Laboratories. PKCS #11: Cryptographic Token
Interface Standard - Version 2.2. Public Key
Cryptography Standards, 2004.
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/
v2-20/pkcs-11v2-20.pdf.
Sun Microsystems, Inc. JSR 224: Java API for
XML-Based Web Services (JAX-WS) 2.0.
http://jcp.org/en/jsr/detail?id=224, 2009.
The Apache Software Foundation. Apache CXF: An
Open-Source Services Framework. Website, 2011.
Available online at http://cxf.apache.org visited on
February 20th 2011.

The German eCard-Strategy - Technische Universität Darmstadt

Transcrição

Documentos relacionados

Globale Kommunikation Astallerstraße 20 80339 München http

directions

Learn German with DW

reflections of an American scientist living in Göttingen

Material Specification EN 10204-2.1

Curriculum Vitae

making a phone call

Create your Photobook in 4 Simple Steps

ficha técnica

Worksheet Version

Failure Modes, Effects and Diagnostic Analysis Pepperl+Fuchs GmbH