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

(1)

EUROPEAN COMMITTEE FOR STANDARDIZATION C O M I T É E U R O P É E N D E N O R M A L I S A T I O N E U R O P Ä I S C H E S K O M I T E E F Ü R N O R M U N G

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

WORKSHOP

AGREEMENT

March 2004

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.

(2)

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

(3)

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.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

(4)

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.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.3 SSCD vs. SCSUG ...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

(5)

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 recognizedstandards. 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.

(6)

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.

(7)

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] ETSI SR 002 176 - Electronic Signatures and Infrastructures (ESI); Algorithms and

Parameters for Secure Electronic Signatures V1.1.1 (2003-03).

[CWA 14170] CWA 14170: Security Requirements for Signature Creation Applications.

[CWA 14167-3] CWA 141673: 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 154081 to 154083, 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] CWA 14167-2: Cryptographic Module for CSP Signing Operations — Protection Profile, CMCSO-PP

[DFA] E. Biham, A. Shamir, Differential Fault Analysis of Secret Key Cryptosystems, Advances in Cryptology Proceedings of CRYPTO’97.

[DPA] P. Kocher, J. Jae and B. Jun, Differential Power Analysis, Advances in Cryptology, Proceedings of CRYPTO’99, 1999, pp. 388-397

[FA] 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 7816] ISO/IEC 7816: Identification cards – Integrated circuit cards with contacts.

PP 9806] French Certification Body PP/9806: Protection Profile Smart Card Integrated Circuit, Version 2.0, Eurosmart, September 1998.

[PP 9911] French Certification Body PP/9911: Protection Profile Smart Card Integrated Circuit with Embedded Software, Version 2.0, Eurosmart, June 1999.

[PP 0002] Bundesamt für Sicherheit in der Informationstechnik BSI-PP-0002: Smartcard IC Platform Protection Profile, Version 1.0, Eurosmart, July 2001.

[PP 0010] 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.

(8)

[TAMPER] R.J. Anderson, M.G. Kuhn: Tamper Resistance - a Cautionary Note, Proceedings of Second USENIX Workshop on Electronic Commerce pp. 1-11, 1996.

[TCPA] Trusted Computing Platform Alliance, Main Specification, version 1.1a, November 2001.

[TPMPP] Trusted Platform Module Protection Profile (TCPA-TPMPP), version 1.0, December 2001.

[TS 101456] ETSI SEC, Policy requirement for certification authorities issuing qualified certificates, Technical Specification ETSI TS 101456..

(9)

3 Terms and definitions, abbreviations

3.1 Terms and definitions

‘Qualified signature’ 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. ‘Type 1 SSCD’ 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]. 'Trusted channel' 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].

'Trusted path' 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 Application Protocol Data Unit CAD Card Acceptor Device

CBC Cipher Block Chaining CC Common Criteria Version 2.1 CCS Cryptographic Checksum

CEN Comité Européen de Normalisation (European Committee for Standardization) CEN/ISSS CEN Information Society Standardization System

CGA Certification Generation Application CSP Certification Service Provider CWA CEN Workshop Agreement DTBS Data to be Signed

DTBSR Data to be Signed Representation DFA Differential Fault Analysis

DPA Differential Power Analysis EAL Evaluation Assurance Level EC European Commission

EESSI European Electronic Signature Standardization Initiative EFP Environment Failure Protection

(10)

EFT Environment Failure Testing

ETSI European Telecommunications Standards Institute ETSI SEC ETSI Security Technical Committee

HI Human Interface HW Hardware IC Integrated Circuit I/O Input/Output

ISSS Information Society Standardisation System MAC Message Authentication Code

OS Operating System PC Personal Computer PDA Personal Digital Assistant PIN Personal Identification Number PP Protection Profile

PUK PIN Unblocking Key

RAD Reference Authentication Data SCA Signature-Creation Application SCD Signature-Creation Data SDO Signed Data Object

SDP Signer’s Document Presentation Component SFP Security Function Policy

SFR Security Functional Requirement SIM Subscriber Identification Module SOF Strength of Function

SPA Simple Power Analysis

SSCD Secure Signature-Creation Device SVD Signature-Verification Data S/WIM SIM-based WIM

TOE Target of Evaluation

VAD Verification Authentication Data WAP Wireless Access Protocol WIM WAP Identity Module

(11)

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

(12)

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.

(13)

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. ‘creation device’ means configured software or hardware used to implement the signature-creation 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.

(14)

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 comparison of SCDs requires knowledge of the SCD, which would violate the provision of SCD secrecy, and

o 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.

(15)

