Sie sind auf Seite 1von 46

BS EN 419241‑1:2018

BSI Standards Publication

Trustworthy Systems Supporting Server Signing


Part 1: General System Security Requirements
BS EN 419241‑1:2018 BRITISH STANDARD

National foreword
This British Standard is the UK implementation of EN 419241‑1:2018. It
supersedes PD CEN/TS 419241:2014, which is withdrawn.
The UK participation in its preparation was entrusted to Technical
Committee IST/17, Cards and security devices for personal identi fication.
A list of organizations represented on this committee can be obtained on
request to its secretary.
This publication does not purport to include all the necessary provisions
of a contract. Users are responsible for its correct application.
© The British Standards Institution 2018
Published by BSI Standards Limited 2018
ISBN 978 0 580 95733 8
ICS 35.030; 35.240.99
Compliance with a British Standard cannot confer immunity from
legal obligations.
This British Standard was published under the authority of the
Standards Policy and Strategy Committee on 31 July 2018.

Amendments/corrigenda issued since publication


Date Text affected
BS EN 419241‑1:2018

EUROPEAN STANDARD EN 419241-1


NORME EUROPÉENNE
EUROPÄISCHE NORM July 2018

ICS 35.030 Supersedes CEN/TS 419241:2014

English Version

Trustworthy Systems Supporting Server Signing - Part 1:


General System Security Requirements
Systèmes fiables de serveur de signature électronique - Vertrauenswürdige Systeme, die Serversignaturen
Partie 1: Exigences de sécurité générales du système unterstützen - Teil 1: Allgemeine
Systemsicherheitsanforderungen

This European Standard was approved by CEN on 30 April 2018.

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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION


C O M I TÉ E URO P É E N D E N O RM ALI S ATI O N
E U RO P ÄI S C H E S KO M I T E E F Ü R N O RM U N G

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels

© 2018 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 419241-1:2018 E
worldwide for CEN national Members.
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Contents Page

European foreword ....................................................................................................................................................... 4


Introduction .................................................................................................................................................................... 6
1 Scope .................................................................................................................................................................... 7
1.1 General ................................................................................................................................................................ 7
1.2 Outside of the scope ....................................................................................................................................... 7
1.3 Audience ............................................................................................................................................................. 7
2 Normative references .................................................................................................................................... 8
3 Terms and definitions ................................................................................................................................... 8
4 Symbols and abbreviations ...................................................................................................................... 10
5 Description of trustworthy systems supporting server signing ................................................. 11
5.1 General ............................................................................................................................................................. 11
5.2 Signature creation and server signing objectives ............................................................................ 11
5.3 Signature bound to a natural person or seal bound to a legal person ...................................... 11
5.4 Sole control assurance levels ................................................................................................................... 11
5.5 Batch server signing .................................................................................................................................... 12
5.6 Signing key and cryptographic module ................................................................................................ 12
5.7 Signer's authentication .............................................................................................................................. 12
5.7.1 Electronic identification means .............................................................................................................. 12
5.7.2 Authentication Mechanism ....................................................................................................................... 12
5.7.3 Authentication target ................................................................................................................................. 13
5.7.4 Delegation of authentication to an external party ........................................................................... 13
5.8 Signature activation data .......................................................................................................................... 14
5.9 Signature activation protocol .................................................................................................................. 14
5.10 Signer’s interaction component.............................................................................................................. 14
5.11 Signature activation module .................................................................................................................... 15
5.12 Environments ................................................................................................................................................ 15
5.12.1 Tamper protected environment ............................................................................................................. 15
5.12.2 TSP protected environment ..................................................................................................................... 15
5.12.3 Signer’s environment.................................................................................................................................. 16
5.13 Functional model.......................................................................................................................................... 16
5.13.1 General ............................................................................................................................................................. 16
5.13.2 Scope of requirements ............................................................................................................................... 16
5.13.3 Signature activation mechanisms .......................................................................................................... 17
5.13.4 TW4S components ....................................................................................................................................... 19
6 Security requirements ............................................................................................................................... 20
6.1 General ............................................................................................................................................................. 20
6.2 General security requirements (SRG) .................................................................................................. 20
6.2.1 Management (SRG_M) ................................................................................................................................. 20
6.2.2 Systems and operations (SRG_SO).......................................................................................................... 22
6.2.3 Identification and authentication (SRG_IA) ........................................................................................ 22
6.2.4 System access control (SRG_SA) .............................................................................................................. 23
6.2.5 Key management (SRG_KM) ..................................................................................................................... 23
6.2.6 Auditing (SRG_AA)........................................................................................................................................ 26
6.2.7 Archiving (SRG_AR) ..................................................................................................................................... 28

2
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.8 Backup and recovery (SRG_BK) ............................................................................................................... 28


6.3 Core components security requirements (SRC) ................................................................................ 29
6.3.1 Signing key setup (SRC_SKS) - Cryptographic key (SRC_ SKS.1) ................................................... 29
6.3.2 Signer authentication (SRC_SA) ............................................................................................................... 29
6.3.3 Digital signature creation (SRC_DSC) - Cryptographic operation (SRC_DSC.1) ...................... 30
6.4 Additional security requirements for SCAL2 (SRA) ......................................................................... 30
6.4.1 General ............................................................................................................................................................. 30
6.4.2 Signature activation protocol and signature activation data (SRA_SAP) ................................. 30
6.4.3 Signing key management (SRA_SKM) .................................................................................................... 32
Annex A (normative) Requirements for electronic identification means, characteristics and
design ................................................................................................................................................................ 34
A.1 Enrolment........................................................................................................................................................ 34
A.1.1 Application and registration .................................................................................................................... 34
A.1.2 Identity proofing and verification (natural person) ........................................................................ 34
A.1.3 Identity proofing and verification (legal person) ............................................................................. 37
A.1.4 Binding between the electronic identification means of natural and legal persons ........... 39
A.2 Electronic identification means and authentication ....................................................................... 40
A.2.1 Electronic identification means characteristics and design ......................................................... 40
A.2.2 Authentication mechanism ....................................................................................................................... 41
Bibliography ................................................................................................................................................................. 42

3
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

European foreword
This document (EN 419241-1:2018) has been prepared by Technical Committee CEN/TC 224 “Personal
identification, electronic signature and cards and their related systems and operations”, the secretariat
of which is held by AFNOR.

This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by January 2019, and conflicting national standards shall
be withdrawn at the latest by January 2019.

Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.

This document supersedes CEN/TS 419241:2014.

This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.

Successful implementation of European Regulation No 910/2014 on electronic identification and trust


services for electronic transactions in the internal market (referred in this document as the eIDAS [4]
Regulation), requires standards for services, processes, systems and products related to trust services
as well as guidance for conformity assessment of such services, processes, systems and products.

In line with Standardization Mandate 460, consequently issued by the Commission to CEN, CENELEC
and ETSI for updating the existing eSignature standardization deliverables, CEN and ETSI have set up
the eSignature Coordination Group in order to coordinate the activities achieved for Mandate 460. One
of the first tasks was to establish a rationalized framework, the second phase to deliver a set of
standards in order to cover the Trust Services defined in the eIDAS [4] Regulation.

This document, being part of the set of European Standards, is aimed to meet the requirements of the
eIDAS [4] Regulation for remote use of a signature creation device by a set of security requirements for
a server-side system using private signing keys managed by a trust service provider in order to create
digital signatures.

The purpose of the trustworthy system is to create a digital signature under sole control of a natural
person, or under control of a legal person which may be incorporated into an electronic signature or an
electronic seal as defined in the eIDAS [4] Regulation.

This standard is identified as EN 419241-1. A complete framework for standardization of signatures can
be found in ETSI TR 119 000.

This series of European Standards consists of the following parts under the general title Trustworthy
Systems Supporting Server Signing :
— Part 1: General System Security Requirements
— Part 2: Protection Profile for QSCD for Server Signing

4
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.

5
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Introduction
The European Regulation eIDAS establishes a legal framework of requirements for electronic
signatures. This regulation also introduces the notion of electronic signatures which are created using a
remote signature creation device to increase usage in the light of its multiple economic benefits and
ease of use. The eIDAS [4] Regulation also introduces the concept of electronic seal which has similar
technical properties to electronic signatures, but with a lower level of sole control. Both electronic
signatures and electronic seals use technology based around asymmetric cryptography commonly
referred to as digital signatures.
However, in order to ensure that such remotely created digital signatures receive the same legal
recognition as digital signatures created in an entirely user-managed environment (e.g. using smart
cards), remote signature services providers should apply specific management and administrative
security procedures, and use reliable systems and products, including secure electronic communication
channels, in order to guarantee that the server signing environment is reliable and that signing keys are
used with a high level of confidence, under the sole control of the signer.
The main objective of this standard is to define requirements and recommendations for a networked
signing server which may manage signing keys used by natural or legal persons for the creation of
digital signatures.
This part of the series of European Standards specifies the general requirements of systems for server
signing. Additional specifications (e.g. protection profiles) may be issued which provide more detailed
requirements for particular components of the system.
It is assumed that the Trust Service Provider (TSP) which provides signature creation services, operates
the trustworthy system in an environment with a security policy which incorporates general physical,
personnel, procedural and documentation security requirements for TSPs providing signature creation
services.
It is recommended to follow, e.g. ETSI EN 319 401 to ensure that the above requirements are met.
The present standard does not aim at limiting the legal form of signatures created; it could be electronic
signature or electronic seals, qualified or not.
Correspondence and comments to this Security Requirements for Trustworthy Systems Supporting
Server Signing should be referred to:
Editor: Franck Leroy
Email: franck.leroy@docapost.fr

6
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

