Cen Workshop Agreement Cwa 14722-3

CEN CWA 14722-3

WORKSHOP August 2004

AGREEMENT

ICS 35.240.15 Supersedes CWA 14722-3:2004

English version

Embedded financial transactional IC card reader (embedded FINREAD) - Part 3: Functional and Security Specifications

This CEN Workshop Agreement has been drafted and approved by a Workshop of representatives of interested parties, the constitution of which is indicated in the foreword of this Workshop Agreement.

The formal process followed by the Workshop in the development of this Workshop Agreement has been endorsed by the National Members of CEN but neither the National Members of CEN nor the CEN Management Centre can be held accountable for the technical content of this CEN Workshop Agreement or possible conflicts with standards or legislation.

This CEN Workshop Agreement can in no way be held as being an official standard developed by CEN and its Members.

This CEN Workshop Agreement is publicly available as a reference document from the CEN Members National Standard Bodies.

CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: rue de Stassart, 36 B-1050 Brussels

Ref. No.:CWA 14722-3:2004 E

CWA 14722-3:2004 (E)

Contents Page

Foreword...... 4 1 Scope ...... 4 2 Normative references ...... 6 3 Terms, definitions and abbreviations...... 7 3.1 Terms and definitions ...... 7 3.2 Abbreviation ...... 8 4 Part I – Functional specifications...... 11 4.1 The basics of Embedded FINREAD ...... 11 4.2 Embedded FINREAD operating modes ...... 23 4.3 Peripherals ...... 26 4.4 Embedded FINREAD Card Reader Applications ...... 28 4.5 Embedded FINREAD card reader authentication ...... 30 4.6 Embedded FINREAD card reader application functions ...... 31 4.7 Embedded FINREAD Aware Application functions...... 33 4.8 Application provisioning and key management functions...... 34 4.9 Vendor specific functions...... 34 5 Part II – Security specifications...... 34 5.1 Assumptions ...... 34 5.2 Security Requirements...... 36 5.3 Specification of implementation ...... 40 5.4 Key management ...... 43 5.5 Cryptographic functions and random number generator ...... 46 Annex A Security objectives, Security requirements and rationale...... 48 A.1 Introduction ...... 48 A.2 EFCR GENERIC MODEL DESCRIPTION...... 51 A.3 EFCR SECURITY ENVIRONMENT ...... 56 A.4 SECURITY OBJECTIVES...... 62 A.5 IT SECURITY FUNCTIONAL REQUIREMENTS...... 64 A.6 RATIONALE ...... 67 A.7 Glossary...... 85 A.8 Common Criteria glossary...... 86

2 CWA 14722-3:2004 (E)

Figures Page

Figure 1 – Example of an Embedded FINREAD Device ...... 11

Figure 2 – Generic Integrated EFD architecture...... 12

Figure 3 – Simplified example of an Embedded FINREAD system architecture used in a payment context ...... 13

Figure 4 – Activation of an EFCRA by a push command ...... 15

Figure 5 – Activation of an EFCRA by a resident DVB-MPH Xlet embedded in a DVB-HTLM page...... 17

Figure 6 – Activation of a standalone EFCRA by the user ...... 18

Figure 7 – Communication with remote entities initiated by the EFCRA ...... 19

Figure 8 – EFCR architecture overview...... 21

Figure 9 – Logical host hardware and software components...... 23

Figure 10 – Operating mode state diagram...... 24

Figure 11 – Suspension of an EFCRA in Embedded FINREAD secure mode ...... 26

Figure 12 – EFCR firmware interface to resources ...... 32

Figure 13 – Firmware interface between EFAAs and the EFCR...... 34

Figure 14 – Example of a hierarchical certification tree ...... 44

Figure 15 – Example of a set of public keys for an Embedded FINREAD device ...... 46

Figure A.1 – Relations between Threats, Security Objectives, OSP and Security Requirements ...... 53

Figure A.2 – Scope of Embedded FINREAD ...... 53

Figure A.3 – Generic EFD architecture...... 54

Figure A.4 – EFD Hardware and Software architecture ...... 55

Figure A.5 – EFCR Life Cycle scheme...... 56

Figure A.6 – Internal Confidence Tree overview ...... 58

3 CWA 14722-3:2004 (E)

Foreword

The production of this CWA (CEN Workshop Agreement) specifying a Embedded Financial transactional IC card reader (Embedded FINREAD), was formally accepted at the Embedded FINREAD Workshop's kick-off meeting on 2001-12-14.

The document has been developed through the collaboration of a number of contributing partners in WS-Embedded FINREAD, representing smart card interests.

This CWA has received the support of representatives of each of these sectors. A list of company experts who have supported the document's contents may be obtained from the CEN/ISSS Secretariat.

This CWA consists of the following parts, under the general title Embedded Financial transactional IC card reader (Embedded FINREAD) :

 Part 1 : Business requirements

 Part 2 : Functional architecture and technical requirements

 Part 3 : Functional and security specifications

 Part 4 : Technical architecture and definition of APIs (Application Programming Interface)

CWA 14722-3 was approved at the Workshop meeting on 2003-02-12 and published by CEN in April 2003; a first revision was published in January 2004; this revised version (mainly editorial changes and lay-out issues) was submitted to CEN for publication on 2004-06-03.

4 CWA 14722-3:2004 (E)

1 Scope

This document defines functional and security requirements for the different components of the Embedded FINREAD device. It is structured in 2 parts as described hereafter:

Part I – Functional Specifications

 it gives an overall description of the Embedded FINREAD card reader architecture and components ;

 it describes in detail the different Embedded FINREAD card reader operating modes ;

 it specifies the characteristics and functional requirements of the main components of the Embedded FINREAD card reader ;

 it defines functions to be provided internally by the embedded FINREAD card reader environment for the Embedded FINREAD card reader applications ;

 it describes the functionality required by Embedded FINREAD aware applications to interface with the Embedded FINREAD card reader.

Part II – Security Specifications

 it describes security assumptions on which the risk analysis performed was based ;

 it lists security requirements for the different components of the Embedded FINREAD device;

 it describes the implementation of these requirements ;

 it describes key management ;

 it lists cryptographic functions and describes the random number generator provided by the core software.

The document Embedded FINREAD Security Objectives, Security Requirements and Rationale is added to this document as an Annex. The Security Requirements expressed in the Annex are set to be easily rewritten as a Protection Profile as regards the Common Criteria requirements.

The main objective of the Embedded FINREAD CWA is to provide a secure and interoperable solution which realistically matches the standards of the targeted industries.

According to the conclusions reached by part 2 of this CWA – Embedded FINREAD Technical Architecture and Functional Requirements, these specifications distinguish 3 different standard Java technologies for the runtime environment of the Embedded FINREAD card reader: J2ME/CLDC and MIDP 2.0, STIP Technology and DVB-MHP. Other Java standards compliant with Embedded FINREAD functional and security requirements may also be considered by industry actors who wish to implement these specifications.

The choice of basing the Embedded FINREAD specifications on several Java technologies, as opposed to a single technology common to all types of devices impacts Embedded FINREAD initial objectives of “global interoperability”:

The level of interoperability supported by Embedded FINREAD is the ability to run Embedded FINREAD card reader applications on different devices potentially having different capabilities and different architectures but supporting the same Java technology and having capabilities that meet the minimum required by the application.

5 CWA 14722-3:2004 (E)

The reason of this choice is to ensure that these specifications appropriately respond to real market needs: requiring vendors to change or adapt their basic Java technology in order to comply with Embedded FINREAD would likely dissuade them from implementing these specifications. Hence, mandating a single Java Technology is not practical, since it would potentially exclude useful devices that are based on other Java technologies.

