English version. Guidelines for the implementation of Secure Signature-Creation Devices

CEN WORKSHOP CWA 14355 March 2004 AGREEMENT ICS 03.160; 35.040; 35.100.05 Supersedes CWA 14355:2002 English version Guidelines for the implementation of Secure Signature-Creation Devices 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 2004 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No.:CWA 14355:2004 E

Contents Contents...2 Foreword...5 1 Scope...6 2 References...7 2.1 Normative references...7 2.2 Informative references...7 3 Terms and definitions, abbreviations...9 3.1 Terms and definitions...9 3.2 Abbreviations...9 3.3 Document conventions...11 4 SSCD-related provisions of the Directive...12 4.1 Relevant definitions...12 4.2 General provisions given as recitals...13 4.3 Technical aspects of provisions given in Annex III...14 4.4 SSCD-related provisions on qualified certificates and CSP...16 5 Explanatory amendments to CWA 14169...17 5.1 General implementation guidelines...17 5.1.1 SSCD overview...17 5.1.2 SSCD Types...18 5.1.2.1 SSCD Type 1...18 5.1.2.2 SSCD Type 2...19 5.1.2.3 SSCD Type 3...19 5.1.3 TOE vs. TOE IT-environment...20 5.1.3.1 SSCD Type 1 and SSCD Type 2...20 5.1.3.2 All SSCD Types...20 5.2 Guidelines on specific matters of interest...21 5.2.1 Inter-TSF trusted channel (FTP_ITC) and trusted path (FTP_TRP)...21 5.2.1.1 Reasoning for selection...21 5.2.1.2 Implementation examples...22 5.2.2 TOE Emanation (FPT_EMSEC)...22 5.2.2.1 Reasoning for selection...22 5.2.2.2 Logical attacks...23 5.2.2.3 Leakage through radiation...23 5.2.2.4 Leakage during cryptographic operations, power attacks...23 5.2.2.5 Insertion of faults, fault analysis...23 5.2.3 Security function policies and roles (FDP_ACC, FDP_ACF)...24 5.2.3.1 SSCD Type 1...24 5.2.3.2 SSCD Type 2...25 5.2.3.3 SSCD Type 3...26 5.2.4 Transition to operational state...27 5.2.5 Key destruction (FCS_CKM.4)...28 5.2.6 Authentication failure handling (FIA_AFL)...28 5.3 Requests for clarification...28 5.3.1 Status of the SSCD PPs...28 5.3.2 Key generation at the CSP...29 5.3.3 Usage for CSP signing...29 5.3.4 Key recovery, key escrow, shared secrets for SSCDs...29 5.3.5 Signature service provision...30 5.3.6 SVD export/import for Type 2...30 5.3.7 Cryptographic attacks...30 5.3.8 Authentication and identification...30 5.3.9 Reasonably assured...30 page 2

5.3.10 Management of security function behaviour (FMT_MOF.1)...30 5.3.11 Emanation Security (FPT_EMSEC) vs. Unobservability (FPR_UNO)...31 6 Relation of SSCD PP to other standards...32 6.1 Overview of related protection profiles...32 6.1.1 SSCD PP...32 6.1.2 Eurosmart PP9911 (software and hardware) relying on PP9806 (hardware)...32 6.1.3 Eurosmart PP0002 "Smart Card IC Platform Protection Profile"...33 6.1.4 Eurosmart PP0010 "Smart Card IC with Multi-Application Secure Platform"...33 6.1.5 The NIST SC-user group PP-document (Version 3.0)...33 6.2 Evaluation aspects of SSCD as HW-SW combination...34 6.2.1 Requirements for hardware components...34 6.2.2 Division of SSCD into different components...35 6.2.2.1 Hardware platform...35 6.2.2.2 Operating system...35 6.2.2.3 SSCD application...36 6.2.3 Evaluation of the SSCD as composite device...36 6.2.3.1 Case 1 Evaluation of the SSCD as an integral product...37 6.2.3.2 Case 2 - Evaluation of the SSCD using hardware evaluation results...37 6.2.3.3 Case 3 - Evaluation of the SSCD using results of hardware and operating system evaluation...38 7 General Platform Implementation Guidelines...39 7.1 SSCD and the Qualified Certificate...39 7.1.1 SSCD-indicator in the certificate...39 7.1.2 Trusted channel to the CGA...40 7.1.3 Certificate distribution...40 7.2 Implementation of SCA and SSCD...40 7.2.1 Class 1 SCS SCA and SSCD share a computing engine...41 7.2.2 Class 2 SCS SCA and SSCD on separate computing engines...41 7.3 Display limitations...41 7.3.1 Display message (DM) device...41 7.3.2 Display hash (DH) device...42 7.4 Use cases...42 7.4.1 Class 1DM System...42 7.4.2 Class 2DM System...42 7.4.3 Class 1DH System...42 7.4.4 Class 2DH System...43 8 Implementation guidelines for smartcards...44 8.1 SSCD platform functions...44 8.1.1 Personalisation...44 8.1.2 User authentication...44 8.1.3 Trusted channels and trusted path...44 8.2 SSCD environment...45 9 Implementation guidelines for mobile phones...46 9.1 Usage considerations...46 9.1.1 Displaying the complete message on the phone...46 9.1.2 Displaying only a hash value on the phone...46 9.2 SSCD platform functions...47 9.2.1 Personalisation...47 9.2.2 User authentication...47 9.2.3 Trusted channels and trusted path...47 9.3 SSCD environment...48 10 Implementation guidelines for PDA...49 10.1 Computing engine choices...49 10.1.1 Single Computing engine...49 10.1.2 Separate Computing engines...49 10.2 Display considerations...49 10.2.1 Display Message device...49 10.2.2 Display Hash device...49 10.3 User intentions...50 3