1 Scope
1.1 General
This document specifies security requirements and recommendations for Trustworthy Systems
Supporting Server Signing (TW4S) that generate digital signatures.
The TW4S is composed at least of one Server Signing Application (SSA) and one Signature Creation
Device (SCDev) or one remote Signature Creation Device.
A remote SCDev is a SCDev extended with remote control provided by a Signature Activation Module
(SAM) executed in a tamper protected environment. This module uses the Signature Activation Data
(SAD), collected through a Signature Activation Protocol (SAP), in order to guarantee with a high level
of confidence that the signing keys are used under sole control of the signer.
The SSA uses a SCDev or a remote SCDev in order to generate, maintain and use the signing keys under
the sole control of their authorized signer. Signing key import from CAs is out of scope.
So when the SSA uses a remote SCDev, the authorized signer remotely controls the signing key with a
high level of confidence.
A TW4S is intended to deliver to the signer or to some other application, a digital signature created
based on the data to be signed.
This standard:
— provides commonly recognized functional models of TW4S;

— specifies overall requirements that apply across all of the services identified in the functional
model;

— specifies security requirements for each of the services identified in the TW4S;

— specifies security requirements for sensitive system components which may be used by the TW4S.

This standard is technology and protocol neutral and focuses on security requirements.
1.2 Outside of the scope
The following aspects are considered outside of the scope of this document:
— other trusted services that may be used alongside this service such as certificate issuance, signature
validation service, time-stamping service and information preservation service;

— any application or system outside of the TW4S (in particular the signature creation application
including the creation of advanced signature formats);

— signing key and signing certificate import from CAs;

— the legal interpretation of the form of signature (e.g. electronic signature, electronic seal, qualified
or otherwise).

1.3 Audience
This standard specifies security requirements that are intended to be followed by:
— providers of TW4S systems;

— Trust Service Providers (TSP) offering a signature creation service.

7
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 15408 (all parts), Information technology — Security techniques — Evaluation criteria for IT
security
ISO/IEC 19790, Information technology — Security techniques — Security requirements for
cryptographic modules
FIPS PUB 140-2, Security requirements for cryptographic modules

3 Terms and definitions


For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
authentication
provision of assurance in the identity of an entity

[SOURCE: ISO/IEC 18014-2:2009]

3.2
authentication Factor
piece of information and/or process used to authenticate or verify the identity of an entity

[SOURCE: ISO/IEC 19790:2012]

3.3
data to be signed representation
data formatted which is used to compute the digital signature value (e.g. hash value)

[SOURCE: ETSI/TR 119 001:2016]

3.4
digital signature
data unit appended to, or a cryptographic transformation of a data that allows a recipient of the data
unit to prove the source and integrity of the data unit and protect against forgery e.g. by the recipient

[SOURCE: ETSI/TR 119 001:2016]

3.5
eIDAS Regulation
Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic
identification and trust services for electronic transactions in the internal market and repealing
Directive 1999/93/EC

8
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

3.6
remote signature creation device
signature creation device used remotely from signer perspective and applying the signature activation
protocol to provide control of signing operation on its behalf and guarantees with a high level of
confidence that the signing keys are used under sole control of the signer

3.7
signature activation data
set of data, which is collected by the SAP, used to control with a high level of confidence a given
signature operation, performed by a cryptographic module on behalf of the signer, that this under sole
control of the signer

Note 1 to entry: SAD can be a result of cryptographic operations (see details in 5.8).

3.8
signature activation module
configured software that uses the SAD in order to guarantee with a high level of confidence that the
signing keys are used under sole control of the signer

3.9
signature activation protocol
protocol that collects the SAD used to control a signature operation on a (set of) DTBS/R, using the
signing key of the signer

3.10
signature creation application
application that creates a signed document, using the digital signature generated by a SCDev

3.11
signature creation sevice
configured software and/or hardware cryptographic module used to create a digital signature

3.12
signature policy
signature creation policy, signature augmentation policy, signature validation policy or any
combination thereof, applicable to the same signature or set of signatures

[SOURCE: ETSI/TS 119 001:2016]

3.13
signer
entity (natural or legal person) being the creator of a digital signature

[SOURCE: ETSI/TR 119 001:2016]

3.14
signer’s interaction component
software and/or hardware component used by the signer to support the SAP

3.15
signing key
private key of an asymmetric cryptographic key pair used to create a digital signature

9
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

3.16
trust service provider
natural or a legal person who provides one or more trust services

[SOURCE: ETSI/TS 119 001:2016]

3.17
trustworthy system supporting server signing
client-server system using signing keys under control of the signer, in order to create digital signatures

4 Symbols and abbreviations

CA Certificate Authority

CC Common Criteria, ISO/IEC 15408, Evaluation criteria for IT security

CEN Comité Européen de Normalization (European Committee for Standardization)

DTBS/R Data To Be Signed Representation

EAL Evaluation Assurance Level

ETSI European Telecommunications Standards Institute

ISO/IEC International Organization for Standardization / International Electrotechnical Commission

ISSS Information Society Standardization System

QSCD Qualified Electronic Signature (or Electronic Seal) creation device as defined in the eIDAS
Regulation

RA Registration Authority

SAD Signature Activation Data

SAM Signature Activation Module

SAP Signature Activation Protocol

SCA Signature Creation Application

SCAL Sole Control Assurance Level

SCDev Signature Creation Device

SIC Signer’s Interaction Component

SSA Server Signing Application

TSP Trust Service Provider

TW4S Trustworthy System Supporting Server Signing

10
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

5 Description of trustworthy systems supporting server signing


5.1 General
This clause describes the different concepts of server signing in order to clarify how the security
requirements found in Clause 6 should be implemented.
All the requirements of this standard are clearly stated and can be:
— mandatory (indicated by SHALL (NOT));
— optional (indicated by SHOULD (NOT));
— permitted (indicated by MAY (NOT)).
5.2 Signature creation and server signing objectives
The purpose of the TW4S is to take Data To Be Signed Representation (DTBS/R) and create a digital
signature under signer control.
5.3 Signature bound to a natural person or seal bound to a legal person
The digital signature can be used to represent an electronic signature or an electronic seal.
The level of confidence of the control of the signing key is not necessarily expected to be the same if the
digital signature represent a seal as when used to represent a signature.
The digital signature created in compliance with this standard can be created under control of a natural
or legal person.
The term signer is used for convenience in this standard to cover a natural or legal person.
The term SCDev is used for convenience in this standard to cover a signature creation device or a seal
creation device.
5.4 Sole control assurance levels
Two assurance levels for sole control are identified in the present document:
— Sole control assurance level 1 (SCAL1):
— The signing keys are used, with a low level of confidence, under the sole control of the signer.
— The authorized signer’s use of its key for signing is enforced by the SSA which authenticates the
signer.
NOTE 1 It is not expected that such implementations would meet the requirements of sole control as it would
be expected for a stand-alone QSCD as defined in the eIDAS [4] Regulation.

— Sole control assurance level 2 (SCAL2):


— The signing keys are used, with a high level of confidence, under the sole control of the signer.
— The authorized signer’s use of its key for signing is enforced by the SAM by means of SAD
provided, by the signer, using the SAP, in order to enable the use of the corresponding signing
key.
NOTE 2 The protocol is aimed to achieve the same sole control assurance level as what would be achieved by a
stand-alone QSCD as defined in the eIDAS [4] Regulation.

The decision to use sole control assurance level 1 or 2 depends on the signature policy and the
applicable legal requirements.

11
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

5.5 Batch server signing


In some EU Member States it is possible to sign a batch of documents, without requiring the signer to
inspect and explicitly approve each document, or to have an opportunity to inspect them before signing,
such as giving links to the documents in the batch rather than passing each document for inspection and
approval.
This means that the signer has only to apply sole controls to the signing process for a batch rather than
each individual document.
Some EU Member States do not allow batch signing. In this case, it is to be ascertained if this prohibition
blindly applies to any kind of advanced electronic signatures or solely to qualified ones.
As the legal applicability of batch signing depends on the legal and application environment, the TW4S
SHOULD have configuration profiles to allow or disallow batch signing for digital signatures.
5.6 Signing key and cryptographic module
To generate a digital signature at SCAL1 and to guarantee high flexibility, the signing key (e.g. private
key of asymmetric keys pair) does not necessarily have to be generated, stored and used inside a
cryptographic module (e.g. hardware security device or smart card). The signing key could also be
stored in a file, and the SCDev can be software using that file.
When using files, specific external security measures SHOULD be implemented in addition to protecting
the files themselves from tampering (deletion, modification).
Nevertheless this standard recommends that the TW4S uses signing keys protected by a tamper
protected environment in order to create digital signatures. That is the SCDev SHOULD be a
cryptographic module (e.g. hardware security devices conforming to the EN 419211 series or
CEN/TS 419221 series).
5.7 Signer's authentication
5.7.1 Electronic identification means
5.7.1.1 SCAL1

The enrolment of the signer and the electronic identification means characteristics and design
requirements are defined in SRC_SA.1.1 .
5.7.1.2 SCAL2

The enrolment of the signer and the electronic identification means characteristics and design
requirements are defined in SRA_SAP.1.1 .
5.7.2 Authentication Mechanism
5.7.2.1 SCAL1

The authentication mechanism requirements are defined in SRC_SA.1.1 .


5.7.2.2 SCAL2

The authentication mechanism requirements are defined in SRA_SAP.1.1 .

12
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

5.7.3 Authentication target


5.7.3.1 SCAL1

— The signer SHALL be successfully authenticated to the SSA in order to grant access to the signature
operation, and

— the signer's signing key SHALL be linked by the SSA to the authentication factor of the signer.

5.7.3.2 SCAL2

— The SAD SHALL be set, computed or be the result of a secured interaction between the SAM and the
SIC through the SSA, to authorize the signing operation within the SCDev, and

— the SAD SHALL be transmitted to the SAM through the SSA to authorize the signing operation
within the SCDev for a dedicated DTBS/R.

5.7.4 Delegation of authentication to an external party