Other aspects of interoperability such as protocol interoperability between different types of devices and application providers, or infrastructure interoperability between devices and service providers are part of the main objectives of Embedded FINREAD and are not affected by this choice.

Some requirements and functionality defined by this CWA are currently missing within the referenced Java environments. The organisations responsible for issuing the specifications of these environments are working towards the release of new versions that should take into consideration most of the missing functionality needed to comply with Embedded FINREAD. Part 4 of this CWA – Embedded FINREAD Technical Architecture and definition of APIs, provides a detailed description of the missing functionality for each referenced Java platform, and defines the technical responses to these issues.

2 Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of these specifications. For dated references, subsequent amendments to, or revisions of any of these publications, do not apply. However, parties to agreements based on Embedded FINREAD specifications are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies.

3GPP TS 23.057, Third Generation Partnership Project, Technical Specification Group Terminals, Mobile Execution Environment (MExE) Functional Description Stage 2.

STIP,STIP Specification version 2.1.1 – July 23, 2002.

JSR 118, Mobile Information Device Profile (MIDP), v2.0, Final Release 20 Nov 2002.

ETSI TS 102 812 V1.1.1, Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification 1.1, November 2001.

ETSI TS 101 476 V7.1.0, Digital cellular telecommunications system (Phase 2+); Subscriber Identity Module Application Programming Interface (SIM API); SIM API for Java Card™; Stage 2 (GSM 03.19 version 7.1.0 Release 1998).

ISO/IEC 20970, J Execution File Format (JEFF).

CEN/ ISSS CWA 14174 (all parts), Financial transactional IC card reader (FINREAD).

EMV 4.0 Book 1, Application independent ICC to Terminal Interface requirements.

ISO 7816 (all parts), Identification cards – Integrated circuit(s) cards with contacts.

ISO/IEC 8859-15, Information technology – 8-bit single-byte coded graphic character sets – Part 1 : Latin alphabet No. 9.

RFC 2313, PKCS#1 “RSA Encryption” Version 1.5.

RFC 2437, PKCS#1 “RSA Encryption” Version 2.0.

RFC 2459, Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

RFC 1321, The MD5 Message Digest Algorithm, Apr. 1992.

ANSI draft X9.52, Triple Data Encryption Algorithm Modes of Operation, Revision 6.0, May 1996.

6 CWA 14722-3:2004 (E)

ANSI X3.92, American National Standard for Data Encryption Algorithm, 1981.

ANSI X3.106, American National Standards for Information Systems, Data Encryption Algorithm – Modes of Operation, 1983.

FIPS PUBS 197, Advanced Encryption Standard (AES), 2001 November 26.

NIST FIPS PUB 180, Secure Hash Standard, Department of Commerce, Apr 1993.

NIST FIPS PUB 186-2, Digital Signature Standard (DSS) appendix 3.3, 2000.

3 Terms, definitions and abbreviations

3.1 Terms and definitions

For the purposes of the present document, the following terms and definitions apply :

Application Management Software AMS generic term used to describe the software on the device that manages the downloading and lifecycle of Java applications. This term does not refer to any specific implementation. In some cases, the term Java Application Manager (JAM) is used interchangeably core software these specifications use indifferently the term “firmware” or “core software” to designate the device dependent software provided by the vendor on top of which the Embedded FINREAD application runs

Embedded FINREAD Aware Application EFAA software program that runs either in the hosting device environment or on a distant entity. This application relies on the functionality provided by one or more ICCs and are executed in the secure environment of the EFCR. All sensitive functions required by the ICC Embedded FINREAD aware FINREAD application are executed by the related EFCRA, activated in the EFCR

Embedded FINREAD Card Reader EFCR Card Reader compliant with the Embedded FINREAD specifications. A hosting device in which an EFCR is embedded is called an Embedded FINREAD device

Embedded FINREAD Card Reader Application EFCRA Java™1) application signed by the appropriate entity that may be downloaded into the EFCR. When an EFCRA is activated and has locked its resources, the EFCR operates in Embedded FINREAD secure mode

Embedded FINREAD device EFD A hosting device with an Embedded FINREAD card reader firmware these specifications use indifferently the term “firmware” or “core software” to designate the device dependent software provided by the vendor on top of which Embedded FINREAD application runs

1) Java, and all Java based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.

7 CWA 14722-3:2004 (E)

hosting device environment non-trusted runtime environment of the Embedded FINREAD device, consisting of the components or functionality which are not included in the context of the EFCR (e.g. vendor tools, Embedded FINREAD aware applications, non-Embedded FINREAD applications, …)

IC card ICC an integrated circuit card, including both memory and microprocessor cards. This definition includes both ISO 7816 Identification cards (ID1 as defined by ISO 7816 – Part 2) and SIM card formats (ID000 as defined in GSM 11.11 – Annex A)

ICC aware application a term commonly used in PC/SC specifications, that refers to an arbitrary software program in the user equipment, which is designed to use the functionality provided by one or more ICCs. interface module IFM the interface module is the part of the EFCR’s FU “card interface unit” that consists of ICC contacts as well as of the hardware and software required to power the ICC and support communications with the ICC native code application / native application application whose code is not interpreted by an intermediate software level (e.g. a virtual machine) but directly executed by the system of the device. Depending on the targeted platform’s core libraries and access policies, a native application may have access to low level system functionality payment scheme scheme defined by an appropriate organisation to process payments. Payment scheme rules may cover : issuing and acquiring rules, ICC acceptance, clearing and settlement provisioning (of applications) term commonly used in various Java platform specifications, that refers to the deployment of applications. Provisioning includes the stages of applications discovery, download, installation and removal push command command which is transmitted by a server to a device without a previous user action. The “push” technology is based on the client/server model, but there is no explicit request from the client before the server transmits its content

3.2 Abbreviation

3GPP 3rd Generation Partnership Program

AES Advanced Encryption Standard

AMS Application Management Software

APDU Application Protocol Data Unit

API Application Programming Interface

CEN European Committee for Normalisation

CLDC Connected Limited Device Configuration

CPK Certified Public Key

CRL Certificate Revocation List

CWA CEN Workshop Agreement

8 CWA 14722-3:2004 (E)

DES Digital Encryption Standard

DTD Document Type Definition

DVB Digital Video Broadcasting

ECMA European Computer Manufacturer Association

EF Embedded FINREAD

EFAA Embedded FINREAD Aware Application

EFCR Embedded FINREAD Card Reader

EFCRA Embedded FINREAD Card Reader Application

EFD Embedded FINREAD Device

EMV Europay International S.A., MasterCard International Incorporated, VISA International Service Association

ETSI European Telecommunications Standards Institute

FIPS PUBS Federal Information Processing Standards Publications

FU Functional Unit

GSM Global System for Mobile Communication

HTTP Hyper-Text Transport Protocol

ICC, IC card Integrated Circuit Card (also called smart card)

IEC International Electrotechnical Commission

ISO International Organization for Standardization

J2ME Java™ 2 Micro Edition

JAD Java Application Descriptor

JAM Java Application Manager

JCP Java Community Process

JSR Java Specification Request

JVM Java Virtual Machine

KVM (Java) Kilobyte Virtual Machine

LED Light Emitting Diodes

MD5 Message Digest algorithm Rev 5

MExE Mobile Execution Environment

MHP Multimedia Home Platform

MID Mobile Information Device

9 CWA 14722-3:2004 (E)

MIDP Mobile Information Device Profile