10.4 SSCD platform functions...50 10.4.1 Personalisation...50 10.4.2 User Authentication...50 10.4.3 Trusted Paths and Channels...50 11 Implementation guidelines for PCs...52 11.1 Computing engine choices...52 11.1.1 Single Computing engine...52 11.1.2 Separate Computing engines...52 11.2 Display considerations...52 11.2.1 Display Message device...52 11.2.2 Display Hash device...52 11.3 User intentions...53 11.4 SSCD platform functions...53 11.4.1 Personalisation...53 11.4.2 User Authentication...53 11.4.3 Trusted Paths and Channels...53 12 Signing Services...55 Annex I (informative) Comparison of Protection Profiles...56 AI.1 Security Objectives comparison...56 AI.1.1 SSCD vs. Eurosmart PP0010...57 AI.1.1.1 Scope of TOE...57 AI.1.1.2 Comparison of security objectives...57 AI.1.2 SSCD vs. Eurosmart PP0002...58 AI.1.2.1 Scope of TOE...58 AI.1.2.2 Comparison of security objectives...59 AI.1.3 SSCD vs. SCSUG...59 AI.1.3.1 Scope of TOE...59 AI.1.3.2 Comparison of security objectives...59 AI.2 Functional Security Requirements comparison...61 AI.2.1 FAU Security audit...61 AI.2.2 FCS Cryptographic support...62 AI.2.3 FDP User data protection...63 AI.2.4 FIA Identification and authentication...64 AI.2.5 FMT Security management...65 AI.2.6 FPR Privacy...66 AI.2.7 FPT Protection of the TSF...67 AI.2.8 FRU Resource utilisation...68 AI.2.9 FTP Trusted path/channels...68 4

Foreword Successful implementation of European Directive 1999/93/EC on a Community framework for electronic signatures [Dir.1999/93/EC] requires standards for services, processes, systems and products related to electronic signatures as well as guidance for conformity assessment of such services, processes, systems and products. In 1999 the European ICT Standards Board, with the support of the European Commission, undertook an initiative bringing together industry and public authorities, experts and other market players, to create the European Electronic Signature Standardisation Initiative (EESSI). Within this framework the Comité Européen de Normalisation / Information Society Standardisation System (CEN/ISSS) and the European Telecommunications Standards Institute / Electronic Signatures and Infrastructures (ETSI/ESI) were entrusted with the execution of a work programme to develop generally recognized standards to support the implementation of [Dir.1999/93/EC] and development of a European electronic signature infrastructure. The CEN/ISSS Workshop on electronic signatures (WS/E-SIGN) resulted in a set of deliverables, CEN Workshop Agreements (CWA), which contributed to those generally recognized standards. The present document is one such CWA. CWA 14169 has defined a Common Criteria Protection Profile (PP) for secure signature creation devices (SSCDs), referred to as [SSCD PP] in the remainder of this document. The SSCD PP was based on the working assumption of a general technology-neutral approach that has solely been based on the requirements that are defined by the Directive. Whilst this allows for swift and harmonised realization of the Directive in an implementation-independent manner, a side effect is that the general SSCD PP neither could emphasize strengths of any certain technology promising to be capable to deploy electronic signatures, nor could the value added of employing CC evaluated SSCDs in e commerce areas (referred to as 5.2 signatures ) be sufficiently addressed. The purpose of CWA 14355 is therefore to extend the previous work towards defining guidelines on implementing SSCDs in specific platforms (such as smart cards, PCs, PDAs and mobile phones) and in specific environments (such as public terminals or secured environments). This CWA is intended for use by both legal and technical experts in the area of electronic signatures, as well as designers of systems and products in this area. This version of this CWA was published 2004-03. A list of the individuals and organizations which supported the technical consensus represented by this CEN Workshop Agreement is available to purchasers from the CEN Central Secretariat. 5

1 Scope Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures [Dir.1999/93/EC] referred to as the Directive in the remainder of this document specifies requirements for secure signature-creation devices (SSCDs) in its Annex III. CWA 14169 clarifies these SSCD security requirements as Protection Profiles that follow the provisions of the Common Criteria (CC) [SSCD PP]. A technology neutral approach has been followed by these PPs. The present document gives guidance on the implementation of [SSCD PP] for specific platforms (e.g. smart cards, personal data assistants, mobile phones, or PCs) and the operation in specific environments (e.g. public terminals or secured environments). The document is intended both for vendors preparing to write a Security Target (ST) conforming to the SSCD PP as well as for users with a need to understand the capabilities of different technical solutions for fulfilling the SSCD PP. A further objective of the document is to compare [SSCD PP] to similar PPs or other well established evaluation standards. This shall assist implementers and ST writers in identifying roads of how to develop products that meet other standards in addition to the SSCD PPs and thus shall assist in avoiding duplicate evaluation processes. The document limits its scope to electronic signatures based on asymmetric cryptography, i.e. to digital signatures based on private key public key pairs. 6