5.7.4.1 General

The TSP MAY delegate the authentication process to an external party (e.g. to an identity provider).
5.7.4.2 SCAL1

The TSP SHALL ensure that the authentication process delegated to the external party meets the
requirements specified in SRC_SA.1.1 .
NOTE If the external party uses an electronic identification means issued under a notified scheme that is
included in the list published by the Commission pursuant to Article 9 of the eIDAS [4] Regulation, there is no
need to demonstrate the conformance to the required level, conformance to the regulatory requirements can be
assumed.

5.7.4.3 SCAL2

The TSP SHALL ensure that the authentication process delegated to the external party meets the
requirements specified in SRA_SAP.1.1 .
The TSP SHALL ensure that:
— the external party fulfils all the relevant requirements of this standard and the requirements for
registration according to the applicable regulatory requirements, or

NOTE 1 In the context of the European Union, the applicable regulatory requirements are defined in
REGULATION (EU) No 910/2014 [4] .

— the authentication process delegated to the external party uses an electronic identification means
issued under a notified scheme in accordance with the applicable regulatory requirements.

NOTE 2 In the context of the European Union, the list of electronic identification means, issued under
notified schemes, is published by the European Commission pursuant to Article 9 of REGULATION (EU) No
910/2014 [4] .

13
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

5.8 Signature activation data


To reach the SCAL2, the use of the SAD to ensure control over the signer’s key SHALL be enforced by the
SAM.
Signature activation at SCAL2 requires fulfilment of several conditions as signer authentication and
authenticity of signature operation request from the signer (details are given in 5.7).
Both properties MAY be given directly by the SAD. It is however for instance also possible to perform
signer authentication prior to SAD generation, e.g. using delegation of authentication.
SAD can be a set of data or be a result of cryptographic operations (details are given in SRA_SAP.2 )
from which the same information can be derived.
SAD contributes to authenticate directly or indirectly the signer.
When the signer authentication takes place prior to collection of the SAD, the SAD SHALL contain items
to identify the signer asserted by a known source. This assertion MAY come from either the SIC or from
a trusted electronic identity provider. The source of the assertion SHALL be authenticated.
5.9 Signature activation protocol
The SAP SHALL be designed to allow secure use of the signing key for the creation of a digital signature
to be performed by the cryptographic module on behalf of a signer.
The SAP is a protocol where the signer (via the SIC) and the TW4S communicate in order to generate
the SAD.
The design of the SAP SHALL include as a minimum the following verifications:
— signer authentication when using the signing key,

— authenticity of the signature request with specific SAD,

— the selected signing key is valid and active,

— secure transfer of all the elements of the SAD.

When the signing key is not used to sign a proof of possession in order to obtain a certificate, the SAP
SHOULD include the following verification:
— presence of valid certificate associated to signing key.

5.10 Signer’s interaction component


The SIC is a piece of software and/or hardware, operated on the signer’s environment under its sole
control.
Using this component is essential in the SAP process and for the creation of a digital signature by the
SCDev.
The SIC always participates in the SAP in order to authenticate the signer or to generate the SAD:
— the SIC can directly generate the SAD, or

— the SIC can be used to authenticate the signer, and the assertion that identify the signer will be used
in the SAD generation.

14
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

This component can be for example (or a combination of):


— an application executed by a browser (e.g. a form HTTP POST over TLS),

— an application executed by a mobile device (e.g. smartphone, tablet),

— a secure element of a cell-phone (e.g. sim-card that receives SMS),

— a cryptographic device owned by the signer (e.g. eID token, eToken, FIDO-Token),

— […]

The SIC enforces the link between the signer and the signature operation within the SAP.
5.11 Signature activation module
The SAM is a software that uses the SAD in order to guarantee with a high level of confidence that the
signing keys are used under sole control of the signer for SCAL2.
The SAM is required to be used in a tamper protected environment.
If the SAM is not used in the same tamper protected environment as the SCDev, then a secure channel
between both tamper protected environments is required.
5.12 Environments
NOTE Three different environments are defined.

5.12.1 Tamper protected environment

The tamper protected environment is operated within the TSP protected environment and shielded
from direct internet access. It ensures integrity of the code executed within this environment.
The code protects the use of signing keys and enforces signature activation to be under the signer
control.
The tamper protected environment also protects link(s) between signing key(s) and signer(s) (link is
created and checked when needed for a signature creation).
For SCAL1 private or secret keys are recommended to be generated and used in a tamper protected
environment.
For SCAL2 private or secret keys are required to be generated and used in a tamper protected
environment. In addition the software of the SAM is also required to be used in a tamper protected
environment.
5.12.2 TSP protected environment

The TSP protected environment is audited according to the requirements for secure operation of the
server signing system.
It protects against attacks from the internet and handles internet connections to/from the external
environments (e.g. signer, SCA, RA).
This environment can store in a protected form, signing key(s) and link(s) between key(s) and
signer(s).
The TSP protects this environment in order to meet SAD and SAP requirements and place obligations on
the RA environment (regarding enrolment). Specifications are given in ETSI EN 319 411-1:2015, 6.2.2
and ETSI EN 319 411-2:2015, 6.2.2, for example.

15
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

It should also meet the requirements for certificate enrolment to demonstrate sole control (needed by
the RA). These requirements are specified in ETSI EN 319 411-1:2015, 6.3.1 a and 6.3.3 d for example.
5.12.3 Signer’s environment

The signer’s environment is local to the signer.


The signer is responsible to protect its environment. When the signer uses an environment provided by
a third party, then the third party is responsible of the protection of the signer’s environment.
The signer environment consists of general elements may be used to prepare the document to be signed
and format the document signature, as well as the SIC.
A SIC is used by the signer to create a link between the signer and the whole signature operation
activated through the SAP.
There is no direct certification requirement on the SIC with regard to this standard. However, on the
design and implementation of the SIC, it is necessary to take into account requirements on the
transmission/computation of SAD and the interaction of the SIC with the SAM via the SAP, including
authentication of the signer.
5.13 Functional model
5.13.1 General

This clause presents a conceptual architecture of a TW4S in order to present its scopes, its components
and its activation mechanisms.
It does not represent any physical architecture, which in practice will use for example, multiple servers
and devices for load sharing or redundancy.
The signer’s environment is unknown to the TW4S. It should be protected, e.g. by installing trusted
software only and by using protection against malicious software.
The TSP providing signature creation services protects the TW4S’s environment. The TW4S is operated
with a security policy which incorporates general physical, personnel, procedural and documentation
security requirements and any specific requirements for TSPs providing signature creation services.
A definition of the requirements can be found in ETSI EN 319 401, for example.
For SCAL2, the signing key(s) and the SAM are protected by a tamper protected environment (e.g.
cryptographic module conforming to the EN 419211 series or CEN/TS 419221 series).
5.13.2 Scope of requirements

A TW4S provides secure remote management of signer's signing key and creation of digital signatures
by means of such a remotely managed signing key.
This standard does not place any restriction on how the server and signer systems MAY be broken up
into one or more components. The signature creation application (SCA) is out of scope (see Figure 1) of
this standard and requirements for trustworthy systems for TSP relating to certificate issuance is
outside scope (see CEN/TS 419261).

16
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Figure 1 — Scope of requirements

NOTE The scope of requirements may be extended to an external party when using delegation of
authentication (see 5.7.4).

5.13.3 Signature activation mechanisms


5.13.3.1 General

This clause presents some suggested models for signature activation in order to create a digital
signature. Any other architecture compliant with Clause 6 MAY be implemented.
TW4S is typically used by a set of signers, each signer owning one or several signing keys and TW4S can
include one or several SCDev to perform signature operations.
The signing key can be securely stored outside the SCDev and loaded dynamically, provided that
controls apply to ensure the same security on the signing key. Key loading/unloading mechanisms to be
employed for protecting signing keys are outside the scope of this standard.
5.13.3.2 Signature activation for SCAL1

Signing key confidentiality and integrity are ensured by the SCDev. The SCDev can be activated by the
SSA. The activation can remain for a given period and/or for a given number of signatures.
The signing key activation requires that the signer has been authenticated by the SSA (see Figure 2).
When the signer authentication succeeds, the corresponding signing key MAY be used for signature
operation on behalf of signer within a certain time frame and/or a certain amount of signature
operations. This allows the SSA to be used for bulk/batch signature purposes.

17
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Figure 2 —Signature activation system with SCAL1

NOTE This architecture may be extended to an external party when using delegation of authentication (see
5.7.4).

This architecture can be used to create digital signature value (e.g. hash encrypted using the signer’s
private key) with low assurance of control.
5.13.3.3 Signature activation for SCAL2

Signing key confidentiality and integrity are ensured by the remote SCDev.
The remote SCDev is under control of the SSA.
The remote SCDev participates in SAP and ensures that the signature operation is under the legitimate
signer control.
The SSA interfaces via a secure channel the SAM of the remote SCDev which verifies the SAD in order to
activate the corresponding signing key (see Figure 3).
The signer authentication can remain for a given period and/or for a given number of signatures. But
SAD computation SHALL be done for each signature operation. The SAD MAY be linked to a set of
DTBS/R, this allows the SSA to be used for bulk/batch signature purposes.
Signer authentication can be done using a SSIC that is used to create a link between the signer and the
signature as part of the SAD.
The SAD uses is under the responsibility of the SAM:
— If the SAD is generated by the SIC, it SHALL be transferred securely from the SIC to the SAM for
verification.

— If the SAD is not generated by the SIC, it SHALL be generated on/during a successful signer’s
authentication using the SIC and be transferred securely to the SAM for verification.

18
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Figure 3 — Signature activation system with SCAL2

NOTE 1 This architecture may be extended to an external party when using delegation of authentication (see
5.7.4).

NOTE 2 The scope of requirements may be extended to an external party when using delegation of
authentication (see 5.7.4).