MIDP NG, MIDP 2.0 Mobile Information Device Profile New Generation (JSR #118)

NIST National Institute of Standards and Technology

OCSP Online Certificate Status Protocol

OS Operating system

OSP Organisational Security Policies

OTA Over The Air

PC Personal Computer

PC/SC Personal Computer / Smart Card

PDA Personal Digital Assistant

PIN Personal Identification Number

PK Public Key

PKI Public Key Infrastructure

RFC Request For Comments

RMI (Java) Remote Method Invocation

RPK Root Public Key

RSA Rivest, Shamir and Adleman Public-key cryptography

SHA-1 Secure Hash Algorithm Rev 1

SIM Subscriber Identification Module

SR Security Requirement

STIP Small Terminal Interoperability Platform

UI User Interface

WAP Wireless Application Protocol

WML Wireless Markup Language

XML Extensible Markup Language

10 CWA 14722-3:2004 (E)

4 Part I – Functional specifications

4.1 The basics of Embedded FINREAD

4.1.1 EFD architecture

4.1.1.1 Overview

These Embedded FINREAD functional requirements address the functionality of an open and secure IC card reader that is a part of another device and which is used to protect electronic transactions on open networks.

Devices covered by these requirements are limited to the two following categories :

 private devices as a definition for devices used in the private environment such as IC card readers connected to a PC, set-top boxes etc. ;

 personal devices as a definition for devices that are mobile, but used under the control of an individual, such as mobile phones, PDAs, etc. Compared with devices used in the private environment, the user of a mobile device is already aware of the risk of loss and theft of his device.

Figure 1 provides an example of an Embedded FINREAD device (EFD), consisting of a hosting device environment which integrates and shares some of its resources with a logical Embedded FINREAD card reader (EFCR). The EFCR together with an ICC, constitute a trusted subset of the hosting device’s environment that provides the security required to carry out sensitive functions.

Embedded FINREAD device Embedded FINREAD card Embedded FINREAD reader resources such as ICC reader, display and keypad may be shared between Embedded FINREAD and the hosting device Hosting device

Display

IC Card Reader keypad card IC

Figure 1 — Example of an Embedded FINREAD Device

11 CWA 14722-3:2004 (E)

4.1.1.2 Generic architecture

Part 2 of this CWA – Embedded FINREAD Functional Architecture and Technical Requirements, presents the different hardware architectures addressed by the Embedded FINREAD specifications and categorises them as follow :

 integrated architecture with dual slot IC card reader (e.g. dual slot mobile phones) ;

 integrated architecture with second ID000 slot (e.g. dual chip mobile phones) ;

 integrated architecture with one IC slot (e.g. classic mobile phones equipped with a subscriber module containing Embedded FINREAD ICC applications) ;

 distributed architecture (e.g. set-top boxes using the TV set as display, the remote control as keypad and having the IC card reader in the main unit) ;

 independent architecture where the Embedded FINREAD card reader is an independent device (e.g. independent card reader connected to a PC or to a PDA).

The Embedded FINREAD specifications focus on integrated and distributed architectures and provides the requirements that shall be considered for including the functionality of an Embedded FINREAD IC card reader into the mentioned architectures.

For independent architectures consisting of a user equipment (PC, PDA, …) linked to an independent dedicated IC card reader used in a private environment, interested parties shall refer to CWA 14174 Financial transactional IC card reader (FINREAD) specifications.

Embedded FINREAD Hosting device Card Reader environment

other EFD keypad storage ICC slot peripheral

other EFD display communication peripheral

Figure 2 — Generic Integrated EFD architecture

Figure 2 shows the generic integrated architecture where the EFCR is a subset of the hosting device formed by the keypad, the display, the processing unit with its storage device, the ICC slot and communication resources (serial ports, networking, others…).

All EFD hardware configurations shall provide the level of functionality and security which is defined by this CWA for the generic integrated architecture. A distributed architecture is assimilated to an integrated architecture with

12 CWA 14722-3:2004 (E)

additional security requirements for protecting data exchange between the distributed parts. Such requirements are specified within part II of this document – Embedded FINREAD Security Specifications.

4.1.2 Embedded FINREAD system architecture

4.1.2.1 Overview

An Embedded FINREAD system consists of the combination of an ICC with different components distributed between the EFD and some remote entities such as authorisation servers, web servers, etc.

The system mainly relies on the concepts of Embedded FINREAD Card Reader Applications (EFCRA) and Embedded FINREAD Aware Applications (EFAA).

EFCRAs are secure applications running in the Java environment of the EFCR which are in charge of processing the sensitive functions of Embedded FINREAD transactions. (e.g. cardholder verification by means of PIN, amount validation, …)

EFAA are 3rd party applications which need to execute sensitive functions and which rely on EFCRA(s) for handling them. For example, in a context of payment, an EFAA could be a merchant web server relying on an EFCRA residing in the customer’s EFD for executing payment or other sensitive functions that shall not be executed by non-trusted applications. Other examples provided later in this document will show that EFAAs can also be located in the EFD.

EFCRA provisioning server

EFCR

Network / Internet EFCRA EFAA Browser or

JVM Merchant web server EFD

Payment authorisation server

Figure 3 — Simplified example of an Embedded FINREAD system architecture used in a payment context

Figure 3 shows a simplified example of an Embedded FINREAD system architecture used in a payment context. An Embedded FINREAD Card Reader Application (EFCRA) is downloaded from an EFCRA provisioning server and installed into the Java environment of the EFCR. It is activated by an Embedded FINREAD Aware Application which runs on a remote server (e.g. merchant web server). The activated EFCRA communicates with a distant payment authorisation server in order to validate the transaction.

In a different case, the EFCRA could be activated by the user of the device or by an EFAA running locally in the hosting environment of the EFD.

13 CWA 14722-3:2004 (E)

This clause presents the different Embedded FINREAD system components and defines their functions in the Embedded FINREAD system architecture.

4.1.2.2 Embedded FINREAD Aware Applications

An Embedded FINREAD Aware Application (EFAA) is a non-secure software program which runs outside of the context of the EFCR and which relies on functionality provided by one or more EFCRA(s).

Depending on the type of EFD and on application scenarios, EFAAs may either be local applications executed by the hosting device environment or distant applications running on 3rd party servers. Administration of EFAAs (download, activation, ...) relies on proprietary mechanisms which are outside of the scope of these specifications.

By definition, an EFAA is intended to activate at least one EFCRA each time it is executed. All other interactions between EFAAs and EFCRAs are application-dependent. For instance, an EFAA may communicate with an activated EFCRA and explicitly request the EFCR to terminate the trusted application, whereas another EFAA may only request the activation of an EFCRA and not interact further with the latter. A distant EFAA may be split into different modules running on different servers and carrying out specific functionality of the EFAA. For instance, one module activates the EFCRA which initiates a communication and exchanges data with another module of the EFAA.

An Embedded FINREAD application scenario does not necessarily involve an EFAA: some EFCRAs may be standalone applications which are activated by the user of the device2) and implementing the full scenario of the Embedded FINREAD transaction.

The following clauses provide specific requirements on EFAAs for each category of EFD addressed by the Embedded FINREAD specifications.

4.1.2.2.1 Mobile phones

In the previous subclauses EFAAs were presented as applications which could either be remote or local to the EFD. The JavaTM environments that are likely to be implemented in mobile phone are J2ME/CLDC and MIDP 2.0 or STIP 2.1. The activation of an EFCRA by a local EFAA could not be realistic in MIDP 2.0 that enables applications to activate each other only if they belong to the same suite, and consequently only if they were packaged and signed by the same entities. STIP 2.1 security policies allow one application to activate another.

This subclause considers EFAAs to be distant applications remotely interfacing the EFCR for mobile phones3.

2) In this specific case, the user is conceptually acting as an EFAA as he selects and activates an EFCRA through the Application Management Software of the EFCR.

3 Subclause dedicated to the set-top boxes (4.1.2.2.2) shows examples of local EFAAs activating EFCRAs. The same logic may be applied to a mobile under STIP using local EFAAs.