2 References 2.1 Normative references This CEN Workshop Agreement incorporates by dated or undated reference, provisions from other publications. These normative references are cited at the appropriate places in the text, and the publications are listed hereafter. For dated references, subsequent amendments to or revisions of any of these publications apply to this CEN Workshop Agreement only when incorporated in it by amendment or revision. For undated references the latest edition of the publication referred to applies (including amendments). [ALGO] [CWA 14170] ETSI SR 002 176 - Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures V1.1.1 (2003-03). CWA 14170: Security Requirements for Signature Creation Applications. [CWA 14167-3] CWA 14167-3: Cryptographic Module for CSP Key Generation Services - Protection Profile (CMCKG-PP), [Dir.1999/93/EC] Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a community framework for electronic signatures [ISO 15408] ISO/IEC 15408-1 to 15408-3, 1999: Information technology - Security techniques - Evaluation criteria for IT security Part 1: Introduction and general model, Part 2: Security functional requirements, Part 3: Security assurance requirements. [SSCD PP] CWA 14169: Security Requirements of Secure Signature Creation Devices(SSCD) 2.2 Informative references [CMCSO PP] [DFA] [DPA] [FA] [ISO 7816] PP 9806] [PP 9911] [PP 0002] [PP 0010] CWA 14167-2: Cryptographic Module for CSP Signing Operations Protection Profile, CMCSO-PP E. Biham, A. Shamir, Differential Fault Analysis of Secret Key Cryptosystems, Advances in Cryptology Proceedings of CRYPTO 97. P. Kocher, J. Jae and B. Jun, Differential Power Analysis, Advances in Cryptology, Proceedings of CRYPTO 99, 1999, pp. 388-397 D. Boneh, R.A. Demillo, R.J. Lipton, On the importance of Checking Cryptographic Protocols for Faults, Advances in Cryptology, Proceedings of EUROCRYPT 97. ISO/IEC 7816: Identification cards Integrated circuit cards with contacts. French Certification Body PP/9806: Protection Profile Smart Card Integrated Circuit, Version 2.0, Eurosmart, September 1998. French Certification Body PP/9911: Protection Profile Smart Card Integrated Circuit with Embedded Software, Version 2.0, Eurosmart, June 1999. Bundesamt für Sicherheit in der Informationstechnik BSI-PP-0002: Smartcard IC Platform Protection Profile, Version 1.0, Eurosmart, July 2001. French Certification Body PP/0010: Protection Profile Smart Card IC with Multi- Application Secure Platform, Version 2.0, Eurosmart, November 2000. [SCSUG] Smart Card Security User Group: Smart Card Protection Profile, version 3.0, September 2001. [TA] P. Kocher, Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems, Advances in Cryptology, Proceedings of CRYPTO 96, pp. 104-113. 7

[TAMPER] [TCPA] [TPMPP] [TS 101456] [WAPWIM] R.J. Anderson, M.G. Kuhn: Tamper Resistance - a Cautionary Note, Proceedings of Second USENIX Workshop on Electronic Commerce pp. 1-11, 1996. Trusted Computing Platform Alliance, Main Specification, version 1.1a, November 2001. Trusted Platform Module Protection Profile (TCPA-TPMPP), version 1.0, December 2001. ETSI SEC, Policy requirement for certification authorities issuing qualified certificates, Technical Specification ETSI TS 101456.. WAP Identity Module, WAP-260-WIM, WAP Forum, Ltd. 8

3 Terms and definitions, abbreviations 3.1 Terms and definitions Qualified signature Type 1 SSCD 'Trusted channel' 'Trusted path' means an electronic signature that fulfils the requirements laid down in the Directive [Dir.1999/93/EC] article 5(1), i.e. an advanced electronic signature which is based on a qualified certificate and which is created by a secure-signature-creation device. means an SCD/SVD generation device different from the SSCD used by the signatory. This can either be a device evaluated against [SSCD PP, Type 1], against [CWA 14167-3] or a device that fulfils the corresponding requirements of [Dir.1999/93/EC]. is a communication channel that may be initiated by either side of the channel, and provides non-repudiation characteristics with respect to the identity of the sides of the channel [ISO 15408]. provides a means for users to perform functions through an assured direct interaction with the TSF. Trusted path is usually desired for user actions such as initial identification and/or authentication, but may also be desired at other times during a user s session. Trusted path exchanges may be initiated by a user or the TSF. User responses via the trusted path are guaranteed to be protected from modification by or disclosure to untrusted applications [ISO 15408]. 3.2 Abbreviations APDU CAD CBC Application Protocol Data Unit Card Acceptor Device Cipher Block Chaining CC Common Criteria Version 2.1 CCS CEN Cryptographic Checksum Comité Européen de Normalisation (European Committee for Standardization) CEN/ISSS CEN Information Society Standardization System CGA CSP CWA DTBS DTBSR DFA DPA EAL EC EESSI EFP Certification Generation Application Certification Service Provider CEN Workshop Agreement Data to be Signed Data to be Signed Representation Differential Fault Analysis Differential Power Analysis Evaluation Assurance Level European Commission European Electronic Signature Standardization Initiative Environment Failure Protection 9

