SIST EN 419211-2:2013

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Schutzprofile für sichere Signaturerstellungseinheiten - Teil 2: Geräte mit SchlüsselerzeugungProfils de protection des dispositifs sécurisés de création de signature - Partie 2: Dispositif avec génération de cléProtection Profile for Secure signature creation device - Part 2: Device with key generation35.100.05UHãLWYHMultilayer applications35.040Nabori znakov in kodiranje informacijCharacter sets and information coding03.160Pravo. UpravaLaw. AdministrationICS:Ta slovenski standard je istoveten z:EN 419211-2:2013SIST EN 419211-2:2013en01-september-2013SIST EN 419211-2:2013SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419211-2
July 2013 ICS 03.160; 35.040; 35.240.15 Supersedes CWA 14169:2004English Version
Protection profiles for secure signature creation device - Part 2: Device with key generation
Profils de protection des dispositifs sécurisés de création de signature - Partie 2: Dispositif avec génération de clé
Schutzprofile für sichere Signaturerstellungseinheiten - Teil 2: Geräte mit Schlüsselerzeugung This European Standard was approved by CEN on 8 May 2013.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2013 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 419211-2:2013: ESIST EN 419211-2:2013

According to the CEN-CENELEC Internal Regulations, the national standards organisations of the following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. SIST EN 419211-2:2013

Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model ISO/IEC 15408-22), Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components ISO/IEC 15408-32), Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance components 3 Conventions and terminology 3.1 Conventions The content and structure of this document follow the rules and conventions laid out in ISO/IEC 15408-1. Normative aspects of content in this European Standard are specified according to the Common Criteria rules and not specifically identified by “shall”. 3.2 Terms and definitions For the purposes of this document, the acronyms, terms and definitions given in prEN 419211-1 apply. 4 PP introduction 4.1 PP reference Title: Protection profiles for secure signature creation device — Part 2: Device with key generation Version: 2.0.1. Author: CEN (TC224/WG17) Publication date:
2013 Registration: BSI-CC-PP-0059-2009-MA-01 CC version: 3.1 Revision 3
1) To be published. This document was submitted to the Enquiry procedure under reference prEN 14169-1. 2) ISO/IEC 15408-1, -2 and -3 respectively correspond to Common Criteria for Information Technology Security Evaluation, Parts 1, 2 and 3.
final draft Keywords: secure signature creation device, electronic signature, digital signature 4.2 PP overview This Protection Profile is established by CEN as a European standard for products to create electronic signatures. It fulfils requirements of Directive 1999/93/EC3) of the European Parliament and of the Council of 13 December 1999 on a community framework for electronic signatures. In accordance with Article 9 of this European Directive, this standard can be indicated by the European Commission in the Official Journal of the European Union as a generally recognised standard for electronic signature products. This protection profile defines security functional requirements and security assurance requirements that comply with those defined in Annex III of the directive for a secure signature creation device (SSCD). This secure signature creation device is the target of evaluation (TOE) for this protection profile. European Union Member States may presume that there is compliance with the requirements laid down in Annex III of the directive when an electronic signature product is evaluated to a Security Target (ST) that is compliant with this Protection Profile (PP). This Protection Profile describes core security requirements for a secure device that can generate a signing key4) (signature creation data, SCD) and operates to create electronic signatures with the generated key. A device evaluated according to this protection profile and used in the specified environments can be trusted to create any type of digital signature. As such, this PP can be used for any device that has been configured to create a digital signature. Specifically this PP allows the qualification of a product as a device for creating an advanced electronic signature as defined in the directive. After an SSCD has generated a signing key, the corresponding public key (signature verification data, SVD) has to be provided as input to a certificate generation application (CGA). Security requirements for export of the SVD are described in a protection profile that extends this PP (prEN 419211-4, Protection profiles for secure signature creation device — Part 4: Extension for device with key generation and trusted channel to certificate generation application)5) and not in this document. When operated in a secure environment for signature creation a signer may use an SSCD that fulfils only these core security requirements to create an advanced electronic signature.6) Security requirements for an SSCD used in environments where the communication between SSCD and the signature creation application (SCA) is assumed to be protected by the SSCD and the SCA are described in a separate protection profile that extend this PP (prEN 419211-5, Protection profiles for secure signature creation device — Part 5: Extension for device with key generation and trusted channel to signature creation application)7) and not in this document. These extended Protection Profiles claim conformance to this PP.
3) This European Directive is referred to in this PP as “the directive”. 4) An SSCD that can generate its own SCD/SVD was defined in the previous version of this PP (CWA 14169) as a Type 3 SSCD. The notion of types does not exist anymore in this series of ENs. In order to refer to the same functionality, a reference to EN 419211-2 (i.e. Part 2) should be used. 5) This document was submitted to the Enquiry procedure under reference prEN 14169-4. 6) An advanced electronic signature is defined as an electronic signature created by an SSCD using a public key with a public key certificate created as specified in the directive. 7) This document was submitted to the Enquiry procedure under reference prEN 14169-5. SIST EN 419211-2:2013