14 CWA 14722-3:2004 (E)

Activation of an EFCRAs by a distant EFAA

An EFAA relies on the functionality of well identified EFCRA(s) and is aware of their availability in the EFD4).

An EFCRA shall be installed in the EFCR before it can be activated.

The EFAA shall activate an EFCRA by transmitting a push command5) to the Application Management Software (AMS) of the EFCR.

The push command transmitted to the AMS shall fully identify the EFCRA which is to be activated.

Depending on the application scenario, the command may also include parameters which shall be transmitted to the EFCRA when it is initialised (e.g. transaction amount, communication parameters, …). Figure 4 illustrates the activation of an EFCRA by a remote EFAA transmitting a push command to the EFCR’s AMS.

EFAA Web server provided by any party

(1) browsing, selection of a transaction

EFCR

EFCRA resident browser (2) PUSH (3) [EFCRA activation EFCRA selection request, parameters] & activation (parameters)

Java Platform (JVM, AMS, APIs)

Hardware + OS

Hosting device

Figure 4 — Activation of an EFCRA by a push command

The action performed by the AMS when receiving a push command requesting the activation of an EFCRA which is not installed in the EFCR is vendor-dependent.

Communication between a distant EFAA and an EFCRA

4) It is up to the application provider to provide the user with the necessary information (e.g. during browsing) to identify and download the EFCRA needed to complete the transaction. 5) Although no industry standard currently defines means of interactions between a distant entity and the AMS of a Java platform, the use of push commands, as specified by MIDP 2.0 seems to be a practical solution experienced by the major actors of the mobile industry.

15 CWA 14722-3:2004 (E)

Depending on the application’s scenario, an EFAA and an EFCRA may need to exchange information. In such case the communication shall be initiated by the EFCRA via the communication interface provided by the Java environment of the EFCR. Required communication parameters may either be statically stored in the EFCRA code, or be provided to the latter by the EFAA as parameters of the “activation push command” sent to the EFCR.

Termination of an EFCRA by a distant EFAA

Depending on the application’s scenario, a distant EFAA may explicitly request the termination of the EFCRA. EFCRAs may also terminate by themselves or be terminated by the user of the device.

4.1.2.2.2 DVB-MHP compliant set-top boxes

If the EFD is a DVB-MHP set-top box, an EFAA is a local application6) running in the hosting device environment of the EFD, and shall either be :

 a resident application (native or Java) part of the DVB-MHP platform and signed by the device vendor ;

 a MHP Xlet embedded in a DVB-HTML page and signed by any party ;

 an ECMAScript embedded in a DVB-HTML page and signed by any party.

Interactions between a resident EFAA and EFCRAs

When an EFAA is a resident application, its interactions with EFCRAs (activation, communication, termination) are device vendor-dependent, and are then not covered by these specifications.

Activation and termination of an EFCRA by a MHP Xlet or an ECMAScript embedded in a DVB-HTML page

EFAAs which are either Xlets or ECMAScripts embedded in a DVB-HTML page are downloaded, activated and terminated by a resident browser.

In order to interact (activate, communicate, terminate) with an EFCRA, the EFAA shall be signalled in the same MHP service as the latter.

Activation of an EFCRA shall be achieved using the MHP “Application discovery and launching APIs” as defined by the DVB-MHP specification.

The same APIs shall be exploited if the EFAA needs to obtain information on the EFCRAs available in its MHP service or if it needs to explicitly terminate an application.

Communication between MHP Xlet or an ECMAScript embedded in a DVB-HTML page and an EFCRA

If the EFAA and the EFCRA need to exchange information, the communication between these entities shall be achieved using the MHP “Inter-Application and Inter-Xlet communication API” as defined by the DVB-MHP specification.

Figure 5 illustrates the case when the EFAA is an Xlet embedded in a DVB-HTML page. The EFAA (Xlet) is downloaded into the browser runtime environment and activates an EFCRA (Xlet) through DVB-MHP “Application Discovery and Launching” API. A communication is then established between the 2 applications through the “Inter- Application” API.

6) Application architecture where the EFAA is a distant application running on the broadcaster server could be conceivable. According to the usual working procedures of the industry, such configuration does not seem to be realistic.

16 CWA 14722-3:2004 (E)

Web server EFAA (Xlet)

(1) browsing, selection of a transaction

(2) download EFAA (Xlet) into browser runtime EFCR environment Browser (5) communication EFCRA downloaded (“Inter-Application API”) (Xlet) EFAA (Xlet)

(3) EFAA (Xlet) running: (4) EFCRA (Xlet) activation selection/activation of an EFCRA (Xlet) (“Application Discovery and Launching” API) DVB-J Platform (JVM, AMS, APIs)

Hardware + OS

Hosting Device

Figure 5 — Activation of an EFCRA by a resident DVB-MHP Xlet embedded in a DVB-HTML page

4.1.2.2.3 PDAs

As was described within part 2 of this CWA – Embedded FINREAD Functional Architecture and Technical Requirements, only two types of PDA-based EFD architectures are considered by these specifications :

 an independent architecture presenting the PDA as the private device of a FINREAD environment which relies on an independent FINREAD Card Reader, as defined within CEN/CWA 14174 (FINREAD Specifications) ;

 an integrated architecture similar to the one described by this document for the other types of EFDs, (i.e. a device implementing secure core software which complies with the Embedded FINREAD security requirements and which supports a Java platform such as MIDP 2.0).

Concerned parties shall then retrieve the appropriate functional requirements from one of these two sets of documents.

4.1.2.3 Embedded FINREAD Card Reader Applications

An Embedded FINREAD Card Reader Application is a piece of software which is executed in the trusted environment of the EFCR and which is in charge of executing functions that require protection. In particular, the EFCRA is used to secure a key-entry or to display reliable information.

To support several different ICC applications and upgrade applications to new standards, it is possible to store and remove the corresponding EFCRAs into / from the EFCR environment. To guarantee the secure use of any EFCR,

17 CWA 14722-3:2004 (E)

the download of new EFCRAs is restricted to applications whose origin and integrity are verified. Requirements on EFCRA provisioning are provided in subclauses 4.4.2 and 4.81 of this document.

The system resources being shared between the hosting device environment and the EFCR, an EFCRA shall be able to request exclusive access to the following EFD peripherals or services for the time lapse it is active :

 the keypad ;

 the display, or a subset of the display (area, window, …) ;

 the ICC reader interfacing with the user ICC applications ;

 a persistent storage dedicated to the application (files, directories, …) ;

 one or more of the system communication resources (serial ports, http connection, socket connection, etc.).

Activation of an EFCRA

As it was previously mentioned, an EFCRA can either be activated by the EFD user (Figure 6) or by an EFAA (accordingly to the requirements provided in subclause 4.1.2.2).

User EFCR

Vendor application EFCRA management tools

EFCRA selection EFCRA activation activation/management

Standard Java Platform (JVM, AMS, API)

Hardware + OS

Hosting device

Figure 6 — Activation of a standalone EFCRA by the user

18 CWA 14722-3:2004 (E)

Termination of an EFCRA

Termination of EFCRAs is application-dependent. For example, an EFCRA may either terminate by itself, be terminated by the user, the system or by the EFAA.

Communication with 3rd party entities

An EFCRA shall be able to initiate communications with remote entities such as a distant EFAA or authorisation servers using the communication resources of the EFCR. (Figure 7). Data exchanges and protocols used for communication are application-dependent. EFCRs shall at least provide EFCRAs with access to a HTTP interface.

3rd party Web server EFAA (authorisation server, EFAA module, ...) application-dependent exchanges application-dependent exchanges

EFCR browser

Active EFCRA

Standard Java Platform (JVM, AMS, API) COMM

Hardware + OS

Hosting device