EFT ETSI Environment Failure Testing European Telecommunications Standards Institute ETSI SEC ETSI Security Technical Committee HI HW IC I/O ISSS MAC OS PC PDA PIN PP PUK RAD SCA SCD SDO SDP SFP SFR SIM SOF SPA SSCD SVD S/WIM TOE VAD WAP WIM Human Interface Hardware Integrated Circuit Input/Output Information Society Standardisation System Message Authentication Code Operating System Personal Computer Personal Digital Assistant Personal Identification Number Protection Profile PIN Unblocking Key Reference Authentication Data Signature-Creation Application Signature-Creation Data Signed Data Object Signer s Document Presentation Component Security Function Policy Security Functional Requirement Subscriber Identification Module Strength of Function Simple Power Analysis Secure Signature-Creation Device Signature-Verification Data SIM-based WIM Target of Evaluation Verification Authentication Data Wireless Access Protocol WAP Identity Module WS/E-SIGN CEN/ISSS Electronic Signatures workshop 10

3.3 Document conventions The document follows a few conventions to point out quotations taken from normative references or to highlight clauses that are referred to frequently throughout the document: Quotations taken from normative references carry a 2 pt frame, as given in the example below. Article 3 lit. 5 of 93/1999/EC The Commission may, in accordance with the procedure laid down in Article 9, establish and publish reference numbers of generally recognised standards for electronic-signature products in the Official Journal of the European Communities. Member States shall presume that there is compliance with the requirements laid down in Annex II, point (f), and Annex III when an electronic signature product meets those standards. To highlight statements that are referred to frequently in the document numbered clauses in a 10 pt bold Arial font are given, such as in the following example Clause 0. Several standards that fulfil the requirements laid down in Annex III may be published in the Official Journal of the European Communities. 11

4 SSCD-related provisions of the Directive The purpose of [SSCD PP] is to implement the provisions of the Directive [Dir.1999/93/EC] Annex III as a Common Criteria PP, i.e. in a technology neutral manner that covers the security requirements but leaves the field open for the market to implement SSCDs in a variety of technologies. As Annex III can not be viewed detached from the Directive as a whole, this section discusses the partly controversial assumptions and interpretations of the Directive on which the [SSCD PP] is based on. 4.1 Relevant definitions Article 2 of 93/1999/EC 1. electronic signature means data in electronic form which are attached to or logically associated with other electronic data and which serve as a method of authentication; 2. advanced electronic signature means an electronic signature which meets the following requirements: (a) it is uniquely linked to the signatory; (b) it is capable of identifying the signatory; (c) it is created using means that the signatory can maintain under his sole control; and (d) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable; For the purpose of this document only advanced signatures are of relevance, as the Directive refers to SSCDs and Annex III only in the context of advanced signatures. This is further discussed with respect to recital (15) of the Directive in section 4.2. Clause 1. For advanced signatures the signatory must be capable to maintain usage of the SCD under his control. This does not imply a requirement to prevent the signatory from giving up such a control such as binding the SCD to biometric characteristics of the signatory. The main provision given in the definition of advanced signatures above and repeatedly referred to in the remainder of this document is that advanced signatures are created by means which the signatory can maintain under his sole control. This essentially implies that: (a) No entity other than the signatory may acquire the means of creating such an advanced electronic signature; (b) However, it may well be in the power of the signatory to give up this sole control. Although statement (b) sounds odd considering that electronic signatures per definition serve as a method of authentication, it seems important to emphasise that here simply because no mandatory technical means to prevent the signatory from giving up his control can be derived from the Directive. Thus, mandating the inclusion of biometric characteristics may not be argued by reliance upon the definition of advanced electronic signatures. For identification by knowledge such as entering a personal identification number (PIN) the SSCD can do virtually nothing to prevent the signatory from giving the PIN to others. 12

Article 2 of 93/1999/EC 3. signatory means a person who holds a signature-creation device and acts either on his own behalf or on behalf of the natural or legal person or entity he represents; 4. signature-creation data means unique data, such as codes or private cryptographic keys, which are used by the signatory to create an electronic signature; 5. signature-creation device means configured software or hardware used to implement the signaturecreation data; Clause 2. To implement the SCD includes generation, storage, usage, and destruction of the SCD, even if at time of generation of the SCD the signatory is not known. The relationship between the signatory and the electronic signature is defined via the device that implements the signature-creation data (SCD). In the context of this document the provision of to implement is interpreted as any interaction with the SCD throughout its lifecycle, regardless of whether at a certain point in time a corresponding certificate exists or not. Consequently, this covers the creation of the SCD, its storage, its usage, and its destruction. Thus, for processes such as pre-personalisation of smartcards Annex III applies, even if the signatory is not yet known. The basic argument behind that interpretation is that otherwise both the definition of an advanced signature and the provisions of Annex III are violated: It is conceivable that the SCD has been used before without the signatory s sole control, and thus without the signatory being able to protect the SCD against that use. 4.2 General provisions given as recitals Recital (15) of 93/1999/EC Annex III covers requirements for secure signature-creation devices to ensure the functionality of advanced electronic signatures; it does not cover the entire system environment in which such devices operate; the functioning of the internal market requires the Commission and the Member States to act swiftly to enable the bodies charged with the conformity assessment of secure signature devices with Annex III to be designated; in order to meet market needs conformity assessment must be timely and efficient; The main aspect of recital (15) influencing [SSCD PP] is that the scope of Annex III and thus the scope of mandatory conformity assessment carried out by designated bodies is limited to the SSCD. As explained later on, an SSCD is basically the device allowed to touch the SCD. In the context of this document the SCD is a private cryptographic key and touching that private key may occur during creation, storage, usage, and destruction. In terms of [ISO 15408] this means that the target of evaluation (TOE) is the SSCD, i.e. again the device touching the SCD. Although an implementer may decide to include additional elements such as display elements, I/O elements, or document generation into the evaluation process to increase his customers confidence in the product, this is not a requirement that can be derived from the Directive. The boundary between the TOE and its immediate environment, i.e. the interface between them, is one of the main issues addressed by these guidelines and is further discussed throughout this document. Recital (18) of 93/1999/EC The storage and copying of signature-creation data could cause a threat to the legal validity of electronic signatures; Clause 3. SCD shall not be backed up or escrowed. For qualified signatures no duplicates of the SCD shall exist even with the consent of the signatory. If SCD is transferred, the source copy shall be reliably destroyed. 13