(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 from the implementation of the SCD (which per definition is the SSCD), o from the signature-generation process itself,

o from the cryptographic protocols, or o 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.

(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.

(16)

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

Annex I of 93/1999/EC

Qualified certificates must contain

(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-of-possession, 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-service-provider 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-service-provider 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.

(17)

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.

D T BS S S C D e.g. sm artcard S C D /SV D gene ra tio n U s e r a u th en tica tio n , U s e r id e n tific a tio n

S igna ture gen eration

D T BS presentation , D T BS R im port

C ertificate ge neration

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.

(18)

• 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.

S C D E xp ort S V D E xpo rt U ser A u th en ticatio n S C D /S V D G e ne ratio n S S C D Type 1

(19)

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 signature-creation 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 U ser A u th en ticatio n S C D Im po rt S V D Im p ort / S V D E xpo rt U ser A u th en ticatio n P e rso n alisation

S ign atu re -C rea tion S S C D Type 2

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 U ser A u th en ticatio n U ser A u th en ticatio n P e rso n alisation

S ign atu re -C rea tion S S C D Type 3

S V D E xpo rt

U ser A u th en ticatio n S C D /S V D G e ne ratio n

(20)

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.

U ser A u th en ticatio n S C D Im po rt S V D Im p ort / S V D E xpo rt U ser A u th en ticatio n P e rso n alisation

S ign atu re -C rea tion S S C D Type 2 Tr u s te d c h an ne l S C D E xp ort S V D E xpo rt U ser A u th en ticatio n S C D /S V D G e ne ratio n S S C D Type 1 Tru s te d c h an ne l

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.

(21)

• 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.

U ser A u th en tica tio n S C D Im po rt S V D Im p o rt / S V D E xpo rt U ser A u th en tica tio n P e rson alisatio n

S ign ature -C re ation S S C D Type 2 Tr u s te d c h a nne l H I

A u the n tica tio n da ta

S C D E xpo rt S V D E xpo rt U ser A u th en tica tio n S C D /S V D G e n era tio n S S C D Type 1 Tru s te d c h a nne l Tru sted cha nn el Tru sted cha nn el ** Tru sted cha nn el Tr u s te d pat h* C G A In it. / S V D in to ce rt. C G A ** S V D in to ce rt. H I Au th e n tic a tio n d a ta SC A

D T B S -re p res e n ta tio n S D O

SC A

D T B S -re p res e n ta tio n S D O C G A In it. / S V D in to ce rt. U ser A u th en tica tio n U ser A u th en tica tio n P e rson alisatio n

S ign ature -C re ation S S C D Type 3 S V D E xpo rt U ser A u th en tica tio n S C D /S V D G e n era tio n Tru sted cha nn el Tru sted cha nn el Tr u s te d pat h *

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

(22)

• 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.

(23)

FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to RAD and SCD.

In the following sections the attacks that implementers shall bear in mind are outlined. As the actual threat and the countermeasures are very dependent on the technology employed, only general considerations are given below – countermeasures are discussed in more detail in 8 to 11.

5.2.2.2 Logical attacks

FPT_EMSEC.1.2 includes logical attacks through the ‘conventional’ interfaces the SSCD provides, e.g. to exploit vulnerabilities through the communication channels used to communicate the DTBS-representation (DTBSR), the signed data object (SDO), or the VAD.

5.2.2.3 Leakage through radiation

The emissions envisaged for FPT_EMSEC.1.1 is electromagnetic radiation as direct effects of handling critical data or parts of critical data. Sources of such radiation may be caused by the ICs via antennas or on-chip busses, or may be caused by communicating the critical elements between components mounted on a printed circuit board (PCB).

Particular attention is to be given when operations on the SCD or RAD are performed, even if not directly communicated outside the component, as any radiation emitted may leak information. Examples of countermeasures are shielding, masking of busses, also referred to as blinding, or encryption of data in transit.

5.2.2.4 Leakage during cryptographic operations, power attacks

This class of attacks are based on the information an attacker collects during the phases when the

component under attack carries out the cryptographic operations. The attack is based on information leakage through secondary channels that are observed, which therefore are sometimes referred to as side-channels. An example of such a channel which in fact is a source of several vulnerabilities is the power consumption of the components. The power supply is to be considered as an interface covered by FPT_EMSEC.1.2,

potentially leaking information

Power attacks are based on the differences in the power consumption when storing a ‘0’-bit compared to a ‘1’-bit, i.e. a rising-edge transition compared to a falling-edge transition respectively.

An example of such an attack is based on directly monitoring the differences in the power consumption when carrying out operations which dependent on the keys. This is referred to as a simple power analysis (SPA). A consequence is that no direct effect of operations on the SCD shall be detectable on the interfaces.

Differential power analysis (DPA) [DPA] is a more sophisticated attack that divides a series of measurements into distinct series, each considered as a statistical distribution function. By calculating the differences of series of such distributions, the DPA significantly gains compared to the SPA from the effect that the

statistical inspection results in neutralising effects other than the one the attacker aims to observe. The attack is in particular serious as increasing the noise emitted by the device may be countered by increasing the number of probes to achieve statistical relevance of the effect aimed to be monitored. A consequence from the attack is that no indirect effects such as statistically noticeable effects shall be detectable.

A further attack may be launched based on the fact that cryptosystems may require different time for processing different inputs. Such timing attacks on public key cryptosystems have been introduced by [TA]. For this reason, no detectable difference in the timing of events shall occur. This prevents SCD-dependent (RAD-dependent) operations with different runtimes from leaking information on the SCD (RAD).

5.2.2.5 Insertion of faults, fault analysis

In a glitch attack TAMPER] the execution of an instruction is deliberately exposed to a malfunction. The aim is to replace the orderly execution of critical instructions by arbitrary ones.

Cryptographic operations that represent hard problems may become solvable, if the processing is performed on deliberately corrupted data. The crypto-analysis may be carried out by inserting faults such as by

(24)

been introduced by [FA]. An advancement of fault attacks is given by differential fault analysis (DFA) [DFA]. A general rule to avoid such attacks is that no false results shall be produced, communicated, or processed. The insertion of faults may result from changing the environmental conditions, such as the temperature, the supply voltage, or sophisticated attacks such as exposing the component to ionising radiation.

It is worth mentioning that stressing components may also emphasise effects such as those exploited for SPA or DPA. Changing operating conditions shall in particular not affect random number generators, such as for example attacks that are based on non-equally distribution of the ephemeral k of DSA.

5.2.3 Security function policies and roles (FDP_ACC, FDP_ACF)

The [SSCD PP] distinguishes between two roles:

(1) An Administrator who may carry out functions during initialisation and personalisation and (2) A Signatory who also can perform signature-creation functions.

In the following sections explanations of the security functional policies (SFP) for each SSCD Type are given.

5.2.3.1 SSCD Type 1

For the SSCD Type 1, a user’s attribute “role” has been defined as “Administrator”. The user’s security attribute “SCD/SVD management” can be “authorised” or “not authorised”.

The reasoning for having this single role is that an SSCD Type 1 is solely intended for generating the SCD-SVD pair; use of the SCD for signature-creation by the signatory is not defined.

Security attributes for SSCD Type 1 (from [SSCD PP] Type 1, FDP_ACF.1)

User, subject or object the attribute is associated with

Attribute Status

User Role Administrator

User SCD / SVD management authorised, not authorised

[SSCD PP] defines three SFPs based on the purpose of an SSCD Type 1 – SCD-SVD pair generation, as follows:

• ‘Initialisation SFP’ covers the generation of the SCD-SVD pair and is mainly employed for restricting SCD / SVD management to the Administrator (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control), to restrict modification of the attribute to Administrator (FMT_MSA.1 management of security attributes) and to define restrictive default values (FMT_MSA.3 static attribute initialisation).

• ‘SCD Export SFP’ covers the export of the SCD to an SSCD Type 2. The SCD Export SFP is mainly employed for restricting SCD export to the Administrator (FDP_ACC.1 subset access control and (FDP_ACF.1 security attribute based access control), FDP_ETC.1 (export of user data without security attributes), FDP_UCT.1 (basic data exchange confidentiality), to restrict modification of the attribute to Administrator (FMT_MSA.1 management of security attributes) and to define restrictive default values

(FMT_MSA.3 static attribute initialisation). In addition, SCD Export SFP is employed for the trusted channel to be provided (FTP_ITC.1 inter-TSF trusted channel).

• ‘SVD Export SFP’ covers the export of the SVD to the CGA (optionally to an SSCD Type 2). The SVD Export SFP is mainly employed for restricting SVD export to the Administrator (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control), FDP_ETC.1 (export of user data without security attributes), and for maintaining the integrity of the exported data (FDP_UIT.1 data exchange integrity). In addition, SVD Export SFP is employed for the trusted channel to be provided (FTP_ITC.1 inter-TSF trusted channel).

(25)

5.2.3.2 SSCD Type 2

For the SSCD Type 2 both the Administrator and the Signatory may carry out actions relating to both the initialisation phase and the signature-creation phase. Therefore, three security attribute groups have been defined: a general attribute group defining that a user’s role may be “Administrator” or “Signatory”, an initialisation attribute group for management and import of SCD/SVD, and a signature-creation attribute group. This is depicted in the following table.

(26)

Attribute Status

General attribute group

User Role Administrator, Signatory

Initialisation attribute group

SCD secure SCD import allowed no, yes

Signature-creation attribute group

SCD SCD operational no, yes

DTBS Sent by an authorised SCA no, yes

[SSCD PP] defines four SFPs for an SSCD Type 2, as follows:

• ‘SVD Transfer SFP’ covers optional import of SVD from an SSCD Type 1 and export to a CGA by either the Administrator or the Signatory as authorised users (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control) It is therefore employed for the SVD export to the CGA (FDP_ETC.1 export of user data without security attributes), for the integrity of the data communicated (FDP_UIT.1 data exchange integrity) to restrict modification of the security attribute SCD / SVD management to Administrator (FMT_MSA.1 management of security attributes) and to define the required trusted channel to the

environment (FTP_ITC.1 inter-TSF trusted channel).

• ‘SCD Import SFP’ represents the counterpart of the SCD Export of an SSCD Type 1. It is therefore employed to restrict the import of the SCD to an authorised user which may be either an Administrator or the Signatory (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control), to ensure that the SCD is imported by an authorised SSCD (FDP_ITC.1 import of user data without security attributes) with keeping the communicated data confidential (FDP_UCT.1 basic data exchange

confidentiality), to restrict modification of the attribute to Administrator (FMT_MSA.1 management of security attributes) and to define restrictive default values (e.g. SCD operational set to “no” after import in

FMT_MSA.3 static attribute initialisation), and for the required trusted channel to the SSCD Type 1 (FTP_ITC.1 inter-TSF trusted channel).

• ‘Personalisation SFP’ covers generation of the RAD by the Administrator. It is therefore employed by the corresponding access control SFRs (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control).

• Signature-creation SFP is defined for the signing of DTBS by the Signatory. The corresponding access control SFRs are FDP_ACC.1 (subset access control) and FDP_ACF.1 (security attribute based access control). The signature-creation SFP is also enforced for import of DTBSR (FDP_ITC.1 import of user data without security attributes) and to maintain DTBS integrity (FDP_UIT.1 data exchange with integrity). Modification of the security attribute is restricted to the Signatory (FMT_MSA.1 management of security attributes) and restrictive default values are defined (FMT_MSA.3 static attribute initialisation). A trusted channel to the SCA is defined for import of DTBSR (FTP_ITC.1 inter-TSF trusted channel) and a trusted path (FTP_TRP trusted path) to the HI, if the HI is not provided by the TOE itself.

5.2.3.3 SSCD Type 3

The SSCD Type 3 defines the roles Administrator and Signatory similarly to the SSCD Type 2 discussed in the previous section. The security attributes that have been defined in [SSCD PP] are listed in the following table. Again different attribute groups have been defined: a user attribute group, a general attribute group and a signature-creation attribute group.

(27)

Attribute Status

User attribute group

User Role Administrator, Signatory

General attribute group

Signature-creation attribute group

SCD SCD operational no, yes

DTBS sent by an authorised SCA no, yes

As a combination of an SSCD Type 1 and an SSCD Type 2, four SFPs have been defined for an SSCD Type 3 in [SSCD PP], as follows:

• ‘Initialisation SFP’ covers the generation of the SCD-SVD pair and is mainly enforced to restrict “SCD / SVD management” to the user which may be an Administrator or the Signatory (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control). Modification of the security attribute “SCD / SVD management” is restricted to Administrator (FMT_MSA.1 management of security attributes) and restrictive default values (FMT_MSA.3 static attribute initialisation) are defined.

• ‘Personalisation SFP’ covers generation of the RAD by the Administrator. It is therefore employed by the corresponding access control SFRs (FDP_ACC.1 subset access control and FDP_ACF.1 security attribute based access control).

• ‘SVD Transfer SFP’ covers export of SVD to a CGA by either the Administrator or the Signatory (FDP_ACC.1 subset access control, FDP_ACF.1 security attribute based access control and FDP_ETC.1 export of user data without security attributes), for the integrity of the data communicated (FDP_UIT.1 data exchange integrity) and for the required trusted channel to the CGA (FTP_ITC.1 inter-TSF trusted channel). • ‘Signature-creation SFP’ is defined for signing DTBS by the Signatory. The corresponding access control SFRs are FDP_ACC.1 (subset access control) and FDP_ACF.1 (security attribute based access control). The signature-creation SFP is also enforced for import of DTBSR (FDP_ITC.1 import of user data without security attributes) and to maintain DTBS integrity (FDP_UIT.1 data exchange with integrity). Modification of the security attribute “SCD operational” is restricted to the Signatory (FMT_MSA.1 management of security attributes) and restrictive default values (e.g. “SCD operational” set to “no” after creation) are defined (FMT_MSA.3 static attribute initialisation). A trusted channel to the SCA is defined for import of DTBSR (FTP_ITC.1 inter-TSF trusted channel) and a trusted path (FTP_TRP trusted path) to the HI, if the HI is not provided by the TOE itself.

5.2.4 Transition to operational state

For the personalised devices, i.e. the SSCD Type 2 and SSCD Type 3, an attribute “SCD operational” is defined to identify whether the SCD is operational for signature-creation or not. The purpose is to implement sole control by the signatory, as defined for advanced electronic signatures in [Dir.1999/93/EC], article 2 and Annex III. There shall be no possibility to use the SCD for signature-creation before the signatory has achieved such sole control.

Numerous organisational and technical means to implement this feature are conceivable. Two possibilities are the following:

• Initial. PIN: The SSCD may be delivered with an "Initial PIN" (I-PIN) that is unequivocally distinguishable from the VAD (PIN) used for signature-creation. This can be provided by defining the length of the I-PIN as shorter than the minimal PIN length, e.g. a five character I-PIN vs. a minimum of six characters for the PIN. When the signatory initially chooses the PIN, the I-PIN is invalidated and the SCD is set to operational. In

(28)

such an approach the signatory can detect if the SCD has been used prior delivery of the SSCD, since a valid I-PIN indicates that the SCD has not been operational.

• Import of certificates: Since qualified signatures require both an SSCD and a qualified certificate, the SSCD might provide functions that allow the signatory to import the qualified certificate. If the SSCD checks the validity of the certificate and the correspondence between the SVD in the certificate and the SCD

implemented by the SSCD, the fact that the signatory has been assigned a qualified certificate can be used to set the SCD to operational.

5.2.5 Key destruction (FCS_CKM.4)

For an SSCD Type 1 the SCD must be destructed after being exported to an SSCD Type 2.

For an SSCD Type 2 or SSCD Type 3 the SCD needs to be destructed on demand from an Administrator or the Signatory. In addition, the SCD must be destructed before an SCD is generated (SSDC Type 3) or re-imported (SSCD Type2).

In general, implementers shall ensure that the destruction is permanent in the sense that no means of recovering the SCD or part of it at a later stage is possible. This effectively means that implementers shall note that:

• It is insufficient to just disable access to the SCD, with the SCD data remaining in storage

• Degenerative effects that result from long-term storage of data need to be considered. An example are ‘hot electrons’ or enriched gate oxides that may be measurable after deletion of data

• Techniques such as E2PROM that periodically circulate data between pages result in situations where data may be deleted in the active page but the content remains in the inactive pages

Despite the issues raised above, physically destructing the SSCD is desirable from the signatory’s perspective. Depending on the technology that is employed, the implementer should provide guidance on what type of “shredder” that should be used for the specific SSCD implementation. As a vivid example, it may not be obvious to the general public that breaking the plastic of a “credit card like” smart card usually does not destroy the SSCD.

5.2.6 Authentication failure handling (FIA_AFL)

The [SSCD PP] defines for authentication failure handling (FIA_AFL.1) that after a number of unsuccessful authentication attempts the RAD shall be blocked and thus the authentication of the signatory required to create signatures shall be inhibited.

There has been some uncertainty regarding what was meant by the PP writers regarding unblocking the RAD, since FMT_MTD.1 (management of TSF data) defines that the only role who may modify the RAD is the Signatory, who in case of a blocked RAD no longer can authenticate himself.

Actually, the Personalisation SFP defines for FDP_ACC.1/ Personalisation SFP (subset access control) and FDP_ACF.1/Personalisation SFP (security attribute based access control) that an Administrator may create a new RAD. This is a common practice employed for example with banking cards.

5.3 Requests for clarification

This section gives responses to “requests for clarifications on the SSCD PPs”. Such requests were received in the course of an increasing interest in the standards. The requests have been grouped by their main statement and are discussed in a question/answer manner.

5.3.1 Status of the SSCD PPs

Question Are the currently published SSCD PPs the only “security standards” for all SSCDs?

Answer The possibility of several standards that fulfil the requirements of an SSCD is implicitly given in the Directive. The procedure defined in articles 3(5), 9, and 10 provides that the Commission