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

Transcription

1 CEN WORKSHOP CWA March 2004 AGREEMENT ICS ; ; 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

2 Contents Contents...2 Foreword Scope References Normative references Informative references Terms and definitions, abbreviations Terms and definitions Abbreviations Document conventions SSCD-related provisions of the Directive Relevant definitions General provisions given as recitals Technical aspects of provisions given in Annex III SSCD-related provisions on qualified certificates and CSP Explanatory amendments to CWA General implementation guidelines SSCD overview SSCD Types SSCD Type SSCD Type SSCD Type TOE vs. TOE IT-environment SSCD Type 1 and SSCD Type All SSCD Types Guidelines on specific matters of interest Inter-TSF trusted channel (FTP_ITC) and trusted path (FTP_TRP) Reasoning for selection Implementation examples TOE Emanation (FPT_EMSEC) Reasoning for selection Logical attacks Leakage through radiation Leakage during cryptographic operations, power attacks Insertion of faults, fault analysis Security function policies and roles (FDP_ACC, FDP_ACF) SSCD Type SSCD Type SSCD Type Transition to operational state Key destruction (FCS_CKM.4) Authentication failure handling (FIA_AFL) Requests for clarification Status of the SSCD PPs Key generation at the CSP Usage for CSP signing Key recovery, key escrow, shared secrets for SSCDs Signature service provision SVD export/import for Type Cryptographic attacks Authentication and identification Reasonably assured...30 page 2

3 Management of security function behaviour (FMT_MOF.1) Emanation Security (FPT_EMSEC) vs. Unobservability (FPR_UNO) Relation of SSCD PP to other standards Overview of related protection profiles SSCD PP Eurosmart PP9911 (software and hardware) relying on PP9806 (hardware) Eurosmart PP0002 "Smart Card IC Platform Protection Profile" Eurosmart PP0010 "Smart Card IC with Multi-Application Secure Platform" The NIST SC-user group PP-document (Version 3.0) Evaluation aspects of SSCD as HW-SW combination Requirements for hardware components Division of SSCD into different components Hardware platform Operating system SSCD application Evaluation of the SSCD as composite device Case 1 Evaluation of the SSCD as an integral product Case 2 - Evaluation of the SSCD using hardware evaluation results Case 3 - Evaluation of the SSCD using results of hardware and operating system evaluation General Platform Implementation Guidelines SSCD and the Qualified Certificate SSCD-indicator in the certificate Trusted channel to the CGA Certificate distribution Implementation of SCA and SSCD Class 1 SCS SCA and SSCD share a computing engine Class 2 SCS SCA and SSCD on separate computing engines Display limitations Display message (DM) device Display hash (DH) device Use cases Class 1DM System Class 2DM System Class 1DH System Class 2DH System Implementation guidelines for smartcards SSCD platform functions Personalisation User authentication Trusted channels and trusted path SSCD environment Implementation guidelines for mobile phones Usage considerations Displaying the complete message on the phone Displaying only a hash value on the phone SSCD platform functions Personalisation User authentication Trusted channels and trusted path SSCD environment Implementation guidelines for PDA Computing engine choices Single Computing engine Separate Computing engines Display considerations Display Message device Display Hash device User intentions

4 10.4 SSCD platform functions Personalisation User Authentication Trusted Paths and Channels Implementation guidelines for PCs Computing engine choices Single Computing engine Separate Computing engines Display considerations Display Message device Display Hash device User intentions SSCD platform functions Personalisation User Authentication Trusted Paths and Channels Signing Services...55 Annex I (informative) Comparison of Protection Profiles...56 AI.1 Security Objectives comparison...56 AI.1.1 SSCD vs. Eurosmart PP AI Scope of TOE...57 AI Comparison of security objectives...57 AI.1.2 SSCD vs. Eurosmart PP AI Scope of TOE...58 AI Comparison of security objectives...59 AI.1.3 SSCD vs. SCSUG...59 AI Scope of TOE...59 AI 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

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 recognized standards. The present document is one such CWA. CWA 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 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 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

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

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] [CWA 14170] ETSI SR Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures V1.1.1 ( ). CWA 14170: Security Requirements for Signature Creation Applications. [CWA ] CWA : 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 to , 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 : 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 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 French Certification Body PP/9911: Protection Profile Smart Card Integrated Circuit with Embedded Software, Version 2.0, Eurosmart, June Bundesamt für Sicherheit in der Informationstechnik BSI-PP-0002: Smartcard IC Platform Protection Profile, Version 1.0, Eurosmart, July French Certification Body PP/0010: Protection Profile Smart Card IC with Multi- Application Secure Platform, Version 2.0, Eurosmart, November [SCSUG] Smart Card Security User Group: Smart Card Protection Profile, version 3.0, September [TA] P. Kocher, Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems, Advances in Cryptology, Proceedings of CRYPTO 96, pp

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

9 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 ] 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

10 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

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 Official Journal of the European Communities. 11

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

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

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

15 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

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

17 5 Explanatory amendments to CWA 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 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 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 Section continues by discussing the borderlines that have been drawn with respect to the separation between the TOE and its environment 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

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

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

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

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. 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 Inter-TSF trusted channel (FTP_ITC) and trusted path (FTP_TRP) 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

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 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] TOE Emanation (FPT_EMSEC) 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

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 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 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 onchip 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 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) 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 tampering with the environment of the component. Such a fault analysis on public key cryptosystems has 23

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

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

26 Security attributes for SSCD Type 2 (from [SSCD PP] Type 2, FDP_ACF.1) User, subject or object the attribute is associated with General attribute group Attribute Status User Role Administrator, Signatory Initialisation attribute group User SCD / SVD management authorised, not authorised 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 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. 26