Two main threats are created if duplicates of SCD are allowed: Firstly, electronic signatures may be created without the consent of the identity attested to by the corresponding certificate. This jeopardizes the authentication property aimed by electronic signatures in general. Secondly, the non-repudiation property that can be derived from electronic signatures is threatened if the signatory may claim that there is a practical possibility that a copy of the SCD exists. Thus, regardless of whether such duplicates of SCD are created with or without the consent or knowledge of the signatory, the interests of both the signatory and of the relying party would be jeopardized by such duplicate SCD. Recital (18) refers to electronic signatures in general, not only SCD stored in SSCD. For SSCDs, duplicates of the SCD are explicitly excluded by the provisions given in Annex III. 4.3 Technical aspects of provisions given in Annex III Annex III of 93/1999/EC 1. Secure signature-creation devices must, by appropriate technical and procedural means, ensure at the least that: (a) the signature-creation-data used for signature generation can practically occur only once, and that their secrecy is reasonably assured; Clause 4. There must be no practicable technical means to reveal the SCD to any entity including the signatory. Clause 5. Generation of SCD shall be based on random processes that keep the probability of duplicate SCD negligibly low. Means to prove singleness of the SCD are not required. Annex III 1(a) has several impacts on the technical implementation of SSCDs: the SCD must remain secret and the SSCD must ensure that secrecy by technical means; there must be no means to circumvent the secrecy-provision required by the Directive, even with the consent of the legitimate signatory; proof of uniqueness of the SCD is not required since: o o comparison of SCDs requires knowledge of the SCD, which would violate the provision of SCD secrecy, and comparison of the SVD to other SVDs (which would indicate duplicate SCDs) would still only be possible within the domain of the SSCD provider. The technical consequence of Annex III 1(a) is that SCD generation shall be based on a random process with sufficient quality to ensure that no duplicate SCDs exist, i.e. a process carrying sufficient entropy. The decision whether a certain SCD generation process is eligible is beyond the scope of [SSCD PP] eligible key generation processes are defined in [ALGO]. The evaluation of the SSCD provides assurance that the processes are appropriately implemented. A further consequence for implementers of SSCDs that is to be derived from Annex III 1(a) is that the protection of SCD secrecy needs to be done by both technical and procedural means. As expressed before for clause 2, an SCD generation service should be considered as part of the SSCD even if the signatory is not yet known. SCD generation at a certification service provider (CSP), where SCD secrecy is solely based on procedural means, would for example violate Annex III 1(a) technical means also need to be in place within the SCD generation service in order to protect the SCD. 14

Annex III of 93/1999/EC 1. Secure signature-creation devices must, by appropriate technical and procedural means, ensure at the least that: (b) the signature-creation-data used for signature generation cannot, with reasonable assurance, be derived and the signature is protected against forgery using currently available technology; Clause 6. Strong protection to ensure SCD secrecy needs to be in place. Clause 7. Strong cryptography is required to prevent forgery of electronic signatures. Clause 8. No provisions for long-term validity in addition to Clause 7 are mandatory for SSCDs such as time-stamps or re-signing. The technical effects that may be derived from Annex III 1(b) are no means of deriving the SCD may be feasible either o o o o from the implementation of the SCD (which per definition is the SSCD), from the signature-generation process itself, from the cryptographic protocols, or by any other means protection against forgery of signatures requires an appropriate cryptographic strength In addition, forgery of signatures explicitly refers to currently available technology. The provision does not exclude that a signature may be forged using future technology. As a consequence, no additional mandatory technical or procedural requirements on SSCD regarding long term validity of electronic signatures can be derived. The assessment whether a certain signature suite is eligible to prevent forgery from a theoretical perspective is beyond the scope of [SSCD PP] this is defined in [ALGO]. It is the implementation of the suite that is covered by the PP. Annex III of 93/1999/EC 1. Secure signature-creation devices must, by appropriate technical and procedural means, ensure at the least that: (c) the signature-creation-data used for signature generation can be reliably protected by the legitimate signatory against the use of others. The definition of advanced electronic signatures includes that the means of creation of such a signature can be under sole control of the signatory. Annex III 1(c) refines that requirement in the sense that the SSCD must provide a means by which the signatory can protect the use of the SCD. Technical consequences are: For the use of the SCD the SSCD must be capable to distinguish between the signatory and others, i.e. there must be a means to identify the legitimate signatory Protected by indicates the capability that the signatory may take an active role in that protection, e.g. by actively selecting data used for identification by knowledge. For identification by knowledge, the secret such as the PIN may not be guessable. Therefore the SSCD must provide technical means that a certain quality is given to reach reliable protection. An example guideline is that defined by banking standards for teller machines. 15