Figure 7 — Communication with remote entities initiated by the EFCRA

Interoperability of EFCRAs

A main objective of Embedded FINREAD is ensuring interoperability of EFCRAs through the use of Java runtime environments. “Interoperability” is understood as the ability to run Embedded FINREAD card reader applications on different devices potentially having different capabilities and different architectures but supporting the same Java technology and having capabilities that meet the minimum required by the application

19 CWA 14722-3:2004 (E)

This specification references 3 standard Java environments7) which are today foreseen to be the solutions that are or will be adopted by the concerned industries; other Java technologies complying with this CWA requirements may also be considered to implement this specification.

 J2ME/CLDC and MIDP v2.0(JSR 118) : this environment supports Java applications running on resource- constrained devices and may address mobile phones or PDA EFDs. Information related to this technology can be found on the internet web site of the Java Community Process, at http://www.jcp.org/ ;

 STIP Technology v2.1 : this environment supports Java applications running on resource-constrained devices and may address PC, PDA, set top boxes or mobile phones EFDs. Information related to this technology can be found on the internet web site of the STIP Consortium, at http://www.stip.org/ ;

 DVB-J : this environment supports a Java based software platform comprising a Virtual Machine and a set of TV-specific APIs. An EFD based on a set-top box shall be compliant with the DVB-MHP v1.1 specifications which include the definition of the DVB-J platform. Related information can be found on the DVB-MHP web site, at http://www.mhp.org/.

Embedded FINREAD requires EFCRAs to be fully interoperable between EFCRs implementing the same Java environment. For example, if an EFCRA is developed for J2ME/CLDC and MIDP 2.0, it shall run appropriately on all EFCRs implementing this platform. The following paragraphs define the structure of EFCRAs within each referenced environment :

MIDP 2.0 :

If the Java environment of the EFCR consists of a J2ME/ CLDC and MIDP v2.0 platform, each EFCRA shall be implemented as a MIDlet encapsulated within a MIDlet suite, as defined by the MIDP v2.0 specifications. A MIDlet suite certified by Embedded FINREAD shall contain at least one EFCRA and its related resources.

STIP v2.1 :

If the Java environment of the EFCR consists of a STIP v2.1 platform, each EFCRA shall be implemented as a Stiplet as defined by the STIP v2.1 specifications.

MHP-DVB v1.1/DVB-J :

If the Java environment of the EFCR consists of a DVB-J platform, each EFCRA shall be an independent Xlet as defined by the DVB-MHP v1.1 specifications.

4.1.2.4 EFCR hardware and software components

The EFCR is a trusted Java-based environment of an EFD in which EFCRAs are executed and interface the resources of the device (Figure 8)

7) Some functionality are currently missing within the referenced Java environments to support the Embedded FINREAD requirements. Technical responses to this issue are provided by part 4 of this CWA – Embedded FINREAD Technical Architecture and APIs.

20 CWA 14722-3:2004 (E)

Hosting device EFCR environment

EFCRA

Standard Java platform (JVM, AMS, APIs)

Hardware + OS

keypad storage ICC slot

communication display interface

Figure 8 — EFCR architecture overview

To comply with Embedded FINREAD specifications, an EFCR shall integrate the following components :

Hardware :

 a display that can show application data that needs to be validated by the user ;

 a keypad which can be used by the cardholder to enter/validate information ;

 one ID1 or ID000 ICC interface dedicated to the user ICC, or no additional ICC interface if the user ICC applications are hosted by the subscriber module ;

 a networking peripheral which enables at least HTTP communications ;

 a permanent storage area which can be used by EFCRAs to store data and by the EFCR’s AMS to store application certificates.

Software :

The EFCR shall implement a Java platform in order to guarantee the interoperability of EFCRAs between EFCRs implementing the same environment. This Java platform shall either be one of the solutions referenced in subclause 4.1.2.3 or another standard Java technology which complies with the functional and security requirements defined by these specifications.

The Java environment of an EFCR shall include the following software components :

 application management software (AMS), also called Java Application Manager (JAM), including the following functions :

21 CWA 14722-3:2004 (E)

 download/installation/removal of EFCRAs compliant with the security requirements provided in part II of this document – Embedded FINREAD Security Specifications ;

 selection and activation of an EFCRA by the user ;

 selection and activation of an EFCRA by a remote EFAA through a push interface as specified in subclause 4.1.2.2 (mandatory for mobile phone EFDs only) ;

 selection and activation of an EFCRA by a local EFAA (when local EFAAs are supported by the device).

 a well defined API which permits to obtain exclusive accesses to the following interfaces or services :

 management of display and keypad ;

 permanent storage space administration ;

 communication with the user ICC:

 detection of card insertion and removal, control of the ICC power supply and transmission of APDU if the device addresses the user card through an ID1 ICC reader ;

 controlling the ICC power supply and sending APDU if the mobile phone is equipped with a second ID000 slot ;

 sending SIMToolkit envelops if the EFD is a mobile phone and the user ICC applications are hosted by the subscriber module.

 HTTP communications with remote servers ;

 cryptographic functions as stated in part II of this document – Embedded FINREAD Security Specifications.

The EFCR hardware design and development is provided by the EFD vendor. It shall comply with these specifications.

4.1.2.5 Hosting device hardware and software components

The hosting device environment consists of a combination of industry specific components and of a defined set of hardware and software resources shared with the EFCR, as defined in 4.1.2.4 and illustrated by Figure 9.

22 CWA 14722-3:2004 (E)

Hosting device environment EFCR

vendor native native tools app. app. Java app. vendor specific software libraries & drivers Standard Java platform (JVM, AMS, APIs)

Hardware + OS

specific keypad storage ICC slot peripheral specific peripheral specific communication display peripheral interface

Figure 9 — Logical host hardware and software components

Depending on the type of hosting device, an EFD may contain various specific non-Embedded FINREAD software components, such as native vendor applications, native 3rd party applications, non-Embedded FINREAD Java applications (games, other MIDlets/Xlets/etc.), …

4.2 Embedded FINREAD operating modes

4.2.1 General description

The operating modes define the level of security ensured by the EFD to the user’s ICC at a given moment in time. As it was previously described in this document, depending on the type of EFD used, user’s ICC applications and data may either reside in an independent ID1 ICC or in a ID000 chip (dual or mono slot configuration).

This CWA distinguishes two operating modes for an Embedded FINREAD device :

 Embedded FINREAD Secure mode ;

 Non-Embedded FINREAD mode.

The following paragraphs describe these two operating modes and specify the policies for switching from one mode to another.

23 CWA 14722-3:2004 (E)

4.2.2 Operating mode state diagram

An EFCRA has been activated and has obtained the exclusive accesses to resources it requested

Non-Embedded FINREAD Embedded FINREAD Mode Secure Mode

Termination of the EFCRA

Figure 10 — Operating mode state diagram

4.2.3 Embedded FINREAD Secure Mode

The EFD switches to Embedded FINREAD secure mode when an EFCRA is activated in the EFCR and has obtained exclusive access to the resources it requested.

When operating in Embedded FINREAD secure mode

The core software shall ensure that the user cannot be mislead by another application :

 either when the user is using an EFCRA, the core software shall notify the user he is using a signed application by means which are inimitable by non-signed applications (e.g. lighting of a dedicated LED, display of a specific icon in a system area of the screen, …)8) ;

 or the core software shall deny unsigned applications the access to the ICC reader interfacing the user ICC applications, as well as access to any communication resource enabling communication with external entities (e.g. network)9).

Each EFCRA shall clearly identify itself to the user as an Embedded FINREAD card reader application each time it is activated in the EFCR (e.g. by means of a message on the display).