8) At a pure functional level the SSCD creates a digital signature; for an implementation of the SSCD, in that meeting the requirements of this PP and with the key certificate created as specified in the directive, Annex I, the result of the signing process can be used as to create a qualified electronic signature. SIST EN 419211-2:2013

Figure 1 - Example of TOE lifecycle9)
9) The asterisks * mark the optional import of the SVD and certificate info during TOE preparation and certificate info deletion when SCD is destroyed. SIST EN 419211-2:2013

10) Self-certification of the SVD is effectively computing an electronic signature with the corresponding SCD. A signing operation requires explicit sole signatory control, this specific case, if supported, provides an exception to this rule as, before being delivered to the signatory, such control is evidently impossible. 11) The certificate request in this case will contain the name of the signatory as the requester, as for instance it may be signed by the signatory’s existing SCD. SIST EN 419211-2:2013

Storing, copying and releasing of the signature creation data An attacker stores or copies the SCD outside the TOE. An attacker can obtain the SCD during generation, storage and use for signature creation in the TOE. 6.2.2 T.SCD_Derive
Derive the signature creation data An attacker derives the SCD from publicly known data, such as SVD corresponding to the SCD or signatures created by means of the SCD or any other data exported outside the TOE, which is a threat against the secrecy of the SCD. 6.2.3 T.Hack_Phys
Physical attacks through the TOE interfaces An attacker interacts physically with the TOE to exploit vulnerabilities, resulting in arbitrary security compromises. This threat is directed against SCD, SVD and DTBS. 6.2.4 T.SVD_Forgery Forgery of the signature verification data An attacker forges the SVD presented by the CSP to the CGA. This results in loss of SVD integrity in the certificate of the signatory. 6.2.5 T.SigF_Misuse Misuse of the signature creation function of the TOE An attacker misuses the signature creation function of the TOE to create SDO for data the signatory has not decided to sign. The TOE is subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. 6.2.6 T.DTBS_Forgery Forgery of the DTBS/R An attacker modifies the DTBS/R sent by the SCA. Thus the DTBS/R used by the TOE for signing does not match the DTBS the signatory intended to sign. 6.2.7 T.Sig_Forgery Forgery of the electronic signature An attacker forges a signed data object, maybe using an electronic signature that has been created by the TOE, and the violation of the integrity of the signed data object is not detectable by the signatory or by third parties. The signature created by the TOE is subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. 6.3 Organisational security policies 6.3.1 P.CSP_QCert
Qualified certificate The CSP uses a trustworthy CGA to generate a qualified certificate or non-qualified certificate (cf. the directive, Article 2, Clause 9, and Annex I) for the SVD generated by the SSCD. The certificates contain at least the name of the signatory and the SVD matching the SCD implemented in the TOE under sole control of the signatory. The CSP ensures that the use of the TOE as SSCD is evident with signatures through the certificate or other publicly available information. SIST EN 419211-2:2013