Annex III of 93/1999/EC 2. Secure signature-creation devices must not alter the data to be signed or prevent such data from being presented to the signatory prior to the signature process. Clause 9. It may be upon the signatory s decision to have data-to-be-signed presented. Annex III 2 ensures that the signatory is able to be presented with the data to be signed, prior to signing it, and ensures that this data has not been altered by the SSCD. There is no derived requirement that the SSCD must ensure that presentation of DTBS actually took place. An SSCD may for example have the option that the signatory may create a series of signatures for different DTBS without presenting them, as long as the signatory can also have each DTBS presented. On the other hand, if a certain implementation presents each DTBS to the signatory without the signatory being able to suppress the presentation, this is also a valid approach with respect to Annex III 2. 4.4 SSCD-related provisions on qualified certificates and CSP Qualified certificates must contain Annex I of 93/1999/EC (e) signature-verification data which correspond to signature-creation data under the control of the signatory; Clause 10. The SSCD shall be capable of assisting in proving correspondence between the SVD and the SCD. The SVD stored in the certificate must correspond to the SCD the signatory uses for signing. Therefore, the SSCD needs to assist the certification generation application (CGA) in proving this correspondence. It is important to consider that such a proof of possession usually requires use of the SCD and may not interfere with other provisions of the Directive. For example, an approach to sign random challenges carries some threats and must be avoided, as the signatory has virtually no chance to distinguish between a nonce supposed to be such a random challenge and the hash value of a document the signatory actually does not intend to sign. The proof of correspondence between the SCD and SVD therefore needs to be viewed separately from the usage of the SCD for signing. For example, RFC 2511 requires that for proof-ofpossession, the SVD shall be only be used to sign the SVD, or a password-based MAC of the SVD. This prevents the risk of a rogue none. Annex II of 93/1999/EC Certification-service-providers must: (g) take measures against forgery of certificates, and, in cases where the certification-serviceprovider generates signature-creation data, guarantee confidentiality during the process of generating such data; (j) not store or copy signature-creation data of the person to whom the certification-serviceprovider provided key management services; The provisions given above, although not directly related to Annex III, are supporting clause 4 that the SCD must remain secret. The proof of correspondence between SCD and SVD is provided by using the SSCD as discussed for clause 10 above. 16

5 Explanatory amendments to CWA 14169 In this section the [SSCD PP] is explained. First, general implementation guidelines explaining the [SSCD PP] are given in section 5.1. A detailed discussion of major issues to be covered by implementers is then given in section 5.2. 5.1 General implementation guidelines In this section, an overview of the [SSCD PP] is given in the technology neutral manner of [SSCD PP] itself. This is done for two reasons: This shall keep the document self-contained, although due to its strong relation it can not be viewed separate from [SSCD PP] The overview shall give an extension to the descriptive parts of [SSCD PP] and thus assist implementers in getting an initial insight into how the SSCD-requirements have been translated to Common Criteria [ISO 15408] by the developers of [SSCD PP]. Therefore, the section is structured as follows: In section 5.1.1 a high-level view of the signature creation process is given. This gives an overview of the components and interfaces involved. The different types of SSCDs are discussed in section 5.1.2. Section 5.1.3 continues by discussing the borderlines that have been drawn with respect to the separation between the TOE and its environment. 5.1.1 SSCD overview From a simplified perspective, the signature-creation process employing the SSCD can be described as follows: Generation of the SCD-SVD pair (the keys) and the corresponding certificate is carried out during an initialisation phase. This is illustrated on the right hand side of the following figure. In the usage phase, DTBS such as a document is signed by the signatory. To maintain the sole control property, authentication of the signatory needs to be in place, for example by entering a PIN. Signature generation DTBS DTBS presentation, DTBSR import Certificate generation User authentication, User identification SSCD e.g. smartcard SCD/SVD generation Even in this sketchy figure that for the moment neglects the various implementation options of SSCDs, several basic threats can be identified, such as: The SCD is a primary asset to be protected (in confidentiality) during both initialisation and usage, since an attacker obtaining control of the SCD may create any number of signatures without the consent of the signatory. Authentication data is a primary asset, since an attacker getting hold of both the SSCD and the authentication data may create signatures impersonating the legitimate signatory. 17

Data communicated during initialisation needs to be protected to prevent an attacker from obtaining a certificate identifying the signatory, but containing the attacker s SVD. Data communicated during the usage phase needs to be protected, to prevent the PIN from being disclosed to an attacker or the DTBSR being replaced by data chosen by an attacker. 5.1.2 SSCD Types During the development of [SSCD PP] a distinction was made depending on two basic alternatives in the initialisation (key generation) phase: The SCD-SVD pair may be generated in the SSCD that is used by the signatory for signing, or a dedicated SCD/SVD-pair generation device is employed which transfers the SCD to the SSCD used for signing. This resulted in three basic SSCD Types, for which general implementation aspects are discussed in the following sub-sections: SSCD Type 1: SCD/SVD-pair generation SSCD Type 2: Signature-creation SSCD Type 3: Both SCD/SVD-pair generation and signature-creation 5.1.2.1 SSCD Type 1 The generation of cryptographic keys is a critical factor for the quality of cryptographic products. However, for digital signatures employing asymmetric cryptography, the key generation may be resource-consuming for several reasons: Generation of keys and testing their strength is usually computationally demanding. The requirement for sufficient entropy (see Clause 5) requires good physical random generators such as good noise sources. System designers may well decide to employ dedicated SCD-SVD pair generation devices specifically designed for the demanding key generation process, thus eliminating the need to include such function blocks in the device used for signature-creation, which may be a mass produced device. With reference to Clause 2 an SCD-generation device may be considered to be an SSCD. The device, in terms of the [SSCD PP], is then an SSCD Type 1. Its main function blocks, illustrated in the figure below, are as follows: SCD/SVD Generation. SCD Export to the signature-creation device of the signatory called SSCD Type 2 in terms of [SSCD PP]. SVD Export, either directly to the CGA for certificate generation, or to the SSCD Type 2 that communicates the SVD to a CGA at a later stage. SSCD Type 1 SVD Export SCD Export SCD/SVD Generation User Authentication 18