8) This requirement could be implemented by EFDs implementing a Java platform such as MIDP where only one signed application package (MIDlet suite) can be executed at a time. 9) This requirement could be implemented by EFDs implementing a Java platform such as MHP where several applications signed by different certification authorities may be executed concurrently.

24 CWA 14722-3:2004 (E)

The Embedded FINREAD card reader applications shall obtain the exclusive access to all sensitive resources10) it requests. Either the Java platform provides the applications with explicit mechanisms to claim exclusivity on resources, or it shall implicitly grant the EFCRA with exclusive access to all sensitive resources.

Download of root keys outside the trusted chain of the device is not allowed in order to prevent suspicious applications signed by unknown root keys to run in the device.

If an event occurs in Embedded FINREAD secure mode with a priority that requires the system to use some of the resources held by an EFCRA (e.g. incoming call on a mobile phone), the latter may be momentarily forced to release the resources it shares with the hosting environment. The system shall notify the EFCRA that it is in the process of pre-empting its resources and shall permit the latter to process ultimate operations before it is suspended. The system may typically achieve this by calling a predefined method of the EFCRA, such as a “pause” function as defined by the different Java frameworks. During the time of suspension, the core software shall ensure that no other “non-system application” can access the resources that were acquired exclusively by the EFCRA.

The firmware shall stop providing secure mode indications to the user (if such indications were provided) and shall notify the user of the interruption.

When the EFCRA is reactivated, the system shall restore its context of execution. This may typically be achieved by calling a predefined method of the EFCRA, such as “(re)activate” through which the application recovers its resources.

The secure mode shall only be re-established when the EFCRA has been reactivated and has recovered exclusive access to its resources.

Figure 11 illustrates the policy for switching operating modes when an EFCRA is suspended.

10) The sensitive resources of an EFD are: the EFCR display, the EFCR keypad, the communication interfaces and the permanent storage.

25 CWA 14722-3:2004 (E)

Non Embedded FINREAD Mode Embedded FINREAD Secure Mode

EFCRA activation

EFCRA obtains exclusive access to resources switching operating mode

(indicating status to user) EFCRA running Interrupting event

EFCRA prepares for suspension and relinquishes resources

switching operating mode

handling event (indicating status to user)

EFCRA reactivation (recovering access to resources) switching operating mode

(indicating status to user) EFCRA running

t t

Figure 11 — Suspension of an EFCRA in Embedded FINREAD secure mode

The EFD leaves Embedded FINREAD secure mode and returns to Non-Embedded FINREAD mode when the EFCRA terminates. Secure mode indications shall end on EFCRA termination (if such indications were provided by the firmware)11).

4.2.4 Non-Embedded FINREAD mode

By definition, an EFD operates in Non-Embedded FINREAD mode when the conditions defined in Embedded FINREAD secure mode are not verified. 4.3 Peripherals

This chapter defines functional requirements for the 3 following EFD peripherals :  ICC reader ;

 display ;

 keypad.

11) Secure mode indications may remain if the system can ensure that the user is only interfacing with a (non EFCRA) signed application.

26 CWA 14722-3:2004 (E)

4.3.1 Integrated circuit card reader

The Interface Module (IFM) is the part of the EFCR that consists of ICC contacts, the hardware and software required for powering the ICC and for supporting communications with the ICC. The three main functional parts of an IFM are the mechanical, electrical and logic ICC interfaces.

Depending on its physical architecture, an EFD shall support one of the following ICC configurations :

 external ID1 slot : the Embedded FINREAD device supports an IC card reader where any ID1 IC card may be inserted (removed). These devices include often an additional slot for the subscriber module(e.g. ID000 SIM for mobile phones or ID1 conditional access card for set-top boxes) ;

 integrated dual slot : the Embedded FINREAD device supports two ID000 slots. One is dedicated to an IC card containing user applications addressed by EFCRAs, and the second is dedicated to the subscriber module ;

 mono slot : the Embedded FINREAD device supports an ID000 slot for an IC card on which the subscriber module applications and the user applications addressed by EFCRAs coexist.

4.3.1.1 Compliance with technical standards for integrated circuit cards

When an Embedded FINREAD IC Card reader is used in an integrated dual slot or an external ID1 slot configuration, the slot interfacing with the user ICC (ID1 or ID000) shall be compliant with the following technical standards :

 EMV 2000 ICC Application Specification for Payment Systems Version 4.0, December 2000

 Book 1: Application Independent ICC to Terminal Interface Requirements

The compliance to these standards is only required up to “Level 1” – a de-facto term derived from the application independent sections of the EMV specifications.

In addition to the EMV specifications, an Embedded FINREAD IC card reader should be compatible with :

 ISO/IEC 7816 : Identification cards – Integration circuit(s) cards with contact

 Part 1 : Physical characteristics

 Part 2 : Dimensions and location of the contacts

 Part 3 : Electronic signals and transmission protocols

An Embedded FINREAD IC Card Reader shall support T = 0 and T = 1 protocols. Other protocols may also be supported.

In a mono slot configuration where the subscriber module is an ID000 SIM card inserted in a mobile phone, the ICC interfaces provided by the EFCR shall comply with the 3GPP TS 31.111, GSM 11.11 and GSM 11.12 requirements.

4.3.1.2 ICC insertion/removal

External ID1 slot Embedded FINREAD devices shall detect insertion and removal of the user ICC.

4.3.1.3 Protocol management

If the IC card application is located in the SIM card as an SIM Toolkit application, access is granted according to SIM-API for Java cards ETSI TS 101 476 through a high level interface (using envelope commands). If the IC card application is located in an external ID1 card or a second chip (ID000) then standard APDUs apply.

The Embedded FINREAD device shall provide functionality to establish communication with the IC card.

27 CWA 14722-3:2004 (E)

In mono-slot configuration based on SIM Toolkit applications, communication between EFCRAs and user ICC application shall be compliant to SIM-API for Java cards ETSI TS 101 476 through a high level interface (using envelope commands).

In external ID1 slot or integrated dual slot configuration communication between EFCRAs and user ICC applications is performed through the use of APDU commands.

4.3.2 Display

An Embedded FINREAD device shall include a display resource.

The display is a resource that may be shared between EFCRAs and non-Embedded FINREAD applications.

4.3.2.1 Physical characteristics

The EFD shall support the alphanumeric ISO/IEC 8859-15 latin alphabet No. 9 character set for the display. The EFD shall make available a logical display of 4 lines of 20 characters per line. The minimum physical display size shall be 2 lines of 16 characters per line. If the physical size of the EFD display is smaller than the logical size, the core software shall provide some type of scrolling or another mechanism to make all displayed information available.

4.3.2.2 EFCR display access requirements

In Embedded FINREAD secure mode, a subset of the display (area, window, …) shall be exclusively dedicated (locked) to the activated EFCRA. Either the Java platform provides the applications with explicit mechanisms to claim exclusivity on the display, or it shall implicitly grant the EFCRA with exclusive access to this resource.

4.3.3 Keypad

An Embedded FINREAD device shall include a keypad resource.

The keypad is a resource that may be shared between EFCRAs and non-Embedded FINREAD applications.

4.3.3.1 Physical characteristics

The keypad of an EFD may consist of several technologies, such as a physical keypad, touch screen or menu system. As a minimum requirement, it shall allow for the submission of a numeric PIN, including at least “enter”, “clear” and “cancel” functionality.

4.3.3.2 EFCR keypad access requirements

In Embedded FINREAD secure mode, the EFCR keypad shall be exclusively dedicated (locked) to the activated EFCRA. Either the Java platform provides the applications with explicit mechanisms to claim exclusivity on the keypad subset, or it shall implicitly grant the EFCRA with exclusive access to this resource.

The user shall always be able to distinguish without ambiguity the application he is interacting with through the keypad from the other active applications.