This architecture can be used to create digital signature value (e.g. hash encrypted using the signer’s
private key) with higher assurance of control.
5.13.4 TW4S components

The core parts of a TW4S for which this standard specifies requirements are the set of functional
components:
— Signing key setup – to generate signing keys within the SCDev and assign them for use by
authorized signers.

— Signing key management – to delete, backup and restore signing keys within the SCDev.

— Signer authentication – to authorize the use of signing key by the signer.

— Digital signature creation – to interface the authorized signer in order to create the digital signature
within the SCDev.

In order to enhance level of assurance, additional components are mandatory to reach SCAL2:
— The SIC – to create a link between the signer and the signature operation within the SAP. SIC MAY
generate SAD in the signer’s environment.

19
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

— The SAM – protected by the tamper protected environment, and responsible for executing the SAP.

The SAM provides a set of components:

— SAD generation – to generate SAD in the tamper protected environment when the SAD is not
generated by the SIC.

— Signing key activation – to manage SAD verification and to activate the signing keys.

— Signing key generation – to manage authentication factors bound to signing keys.

6 Security requirements
6.1 General
This clause describes all requirements applicable to a server signing system in order to be regarded as a
TW4S.
Requirements in 6.4 applies to TW4S supporting sole control assurance level 2.
6.2 General security requirements (SRG)
6.2.1 Management (SRG_M)
6.2.1.1 General

It is assumed that the Trust Service Provider (TSP) which provides signature creation services, operates
the TW4S in an environment with a security policy which incorporates general physical, personnel,
procedural and documentation security requirements and any specific requirements for TSPs providing
signature creation services.
A definition of the requirements can be found in ETSI EN 319 401 for example.
6.2.1.2 Systems and security management (SRG_M.1)

A TSP needs to manage its security in order to operate a TW4S that provides signature creation
services.

20
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

SRG_M.1.1 TW4S SHALL support roles with different privileges.


SRG_M.1.2 As a minimum the TW4S SHALL support the following roles:
Security Officers : having overall responsibility for administering the implementation of
the security policies, practices and have access to security related information.
System Administrators : are authorized to install, configure and maintain the TW4S but
with controlled access to security-related information.
System Operators : are responsible for operating the TW4S on a day-to-day basis and
are authorized to perform system backup and recovery.
System Auditors : are authorized to view archives and audit logs of the TW4S for the
purposes of auditing the operations of the system in line with security policy.
Security officers and system administrators are privileged system users.
System operators and system auditors have privileged roles but are not able to
administer or configure the TW4S.
SRG_M.1.3 As a minimum the TW4S SHALL support the following non-privileged roles:
Signer: is authorized to use the TW4S by passing the SAD as part of the SAP in order to
sign the document or the DTBS/R, which potentially can be passed through the SAP as
well.
SCA: is authorized to send the DTBS/R request to the TW4S in order to be signed by a
signer.
RA: is authorized to send the public key certificate to the TW4S in response of a
certificate signing request.

SRG_M.1.4 One privileged user SHALL NOT be able to take on all the privileged roles and SHOULD
NOT take on more than one of the privileged roles.
SRG_M.1.5 Users associated with privileged roles SHALL NOT be associated with non-privileged
role.
Users associated with non-privileged roles SHALL NOT be associated with privileged
role.
SRG_M.1.6 TW4S SHALL be capable of ensuring that a user authorized to assume a Security Officer
role is not authorized to assume a System Auditor role.
SRG_M.1.7 TW4S SHALL be capable of ensuring that a user authorized to assume a System
Administrator role and/or a System Operator role is not authorized to assume a System
Auditor role and/or a Security Officer role.
SRG_M.1.8 Individuals that are part of a group of privileged system users SHALL be named and
trained persons.
SRG_M.1.9 Only privileged system users SHALL have physical access to the hardware and can
administer the TW4S.
SRG_M.1.10 Only privileged system users SHALL have extensive privileges to administer the TW4S
through all relevant applications and interfaces.

21
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.2 Systems and operations (SRG_SO)


6.2.2.1 Operations management (SRG_SO.1)

A TSP operating a TW4S needs to ensure that its operation management functions are adequately
secure.
SRG_SO.1.1 TW4S manufacturers SHALL ensure instructions are provided to allow the TW4S to be:
— correctly and securely operated;
— deployed in such a way that the risk of systems failure is minimized;
— protected against viruses and malicious software to ensure the integrity of the
systems and the information they process.
SRG_SO.1.2 TW4S manufacturers SHALL provide system documentation covering the responsibilities
of the four privileged roles mentioned in SRG_M.1.2. It SHOULD include:
— Installation Guidance;
— Administration Guidance;
— User Guidance.

6.2.2.2 Time synchronization (SRG_SO.2)

The signature creation and the subsequent verification are time related, therefore there is a need to
ensure that TW4S are suitably synchronized with a standard time source. This requirement is separate
from any time-stamping requirements that can be set up by the TSP.
SRG_SO.2.1 TW4S manufacturers SHALL state the time accuracy of TW4S and how this is ensured.
SRG_SO.2.2 In order to ensure time accuracy of audited events, a time source suitably synchronized
with a standard time source SHOULD be used.
SRG_SO.2.3 In order to check whether a certificate has expired, a time source suitably synchronized
with the UTC SHALL be used.

6.2.3 Identification and authentication (SRG_IA)


6.2.3.1 General

The Identification and Authentication functions restrict the access to and the use of TW4S to authorized
persons only. This is applicable to all management components of the TSP. Identification and
Authentication MAY be provided either by the underlying operating software or directly by the actual
component itself.
6.2.3.2 Authentication for privileged and non-privileged roles other than signer (SRG_IA.1)

NOTE Signer’s authentication is covered by SRC_SA.

SRG_IA.1.1 TW4S SHALL require each user to identify him/herself and be successfully
authenticated before allowing any action on behalf of that user or role assumed by the
user.
SRG_IA.1.2 Re-authentication SHALL be mandatory after log out.
SRG_IA.1.3 Combination of authentication data, where used, SHALL be unpredictable.
SRG_IA.1.4 For privileged users mechanisms SHALL be implemented to reduce the risk of an
authenticated user session being taken over if the user's input device is left
unattended, for example by terminating a user session after a given idle period.

22
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.3.3 Authentication failure (SRG_IA.2)

SRG_IA.2.1 If the number of unsuccessful authentication attempts from the same user reaches the
maximum number of allowed attempts, the TW4S SHALL prevent further user
authentication attempts within a certain time frame or until an administrative role
unblock the user.
6.2.4 System access control (SRG_SA)
6.2.4.1 General

System access control functions restrict use of the objects of TW4S to authorized persons only. This is
not applicable to signer access control but to privileged user's access control on all sensitive objects of
the TW4S (see SRC_SA for signer access control).
System access control MAY be provided either by the underlying operating software or directly by the
actual component itself. Access rights to specific TW4S objects are determined by the owner of the
object based on the identity of the subject attempting to access it and:
a) the access rights to the object granted to the subject or;

b) the privileges held by the subject.

6.2.4.2 Right management (SRG_SA.1)

SRG_SA.1.1 TW4S SHALL provide the capability of controlling and limiting access for identified
individuals to the system or user objects which they own or are responsible for.
SRG_SA.1.2 TW4S SHALL ensure it provide access control to sensitive residual information.

6.2.5 Key management (SRG_KM)


6.2.5.1 General

A TW4S can use cryptographic keys to provide integrity, confidentiality and authentication functions
within its own subsystems and in between subsystems. As such, the unauthorised use, disclosure,
modification, or substitution of these keys would result in a loss of security in the TW4S. It is essential
that throughout the key lifecycle these keys are securely managed.
Due to the different threats bearing upon the keys of TW4S, depending on where and how they are
used, it is important to categorize keys with respect to their risk profile (i.e. sensitivity). For this
standard, keys are separated into the following categories:
1) Signer’s Signing Keys – keys used by their associated signers for creating digital signatures;

2) Infrastructure Keys – keys used by the TW4S for processes such as key agreement, subsystem
authentication, audit log signing, transmitted or stored data encryption, etc. Short term session
keys are also categorized as Infrastructure keys;

3) Control Keys – keys used by personnel managing or using the TW4S and who are likely to use these
keys for authentication, signing, or confidentiality purposes.

In terms of security requirements, signer’s signing key SHALL be considered as highly sensitive.
Consequently, countermeasures for managing the underlying risk SHOULD be adapted in both number
and effect. Infrastructure keys are also considered as highly sensitive but due to their distributed
characteristic they are less sensitive in comparison to signer’s signing key. The least sensitive keys used
by the TSP are considered to be those used by personnel for controlling TW4S as they are used by

23
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

trusted individuals and have an even shorter lifespan. Session keys, used for single/short transactions
are treated as sensitive information but with lower security requirements than the aforementioned
categories.
Infrastructure and Control Keys MAY be either private or secret keys.
6.2.5.2 Keys generation (SRG_KM.1)

SRG_KM.1.1 Private or secret keys SHOULD be generated and used in a SCDev.