5.1.2.2 SSCD Type 2 The counterpart of the SSCD Type 1 is the SSCD Type 2 which is the personal device used for signaturecreation by the signatory. It is thus a personalised device, and its main functional blocks, illustrated in the figure below, are the following: Personalisation, which is the process of applying unequivocal signatory-related data, including o Reference authentication data (RAD) such as PIN and PIN Unblocking Key (PUK) o SCD which is imported from an SSCD Type 1 o SVD corresponding to the SCD, imported from an SSCD Type 1. Note, that this is optional as the SVD is not necessarily held in the SSCD. Signature creation User authentication, ensuring that the signatory can maintain sole control of the signature-creation function SSCD Type 2 Personalisation SVD Import / SVD Export User Authentication Signature-Creation User Authentication SCD Import 5.1.2.3 SSCD Type 3 If the SCD-SVD pair is generated on board the SSCD that is used for signing by the signatory, the resulting device is in terms of [SSCD PP] an SSCD Type 3. An SSCD Type 3 is a self-contained device which may be considered as a combination of an SSCD Type 1 and an SSCD Type 2. The main obvious difference is that the SCD need not be communicated outside the SSCD as shown in the figure below. The main building blocks of the SSCD Type 3 are, as follows: SCD/SVD generation SVD Export to the CGA for certificate generation, whereas the SCD remains in the SSCD Personalisation, which is the process of applying unequivocal signatory-related data such as RAD Signature-creation User authentication, ensuring that the signatory can maintain sole control of the signature-creation function SSCD Type 3 Personalisation User Authentication Signature-Creation User Authentication SVD Export SCD/SVD Generation User Authentication 19

5.1.3 TOE vs. TOE IT-environment In the light of the three different SSCD Types described above, three different PPs have been developed in [SSCD PP] one for each SSCD Type. An implementer and ST writer needs to choose the appropriate PP to claim conformance to. In this section, the limits of the TOE are discussed. [SSCD PP] derived the components that are necessary parts of the TOE from Annex III of the Directive. An implementer is free to integrate further components into the TOE, such as a document viewer, which however is beyond of the scope of this general section but is further discussed in the remainder of this document. The distinction between the TOE and its environment is dependent on the SSCD Type. Therefore, the following section discusses this distinction for SSCD Type 1 and SSCD Type 2. The subsequent section discusses the TOE limits that are common to all SSCD Types. 5.1.3.1 SSCD Type 1 and SSCD Type 2 Regarding the distinction between the TOE and its environment there is an obvious interrelation between an SSCD Type 1 and an SSCD Type 2: In case of an SSCD Type 1 TOE, the TOE exports the SCD to an SSCD Type 2, i.e. the SSCD Type 2 is an IT environment of the TOE. The same applies for the SVD in cases where the SVD is communicated from the TOE to the SSCD Type 2. On the other hand, in case of an SSCD Type 2 TOE, the SCD is imported from an SSCD Type 1. Thus the SSCD Type 1 is an IT environment of the TOE. The same applies for the SVD in cases where the SVD is communicated from the TOE to the SSCD Type 2. The scenario discussed above is illustrated in the figure below. In order to meet the requirement of SCD secrecy, a so-called trusted channel has been defined in [SSCD PP] between the SSCD Type 1 and the SSCD Type 2. The purpose of the trusted channel is to maintain the SCD confidentiality and SCD integrity when in transit. For the optional transfer of the SVD a trusted channel has been defined that shall maintain the SVD integrity. Trusted channels are further discussed in section 5.2.1. SSCD Type 2 Personalisation SVD Import / SVD Export User Authentication Signature-Creation User Authentication SCD Import Trusted channel SSCD Type 1 SVD Export Trusted channel SCD Export SCD/SVD Generation User Authentication Note that, with reference to the definition in section 3.1, the SSCD Type 1 is not necessarily a device that is evaluated against [SSCD PP], as other devices that conform to [Dir.1999/93/EC] may be employed. 5.1.3.2 All SSCD Types In addition to the interrelation between the SSCD Type 1 and the SSCD Type 2, the TOE communicates with a number of applications that constitute the IT environment of the TOE: The SVD is transferred from the SSCD to the CGA for certificate generation. Therefore, a trusted channel has been defined in [SSCD PP] in order to maintain the SVD integrity. 20