4.4 Embedded FINREAD Card Reader Applications

4.4.1 Embedded FINREAD card reader applications overview

The main objective of the present CWA is to provide payment schemes, financial institutions and any other application providers with a tool for designing and describing their specific applications in a vendor independent environment for a given type of devices : private devices or personal devices.

The EFCRA is an extension of the Embedded FINREAD aware application, which resides in the EFCR and accesses the ICC application and the EFCR resources: ICC interface, display, keypad, cryptographic functions,

28 CWA 14722-3:2004 (E)

security module, etc. The EFCRA is a very sensitive part of the overall application which is under the direct control of the application provider.

Subclause 4.1.2 describes interactions between EFCRAs and the other Embedded FINREAD components.

The EFCRA is executed within the Java environment of the EFCR and interfaces the core software of the device through a standardised API. This document references 3 standard Java technologies : MIDP, STIP, DVB-MHP (see subclause 4.1.2.3).

Dialogues (commands, data exchanges, …) between EFCRAs and the other elements of the overall application (local or remote) are application-dependent and are outside of the scope of this CWA.

The Embedded FINREAD application provider is entirely responsible for developing its EFCRAs. EFCRAs development should follow several rules taking the security of all the different application providers into consideration. For example, in the context of a payment application, an EFCRA should not transmit the cardholder’s PIN in clear text to any other local or remote applications.

4.4.2 Management of FINREAD card reader applications

4.4.2.1 Development and distribution of EFCRA

The Embedded FINREAD specifications address different application providers, vendors and users across different industries.

Management and proper deployment of Embedded FINREAD applications rely on the establishment of a set of rules and conventions that shall be considered by the different actors concerned.

These rules should consider aspects such as :

 naming convention consistency ;

 programming rules (locking of resources, user interface management, handling of exceptions and errors, secure PIN handling, …) ;

 certification procedures (evaluation, signature, …) ;

 selection of appropriate certification authorities ;

 deployment (application discovery, versioning of applications, documentation, guidelines, …).

These different aspects are outside of the scope of this CWA.

4.4.2.2 Downloading of a new EFCRA

The EFCR may download one or more EFCRA(s).

Downloading of an EFCRA includes implicit replacement if a new version of an existing EFCRA is downloaded.

The download format contains signed information concerning the EFCRA such as identification, version number, etc. (for more details see Part 4 of this CWA – Embedded FINREAD Technical Architecture and APIs).

Authenticity of the downloaded EFCRA is ensured by adding a signature. The detailed security mechanisms used (algorithm, key length, key management, etc.) are defined in part II of this document – Security Specifications.

The EFCR shall verify the signature added to the EFCRAs at download time.

Processing performed by the EFCR core software during EFCRA downloading is vendor-dependent: information displayed, memory management, behaviour with insufficient memory, etc.

29 CWA 14722-3:2004 (E)

The EFCR shall ensure the unaltered status of the EFCRAs while they remain in the EFCR after being downloaded.

The EFCR shall be able to provide the user of the device with the list and version of the EFCRAs downloaded.

4.4.2.3 Activation/Termination of EFCRAs

EFCRA activation is either initiated by the user of the device or by an EFAA. The different potential activation procedures are described in subclause 4.1.2.3 of this document.

The EFCR shall switch to secure mode when an EFCRA is activated and has obtained the exclusive accesses to resources it requested

Each EFCRA shall clearly identify itself to the user as an Embedded FINREAD card reader application each time it is activated in the EFCR.

Termination of EFCRAs is application-dependent. An EFCRA may either terminate by itself, be terminated by the user, the system or by the EFAA.

When the EFCRA terminates, the EFCR core software shall ensure that no application data remains accessible to other applications.

4.4.2.4 EFCRA Removal

Management of EFCRA removal is not specified by this document and relies on vendor-dependent tools.

4.5 Embedded FINREAD card reader authentication

Part 1 of this CWA – Embedded FINREAD Business Requirements, specifies that :

“During a transaction an Embedded FINREAD device shall provide the means to verify that it is a genuine and certified device, in order to provide non-repudiation. It is the responsibility of the (payment) scheme provider whether or how they make use of this feature. This feature may be useful to provide additional guarantees, to restrict access for special types of transactions or to provide non-repudiation.

The implementation of the Embedded device authentication should take into account the framework of hosting devices.

This requirement shall be considered in line with statements on cost efficiency / low cost devices and security / tamper evidence.”

The Risk Analysis12) carried out for Embedded FINREAD identifies the authentication as a countermeasure for the following threats :

 device faking ;

 device cloning ;

 EFCR software emulator.

The resulting risks of these threats for business may be high but the probability of their occurrence is considered “medium-low”.

Implementation of card reader authentication may be costly and technically complex. It may be replaced by other means such as contractual agreements between the user and his service provider, audit, traces, ….

12) A comprehensive Risk Analysis was carried out for these specifications and is available under non-disclosure agreement.

30 CWA 14722-3:2004 (E)

In accordance with these different statements, these specifications do not mandate Embedded FINREAD card reader authentication.

4.6 Embedded FINREAD card reader application functions

This clause identifies the set of functionality which shall be provided by the EFCR firmware (Java platform) to EFCRAs for interfacing the EFCR resources. Depending on the specific architecture of the EFD, this firmware may be distinct from the hosting device firmware or (partly) shared with the latter (Figure 12).

Hosting device EFCR environment EFCRA

API

Standard Java platform

Hardware + OS

keypad storage ICC slot

communication display interface

Figure 12 — EFCR firmware interface to resources

Each function is described below. The detailed interfaces provided by the specific Java technologies referenced by these specifications (MIDP, MHP, STIP) is described in Part 4 of this CWA – Technical Architecture and APIs.

4.6.1 General functions

4.6.1.1 Embedded FINREAD card reader status

The EFCR firmware shall provide EFCRAs with functions to access general information about the EFCR/EFD status. Depending on the hosting device software environment, this information may include EFD identification, vendor, preferred language configuration, …

4.6.1.2 Functions used to access the logical display

The EFCR firmware shall provide functions to present a message on the EFCR logical display. The EFCR logical display may consist of a subset of the EFD physical display such as an area or a window.

31 CWA 14722-3:2004 (E)

The EFCR firmware shall provide functions to clear the EFCR logical display.

The EFCR firmware shall provide functions to obtain the logical display properties. These properties may include the number of lines and characters per line or the display resolution.

4.6.1.3 Functions used to access the keypad

The EFCR firmware shall provide functions for requesting key entries.

4.6.1.4 ICC interface

The EFCR firmware shall provide functions allowing management of the ICC by the activated EFCRA.

In case of external ID1 slot or internal dual slot configuration, EFCR firmware functions shall enable ICC power control (power on, power off, warm reset). These functions shall indicate the presence of the ICC. The EFCR firmware shall provide EFCRAs with functions to transmit APDUs to the ICC and to receive responses.

In case of mono slot configuration, the EFCR firmware functions shall enable transmission of SIM Toolkit envelop commands and reception of responses.

The EFCR firmware shall provide functions to select an ICC interface if there is more than one available.

4.6.1.5 Management of permanent application data

The core software shall provide functions to manage EFCRA permanent data in a permanent memory location. Permanent data management includes writing, reading, modifying and deleting. An EFCRA shall be able to manage private permanent data which are not accessible by other applications.

Private permanent data shall be removed when the EFCRA is removed.

4.6.1.6 Communication

The EFCR firmware shall provide functions that allow the activated EFCRA to establish connections and exchange data with other applications (e.g. distant EFAAs). These applications may either run on the EFD firmware or reside on a remote entity.

The EFCR firmware functions shall include client HTTP functionality.

4.6.1.7 Exclusive access to resources