The SCDev used SHOULD:
— be a trustworthy system which is ensured to EAL 4 or higher, augmented by
AVA_VAN.5 in accordance with ISO/IEC 15408, or equivalent national or
internationally recognized evaluation criteria for IT security. This SHALL be to a
security target or protection profile which meets the requirements of the present
document, based on a risk analysis and taking into account physical and other non-
technical security measures; or
NOTE 1 Standards specifying common criteria protection profiles for TSP
cryptographic modules, in accordance with ISO/IEC 15408, are currently under
development within CEN as CEN/TS 419221–2, CEN/TS 419221–3, CEN/TS 419221–4,
or EN 419221–5.
— meets the requirements identified in ISO/IEC 19790 or FIPS PUB 140–2 level 3.
NOTE 2 With the general availability of devices which meet ISO/IEC 15408, it is
expected that ISO/IEC 19790 or FIPS 140–2 level 3 will no longer be acceptable.
SRG_KM.1.2 The SCDev SHALL support cryptographic algorithms and key lengths corresponding to
the appropriate level of security, which fulfils the security needs identified during the
system design.
NOTE Standardization bodies, security agencies and supervisory authorities of the
Member States, cooperate on the harmonization of suitable algorithms [5] , and provide
cryptographic suites recommendations (e.g. ETSI/TS 119 312 [10] , SOG-IS-CRYPTO
[18] ).
Wherever confidentiality or integrity protection services are required (e.g. for backup
of signing keys), only cryptographic algorithms and algorithm parameters of equivalent
or higher strength SHALL be used.
SRG_KM.1.3 When the private or secret keys (including signer’s signing key, Infrastructure and
Control Keys) are held outside the SCDev, these keys SHALL be protected to ensure the
confidentiality and integrity of the keys.
SRG_KM.1.4 SCDev SHALL be initialised, before generating or containing any signing key, with
technical mechanisms that requires at least two operators in the SCDev.

24
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.5.3 Keys storage, backup and recovery (SRG_KM.2)

SRG_KM.2.1 All private or secret keys (including signer’s signing key, Infrastructure and Control
Keys) SHALL be securely stored, i.e. never be stored in an unprotected state.
SRG_KM.2.2 If any private or secret key (including signer’s signing key, Infrastructure and Control
Keys), is exported from that SCDev, it SHALL be protected to ensure its confidentiality
and integrity to the same or higher security level as within the SCDev.
Wherever the private/secret key is protected by encryption, only cryptographic
algorithms and algorithm parameters of equivalent or higher strength SHALL be used.
SRG_KM.2.3 TW4S SHALL ensure that backup, storage and restoration of private or secret keys
(including signer’s signing key, Infrastructure and Control Keys) are only performed by
authorized personnel. Master keys used to protect both user and working keys SHALL
be backed up, stored and reloaded under at least dual control. Such master keys SHALL
only be held outside the SCDev in protected form.

6.2.5.4 Key usage (SRG_KM.3)

SRG_KM.3.1 Private or secret key (including signer’s signing key, Infrastructure and Control Keys)
SHALL only be used for its intended purpose.
SRG_KM.3.2 Private or secret keys (including signer’s signing key, Infrastructure and Control Keys)
SHALL NOT be shared except as required to meet their purpose.
SRG_KM.3.3 Access controls SHALL be in place to protect the access and usage of the keys (including
signer’s signing key, Infrastructure and Control Keys).
SRG_KM.3.4 A signing key SHALL be linked to only one signer and only one public key certificate.

6.2.5.5 Key distribution (SRG_KM.4)

SRG_KM.4.1 Private or secret keys (including Infrastructure and Control Keys) SHALL be transmitted
securely when they have to be transmitted.
SRG_KM.4.2 All the keys used to protect other private/secret keys during transmission SHALL be (at
least) as strong as keys transmitted.

6.2.5.6 Key renewal/update/change (SRG_KM.5)

SRG_KM.5.1 Infrastructure and Control Keys SHOULD be changed on a regular basis, with a frequency
based on risk assessment.
SRG_KM.5.2 If any of the key algorithms or length is considered to have become unsuitable, keys
based on those algorithms SHALL be changed immediately.
SRG_KM.5.3 If any of the keys is compromised or suspected to be compromised, they SHOULD be
changed immediately.

6.2.5.7 Key archiving (SRG_KM.6)

SRG_KM.6.1 A signing key SHALL NOT be archived.

25
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.5.8 Key deletion (SRG_KM.7)

SRG_KM.7.1 A signing key SHALL be destroyed after the expiration of the public key certificate or if
the signing key is useless for the signer.
SRG_KM.7.2 If the link between the signing key and the signer is not maintained after the signing
operations session, then the signing key SHALL be destroyed at the end of the signing
operations session.
SRG_KM.7.3 Signing key destruction mechanism and procedure SHOULD ensure that all backups of
the destroyed signing key are also destroyed and that no residual information can be
used to reconstruct the signing key.
NOTE this recommendation does not apply if deleting of single keys in backup is
practically not feasible.

6.2.6 Auditing (SRG_AA)


6.2.6.1 Audit data generation (SRG_AA.1)

Each service has additional specific auditing requirements that SHALL be addressed in addition to these
general requirements.
SRG_AA.1.1 As a minimum, the following events SHALL be logged:
— significant TW4S environmental, key management events (generation, usage and
destruction);
— user signing events (e.g. successful signing with a signer’s signing key and DTBS/R
request management);
— user authentication during SAP;
— signer’s SAD management by TW4S;
— start up and shut down of the audit data generation function;
— changes of the audit parameters.
User signing events SHALL include associate certificate to the signing key.
All access attempts to TW4S SHOULD be logged.
SRG_AA.1.2 The TSP SHALL specify what is done (i.e. actions taken) in case of failure of passing audit
information to any external storage.

6.2.6.2 Guarantees of audit data availability (SRG_AA.2)

SRG_AA.2.1 TW4S SHALL maintain audit data and ensure that measures are taken for all audit data to
be stored.
SRG_AA.2.2 The audit function SHALL only append information.
SRG_AA.2.3 TW4S SHALL protect the stored audit records in the audit trail from unauthorized
deletion.
SRG_AA.2.4 Audit records MAY be deleted when archived to an external storage.

26
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.6.3 Audit data parameters (SRG_AA.3)

SRG_AA.3.1 All audit records (including service specific audit logging) SHALL contain the following
parameters:
— Date and time of event;
— Type of event;
— Identity of the entity (e.g. user, administrator, process) responsible for the action;
— Success or failure of the audited event.

6.2.6.4 Selectable audit review (SRG_AA.4)

SRG_AA.4.1 TW4S SHALL allow searching for events in the audit log based on the date of event, the
type of event and/or the identity of the user.
SRG_AA.4.2 The audit records SHALL be in a format that can be processed and be presented in such a
way that is suitable for the system auditors to interpret the information.

6.2.6.5 Restricted audit review (SRG_AA.5)

SRG_AA.5.1 TW4S SHALL by default deny all user read access to the audit records, except for users
that have been granted explicit read access (e.g. those with System Auditor role).

6.2.6.6 Generation of warning (SRG_AA.6)

SRG_AA.6.1 TW4S SHALL generate a warning notifying in a timely manner unusual events which can
have impact on the ability of the signing server system to meet the security requirements
identified in this standard.
A mechanism that issues a warning whenever an unusual event is detected SHOULD be
implemented. The warning SHOULD trigger a notification to relevant administrator
personnel.
A warning MAY also trigger further actions to react to possible attacks such as cutting off
the path of potential attack.
Examples of unusual events related to user activities can be (but not limited to):
— User actions outside of standard usage hours.
— User actions executed with an abnormal speed (in order to detect non-human
interventions).
— User actions skipping standard activities within defined processes.
— Duplicated user sessions.

6.2.6.7 Guarantees of audit data integrity (SRG_AA.7)

SRG_AA.7.1 TW4S SHALL ensure the integrity of the audit data.


SRG_AA.7.2 TW4S SHALL provide a function to verify the integrity of the audit data.

6.2.6.8 Guarantees of audit timing (SRG_AA.8)

SRG_AA.8.1 To ensure time accuracy of audited events requirement SRG_SO.2.2 applies.

27
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.2.7 Archiving (SRG_AR)


6.2.7.1 Archive data generation (SRG_AR.1)

SRG_AR.1.1 TSP SHALL be capable of generating an archive on an external media. The media
SHOULD be appropriate for storage and subsequent processing, and be able to provide
the necessary legal evidence in support of digital signatures.
NOTE These policy requirements will be moved into the appropriate standard when
available.
SRG_AR.1.2 All audit logs SHALL be archived.
SRG_AR.1.3 Each archive entry SHALL include the time at which the archiving occurred.
SRG_AR.1.4 The archive SHALL NOT include any sensitive security parameters, such as TW4S user
passwords.

6.2.7.2 Integrity of archived data (SRG_AR.2)

SRG_AR.2.1 Unauthorized modifications of each entry in the archive SHALL be prevented. A


mechanism to verify the integrity SHALL be in place to detect unauthorized
modifications.

6.2.8 Backup and recovery (SRG_BK)


6.2.8.1 General

This clause only covers system information, subject information and all other data that is necessary to
restore the system after a failure or disaster. It does NOT cover backup and recovery of keys, security
requirements for which are found in clause SRG_KM.2 .
6.2.8.2 Integrity and confidentiality of backup information (SRG_BK.1)

SRG_BK.1.1 Backups SHALL be protected against modification by a mechanism that allows verifying
the integrity of the backup information.
SRG_BK.1.2 Sensitive security parameters and other confidential information SHALL be stored in a
protected form in order to ensure confidentiality and integrity.

6.2.8.3 Recovery (SRG_BK.2)

SRG_BK.2.1 The TW4S SHALL include a recovery function that is able to restore the state of the
system from a backup.
SRG_BK.2.2 A user linked to a role with sufficient privileges SHALL be capable of invoking the
recovery function on demand from a backup.

28
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.3 Core components security requirements (SRC)


6.3.1 Signing key setup (SRC_SKS) - Cryptographic key (SRC_ SKS.1)

SRC_SKS.1.1 Algorithm parameters to be used for signature creation by trustworthy systems SHALL
be chosen so that can resist during the life time of the signer's certificate.
NOTE Standardization bodies, security agencies and supervisory authorities of the
Member States, cooperate on the harmonization of suitable algorithms [5] , and provide
cryptographic suites recommendations (e.g. ETSI/TS 119 312 [10] , SOG-IS-CRYPTO
[18] ).
SRC_SKS.1.2 TW4S SHALL link signer’s signing keys with the appropriate signer's public key
certificate.
SRC_SKS.1.3 Signer’s signing key MAY be generated in advance (i.e. not linked to a public key
certificate).
SRC_SKS.1.4 A signing key SHOULD NOT be used before its public key certificate is linked by the
TW4S.
NOTE this recommendation does not apply when the signing key is used to sign a
proof of possession in order to obtain a certificate.
SRC_SKS.1.5 TW4S SHALL protect the integrity of links between signer’s signing key and public key
certificate.

