SIST EN 419241-2:2019

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vertrauenswürdige Systeme, die Serversignaturen unterstützen - Teil 2: Schutzprofil für qualifizierte Signaturerstellungseinheiten zur ServersignierungSystèmes fiables de serveur de signature électronique - Partie 2 : Profil de protection de QSCD pour la signature par serveurTrustworthy Systems Supporting Server Signing - Part 2: Protection profile for QSCD for Server Signing35.040.01Kodiranje informacij na splošnoInformation coding in general35.030Informacijska varnostIT SecurityICS:Ta slovenski standard je istoveten z:EN 419241-2:2019SIST EN 419241-2:2019en,fr,de01-maj-2019SIST EN 419241-2:2019SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419241-2
February
t r s { ICS
u wä r u r English Version
Trustworthy Systems Supporting Server Signing æ Part
tã Protection profile for QSCD for Server Signing Systèmes fiables de serveur de signature électronique æPartie
t ã Profil de protection de QSCD pour la signature par serveur
Vertrauenswürdige Systemeá die Serversignaturen unterstützen æ Teil
tã Schutzprofil für qualifizierte Signaturerstellungseinheiten zur Serversignierung This European Standard was approved by CEN on
t x November
t r s zä
egulations 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ä
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á Serbiaá Slovakiaá Sloveniaá Spainá Swedená Switzerlandá Turkey and United Kingdomä
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Rue de la Science 23,
B-1040 Brussels
t r s { CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Membersä Refä Noä EN
v s { t v sæ tã t r s { ESIST EN 419241-2:2019

Contents EUROPEAN FOREWORD . 4 INTRODUCTION . 5 1 SCOPE . 6 2 NORMATIVE REFERENCES. 6 3 TERMS, DEFINITIONS, SYMBOLS AND ABBREVIATIONS . 6 3.1 TERMS AND DEFINITIONS . 6 3.2 SYMBOLS AND ABBREVIATIONS . 7 4 INTRODUCTION . 7 4.1 GENERAL . 7 4.2 PROTECTION PROFILE REFERENCE . 7 4.3 PROTECTION PROFILE OVERVIEW . 7 4.4 TOE OVERVIEW . 7 5 CONFORMANCE CLAIM . 11 5.1 CC CONFORMANCE CLAIM . 11 5.2 PP CLAIM . 12 5.3 CONFORMANCE RATIONALE . 12 5.4 CONFORMANCE STATEMENT . 12 6 SECURITY PROBLEM DEFINITION . 12 6.1 ASSETS . 12 6.2 SUBJECTS . 14 6.3 THREATS . 15 6.4 RELATION BETWEEN THREATS AND ASSETS . 18 6.5 ORGANISATIONAL SECURITY POLICIES . 19 6.6 ASSUMPTIONS . 20 7 SECURITY OBJECTIVES . 21 7.1 GENERAL . 21 7.2 SECURITY OBJECTIVES FOR THE TOE . 21 7.3 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT . 23 7.4 SECURITY PROBLEM DEFINITION AND SECURITY OBJECTIVES . 25 7.5 RATIONALE FOR THE SECURITY OBJECTIVES . 30 8 EXTENDED COMPONENTS DEFINITIONS. 33 8.1 CLASS FCS: CRYPTOGRAPHIC SUPPORT . 33 9 SECURITY REQUIREMENTS . 34 9.1 TYPOGRAPHICAL CONVENTIONS . 34 9.2 SUBJECTS, OBJECTS AND OPERATIONS . 35 9.3 SFRS OVERVIEW . 36 9.4 SECURITY FUNCTIONAL REQUIREMENTS . 39 9.5 SECURITY ASSURANCE REQUIREMENTS . 64 SIST EN 419241-2:2019

EN 419241-1: Security Requirements for Trustworthy Systems Supporting Server Signing;
EN 419241-2: This document Further details of this series can be found in EN 419241-1. Document Structure Section 1 provides the introductory material for the Protection Profile. Section 2 describes normative references Section 3 describes terms and definitions Section 4 contains the introduction Section 5 provides the conformance claim Section 6 provides the Security Problem Definition. It presents the Assets, Threats, Organisational Security Policies and Assumptions related to the TOE. Section 7 defines the security objectives for both the TOE and the TOE environment. Section 8 contains an extended component definition to include random number generation Section 9 contains the functional requirements and assurance requirements derived from the Common Criteria (CC), Part 2 [CC2] and Part 3 [CC3] that has to be satisfied by the TOE. Section 10 provides rationales to demonstrate that:
Security Objectives satisfy the policies and threats
SFR match the security Objectives
SFR dependencies are satisfied
The SARs are appropriate. A reference section is provided to identify background material. An acronym list is provided to define frequently used acronyms. SIST EN 419241-2:2019

IEC Electropedia: available at http://www.electropedia.org/
http://www.iso.org/obp NOTE Common Criteria terms and definitions are given in [CC1]. 3.1.1 certificate certificate for electronic signature as defined in [eIDAS] article 3 3.1.2 delegated party subcontractor of the TSP or notified eID provider according to eIDAS regulation used for authentication 3.1.3 digital signature value result of a cryptographic operation involving the signing key Note 1 to entry: Within this document, Seal, Signature, Digital Signature or Digital Seal denote Digital Signature Value. 3.1.4 one-time signing key signing key created, used and disposed based on one a single authorization, typically linked to a single session signing DTBS/R(s) Note 1 to entry:
Contrary to signing keys, which may be used in several signing sessions. SIST EN 419241-2:2019

Directly by the SAM. In this case the SAM verifies the signer’s authentication factor(s).
Indirectly by the SAM. In this case, an external authentication service as part of the TW4S or a delegated party that verifies the signer’s authentication factor(s) and issues an assertion that the signer has been authenticated. The SAM shall verify the assertion.
A combination of the two direct or indirect schemes, where a part of the signer authentication is done directly by the SAM and another part is done indirectly by the SAM. In case the signer authentication is not performed directly by the SAM, the SAM has to assume (on the environment) that part of or complete authentication has taken place and rely on an assertion. In this PP signer authentication means that the signer has been authenticated in one of the three ways mentioned above. The SAM module is the TOE of this PP. The TOE and Cryptographic Module certified against EN 419221-5 is required to obtain a QSCD. The illustration below gives an overview of the environment on which the TOE is placed. The signer is located in the local environment with a user interface on device (e.g. laptop, tablet, smartphone). The user interface can display documents for the signer. The device uses a signer interaction component (SIC) to communicate with the SSA. The SSA forwards the communication from the SIC or from the SSA to the QSCD. Inside the QSCD the SAM receives the messages and optionally communicates with the SSA to obtain relevant data. When the SAM module has verified SAD, it can authorize the activation of the signing key within the Cryptographic Module and produce a digital signature value. The value is returned to the SSA and may be further delivered to the SCA or SIC. From a TOE point of view the SSA and User Interface acts as supporting modules which displays document and forwards communication messages. The TOE generates audit records for all security related events and relies on the SSA to store and provide access control for the records. The TW4S relies on other services: - Signers shall be identified and registered. It may involve establishment of authentication mechanism for a signer. - Signing keys are certified by a Certification Authority. SIST EN 419241-2:2019

Figure 1 4.4.2 TOE type The TOE is a software component, which implements the Signature Activation Protocol (SAP). It is either deployed within the tamper protected part of the Cryptographic Module or alternatively in a dedicated tamper protected environment, that is connected to the Cryptographic Module via a trusted channel. It uses the Signature Activation Data (SAD) from the signer to activate the corresponding signing key for use in a Cryptographic Module. Together the TOE and Cryptographic Module are a QSCD. 4.4.3 TOE life cycle The TOE life cycle consists of successive phase for development, production, preparation and operational use. Development: The TOE developer develops the TOE application and its guidance documentation using any appropriate guidance documentation for components working with the TOE, including the Cryptographic Module. Delivery: The TOE is securely delivered from the TOE developer to the TSP. Installation and configuration: The TSP installs and configures the TOE with the appropriate configuration and initialisation data. Installation may allow creating the Privileged Users. Operational phase: In operation, the TOE can be used by Privileged Users to create Privileged Users and Signers. Privileged Users can maintain TOE configuration. Privileged Users and Signers may generate signature keys for a Signer. Privileged Users and Signers can supply the data to be signed to the TOE, but only Signer can authorize a signature creation. SIST EN 419241-2:2019

Operator management: o Privileged Users can create other Privileged Users.
System management o Privileged Users can handle system configuration.
Signer management covers: o Privileged Users can create Signers o Privileged Users can assign one of the three authentication schemes (direct, indirect or mixed) to a Signer. o Privileged Users or Signers can generate signing keys and signature Verification Data (SVD) using a Cryptographic Module and assign the signing key identifier and SVD to a Signer. o Privileged Users or Signers can disable a signing key identifier to be used by a Signer.
Signature operation o Privileged Users or Signers can supply a DTBS/R(s) to be signed. o The link between signer authentication, DTBS/R(s) and signing key identifier is handled by the Signature Activation Data (SAD). This SAD is securely exchanged with the TOE using the Signature Activation Protocol (SAP). Within the TOE the following actions are performed: ’ The SAD is verified in integrity. ’ The SAD is verified that it binds together the Signer authentication, a DTBS/R(s) and signing key identifier. ’ The Signer identified in the SAD is authenticated using one of the three authentication schemes. ’ The DTBS/R(s) used for signature operations is bound to the SAD. ’ The signing key identifier is assigned to the Signer. ’ The TOE uses Authorization Data to activate the signing key within the Cryptographic Module. ’ The TOE uses the Cryptographic Module to create signatures.
The TOE generates audit records for all security related events and relies on the SSA to store and provide access control for the records. SIST EN 419241-2:2019

A Signature Creation Application (SCA) that manages the document to be signed and transfers that to the SSA, either directly or through the SIC.
A SSA component that handles communications between SAM in the QSCD and SIC in the signer device.
A SIC used locally by the signer to communicate with the remote systems.
A Cryptographic Module certified against EN 419221-5, which supports the operation of the TOE. 4.4.7 Options The Protection Profile includes options, which the ST writer shall specify. To assist the ST writer identifying these options, they are summarized in Table 1. Table 1 Option Description Deployment The TOE may be deployed in a Cryptographic Module or in a dedicated hardware module. The ST writer shall pay special attention to the SFRs FCS_CKM.1, FCS_CKM.4, FCS_COP.1, FCS_RNG.1, FPT_PHP.1, FPT_PHP.3 and FTP_ITC.1/CM as these SFRs may be met differently depending on the deployment. 5 Conformance Claim 5.1 CC Conformance Claim This protection profile (PP) claims to be Common Criteria Part 2 extended and Common Criteria Part 3 conformant and written according to the Common Criteria version 3.1 R4 [CC1], [CC2] and [CC3]. The assurance requirement of this Protection Profile is EAL4 augmented. Augmentation results from the selection of:
AVA_VAN.5 Advanced methodical vulnerability analysis SIST EN 419241-2:2019

The integrity and confidentiality of the signing key and the link between the R.Signing_Key_Id and the signing key is the responsibility of the Cryptographic Module. The TOE shall ensure that only the signer can use the signing key under his sole control. R.Authorisation_Data: is data used by the TOE to activate a signing key in the Cryptographic Module. The signing key is identified by R.Signing_Key_Id. It shall be protected in integrity and confidentiality. Application Note 2
The R.Authorisation_Data are used by the Cryptographic Module to activate a signing key. The data may be an asset of the TOE or derived by the TOE from the SAD. In both cases, the TOE shall verify the SAD before the R.Authorisation_Data are used to activate the signing key in the Cryptographic Module. If the TOE derives the R.Authorisation_Data from SAD then this data may not be held by the TOE. R.SVD: signature verification data are the public part, associated with the signing key, to perform digital signature verification. The R.SVD shall be protected in integrity. The TOE uses a Cryptographic Module for signing key pair generation. As part of the signing key pair generation, Cryptographic Module provides the TOE with R.Signing_Key_Id and R.SVD. The TOE provides the R.SVD to the SSA for further handling for the key pair to be certified. R.DTBS/R: set of data which is transmitted to the TOE for digital signature creation on behalf of the signer. The DTBS/R(s) is transmitted to the TOE. The R.DTBS/R shall be protected in integrity. The transmission of the DTBS/R(s) to the TOE shall require the sending party - Signer or Privileged User - to be authenticated. Application Note 3
The signer’s strong authentication as specified in EN 419241-1
If a particular key is not implied (e.g a default or one-time key) a unique reference to R.Signing_Key_Id.
A given R.DTBS/R. The R.SAD shall be protected in integrity and confidentiality. Application Note 4
If the SAD does not require encrypted data then the confidentiality requirement is considered fulfilled. The ST writer shall describe which part of the SAD shall be protected in confidentiality. Application Note 5
The R.SAD may include some or all authentication factors or evidence from other systems that some or all authentication factors have been verified. Application Note 6
The unique reference to R.Signing_Key_Id in the R.SAD could be a certificate, a key identifier or derived information obtained from the signer’s authentication. Some solutions may use one-time signing keys, which are generated, certified and used within a limited signing session. The derived information from the signer’s authentication may be used to provide session separation if a signer has multiple simultaneous signing sessions with the TOE, or to derive a R.Signing_Key_Id if the key is a one-time key. At the end of the session, the signing key is reliably deactivated. For solutions that only handle one signing key for each signer, the reference to the R.Signing_Key_Id may also be implied and omitted from the SAD. The ST writer shall describe what R.Signing_Key_Id is for a specific TOE. R.Signature: is the result of the signature operation and is a digital signature value. R.Signature is created on the R.DTBS/R using R.Signing_Key_Id by the Cryptographic Module under the signer’s control as part of the SAP. The R.Signature shall be protected in integrity. The R.Signature can be verified outside TOE using R.SVD. R.Audit: is audit records containing logs of events requiring to be audited. The logs are produced by the TOE and stored externally. The R.Audit shall be protected in integrity. R.Signer: is a TOE subject containing the set of data that uniquely identifies the signer within the TOE. The R.Signer shall be protected in integrity and confidentiality. Application Note 7
It is only within the TOE the R.Signer needs to be unique. It is not the responsibility of the TOE to establish a connection between the R.Signer and the signer’s identity. The signer is said to own the R.Signer object which uniquely identifies him within the TOE. Application Note 8
The R.Signer can include references to zero, one or several R.Signing_Key_Ids and R.SVDs. Application Note 9
The R.Reference_Signer_Authentication_Data are used by the TOE to authenticate the signer, and the R.Authorisation_Data are used by the TOE to activate a signing key in the Cryptographic Module. Application Note 11
If the R.Reference_Signer_Authentication_Data does not require encrypted data then the confidentiality requirement is considered fulfilled. The ST writer shall describe which part of the R.Reference_Signer_Authentication_Data shall be protected in confidentiality. R.TSF_DATA: is the set of TOE configuration data used to operate the TOE. It shall be protected in integrity. Application Note 12
The TOE configuration data could include cryptographic algorithm, key length, flows for SAP etc. R.Privileged_User is a TOE subject containing the set of data that uniquely identifies a Privileged User within the TOE. It shall be protected in integrity. R.Reference_Privileged_User_Authentication_Data is the set of data used by the TOE to authenticate the Privileged User. It shall be protected in integrity and confidentiality. Application Note 13
If the R.Reference_Privileged_User_Authentication_Data does not require encrypted data then the confidentiality requirement is considered fulfilled. The ST writer shall describe which part of the R.Reference_Privileged_User_Authentication_Data shall be protected in confidentiality. R.Random is random secrets, e.g. keys, used by the TOE to operate and communicate with external parties. It shall be protected in integrity and confidentiality. 6.2 Subjects This following list of subjects interact with the TOE.
Signer, which is the natural or legal person who uses the TOE through the SAP where he provides the SAD and can sign DTBS/R(s) using his signing key in the Cryptographic Module.
Privileged User, which performs the administrative functions of the TOE and is able to provide a DTBS/R(s) to the TOE as part of the signature operation. Application Note 14
The list of subjects described in EN 419241-1:2018, 6.2.1.2 SRG M.1.2 contains more roles as it covers the whole T4WS. The ST writer shall describe the specific roles it implements and how these relate to authorization rules in the SFRs. SIST EN 419241-2:2019

The SSA plays a special role as it interacts directly with the TOE. Privileged Users can interact with the TOE directly or via the SSA. If the SSA as a service can perform administrative functions, e.g. creating signer, this is in this PP considered as Privileged User. Application Note 16
The creation of signers, management of reference signer authentication data and signing key generation is expected to be carried out together with a registration authority (RA) providing a registration service using the SSA, as specified in e.g. [ETSI EN 319 411-1]. 6.3 Threats 6.3.1 General The following threats are defined for the TOE. An attacker described in each of the threats is a subject that is not authorized for the relevant operation, but may present himself as an unknown user or as one of the other defined subjects. 6.3.2 Enrolment The threats during enrolment are: T.ENROLMENT_SIGNER_IMPERSONATION An attacker impersonates signer during enrolment. As examples, it could be:
by transferring wrong R.Signer to TOE from RA
by transferring wrong R.Reference_Signer_Authentication_Data to TOE from RA The assets R.Signer and R.Reference_Signer_Authentication_Data are threatened. Such impersonation may allow a potential incorrect signer authentication leading to unauthorised signature operation on behalf of signer. T.ENROLMENT_SIGNER_AUTHENTICATION_DATA_DISCLOSED An attacker is able to obtain whole or part of R.Reference_Signer_Authentication_Data during enrolment. This can be during generation, storage or transfer to the TOE or transfer between signer and TOE. As examples it could be:
by reading the data
by changing the data, e.g. to a known value The asset R.Reference_Signer_Authentication_Data are threatened. Such data disclosure may allow a potential incorrect signer authentication leading to unauthorised signature operation on behalf of signer. The threats on enrolment are threats on the environment in case external authentication is supported by the TOE. T.SVD_FORGERY An attacker modifies the R.SVD during transmission to the RA or CA. This results in loss of R.SVD integrity in the binding of R.SVD to signing key and to R.Signer. The asset R.SVD is threatened. If the CA relies on the generation of the key pair controlled by the TOE as specified in [ETSI EN 319 411-1] 6.3.3 d) then an attacker can forge signatures masquerading as the signer. SIST EN 419241-2:2019

There should be a secure transport of R.SVD from TOE to RA or CA. The SAM is expected to produce a CSR. If the registration services of the TSP issuing the certificate requires a “proof of possession or control of the private key” associated with the SVD, as specified in [ETSI EN 319 411-1] Clause 6.3.1 a), this threat can be countered without any specific measures within the TOE. 6.3.3 Signer Management T.ADMIN_IMPERSONATION Attacker impersonates a Privileged User and updates R.Reference_Signer_Authentication_Data, R.Signing_Key_Id or R.SVD. The assets R.Reference_Signer_Authentication_Data, R.SVD and R.Signing_Key_Id are threatened. Such data modification may allow a potential incorrect signer authentication leading to unauthorised signature operation on behalf of signer. T.MAINTENANCE_AUTHENTICATION_DISCLOSE Attacker discloses or changes (e.g. to a known value) R.Reference_Signer_Authentication_Data during update and is able to create a signature. The assets R.Reference_Signer_Authentication_Data and R.Signing_Key_Id are threatened. Such data disclosure may allow a potential incorrect signer authentication leading to unauthorised signature operation on behalf of signer. 6.3.4 Usage This section describes threats for signature operation including authentication. T.AUTHENTICATION_SIGNER_IMPERSONATION An attacker impersonates signer using forged R.Reference_Signer_Authentication_Data and transmits it to the TOE during SAP and uses it to sign the same or modified DTBS/R(s). The assets R.Reference_Signer_Authentication_Data, R.SAD and R.Signing_Key_Id are threatened. T.SIGNER_AUTHENTICATION_DATA_MODIFIED An attacker is able to modify R.Reference_Signer_Authentication_Data inside the TOE or during maintenance. The asset R.Reference_Signer_Authentification_Data are threatened. Such data modification may allow a potential incorrect signer authentication leading to unauthorised signature operation on behalf of signer. T.SAP_BYPASS An attacker bypasses one or more steps in the SAP and is able to create a signature without the signer having authorized the operation. The asset R.SAD is threatened. T.SAP_REPLAY An attacker replays one or more steps of SAP and is able to create a signature without the signer having authorized the operation. The asset R.SAD is threatened. T.SAD_FORGERY SIST EN 419241-2:2019

The modification of a signature can be detected by the SSA or any relying party by validation of the signature. 6.3.5 System T.PRIVILEGED_USER_INSERTION An attacker is able to create R.Privileged_User including R.Reference_Privileged_User_Authentication_Data and is able to log on to the TOE as a Privileged User. The assets R.Privileged_User and R.Reference_Privileged_User_Authentication_Data are threatened. T.REFERENCE_PRIVILEGED_USER_AUTHENTICATION_DATA_MODIFICATION An attacker modifies R.Reference_Privileged_User_Authentication_Data and is able to log on to the TOE as the Privileged User. The asset R.Reference_Privileged_User_Authentication_Data are threatened. T.AUTHORISATION_DATA_UPDATE Attacker impersonates Privileged User and updates R.Authorisation_Data and may be able to activate a signing key. The assets R.Authorisation_Data and R.Signing_Key_Id are threatened. Application Note 19
In some applications, it may be sufficient for an attacker with access to R.Authorisation_Data and R.Signing_Key_Id to activate the signing key within the Cryptographic Module. Since the R.Signing_Key_Id is only to be protected in integrity and not in confidentiality, access to R.Authorisation_Data should only be allowed for authorized operators. T. AUTHORISATION_DATA _DISCLOSE Attacker discloses R.Authorisation_Data during update and is able to activate a signing key. The assets R.Authorisation_Data and R.Signing_Key_Id are threatened. SIST EN 419241-2:2019

T.AUTHENTICATION_SIGNER_IMPERSONATION T.CONTEXT_ALTERATION T.AUDIT_ALTERATION T.SAP_BYPASS T.SAP_REPLAY T.SAD_FORGERY Confidentiality T.AUTHENTICATION_SIGNER_IMPERSONATION T.DTBSR_FORGERY T.CONTEXT_ALTERATION R.Signature Integrity T.SIGNATURE_FORGERY SIST EN 419241-2:2019

For cryptographic algorithms within the European Union this is as indicated in [eIDAS] and an exemplary list of algorithms and parameters is given in [ETSI TS 119 312] or [SOGIS]. 6.6 Assumptions A.PRIVILEGED_USER It is assumed that all personnel administering the TOE are trusted, competent and possesses the resources and skills required for his tasks and is trained to conduct the activities he is responsible for. A.SIGNER_ENROLMENT The signer shall be enrolled and certificates managed in conformance with the regulations given in [eIDAS]. Guidance for how to implement an enrolment and certificate management system in conformance with [eIDAS] are given in e.g. [EN 319 411-1] or for qualified certificate in e.g. [EN 319 411-2]. A.SIGNER_AUTHENTICATION_DATA_PROTECTION I
...