As several applications may run concurrently and share the same resources, the EFCR firmware shall either provide EFCRAs with explicit mechanisms to claim exclusivity on sensitive resources, or implicitly grant the EFCRAs with exclusive access to these resources.

4.6.2 Cryptographic functions

The implementation of common algorithms in the firmware provides a standardised cryptographic interface to all EFCRAs, simplifies development and reduces downloaded application size.

The EFCR core software shall provide encryption and decryption functions using symmetric algorithms. It shall also provide functions to compute asymmetric algorithms with public keys.

The EFCR firmware shall provide functions to calculate hash algorithms.

It shall be able to generate pseudo-random numbers. The algorithm used to compute random numbers and the statistical quality of the random number generator is defined in part II of this document – Embedded FINREAD Security Specifications.

32 CWA 14722-3:2004 (E)

Algorithms to be implemented and their characteristics, key length, operating mode and standard compatibility are defined in part II of this document – Embedded FINREAD Security Specifications.

4.7 Embedded FINREAD Aware Application functions

This clause identifies the services provided by the EFD firmware to EFAAs. Implementation of these services is vendor-dependent.

Web server

EFAA

EFCR EFAA EFCRA

Java Platform (JVM, AMS, APIs)

Hardware + OS

Hosting device

Figure 13 — Firmware interface between EFAAs and the EFCR

4.7.1 Embedded FINREAD card reader properties

The EFD firmware should provide both local and distant EFAAs with functions to retrieve the EFCR properties such as the EFCR unique identification, the preferred language codes, … The complete list of properties is specified in part 4 of this CWA – Embedded FINREAD Technical Architecture and APIs.

4.7.2 Functions related to Embedded FINREAD card reader applications

The EFD/EFCR firmware shall provide functions enabling activation of an EFCRA by EFAAs (local or distant).

The EFCR firmware may provide functions allowing EFAAs (local or distant) to exchange data with the activated EFCRA.

The EFCR firmware should provide functions allowing an EFAA to terminate an EFCRA.

The user of the device shall be able to activate and terminate an EFCRA. In some cases the execution of EFCRAs relies on parameters provided by EFAAs at activation time, in such case activation of the EFCRA by the user will fail and an error message should notify the user.

33 CWA 14722-3:2004 (E)

4.8 Application provisioning and key management functions

4.8.1 Provisioning

Provisioning includes the stages of applications discovery, download, installation and removal.

Application discovery is realised through device-dependent mechanisms which are outside of the scope of this CWA.

EFCR specific functions shall enable EFCRAs download, installation and removal as specified in subclause 4.4.2 of this document.

4.8.2 Key management

The EFCR firmware functions shall support the key management needed to verify the authenticity of EFCRAs before their installation on the platform, as described in part II of this document – Embedded FINREAD Security Specifications.

It shall also support the key management needed to verify the authenticity of new firmware components as described in the part II of this document – Embedded FINREAD Security Specifications.

4.9 Vendor specific functions

This subclause identifies functions that shall be supplied by the EFCR vendor.

The method for implementing these features is vendor-dependent. No detailed API is specified by this CWA.

4.9.1 Core software downloading

The firmware of the EFCR offers a high level of functionality that requires substantial infrastructure. Therefore in order to add new functionality or modify existing functionality it is recommended to provide an upgrade capability for the factory loaded core software.

The EFCR vendor should provide tools to permit downloading of new versions of the core software.

The EFCR shall verify the authenticity of the core software after downloading. Mechanisms used to check core software authenticity are vendor-dependent.

The EFCR vendor shall ensure the unaltered status of the core software installed in the EFCR.

4.9.2 Language configuration

The EFD firmware shall permit the user to specify his preferred language and shall at least support the English language.

5 Part II – Security specifications

5.1 Assumptions

The following security assumptions were imported from the Embedded FINREAD Risk Analysis. Assumptions cover information about the intended usage of the EFCR, including such aspects as the intended environment application and possible limitations of use.

The assumptions considered for the EFCR are divided into the following categories :

 general assumptions ;

34 CWA 14722-3:2004 (E)

 assumptions about the intended usage of the EFCR ;

 assumptions about the environment in which EFCR is planned to be used.

5.1.1 General assumptions

A.SECURE_ICC

The security level of the IC Card is not within the scope of the Risk Analysis. It is assumed that the (payment) scheme or the (financial) institution have chosen the appropriate security requirements for the IC Card.

A.SECURE_SCHEME

The security level of the payment scheme or any other financial scheme is assumed to be secure in itself. The EFCR does not add security to the application itself but provides a secure interface for cardholder interaction.

A.CONFIDENTIAL_DATA

The EFCR is not expected to provide physical protection for the storage of confidential data.

5.1.2 EFCR environment assumptions

A.EXTERNAL_DATA

Confidential data in the EFCR environment (e.g. private keys for signing of applications) used for any type of download are kept in a secure environment.

A.USER_CONTROL

The EFCR is intended to be used under direct control of its possessor. The use of an EFCR for a public use is out of considered scope.

A.CERTIFIED_EFCRA

In secure mode, the EFCR is intended to be used with certified EFCR applications. A certified (signed) EFCRA is assumed to be secure at download.

A.TRUSTED_FIRMWARE

The EFCR firmware is secure at installation. EFCR firmware is assumed to be secure at first-time installation.

A.USER_EDUCATION

End-users are informed of proper use and of their responsibilities when using the EFCR.

5.1.3 Other environment

A.DEVT_POLICY

All actors managing EFCR and EFCRA issue and maintain a written procedure which describes their security rules, and apply it in the design environment.

35 CWA 14722-3:2004 (E)

A.PROD_POLICY

The manufacturer issues and maintains a written procedure which describes the security rules, and applies it in the production environment.

A.OPERATING_POLICY

The device operators along with the application providers issue and maintain a written procedure which describes the security rules, and applies it in the operating environment.

A.EXTERNAL_KEYS

All actors generating and/or managing cryptographic keys ensure their protection at all times.

5.2 Security Requirements

This clause presents the security functional requirements which were defined by the Embedded FINREAD Risk Analysis.

These requirements are split into the following categories :

 security requirements for the EFCR ;

 security requirements for its environment, some of which can be related to organisational security policies (OSP), and other need to be refined in security measures.

As indicated for each security requirement, implementation may either be specified by this document or outside of the scope of this CWA.

5.2.1 EFCR Security Functional Requirements

The following set of Security Functional requirements shall be fulfilled.

5.2.1.1 EFCR related requirements

SR_EFCR_Unique_ID

The EFCR shall provide a unique identification number for itself or for the EFD to which it is inseparably joined. Implementation : shall be compliant with industry conventions

SR_Keypad_NoLeakage

The EFCR shall not allow disclosure by audible feedback from the keypad. Implementation: vendor-dependent

5.2.1.2 Firmware related requirements

SR_Firmware_Integrity_Verification

During use stage, the EFCR shall be able to verify the integrity of firmware extensions or updates, after downloading and before installation. This requirement also applies to all native code applications. Implementation : vendor-dependent; cryptographic mechanisms and related security parameters such as key lengths shall conform to cryptographic standards suitable for high strength of function.

SR_Firmware_Authenticity_Verification

36 CWA 14722-3:2004 (E)

During use stage, the EFCR shall be able to verify the authenticity of firmware extensions or updates, after downloading and before installation. This requirement also applies to all native code applications.

Implementation : vendor-dependent; cryptographic mechanisms and related security parameters such as key lengths shall conform to current cryptographic standards suitable for high strength of function.

SR_Firmware_Integrity_Protection

The EFCR shall not allow firmware operation when code or permanent data modification of related parts of the firmware have been detected. Firmware integrity check shall be performed at least between reset and code use. This requirement also applies to all native code applications.