6.3.2 Signer authentication (SRC_SA)


6.3.2.1 Signer authentication for SCAL1 (SRC_SA.1)

SRC_SA.1.1 The enrolment of the signer SHALL be as specified in Annex A, A.1, for assurance level
low or higher.
The electronic identification means characteristics and design SHALL be as specified in
Annex A, A.2.1, for assurance level low or higher.
The authentication mechanism SHALL be as specified in Annex A, A.2.2, for assurance
level low or higher.
SRC_SA.1.2 SSA SHALL require each signer to be successfully identified and authenticated before
allowing any actions that can impact the sole control of any signing key.
SRC_SA.1.3 Protocols in use SHALL prevent man-in-the-middle attacks, replay attacks, and more
generally any form of attacks where a malicious user can use authentication credentials
which do not belong to him/her.
SRC_SA.1.4 Access controls SHALL ensure that a signer does not have access to sensitive system
objects and any functions which gives the user control over another's signing key.
SRC_SA.1.5 The TW4S SHALL ensure that the DTBS/R provided under control of the signer is only
signed by the signing key belonging to this signer.

29
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.3.2.2 Authentication failure handling (SRC_SA.2)

SRC_SA.2.1 For a given signer, TW4S SHALL detect when a defined number of consecutive
unsuccessful authentication attempts occurs.
SRC_SA.2.2 For a given signer, when the defined number of unsuccessful authentication attempts is
met, the TW4S SHALL block this user’s access for a reasonable amount of time or until
an administrative role unblock the user.

6.3.2.3 Signer authentication delegated to external system (SRC_SA.3)

SRC_SA.3.1 If the signer authentication is delegated to an external system, the TSP SHALL ensure
that requirements specified in Clauses SRC_SA.1 and SRC_SA.2 are met by the external
system.

6.3.3 Digital signature creation (SRC_DSC) - Cryptographic operation (SRC_DSC.1)

SRC_DSC.1.1 Algorithm parameters for being used for signature creation by trustworthy systems
SHALL be chosen so that can resist during the life time of the signer's certificate.
NOTE Standardization bodies, security agencies and supervisory authorities of the
Member States, cooperate on the harmonization of suitable algorithms [5] , and provide
cryptographic suites recommendations (e.g. ETSI/TS 119 312 [10] , SOG-IS-CRYPTO
[18] ).

6.4 Additional security requirements for SCAL2 (SRA)


6.4.1 General

The following requirements are only applicable to TW4S implementing sole control assurance level 2.
The SAM directly or indirectly authenticates the signer.
The SAD is collected under sole control of the signer, with a high level of confidence, ensuring that the
identified key is used by the authenticated signer for a specific (set of) DTBS/R.
6.4.2 Signature activation protocol and signature activation data (SRA_SAP)
6.4.2.1 Threat resistance (SRA_SAP.1)

SRA_SAP.1.1 The enrolment of the signer SHALL be as specified in Annex A, subclause A.1, for
assurance level substantial or higher.
The electronic identification means characteristics and design SHALL be as specified in
Annex A, subclause A.2.1, for assurance level substantial or higher.
The authentication mechanism SHALL be as specified in Annex A, subclause A.2.2, for
assurance level substantial or higher.
SRA_SAP.1.2 Controls SHALL be provided, as determined necessary by a risk assessment, in order to
counter the following threats on SAD and SAD use: online guessing, offline guessing,
credential duplication, phishing, eavesdropping, replay, session hijacking, man-in-the
middle, credential theft, spoofing and masquerading attacks.
SRA_SAP.1.3 SAP SHALL provide cryptographic strength mechanisms that protect the authentication
factors against compromise by the protocol threats as well as trusted third party
impersonation attacks.

30
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

SRA_SAP.1.4 The SAP SHALL be protected against replay, bypass and forgery attack between signer
and the remote SCDev (e.g. with a nonce, timestamp or session token).
SRA_SAP.1.5 The SAM SHALL be used in a tamper protected environment that:
— is a trustworthy system which is ensured to EAL 4 or higher in accordance with
ISO/IEC 15408, or equivalent national or internationally recognized evaluation
criteria for IT security. This SHALL be to a security target or protection profile
which meets the requirements of the present document, based on a risk analysis
and taking into account physical and other non-technical security measures; or
NOTE 1 Standards specifying common criteria protection profiles for TSP
cryptographic modules, in accordance with ISO/IEC 15408 are currently under
development within CEN as CEN/TS 419221–2, CEN/TS 419221–3, CEN/TS 419221–4,
or EN 419221–5.
— meets the requirements identified in ISO/IEC 19790 or FIPS PUB 140–2 level 3.
NOTE 2 With the general availability of devices which meet ISO/IEC 15408, it is
expected that ISO/IEC 19790 or FIPS 140–2 level 3 will no longer be acceptable.
SRA_SAP.1.6 The SAP SHALL be designed such that it can be assumed that the SAD is always reliably
protected against duplication or tampering against an attacker with high attack
potential.
SRA_SAP.1.7 The SAP SHALL be designed such that the signer can always reliably protect the signing
key activation by the SAD against an attacker with high attack potential.

6.4.2.2 SAD Management (SRA_SAP.2)

SRA_SAP.2.1 The SAD MAY be a set of data or be a result of cryptographic operations using
mandatory parameters listed below.
SRA_SAP.2.2 The SAD MAY be collected or generated in the signer’s environment by the SIC or
remotely using the SIC under control of signer.
SRA_SAP.2.3 The SAD SHALL link with a high level of confidence at least the following parameters:
— a given DTBS/R or a set of DTBS/R,
— items to identify the authenticated signer, and
— default or selected signing key.
If supported, it SHALL be possible to disable use of more than one DTBS/R in contexts
where it is not legally permitted.
SRA_SAP.2.4 The SAD SHALL be used to activate signing key only if signer authentication succeeds
(by e.g. computing SAD after successful authentication, or by other cryptographic
means).
SRA_SAP.2.5 The SAD SHALL be passed to the SAM in the SAP.
SRA_SAP.2.6 The SAD SHALL:
— be collected in a way that is under the control of the signer with a high level of
confidence,
— be protected so that any keys held within devices are secure, and
— protect any secret used (one time or long term one) as defined in SRA_SAP.1.4
SRA_SAP.2.7 The SAP SHALL be designed such that if SAD are received by the SAM, it can be
assumed that the SAD were submitted under sole control of the signer by means that
are in possession of the signer.

31
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

SRA_SAP.2.8 The SAD SHALL be verified such that it is highly unlikely that activities such as
guessing, eavesdropping, replay or manipulation of communication by an attacker with
high attack potential can subvert the authentication for signature activation.

6.4.3 Signing key management (SRA_SKM)


6.4.3.1 Signing key generation (SRA_SKM.1)

SRA_SKM.1.1 Signer’s signing key SHALL be generated and used in a SCDev that:
— is a trustworthy system which is ensured to EAL 4 or higher, augmented by
AVA_VAN.5 in accordance with ISO/IEC 15408, or equivalent national or
internationally recognized evaluation criteria for IT security. This SHALL be to a
security target or protection profile which meets the requirements of the present
document, based on a risk analysis and taking into account physical and other non-
technical security measures; or
NOTE 1 Standards specifying common criteria protection profiles for TSP
cryptographic modules, in accordance with ISO/IEC 15408, are currently under
development within CEN as CEN/TS 419221–2, CEN/TS 419221–3, CEN/TS 419221–4,
or EN 419221–5.
— meets the requirements identified in ISO/IEC 19790 or FIPS PUB 140–2 level 3.
NOTE 2 With the general availability of devices which meet ISO/IEC 15408, it is
expected that ISO/IEC 19790 or FIPS 140–2 level 3 will no longer be acceptable.
SRA_SKM.1.2 This SCDev SHALL be dedicated to supporting the cryptographic functions required by
the signature creation service (i.e. including random number generation and possibly
even encryption in support of the server signing).
SRA_SKM.1.3 When the SCDev used to generate signing keys is different from the SCDev used for
signature operations, the transmission of signing keys SHALL be compliant with
requirement SRG_KM.4.1.
SRA_SKM.1.4 SCDev MAY contain several signing keys for the same signer and for different signers.
Where several signing keys for the same signer or for different signers are contained
within the SCDev, separation of control over the use of the keys SHALL be ensured.
SRA_SKM.1.5 Signer’s signing key SHALL be linked with a high level of confidence to its signer by a
means provided by the SAP.
SRA_SKM.1.6 Signer’s signing key SHALL NOT be used before its signer is linked by the TW4S.
SRA_SKM.1.7 TW4S MAY support several different SAP and SAD mechanisms to activate signing keys.
However, a signing key SHALL be linked to only one SAD and SAP mechanism.

32
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

6.4.3.2 Signing key activation (SRA_SKM.2)

SRA_SKM.2.1 The TW4S SHALL require the signer to present a SAD to the SAM in order to be
authenticated and to activate the signing key.
SRA_SKM.2.2 The SAP SHALL manage the transmission of SAD to SAM in a way that guarantees that
the signing key is under control of signer with high level of confidence.
SRA_SKM.2.3 Signer’s signing key SHALL be activated for a use in a remote SCDev only.
SRA_SKM.2.4 Signer’s signing key SHALL be activated by the SAD generated with the signer’s
authentication factors with the correct key reference.
SRA_SKM.2.5 Activated signing key SHALL be used to sign only DTBS/R authorized by the SAP.
SRA_SKM.2.6 Where DTBS/R for a SAD comes from a SCA, the source SHALL be authenticated.
SRA_SKM.2.7 Privileged users SHALL not be able to use signing key allocated to a signer.
SRA_SKM.2.8 After signing key activation and digital signature creation, signer’s SAD SHALL NOT be
stored unprotected anywhere by TW4S.

