Protection Profile —
Secure Signature-Creation Device
Type1
Version: 1.05, EAL 4+
Saturday, 28 July 2001
Prepared By: ESIGN Workshop - Expert Group F
Prepared For: CEN/ISSS
Note: This Protection Profile (PP) has been prepared for the European
Electronic Signature Standardisation Initiative EESSI by CEN/ISSS area F on
secure signature-creation devices (SSCDs). In its present form it represents
one of two documents that the CEN/ISSS E-Sign Workshop decided at its
Brussels meeting 21st
November 2000 to forward to the EESSI Steering
Committee—one defining evaluation assurance level EAL 4 augmented and
one defining EAL 4.
The actual PP is EAL 4 augmented by AVA_VLA.4 and AVA_MSU.3, strength
of function high.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 i version 1.05, EAL 4+
—— this page was intentionally left blank ——
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 ii version 1.05, EAL 4+
Foreword
This ‘Protection Profile — Secure Signature-Creation Device’ is issued by the European
Committee for Standardization, Information Society Standardization System (CEN/ISSS)
Electronic Signatures (E-SIGN) workshop. The document represents Annex A of the CEN/ISSS
workshop agreement (CWA) on secure signature-creation devices.
The document is for use by the European Commission in accordance with the procedure laid
down in Article 9 of the Directive 1999/93/ec of the European parliament and of the council of
13 December 1999 on a Community framework for electronic signatures [1] as generally
recognised standard for electronic-signature products in the Official Journal of the European
Communities.
The document has been prepared as a Protection Profile (PP) following the rules and formats of
ISO 15408, as known as the Common Criteria version 2.1 [2] [3] [4].
The set of algorithms for secure signature-creation devices and parameters for algorithms for
secure signature-creation devices is given in a separate document in [5].
Correspondence and comments to this secure signature-creation device protection profile
(SSCD-PP) should be referred to:
CONTACT ADDRESS
CEC/ISSS Secretariat
Rue de Stassart 36
1050 Brussels, Belgium
Tel +32 2 550 0813
Fax +32 2 550 0966
Email isss@cenorm.be
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 iii version 1.05, EAL 4+
—— this page was intentionally left blank ——
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 iv version 1.05, EAL 4+
Revision History
v1.0-draft 22.09.00 submitted to CEN/ISSS WS/E-Sign Workshop
v1.0-final 16.11.00 for ballot by WS/E-Sign at Brussels meeting (11/00)
v1.0, EAL4+ 28.11.00 for submission to European Commission by EESSI
v1.01, EAL4+ 01.02.01 for ballot by WS/E-Sign at Brussels meeting (12/01)
v1.02, EAL4+ 14.02.01 for ballot by WS/E-Sign as decided at Brussels meeting.
V1.03-EAL4+ 15.06.01 Type1 PP extracted from SSCD approved by WS/E-Sign
ballot to comply with the request of the evaluator.
V1.04-EAL4+ 28.06.01 Type1 PP revised to comply with the request of the
evaluator.
V1.05-EAL4+ 28.07.01 final version after evaluation
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 v version 1.05, EAL 4+
—— this page was intentionally left blank ——
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 vi version 1.05, EAL 4+
Table Of Contents
Revision History iv
Table Of Contents vi
List of Tables ix
Conventions and Terminology 1
Conventions 1
Terminology 1
Document Organisation 3
1 Introduction 4
1.1 Identification 4
1.2 Protection Profile Overview 4
2 TOE Description 5
2.1 Secure Signature Creation Devices 5
2.2 Limits of the TOE 6
3 TOE Security Environment 9
3.1 Assumptions 9
3.2 Threats to Security 10
3.3 Organisational Security Policies 11
4 Security Objectives 12
4.1 Security Objectives for the TOE 12
4.2 Security Objectives for the Environment 13
5 IT Security Requirements 14
5.1 TOE Security Functional Requirements 14
5.1.1 Cryptographic support (FCS) 14
5.1.2 User data protection (FDP) 15
5.1.3 Identification and authentication (FIA) 18
5.1.4 Security management (FMT) 19
5.1.5 Protection of the TSF (FPT) 19
5.1.6 Trusted path/channels (FTP) 21
5.2 TOE Security Assurance Requirements 23
5.2.1 Configuration management (ACM) 23
5.2.2 Delivery and operation (ADO) 25
5.2.3 Development (ADV) 25
5.2.4 Guidance documents (AGD) 28
5.2.5 Life cycle support (ALC) 29
5.2.6 Tests (ATE) 30
5.2.7 Vulnerability assessment (AVA) 31
5.3 Security Requirements for the IT Environment 32
5.3.1 SCD import (SSCD type2) 32
5.3.2 Certification generation application (CGA) 34
5.4 Security Requirements for the Non-IT Environment 35
6 Rationale 36
6.1 Introduction 36
6.2 Security Objectives Rationale 36
6.2.1 Security Objectives Coverage 36
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 vii version 1.05, EAL 4+
6.2.2 Security Objectives Sufficiency 36
6.3 Security Requirements Rationale 40
6.3.1 Security Requirement Coverage 40
6.3.2 Security Requirements Sufficiency 42
6.4 Dependency Rationale 45
6.4.1 Functional and Assurance Requirements Dependencies 45
6.4.2 Justification of Unsupported Dependencies 47
6.5 Security Requirements Grounding in Objectives 48
6.6 Rationale for Extensions 49
6.6.1 FPT_EMSEC TOE Emanation 49
6.7 Rationale for Strength of Function High 50
6.8 Rationale for Assurance Level 4 Augmented 50
References 51
Appendix A - Acronyms 51
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 viii version 1.05, EAL 4+
—— this page was intentionally left blank ——
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 ix version 1.05, EAL 4+
List of Tables
Table 5.1 Assurance Requirements: EAL(4) 23
Table 6.1 : Security Environment to Security Objectives Mapping 36
Table 6.2 : Functional Requirement to TOE Security Objective Mapping 40
Table 6.3: IT Environment Functional requirement to Environment Security Objective Mapping 41
Table 6.4 : Assurance Requirement to Security Objective Mapping 42
Table 6.5 Functional and Assurance Requirements Dependencies 45
Table 6.6 Assurance and Functional Requirement to Security Objective Mapping 48
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 x version 1.05, EAL 4+
—— this page was intentionally left blank ——
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 1 version 1.05, EAL 4+
Conventions and Terminology
Conventions
The document follows the rules and conventions laid out in Common Criteria 2.1, part 1 [2],
AnnexB “Specification of Protection Profiles”. Admissible algorithms and parameters for
algorithms for secure signature-creation devices (SSCD) are given in a separate document [5].
Therefore, the Protection Profile (PP) refers to [5].
Terminology
Administrator means an user that performs TOE initialisation, TOE personalisation, or other
TOE administrative functions.
Advanced electronic signature (defined in the Directive [1], article 2.2) means an electronic
signature which meets the following requirements:
(a) it is uniquely linked to the signatory;
(b) it is capable of identifying the signatory;
(c) it is created using means that the signatory can maintain under his sole control, and
(d) it is linked to the data to which it relates in such a manner that any subsequent
change of the data is detectable.
Authentication data is information used to verify the claimed identity of a user.
CEN workshop agreement (CWA) is a consensus-based specification, drawn up in an open
workshop environment of the European Committee for Standardisation (CEN). This Protection
Profile (PP) represents Annex A to the CWA that has been developed by the European
Electronic Signature Standardisation Initiative (EESSI) CEN/ISSS electronic signature (E-SIGN)
workshop, Area F on secure signature-creation devices (SSCD).
Certificate means an electronic attestation which links the SVD to a person and confirms the
identity of that person. (defined in the Directive [1], article 2.9)
Certification generation application (CGA) means a collection of application elements which
requests the SVD from the SSCD for generation of the qualified certificate. The CGA stipulates
the generation of a correspondent SCD / SVD pair by the SSCD, if the requested SVD has not
been generated by the SSCD yet. The CGA verifies the authenticity of the SVD by means of
(a) the SSCD proof of correspondence between SCD and SVD and
(b) checking the sender and integrity of the received SVD.
Certification-service-provider (CSP) means an entity or a legal or natural person who issues
certificates or provides other services related to electronic signatures. (defined in the Directive
[1], article 2.11)
Data to be signed (DTBS) means the complete electronic data to be signed (including both
user message and signature attributes).
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 2 version 1.05, EAL 4+
Data to be signed representation (DTBS-representation) means the data sent by the SCA to
the TOE for signing and is
(a) a hash-value of the DTBS or
(b) an intermediate hash-value of a first part of the DTBS and a remaining part of the
DTBS or
(c) the DTBS.
The SCA indicates to the TOE the case of DTBS-representation, unless implicitly indicated. The
hash-value in case (a) or the intermediate hash-value in case (b) is calculated by the SCA. The
final hash-value in case (b) or the hash-value in case (c) is calculated by the TOE.
Directive The Directive 1999/93/ec of the European parliament and of the council of
13 December 1999 on a Community framework for electronic signatures [1] is also referred to
as the ‘Directive’ in the remainder of the PP.
Qualified certificate means a certificate which meets the requirements laid down in Annex I of
the Directive [1] and is provided by a CSP who fulfils the requirements laid down in Annex II of
the Directive [1]. (defined in the Directive [1], article 2.10)
Qualified electronic signature means an advanced signature which is based on a qualified
certificate and which is created by a SSCD according to the Directive [1], article 5, paragraph 1.
Reference authentication data (RAD) means data persistently stored by the TOE for
verification of the authentication attempt as authorised user.
Secure signature-creation device (SSCD) means configured software or hardware which is
used to implement the SCD and which meets the requirements laid down in Annex III of the
Directive [1]. (SSCD is defined in the Directive [1], article 2.5 and 2.6).
Signatory means a person who holds a SSCD and acts either on his own behalf or on behalf of
the natural or legal person or entity he represents. (defined in the Directive [1], article 2.3)
Signature attributes means additional information that is signed together with the user
message.
Signature-creation application (SCA) means the application used to create an electronic
signature, excluding the SSCD. I.e., the SCA is a collection of application elements
(a) to perform the presentation of the DTBS to the signatory prior to the signature
process according to the signatory's decision,
(b) to send a DTBS-representation to the TOE, if the signatory indicates by specific non-
misinterpretable input or action the intend to sign,
(c) to attach the qualified electronic signature generated by the TOE to the data or
provides the qualified electronic signature as separate data.
Signature-creation data (SCD) means unique data, such as codes or private cryptographic
keys, which are used by the signatory to create an electronic signature. (defined in the Directive
[1], article 2.4)
Signature-creation system (SCS) means the overall system that creates an electronic
signature. The signature-creation system consists of the SCA and the SSCD.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 3 version 1.05, EAL 4+
Signature-verification data (SVD) means data, such as codes or public cryptographic keys,
which are used for the purpose of verifying an electronic signature. (defined in the Directive [1],
article 2.7)
Signed data object (SDO) means the electronic data to which the electronic signature has
been attached to or logically associated with as a method of authentication.
SSCD provision servicemeans a service that prepares and provides a SSCD to subscribers.
User means any entity (human user or external IT entity) outside the TOE that interacts with the
TOE.
Verification authentication data (VAD) means authentication data provided as input by
knowledge or authentication data derived from user’s biometric characteristics.
Document Organisation
Section 1 provides the introductory material for the Protection Profile.
Section 2 provides general purpose and TOE description.
Section 3 provides a discussion of the expected environment for the TOE. This section also
defines the set of threats that are to be addressed by either the technical countermeasures
implemented in the TOE hardware, the TOE software, or through the environmental controls.
Section 4 defines the security objectives for both the TOE and the TOE environment.
Section 5 contains the functional requirements and assurance requirements derived from the
Common Criteria (CC), Part 2 [3] and Part 3 [4], that must be satisfied by the TOE.
Section 6 provides a rationale to explicitly demonstrate that the information technology security
objectives satisfy the policies and threats. Arguments are provided for the coverage of each
policy and threat. The section then explains how the set of requirements are complete relative
to the objectives, and that each security objective is addressed by one or more component
requirements. Arguments are provided for the coverage of each objective. Next section 6
provides a set of arguments that address dependency analysis, strength of function issues, and
the internal consistency and mutual supportiveness of the protection profile requirements
A reference section is provided to identify background material.
An acronym list is provided to define frequently used acronyms.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 4 version 1.05, EAL 4+
1 Introduction
This section provides document management and overview information that is required to carry
out protection profile registry. Therefore, section 1.1 “Identification” gives labelling and
descriptive information necessary for registering the Protection Profile (PP). Section 1.2
“Protection Profile Overview” summarises the PP in narrative form. As such, the section gives
an overview to the potential user to decide whether the PP is of interest. It is usable as
stand-alone abstract in PP catalogues and registers.
1.1 Identification
Title: Protection Profile — Secure Signature-Creation Device Type1
Authors: Wolfgang Killmann, Herbert Leitold, Reinhard Posch, Patrick Sallé
Vetting Status:
CC Version: 2.1 Final
General Status: Final Ballot Draft
Version Number: 1.05
Registration:
Keywords: secure signature-creation device, electronic signature
1.2 Protection Profile Overview
This Protection Profile (PP) is established by CEN/ISSS for use by the European Commission in
accordance with the procedure laid down in Article 9 of the Directive 1999/93/ec of the
European parliament and of the council of 13 December 1999 on a Community framework for
electronic signatures [1], also referred to as the ‘Directive’ in the remainder of the PP, as
generally recognised standard for electronic-signature products in the Official Journal of the
European Communities.
The intent of this Protection Profile is to specify functional and assurance requirements for the
generation of the SCD in conformance with the Directive [1], Annex III for secure signature-
creation devices. Member States shall presume that there is compliance with the requirements
laid down in Annex III of the Directive [1] when electronic signature products are evaluated
according to Security Targets (ST) that are compliant with this PP and the PP for SSCD type 2
or a PP for SSCD type 3
The Protection Profile defines the security requirements of a SSCD for the generation of
signature-creation data (SCD).
The assurance level for this PP is EAL4 augmented. The minimum strength level for the TOE
security functions is 'SOF high' (Strength of Functions High).
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 5 version 1.05, EAL 4+
2 TOE Description
2.1 Secure Signature Creation Devices
The present document assumes a well defined process signature-creation to take place. The
present chapter defines three possible SSCD implementations, referred to as ‘SSCD types’, as
illustrated in Figure 1.
The left part of Figure 1 shows two SSCD components: A SSCD of Type 1 representing the
SCD/SVD generation component, and a SSCD of Type 2 representing the SCD storage and
signature-creation component. The SCD generated on a SSCD Type 1 shall be exported to a
SSCD Type 2 over a trusted channel. The right part of Figure 1 shows a SSCD Type 3 which is
analogous to a combination of Type 1 and Type 2, but no transfer of the SCD between two
devices is provided.
If the SSCD holds the SVD and exports the SVD to a CGA for certification, a trusted channel is
to be provided. The CGA initiates SCD/SVD generation (“Init.”) and the SSCD exports the SVD
for generation of the corresponding certificate (“SVD into cert.”).
The signatory must be authenticated to create signatures that he sends his authentication data
(e.g., a PIN) to the SSCD Type 2 or Type 3 (e.g., a smart card). If the human interface (HI) for
such signatory authentication is not provided by the SSCD, a trusted path (e.g., a encrypted
channel) between the SSCD and the SCA implementing the HI is to be provided. The data to be
signed (DTBS) representation (i.e., the DTBS itself, a hash value of the DTBS, or a pre-hashed
value of the DTBS) shall be transferred by the SCA to the SSCD only over a trusted channel.
The same shall apply to the signed data object (SDO) returned from a SSCD to the SCA.
SSCD Type 1 is not a personalized component in the sense that it may be used by a specific
user only, but the SCD/SVD generation and export shall be initiated by authorized persons only
(e.g., system administrator).
SSCD Type 2 and Type 3 are personalized components which means that they can be used for
signature creation by one specific user – the signatory - only.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 6 version 1.05, EAL 4+
HI
Authentication data
User
Authentication
SCD Import
Personalisation
Signature-Creation
SSCD Type 2
SCD Export
SVD Export
SCD/SVD Generation
SSCD Type 1
Trusted
channel
Trusted
channel **
Trusted
channel
CGA
Init. / SVD into cert.
CGA **
SVD into cert.
HI
A
uthentication data
SCA
DTBS-representation
SDO
SCA
DTBS-representation
SDO
CGA
Init. / SVD into cert.
User
Authentication
Personalisation
Signature-Creation
SSCD Type 3
SVD Export
SCD/SVD Generation
Trusted
channel
Trusted
channel
Trusted
Path*
Trusted
Channel
Trusted
Path*
* The trusted path for user authentication will be required if the HI is not provided by the TOE itself
(e. g., it is provided by a SCA outside the SSCD)
** The trusted channel between the SSCD Type 2 and the CGA is required for cases where
the SSCD type 2 holds the SVD and export of the SVD to the CGA for certification is provided.
Figure 1: SSCD types and modes of operation
2.2 Limits of the TOE
The TOE is a secure signature-creation device (SSCD Type1) according to Directive
1999/93/ec of the European parliament and of the council of 13December 1999 on a
Community framework for electronic signatures [1]. A SSCD is configured software or hardware
used to generate the signature-creation data (SCD).
The TOE provides the following function necessary for devices involved in qualified electronic
signatures:
(1) Generation of the SCD and the correspondent signature-verification data (SVD)
The generation of the SCD/SVD pair by means of the TOE (Type1) requires the export the SCD
into a SSCD of Type 2. Vice versa, signature generation by means of a SSCD Type 2 requires
that the SCD/SVD pair has been generated by and imported from the TOE. Consequently, there
is an interdependence where a SSCD Type 2 forms the environment of the TOE.
The TOE implements all IT security functionality which are necessary to ensure the secrecy of
the SCD. To prevent the unauthorised usage of the SCD the TOE provides user authentication
and access control.
The SSCD protects the SCD during the whole life cycle as to be solely used in the signature-
creation process by the legitimate signatory. The TOE (Type1) generates signatory's SCD and
exports it into a SSCD of Type 2 in a secure manner.
The SVD corresponding to the signatory's SCD will be included in the certificate of the signatory
by the certificate-service-provider (CSP). The TOE will destroy the SCD after export.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 7 version 1.05, EAL 4+
Figure 2 shows the PP scope from the structural perspective. The SSCD, i.e. the TOE,
comprises the underlying hardware, the operating system (OS), the SCD/SVD generation, and
signature-creation functionality. The SSCD Type2 and the CGA (and possibly other
applications) are part of the immediate environment of the TOE. They shall communicate with
the TOE over a trusted channel.
Other
applications
CGA
TOE
Hardware
SCD/SVD generation
Operating system
Immediate
environment
Network
interface
Human interface I/O
Trusted
Channel
SSCD Type2
Trusted
Channel
Figure 2: Scope of the SSCD, structural view
The TOE life cycle is shown in Figure 3. Basically, it consists of a development phase and the
operational phase. This document refers to the operational phase which starts with
personalisation including SCD/SVD generation and SCD export. This phase represents
installation, generation, and start-up in the CC terminology. The main functionality in the usage
phase is SCD/SVD creation including all supporting functionality. The life cycle ends with the
destruction of the SSCD.
Application
design
OS design
HW design
SSCD destruction
SCD/SVD generation
SCD/SVD export
HW fabrication
OS and application implementation
Loading of general application data
Design
Fabrication
Initialisation
Usage
Destruction
Development
phase
Operational
phase
Figure 3. SSCD life cycle
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 8 version 1.05, EAL 4+
Application note: Scope of SSCD PP application
This SSCD PP refers to qualified certificates as electronic attestation of the SVD corresponding
to the signatory's SCD that is created by the TOE.
While the main application scenario of a SSCD will assume a qualified certificate to be used in
combination with a SSCD, there still is a large benefit in the security when such SSCD is
applied in other areas and such application is encouraged. The SSCD PP may as well be
applied to environments where the certificates expressed as 'qualified certificates' in the SSCD
PP do not fulfil the requirements laid down in Annex I and Annex II of the Directive [1].
With this respect the notion of qualified certificates in the PP refers to the fact that when an
instance of a SSCD is used with a qualified certificate, such use is from the technical point of
view eligible for an electronic signature as referred to in Directive [1], article 5, paragraph 1. As
a consequence, this standard does not prevent a device itself from being regarded as a SSCD,
even when used together with a non-qualified certificate.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 9 version 1.05, EAL 4+
3 TOE Security Environment
Assets:
1. SCD. confidentiality of the SCD must be maintained.
2. SVD: integrity of the SVD when it is exported must be maintained.
3. VAD: PIN code or biometrics data entered by the End User to perform a generation
operation (confidentiality and authenticity of the VAD as needed by the authentication
method employed)
4. RAD: Reference PIN code or biometrics authentication reference used to identify and
authenticate the End User (integrity and confidentiality of RAD must be maintained)
Subjects
Subject
Definition
S.User
End user of the TOE which can be identified as S.Admin
S.Admin
User who is in charge to perform the TOE initialisation, TOE personalisation or
other TOE administrative functions.
Threat agents
S.OFFCARD
Attacker. A human or a process acting on his behalf being located outside the
TOE. The main goal of the S.OFFSSCD attacker is to access Application sensitive
information. The attacker has a high level potential attack and knows no secret.
3.1 Assumptions
A.SCD_Import Trustworthy SCD import
The party using the SCD/SVD-pair generated by the TOE will ensure that the confidentiality of
the SCD will be guaranteed until the SCD is under the sole control of the signatory and
A.CGA Trustworthy certification-generation application
The CGA protects the authenticity of the signatory’s name and the SVD in the qualified
certificate by an advanced signature of the CSP.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 10 version 1.05, EAL 4+
3.2 Threats to Security
T.Hack_Phys Exploitation of vulnerabilities in the physical environment
An attacker interacts with the TOE interfaces to exploit vulnerabilities, resulting in arbitrary
security compromises. This threat addresses all the assets.
T.SCD_Divulg Storing ,copying, and releasing of the signature-creation data
An attacker can store, copy the SCD outside the TOE. An attacker can release the SCD during
generation, storage and use for signature-creation in the TOE.
T.SCD_Derive Derive the signature-creation data
An attacker derives the SCD from public known data, such as SVD corresponding to the SCD or
signatures created by means of the SCD or any other data communicated outside the TOE,
which is a threat against the secrecy of the SCD.
T.SCD_Rel Release of the signature-creation data
The SCD are released during generation in the TOE. The TOE is subject to deliberate attacks
by experts possessing a high attack potential with advanced knowledge of security principles
and concepts employed by the TOE.
T.Sig_Forgery Forgery of the electronic signature
An attacker forges the signed data object maybe together with its electronic signature, created
by a SSCD Type2 using the SCD generated by the TOE, and the violation of the integrity of the
signed data object is not detectable by the signatory or by third parties.
T.Sig_Repud Repudiation of signatures
If an attacker can successfully threaten any of the assets, then the non repudation of the
electronic signature is compromised.
The signatory is able to deny to have signed data using the SCD in the TOE under his control
even if the signature is successfully verified with the SVD contained in his un-revoked
certificate.
T.SVD_Forgery Forgery of the signature-verification data
An attacker forges the SVD presented by the TOE to the CGA. This result in loss of SVD
integrity in the certificate of the signatory.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 11 version 1.05, EAL 4+
3.3 Organisational Security Policies
P.CSP_QCert Qualified certificate
The CSP uses a trustworthy CGA to generate the qualified certificate for the SVD generated by
the TOE. The qualified certificates contains at least the elements defined in Annex I of the
Directive, i.e., inter alia the name of the signatory and the SVD matching the SCD generated by
the TOE. The CSP ensures that the use of the TOE is evident with signatures through the
certificate or other publicly available information.
P.SCD_Generate TOE as SCD/SVD-generator of the SSCD provision service
If a party other than the signatory generates the SCD/SVD-pair of a signatory, then
(a) this party will use a SSCD for SCD/SVD-generation,
(b) confidentiality of the SCD will be guaranteed until the SCD is under the sole control
of the signatory and
(c) the SCD will not be used for signature-creation until the SCD is under the sole
control of the signatory.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 12 version 1.05, EAL 4+
4 Security Objectives
This section identifies and defines the security objectives for the TOE and its environment.
Security objectives reflect the stated intent and counter the identified threats, as well as comply
with the identified organisational security policies and assumptions.
4.1 Security Objectives for the TOE
OT.EMSEC_Design Provide physical emanations security
Design and build the TOE in such a way as to control the production of intelligible emanations
within specified limits.
OT.Lifecycle_Security Lifecycle security
The TOE shall detect flaws during the initialisation, and operational usage. The TOE shall
provide safe destruction techniques for the SCD after exportation.
OT.SCD_Secrecy Secrecy of the signature-creation data
The secrecy of the SCD (used for signature generation) is reasonably assured against attacks
with a high attack potential.
OT.SCD_SVD_Corresp Correspondence between SVD and SCD
The TOE shall ensure the correspondence between the SVD and the SCD. The TOE shall
verify on demand the correspondence between the exported SCD and SVD.
OT.SVD_Auth_TOE TOE ensures authenticity of the SVD
The TOE provides means to enable the CGA to verify the authenticity SVD that has been
exported by that TOE.
OT.Tamper_ID Tamper detection
The TOE provides system features that detect physical tampering of a system component, and
use those features to limit security breaches.
OT.Tamper_Resistance Tamper resistance
The TOE prevents or resists physical tampering with specified system devices and components.
OT.SCD_Transfer Secure transfer of SCD between SSCD
The TOE shall ensure the confidentiality of the SCD transferred between SSCDs. The SCD
shall be deleted from the TOE whenever it is exported from that TOE into a SSCD Type 2.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 13 version 1.05, EAL 4+
OT.Init SCD/SVD generation
The TOE provides security features to ensure that the generation of the SCD and the SVD is
invoked by authorised users only.
OT.SCD_Unique Uniqueness of the signature-creation data
The TOE shall ensure the cryptographic quality of the SCD/SVD pair for the qualified electronic
signature. The SCD used for signature generation can practically occur only once and cannot
be reconstructed from the SVD. In that context ‘practically occur once’ means that the
probability of equal SCDs is negligible low.
4.2 Security Objectives for the Environment
OE.SCD_Transfer Secure transfer of SCD between SSCD
The SSCD Type2 shall ensure the confidentiality of the SCD transferred from the TOE. In case
the SVD is also transferred from the TOE to the SSCD Type2, it shall ensure its integrity.
OE.SVD_Auth_Type2 SSCD Type2 ensures authenticity of the SVD
The SSCD Type2 provides means to enable the CGA to verify the authenticity of the SVD that
has been first exported by the TOE to the SSCD Type2 then exported by the SSCD Type2 to
the CGA.
Note: This objective is applied only if SSCD Type2 imports the SVD from the TOE then exports
it to the CGA. In case the TOE exports the SVD directly to the CGA, this Objective is not
applicable.
OE.CGA_QCert Generation of qualified certificates
The CGA generates qualified certificates which include inter alias
(a) the name of the signatory controlling the TOE,
(b) the SVD matching the SCD implemented in the TOE under sole control of the
signatory,
(c) the advanced signature of the CSP.
OE.SVD_Auth_CGA CGA proves the authenticity of the SVD
The CGA verifies that the SSCD is the sender of the received SVD and the integrity of the
received SVD. The CGA verifies the correspondence between the SCD in the SSCD of the
signatory and the SVD in the qualified certificate.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 14 version 1.05, EAL 4+
5 IT Security Requirements
This chapter gives the security functional requirements and the security assurance
requirements for the TOE and the environment.
Security functional requirements components given in section 5.1 “TOE security functional
requirements” excepting FPT_EMSEC.1 which is explicitly stated, are drawn from Common
Criteria part 2 [3]. Some security functional requirements represent extensions to [3].
Operations for assignment, selection and refinement have been made. Operations not
performed in this PP are identified in order to enable instantiation of the PP to a Security Target
(ST).
The TOE security assurance requirements statement given in section 5.2 “TOE Security
Assurance Requirement” is drawn from the security assurance components from Common
Criteria part 3 [4].
Section 5.3 identifies the IT security requirements that are to be met by the IT environment of
the TOE.
The non-IT environment is described in section 5.4.
5.1 TOE Security Functional Requirements
5.1.1 Cryptographic support (FCS)
5.1.1.1 Cryptographic key generation (FCS_CKM.1)
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm [assignment:
cryptographic key generation algorithm] and specified
cryptographic key sizes [assignment: cryptographic key sizes] that
meet the following: List of approved algorithms and parameters.
5.1.1.2 Cryptographic key destruction (FCS_CKM.4)
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method [assignment:
cryptographic key destruction method] that meets the following:
[assignment: list of standards].
Application notes:
The cryptographic key SCD will be destroyed automatically after export.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 15 version 1.05, EAL 4+
5.1.1.3 Cryptographic operation (FCS_COP.1)
FCS_COP.1.1/
CORRESP
The TSF shall perform SCD / SVD correspondence verification in
accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: List of approved
algorithms and parameters.
5.1.2 User data protection (FDP)
5.1.2.1 Subset access control (FDP_ACC.1)
FDP_ACC.1.1/
Initialisation SFP
The TSF shall enforce the Initialisation SFP on generation of
SCD/SVD pair by Administrator.
FDP_ACC.1.1/
SVD Export SFP
The TSF shall enforce the SVD Export SFP on export of SVD by
Administrator.
FDP_ACC.1.1/
SCD Export SFP
The TSF shall enforce the SCD Export SFP on export of SCD by
Administrator.
5.1.2.2 Security attribute based access control (FDP_ACF.1)
The security attributes for the user, TOE components and related status are
User, subject or object the
attribute is associated with
Attribute Status
General attribute
User Role Administrator
Initialisation attribute
User SCD / SVD management authorised, not authorised
Note: The Signatory can be a user role if the evaluated product includes a Type2 or a Type3
SSCD.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 16 version 1.05, EAL 4+
Initialisation SFP
FDP_ACF.1.1/
Initialisation SFP
The TSF shall enforce the Initialisation SFP to objects based on
security attributes “role” and “SCD / SVD management”.
FDP_ACF.1.2/
Initialisation SFP
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
The user with the security attribute “role” set to “Administrator” and
with the security attribute “SCD / SVD management” set to “
authorised” is allowed to generate SCD/SVD pair.
FDP_ACF.1.3/
Initialisation SFP
The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/
Initialisation SFP
The TSF shall explicitly deny access of subjects to objects based on
the rule: none
SVD Export SFP
FDP_ACF.1.1/
SVD Export SFP
The TSF shall enforce the SVD Export SFP to objects based on
General attribute group.
FDP_ACF.1.2/
SVD Export SFP
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
The user with the security attribute “role” set to “Administrator” is
allowed to export SVD.
FDP_ACF.1.3/
SVD Export SFP
The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/
SVD Export SFP
The TSF shall explicitly deny access of subjects to objects based on
the rule: none.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 17 version 1.05, EAL 4+
SCD Export SFP
FDP_ACF.1.1/
SCD Export SFP
The TSF shall enforce the SCD Export SFP to objects based on
General attribute group and Initialisation attribute group.
FDP_ACF.1.2/
SCD Export SFP
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
The user with the security attribute “role” set to “Administrator” whose
security attribute “SCD / SVD management” is set to “authorised” is
allowed to export a SCD.
FDP_ACF.1.3/
SCD Export SFP
The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/
SCD Export SFP
The TSF shall explicitly deny access of subjects to objects based on
the rule:
The user with the security attribute “role” set to “Administrator” or set
to “Signatory” whose security attribute “SCD / SVD management” is
set to “not authorised” is not allowed to export a SCD.
5.1.2.3 Export of user data without security attributes (FDP_ETC.1)
FDP_ETC.1.1/
SCD Export
The TSF shall enforce the SCD Export SFP when exporting user
data, controlled under the SFP(s),outside of the TSC.
FDP_ETC.1.2/
SCD Export
The TSF shall export the user data without the user data's
associated security attributes.
FDP_ETC.1.1/
SVD Export
The TSF shall enforce the SVD Export SFP when exporting user
data, controlled under the SFP(s), outside of the TSC.
FDP_ETC.1.2/
SVD Export
The TSF shall export the user data without the user data's
associated security attributes.
5.1.2.4 Subset residual information protection (FDP_RIP.1)
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource
from the following objects: SCD, VAD, RAD.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 18 version 1.05, EAL 4+
5.1.2.5 Basic data exchange confidentiality (FDP_UCT.1)
FDP_UCT.1.1/ Sender The TSF shall enforce the SCD Export SFP to be able to transmit
objects in a manner protected from unauthorised disclosure.
5.1.2.6 Data exchange integrity (FDP_UIT.1)
FDP_UIT.1.1/
SVD export
The TSF shall enforce the SVD Export SFP to be able to transmit user
data in a manner protected from modification and insertion errors.
FDP_UIT.1.2/
SVD export
The TSF shall be able to determine on receipt of user data, whether
modification and insertion has occurred.
5.1.3 Identification and authentication (FIA)
5.1.3.1 Authentication failure handling (FIA_AFL.1)
FIA_AFL.1.1 The TSF shall detect when [assignment: number] unsuccessful
authentication attempts occur related to consecutive failed
authentication attempts.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has
been met or surpassed, the TSF shall block RAD.
5.1.3.2 User attribute definition (FIA_ATD.1)
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users: RAD.
5.1.3.3 Timing of authentication (FIA_UAU.1)
FIA_UAU.1.1 The TSF shall allow [
1. Identification of the user by means of TSF required by FIA_UID.1.
2. Establishing a trusted channel between the TOE and a SSCD of
Type 2 by means of TSF required by FTP_ITC.1/SCD export. on
behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that user.
5.1.3.4 Timing of identification (FIA_UID.1)
FIA_UID.1.1 The TSF shall allow establishing a trusted channel between the TOE
and a SSCD of Type 2 by means of TSF required by FTP_ITC.1/SCD
export on behalf of the user to be performed before the user is
identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 19 version 1.05, EAL 4+
5.1.4 Security management (FMT)
5.1.4.1 Management of security attributes (FMT_MSA.1)
FMT_MSA.1.1 The TSF shall enforce the Initialisation SFP and SCD Export SFP to
restrict the ability to modify [assignment: other operations] the security
attributes SCD / SVD management to Administrator.
5.1.4.2 Secure security attributes (FMT_MSA.2)
FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for
security attributes.
5.1.4.3 Static attribute initialisation (FMT_MSA.3)
FMT_MSA.3.1 The TSF shall enforce the Initialisation SFP and SCD Export SFP to
provide restrictive default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the Administrator to specify alternative initial
values to override the default values when an object or information is
created.
5.1.4.4 Security roles (FMT_SMR.1)
FMT_SMR.1.1 The TSF shall maintain the roles Administrator.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
5.1.5 Protection of the TSF (FPT)
5.1.5.1 Abstract machine testing (FPT_AMT.1)
FPT_AMT.1.1 The TSF shall run a suite of tests [
selection: during initial start-up,
periodically during normal operation, at the request of an authorised
user, other conditions] to demonstrate the correct operation of the
security assumptions provided by the abstract machine that underlies
the TSF.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 20 version 1.05, EAL 4+
5.1.5.2 TOE Emanation (FPT_EMSEC.1)
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
[assignment: specified limits] enabling access to RAD and SCD.
FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use
the following interface [assignment: type of connection] to gain access
to RAD and SCD.
Application note:
The TOE shall prevent attacks against the SCD and other secret data where the attack is based
on external observable physical phenomena of the TOE. Such attacks may be observable at the
interfaces of the TOE or may origin from internal operation of the TOE or may origin by an
attacker that varies the physical environment under which the TOE operates. The set of
measurable physical phenomena is influenced by the technology employed to implement the
TOE. Examples of measurable phenomena are variations in the power consumption, the timing
of transitions of internal states, electromagnetic radiation due to internal operation, radio
emission.
Due to the heterogeneous nature of the technologies that may cause such emanations,
evaluation against state-of-the-art attacks applicable to the technologies employed by the TOE
is assumed. Examples of such attacks are, but are not limited to, evaluation of TOE’s
electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA),
timing attacks, etc.
5.1.5.3 Failure with preservation of secure state (FPT_FLS.1)
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur: [assignment: list of types of failures in the TSF].
5.1.5.4 Passive detection of physical attack (FPT_PHP.1)
FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering
that might compromise the TSF.
FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical
tampering with the TSF's devices or TSF's elements has occurred.
5.1.5.5 Resistance to physical attack (FPT_PHP.3)
FPT_PHP.3.1 The TSF shall resist [assignment: physical tampering scenarios] to the
[assignment: list of TSF devices/elements] by responding
automatically such that the TSP is not violated.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 21 version 1.05, EAL 4+
5.1.5.6 TSF testing (FPT_TST.1)
FPT_TST.1.1 The TSF shall run a suite of self tests [
selection: during initial
start-up, periodically during normal operation, at the request of
the authorised user, at the conditions ][assignment: conditions
under which self test should occur] to demonstrate the correct
operation of the TSF.
FPT_TST.1.2 The TSF shall provide authorised users with the capability to
verify the integrity of TSF data.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to
verify the integrity of stored TSF executable code.
5.1.6 Trusted path/channels (FTP)
5.1.6.1 Inter-TSF trusted channel (FTP_ITC.1)
FTP_ITC.1.1/
SCD export
The TSF shall provide a communication channel between itself
and a remote trusted IT product that is logically distinct from other
communication channels and provides assured identification of its
end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/
SCD export
The TSF shall permit [selection: the TSF, the remote trusted IT
product] to initiate communication via the trusted channel.
FTP_ITC.1.3/
SCD export
The TSF or the SSCD Type2 shall initiate communication via the
trusted channel for SCD export.
Refinement: The mentioned remote trusted IT product is a SSCD of type 2.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 22 version 1.05, EAL 4+
FTP_ITC.1.1/
SVD export
The TSF shall provide a communication channel between itself
and a remote trusted IT product that is logically distinct from other
communication channels and provides assured identification of its
end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/
SVD export
The TSF shall permit [selection: the TSF, the remote trusted IT
product] to initiate communication via the trusted channel.
FTP_ITC.1.3/
SVD export
The TSF shall initiate communication via the trusted channel for
export SVD.
Refinement: The mentioned remote trusted IT product is the CGA or a SSCD Type2
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 23 version 1.05, EAL 4+
5.2 TOE Security Assurance Requirements
Table 5.1 Assurance Requirements: EAL(4)
Assurance Class Assurance Components
ACM ACM_AUT.1 ACM_CAP.4 ACM_SCP.2
ADO ADO_DEL.2 ADO_IGS.1
ADV
ADV_FSP.2 ADV_HLD.2 ADV_IMP.1 ADV_LLD.1 ADV_RCR.1
ADV_SPM.1
AGD AGD_ADM.1 AGD_USR.1
ALC ALC_DVS.1 ALC_LCD.1 ALC_TAT.1
ATE ATE_COV.2 ATE_DPT.1 ATE_FUN.1 ATE_IND.2
AVA AVA_MSU.3 AVA_SOF.1 AVA_VLA.4
5.2.1 Configuration management (ACM)
5.2.1.1 Partial CM automation (ACM_AUT.1)
ACM_AUT.1.1D The developer shall use a CM system.
ACM_AUT.1.2D The developer shall provide a CM plan.
ACM_AUT.1.1C The CM system shall provide an automated means by which only
authorised changes are made to the TOE implementation
representation.
ACM_AUT.1.2C The CM system shall provide an automated means to support the
generation of the TOE.
ACM_AUT.1.3C The CM plan shall describe the automated tools used in the CM
system.
ACM_AUT.1.4C The CM plan shall describe how the automated tools are used in
the CM system.
5.2.1.2 Generation support and acceptance procedures (ACM_CAP.4)
ACM_CAP.4.1D The developer shall provide a reference for the TOE.
ACM_CAP.4.2D The developer shall use a CM system.
ACM_CAP.4.3D The developer shall provide CM documentation.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 24 version 1.05, EAL 4+
ACM_CAP.4.1C The reference for the TOE shall be unique to each version of the
TOE.
ACM_CAP.4.2C The TOE shall be labelled with its reference.
ACM_CAP.4.3C The CM documentation shall include a configuration list, a CM
plan, and an acceptance plan.
ACM_CAP.4.4C The configuration list shall describe the configuration items that
comprise the TOE.
ACM_CAP.4.5C The CM documentation shall describe the method used to
uniquely identify the configuration items.
ACM_CAP.4.6C The CM system shall uniquely identify all configuration items.
ACM_CAP.4.7C The CM plan shall describe how the CM system is used.
ACM_CAP.4.8C The evidence shall demonstrate that the CM system is operating
in accordance with the CM plan.
ACM_CAP.4.9C The CM documentation shall provide evidence that all
configuration items have been and are being effectively
maintained under the CM system.
ACM_CAP.4.10C The CM system shall provide measures such that only authorised
changes are made to the configuration items.
ACM_CAP.4.11C The CM system shall support the generation of the TOE.
ACM_CAP.4.12C The acceptance plan shall describe the procedures used to
accept modified or newly created configuration items as part of
the TOE.
5.2.1.3 Problem tracking CM coverage (ACM_SCP.2)
ACM_SCP.2.1D The developer shall provide CM documentation.
ACM_SCP.2.1C The CM documentation shall show that the CM system, as a
minimum, tracks the following: the TOE implementation
representation, design documentation, test documentation, user
documentation, administrator documentation, CM documentation,
and security flaws.
ACM_SCP.2.2C The CM documentation shall describe how configuration items
are tracked by the CM system.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 25 version 1.05, EAL 4+
5.2.2 Delivery and operation (ADO)
5.2.2.1 Detection of modification (ADO_DEL.2)
ADO_DEL.2.1D The developer shall document procedures for delivery of the TOE
or parts of it to the user.
ADO_DEL.2.2D The developer shall use the delivery procedures.
ADO_DEL.2.1C The delivery documentation shall describe all procedures that are
necessary to maintain security when distributing versions of the
TOE to a user's site.
ADO_DEL.2.2C The delivery documentation shall describe how the various
procedures and technical measures provide for the detection of
modifications, or any discrepancy between the developer's
master copy and the version received at the user site.
ADO_DEL.2.3C The delivery documentation shall describe how the various
procedures allow detection of attempts to masquerade as the
developer, even in cases in which the developer has sent nothing
to the user's site.
5.2.2.2 Installation, generation, and start-up procedures (ADO_IGS.1)
ADO_IGS.1.1C The documentation shall describe the steps necessary for secure
installation, generation, and start-up of the TOE.
ADO_IGS.1.1D The developer shall document procedures necessary for the
secure installation, generation, and start-up of the TOE.
5.2.3 Development (ADV)
5.2.3.1 Fully defined external interfaces (ADV_FSP.2)
ADV_FSP.2.1D The developer shall provide a functional specification.
ADV_FSP.2.1C The functional specification shall describe the TSF and its external
interfaces using an informal style.
ADV_FSP.2.2C The functional specification shall be internally consistent.
ADV_FSP.2.3C The functional specification shall describe the purpose and method
of use of all external TSF interfaces, providing complete details of
all effects, exceptions and error messages.
ADV_FSP.2.4C The functional specification shall completely represent the TSF.
ADV_FSP.2.5C The functional specification shall include rationale that the TSF is
completely represented.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 26 version 1.05, EAL 4+
5.2.3.2 Security enforcing high-level design (ADV_HLD.2)
ADV_HLD.2.1D The developer shall provide the high-level design of the TSF.
ADV_HLD.2.1C The presentation of the high-level design shall be informal.
ADV_HLD.2.2C The high-level design shall be internally consistent.
ADV_HLD.2.3C The high-level design shall describe the structure of the TSF in
terms of subsystems.
ADV_HLD.2.4C The high-level design shall describe the security functionality
provided by each subsystem of the TSF.
ADV_HLD.2.5C The high-level design shall identify any underlying hardware,
firmware, and/or software required by the TSF with a presentation
of the functions provided by the supporting protection mechanisms
implemented in that hardware, firmware, or software.
ADV_HLD.2.6C The high-level design shall identify all interfaces to the subsystems
of the TSF.
ADV_HLD.2.7C The high-level design shall identify which of the interfaces to the
subsystems of the TSF are externally visible.
ADV_HLD.2.8C The high-level design shall describe the purpose and method of
use of all interfaces to the subsystems of the TSF, providing
details of effects, exceptions and error messages, as appropriate.
ADV_HLD.2.9C The high-level design shall describe the separation of the TOE into
TSP-enforcing and other subsystems.
5.2.3.3 Implementation of the TSF (ADV_IMP.1)
ADV_IMP.1.1D The developer shall provide the implementation representation for
a selected subset of the TSF.
ADV_IMP.1.1C The implementation representation shall unambiguously define the
TSF to a level of detail such that the TSF can be generated without
further design decisions.
ADV_IMP.1.2C The implementation representation shall be internally consistent.
5.2.3.4 Descriptive low-level design (ADV_LLD.1)
ADV_LLD.1.1D The developer shall provide the low-level design of the TSF.
ADV_LLD.1.1C The presentation of the low-level design shall be informal.
ADV_LLD.1.2C The low-level design shall be internally consistent.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 27 version 1.05, EAL 4+
ADV_LLD.1.3C The low-level design shall describe the TSF in terms of modules.
ADV_LLD.1.4C The low-level design shall describe the purpose of each module.
ADV_LLD.1.5C The low-level design shall define the interrelationships between
the modules in terms of provided security functionality and
dependencies on other modules.
ADV_LLD.1.6C The low-level design shall describe how each TSP-enforcing
function is provided.
ADV_LLD.1.7C The low-level design shall identify all interfaces to the modules of
the TSF.
ADV_LLD.1.8C The low-level design shall identify which of the interfaces to the
modules of the TSF are externally visible.
ADV_LLD.1.9C The low-level design shall describe the purpose and method of use
of all interfaces to the modules of the TSF, providing details of
effects, exceptions and error messages, as appropriate.
ADV_LLD.1.10C The low-level design shall describe the separation of the TOE into
TSP-enforcing and other modules.
5.2.3.5 Informal correspondence demonstration (ADV_RCR.1)
ADV_RCR.1.1D The developer shall provide an analysis of correspondence
between all adjacent pairs of TSF representations that are
provided.
ADV_RCR.1.1C For each adjacent pair of provided TSF representations, the
analysis shall demonstrate that all relevant security functionality of
the more abstract TSF representation is correctly and completely
refined in the less abstract TSF representation.
5.2.3.6 Informal TOE security policy model (ADV_SPM.1)
ADV_SPM.1.1D The developer shall provide a TSP model.
ADV_SPM.1.1C The TSP model shall be informal.
ADV_SPM.1.2C The TSP model shall describe the rules and characteristics of all
policies of the TSP that can be modeled.
ADV_SPM.1.2D The developer shall demonstrate correspondence between the
functional specification and the TSP model.
ADV_SPM.1.3C The TSP model shall include a rationale that demonstrates that it
is consistent and complete with respect to all policies of the TSP
that can be modeled.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 28 version 1.05, EAL 4+
ADV_SPM.1.4C The demonstration of correspondence between the TSP model
and the functional specification shall show that all of the security
functions in the functional specification are consistent and
complete with respect to the TSP model.
5.2.4 Guidance documents (AGD)
5.2.4.1 Administrator guidance (AGD_ADM.1)
AGD_ADM.1.1D The developer shall provide administrator guidance addressed to
system administrative personnel.
AGD_ADM.1.1C The administrator guidance shall describe the administrative
functions and interfaces available to the administrator of the TOE.
AGD_ADM.1.2C The administrator guidance shall describe how to administer the
TOE in a secure manner.
AGD_ADM.1.3C The administrator guidance shall contain warnings about functions
and privileges that should be controlled in a secure processing
environment.
AGD_ADM.1.4C The administrator guidance shall describe all assumptions
regarding user behaviour that are relevant to secure operation of
the TOE.
AGD_ADM.1.5C The administrator guidance shall describe all security parameters
under the control of the administrator, indicating secure values as
appropriate.
AGD_ADM.1.6C The administrator guidance shall describe each type of security-
relevant event relative to the administrative functions that need to
be performed, including changing the security characteristics of
entities under the control of the TSF.
AGD_ADM.1.7C The administrator guidance shall be consistent with all other
documentation supplied for evaluation.
AGD_ADM.1.8C The administrator guidance shall describe all security requirements
for the IT environment that are relevant to the administrator.
5.2.4.2 User guidance (AGD_USR.1)
AGD_USR.1.1D The developer shall provide user guidance.
AGD_USR.1.1C The user guidance shall describe the functions and interfaces
available to the non-administrative users of the TOE.
AGD_USR.1.2C The user guidance shall describe the use of user-accessible
security functions provided by the TOE.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 29 version 1.05, EAL 4+
AGD_USR.1.3C The user guidance shall contain warnings about user-accessible
functions and privileges that should be controlled in a secure
processing environment.
AGD_USR.1.4C The user guidance shall clearly present all user responsibilities
necessary for secure operation of the TOE, including those related
to assumptions regarding user behaviour found in the statement of
TOE security environment.
AGD_USR.1.5C The user guidance shall be consistent with all other documentation
supplied for evaluation.
AGD_USR.1.6C The user guidance shall describe all security requirements for the
IT environment that are relevant to the user.
5.2.5 Life cycle support (ALC)
5.2.5.1 Identification of security measures (ALC_DVS.1)
ALC_DVS.1.1D The developer shall produce development security documentation.
ALC_DVS.1.1C The development security documentation shall describe all the
physical, procedural, personnel, and other security measures that
are necessary to protect the confidentiality and integrity of the TOE
design and implementation in its development environment.
ALC_DVS.1.2C The development security documentation shall provide evidence
that these security measures are followed during the development
and maintenance of the TOE.
5.2.5.2 Developer defined life-cycle model (ALC_LCD.1)
ALC_LCD.1.1C The life-cycle definition documentation shall describe the model
used to develop and maintain the TOE.
ALC_LCD.1.1D The developer shall establish a life-cycle model to be used in the
development and maintenance of the TOE.
ALC_LCD.1.2C The life-cycle model shall provide for the necessary control over
the development and maintenance of the TOE.
ALC_LCD.1.2D The developer shall provide life-cycle definition documentation.
5.2.5.3 Well-defined development tools (ALC_TAT.1)
ALC_TAT.1.1C All development tools used for implementation shall be well-
defined.
ALC_TAT.1.1D The developer shall identify the development tools being used for
the TOE.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 30 version 1.05, EAL 4+
ALC_TAT.1.2C The documentation of the development tools shall unambiguously
define the meaning of all statements used in the implementation.
ALC_TAT.1.2D The developer shall document the selected implementation-
dependent options of the development tools.
ALC_TAT.1.3C The documentation of the development tools shall unambiguously
define the meaning of all implementation-dependent options.
5.2.6 Tests (ATE)
5.2.6.1 Analysis of coverage (ATE_COV.2)
ATE_COV.2.1C The analysis of the test coverage shall demonstrate the
correspondence between the tests identified in the test
documentation and the TSF as described in the functional
specification.
ATE_COV.2.1D The developer shall provide an analysis of the test coverage.
ATE_COV.2.2C The analysis of the test coverage shall demonstrate that the
correspondence between the TSF as described in the functional
specification and the tests identified in the test documentation is
complete.
5.2.6.2 Testing: high-level design (ATE_DPT.1)
ATE_DPT.1.1C The depth analysis shall demonstrate that the tests identified in the
test documentation are sufficient to demonstrate that the TSF
operates in accordance with its high-level design.
ATE_DPT.1.1D The developer shall provide the analysis of the depth of testing.
5.2.6.3 Functional testing (ATE_FUN.1)
ATE_FUN.1.1C The test documentation shall consist of test plans, test procedure
descriptions, expected test results and actual test results.
ATE_FUN.1.1D The developer shall test the TSF and document the results.
ATE_FUN.1.2C The test plans shall identify the security functions to be tested and
describe the goal of the tests to be performed.
ATE_FUN.1.2D The developer shall provide test documentation.
ATE_FUN.1.3C The test procedure descriptions shall identify the tests to be
performed and describe the scenarios for testing each security
function. These scenarios shall include any ordering dependencies
on the results of other tests.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 31 version 1.05, EAL 4+
ATE_FUN.1.4C The expected test results shall show the anticipated outputs from a
successful execution of the tests.
ATE_FUN.1.5C The test results from the developer execution of the tests shall
demonstrate that each tested security function behaved as
specified.
5.2.6.4 Independent testing - sample (ATE_IND.2)
ATE_IND.2.1D The developer shall provide the TOE for testing.
ATE_IND.2.1C The TOE shall be suitable for testing.
ATE_IND.2.2C The developer shall provide an equivalent set of resources to
those that were used in the developer's functional testing of the
TSF.
5.2.7 Vulnerability assessment (AVA)
5.2.7.1 Analysis and testing for insecure states (AVA_MSU.3)
AVA_MSU.3.1D The developer shall provide guidance documentation.
AVA_MSU.3.2D The developer shall document an analysis of the guidance
documentation.
AVA_MSU.3.1C The guidance documentation shall identify all possible modes of
operation of the TOE (including operation following failure or
operational error), their consequences and implications for
maintaining secure operation.
AVA_MSU.3.2C The guidance documentation shall be complete, clear, consistent
and reasonable.
AVA_MSU.3.3C The guidance documentation shall list all assumptions about the
intended environment.
AVA_MSU.3.4C The guidance documentation shall list all requirements for external
security measures (including external procedural, physical and
personnel controls).
AVA_MSU.3.5C The analysis documentation shall demonstrate that the guidance
documentation is complete.
5.2.7.2 Strength of TOE security function evaluation (AVA_SOF.1)
AVA_SOF.1.1D The developer shall perform a strength of TOE security function
analysis for each mechanism identified in the ST as having a
strength of TOE security function claim.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 32 version 1.05, EAL 4+
AVA_SOF.1.1C For each mechanism with a strength of TOE security function
claim the strength of TOE security function analysis shall show that
it meets or exceeds the minimum strength level defined in the
PP/ST.
AVA_SOF.1.2C For each mechanism with a specific strength of TOE security
function claim the strength of TOE security function analysis shall
show that it meets or exceeds the specific strength of function
metric defined in the PP/ST.
5.2.7.3 Highly resistant (AVA_VLA.4)
AVA_VLA.4.1D The developer shall perform and document an analysis of the TOE
deliverables searching for ways in which a user can violate the
TSP.
AVA_VLA.4.2D The developer shall document the disposition of identified
vulnerabilities.
AVA_VLA.4.1C The documentation shall show, for all identified vulnerabilities, that
the vulnerability cannot be exploited in the intended environment
for the TOE.
AVA_VLA.4.2C The documentation shall justify that the TOE, with the identified
vulnerabilities, is resistant to obvious penetration attacks.
AVA_VLA.4.3C The evidence shall show that the search for vulnerabilities is
systematic.
AVA_VLA.4.4C The analysis documentation shall provide a justification that the
analysis completely addresses the TOE deliverables.
5.3 Security Requirements for the IT Environment
5.3.1 SCD import (SSCD type2)
5.3.1.1 Subset access control (FDP_ACC.1)
FDP_ACC.1.1/
SCD Import SFP
The TSF shall enforce the SCD Import SFP on import of SCD by User.
FDP_ACC.1.1/
SVD Transfer SFP
The TSF shall enforce the SVD Transfer SFP on import and on export
of SVD by User.
Application note:
FDP_ACC.1/SVD Transfer SFP will be required only, if the SSCD Type2 is to import the SVD
from the TOE so it will be exported to the CGA for certification.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 33 version 1.05, EAL 4+
5.3.1.2 Import of user data without security attributes (FDP_ITC.1)
FDP_ITC.1.1/SCD The TSF shall enforce the SCD Import SFP when importing user data,
controlled under the SFP, from outside of the TSC.
FDP_ITC.1.2/SCD The TSF shall ignore any security attributes associated with the user
data when imported from outside the TSC.
FDP_ITC.1.3/SCD The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TSC: SCD shall be sent by
an authorised SSCD.
5.3.1.3 Basic data exchange confidentiality (FDP_UCT.1)
FDP_UCT.1.1/ Receiver The TSF shall enforce the SCD Import SFP to be able to receive
objects in a manner protected from unauthorised disclosure.
5.3.1.4 Inter-TSF trusted channel (FTP_ITC.1)
FTP_ITC.1.1/
SCD Import
The TSF shall provide a communication channel between itself
and a remote trusted IT product that is logically distinct from other
communication channels and provides assured identification of its
end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/
SCD Import
The TSF shall permit [selection: the TSF, the remote trusted IT
product] to initiate communication via the trusted channel.
FTP_ITC.1.3/
SCD Import
The TSF or the remote trusted IT shall initiate communication via
the trusted channel for SCD import.
Refinement: The mentioned remote trusted IT product is a SSCD of type 1.
FTP_ITC.1.1/
SVD Transfer
The TSF shall provide a communication channel between itself
and a remote trusted IT product that is logically distinct from other
communication channels and provides assured identification of its
end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/
SVD Transfer
The TSF shall permit [selection: the TSF, the remote trusted IT
product] to initiate communication via the trusted channel.
FTP_ITC.1.3/
SVD Transfer
The TSF or the trusted IT shall initiate communication via the
trusted channel for transfer of SVD.
Refinement: The mentioned remote trusted IT product is a SSCD of type 1.for SVD import and
the CGA for the SVD export.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 34 version 1.05, EAL 4+
Application note:
FTP_ITC.1/SVD Transfer will be required only, if the TOE is to import the SVD from a SSCD
Type1 so it will be exported to the CGA for certification.
5.3.2 Certification generation application (CGA)
5.3.2.1 Cryptographic key distribution (FCS_CKM.2)
FCS_CKM.2.1/ CGA The TSF shall distribute cryptographic keys in accordance with a
specified cryptographic key distribution method qualified certificate
that meets the following: List of approved algorithms and
parameters.
5.3.2.2 Cryptographic key access (FCS_CKM.3)
FCS_CKM.3.1/ CGA The TSF shall perform import the SVD in accordance with a specified
cryptographic key access method import through a secure channel
that meets the following: [assignment: list of standards].
5.3.2.3 Data exchange integrity (FDP_UIT.1)
FDP_UIT.1.1/
SVD import
The TSF shall enforce the SVD import SFP to be able to receive user
data in a manner protected from modification and insertion errors.
FDP_UIT.1.2/
SVD import
The TSF shall be able to determine on receipt of user data, whether
modification and insertion has occurred.
5.3.2.4 Inter-TSF trusted channel (FTP_ITC.1)
FTP_ITC.1.1/
SVD import
The TSF shall provide a communication channel between itself
and a remote trusted IT product that is logically distinct from other
communication channels and provides assured identification of its
end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/
SVD import
The TSF shall permit [selection: the TSF, the remote trusted IT
product] to initiate communication via the trusted channel.
FTP_ITC.1.3/
SVD import
The TSF shall initiate communication via the trusted channel for
import SVD.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 35 version 1.05, EAL 4+
5.4 Security Requirements for the Non-IT Environment
R.Administrator_Guide Application of Administrator Guidance
The implementation of the requirements of the Directive, ANNEX II “Requirements for
certification-service-providers issuing qualified certificates”, literal (e), stipulates employees of
the CSP or other relevant entities to follow the administrator guidance provided for the TOE.
Appropriate supervision of the CSP or other relevant entities shall ensures the ongoing
compliance.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 36 version 1.05, EAL 4+
6 Rationale
6.1 Introduction
The tables in sub-sections 6.2.1 “Security Objectives Coverage” and 6.3.1 “Security
Requirement Coverage” provide the mapping of the security objectives and security
requirements for the TOE.
6.2 Security Objectives Rationale
6.2.1 Security Objectives Coverage
Table 6.1 : Security Environment to Security Objectives Mapping
Threats - Assumptions
- Policies / Security
objectives
OT.EMSEC_Design
OT.lifecycle_Security
OT.SCD_Transfer
OT.SCD_Secrecy
OT.SCD_SVD_Corresp
OT.SVD_Auth_TOE
OT.Tamper_ID
OT.Tamper_Resistance
OT.Init
OT.SCD_Unique
OE.SCD_Transfer
OE.SVD_Auth_Type2
OE.CGA_QCert
OE.SVD_Auth_CGA
T.Hack_Phys x x x x
T.SCD_Divulg x x x x
T.SCD_Derive x
T.SCD_Rel x
T.SVD_Forgery x x x
T.Sig_Forgery x x x x x x x x x x x x
T.Sig_Repud x x x x x x x x x x x x x
A.SCD_Import x
A.CGA x x
P.CSP_Qcert x x
P.SCD_Generate x x x
6.2.2 Security Objectives Sufficiency
6.2.2.1 Policies and Security Objective Sufficiency
P.CSP_QCert (CSP generates qualified certificates) establishes the qualified certificate for
the signatory and provides that the SVD matches the SCD that is implemented in the SSCD
under sole control of this signatory. P.CSP_QCert is addressed by the TOE by
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 37 version 1.05, EAL 4+
OT.SCD_SVD_Corresp concerning the correspondence between the SVD and the SCD, in the
TOE IT environment, by OE.CGA_QCert for generation of qualified certificates by the CGA,
respectively.
P.SCD_Generate (TOE as SCD/SVD-generator of the SSCD provision service) addresses
the requirement of confidentiality of the signatory’s SCD during the generation process. This
requirement is derived form the Directive [1], Annex II, literal (g). OT.SCD_Secrecy and
OT.SCD_Transfer address the confidentiality of the SCD during generation and, if applicable,
the transfer between the SSCD of the CSP and the SSCD of the signatory. OT.Init provides that
SSCD initialisation is restricted to authorised users. Threats and Security Objective Sufficiency
6.2.2.2 Threats and Security Objective Sufficiency
T.Hack_Phys (Exploitation of vulnerabilities in the physical environment) deals with
physical attacks exploiting vulnerabilities in the environment of the TOE. OT.SCD_Secrecy
preserves the secrecy of the SCD. Physical attacks through the TOE interfaces are countered
by OT.EMSEC_Design. OT.Tamper_ID and OT.Tamper_Resistance counter the threat
T.Hack_Phys by detecting and by resisting tamper attacks.
T.SCD_Divulg (Storing and copying and releasing of the signature-creation data)
addresses the threat against the legal validity of electronic signature due to storage and copying
of SCD outside the TOE, as expressed in the Directive [1], recital (18). This threat is countered
by OT.SCD_Secrecy which assures the secrecy of the SCD used by Type2 SSCD for signature
generation. OT.SCD_Transfer and OE.SCD_Transfer insure the confidentiality of the SCD
during it’s transfer between the TOE and a SSCD Type2. OT.SCD_Transfer ensures that the
SCD is deleted by TOE after it is exported TOE Type 2. OT.Init ensures that only authorized
users cabn generate the SCD so to counteract it’s divulgation.
T.SCD_Derive (Derive the signature-creation data) deals with attacks on the SCD via public
known data produced by the TOE. This threat is countered by OT.SCD_Unique that provides
cryptographic secure generation of the SCD/SVD-pair.
T.SCD_Rel (Release of the signature-creation data) addresses the threat of compromising
the SCD during generation in the TOE. This threat is addressed by OT.SCD_Secrecy in order to
reasonably assure the secrecy of the SCD used for signature generation.
T.Sig_Forgery (Forgery of the electronic signature) deals with non-detectable forgery of the
electronic signature. This threat is in general addressed by OE.CGA_QCert (Generation of
qualified certificates), OT.SCD_SVD_Corresp (Correspondence between SVD and SCD),
OT.SVD_Auth_TOE (TOE ensures authenticity of the SVD), OE.SVD_Auth_CGA (CGA proves
the authenticity of the SVD), OT.SCD_Secrecy (Secrecy of the signature-creation data),
OT.SCD_Transfer and OE_SCD_Transfer (Secure transfer of SCD between SSCD),
OT.EMSEC_Design (Provide physical emanations security), OT.Tamper_ID (Tamper detection),
OT.Tamper_Resistance (Tamper resistance) and OT.Lifecycle_Security (Lifecycle security), as
follows:
The combination of OE.CGA_QCert, OT.SCD_SVD_Corresp, OT.SVD_Auth_TOE, and
OE.SVD_Auth_CGA provides the integrity and authenticity of the SVD that is used by the
signature verification process. OT.Sig_Secure, OT.SCD_Secrecy, OT.SCD_Transfer,
OT.EMSEC_Design, OT.Tamper_ID, OT.Tamper_Resistance, and OT.Lifecycle_Security
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 38 version 1.05, EAL 4+
ensure the confidentiality of the SCD sent to the signatory's SSCD and thus prevent forgery of
the electronic signature by means of knowledge of the SCD.
If the SVD is exported to a SSCD Type2, OE.SVD_Auth_Type2 participates to the provision of
the integrity and authenticity of the SVD
T.Sig_Repud (Repudiation of electronic signatures) deals with the repudiation of signed
data by the signatory, although the electronic signature is successfully verified with the SVD
contained in his un-revoked certificate. This threat is in general addressed by OE.CGA_QCert
(Generation of qualified certificates), OT.SVD_Auth_TOE (TOE ensures authenticity of the
SVD), OE.SVD_Auth_CGA (CGA proves the authenticity of the SVD), OT.SCD_SVD_Corresp
(Correspondence between SVD and SCD), OT.SCD_Unique (Uniqueness of the signature-
creation data), OT.SCD_Transfer and OE.SCD_Transfer (Secure transfer of SCD between
SSCD), OT.SCD_Secrecy (Secrecy of the signature-creation data), OT.EMSEC_Design
(Provide physical emanations security), OT.Tamper_ID (Tamper detection),
OT.Tamper_Resistance (Tamper resistance), OT.Lifecycle_Security (Lifecycle security),
If the SVD is exported to a SSCD Type2, OE.SVD_Auth_Type2 addresses also the threat
(SSCD Type2 ensures authenticity of the SVD)
OE.CGA_QCert ensures qualified certificates which allow to identify the signatory and thus to
extract the SVD of the signatory. OE.CGA_QCert, OT.SVD_Auth_TOE and
OE.SVD_Auth_CGA ensure the integrity of the SVD. If the SVD is exported to a SSCD Type2,
OE.SVD_Auth_Type2 also participates to ensure the integrity of the SVD. OE.CGA_QCert and
OT.SCD_SVD_Corresp ensure that the SVD in the certificate correspond to the SCD that is
implemented by the SSCD of the signatory. OT.SCD_Unique provides that the signatory’s SCD
can practically occur just once. OT.Sig_Secure, OT.SCD_Transfer, OE.SCD_Transfer,
OT.SCD_Secrecy, OT.Tamper_ID, OT.Tamper_Resistance, OT.EMSEC_Design, and
OT.Lifecycle_Security ensure the confidentiality of the SCD sent to the signatory's SSCD.
T.SVD_Forgery (Forgery of the signature-verification data) deals with the forgery of the
SVD exported by the TOE to the CGA for the generation of the certificate. T.SVD_Forgery is
addressed by OT.SVD_Auth_TOE which ensures that the TOE sends the SVD in a verifiable
form to the CGA, as well as by OE.SVD_Auth_CGA which provides verification of SVD
authenticity by the CGA. In case the SVD is first exported a SSCD Type2, T.SVD_Forgery is
also addressed by OE.SVD_Auth_Type2 which ensures that the TOE sends the SVD in a
verifiable form to the CGA.
6.2.2.3 Assumptions and Security Objective Sufficiency
A.SCD_Import (Trustworthy SCD import) protects the confidentiality of the SCD while it is
imported into the SSCD Type2. This is addressed by OE_SCD_Transfer which ensures the
confidentiality of the SCD while it is transferred to the SSCD Type2. In case the SVD is also
exported to the SSCD type2 (for re-exportation to the CGA), the integrity of the SVD must be
maintained. This is also ensured by OE.SCD_Transfer.
A.CGA (Trustworthy certification-generation application) establishes the protection of the
authenticity of the signatory's name and the SVD in the qualified certificate by the advanced
signature of the CSP by means of the CGA. This is addressed by OE.CGA_QCert (Generation
of qualified certificates) which ensures the generation of qualified certificates and by
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 39 version 1.05, EAL 4+
OE.SVD_Auth_CGA (CGA proves the authenticity of the SVD) which ensures the verification of
the integrity of the received SVD and the correspondence between the SVD and the SCD that is
implemented by the SSCD of the signatory.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 40 version 1.05, EAL 4+
6.3 Security Requirements Rationale
6.3.1 Security Requirement Coverage
Table 6.2 : Functional Requirement to TOE Security Objective Mapping
TOE Security Functional
Requirement / TOE Security
objectives
OT.EMSEC_Design
OT.lifecycle_Security
OT.SCD_Transfer
OT.SCD_Secrecy
OT.SCD_SVD_Corresp
OT.SVD_Auth_TOE
OT.Tamper_ID
OT.Tamper_Resistance
OT.Init
OT.SCD_Unique
FCS_CKM.1 x x
FCS_CKM.4 x x x
X
FCS_COP.1/CORRESP x
FDP_ACC.1/Initialisation SFP x
X
x
FDP_ACC.1/SVD Export SFP x
FDP_ACC.1/SCD Export SFP x
FDP_ACF.1/Initialisation SFP x x
X
FDP_ACF.1/SVD Export SFP x
FDP_ACF.1/SCD Export SFP x
X
FDP_ETC.1/SVD Export x
X
FDP_ETC.1/SCD Export x
X
FDP_RIP.1 x
FDP_UCT.1/Sender x
FDP_UIT.1/SVD Export x
FIA_AFL.1 x
FIA_ATD.1 x
FIA_UAU.1 x
FIA_UID.1 x
FMT_MSA.1 x x
FMT_MSA.2 x
FMT_MSA.3 x x x
FMT_SMR.1 x x
FPT_AMT.1 x x
FPT_EMSEC.1 x
FPT_FLS.1 x
FPT_PHP.1 x
FPT_PHP.3 x
FPT_TST.1 x
FTP_ITC.1/SCD Export x
FTP_ITC.1/SVD Export x
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 41 version 1.05, EAL 4+
Table 6.3: IT Environment Functional requirement to Environment Security Objective Mapping
Environment Security
Requirement / Environment
Security objectives
OE.SCD_Transfer
OE.SVD_Auth_Type2
OE.CGA_QCert
OE.SVD_Auth_CGA
FDP_ACC.1/SCD Import SFP x
X
FDP_ACC.1/SVD Transfer SFP x
X
FDP_ITC.1/SCD x
X
FDP_UCT.1/Receiver x
X
FTP_ITC.1/SCD Import x
X
FTP_ITC.1/SVD Transfer x
X
FCS_CKM.2/CGA x
X
FCS_CKM.3/CGA x
X
FDP_UIT.1/SVD Import x
X
FTP_ITC.1/SVD Import x
X
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 42 version 1.05, EAL 4+
Table 6.4 : Assurance Requirement to Security Objective Mapping
Objectives Requirements
Security Assurance Requirements
OT.Lifecycle_Security ALC_DVS.1, ALC_LCD.1, ALC_TAT.1, ADO_DEL.2, ADO_IGS.1
OT.SCD_Secrecy AVA_MSU.3, AVA_SOF.1, AVA_VLA.4
Security Objectives
ACM_AUT.1, ACM_CAP.4, ACM_SCP.2, ADO_DEL.2,
ADO_IGS.1, ADV_FSP.2, ADV_HLD.2, ADV_IMP.1, ADV_LLD.1,
ADV_RCR.1, ADV_SPM.1, AGD_ADM.1, AGD_USR.1,
ATE_COV.2, ATE_DPT.1, ATE_FUN.1, ATE_IND.2
6.3.2 Security Requirements Sufficiency
6.3.2.1 TOE Security Requirements Sufficiency
OT.EMSEC_Design (Provide physical emanations security) covers that no intelligible
information is emanated. This is provided by FPT_EMSEC.1.
OT.Init (SCD/SVD generation) addresses that generation of a SCD/SVD pair requires proper
user authentication. FIA_ATD.1 define RAD as the corresponding user attribute. The TSF
specified by FIA_UID.1 and FIA_UAU.1 provide user identification and user authentication prior
to enabling access to authorised functions. The attributes of the authenticated user are provided
by FMT_MSA.1, FMT_MSA.3, for static attribute initialisation. Access control is provided by
FDP_ACC.1/Initialisation SFP and FDP_ACF.1/Initialisation SFP. Effort to bypass the access
control by a frontal exhaustive attack is blocked by FIA_AFL.1.
OT.Lifecycle_Security (Lifecycle security) is provided by the security assurance
requirements ALC_DVS.1, ALC_LCD.1, ALC_TAT.1,ADO_DEL.2, and ADO_IGS.1 that ensure
the lifecycle security during the development, configuration and delivery phases of the TOE.
The test functions FPT_TST.1 and FPT_AMT.1 provide failure detection throughout the
lifecycle. FCS_CKM.4 provides secure destruction of the SCD to conclude the operational
usage of the TOE as SSCD.
OT.SCD_Secrecy (Secrecy of signature-creation data) counters that, with reference to
recital (18) of the Directive, storage or copying of SCD causes a threat to the legal validity of
electronic signatures. OT.SCD_Secrecy is provided by the security functions specified by
FDP_ACC.1/Initialisation SFP and FDP_ACF.1/Initialisation SFP that ensure that only
authorised user can initialise the TOE and create or load the SCD. The authentication and
access management functions specified by FMT_MSA.1, and FMT_SMR.1 ensure that only the
signatory can use the SCD and thus avoid that an attacker may gain information on it.
The security functions specified by FDP_RIP.1 and FCS_CKM.4 ensure that residual
information on SCD is destroyed after the SCD has been use for signature creation and that
destruction of SCD leaves no residual information. Cryptographic quality of SCD/SVD pair shall
prevent disclosure of SCD by cryptographic attacks using the publicly known SVD.
FPT_AMT.1 and FPT_FLS.1 test the working conditions of the TOE and guarantee a secure
state when integrity is violated and thus assure that the specified security functions are
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 43 version 1.05, EAL 4+
operational. An example where compromising error conditions are countered by FPT_FLS is
differential fault analysis (DFA).
The assurance requirements ADV_IMP.1 by requesting evaluation of the TOE implementation,
AVA_SOF HIGH by requesting strength of function high for security functions, and AVA_VLA.4
by requesting that the TOE resists attacks with a high attack potential assure that the security
functions are efficient.
OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) addresses that the SVD
corresponds to the SCD implemented by the TOE. This is provided by the algorithms specified
by FCS_CKM.1 to generate corresponding SVD/SCD pairs. Cryptographic correspondence is
provided by FCS_COP.1/CORRESP
OT.SCD_Transfer (Secure transfer of SCD between SSCD) is provided by
FDP_UCT.1/Sender that ensures that a trusted channel is provided and that confidentiality is
maintained.
Security functions specified by FDP_ACC.1/SCD Export SFP, FMT_MSA.2; FMT_MSA.3,
FMT_SMR.1, FDP_ACF.1/SCD Export SFP, and FDP_ETC.1/SCD Export ensure that transfer
of SCDs is restricted to administrators. This supports the confidentiality-oriented functions.
Security functions complying with FDP_ETC.1/SCD Export and FTP_ITC.1/ SCD Export ensure
that only TOE may export the SCD. Security function specified by FCS_CKM.4 destroy the
SCD, once exported from the TOE.
OT.SCD_Unique (Uniqueness of the signature-creation data) implements the requirement of
practically unique SCD as laid down in the Directive [1], Annex III, article 1(a), which is provided
by the cryptographic algorithms specified by FCS_CKM.1.
OT.SVD_Auth_TOE (TOE ensures authenticity of the SVD) is provided by a trusted channel
guaranteeing SVD origin and integrity by means of FTP_ITC.1/SVD Export and
FDP_UIT.1/SVD Export. The cryptographic algorithms specified by
FDP_ACC.1/SVD Export SFP, FDP_ACF.1/SVD Export SFP and FDP_ETC.1/SVD Export
ensure that only authorised user can export the SVD to the CGA.
OT.Tamper_ID (Tamper detection) is provided by FPT_PHP.1 by the means of passive
detection of physical attacks.
OT.Tamper_Resistance (Tamper resistance) is provided by FPT_PHP.3 to resist physical
attacks.
6.3.2.2 TOE Enviroment Security Requirements Sufficiency
OE.SCD_Transfer (Secure transfer of SCD between SSCD) is provided by FDP_ITC.1/SCD
, FDP_UCT.1/Receiver and FTP_ITC.1/SCD Import that ensure that a trusted channel is
provided and that confidentiality is maintained.
Security functions specified by FDP_ACC.1/SCD Import SFP ensures that transfer of SCDs is
restricted to administrators. This supports the confidentiality-oriented functions.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 44 version 1.05, EAL 4+
OE.SVD_Auth_Type2 (SSCD Type2 ensures authenticity of the SVD) is provided by a
trusted channel guaranteeing SVD origin and integrity by means of FTP_ITC.1/SVD Transfer.
FDP_ACC.1/SVD Transfer SFP ensures that only authorised user can Import the SVD from the
TOE and Export the SVD to the CGA.
OE.CGA_QCert (Generation of qualified certificates) addresses the requirement of qualified
certificates. The functions specified by FCS_CKM.2/CGA provide the cryptographic key
distribution method. The functions specified by FCS_CKM.3/CGA and FTP_ITC.1/SVD Import
ensure that the CGA imports the SVD using a secure channel and a secure key access method.
OE.SVD_Auth_CGA (CGA proves the authenticity of the SVD) is provided by
FTP_ITC.1/SVD.Import which assures identification of the sender and by FDP_UIT.1/ SVD
Import. which guarantees it’s integrity
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 45 version 1.05, EAL 4+
6.4 Dependency Rationale
6.4.1 Functional and Assurance Requirements Dependencies
The functional and assurance requirements dependencies for the TOE are completely fulfilled.
The functional requirements dependencies for the TOE environment are not completely fulfilled
(see section 6.4.2 for justification).
Table 6.5 Functional and Assurance Requirements Dependencies
Requirement Dependencies
Functional Requirements
FCS_CKM.1 FCS_COP.1/CORRESP, FCS_CKM.4, FMT_MSA.2
FCS_CKM.4 FCS_CKM.1, FMT_MSA.2
FCS_COP.1/
CORRESP
FCS_CKM.1, FCS_CKM.4, FMT_MSA.2
FDP_ACC.1/
Initialisation SFP
FDP_ACF.1/Initialisation SFP
FDP_ACC.1/
SCD Export SFP
FDP_ACF.1/SCD Export SFP
FDP_ACC.1/
SVD Export SFP
FDP_ACF.1/SVD Export SFP
FDP_ACF.1/
Initialisation SFP
FDP_ACC.1/Initialisation SFP, FMT_MSA.3
FDP_ACF.1/
SCD Export SFP
FDP_ACC.1/SCD Export SFP, FMT_MSA.3
FDP_ACF.1/
SVD Export SFP
FDP_ACC.1/SVD Export SFP, FMT_MSA.3
FDP_ETC.1/
SCD Export SFP
FDP_ACC.1/ SCD Export SFP
FDP_ETC.1/
SVD Export SFP
FDP_ACC.1/ SVD Export SFP
FDP_RIP.1 None
FDP_UCT.1/
Sender
FTP_ITC.1/SCD Export, FDP_ACC.1/ SCD Export SFP
FDP_UIT.1/
SVD Export
FTP_ITC.1/SVD Export, FDP_ACC.1/SVD Export
FIA_AFL.1 FIA_UAU.1
FIA_ATD.1 None
FIA_UAU.1 FIA_UID.1
FIA_UID.1 None
FMT_MSA.1 FDP_ACC.1/Initialisation SFP, FMT_SMR.1
FMT_MSA.2
ADV_SPM.1, FDP_ACC.1/Personalisation SFP, FMT_SMR.1
FMT_MSA.1
FMT_MSA.3 FMT_MSA.1, FMT_SMR.1
FMT_SMR.1 FIA_UID.1
FPT_AMT.1 None
FPT_EMSEC.1 None
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 46 version 1.05, EAL 4+
Requirement Dependencies
FPT_FLS.1 ADV_SPM.1
FPT_PHP.1 unsupported dependencies, see sub-section 6.4.2 for justification.
FPT_TST.1 FPT_AMT.1
FTP_ITC.1/
SCD Export
FTP_ITC.1/SCD Import
FTP_ITC.1/
SVD Export
FTP_ITC.1/SVD Import
Assurance Requirements
ACM_AUT.1 ACM_CAP.3
ACM_CAP.4 ACM_SCP.1, ALC_DVS.1
ACM_SCP.2 ACM_CAP.3
ADO_DEL.2 ACM_CAP.3
ADO_IGS.1 AGD_ADM.1
ADV_FSP.2 ADV_RCR.1
ADV_HLD.2 ADV_FSP.1, ADV_RCR.1
ADV_IMP.1 ADV_LLD.1, ADV_RCR.1, ALC_TAT.1
ADV_LLD.1 ADV_HLD.2, ADV_RCR.1
ADV_SPM.1 ADV_FSP.1
AGD_ADM.1 ADV_FSP.1
AGD_USR.1 ADV_FSP.1
ALC_TAT.1 ADV_IMP.1
ATE_COV.2 ADV_FSP.1, ATE_FUN.1
ATE_DPT.1 ADV_HLD.1, ATE_FUN.1
ATE_IND.2 ADV_FSP.1, AGD_ADM.1, AGD_USR.1, ATE_FUN.1
AVA_MSU.3 ADO_IGS.1, ADV_FSP.1, AGD_ADM.1, AGD_USR.1
AVA_SOF.1 ADV_FSP.1, ADV_HLD.1
AVA_VLA.4
ADV_FSP.1, ADV_HLD.2, ADV_IMP.1, ADV_LLD.1, AGD_ADM.1,
AGD_USR.1
Functional Requirement for SSCD Type2
FDP_ACC.1/
SCD Import SFP
unsupported dependencies, see sub-section 6.4.2 for justification
FDP_ACC.1/
SVD Transfer SFP
unsupported dependencies, see sub-section 6.4.2 for justification
FDP_ITC.1/
SCD Import
FDP_ACC.1/ SCD Import, unsupported dependencies, see sub-
section 6.4.2 for justification
FDP_UCT.1/Receiver FDP_ACC.1/ SCD Import, FTP_ITC.1/SCD Import
FTP_ITC.1/
SVD Transfer
None
FTP_ITC.1/
SCD Import
None
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 47 version 1.05, EAL 4+
Functional Requirements for Certification generation application (GGA)
FCS_CKM.2/CGA unsupported dependencies, see sub-section 6.4.2 for justification
FCS_CKM.3/CGA unsupported dependencies, see sub-section 6.4.2 for justification
FDP_UIT.1/
SVD Import
FTP_ITC.1/SVD Import, unsupported dependencies, see sub-section
6.4.2 for justification
FTP_ITC.1/
SVD Import
None
6.4.2 Justification of Unsupported Dependencies
FPT_PHP.1 Upon detection of physical tampering that might compromise the TSF,
the SCD creation function must be disabled with no restriction. This is
why FMT_MOF.1 is not applicable.
The security functional dependencies for the TOE environment SSCD Type2 and CGA are not
completely supported by security functional requirements in section 5.3.
FDP/ACC.1/
SCD Import SFP
The SSCD Type2 will follow the SCD Import SFP when importing the
SCD. The access control required by this SFP, FDP_ACF.1 Security
attribute based access control, is outside the scope of this PP.
FDP/ACC.1/
SVD Transfer SFP
The SSCD Type2 will follow the SVD Transfer SFP when importing
and then exporting the SVD. The access control required by this
SFP, FDP_ACF.1 Security attribute based access control, is outside
the scope of this PP.
FDP_ITC.1/
SCD Import
The SSCD Type2 importing the SCD must maintain it’s
confidentiality. The SFP used including The Static attribute
initialisation FMT_MSA.3 is outside the scope of this PP.
FCS_CKM.2/ CGA
The CGA generates qualified electronic signatures including the SVD
imported from the TOE. The FCS_CKM.1 is not necessary because
the CGA does not generate the SVD. There is no need to destroy the
public SVD and therefore FCS_CKM.4 is not required for the CGA.
The security management for the CGA by FMT_MSA.2 is outside of
the scope of this PP.
FCS_CKM.3/ CGA
The CGA imports SVD via trusted cannel implemented by
FTP_ITC.1/ SVD import. The FCS_CKM.1 is not necessary because
the CGA does not generate the SVD. There is no need to destroy the
public SVD and therefore FCS_CKM.4 is not required for the CGA.
The security management for the CGA by FMT_MSA.2 is outside of
the scope of this PP.
FDP_UIT.1/
SVD IMPORT
The access control policy (FDP_ACC.1) for the CGA is out of the
scope of this PP.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 48 version 1.05, EAL 4+
6.5 Security Requirements Grounding in Objectives
Table 6.6 Assurance and Functional Requirement to Security Objective Mapping
Requirement Security Objectives
Security Assurance Requirements
ACM_AUT.1 EAL 4
ACM_CAP.4 EAL 4
ACM_SCP.2 EAL 4
ADO_DEL.2 EAL 4
ADO_IGS.1 EAL 4
ADV_FSP.2 EAL 4
ADV_HLD.2 EAL 4
ADV_IMP.1 EAL 4
ADV_LLD.1 EAL 4
ADV_RCR.1 EAL 4
ADV_SPM.1 EAL 4
AGD_ADM.1 EAL 4
AGD_USR.1 EAL 4
ALC_DVS.1 EAL 4, OT.Lifecycle_Security
ALC_LCD.1 EAL 4, OT.Lifecycle_Security
ALC_TAT.1 EAL 4, OT.Lifecycle_Security
ATE_COV.2 EAL 4
ATE_DPT.1 EAL 4
ATE_FUN.1 EAL 4
ATE_IND.2 EAL 4
AVA_MSU.3 OT.SCD_Secrecy
AVA_SOF.1 EAL 4, OT.SCD_Secrecy
AVA_VLA.4 OT.SCD_Secrecy
Security requirements
R.Administrator_Guide AGD_ADM.1
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 49 version 1.05, EAL 4+
6.6 Rationale for Extensions
The additional family FPT_EMSEC (TOE Emanation) of the Class FPT (Protection of the TSF)
is defined here to describe the IT security functional requirements of the TOE. The TOE shall
prevent attacks against the SCD and other secret data where the attack is based on external
observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s
electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA),
timing attacks, etc. This family describes the functional requirements for the limitation of
intelligible emanations.
6.6.1 FPT_EMSEC TOE Emanation
Family behaviour
This family defines requirements to mitigate intelligible emanations.
Component levelling:
FPT_EMSEC.1 TOE Emanation has two constituents:
• FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible emissions enabling
access to TSF data or user data.
• FPT_EMSEC.1.2 Interface Emanation requires not emit interface emanation enabling
access to TSF data or user data.
Management: FPT_EMSEC.1
There are no management activities foreseen.
Audit: FPT_EMSEC.1
There are no actions identified that should be auditable if FAU_GEN Security audit data
generation is included in the PP/ST.
FPT_EMSEC.1 TOE Emanation
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
[assignment: specified limits] enabling access to RAD and SCD.
FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use
the following interface [assignment: type of connection] to gain access
to RAD and SCD.
Hierarchical to: No other components.
Dependencies: No other components.
FPT_EMSEC TOE Emanation 1
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 50 version 1.05, EAL 4+
6.7 Rationale for Strength of Function High
The TOE shall demonstrate to be highly resistant against penetration attacks in order to meet
the security objective OT.SCD_Secrecy. The protection against attacks with a high attack
potential dictates a strength of function high rating for functions in the TOE that are realised by
probabilistic or permutational mechanisms.
6.8 Rationale for Assurance Level 4 Augmented
The assurance level for this protection profile is EAL4 augmented.EAL4 allows a developer to
attain a reasonably high assurance level without the need for highly specialized processes and
practices. It is considered to be the highest level that could be applied to an existing product line
without undue expense and complexity. As such, EAL4 is appropriate for commercial products
that can be applied to moderate to high security functions. The TOE described in this protection
profile is just such a product. Augmentation results from the selection of:
AVA_MSU.3 Vulnerability Assessment - Misuse - Analysis and testing for insecure
states
AVA_VLA.4 Vulnerability Assessment - Vulnerability Analysis – Highly resistant
The TOE is intended to generate SCD/SVD pairs by the CSP on behalf of the signatories in
large quantities. The guidance shall allow the CSP to apply administrative and management
procedures which are adequate and correspond to recognised standards and to prevent
insecure states endangering the confidentiality of the SCD and authenticity of the SVD.
In AVA_MSU.3, an analysis of the guidance documentation by the developer is required to
provide additional assurance that the objective has been met, and this analysis is validated and
confirmed through testing by the evaluator. AVA_MSU.3 has the following dependencies:
ADO_IGS.1 Installation, generation, and start-up procedures
ADV_FSP.1 Informal functional specification
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
All of these are met or exceeded in the EAL4 assurance package.
AVA_VLA.4 Vulnerability Assessment - Vulnerability Analysis – Highly resistant
The TOE shall be shown to be highly resistant to penetration attacks to meet the security
objectives OT.SCD_Secrecy. AVA_VLA.4 has the following dependencies:
ADV_FSP.1 Informal functional specification
ADV_HLD.2 Security enforcing high-level design
ADV_IMP.1 Subset of the implementation of the TSF
ADV_LLD.1 Descriptive low-level design
AGD_ADM.1 Administrator guidance
AGD_USR.1 User guidance
All of these are met or exceeded in the EAL4 assurance package.
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 51 version 1.05, EAL 4+
References
[1] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 13 December 1999 on a Community framework for electronic signatures
[2] International Organization for Standardization, ISO/IEC 15408-1:1999 Information
technology — Security techniques — Evaluation criteria for IT security — Part 1:
Introduction and general model, 1999.
[3] International Organization for Standardization, ISO/IEC 15408-2:1999 Information
technology — Security techniques — Evaluation criteria for IT security — Part 2:
Security functional requirements, 1999.
[4] International Organization for Standardization, ISO/IEC 15408-3:1999 Information
technology — Security techniques — Evaluation criteria for IT security — Part 3:
Security assurance requirements, 1999.
[5] Algorithms and parameters for algorithms, list of algorithms and parameters eligible for
electronic signatures, procedures as defined in the directive 1999/93/EC, article 9 on
the ‘Electronic Signature Committee’ in the Directive.
Appendix A - Acronyms
CC Common Criteria
EAL Evaluation Assurance Level
IT Information Technology
PP Protection Profile
SF Security Function
SFP Security Function Policy
SOF Strength of Function
ST Security Target
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSFI TSF Interface
TSP TOE Security Policy
Protection Profile — Secure Signature-Creation Device CEN/ISSS Electronic Signature (E-SIGN) Workshop
28.07.01 52 version 1.05, EAL 4+
—— this page was intentionally left blank ——