TOE as secure signature creation device The TOE meets the requirements for an SSCD laid down in Annex III of the directive [1]. This implies the SCD is used for digital signature creation under sole control of the signatory and the SCD can practically occur only once. 6.3.4 P.Sig_Non-Repud
Non-repudiation of signatures The lifecycle of the SSCD, the SCD and the SVD shall be implemented in a way that the signatory is not able to deny having signed data if the signature is successfully verified with the SVD contained in their unrevoked certificate. 6.4 Assumptions 6.4.1 A.CGA Trustworthy certificate generation application The CGA protects the authenticity of the signatory’s name or pseudonym and the SVD in the (qualified) certificate by an advanced electronic signature of the CSP. 6.4.2 A.SCA Trustworthy signature creation application The signatory uses only a trustworthy SCA. The SCA generates and sends the DTBS/R of the data the signatory wishes to sign in a form appropriate for signing by the TOE. 7 Security objectives 7.1 Security objectives for the TOE 7.1.1 Relation to PP SSCD KI Security objectives for the TOE in this PP, which are identically stated in the PP SSCD KI, are OT.Lifecycle_Security, OT.SCD_Secrecy, OT.Sig_Secure, OT.Sigy_SigF, OT.DTBS_Integrity_TOE, OT.EMSEC_Design, OT.Tamper_ID and OT.Tamper_Resistance (these are independent from the fact whether SCD are generated by the TOE itself or imported from the operational environment). The remaining security objectives for the TOE OT.SCD/SVD_Auth_gen, OT.SCD_Unique and OT.SCD_SVD_Corresp cover different aspects of the SCD/SVD generation by the TOE and are not present in PP SSCD KI. Instead, in PP SSCD KI the analogous security objectives for the operational environment OE.SCD/SVD_Auth_gen, OE.SCD_Unique and OE.SCD_SVD_Corresp are defined, as with key import the operational environment is responsible for the key generation.
12) It is a non-qualified advanced electronic signature if it is based on a non-qualified certificate for the SVD. SIST EN 419211-2:2013

Lifecycle security The TOE shall detect flaws during the initialisation, personalisation and operational usage. The TOE shall securely destroy the SCD on demand of the signatory. Application Note 1: The TOE may contain more than one set of SCD. There is no need to destroy the SCD in case of repeated SCD generation. The signatory shall be able to destroy the SCD stored in the SSCD, e.g. after the (qualified) certificate for the corresponding SVD has been expired. 7.1.3 OT.SCD/SVD_Auth_Gen Authorised SCD/SVD generation The TOE shall provide security features to ensure that authorised users only may invoke the generation of the SCD and the SVD. 7.1.4 OT.SCD_Unique Uniqueness of the signature creation data The TOE shall ensure the cryptographic quality of an SCD/SVD pair it creates as suitable for the advanced or qualified electronic signature. The SCD used for signature creation shall practically occur only once and shall not be reconstructable from the SVD. In that context ‘practically occur once’ means that the probability of equal SCDs is negligible. 7.1.5 OT.SCD_SVD_Corresp Correspondence between SVD and SCD The TOE shall ensure the correspondence between the SVD and the SCD generated by the TOE. This includes unambiguous reference of a created SVD/SCD pair for export of the SVD and in creating an electronic signature creation with the SCD. 7.1.6 OT.SCD_Secrecy
Secrecy of the signature creation data The secrecy of the SCD (used for signature creation) shall be reasonably assured against attacks with a high attack potential. Application Note 2: The TOE shall keep the confidentiality of the SCD at all times, in particular during SCD/SVD generation, signature creation operation, storage and secure destruction. 7.1.7 OT.Sig_Secure Cryptographic security of the electronic signature The TOE shall create digital signatures that cannot be forged without knowledge of the SCD through robust encryption techniques. The SCD shall not be reconstructable using the digital signatures or any other data exportable from the TOE. The digital signatures shall be resistant against these attacks, even when executed with a high attack potential. 7.1.8 OT.Sigy_SigF
Signature creation function for the legitimate signatory only The TOE shall provide the digital signature creation function for the legitimate signatory only and protects the SCD against the use of others. The TOE shall resist attacks with high attack potential. 7.1.9 OT.DTBS_Integrity_TOE DTBS/R integrity inside the TOE The TOE shall not alter the DTBS/R. As by definition of the DTBS/R this may consist of the DTBS themselves, this objective does not conflict with a signature creation process where the TOE hashes the provided DTBS (in part or entirely) for signature creation. SIST EN 419211-2:2013