33
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Annex A
(normative)

Requirements for electronic identification means, characteristics and


design

NOTE The elements of technical specifications and procedures outlined in this Annex are equivalent to the
requirements specified in (EU) 2015/1502 [6] ANNEX Clauses 2.1, 2.2.1 and 2.3.1 for assurance level low,
substantial or high.

A.1 Enrolment
A.1.1 Application and registration

Assurance level Elements


needed
Low 1. Ensure the applicant is aware of the terms and conditions related to
the use of the electronic identification means.
2. Ensure the applicant is aware of recommended security precautions
related to the electronic identification means.
3. Collect the relevant identity data required for identity proofing and
verification.
Substantial Same as level low.
High Same as level low.

A.1.2 Identity proofing and verification (natural person)

Assurance level Elements


needed
Low 1. The person can be assumed to be in possession of evidence recognized
by the Member State in which the application for the electronic
identity means is being made and representing the claimed identity.
2. The evidence can be assumed to be genuine, or to exist according to an
authoritative source and the evidence appears to be valid.
3. It is known by an authoritative source that the claimed identity exists
and it may be assumed that the person claiming the identity is one and
the same.

34
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Assurance level Elements


needed
Substantial Level low, plus one of the alternatives listed in points 1 to 4 has to be
met:
1. The person has been verified to be in possession of evidence
recognized by the Member State in which the application for the
electronic identity means is being made and representing the claimed
identity
and
the evidence is checked to determine that it is genuine; or, according
to an authoritative source, it is known to exist and relates to a real
person
and
steps have been taken to minimize the risk that the person's identity is
not the claimed identity, taking into account for instance the risk of
lost, stolen, suspended, revoked or expired evidence;
or
2. An identity document is presented during a registration process in the
Member State where the document was issued and the document
appears to relate to the person presenting it
and
steps have been taken to minimize the risk that the person's identity is
not the claimed identity, taking into account for instance the risk of
lost, stolen, suspended, revoked or expired documents;
or
3. Where procedures used previously by a public or private entity in the
same Member State for a purpose other than the issuance of
electronic identification means provide for an equivalent assurance to
those set out in section A.1.2 for the assurance level substantial, then
the entity responsible for registration need not to repeat those earlier
procedures, provided that such equivalent assurance is confirmed by a
conformity assessment body compliant with the applicable regulatory
requirements (see note) or by an equivalent body;
or
4. Where electronic identification means are issued on the basis of a
valid notified electronic identification means having the assurance
level substantial or high, and taking into account the risks of a change
in the person identification data, it is not required to repeat the
identity proofing and verification processes. Where the electronic
identification means serving as the basis has not been notified, the
assurance level substantial or high must be confirmed by a conformity
assessment body compliant with the applicable regulatory
requirements (see note) or by an equivalent body.
NOTE 1 In the context of the European Union the applicable regulatory
requirement for a conformity assessment body is Article 2(13) of Regulation
(EC) No 765/2008 of the European Parliament and of the Council.

35
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Assurance level Elements


needed
High Requirements of either point 1 or 2 have to be met:
1. Level substantial, plus one of the alternatives listed in points (a) to (c)
has to be met:
(a) Where the person has been verified to be in possession of photo
or biometric identification evidence recognized by the Member
State in which the application for the electronic identity means is
being made and that evidence represents the claimed identity, the
evidence is checked to determine that it is valid according to an
authoritative source;
and
the applicant is identified as the claimed identity through
comparison of one or more physical characteristic of the person
with an authoritative source;
or
(b) Where procedures used previously by a public or private entity in
the same Member State for a purpose other than the issuance of
electronic identification means provide for an equivalent
assurance to those set out in section A.1.2 for the assurance level
high, then the entity responsible for registration need not to
repeat those earlier procedures, provided that such equivalent
assurance is confirmed by a conformity assessment body
compliant with the applicable regulatory requirements (see note)
or by an equivalent body
and
steps are taken to demonstrate that the results of the earlier
procedures remain valid;
or
(c) Where electronic identification means are issued on the basis of a
valid notified electronic identification means having the assurance
level high, and taking into account the risks of a change in the
person identification data, it is not required to repeat the identity
proofing and verification processes. Where the electronic
identification means serving as the basis has not been notified,
the assurance level high must be confirmed by a conformity
assessment body compliant with the applicable regulatory
requirements (see note) or by an equivalent body
and
steps are taken to demonstrate that the results of this previous
issuance procedure of a notified electronic identification means
remain valid.
OR
2. Where the applicant does not present any recognized photo or
biometric identification evidence, the very same procedures used at
the national level in the Member State of the entity responsible for
registration to obtain such recognized photo or biometric
identification evidence are applied.
NOTE 2 In the context of the European Union the applicable regulatory
requirement for a conformity assessment body is Article 2(13) of Regulation (EC)
No 765/2008 of the European Parliament and of the Council.

36
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

A.1.3 Identity proofing and verification (legal person)

Assurance level Elements


Needed
Low 1. The claimed identity of the legal person is demonstrated on the basis of
evidence recognized by the Member State in which the application for
the electronic identity means is being made.
2. The evidence appears to be valid and can be assumed to be genuine, or
to exist according to an authoritative source, where the inclusion of a
legal person in the authoritative source is voluntary and is regulated by
an arrangement between the legal person and the authoritative source.
3. The legal person is not known by an authoritative source to be in a
status that would prevent it from acting as that legal person.
Substantial Level low, plus one of the alternatives listed in points 1 to 3 has to be
met:
1. The claimed identity of the legal person is demonstrated on the basis of
evidence recognized by the Member State in which the application for
the electronic identity means is being made, including the legal
person's name, legal form, and (if applicable) its registration number
and
the evidence is checked to determine whether it is genuine, or known
to exist according to an authoritative source, where the inclusion of the
legal person in the authoritative source is required for the legal person
to operate within its sector
and
steps have been taken to minimise the risk that the legal person's
identity is not the claimed identity, taking into account for instance the
risk of lost, stolen, suspended, revoked or expired documents;
or
2. Where the procedures used previously by a public or private entity in
the same Member State for a purpose other than issuance of electronic
identification means provide for an equivalent assurance to those set
out in section A.1.3 for the assurance level substantial, then the entity
responsible for registration need not to repeat those earlier
procedures, provided that such equivalent assurance is confirmed by a
conformity assessment body compliant with the applicable regulatory
requirements (see note) or by an equivalent body;
or
3. Where electronic identification means are issued on the basis of a valid
notified electronic identification means having the assurance level
substantial or high, it is not required to repeat the identity proofing
and verification processes. Where the electronic identification means
serving as the basis has not been notified, the assurance level
substantial or high must be confirmed by a conformity assessment
body compliant with the applicable regulatory requirements (see note)
or by an equivalent body.
NOTE 1 In the context of the European Union the applicable regulatory
requirement for a conformity assessment body is Article 2(13) of Regulation (EC)
No 765/2008 of the European Parliament and of the Council.

37
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Assurance level Elements


Needed
High Level substantial, plus one of the alternatives listed in points 1 to 3 has to
be met:
1. The claimed identity of the legal person is demonstrated on the basis of
evidence recognized by the Member State in which the application for
the electronic identity means is being made, including the legal person's
name, legal form, and at least one unique identifier representing the
legal person used in a national context
and
the evidence is checked to determine that it is valid according to an
authoritative source;
or
2. Where the procedures used previously by a public or private entity in
the same Member State for a purpose other than issuance of electronic
identification means provide for an equivalent assurance to those set
out in section A.1.3 for the assurance level high, then the entity
responsible for registration need not to repeat those earlier
procedures, provided that such equivalent assurance is confirmed by a
conformity assessment body compliant with the applicable regulatory
requirements (see note) or by an equivalent body
and
steps are taken to demonstrate that the results of this previous
procedure remain valid;
or
3. Where electronic identification means are issued on the basis of a valid
notified electronic identification means having the assurance level high,
it is not required to repeat the identity proofing and verification
processes. Where the electronic identification means serving as the
basis has not been notified, the assurance level high must be confirmed
by a conformity assessment body compliant with the applicable
regulatory requirements (see note) or by an equivalent body
and
steps are taken to demonstrate that the results of this previous
issuance procedure of a notified electronic identification means remain
valid.
NOTE 2 In the context of the European Union the applicable regulatory
requirement for a conformity assessment body is Article 2(13) of Regulation (EC)
No 765/2008 of the European Parliament and of the Council.

38
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

A.1.4 Binding between the electronic identification means of natural and legal persons
Where applicable, for binding between the electronic identification means of a natural person and the
electronic identification means of a legal person (‘binding’) the following conditions apply:
a) It shall be possible to suspend and/or revoke a binding. The life-cycle of a binding (e.g. activation,
suspension, renewal, revocation) shall be administered according to nationally recognized
procedures.
b) The natural person whose electronic identification means is bound to the electronic identification
means of the legal person may delegate the exercise of the binding to another natural person on the
basis of nationally recognized procedures. However, the delegating natural person shall remain
accountable.
c) Binding shall be done in the following manner:

Assurance level Elements