27 Security attributes for SSCD Type 3 (from [SSCD PP] Type 3, FDP_ACF.1) User, subject or object the attribute is associated with User attribute group Attribute Status User Role Administrator, Signatory General attribute group User SCD / SVD management authorised, not authorised 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 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 27

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 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 re-generated (SSDC Type 3) or reimported (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 E 2 PROM 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 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 Status of the SSCD PPs Question Answer Are the currently published SSCD PPs the only security standards for all SSCDs? 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 may publish (any number) of such reference numbers in the Official Journal of the European 28

29 Communities. When a product meets one such standard referenced in the Official Journal, this only means that the product is automatically presumed to meet the requirements in Annex III of the Directive. However, a product may also be directly determined to conform to Annex III (without using such a standard), by an "appropriate public or private body designated by a Member State. Such a determination of conformity must also be recognised by all other Member States. Question Is the PP a reference number, as defined in the Directive article 3(5)? Answer Yes, the CWA containing the PPs has been referenced by the European Commission in the Official Journal on July 15, Question Are any of the SSCD PPs (Type 1-3; EAL 4, EAL4+) evaluated? Answer All three SSCD PPs (Type 1, Type 2, and Type 3 have been evaluated and certified for EAL Key generation at the CSP Question Answer There is an SSCD PP for SCD generation the Type 1 device. Since key generation usually is performed by the CSP in a physically protected environment, isn t it going too far to require such devices to fulfil Annex III? This was a source of controversial discussion during development of the SSCD PPs. With reference to Clause 1 in this document, generation of SCD is by definition performed in an SSCD. However, since the SSCD PP followed a general approach that did not consider specific environments such as those provided at CSP facilities, there may of course be other standards covering key generation and subscriber device provision more specifically Usage for CSP signing Question Answer May the [SSCD PP] be employed for signing device used at the CSP for time stamping or signing qualified certificates? This has not been the primary scope during development of the [SSCD PP]. Still the scope of the CWA expresses that the document is applicable for such purposes. A PP for a cryptographic module specifically addressing the requirements of a CSP signing device has been developed in EESSI area D2 [CMCSO PP] and has been referenced by he European Commission in the Official Journal on July as defined in Annex II (f) of the Directive [Dir.1999/93/EC] Key recovery, key escrow, shared secrets for SSCDs Question Answer Can devices with SCD shared by several persons be evaluated against the SSCD PP? Such scenarios are not supported by the SSCD PPs, based on the definition of signatory given in the Directive (article 2(3): the signatory is a person that holds the signature-creation device) and the definition of advanced signature (article 2(2): an advanced signature is created using means that the signatory can maintain under his sole control). This neither provides for multiple persons, nor is sole control to be assumed, if multiple persons share the SCD. Question Answer May the CSP provide backup functions for the SCD? Backup of SCD is not supported in the SSCD PP, as discussed for clause 3 in this document. Question Answer Shared secrets may be useful for CSPs, e.g. for key backup purposes and with reference to the scope the PP is applicable for CSPs also. Whilst the scope states that the PP is applicable, the primary scope is the signatory s SSCD. Therefore the SSCD PPs have limited the scope to the definition of the signatory as a single entity. No shared secrets have been considered. 29

30 5.3.5 Signature service provision Question Answer Are SSCD PPs applicable to signature service provision, such as a service provider that maintains the SCD in a manner that it is remotely accessible, e.g. via the Internet? Such scenarios have not been considered in [SSCD PP]. However, they seem to be relevant for being considered and therefore are discussed in detail in section SVD export/import for Type 2 Question Answer In Figure 3, why are blocks for SVD import and SVD export missing? These blocks have indeed not been drawn. Still both SVD import and SVD export are provided by the SVD Transfer SFP. Note that holding the SVD or the corresponding certificate is neither mandatory for Type 2 nor for Type 3 SSCDs: For Type 3, it needs to be exported to the CGA for certification and may be deleted afterwards. For Type 2, either the corresponding Type 1 SSCD that generated the SCD may present the SVD to the CGA, or the SVD may be imported with the SCD for being presented to the CGA. In either case the SSCD needs to be capable of proofing whether an SVD presented to the SSCD corresponds to the SCD Cryptographic attacks Question Answer How are attacks based on the underlying cryptographic operations covered, such as attacks on the hash functions, or the signature protocols? In particular, as the SCA may calculate the hash values, there may be attacks on padding schemes, etc. The signature suites suitable for qualified signatures are defined in [ALGO]. Since there are suites that are resistant against padding attacks, it is possible to allow for hashing outside the SSCD Authentication and identification Question Answer Question Answer The SSCD PP discusses authentication of the signatory (TOE description or OE.HI_VAD), whilst the Directive speaks of advanced signatures as identifying the signatory. Authentication of the signatory, as used by the SSCD PP, is used to enforce Annex III, literal 1(c) which requires the SSCD to ensure that the SCD can be reliably protected by the signatory against the use of others. It seems insufficient that the CGA in OE.SVD_Auth_CGA verifies the SSCD being sender of the SVD with respect to man-in-the-middle attacks. In addition, it is also required in OE.SVD_Auth_CGA that the CGA verifies the correspondence between the SVD and the SCD in the SSCD of the signatory, respectively OE.CGA_QCert refers to the SVD matching the SCD implemented in the TOE under sole control of the signatory. Thus, a clear link to the signatory is given Reasonably assured Question Answer OT.SCD_Secrecy states reasonably assured where reasonably is unclear. This wording has been taken from the Directive Annex III 1(a). In its actual usage in OT.SCD_Secrecy, reasonably means that the objective is to provide means that sufficiently assure secrecy of the SCD as primary asset even considering an attacker with high attack potential Management of security function behaviour (FMT_MOF.1) Question Answer Mapping of FMT_MOF.1 to OT.Sigy_SigF and OT.SCD_Secrecy states is unclear. The access control functions ensure that only the legitimate signatory can use the SCD for signature creation, as given in OT.Sigy_SigF, defined in the Directive Annex III literal 1(c) ( the SSCD ensures that the SCD can be reliably protected by the legitimate signatory against the user of others ). The mapping the OT.SCD_Secrecy shall prevent that attacks against the SCD 30

31 based on the signature-creation process can be launched, such as [DFA] or glitch attacks Emanation Security (FPT_EMSEC) vs. Unobservability (FPR_UNO) Question Answer [SSCD PP] introduces a specific family FPT_EMSEC to cover threats that result from observation of interface or component emanations. This is an extension to [ISO 15408]. Why was unobservability (FPR_UNO) not sufficient to cover such threats? FPT_EMSEC has been introduced to cover threats that results from leakage during processing or communicating data. Such leakage may be observable through electromagnetic radiation of the SSCD, through data interfaces, phenomena in power consumption, etc. Related attacks are for example SPA, [DPA], [DFA], etc. and are discussed in detail in section FPR_UNO is a family that covers protection of privacy to avoid observation of usage of a service by the user. In the context of an SSCD this would be for instance the observation of the event that a signatory creates a signature, which is beyond the scope of [SSCD PP]. In contrast the attacks addressed by FPT_EMSEC are based on observation of secondary effects such as physical phenomena that reveal confidential assets during usage of the SSCD, not the fact of usage of the SSCD itself. Therefore, FPR_UNO has been considered insufficient to cover these threats. 31

32 6 Relation of SSCD PP to other standards In this section, guidance is given to implementers that aim to claim conformance also to other related protection profiles. Section 6.1 gives an overview of the various standards which is enhanced by a detailed discussion in Annex I of this document. Section 6.2 discusses evaluation of the SSCD as a combination of hardware and software, using different pro. 6.1 Overview of related protection profiles The SSCD PP has been compared with the following related protection profiles: The Eurosmart PP-documents [PP 9806] [PP 9911] [PP 0002] and [PP 0010] The NIST SC-user group PP-document [SCSUG] A complete comparison between the PP SSCD and the others should ideally contain the following comparison themes: What kind of TOE may satisfy different PPs? What are the threats taken into account? What are the SFRs taken into account and what are the main differences of concern? SSCD PP Evaluation level of CWA is EAL4 augmented by AVA_VLA.4 AVA_MSU.3 The claimed strength of function is "SOF-HIGH" Eurosmart PP9911 (software and hardware) relying on PP9806 (hardware) The evaluation level of [PP 9911] is also EAL4+ but the augmentation concerns: ADV_IMP.2 ALC_DVS.2 AVA_VLA.4 These PPs take into account the development phase and the use phase of the product. Consequently, the covered assets are: the IC specifications, design, development tools and technology, the IC dedicated software, the smart card embedded software including specifications, implementation and related documentation, the application data of the TOE (such as IC and system specific data, initialisation data, IC prepersonalization requirements and personalization data) A distinction is made in the description of the TOE between the process unit, the memories and the input/outputs. 32

33 Assets have to be protected in terms of confidentiality and integrity. Threats are distinguished between phases. As in [SSCD PP], there is no Organisational Security Policy definition, because it is considered too much dependant of the TOE usage context (i.e. application). The security objectives include an objective for the TOE to always work, even if environment suffers variations. This PP includes the security requirement FPR_UNO instead of the SSCD PP specific functional security requirement FPT_EMSEC Eurosmart PP0002 "Smart Card IC Platform Protection Profile" The evaluation level of [PP 0002] is also EAL4+ but the augmentation concerns: ADV_IMP.2 (Implementation of the TSF) ALC_DVS.2 (Sufficiency of security measures) AVA_MSU.3 (Analysis and testing for insecure states) AVA_VLA.4 (Highly resistant) [PP 0002] mainly addresses the smartcard IC. [PP 0002] also covers software such IC firmware that is delivered with the smartcard by the IC manufacturer. The only organisational security policy is P.Process-TOE that covers protection during development and production Eurosmart PP0010 "Smart Card IC with Multi-Application Secure Platform" The evaluation level is also EAL4+ but the augmentation concerns: ADV_IMP.2 (Implementation of the TSF) ALC_DVS.2 (Sufficiency of security measures) AVA_VLA.4 (Highly resistant) As for [PP 9911], the [PP 0010] presents a strong dependence with the [PP 9806]. In fact, the TOE shall operate on a hardware platform conformant to the [PP 9806]. As in [SSCD PP], there is no Organisational Security Policy definition, because it is considered too much dependant of the TOE usage context (i.e. application) The NIST SC-user group PP-document (Version 3.0) The evaluation level is also EAL4+ but the augmentation concerns: AVA_VLA.3 (Vulnerability Assessment - Vulnerability Analysis - Moderately resistant) ADV_INT.1 (Development - TSF internals Modularity) [SCSUG] includes the following remark about a trusted channel: "The TOE consists of sufficient hardware and software elements to be capable of establishing a trusted channel to a trusted source for application loading or for other potentially privileged commands." ([SCSUG], section 2.2, paragraph 5) The PP covers the TOE user and the application so the assets are composed of user data and also the application code. The PP includes organisational security policies: 33

34 P.Audit P.Crypt_Std - Cryptographic Standards P.Data_Acc - Data Access P.File_Str - File Structure P.Ident Identification P.Sec_Com - Secure Communications A detailed discussion on these standards compared with [SSCD PP] is given in Annex I. The following section addresses aspects that implementers shall consider when aiming to claim conformance to these different PPs. 6.2 Evaluation aspects of SSCD as HW-SW combination In this section, evaluation of the SSCD as a combination of hardware and software is discussed. Therefore, section addresses those aspects where hardware implementation is desirable. In section software aspects are addressed. Finally, section discusses how combined evaluations may be carried out Requirements for hardware components The SSCD consists of a combination of hardware and software components implementing the specific TOE Security Functions (TSF) for the functional requirements defined in the PP. For some of these requirements, hardware support is required, as described in the following. The SSCD shall implement security measures to fulfil the security functional requirements FPT_PHP.1 (passive detection of physical attack) and FPT_PHP.3 (resistance to physical attack). The TSF required by FPT_PHP.1 shall detect physical tampering that might compromise the TSF and provide evidence of tampering. This is normally implemented by covers, locks, seals and/or encapsulation by a hard opaque potting material. Furthermore the SSCD shall, according to FPT_PHP.3, resist physical tampering attacks by responding automatically such that the TSF is not violated. This may be achieved by tamper detecting sensors and zeroing of the SCD and other secrets, environmental failure protection (EFP) features or undergo environmental failure testing (EFT). These TSFs might be implemented completely by hardware but they might be supported by software as well (e.g. active shields of smart card chip checked by the operating system). A signature-creation device completely implemented in software can thus not by itself protect the SCD against physical tamper attack. For an SSCD implemented on a smart card, where there is only power available when the card is inserted in a card reader, the tamper resistance and zeroing of the SCD could for example occur as part of the initial power-up self-testing procedure. The security functional requirement FDP_EMSEC.1 (TOE Emanation) is often implemented by a combination of hardware and software security measures. Hardware co-processors are used not only to speed-up the cryptographic algorithms but also to provide security features to protect the SCC against simple and differential power analysis, timing attacks and other attacks based on the physical behaviour of the implementation. The software implementation of the TSF according to FCS_CKM.1 (Cryptographic key generation) and FCS_COP.1 (Cryptographic operation) shall use these security features for the signaturecreation process. The TSF generating the SCD/SVD pair as required by FCS_CKM.1 for the SSCD Type 1 and Type 3 should use a physical random number generator. The software shall implement the cryptographic algorithm creating the SCD/SVD pair and perform the tests of the physical random number generator according to FPT_TST.1 (TSF testing). All other security functional requirements in the PP may in general be implemented by software which is independent of hardware. 34

35 6.2.2 Division of SSCD into different components As described in the previous section, the SSCD will consist of hardware and software components. The TSF will be implemented by a combination of security features provided by the hardware, software and application data. Different solutions to compose these security features are possible, but they are characterised in general as hardware and operating system, and application functions as discussed in the following sections Hardware platform The SSCD hardware implements the TSF required by (a) the response of the hardware to detected by FPT_TST.1 hardware failures according to FPT_FLS.1 (failure with preservation of secure state), (b) the FPT_PHP.1 (passive detection of physical attack) and the FPT_PHP.3 (resistance to physical attack), and (c) the self-test of hardware resources as required by FPT_TST.1 (TSF self test). Furthermore, the hardware is supposed to provide functions to support FCS_CKM.1 (Cryptographic key generation), FCS_COP.1 (Cryptographic operation), and FPT_EMSEC.1 (TOE emanation) and a random number generator to support FCS_CKM.1. Furthermore, the hardware is supposed to provide functions to support FCS_CKM.1 (Cryptographic key generation), FCS_COP.1 (Cryptographic operation), and FPT_EMSEC.1 (TOE emanation). For FCS_CKM.1 a random number generator such as a hardware noise source as discussed is required that needs to fulfil the provisions of [ALGO]. For the functions, either a cryptographic co-processor common for smartcards or a general purpose processor carrying out the crypto-processing can be employed. Besides performance aspects, an implementer may decide to employ a dedicated crypto co-processor in order to develop an SSCD that is resistant against attacks such as [DPA], with reference to FPT_EMSEC Operating system The operating system software manages the hardware resources and provides services for the applications. The operating system software implements the following: (a) cryptographic algorithms for FCS_CKM.1 and FCS_COP.1 while the parameters are defined by TSF data of the application. These TSF fulfil FPT_EMSEC.1 and use the cryptographic coprocessor and the random number generator of the hardware platform; (b) access control to files, keys and reference authentication data based on the TSF data of the application; (c) identification according to FIA_UID.1 (Timing of identification), authentication according to FIA_UAU.1 (Timing of authentication) and management of reference authentication data according to FIA_AFL.1 (Authentication failure handling) and FIA_ATD.1 (User attribute definition), (d) automatic integrity check for stored data according to FDP_SDI.1 (stored data integrity monitoring); (e) object reuse for cryptographic private and secret keys and authentication data according to FDP_RIP.1 (subset residual information protection); (f) the operating system response to detected by FPT_TST.1 (TSF self testing) hardware or software failures according to FPT_FLS.1 (failure with preservation of secure state); (g) self-test according to FPT_TST.1 (TSF self testing) for the implementation of the cryptographic algorithms, the random number generator and access control features; and 35

36 (h) encryption and cryptographic checksums mechanisms for input and output data for support of FDP_UIT.1 (data exchange integrity), FTP_ITC.1 (inter-tsf trusted channel) and FTP_TRP.1 (trusted path) depending on the TSF data (keys) of an application SSCD application The SSCD application consists of SSCD specific data (user data and TSF data) and possibly of specific software for signing. For smart cards, the SSCD application normally consists only of user data (keys) and TSF data in the form of directory files, elementary files with their access conditions. No executable code is then part of the SSCD application, because the operating system provides all necessary functions. The SSCD application implements: (a) (b) (c) (d) the access control security functional requirements FDP_ACC.1 (Access control policy) and FDP_ACF.1 (Security attribute based access control) by the definition of the PP SSCD SFP through security attributes (e.g. file access conditions for smart cards) based on security features of the operating system; the SFP for imported and exported data according to FDP_ETC.1 (Export of user data without security attributes) and FDP_ITC.1 (Import from outside TSF control); the security management functions FMT_MOF.1 (management of security functions behaviour), FMT_MSA.1 (management of security attributes), FMT_MSA.2 (secure security attributes), FMT_MSA.3 (static attribute initialisation), FMT_MTD.1 (management of TSF data ) and FMT_SMR.1 (security roles) based on security features of the operating system; the specific abstract machine testing FPT_AMT.1 (Abstract machine testing) based on security features of the operating system, possibly refined according to the [SSCD PP] security functional policy through security attributes Evaluation of the SSCD as composite device The hardware, software and the application are usually provided by different vendors. This calls for an evaluation of a composite product based on evaluated components. Below, we will discuss the most common evaluation approaches (see picture). The goal for all these evaluations is to get a certificate for the SSCD conforming to the PP SSCD. 36

37 Case 1 Case 2 Case 3 Application level Operating system level Hardware level PP SSCD Evaluation of SSCD with PP SSCD claim Evaluation of SSCD with PP SSCD claim Evaluation of Hardware Platform Evaluation of SSCD with PP SSCD claim Evaluation of Hardwrae Platform and Operating System Case 1 Evaluation of the SSCD as an integral product The TOE is the complete SSCD and the security target claims conformity with the PP SSCD. None of the TOE components is evaluated separately. The sponsor of the SSCD evaluation ensures that the developers of the different components provide the necessary evaluation deliverables of their respective components Case 2 - Evaluation of the SSCD using hardware evaluation results The TOE and the security target are the same as in case 1, but the hardware platform of the TOE has previously been evaluated and certified. The SSCD evaluation may use the results of the hardware platform certification ensuring that - the ST of the hardware platform includes the appropriate security objectives and security requirements of the PP SSCD and - the operating system and application components of the TOE use the hardware platform in the certified manner, i.e. as required by the hardware platform guidance. If these conditions are fulfilled, the SSCD evaluation can assume the certified security features as given. The SSCD evaluation will focus on - the TSF provided by combining the hardware platform and the operating system, e. g. TSF implementing FPT_EMSEC.1, - the correctness and effectiveness of the TSF provided by the operating system and the application, and - the product as a whole fulfilling the PP SSCD. Note that the last evaluation task may need further information about the results of the hardware platform evaluation. These issues are very implementation-specific and depend on the SSCD technology, the hardware platform certificate and other factors. The described evaluation approach is widely used for smart cards. Examples of protection profiles that could be considered as a basis for hardware evaluations are 37

38 Protection Profile Smart Card Integrated Circuit [PP 9806] Smartcard IC Platform Protection Profile [PP 0002] But note that PP SSCD at the one hand and the PP [PP 9806] and [PP 0002] on the other hand do not match completely each other. For further details see Annex I. The evaluation of the smart card as combination of chip on the one hand and the operating system and application on the other hand is discussed in the eeurope Smartcard Charter initiative, TB3, including certification bodies, evaluation facilities and smart card vendors Case 3 - Evaluation of the SSCD using results of hardware and operating system evaluation The TOE and the security target are the same as in case 1, but the combined hardware platform and the operating system of the TOE has previously been evaluated and certified. The SSCD evaluation may use the results of the certification ensuring that (i) the ST of the product includes the appropriate security objectives and security requirements of the PP SSCD and (ii) the application component of the TOE uses the certified product in the certified manner i.e. as required by the guidance. If these conditions are fulfilled, the SSCD evaluation can assume the certified security features as given. The SSCD evaluation will focus on that (iii) the application uses the security features provided by the certified product to implement the TSF required by the PP SSCD, e. g. the access control for the keys provided by the operating system is used to implement the SVD Transfer SFP, Initialisation SFP, Personalisation SFP and Signaturecreation SFP and (iv) the product as a whole fulfils the PP SSCD. Note that the evaluation task (iii) may need further information about the results of the hardware platform and operating system evaluation. These issues are very implementation-specific and depend on the SSCD technology, the evaluation certificate and other factors. The described evaluation approach can also be used for smart cards. Examples of protection profiles that could be considered as a basis for evaluations are Protection Profile Smart Card Integrated Circuit with Embedded Software [PP 9911] Smart Card Security User Group: Smart Card Protection Profile [SCSUG] However, it should be noted that PP SSCD on one hand and the PP [PP 9911] and [SCSUG] on the other hand do not match each other completely. For further details see Annex I. 38

39 7 General Platform Implementation Guidelines The signature creation process is described in [CWA 14170], and defines a Signature Creation System (SCS) as consisting of a Signature Creation Application (SCA) and a Secure Signature Creation Device (SSCD). The generic process to produce an electronic signature is as follows: The Signer s Document Presentation Component (SDP) of the SCA is used to review the document The SCA obtains the permission to sign the message through the Human Interface (HI) The Data Hashing Component (DHC) of the SCA creates the representation (hash) of the DTBS which is referred to as the DTBSR The SCA sends the DTBSR to the SSCD The SSCD creates the signature using the SCD The Signed Data Object Composer (SDOC) formats the SDO output Signature Creation Functional Model Signature policy Issuers (optional) Contract PKI - CSP Certificates Signature Creation System Signature Policy (optional) Operating System & other application processes Signer Signer s interface Result Signature Creation Application Local storage Signer s Authentication Data Signature-Creation Device Trusted SCA components Application specific SCA components Other inputs and outputs Networks Signature creation data Signature Suite SSCD/SCA interface (trusted path) SCA Manager 7.1 SSCD and the Qualified Certificate SSCD-indicator in the certificate A Qualified Electronic Signature is defined as an advanced electronic signature, based on a qualified certificate and created by an SSCD. The ETSI QCP [TS ] defines two certificate policy identifiers, one of which, QCP public + SSCD, guarantees that the qualified certificate is issued for an SVD (public key) 39

40 where the corresponding SCD (private key) resides in an SSCD. For relying parties receiving a signed message referencing such a certificate, this will assure them that the signature actually is a qualified signature. If the qualified certificate instead only contains the QCP public policy identifier, the relying party must through some other means get assurance that an SSCD has been used. Although this may be achieved either by technical or procedural means, it will certainly be much more complicated than if this is assured by the CA, for example by specifying the QCP OID in the certificate Trusted channel to the CGA In order to simplify the needs of relying parties, it can be expected that most CAs will want to ensure and guarantee that an SSCD is used to store the SCD, even if the SSCD is not provided by the CA. In such a scenario, the signatory will obtain his SSCD from a different source, and then at a later stage ask for certification of his SVD. This has already been foreseen in the [SSCD PP], which requires in FTP_ITC.1/SVD Export that the SSCD provides a trusted channel for exporting the SVD to the Certificate Generation Application (CGA). However, no implementation details are given for such a channel, and there is no requirement anywhere for the CGA to use this trusted channel. The following implementation guidelines for the trusted channels are known worth considering: An implementation of an SSCD should therefore consider this function carefully, and provide a mechanism that can be used easily by a CGA to ensure that the SVD is coming from a genuine SSCD, and to verify the integrity of the SVD. A possible mechanism for this could for example be to provide all SSCDs with a vendor-specific private key, which is used to sign the exported SVD. The CGA can then verify the SVD using the vendor s corresponding public key, which even can be distributed in a certificate. A more reliable mechanism would be to store a device-specific private key on all SSCDs together with a device-certificate, signed by the vendor. The CGA can then also verify that the SSCD is genuine. In addition [SSCD PP] assists the CGA by offering a correspondence proof between SCD and SVD as a cryptographic operation (FCS_COP) Certificate distribution During certificate generation the SSCD communicates with a CGA. In general, two alternatives exist depending on the time of delivery of the SSCD to the signatory: The certificate is created by the CSP in connection with key generation and SSCD personalisation, before delivering the SSCD to the signatory. The certificate is created at a later point in time, initiated by the signatory. What needs to be considered is that the definition of a qualified certificate includes that the SCD is under control of the signatory ([Dir.1999/93/EC], Annex I (e)). Thus, in the first case measures need to be in place to ensure that the certificate is not made available prior the signatory having control of the SCD, such as actually having received the SSCD. In both cases, SVD export through a trusted channel is necessary if the SCD/SVD generation has been performed in the SSCD, or if it was performed in a Type 1 SSCD and later exported to the signatory's SSCD. 7.2 Implementation of SCA and SSCD When implementing both SCA and SSCD on a specific platform, there are two possibilities: The SCA and SSCD share a computing engine (Class 1 SCS), or The SCA and SSCD are using two separate computing engines (Class 2 SCS). Both possibilities will be discussed further in the following sections. 40

41 7.2.1 Class 1 SCS SCA and SSCD share a computing engine For a Class 1 SCS, the SCA and SSCD share a computing engine. This arrangement requires the following issues to be solved: Domain separation The SCA and SSCD must be separate from all other computing processes. If the single purpose of the device is signature creation, this is not an issue. If the device allows for other operations then the connection between the SCA and SSCD requires a trusted channel. Protection of SCD As the device is acting as an SSCD, it must provide all of the functions of an SSCD. Protection of DTBSR - Creation and transmission of the DTBSR (i.e. hash value) requires a trusted channel between the SCA and SSCD. The trusted channel in a single purpose device could be a hardware channel in a protected platform. Secure input and output The SCA must be able to display properly the message to sign (DTBS) and receive the user s unambiguous consent to create one or more signatures. The major attack points for a Class 1 SCS implementation are the separation of the SCA and SSCD from other components and the protection of the SCD. In single purpose devices, most of these problems do not exist; however the user has a device that only performs one operation. With the shared computing engine and multiple processes, the protection of the SCD and the proper transmission of the DTBSR become very difficult problems to solve Class 2 SCS SCA and SSCD on separate computing engines For a Class 2 SCS, the SCA and SSCD are using separate computing engines. The separate components could be on the same physical platform, but the processes do not share the same computing engine. This arrangement requires the following issues to be solved: Trusted channel The SCA and SSCD require a trusted channel to communicate commands and the DTBSR. The commands include the user s selection of the SCD and the unambiguous consent to perform one or more signatures. Identification of SCA and SSCD Proper creation of the trusted channel requires the identification and authentication of the two end points. The SCA should have a secure input and output path to properly display the message to sign and obtain the user s consent to sign through a trusted path The SSCD must revalidate the user s consent to perform the signature. The major attack point for a Class 2 implementation is the trusted channel between the SCA and SSCD. Since the SSCD meets the requirements of the SSCD PP, once the DTBSR arrives at the SSCD the security needs are met. The issue is the creation of the DTBSR and its transmission. 7.3 Display limitations Many devices will have access to a limited amount of screen display. This limitation creates a need to have two types of signature devices. These two types are known as Display message and Display hash Display message (DM) device With a DM device, the entire message can be displayed by the device, thus containing the complete SCA. The entire message includes text, format information, graphics, colours and other information. The message is presented on the screen of the device by the SDP (Signer's Document Presentation component) of the SCA residing in the device. 41

42 7.3.2 Display hash (DH) device If the signing device only can display a limited amount of data, the SCA will actually consist of two parts: one in the device, and one in a remote terminal. The remote terminal part of the SCA, containing the SDP as well as the Data Hashing Component (DHC), will present the data, perform hashing, display the resulting hash value and also send the hash value to the device. The hash value will then be displayed also in the device, to ensure the integrity of the DTBSR sent from the remote terminal to the device. 7.4 Use cases The following use cases can be seen. Class 1: Shared computing engine Class 2: Separate computing engine Class 1DM System Display Message device Class 1DM system Ex: Dedicated signing device, Secure PC with trusted I/O, Secure PDA with integral SSCD, SIM card with SSCD Class 2DM system Ex: PC with smart card, PDA with smart card, Mobile phone with S/WIM Display Hash device Class 1DH system Ex: Smart card with display, Mobile phone with integral WIM, Dedicated signing terminal Class 2DH system Ex: Mobile phone with S/WIM This system is totally self-contained, has only one processing unit and provides complete protection of the SSCD and SCA at all times. The system provides an internal trusted channel between the SSCD and SCA. The message display unit can display the message unambiguously to the user and obtain the user s consent to perform the signature. An example of this type of system would be a dedicated signing device product, or a PC running a secure operating system with trusted I/O for all input and output devices. Another example is a SIM card containing both the SSCD and SCA, only using the mobile phone as a trusted I/O device. A Class 1DM system can also perform the same functions as a Class 1DH system, i.e. display a hash instead of the complete message Class 2DM System This system has two processing units: the main processor and the SSCD. The system must provide a trusted path between the SCA on the main system and the SSCD. The message display unit is connected to the SCA processor and can display the message unambiguously to the user. The user s consent to perform the signature can be obtained through a trusted path either to the SCA, or directly to the SSCD (for example using a smart card reader with built-in PIN-pad). An example of this system would be a PC or PDA with an SSCD attached as a smartcard or USB device, or a mobile phone with S/WIM where the message is short enough to be displayed on the phone Class 1DH System This system has the SSCD and parts of the SCA on the same processor and the system provides complete protection of the SSCD and the local part of the SCA at all times. However, the display unit is incapable of displaying the entire message and only displays a hash of the message. A trusted channel is therefore required between the remote part of the SCA (displaying the message and performing the hashing) and the local part of the SCA. 42

43 7.4.4 Class 2DH System This system has separate processing units for SSCD and SCA. The display unit is incapable of displaying the entire message and only displays a hash of the message. The SSCD and the SCA part residing in the device, which displays the hash value, are connected using a trusted channel. The SCA also contains a remote component with SDP and DHC. The system must provide a trusted channel between the DHC and the SSCD. An example of this type of system would be a mobile phone with the SSCD in an S/WIM (SIM-based WIM), being used to sign messages that can not be displayed on the phone itself. Part of the local SCA resides in the S/WIM, using the processing unit of the mobile phone just to display the hash value. The main part of the SDP and DHC are however contained in a remote terminal application, for example displaying the message to be signed in a web browser. 43

44 8 Implementation guidelines for smartcards The smartcard is currently seen as an obvious SSCD. It is secure, it is personal and it gives the user mobility. Smartcards are available both as Type 2 and Type 3 SSCD (without and with on-board key generation). A smartcard will be a very natural component of a Class 2 signature creation system, since the smartcard does not have the capability to contain the SCA. 8.1 SSCD platform functions Personalisation Personalisation encompasses SCD/SVD Generation and SCD import or SVD export as necessary. There are two possibilities for performing key generation: Key generation performed outside the card. This means that the SSCD is a Type 2 device according to [SSCD PP], with a requirement for a Trusted Channel for SCD import. In this case, key generation will usually be performed by the manufacturer of the smart card, or by the CSP offering an SSCD provision service. The smart card will then be delivered to the user with pre-generated keys. Key generation in the smart card itself, on-board key generation. A smart card with on-board key generation would constitute an SSCD Type 3 device according to [SSCD PP]. Key generation can then either be initiated by the manufacturer, the CSP or the user himself after receiving the smart card. The second step of personalisation is the Certificate Generation, which has been addressed in section User authentication For a smart card, user authentication is performed by entering an alphanumeric PIN value through a Human Interface. The Human Interface can either be a keyboard controlled by the SCA (for example a PC or PDA keyboard), or a PIN-pad directly on the smartcard terminal. A trusted path needs to be established between the Human Interface and the smart card, ensuring the confidentiality of the PIN. This is naturally more easily done with a PIN-pad smartcard terminal. After a pre-defined number of erroneous attempts, the card will be blocked. It can then only be unblocked by entering a PIN Unblocking Key (PUK) Trusted channels and trusted path In a Class 2 SCS an important consideration for the SSCD is the trusted channel to the SCA. For smartcards this entails the authentication of the SCA and the mechanism that supports the trusted channel. The following mechanisms for establishing a trusted channel can be seen for smart cards: Secure Messaging as defined in [ISO 7816]; for more details refer to section ; External authentication as defined in [ISO 7816]. Trusted channels and paths also need to be established for the following purposes: A trusted channel is required for SCD import to the smart card from the SSCD Type 1, when key generation is performed outside the smart card. A trusted channel is required for SVD export from the smart card to the CGA, when key generation is performed in the smart card A trusted path is required for the user s input of the authentication data (PIN) to the smart card. 44

45 8.2 SSCD environment The signing process can take place in two distinctly different types of physical environments where the SCA is controlled by different organisations. A typical environment for the first case might be the home or the office, where the individual or the company has direct control of SCA. In this case, the security requirements may be met by organisational methods by the signer, and the technical means to ensure achievement of the security requirements may be more relaxed. For instance, in an extreme case, the Signer can use an isolated PC that is stored in a safe that can only be opened by the signer. A typical environment for the second case is where an SCA is located in a public place such as a railway station, bank or any other SCA that is operated by a service provider that is not necessarily related to or under the control of the signer. Without further technical security measures, this type of environment can suffer a number of other types of attacks, for example replacement of the SCA with a false SCA. The technical requirements of SCAs operated in such a public environment will therefore be more stringent. 45

46 9 Implementation guidelines for mobile phones The mobile phone is an excellent signature creation device. It has the capability to contain an SSCD and parts of the SCA. The mobile phone is a personal device that is normally protected from misuse by its owner. In the following, the mobile phone is used to denote the complete handheld device, consisting of both the Mobile Equipment (ME) itself and any SIM cards, chips or other smart cards inserted into it. The mobile phone can in theory be either a Class 1 or Class 2 SCS. Although it is possible to use the phone itself to implement the SSCD, it is anticipated that it would normally be a Class 2 SCS with the SSCD being implemented in a SIM card, possibly according to the WIM standard (S/WIM card). Another interesting possibility is that the SIM card itself constitutes a Class 1 SCS, using the ME just as a trusted I/O device for PIN input and display. It is also possible to implement the SSCD on a separate chip than the SIM card. This solution requires a "dual-slot" or dual-chip phone where a separate smart card or chip (using WIM or other standard) is inserted into the phone. However, at the time of the development of the present document, this solution seems to be of decreasing interest, and therefore will not be further discussed. 9.1 Usage considerations A mobile phone has a limited amount of screen space available to display a message. It should therefore be considered to be used for signing in one of three ways: As a Class 1DM, where the message is small enough to be presented on the phone s display. In this case, the complete SCA, including SDP and DHC, reside in the SIM together with the SSCD. As a Class 2DM, where the message is small enough to be presented on the phone s display. However, in this case, the SDP and DHC reside in the Mobile Equipment and the SSCD in the SIM. As a Class 2DH system, where the message is too large to be presented on the phone, and therefore only a hash value is presented and signed Displaying the complete message on the phone The message to be signed is sent to the mobile phone, using the WMLScript signtext command or a similar function. The mobile phone presents the message on the screen, hashes the message and signs it using the private key stored in the mobile phone. In this case, there are actually two ways of implementing the SCA: SCA in ME In this case, the SCA resides in the Mobile Equipment, and just transmits the hash value to the SIM card, which needs to establish a trusted channel with the SCA to receive the DTBSR, and to transmit back the SDO (Signed Data Object). It also needs a trusted channel for the input of authentication data from the keypad of the ME. SCA in SIM itself In this case, the SCA resides in the SIM together with the SSCD, thus sharing the computing engine of the SIM. Through the phone s SIM Toolkit API, the SCA only uses the phone s display as SDP (viewer) and keypad as input device for authentication data (PIN). The SIM card would in this case actually implement a type 1DM System Displaying only a hash value on the phone The message to be signed is too large to be presented on the screen of the ME. The message is instead presented for example in a Web-browser residing on a PC. The signing application then hashes the message, and sends the hash to the phone for signing. In order to ensure that the hash value has not been tampered with in transit, a part of the hash value is presented as a hexadecimal string both in the browser/viewer and on the screen of the phone. 46

47 When only a hash value is sent to the phone for signing, the SCA actually consists of two parts: one in the mobile phone and one in the remote terminal, containing the SDP as well as DHC. Together, the two parts of the SCA have to ensure the integrity of the DTBSR (hash value) sent from the remote terminal to the phone. This can be done by comparing the hash values presented in both parts of the SCA, thus letting the user verify their correctness. 9.2 SSCD platform functions Personalisation Personalisation encompasses SCD/SVD Generation and SCD import or SVD export as necessary. There are two possibilities for performing key generation: Key generation performed outside the card. This means that the SSCD will be a Type 2 device according to [SSCD PP], with a requirement for a Trusted Channel for SCD import. In this case, key generation will usually be performed by the manufacturer of the SIM card, or by the mobile operator. The SIM will then be delivered to the user with pre-generated keys. Key generation in the smart card itself, on-board key generation. A SIM card with on-board key generation would constitute an SSCD Type 3 device according to [SSCD PP]. Key generation can then either be initiated by the manufacturer, the operator or the user himself after receiving the SIM. The second step of personalisation is the Certificate Generation, which has been addressed in section User authentication The mobile phone provides an excellent mechanism to obtain user intention. The screen and input (keypad) are connected and protected from interference. It is very easy to have the user enter a sequence of numbers that are displayed on the screen to verify intention rather than just clicking with a mouse or selecting a single button. User authentication encompasses input of the Signatory's verification authentication data (SVAD), i.e. authentication data provided by the user for authentication as signatory. For the mobile phone, this means a numeric PIN code entered by the user on the mobile phone s keypad. It is recommended that the PIN code is not displayed in clear when typed. The SSCD must thus provide support for a trusted path to the PIN keypad. However, in contrast with the ordinary PIN for the SIM card, the user authentication for the signature function must be entered for each signature operation. After a pre-defined number of erroneous attempts, the SIM card will be blocked. It can then only be unblocked by entering a PIN Unblocking Key (PUK) Trusted channels and trusted path The following trusted channels and paths can be foreseen for the mobile phone platform: A trusted channel is required for SCD import to the SSCD from the SSCD Type 1, when key generation is performed outside the SIM card A trusted channel is required for SVD export from the SSCD to the CGA, when key generation is performed in the SIM card A trusted channel is required for DTBSR import to the SSCD from the SCA. This is of course most easily achieved in a Class 1 System, when both the SSCD and the SCA reside in the SIM card. When the SCA resides in the Mobile Equipment, the requirements for the trusted channel depend heavily on the operating system of the ME. A trusted path is required for the user s input of the authentication data (PIN) from the keypad of the phone to the SSCD. 47

48 9.3 SSCD environment In all use cases above, the SSCD is implemented in the SIM card. The mobile phone comprises the "immediate environment", with screen, keypad and SCA (except where the SCA is implemented in the SIM together with the SSCD). As long as the user employs his own mobile phone, he will regard this as a trusted environment. However, if he at some point in time decides to put his SIM card in a different mobile phone, he may want to ensure that this new mobile phone can be trusted, and not is a manipulated mobile phone, compromising the signing function. 48

49 10 Implementation guidelines for PDA The Personal Digital Assistant (PDA) has rapidly become a personal tool for everyone. With the advent of communication services for a PDA, there is a need for using the PDA as a signature creation system. The PDA can be designed to be all classes of systems: 1DH, 1DM, 2DH and 2DM Computing engine choices Single Computing engine The major issue with a single computing engine is the requirement for domain separation. The PDA hardware and OS must allow for the creation and enforcement of separate domains. Current PDA hardware and OS development makes meeting these requirements quite difficult. This does not preclude a PDA from providing this functionality in the future. After providing for domain separation the PDA must also provide a trusted channel between the SSCD and SCA. This channel could be a hardware channel based on how the PDA was designed or it could be a logical channel using the protections provided by the PDA OS. The final major requirement is to provide for the long-term storage of the SCD. The storage mechanism must pass the [SSCD PP] evaluation Separate Computing engines The separation of SSCD and SCD could be done by having an internal SSCD or by employing a removable SSCD. The PDA must provide a trusted path between the SSCD and SCA. This could be done with a pure hardware connection in the case where the SSCD is always part of the PDA. In the case where the SSCD is a removable part of the PDA, it could be done with a logical path using encryption. When using a removable SSCD the establishment of the trusted path between the SSCD and SCA is critical. Both sides must be able to validate the path and all establishment parameters Display considerations The PDA has an integrated display so it has the ability to have an SCA application running on the device Display Message device The PDA may have the ability to display the complete message to sign. When displaying the complete document the SCA would be an application on the PDA. After creation of the DTBS, the transmission of the DTBSR to the signing engine would be done by trusted path or channel depending on the connection of the SCD to the PDA. It must be ensured that the SCA application can determine the capabilities of the PDA display and inform the signer appropriately. For example if the SCA has insufficient resources to display the document in the correct resolution or with sufficient colour, the SCA must prevent the signing operation. The PDA must create a trusted path/channel to the SSCD depending on the computing engine choices Display Hash device As in all other devices if the SCA is in split mode and is displaying a message rendered on some incompatible device, the SCA must display a hash value on both displays. The signer validates that both devices are displaying the same hash value and then the signer gives the indication that signing can occur. 49

50 The PDA must create a trusted path/channel to the SSCD depending on the computing engine choices User intentions The PDA provides an excellent mechanism to obtain user intention. The screen and input device are connected and can be protected from interference. It is very easy to have the user enter a sequence of numbers that are displayed on the screen to verify intention rather than just clicking with a mouse or selecting a single button. User authentication encompasses the input of Signatory's verification authentication data (SVAD), i.e. authentication data provided by the user for authentication as signatory. The PDA design must consider the effects of docking the PDA. When docked some PDA s allow for the input of information from devices other than the PDA input device and also provide for displaying information on some output device other than the PDA display. Both of these cases must not allow the users intention to be subverted or improperly displayed. Unless the design can ensure that the security properties of the docked and extended devices are exactly the same as the internal devices the PDA must not allow their use in a signature creation operation SSCD platform functions Personalisation Personalisation encompasses SCD/SVD Generation and SCD import or SVD export as necessary. There are two possibilities for performing key generation: Key generation performed outside the SSCD. This means that the SSCD will be of Type 2, with a requirement for a Trusted Channel for SCD import. In this case, key generation will usually be performed by the manufacturer of the SSCD, or by the PDA manufacturer. The PDA will then be delivered to the user with pre-generated keys. Key generation in the SSCD itself. A PDA with on-board key generation would constitute an SSCD Type 3 according to [SSCD PP]. The SSCD manufacturer, the PDA manufacturer or the user himself after receiving the PDA can initiate key generation. The second step of personalisation is the Certificate Generation, which has been addressed in section User Authentication The PDA has a fully-featured input and display devices so the assumption will be that user authentication takes advantage of these facilities. User authentication should use pass phrases at a minimum and if possible use a second factor of authentication. A trusted path/channel between the input device and the SSCD must ensure the confidentiality of the pass phrase or other authentication information. In the case of multiple authentication failures, policies regarding the locking of the SSCD must be implemented Trusted Paths and Channels All systems require at a minimum: For a Type 2 SSCD a trusted channel for SCD import into the SSCD. For a Type 3 SSCD a trusted channel for the SVD export to the CGA. For separate computing engine devices a trusted path between the input device and the SSCD. 50

51 For single engine computing devices a trusted communication line between the input device and the SSCD. The type of communication line (path or channel) will depend on the construction of the PDA and how the input device is connected to the system. The Class 1DH system will require at a minimum the following: A trusted channel between the separated SCA application portions. This path would be the entry point of the DTBSR into the system. A trusted channel between the SCA that displays the hash on the device and the SSCD. The Class 2DH system will require at a minimum the following: A trusted channel between the separated SCA application portions. This path would be the entry point of the DTBSR into the system. A trusted channel between the SCA that displays the hash on the device and the SSCD. The Class 1DM system will require at a minimum the following: A trusted channel between the SCA and the SSCD. The Class 2DM system will require at a minimum the following: A trusted path between the SCA and the SSCD. 51

52 11 Implementation guidelines for PCs The PC has for a long time been the most used device for e-commerce. Already today, many applications create signed messages in the PC environment: Mail programs, browser plug-ins and forms applications. The power of the PC allows for fast calculations and a diverse array of devices. The PC can be used to create all four SCS classes Computing engine choices Single Computing engine The major issue with a single computing engine is the requirement for domain separation. The PC hardware and OS must allow for the creation and enforcement of separate domains. Current PC hardware and OS development makes meeting these requirements quite difficult. This does not preclude a PC from providing this functionality in the future. After providing for domain separation the PC must also provide a trusted channel between the SSCD and SCA. This channel could be a hardware channel based on how the PC was designed or it could be a logical channel using the protections provided by the PC OS. The final major requirement is to provide for the long-term storage of the SCD. The storage mechanism must pass the [SSCD PP] evaluation Separate Computing engines The separation of SSCD and SCD could be done by having an internal SSCD or by inserting a removable SSCD into a slot. The PC must provide a trusted path between the SSCD and SCA. This could be done with a pure hardware connection in the case where the SSCD is always part of the PC. In the case where the SSCD is a removable part of the PC, it could be done with a logical path using encryption. When using a removable SSCD the establishment of the trusted path between the SSCD and SCA is critical. Both sides must be able to validate the path and all establishment parameters Display considerations The PC has an integrated display so it has the ability to have an SCA application running on the device Display Message device The PC may have the ability to display the complete message to sign. When displaying the complete message the SCA would be an application on the PC. After creation of the DTBS, the transmission of the DTBSR to the signing engine would be done by trusted path or channel depending on the connection of the SCD to the PC. It must be ensured that the SCA application can determine the capabilities of the PC display and inform the signer appropriately. For example if the SCA has insufficient resources to display the document in the correct resolution or with sufficient colour, the SCA must prevent the signing operation. The PC must create a trusted path/channel to the SSCD depending on the computing engine choices Display Hash device As in all other devices if the SCA is in split mode and is displaying a message rendered on some incompatible device, the SCA must display a hash value on both displays. The signer validates that both devices are displaying the same hash value and then the signer gives the indication that signing can occur. 52

53 The PC must create a trusted path/channel to the SSCD depending on the computing engine choices User intentions The PC provides an excellent mechanism to obtain user intention. The screen and input device are connected and can be protected from interference. It is very easy to have the user enter a sequence of numbers that are displayed on the screen to verify intention rather than just clicking with a mouse or selecting a single button. User authentication encompasses input of Signatory's verification authentication data (SVAD), i.e. authentication data provided by the user for authentication as signatory SSCD platform functions Personalisation Personalisation encompasses SCD/SVD Generation and SCD import or SVD export as necessary. There are two possibilities for performing key generation: Key generation performed outside the SSCD. This means that the SSCD will be of Type 2, with a requirement for a Trusted Channel for SCD import. In this case, key generation will usually be performed by the manufacturer of the SSCD, or by the PC manufacturer. The PC will then be delivered to the user with pre-generated keys. Key generation in the SSCD itself. A PC with on-board key generation would constitute an SSCD Type 3 according to [SSCD PP]. The SSCD manufacturer, the PC manufacturer or the user himself after receiving the PC can initiate key generation. The second step of personalisation is the Certificate Generation, which has been addressed in section User Authentication The PC has a full-featured input and display devices so the assumption will be that user authentication takes advantage of these facilities. User authentication should use pass phrases at a minimum and if possible use a second factor of authentication. Using the ability of the PC to attach additional devices would allow for greater assurance during user authentication. For example, the PC could have a fingerprint reader attached so that the pass phrase could be checked with the appropriate fingerprint for the user. A trusted path/channel between the input device and the SSCD ensures the confidentiality of the pass phrase or other authentication information. In the case of multiple authentication failures, policies regarding the locking of the SSCD must be implemented Trusted Paths and Channels All systems require at a minimum: For a Type 2 SSCD a trusted channel for SCD import into the SSCD. For a Type 3 SSCD a trusted channel for the SVD export to the CGA. For separate computing engine devices a trusted path between the input device and the SSCD. For single engine computing devices a trusted communication line between the input device and the SSCD. The type of communication line (path or channel) will depend on the construction of the PC and how the input device is connected to the system. A trusted channel between the computing engine and the output device. 53

54 The Class 1DH system will require at a minimum the following: A trusted channel between the separated SCA application portions. This path would be the entry point of the DTBSR into the system. A trusted channel between the SCA that displays the hash on the device and the SSCD. The Class 2DH system will require at a minimum the following: A trusted path between the separated SCA application portions. This path would be the entry point of the DTBSR into the system. A trusted path between the SCA that displays the hash on the device and the SSCD. The Class 1DM system will require at a minimum the following: A trusted channel between the SCA and the SSCD. The Class 2DM system will require at a minimum the following: A trusted path between the SCA and the SSCD. 54

55 12 Signing Services It is quite possible to design a Signing Service system where the SCD of all users are held in a large SSCD to which many users can connect. One instance would be an Internet site that signs messages for the signatory when presented with the message and proper user authentication. This design is not prohibited by the Directive and is technically possible. The output of the current workgroup however does not address the serious technical issues that this type of design will present. Firstly, the [SSCD PP] is not appropriate for the SSCD that the signing service would use. A new PP is required to address the concerns of proper separation of SCD information, user authorization, user intentions and message display. Another major problem that the signing service must solve is the creation of the trusted path between the user and the SCA and the trusted path between the SCA and the SSCD. For the Signing Service, the trusted path may very well have to be established over the public Internet. In addition the ability to properly obtain the user s consent to use the SCD would require a trusted path between the SSCD and the current platform where the user is residing. These problems are not technically infeasible to solve; however with the current generations of hardware and software the choices will be limited. 55

56 Annex I (informative) Comparison of Protection Profiles In section 6.2 the document identified a number of related protection profiles that an implementer might aim to conform to in addition to the [SSCD PP]. Several cases that might be considered regarding the combination of evaluation against these PPs have been discussed in section 6.2. In this Annex, details of the related PPs are given. Therefore, section AI.1 gives a comparison of security objectives that overlap in the various PPs. In section AI.2 the selection of SFRs in the different PPs is given. AI.1 Security Objectives comparison This section aims at providing a comparison between the security objectives of the [SSCD PP] and the Eurosmart PPs [PP 0010] and [PP 0002] (respectively the [SCSUG] PP) by trying to answer to the question: If one was to write a Security Target claiming compliance with both [SSCD PP] and Eurosmart [PP 0010] (resp. [PP 0002] or [SCSUG]) PP, which security objectives of each would help guaranteeing security objectives of the other?. For each security objective, the answers to this question can be quite straightforward or, more frequently, depend on additional assumptions or commitments in the development or the features of the SSCD. The contents of this sections tries to outline questions that have to be answered to while trying to make up a ST compliant with both and Eurosmart [PP 0010] (resp. [PP 0002] or [SCSUG]) PPs. In the cases covered in this section, general assumptions are necessary to delineate scenarios of composition. Additional assumptions are stated below for each case, as appropriate. The SSCD considered (whatever its type) is implemented into a smartcard, destined to be inserted and used into a terminal (e.g. Card Accepting Device, CAD). Hence, the SSCD personalisation phase corresponds to smartcard personalisation phase, and the SSCD usage and destruction phase correspond to smartcard endusage. Authentication of the signatory is performed through an external device, connected to (and possibly part of) the terminal. As some caution is to be given to these different life-cycle models represented in the various PPs covered in this section, the following figure illustrates the different life-cycle models from [SSCD PP] and the Eurosmart PPs ([PP 9806] and [PP 0010], resp. [PP 0002]). Design Fabrication Initialisation Personalisation Usage Destruction HW design OS design SSCD destruction Application design H W fabrication OS and application implementation Loading of general application data SCD/SVD generation (Type 1, Type 3) SCD export (Type 1), SCD import (Type 2) Signature-creation (Type 2, Type 3) Operational phase Development phase PP 0002 TOE-Manufacturer PP 0002 TO E D elivery PP 0002 Card-Manufacturer PP/9806 scope Development phase Production phase User phase Phase 1: Smartcard embedded HW design softw are developm ent Phase HW design 2: IC development Phase 3: IC manufacturing HW design and testing Phase 4: IC packaging HW design and testing Phase 5: Smartcard product HW design finishing process Phase 6: Smartcard HW design personalisation Phase HW design 7: Smartcard end-usage [SSCD PP] Life-cycle model Eurosmart PPs Life-cycle model (simplified) [PP 9806]/[PP0010], resp. [PP 0002] SSCD application software deployment can be planned as early as embedded software development, or be carried out in a separate life-cycle ending with a late integration within the smartcard. 56

57 AI.1.1 AI SSCD vs. Eurosmart PP0010 Scope of TOE Eurosmart [PP 0010] Protection Profile defines requirements for a multi-application smart-card platform built in an integrated circuit, as well as for its life-cycle, defining phases numbered from 1 (embedded software development) to 7 (end-usage). The platform comprises an Operating System, a Loaded-Application System Interface, IC Dedicated Software (out of TOE, but subject to the requirements of [PP 9806]) and possibly Native Applications. The platform s Operating System supports loading of Loaded Application at personalisation or end-usage phases (phases 6 and 7 respectively). The development and inclusion of Native Applications can be forecast and carried out as early as phase 1 and included at phase 3 (IC manufacturing), 6 (personalisation) or 7 (end-usage). Loaded Application interactions with the Operating System are bounded by the use of the Loaded-Application System Interface, whereas Native Applications may have direct access to the Operating System. The security problems dealt with by the security objectives stated in this PP can be summarised as follows: tampering with or passive listening to TOE security functions, TSF data and user (Loaded and Native Application) data, protection from cloning, development security, elimination of flaws, multi-application management: o o o o o fault-tolerant loading, access control on application loading and removal operations, control of confidentiality, integrity, authenticity of loaded applications, deletion of residual information associated with removed applications, segregation and resource containment between applications. The questions that should be answered to are: Is the SSCD a Native or a Loaded Application? During which phase is it inserted? (the lifecycle Figure 5 in the CWA, Figure 3 in the SSCD PP respectively rather indicates a Native Application loaded by the card manufacturer). SSCD operational environment (in the sense of the CC) begins with phase 6, whereas Eurosmart maps it to phases 4-7. One must be cautious of the context (SSCD or Eurosmart) when reading such terms as development operation or life-cycle. Are there additional applications (Loaded or Native) allowed to stand aside of the SSCD? Is loading of applications during the end-usage phase allowed? Does the destruction of the SSCD rely upon the application removal operations envisioned by the Eurosmart PP, or is it physical destruction (the SSCD PP is not clear about this point, however SCD destruction is discussed in detail in section of these guidelines)? Does the secure communication protocol with the card terminal encompass authentication of the user? Other checkpoints are identified below as provisos for the matching of security objectives. AI Comparison of security objectives There is not a tremendous match between the two sets of security objectives. The common subset deals with physical and electronic protection, life-cycle requirements, and secure communication with terminal. There is a problem with the security objectives dealing with tampering. 57

58 Some security objectives for the environment from Eurosmart PP partially match those security objectives for the TOE from SSCD PP. This means that conformance to SSCD PP help to fulfil environmental requirements/assumptions from the Eurosmart PP point of view. In order to mark security objectives for the environment, their prefixes have been changed form O. to OE., for objectives of the TOE [SSCD PP] uses the prefix OT. Objective OT.EMSEC_Design (from SSCD PP) completely matches objective O.SIDE (from Eurosmart PP). Objective OT.Init can match OE.INIT_ACS, provided that the scope of this latter objective ( Initialisation Data shall be accessible only by authorised personnel (physical, personnel, organisational, technical procedures). ) effectively match SCD/SVD Note that SCD shall not be delivered to any person and as such SCD may not be considered initialisation data in as defined in [PP 9911]- Objective OT.Lifecycle_Security matches O.FLAW as far as the elimination of faults is concerned. Objective OT.SCD_Secrecy can match O.DIS_MECHANISM2, provided that the scope of this latter objective ( protection of ES security mechanisms against unauthorised disclosure ) implies non-disclosure of the SSCD Objective OT.Tamper_ID is in direct contradiction with O.TAMPER_ES, whereas O.Tamper_Resistance completely matches it. The contradiction lies between prevention and detection of tampering. To some extent the difference is due to [SSCD PP] having been defined technology-neutral whereas the Eurosmart PPs strongly relate to smartcards. Objective OT.DTBS_Integrity_TOE matches O.MOD_MEMORY (as far as protection of DTBS representations stored within the TOE) and can match OE.USE_DIAG (as far as protection of DTBS representations between the SCA and the SSCD. What is to be considered is that [SSCD PP] requires the TOE to preserve integrity of DTBS-representation, whereas O.USE_DIAG is an objective of the requirement. Objective OT.Sigy_SigF can match OE.USE_DIAG provided that the secure communication protocols between the smartcard and the terminal addressed by this latter objective implies authentication of the user. Note that user authentication is not as explicit in the Eurosmart PPs as in [SSCD PP]. Objective OE.HI_VAD can match OE.USE_DIAG provided that the secure communication protocols between the smartcard and the terminal addressed by this latter objective implies authentication of the user and appropriate protection (confidentiality and integrity) of the authentication data (the VAD) in transit between the terminal and the smartcard. AI.1.2 AI SSCD vs. Eurosmart PP0002 Scope of TOE The Eurosmart [PP 0002] Protection Profile defines requirements for the smart card IC platform which consists of a processing unit, security components, I/O ports and memory (volatile and non-volatile). Software is covered as dedicated software (firmware) to the extend as it exists when being delivered by the IC manufacturer. As such the PP is mainly concerned with the hardware design and development stages. [PP 0002] relates to the Eurosmart PPs in a sense that it defines the same seven phase life-cycle model as it has been discussed in the previous section AI The PP defines user data as the primary asset to be protected (besides others such as embedded software, initialisation data, pre-personalisation data). Therefore, leakage of user data information is emphasized as threats to be covered. In addition, quality of random number generators is covered. Secondary assets also cover IC design and physical implementation information. [PP 0002] defines three high-level security goals: SG1: to maintain integrity of user data and embedded software SG2: to maintain confidentiality of user data and embedded software SG3: to provide random numbers 58

59 AI Comparison of security objectives When comparing [SSCD PP] and [PP 0002] the objectives give a certain match where user data primarily the SCD need to be protected. As such, the [PP 0002] represents the hardware platform for the SSCD (similar to [PP 9806]) Objective OT.EMSEC_Design of [SSCD PP] matches objective O.Leak_Inherent and O.Leak_Forced in [PP 0002] OT.SCD_Secrecy of [SSCD PP] matches O.Leak_Inherent and O.Phys-Probing. OT.Tamper_ID and OT.Tamper_Resistance of [SSCD PP] relate to O.Phys-Probing and O.Phys- Manipulation of [PP 0002]. OT.Init of [SSCD PP] partly matches O.Identification by means of supporting pre-personalisation via initialisation data for TOE identification. AI.1.3 AI SSCD vs. SCSUG Scope of TOE [SCSUG] Protection Profile defines requirements for a smart-card platform built in an integrated circuit, comprising an Operating System, and onto which additional applications can be loaded during the end-usage phase. As opposed to the Eurosmart 0010 PP [PP 0010], the smartcard life-cycle is not taken into account for the statement of security objectives (informative annex B.2 provides much information about this point, though). Hence, the fact that (native) applications can be developed and inserted before end-usage, and the corresponding set of security requirements, is not precisely addressed by the security objectives. Operational environment corresponds to end-usage phase. The security objectives for the TOE address this phase exclusively. The security problems dealt with by the security objectives stated in this PP can be summarised as follows: tampering with or passive listening to TOE security functions, TSF data and user data, abiding to cryptography standards and regulations, fault-tolerance, access control to user data and TSF data, access control to life-cycle functions, segregation between applications, audit capabilities, protection against brute-force attacks, protection against replay attacks, secure communication with the CAD. Checkpoints are identified below as provisos for the matching of security objectives. AI Comparison of security objectives There is a better match between SCSUG PP and SSCD PP than with Eurosmart PP, because the tailoring of the smartcard life-cycle phases is in better concordance. Naturally, the SCSUG does not address SSCDspecific objectives, but there are connections concerning general matters like tamper-evidence, logical protection, resistance to brute force attacks, public key management or user authentication. 59

60 One matter of concern, though, is the fact that the SCSUG PP assurance package only comprises component AVA_VLA.3, whereas SSCD PP comprise AVA_VLA.4. The rationale for the selection AVA_VLA.3 ([SCSUG] p. 100) is considered as controversial. Besides, the SCSUG PP mandates a SOF- High level for all statistical or probabilistic mechanisms in the TOE, but not in 0a normative way ([SCSUG] p. 100): Component AVA_VLA.4 shall be selected for claiming conformance to [SSCD PP]. Strength of function claims for the appropriate security mechanisms should be high, in accordance with the considerations of good practice above. Objective OT.EMSEC_Design matches O.I_Leak and O.Env_Strs. Objective OT.Init can match O.Life_Cycle by means of SCD/SVD generation being a life-cycle specific command in terms of [SCSUG]. Within the scope of this security objective, the only commands available to SCD and SVD generation operations need to be explicitly related to the personalisation phase of the SSCD application. OT.Init can also match O.Set_Up. Objective OT.SCD_Secrecy can match O.Brute-Force provided that as far as SCD is concerned the scope of this security objective covers deduction of the SCD by brute-force search. Objective OT.Tamper_ID matches OE.Tamper, but this latter security objective for the TOE environment also provides a supporting organisational security policy about inspection of the carriers by appropriate personnel. Objective OT.DTBS_Integrity_TOE matches O.Log_Prot (as far as protection of DTBS representations stored within the TOE) and can match O.Sec_Com (as far as protection of DTBS representations between the SCA and the SSCD. Objective OT.Sigy_SigF can match O.Sec_Com where the trusted path is provided by [SCSUG]. O.Brute- Force provides the necessary resistance to attacks. Objective OT.Sig_Secure can match O.Crypt, O.Brute-Force or O.Unlink. Objective OE.CGA_QCert can match OE.Key_Supp. Objective OE.SVD_Auth_CGA can match OE.CAD_Sec-Com and/or OE.Key_Supp, depending of the details of the SVD/certificate management policies. Objective OE.HI_VAD can match O.Sec_Com where the trusted path is provided by [SCSUG]. 60

61 AI.2 AI.2.1 Functional Security Requirements comparison FAU Security audit Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Security Alarms FAU_ARP.1.1 X X Audit list generation (PP SCUG) FAU_LST.1.1 FAU_LST.1.2 X X Potential violation analysis FAU_SAA.1.1 X X X FAU_SAA.1.2 X X X Audit data storage [PP 0002] FAU_SAS.1.1 X Selective audit FAU_SEL.1.1 X Protected audit trail storage FAU_STG.1.1 FAU_STG.1.2 X X Action in case of possible audit data loss FAU_STG.3.1 X Comments [SSCD PP] and [PP 9806] do not cover any audit functionality whereas the other PPs do. More precisely, Eurosmart PPs (in term of [PP 9806], [PP 9911], and [PP 0010]) integrated security requirements for security alarms generation and analysis of potential violation of security. [PP 0002] defines a specific family for the capability to store audit data. 61

62 AI.2.2 FCS Cryptographic support Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Cryptographic key generation Cryptographic key distribution Cryptographic key access Cryptographic key destruction FCS_CKM.1.1 X X X FCS_CKM.2.1 E E E FCS_CKM.3.1 E E E X X X FCS_CKM.4.1 X X X X X Cryptographic operation FCS_COP.1.1 X X X X X X Quality metrics for random numbers [PP 0002] X Comments Security requirement about access to the cryptographic key is under the responsibility of the IT environment of the TOE (the CGA for certificate generation). [PP 0002] defines a specific family for the quality metrics of random number generators. 62

63 AI.2.3 FDP User data protection Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Subset access control FDP_ACC.1.1 X X X X Complete Access control FDP_ACC.2.1 X X X FDP_ACC.2.2 X X X FDP_ACF.1.1 X X X X X X X Security attribute based access control FDP_ACF.1.2 X X X X X X X FDP_ACF.1.3 X X X X X X X FDP_ACF.1.4 X X X X X X X Basic Data Authentication FDP_DAU.1.1 X X FDP_DAU.1.2 X X Export of user data FDP_ETC.1.1 X X X X X X without security attributes FDP_ETC.1.2 X X X X X X Subset information flow control FDP_IFC.1.1 X X X FDP_IFF.1.1 X X FDP_IFF.1.2 X X Simple security attributes FDP_IFF.1.3 X X FDP_IFF.1.4 X X FDP_IFF.1.5 X X FDP_IFF.1.6 X X Import of user data without security attributes Basic internal transfer protection Subset residual information protection FDP_ITC.1.1 X X X X X FDP_ITC.1.2 X X X X X FDP_ITC.1.3 X X X X X FDP_ITT.1.1 X X FDP_RIP.1.1 X X X X X X Basic rollback FDP_ROL.1.1 FDP_ROL.1.2 X X Stored data integrity monitoring FDP_SDI.1.1 X Stored data integrity monitoring and action FDP_SDI.2.1 X X X X 63

64 FDP_SDI.2.2 X X X X Basic data exchange confidentiality Data exchange integrity FDP_UCT.1.1 X X FDP_UIT.1.1 X X X X FDP_UIT.1.2 X X X X Comments [SSCD PP] takes into account integrity of data when exchange with other devices occurs. [SSCD PP] does not cover rollback of functions in case of error but manage data integrity. [SSCD PP] and [SCSUG] require both only a subset access control to user data whereas the Eurosmart PPs require a complete access control. AI.2.4 FIA Identification and authentication Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Authentication failure handling FIA_AFL.1.1 X X X X X X FIA_AFL.1.2 X X X X X X User attribute definition FIA_ATD.1.1 X X X X X X X Timing of authentication FIA_UAU.1.1 X X X X X X FIA_UAU.1.2 X X X X X X User authentication before any action FIA_UAU.2.1 X Unforgettable authentication FIA_UAU.3.1 FIA_UAU.3.2 X X Single-use authentication mechanisms FIA_UAU.4.1 X X Protected authentication feedback FIA_UAU.7.1 X Timing of identification FIA_UID.1.1 X X X X X X FIA_UID.1.2 X X X X X X User identification before any action FIA_UID.2.1 X User-subject Binding FIA_USB.1.1 X X 64

65 Comments No comments AI.2.5 FMT Security management Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Limited capabilities [PP 0002] Limited availability [PP 0002] FMT_LIM.1.1 FMT_LIM.2.1 X X Management of security functions behaviour Management of security attributes Secure security attributes Static attribute initialisation Management of TSF data FMT_MOF.1.1 X X X X X X FMT_MSA.1.1 X X X X X X X FMT_MSA.2.1 X X X X X X FMT_MSA.3.1 X X X X X X X FMT_MSA.3.2 X X X X X X X FMT_MTD.1.1 X X X X X Management of limits on TSF data FMT_MTD.2.1 X X FMT_MTD.2.2 X X Revocation Security roles FMT_REV.1.1 FMT_REV.1.2 FMT_SMR.1.1 X X X X X X FMT_SMR.1.2 X X X X X X X X Comments [SSCD PP] covers the same requirements as the Eurosmart PPs [PP 9911] [PP 0010]. [PP 9806] covers the same requirements as [SSCD PP] except for FMT_MTD.1 (management of TSF data). [PP 0002] introduces a specific family to limit the capability and availability of the TSF to its sole purpose. This actually is the only security management function required by [PP 0002]. A difference exists with the PP SCUG that concerns the revocation of security attributes of any data in the TOE which is covered only by the latter. 65

66 AI.2.6 FPR Privacy Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Unobservability FPR_UNO.1.1 X X X Comments See comment about FPT_EMSEC in next section AI

67 AI.2.7 FPT Protection of the TSF Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Abstract machine testing TOE Emanation [SSCD PP] Failure with presservation of secure state FPT_AMT.1.1 X X X FPT_EMSEC.1.1 X X X FPT_EMSEC.1.2 X X X FPT_FLS.1.1 X X X X X X X Inter-TSF detection of modification FPT_ITI.1.1 FPT_ITI.1.2 X X Basic internal TSF data transfer protection Passive detection of physical attack FPT_ITT.1.1 X X FPT_PHP.1.1 X X X FPT_PHP.1.2 X X X Notification of physical attack FPT_PHP.2.1 FPT_PHP.2.2 FPT_PHP.2.3 X X X Resistance to physical attack FPT_PHP.3.1 X X X X X X X X Automated recovery without undue loss FPT_RCV.3.1 FPT_RCV.3.2 FPT_RCV.3.3 FPT_RCV.3.4 X X X X Function recovery FPT_RCV.4.1 X X Replay detection FPT_RPL.1.1 FPT_RPL.1.2 X X Non-bypassability of the TSP TSF Domain separation Inter-TSF data consistency FPT_RVM.1.1 X X FPT_SEP.1.1 X X X X FPT_SEP.1.2 X X X X FPT_TDC.1.1 X X FPT_TDC.1.2 X X 67

68 FPT_TST.1.1 X X X X X X TSF Testing FPT_TST.1.2 X X X X X 1 X FPT_TST.1.3 X X X X X 1 X Comments The SFR FPT_EMSEC has been created for the [SSCD PP]. [SSCD PP] does not take into account recovery functions. [SSCD PP] is the only one to require a passive detection of physical attack. AI.2.8 FRU Resource utilisation Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Limited fault tolerance FRU_FLT.2.1 X Maximum quotas FRU_RSA.1.1 X Comments Fault tolerance is only requested by [PP 0002]. [PP 0010] concerns multi-application and as such FRU_RSA is justified. AI.2.9 FTP Trusted path/channels Functional Security Requirements PP SSCD T1 T2 T3 PP9806 PP0002 PP9911 PP0010 PP SCUG Inter-TSF trusted channel FTP_ITC.1.1 X X X X FTP_ITC.1.2 X X X X FTP_ITC.1.3 X X X X FTP_TRP.1.1 X X Trusted path FTP_TRP.1.2 X X FTP_TRP.1.3 X X Comments Importance given to trusted channels and trusted path is a main difference with other PPs, as reflected by the given table. For a detailed discussion of the trusted paths/channel, see section Both requirements are absent in the [PP 0010] but this seems to be an error in the PP. 68