Authenticity of the SVD The operational environment shall ensure the integrity of the SVD sent to the CGA of the CSP. The CGA verifies the correspondence between the SCD in the SSCD of the signatory and the SVD in the qualified certificate. 7.2.3 OE.CGA_QCert Generation of qualified certificates The CGA shall generate a qualified certificate that includes (amongst others): a) the name of the signatory controlling the TOE; b) the SVD matching the SCD stored in the TOE and being under sole control of the signatory; c) the advanced signature of the CSP. The CGA shall confirm with the generated qualified certificate that the SCD corresponding to the SVD is stored in a SSCD. 7.2.4 OE.SSCD_Prov_Service Authentic SSCD provided by SSCD-provisioning service The SSCD-provisioning service shall initialise and personalise for the signatory an authentic copy of the TOE and deliver this copy as SSCD to the signatory. 7.2.5 OE.HID_VAD
Protection of the VAD If an external device provides the human interface for user authentication, this device shall ensure confidentiality and integrity of the VAD as needed by the authentication method employed from import through its human interface until import through the TOE interface. In particular, if the TOE requires a trusted channel for import of the VAD, the HID shall support usage of this trusted channel. SIST EN 419211-2:2013

SCA sends data intended to be signed The signatory shall use a trustworthy SCA that:  generates the DTBS/R of the data that has been presented as DTBS and which the signatory intends to sign in a form which is appropriate for signing by the TOE;  sends the DTBS/R to the TOE and enables verification of the integrity of the DTBS/R by the TOE;  attaches the signature produced by the TOE to the data or provides it separately. Application Note 3: The SCA should be able to support advanced electronic signatures. Currently, there are three formats defined by ETSI recognised as meeting the requirements needed by advanced electronic signatures: CAdES, XAdES and PAdES. These three formats mandate to include the hash of the signer's public key certificate in the data to be signed. In order to support for the mobility of the signer, it is recommended to store the certificate info on the SSCD for use by SCA and identification of the corresponding SCD if more than one SCD is stored on the SSCD. 7.2.7 OE.DTBS_Protect
SCA protects the data intended to be signed The operational environment shall ensure that the DTBS/R cannot be altered in transit between the SCA and the TOE. In particular, if the TOE requires a trusted channel for import of the DTBS/R, the SCA shall support usage of this trusted channel. 7.2.8 OE.Signatory Security obligation of the signatory The signatory shall check that the SCD stored in the SSCD received from SSCD-provisioning service is in non-operational state. The signatory shall keep their VAD confidential. SIST EN 419211-2:2013

OT.Lifecycle_Security OT.SCD/SVD_Auth_Gen OT.SCD_Unique OT.SCD_SVD_Corresp OT.SCD_Secrecy OT.Sig_Secure OT.Sigy_SigF OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Tamper_ID OT.Tamper_Resistance OE.CGA_QCert OE.SVD_Auth OE.SSCD_Prov_Service OE.HID_VAD OE.DTBS_Intend OE.DTBS_Protect OE.Signatory T.SCD_Divulg
X
T.SCD_Derive
X
X
T.Hack_Phys
X
X X X
T.SVD_Forgery
X
X
T.SigF_Misuse X
X X
X X X X T.DTBS_Forgery
X
X X
T.Sig_Forgery
X
X
X
P.CSP_QCert X
X
X
P.QSign
X X
X
X
P.Sigy_SSCD X X X
X X X X X
X
X
P.Sig_Non-Repud X
X X X X X X X X X X X X
X X X A.CGA
X X
A.SCA
X
7.3.2 Security objectives sufficiency Countering of threats by security objectives: T.SCD_Divulg (Storing, copying and releasing of the signature creation data) addresses the threat against the legal validity of electronic signature due to storage and copying of SCD outside the TOE, as expressed in recital (18) of the directive. This threat is countered by OT.SCD_Secrecy, which assures the secrecy of the SCD used for signature creation. T.SCD_Derive (Derive the signature creation data) deals with attacks on the SCD via public known data produced by the TOE, which are the SVD and the signatures created with the SCD. OT.SCD/SVD_Auth_Gen counters this threat by implementing cryptographically secure generation of the SCD/SVD pair. OT.Sig_Secure ensures cryptographically secure electronic signatures. T.Hack_Phys (Exploitation of physical vulnerabilities) deals with physical attacks exploiting physical vulnerabilities of the TOE. OT.SCD_Secrecy preserves the secrecy of the SCD. OT.EMSEC_Design counters physical attacks through the TOE interfaces and observation of TOE emanations. OT.Tamper_ID and OT.Tamper_Resistance counter the threat T.Hack_Phys by detecting and by resisting tampering attacks. SIST EN 419211-2:2013
...