Needed
Low 1. The identity proofing of the natural person acting on behalf of the
legal person is verified as having been performed at level low or
above.
2. The binding has been established on the basis of nationally
recognized procedures.
3. The natural person is not known by an authoritative source to be in
a status that would prevent that person from acting on behalf of the
legal person.
Substantial Point 3 of level low, plus:
1. The identity proofing of the natural person acting on behalf of the
legal person is verified as having been performed at level
substantial or high.
2. The binding has been established on the basis of nationally
recognized procedures, which resulted in the registration of the
binding in an authoritative source.
3. The binding has been verified on the basis of information from an
authoritative source.
High Point 3 of level low and point 2 of level substantial, plus:
1. The identity proofing of the natural person acting on behalf of the
legal person is verified as having been performed at level high.
2. The binding has been verified on the basis of a unique identifier
representing the legal person used in the national context; and on
the basis of information uniquely representing the natural person
from an authoritative source.

39
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

A.2 Electronic identification means and authentication


A.2.1 Electronic identification means characteristics and design

Assurance level Elements


needed
Low 1. The electronic identification means utilises at least one authentication
factor.
2. The electronic identification means is designed so that the issuer takes
reasonable steps to check that it is used only under the control or
possession of the person to whom it belongs.
Substantial 1. The electronic identification means utilises at least two authentication
factors from different categories.
2. The electronic identification means is designed so that it can be
assumed to be used only if under the control or possession of the
person to whom it belongs.
High Level substantial, plus:
1. The electronic identification means protects against duplication and
tampering as well as against attackers with high attack potential
2. The electronic identification means is designed so that it can be
reliably protected by the person to whom it belongs against use by
others.

40
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

A.2.2 Authentication mechanism


The following table sets out the requirements per assurance level with respect to the authentication
mechanism, through which the natural or legal person uses the electronic identification means to
confirm its identity to a relying party.

Assurance level Elements


needed
Low 1. The release of person identification data is preceded by reliable
verification of the electronic identification means and its validity.
2. Where person identification data is stored as part of the authentication
mechanism, that information is secured in order to protect against loss
and against compromise, including analysis offline.
3. The authentication mechanism implements security controls for the
verification of the electronic identification means, so that it is highly
unlikely that activities such as guessing, eavesdropping, replay or
manipulation of communication by an attacker with enhanced-basic
attack potential can subvert the authentication mechanisms.
Substantial Level low, plus:
1. The release of person identification data is preceded by reliable
verification of the electronic identification means and its validity through
a dynamic authentication.
2. The authentication mechanism implements security controls for the
verification of the electronic identification means, so that it is highly
unlikely that activities such as guessing, eavesdropping, replay or
manipulation of communication by an attacker with moderate attack
potential can subvert the authentication mechanisms.
High Level substantial, plus:
The authentication mechanism implements security controls for the
verification of the electronic identification means, so that it is highly
unlikely that activities such as guessing, eavesdropping, replay or
manipulation of communication by an attacker with high attack potential
can subvert the authentication mechanisms.

41
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

Bibliography

The following materials, though not specifically referenced in the body of the present document (or not
publicly available), give supporting information.

[1] CWA 14355, Guidelines for the implementation of Secure Signature-Creation Devices
[2] ETSI/TS 102 853, Electronic Signatures and Infrastructures (ESI); Signature validation procedures
and policies
[3] Mandate M460, Standardisation Mandate to the European Standardisation Organisations CEN,
CENELEC and ETSI in the Field of Information and Communication Technologies Applied to
Electronic Signatures
[4] Regulation (EU) No 910/2014, of the European Parliament and of the Council on electronic
identification and trust services for electronic transactions in the internal market and repealing
Directive 1999/93/EC
[5] Commission Implementing Decision (EU) 2016/650 of 25 April 2016, laying down standards for
the security assessment of qualified signature and seal creation devices
[6] Commission Implementing Decision (EU) 2015/1502 of 8 September 2015, on setting out
minimum technical specifications and procedures for assurance levels for electronic identification
means
[7] ETSI/SR 001 604, Rationalised Framework for Electronic Signature Standardisation

[8] CEN/TS 419261, Security requirements for trustworthy systems managing certificates and time-
stamps
[9] EN 419251-1, Security requirements for device for authentication - Part 1: Protection profile for
core functionality
[10] ETSI/TS 119 312, Electronic Signatures and Infrastructures (ESI); Cryptographic Suites for Secure
Electronic Signatures
[11] ETSI EN 319 401, Electronic Signatures and Infrastructures (ESI); General Policy Requirements for
Trust Service Providers supporting Electronic Signatures
[12] ETSI EN 319 411-1, Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Trust Service Providers issuing certificates; Part 1: General requirements
[13] ETSI EN 319 411-2, Electronic Signatures and Infrastructures (ESI); Policy and security
requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service
providers issuing EU qualified certificates
[14] ETSI EN 319-122, Electronic Signatures and Infrastructures (ESI); CAdES digital signatures

[15] ETSI EN 319 132, Electronic Signatures and Infrastructures (ESI); XAdES digital signatures

[16] ETSI EN 319 142, Electronic Signatures and Infrastructures (ESI); PAdES digital signatures

42
BS EN 419241‑1:2018
EN 419241-1:2018 (E)

[17] ETSI/TS 119 101, Electronic Signatures and Infrastructures (ESI); Policy and Security
Requirements for Electronic Signature Creation and Validation
[18] SOG-IS C RYPTO WORKING G ROUP . SOG-IS Crypto Evaluation Scheme Agreed Cryptographic
Mechanisms, available at http://www.sogis.org

[19] EN 419211 (all parts), Protection profiles for secure signature creation device

[20] EN 419212 (all parts), Application Interface for smart cards used as Secure Signature Creation
Devices
[21] CEN/TS 419221-2, Protection Profiles for TSP cryptographic modules - Part 2: Cryptographic
module for CSP signing operations with backup
[22] CEN/TS 419221-3, Protection Profiles for TSP Cryptographic modules - Part 3: Cryptographic
module for CSP key generation services
[23] CEN/TS 419221-4, Protection Profiles for TSP cryptographic modules - Part 4: Cryptographic
module for CSP signing operations without backup
[24] EN 419221-5, Protection profiles for TSP Cryptographic modules - Part 5: Cryptographic Module
for Trust Services

43
NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

British Standards Institution (BSI)


BSI is the national body responsible for preparing British Standards and other
standards-related publications, information and services.
BSI is incorporated by Royal Charter. British Standards and other standardization
products are published by BSI Standards Limited.

About us Reproducing extracts


We bring together business, industry, government, consumers, innovators For permission to reproduce content from BSI publications contact the BSI
and others to shape their combined experience and expertise into standards Copyright & Licensing team.
-based solutions.
The knowledge embodied in our standards has been carefully assembled in Subscriptions
a dependable format and ref ned through our open consultation process. Our range of subscription services are designed to make using standards
Organizations of all sizes and across all sectors choose standards to help easier for you. For further information on our subscription products go to
them achieve their goals. bsigroup.com/subscriptions.
With British Standards Online (BSOL) you’ll have instant access to over 55,000
Information on standards British and adopted European and international standards from your desktop.
We can provide you with the knowledge that your organization needs It’s available 24/7 and is refreshed daily so you’ll always be up to date.
to succeed. Find out more about British Standards by visiting our website at You can keep in touch with standards developments and receive substantial
bsigroup.com/standards or contacting our Customer Services team or discounts on the purchase price of standards, both in single copy and subscription
Knowledge Centre. format, by becoming a BSI Subscribing Member.

Buying standards PLUS is an updating service exclusive to BSI Subscribing Members. You will
automatically receive the latest hard copy of your standards when they’re
You can buy and download PDF versions of BSI publications, including British revised or replaced.
and adopted European and international standards, through our website at
bsigroup.com/shop, where hard copies can also be purchased. To f nd out more about becoming a BSI Subscribing Member and the benef ts
of membership, please visit bsigroup.com/shop.
If you need international and foreign standards from other Standards Development
Organizations, hard copies can be ordered from our Customer Services team. With a Multi-User Network Licence (MUNL) you are able to host standards
publications on your intranet. Licences can cover as few or as many users as you
Copyright in BSI publications wish. With updates supplied as soon as they’re available, you can be sure your
documentation is current. For further information, email subscriptions@bsigroup.com.
All the content in BSI publications, including British Standards, is the property
of and copyrighted by BSI or some person or entity that owns copyright in the
information used (such as the international standardization bodies) and has
Revisions
formally licensed such information to BSI for commercial publication and use. Our British Standards and other publications are updated by amendment or revision.

Save for the provisions below, you may not transfer, share or disseminate any We continually improve the quality of our products and services to benef t your
portion of the standard to any other person. You may not adapt, distribute, business. If you f nd an inaccuracy or ambiguity within a British Standard or other
commercially exploit, or publicly display the standard or any portion thereof in any BSI publication please inform the Knowledge Centre.
manner whatsoever without BSI’s prior written consent.
Useful Contacts
Storing and using standards Customer Services
Standards purchased in soft copy format: Tel: +44 345 086 9001
• A British Standard purchased in soft copy format is licensed to a sole named Email (orders): orders@bsigroup. com
user for personal or internal company use only. Email (enquiries): cservices@bsigroup. com
• The standard may be stored on more than 1 device provided that it is accessible Subscriptions
by the sole named user only and that only 1 copy is accessed at any one time. Tel: +44 345 086 9001
• A single paper copy may be printed for personal or internal company use only. Email: subscriptions@bsigroup. com
• Standards purchased in hard copy format:
Knowledge Centre
• A British Standard purchased in hard copy format is for personal or internal Tel: +44 20 8996 7004
company use only.
Email: knowledgecentre@bsigroup. com
• It may not be further reproduced – in any format – to create an additional copy.
This includes scanning of the document. Copyright & Licensing
If you need more than 1 copy of the document, or if you wish to share the Tel: +44 20 8996 7070
document on an internal network, you can save money by choosing a subscription Email: copyright@bsigroup. com
product (see ‘Subscriptions’).
BSI Group Headquarters
389 Chiswick High Road London W4 4AL UK

This page deliberately left blank