The DTBSR is transferred from the SCA to the SSCD for signature creation. Therefore, a trusted channel has been defined to maintain the DTBSR integrity. The technical means to enable the signatory to initiate the signature-creation under his sole control is provided by user authentication. Therefore, a so-called trusted path to the human interface (HI) has been defined in [SSCD PP]. During the development of [SSCD PP] devices that integrate the HI in the TOE have been anticipated and therefore, no such trusted path is needed in that case. Considering that an SSCD Type 3 may be a combination of an SSCD Type 1 and an SSCD Type 2, the distinction between the TOE the certain SSCD Type and its environment is illustrated in the figure below. Note that there is obviously no direct interface to an SCA and a HI for an SSCD Type 1. On the other hand, the interface between the SSCD Type 2 and a CGA is only required for cases where the SSCD Type 2 holds the SVD and exports it for certificate generation. SCA DTBS-representation SDO CGA ** SVD into cert. Trusted channel Trusted channel ** SSCD Type 2 Personalisation SVD Import / SVD Export HI Authentication data Trusted path* User Authentication Signature-Creation User Authentication SCD Import SCA DTBS-representation SDO Trusted channel SSCD Type 3 Personalisation HI A uthentication data Trusted path* User Authentication Signature-Creation User Authentication Trusted channel SSCD Type 1 SVD Export Trusted channel SCD Export SVD Export CGA Init. / SVD into cert. Trusted channel SCD/SVD Generation User Authentication CGA Init. / SVD into cert. Trusted channel SCD/SVD Generation User Authentication 5.2 Guidelines on specific matters of interest In this section, aspects deemed of particular interest for implementers are discussed. Such issues considered worthwhile paying special attention to have either been raised repeatedly by implementers or have been a source of intense interest during the development of the SSCD PPs. 5.2.1 Inter-TSF trusted channel (FTP_ITC) and trusted path (FTP_TRP) 5.2.1.1 Reasoning for selection AN SSCD communicates sensitive data to other IT products, such as the SCD or VAD transferred between an SSCD Type 1 and an SSCD Type 2, or with users. Therefore, trusted channels FTP_ITC and trusted paths FTP_TRP have been defined. These trusted channels/paths for the TOE are: FTP_ITC/SCD Export (SSCD Type 1) and FTP_ITC/SCD Import (SSCD Type 2): The SCD is transferred between an SSCD Type 1 and an SSCD Type 2. With reference to Annex III 1 (a), clause 4 respectively, the SSCD needs to ensure the secrecy of the SCD. FTP_ITC/SVD Export, SVD Transfer (SSCD Types 1, 2, and 3) SVD integrity shall be protected when transferred to the CGA for certification FTP_ITC/DTBS import (SSCD Type 2 and 3) The SSCD must prevent alteration of the DTBS. DTBS-representation in transit between the SCA and the SSCD needs to be protected by the trusted channel 21

FTP_TRP/TOE, SCA For authentication of the signatory a Human Interface (HI) is required, e.g. for entering a PIN. If this HI is not provided by the SSCD, the sensitive data (VAD) needs to be protected. 5.2.1.2 Implementation examples Secure messaging, as defined for smartcards in [ISO 7816] part 4 and in part 8 for extended functions, represents one option to implement a trusted channel. It allows secure transfer of application protocol data units (APDUs) between the terminal and the smartcard. Two modes represent potential candidates to be used with SSCDs: Authentic mode: A cryptographic checksum (CCS) is calculated over the APDU, e.g. a keyed message authentication code (MAC) or a MAC based on a symmetric block cipher in cipher block chaining (CBC) operational mode. This provides data integrity of the data transferred, but does not provide data confidentiality. Combined Mode: In the combined mode, an APDU that has been protected in authentic mode is padded and encrypted. This provides both data integrity and data confidentiality. The combined mode fits the requirements for transferring the SCD. For SVD transfer or DTBS-representation carrying no confidential data both the authentic mode and the combined mode may be used. Smartcards usually employ symmetric algorithms to implement secure messaging, still asymmetric algorithms are possible. However, in either case cryptographic keys are required raising the problem of protecting these keys. While protecting the keys used for secure messaging is not assumed problematic for the SSCD, as implementation of protection measures are required for the SCD anyhow, the storage of cryptographic keys in the SSCD environment is to be viewed differently, as revealing these keys is critical. Depending on the actual implementation which is discussed in detail in section 7, a desirable advantage is achieved if the SSCD authenticates the environment e.g. a secure smartcard terminal in a manner verifiable by the signatory and before sensitive data such as signatory s VAD (e.g. the PIN) are transferred. An example of authenticating the environment that has been implemented with smartcards is that a secret selected by the signatory is stored in the SSCD. Only after the terminal has been successfully authenticated this secret is revealed and displayed to the signatory. Provided that the terminal itself properly protects these authentication data to avoid attacks on the terminal that passes the secret to an attacker, the signatory has confidence in the trustworthiness of the terminal and may proceed with the signature. The examples given above for the trusted path/channel are closely related to secure messaging which is implemented in many smart cards and card acceptor devices. For off-the-shelf products such as PCs, methods similar to the authentic mode or the combined mode are conceivable. However, such devices are not yet very common for PCs. If implementing methods similar to secure messaging, the storage of the required cryptographic keys need to be considered. A development in that area that may assist in implementing the required functions is the trusted platform module [TPMPP] which has been developed within the trusted computing platform alliance [TCPA]. 5.2.2 TOE Emanation (FPT_EMSEC) 5.2.2.1 Reasoning for selection The major assets to be kept secret by the SSCD are the SCD and RAD. Limiting the protection to physical measures such as FPT_PHP has been considered insufficient due to sophisticated attacks such as power analysis or timing attacks. To counter these attacks a family FPT_EMSEC has been defined to ensure that neither the TOE emanates information relating to the SCD or RAD, nor that the interfaces can be used to get access to these assets. [SSCD PP] FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits] enabling access to RAD and SCD. 22