EN 419231:2019

Protection profile for trustworthy systems supporting time stamping

This document specifies a protection profile for trustworthy systems supporting time stamping.

Schutzprofil für vertrauenswürdige Systeme, die Zeitstempel unterstützen

Profil de protection pour des systèmes fiables d’horodatage

La présente Norme européenne spécifie un profil de protection pour des systèmes fiables d’horodatage.

Profil zaščite zaupanja vrednih sistemov, ki podpirajo časovne žige

Ta evropski standard določa profil zaščite zaupanja vrednih sistemov, ki podpirajo časovne žige.

General Information

• Status: Published
• Publication Date: 28-Aug-2019
• Withdrawal Date: 28-Feb-2020
• ICS: 35.030 - IT Security
• ICS: 35.040.01 - Information coding in general
• Technical Committee: CEN/TC 224 - Machine-readable cards, related device interfaces and operations
• Drafting Committee: CEN/TC 224/WG 17 - Protection Profiles in the context of SSCD
• Current Stage: 9093 - Decision to confirm - Review Enquiry
• Start Date: 03-Jul-2025
• Completion Date: 23-Sep-2025
• Directive: 910/2014 - Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing directive 1999/93/EC
• Mandate: M/460 - Standardisation Mandate to the European Standardisation Organizations CEN, CENELEC and ETSI in the field of Information and Communication Technologies applied to Electronic Signatures
• Ref Project: SIST EN 419231:2019 - Protection profile for trustworthy systems supporting time stamping

Overview

EN 419231:2019 - Protection profile for trustworthy systems supporting time stamping defines a Common Criteria protection profile for IT components that issue time‑stamp tokens. It specifies the security objectives, threats, assumptions, functional and assurance requirements for a trustworthy Time‑Stamping Authority (TSA) component (the TOE) and its operational environment. The profile covers the behaviour of a time‑stamping unit (TSU), the binding of data to Coordinated Universal Time (UTC), and the expected physical and organisational controls (for example, restricted access and dual control).

Key technical topics and requirements

• Time‑stamp token definition and semantics: a token that binds a representation of a datum to a point in time, providing evidence the datum existed before that time.
• TOE and operational environment model: TOE is a software component within a TSA system; the environment supplies an external trusted UTC time source and implements physical/organisational protections. Cryptographic modules may be outside the TOE perimeter.
• Security functional requirements (SFRs) (detailed in the profile):
  • User Data Protection (FDP) - integrity and protection of issued tokens and request/response handling.
  • Security Management (FMT) - administrative roles, configuration and operational controls.
  • Protection of the TSF (FPT) - self‑protection and tamper resistance measures.
  • Trusted Path/Channels (FTP) - secure communication between requesters and the TOE.
  • Cryptographic Support (FCS) - approved algorithms, key handling and interaction with cryptographic modules.
  • Identification and Authentication (FIA) - authentication of administrators and requesters as applicable.
  • Security Audit (FAU) - generation and protection of audit records.
• Security assurance: the profile aligns with ISO/IEC 15408 (Common Criteria) concepts for assurance and references ISO/IEC 19790 when cryptographic modules are involved.
• Normative references: ETSI EN 319 421 (TSP operational policy), and CEN/TS 419221 series for cryptographic module protection profiles.

Practical applications

• Ensuring trustworthy issuance of time‑stamp tokens used in electronic signatures, document notarisation, long‑term archiving, and non‑repudiation services.
• Providing a standard security target for developers and evaluators of time‑stamping systems to achieve certified trustworthiness.
• Supporting compliance with regulatory frameworks that rely on trusted timestamps (e.g., eIDAS‑related services).

Who should use this standard

• Time‑Stamping Authorities (TSA) and Trust Service Providers (TSPs) designing or operating time‑stamping services.
• Security architects and system integrators implementing TSUs and related software.
• Evaluation labs and auditors performing Common Criteria assessments.
• Policy makers and legal/records managers requiring reliable timestamping for evidential or archival purposes.

Related standards

• ISO/IEC 15408 (Common Criteria)
• ISO/IEC 19790 (cryptographic module requirements)
• ETSI EN 319 421 (Policy & security requirements for TSPs providing time‑stamping)
• CEN/TS 419221 parts (protection profiles for TSP cryptographic modules)

Keywords: protection profile, time stamping, time‑stamp token, TSA, TSU, trustworthy systems, Common Criteria, UTC, cryptographic support, ETSI EN 319 421.

Standards Content (Sample)

SLOVENSKI STANDARD
01-november-2019
Profil zaščite zaupanja vrednih sistemov, ki podpirajo časovne žige
Protection profile for trustworthy systems supporting time stamping
Schutzprofil für vertrauenswürdige Systeme, die Zeitstempel unterstützen
Profil de protection pour systèmes fiables d’horodatage
Ta slovenski standard je istoveten z: EN 419231:2019
ICS:
35.030 Informacijska varnost IT Security
35.040.01 Kodiranje informacij na Information coding in general
splošno
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 419231
EUROPEAN STANDARD
NORME EUROPÉENNE
August 2019
EUROPÄISCHE NORM
ICS 35.030; 35.040.01
English Version
Protection profile for trustworthy systems supporting
time stamping
Profil de protection pour des systèmes fiables Schutzprofil für vertrauenswürdige Systeme, die
d'horodatage Zeitstempel unterstützen
This European Standard was approved by CEN on 7 July 2019.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 419231:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 5
3.1 Terms and definitions . 5
3.2 Abbreviations . 11
4 Introduction . 12
4.1 PP reference . 12
4.2 TOE overview . 12
5 Conformance claims . 18
5.1 CC conformance claim . 18
5.2 PP claim . 18
5.3 Conformance rationale . 18
5.4 Conformance statement . 18
6 Security problem definition . 19
6.1 TOE assets . 19
6.2 Threats . 21
6.3 Organizational security policies . 24
6.4 Assumptions . 25
7 Security objectives . 27
7.1 General . 27
7.2 Security objectives for the TOE . 27
7.3 Security objectives for the operational environment . 29
7.4 Security objectives rationale . 31
8 Security functional requirements . 37
8.1 General . 37
8.2 Subjects, objects, operations and security attributes . 37
8.3 Security requirements operations . 40
8.4 User Data Protection (FDP) . 40
8.5 Security Management (FMT) . 47
8.6 Protection of the TSF (FPT) . 50
8.7 Trusted Path/Channels (FTP). 50
8.8 Cryptographic Support (FCS) . 51
8.9 Identification and Authentication (FIA) . 52
8.10 Security Audit (FAU) . 52
9 Security assurance requirements . 54
10 Security requirements rationale . 55
10.1 Security functional requirements rationale . 55
10.2 Security assurance requirements rationale . 61
Bibliography . 63

European foreword
This document (EN 419231:2019) has been prepared by Technical Committee CEN/TC 224 “Personal
identification, electronic signature and cards and their related systems and operations”, the secretariat
of which is held by AFNOR.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by February 2020, and conflicting national standards shall
be withdrawn at the latest by February 2020.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
This document specifies a protection profile for a software component that is part of time stamping
system that provides time-stamp tokens to requesters. The TOE operational environment is composed of
an operating system, other software applications, drivers and an external UTC time source that is
considered to be trusted by the TOE. When a cryptographic module is being used, it is outside of the TOE
perimeter.
The TOE is expected to be protected by physical and organisational protection measures implemented
by the TOE environment. Those measures are expected to restrict the TOE physical access (e.g. for
administration purposes) to authorized persons only and are expected to require dual control.
ETSI EN 319 421 specifies additional policy and security requirements relating to the operation and
management practices of TSPs issuing time-stamps.
This protection profile is issued by the European Committee for Standardization, Information Society
Standardization System (CEN/ISSS).
Correspondence and comments to this document should be referred to:
Editor: Dr. Jorge López Hernández-Ardieta
Email: [e-mail]
Main contributor: Mr. Julien Groslambert
Email: [e-mail]
After EN approval the contact address will be:
CEN/ISSS Secretariat
Rue de Stassart 36
1050 Brussels, Belgium
Tel [phone]
Fax [phone]
Email: [e-mail]
For Revision history, see Annex A.
For document structure, see Annex B.
1 Scope
This document specifies a protection profile for trustworthy systems supporting time stamping.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
CEN/TS 419221-2, Protection Profiles for TSP cryptographic modules - Part 2: Cryptographic module for
CSP signing operations with backup
CEN/TS 419221-4, Protection Profiles for TSP cryptographic modules - Part 4: Cryptographic module for
CSP signing operations without backup
EN 419221-5, Protection Profiles for TSP Cryptographic Modules - Part 5: Cryptographic Module for Trust
Services
ISO/IEC 15408 (all parts), Information technology — Security techniques — Evaluation criteria for IT
security
ISO/IEC 19790, Information technology — Security techniques — Security requirements for cryptographic
modules
ETSI EN 319 421:2016, Electronic Signatures and Infrastructures (ESI) - Policy and Security Requirements
for Trust Service Providers providing Time-Stamping
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
Coordinated Universal Time
UTC
time scale based on the second as defined in TF.460-6
Note 1 to entry: For most practical purposes UTC is equivalent to mean solar time at the prime meridian (0°).
More specifically, UTC is a compromise between the highly stable atomic time (Temps Atomique International -
TAI) and solar time derived from the irregular Earth rotation (related to the Greenwich mean sidereal time (GMST)
by a conventional relationship).

The following documents are equivalent to ISO/IEC 15408:
Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional Components; Version 3.1, Revision
4. CCMB-2012-09-002, September 2012.
Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance Components; Version 3.1, Revision
4. CCMB-2012-09-003, September 2012.
3.1.2
requester
legal or natural person to whom a time-stamp token is issued and who is bound to any requester
obligations
3.1.3
time-stamping policy
named set of rules that indicates the applicability of a time-stamp token to a particular community and/or
class of application with common security requirements
3.1.4
time-stamp token
data object that binds a representation of a datum to a particular time, thus establishing evidence that
the datum existed before that time
3.1.5
time-stamping authority
TSA
authority which issues time-stamp tokens using one or more time stamping units (TSUs)
3.1.6
time-stamping unit
TSU
set of hardware and software which is managed as a unit and has a single time-stamp token signing key
active at a time
3.1.7
TSA system
composition of IT products and components organized to support the provision of time-stamping
services
3.1.8
time-stamping service
service that generates and provides time-stamp tokens
3.1.9
electronic signature
data in electronic form which is attached to or logically associated with other electronic data in electronic
form and which is used by the signatory to sign
[SOURCE: Reg. eIDAS]
3.1.10
advanced electronic signature
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 electronic signature creation data that the signatory can, with a high level of
confidence, use under his sole control; and
d) it is linked to the data signed therewith in such a way that any subsequent change in the data are
detectable
[SOURCE: Reg. eIDAS modified]
3.1.11
qualified electronic signature
advanced electronic signature that is created by a qualified electronic signature creation device, and
which is based on a qualified certificate for electronic signatures
[SOURCE: Reg. eIDAS]
3.1.12
signatory
natural person who creates an electronic signature
[SOURCE: Reg. eIDAS]
3.1.13
electronic signature-creation data
unique data which is used by the signatory to create an electronic signature
[SOURCE: Reg. eIDAS]
3.1.14
electronic signature-creation device
configured software or hardware used to create an electronic signature
[SOURCE: Reg. eIDAS]
3.1.15
qualified electronic- signature-creation device
electronic signature creation device that meets the requirements in Annex II of eIDAS Regulation
[SOURCE: Reg. eIDAS modifed]
3.1.16
signature-verification-data or validation data
data that is used to validate an electronic signature or an electronic seal
[SOURCE: Reg. eIDAS]
3.1.17
certificate for electronic signature
electronic attestation which links electronic signature validation data to a natural person and confirms
at least the name or the pseudonym of that person
[SOURCE: Reg. eIDAS]
3.1.18
qualified certificate for electronic signature
certificate for electronic signatures that is issued by a qualified trust service provider and meets the
requirements laid down in Annex I of eIDAS Regulation
[SOURCE: Reg. eIDAS modified]
3.1.19
certification-service-provider
electronic service normally provided for remuneration which consists of issuance of certificates related
to the services of creation, verification, and validation of electronic signatures and electronic seals
[SOURCE: Reg. eIDAS modified]
3.1.20
trustworthy system
information system or product implemented as either hardware and/or software that produces reliable
and authentic records which are protected against modification and additionally ensures the technical
and cryptographic security of the processes supported by it
3.1.21
self-signed certificate
certificate for one CA signed by that CA
[SOURCE: RFC 5280]
3.1.22
certificate policy
named set of rules that indicates the applicability of a certificate to a particular community and/or class
of application with common security requirements
[SOURCE: ISO/IEC 9594-8; ITU-T X.509]
3.1.23
certification authority (CA)
authority trusted by one or more users to create and assign certificates. Optionally the certification
authority may create the users’ keys
[SOURCE: ISO/IEC 9594-8; ITU-T X.509]
3.1.24
end entity
certificate subject which uses its private key for purposes other than signing certificates
[SOURCE: ISO/IEC 9594-8; ITU-T X.509]
3.1.25
relying party
user or agent that relies on the data in a certificate in making decisions
[SOURCE: RFC 5280]
3.1.26
security policy
set of rules laid down by the security authority governing the use and provision of security services and
facilities
[SOURCE: ISO/IEC 9594-8; ITU-T X.509]
3.1.27
activation data
data values, other than keys, that are required to operate cryptographic devices and that need to be
protected (e. g., a PIN, a passphrase, or a manually-held key share)
[SOURCE: RFC 3647]
3.1.28
public key
that key of an entity’s asymmetric key pair which can be made public
[SOURCE: ISO/IEC 9798-1]
3.1.29
private key
that key of an entity's asymmetric key pair which should only be used by that entity
[SOURCE: ISO/IEC 9798-1]
3.1.30
hash function
function which maps string of bits to fixed-length strings of bits, satisfying the following two properties:
a) it is computationally infeasible to find for a given output an input which maps to this output;
b) it is computationally infeasible to find for a given input a second input which maps to the same output
[SOURCE: ISO/IEC 10118-1]
3.1.31
digital signature
data appended to, or a cryptographic transformation (see cryptography) of, a data unit that allows a
recipient of the data unit to prove the source and integrity of the data unit and protect against forgery e.g.
by the recipient
[SOURCE: ISO 7498-2:1989]
3.1.32
authentication data
data used to verify the claimed identity of a user requesting services from TWS
3.1.33
subject
entity identified in a certificate as the holder of the private key associated with the public key given in the
certificate
3.1.34
registration service
service that verifies the identity and, if applicable, any specific attributes of a subject
Note 1 to entry: The results of this service are passed to the Certificate Generation Service
3.1.35
certificate generation service
service that creates and sign certificates based on the identity and other attributes verified by the
registration service
3.1.36
dissemination service
service that disseminates certificates to subjects, and if the subject consents, to relying parties as well as
the CA’s policy & practice information to subjects and relying parties
3.1.37
revocation management service
service that processes requests and reports relating to revocation to determine the necessary action to
be taken
Note 1 to entry: The results of this service are distributed through the Revocation Status Service
3.1.38
revocation status service
service that provides certificate revocation status information to relying parties; this service may be a
real-time service or may be based on revocation status information which is updated at regular intervals
3.1.39
cryptographic device
hardware-based cryptographic device that generates stores and protects cryptographic keys and
provides a secure environment in which to perform cryptographic functions
3.1.40
subject device provision service
service that prepares and provides a signature creation device to subjects
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
ARL Authority Revocation List
CA Certification Authority
CEN Comité Européen de Normalisation (European Committee for Standardization)
CEN/ISSS CEN Information Society Standardization System
CP Certificate Policy
CRL Certificate Revocation List
CSP Certification Service Provider
EC European Commission
EESSI European Electronic Signature Standardization Initiative
ETSI European Telecommunications Standards Institute
HSM Hardware Security Module
ISSS Information Society Standardization System
NQC Non-Qualified Certificate
OCSP Online Certificate Status Protocol
OS Operating System
OSP Organisational Security Policy
PKI Public Key Infrastructure
PP Protection Profile
QC Qualified Certificate
SCDev Signature-Creation Device
SSCD Secure-Signature-Creation Device
ST Security Target
TSA Time-Stamping Authority
TSP Trust Service Provider
TSS Time-Stamping Service
TST Time-Stamp Token
TWS Trustworthy System
WORM Write Once Read Many
WS/E-SIGN CEN/ISSS Electronic Signatures workshop
4 Introduction
4.1 PP reference
Title: Protection profile for trustworthy systems supporting time stamping
Authors: Jorge López Hernández-Ardieta, Julien Groslambert
Version: 0,17
Publication date: 24th September 2018
4.2 TOE overview
4.2.1 TOE type
The TOE corresponds to a software component running on an operating system and that provides time-
stamps generation services to its requesters. Hardware and other software components (e.g. operating
system, drivers, and other software applications) that might be needed by the TOE to provide its services
are considered part of the TOE operational environment. The TOE shall use a hardware secure module
(HSM) for the implementation of the cryptographic operations.
4.2.2 TOE usage and major security features
The TOE is a software component that provides services for the generation of time-stamps in a manner
that:
— It is able to receive and process time-stamping requests from external users (requesters), protecting
the integrity of the requests when managed by the TOE.
— The integrity of the time-stamps produced by the TOE is protected when created and managed by
the TOE and during transfer from the TOE to an external entity.
— Any external entity can verify the authentication of the time-stamps produced by the TOE.
— The TOE services (user identity and role management, TSU initialisation, start of TSU operation, stop
of TSU operation, finalisation of TSU operation, generation of key pair, public key export for
certificate request, certificate import, timestamp token generation and internal audit) are only used
in an authorized way.
— The time included in the time-stamps is synchronised with a trusted UTC time source.
The TOE shall provide the following additional functions to protect the TOE services:
— User authentication and access control, except for requesters (see roles below).
— Auditing of security-relevant events produced within the TOE boundaries.
The TOE shall handle the following user data:
— Time-stamping request: Time-stamping request sent by the requester to the TOE in order to obtain
a time-stamp.
— Time-stamp: Time-stamp generated and signed by the TOE based on the time-stamp request
information, and using the active private key of the time stamping context of the TSU.
— Time-stamp context: Set of data that comprises all the information needed to operate a TSU.
— Internal clock: Internal time used by the TSU that provides the date and time corresponding to UTC
time included in each time-stamp.
— Cryptographic key pair: Public key used by external entities to verify the integrity and origin
authentication of the TOE signed time-stamps, and handler to the private key used by the TSU to
digitally sign the time-stamps.
— Audit data: Internal audit records produced by the TOE.
The TOE shall, as a minimum, support the following user categories (roles):
— Requester of the TOE services: external entity that sends time-stamping requests to the TOE and
expects to receive a time-stamp signed by the TOE.
— Security Officer: Overall responsibility for administering the implementation of the security practices
as well as administering the TSU.
— System Administrator: Authorized to install, configure and maintain the TOE and the trustworthy
systems of the operational environment for time-stamping management.
— System Operator: Responsible for operating the TOE and the trustworthy systems of the operational
environment on a day-to-day basis. Authorized to perform system backup and recovery.
— System Auditor: Authorized to view archives and audit logs of the TOE and the trustworthy systems
of the operational environment.
Any user accessing the time-stamp generation service is regarded as a Requester. This service may be not
authenticated and there may be no access control mechanism. Notwithstanding, the TOE will not process
the authentication data, and thus the requests will be treated as non-authenticated.
The TOE may support other roles or sub-roles in addition to the roles specified above. The roles may also
be allowed to perform additional functions provided by the TOE as long as the separation between
different roles is given. None of those additional roles shall be able to access the security-related and
management services restricted to the Security Officer role.
The interface to the TOE may be either shared between the different user categories, or separated for
certain functions. Authentication for all user categories shall be identity-based, except for the Requester,
who accesses non-authenticated services.
Figure 1 shows an overview of the TOE and its relations with the operational environment and TOE users.
Figure 1 — The TOE in its environment
The TOE is a piece of software that is part of a time-stamping system. The time-stamping system is also
composed of a computer (typically a server containing hardware, an operating system (OS) and some
drivers) running the TOE and a cryptographic module. The TOE is directly interacting with the requester,
that exchange with the TOE to obtain timestamps and a Security Officer that is in charge of the
configuration of the TOE. The Time Stamping System in general is in interaction with the System
Administrator, System Operator and System Auditor on one hand, and an external trusted time source on
the other hand.
The Time Stamping System is part of the operational environment where the TOE resides. It contains
non-TOE elements such as the Operating System or the Cryptographic Module. Figure 2 shows the details
of the TOE in terms of functional components that are part of it, as well as the messages/operations
exchanged with entities that belong to the operational environment, and others that do not (i.e. the CA,
the external trusted time source).
The TOE is composed of three modules (see Figure 2):
— A time stamp request manager that handles the exchanges with the requesters (handling Time stamp
request and providing corresponding time-stamps.
— A clock manager, in charge of the accurate synchronization with the external Trusted Time Source
and the detections of incidents related to the time synchronization.
— A context manager, interacting with the crypto-module and the CA, in charge of the life-cycle of the
key pair management. In particular:
— Requesting the key pair generation within the crypto module;
— Exporting the public key for the certificate request to the CA;
— Importing the certificate generated by the CA;
— Requesting the Crypto module signature of the generated Time-stamps.
Time
Time Stamping Software
Stamp
Request
Timestamp
Public Key
requests
Requester
Export
Manager
Context
Manager
Time
CA
Stamp
Clock
Certificate
Manager
Import
Key Pair Generation
Synchronisation
Signature
Crypto.
External
Module
Trusted Time
Source
TOE
Figure 2 — Overview of the TOE functional perimeter
As can be seen, other entities might be related to the TOE, though not directly connected through logical
interfaces, such as a Certification Authority (CA).
As depicted in Figure 3, the time-stamping software (i.e. the TOE) may operate several Time-stamping
Units (TSU).
Figure 3 — Time-stamping Unit
A Time-stamping Unit is the composition of
— A time stamping context, directly managed by the TOE;
— A key pair, stored within the HSM, outside of the TOE.
4.2.3 TOE Environment general overview
The TOE by itself is not able to ensure the complete security of the time stamping generation process and
shall be operated in an environment that meets the requirement described in this document.
More generally, this PP has been written for Trusted Service Provider operating time-stamping authority
to help them to meet the requirements of ETSI EN 319 421 or equivalent. Therefore, the TOE shall be
operated in an environment that is compliant with the above technical specification and, particularly,
with a Hardware Security Module that shall meet the requirement of ETSI EN 319 421 or equivalent.
Figure 4 presents the general overview of the expected TOE environment.
Figure 4 — Interactions of the TOE with its environment
The TOE and Time-stamping system, including the crypto-module, are intended to be operated a Time
Stamping Authority. The Security Officer, the System auditor and the System Operator are located within
the perimeter of the TSA Authority and are considered as Trusted Roles. The requester is not part of the
Time-stamping authority but is in relation with the Time-stamping authority as a consumer of the Time-
stamping service.
4.2.4 Required non-TOE hardware/software/firmware
The TOE needs, at least, the following hardware/software/firmware to operate:
— A server running a general purpose operating system, and is part of the Time Stamping System.
— A Cryptographic module, able to create digital signatures of the time-stamp tokens, and is part of the
Time Stamping System.
— An external reference Clock
The Cryptographic module shall be hardware based and that shall meet
— the requirements of: ETSI EN 319 421:2016, 7.5.2 or equivalent; or
— that meet the following:
— meets the requirements identified in ISO/IEC 19790, level 3 or higher; or
NOTE Demonstrated conformance to FIPS PUB 140-2, level 3 is considered as fulfilment of this
requirement.
— meets the requirements identified in CEN/TS 419221-2 or CEN/TS 419221-4 or EN 419221-5;
or
— is a trustworthy system which is ensured to EAL 4 or higher in accordance to ISO/IEC 15408 (all
parts), or equivalent security criteria. This shall be to a security target or protection profile which
meets the requirements of the present document, based on a risk analysis and taking into
account physical and other non-technical security measures.
— A external reference Clock that is synchronized with UTC time such that
— the time values the TSU uses in the time-stamp token shall be traceable to at least one of the real
time values distributed by a UTC(k) laboratory;
— the time included in the time-stamp token shall be synchronized with UTC within the accuracy
defined in the policy and, if present, within the accuracy defined in the time-stamp token itself.
It is strictly forbidden to use non-TOE software to implement TSF-enforcing functionalities. All TSF-
enforcing functions handled by software shall be included within the TOE. For example, external libraries
may be used for cryptographic computation as long as these libraries are included in the TOE scope. The
TOE may use features of the HSM, as long as these features are within the scope of the HSM Security
Target, have been evaluated at least at the same EAL level than the TOE and are implemented according
to the HSM guidance (i.e. in CC evaluated mode).
5 Conformance claims
5.1 CC conformance claim
This Protection Profile (PP) complies with Common Criteria, version 3.1, revision 4, September 2012, for
both the content and presentation requirements.
All functional and assurance security requirements laid out in this PP comply with Part 2 and Part 3
respectively of the aforementioned Common Criteria version.
This PP is conforming to assurance package Evaluation Assurance Level 4 augmented (EAL4+) as defined
in Part 3 of the aforementioned Common Criteria version. Augmentation results from the selection of:
— ALC_FLR.3 Systematic flaw remediation
5.2 PP claim
This PP does not claim conformance to any other PP.
5.3 Conformance rationale
This PP does not provide a conformance rationale because it does not claim conformance to any other
PP.
5.4 Conformance statement
The PP requires demonstrable conformance of the ST or PP claiming conformance to this PP.
6 Security problem definition
6.1 TOE assets
The TOE implements services that include user management, TSU configuration, start of TSU operation,
stop of TSU operation if the clock is detected as being out of the stated accuracy, key destruction,
generation of key pair, public key export for certificate request, certificate import, timestamp token
generation and internal audit.
The primary assets that need to be protected by the TOE are the following TOE internal data:
— R.REQUEST. This asset is the time-stamping request sent by the requester to the TOE in order to
obtain a time-stamp. This request shall contain:
— the hash of the document to be processed,
— identification of the hash algorithm used to calculate the hash of the document,
Other information may be included in R.REQUEST.
It is important to notice that the request contains the hash of the document obtained with the hash
algorithm defined in the request and not the document itself.
R.REQUEST shall be protected in integrity when inside the TOE.
— R.TIMESTAMP_TOKEN. The time-stamp token is a signed electronic message associating a
document hash with a UTC time and a unique reference to the time-stamping policy. Other
information may be included. The time-stamp is generated based on the time-stamp request
information and signed using the active private key of the time stamping context of the TSU.
R.TIMESTAMP_TOKEN shall be protected in integrity and its origin shall be authenticated.
— R.CONTEXT. The time-stamp context comprises all the information needed to operate a TSU. This
asset contains the following elements:
— the identification of the time source to be used when the TOE manages multiple time source
references;
— the accuracy of the time in the time-stamp tokens with respect to UTC.
— the configuration of the supported time-stamping policies. For each supported policy, the time-
stamp context contains:
— the identifier of the time-stamping policy;
— the identifier(s) of the supported hash algorithm(s);
— the identification of the default time-stamping policy;
— the identifier(s) of the key pair(s) to be used;
— the certificate of the TSU public key. This certificate is issued by a certification authority, and it
is included when the context state is in operational mode. The public key value within the
certificate shall be the same as the public key of the key pair identified in the context.
R.,CONTEXT shall be protected in integrity.
— R.DATE_AND_TIME. This asset provides the date and time (reference time) to be included in each
time-stamp token. Associated with this date and time is:
— a synchronisation state (internal clock manager), that indicates whether the clock is
synchronized with UTC or not;
— a synchronization precision value.
R.DATE_AND_TIME shall be protected in integrity.
— R.KEY_PAIR_PUB. This asset is the public key of a time-stamping context. The public key can be used
by the requester and third parties to verify the integrity and authorship of the signed time-stamp.
R.KEY_PAIR_PUB shall be protected in integrity prior to being certified.
— R.KEY_PAIR_PRIV. This asset is the handler of or reference to the private key of a time-stamping
context. The private key, stored in the cryptographic module, is used by the TSU to digitally sign the
time-stamps.
R.KEY_PAIR_PRIV shall be protected in integrity and confidentiality.
The private key itself shall be protected in integrity and in confidentiality by the cryptographic
module.
— R.TSF_DATA: TSF data, including:
— authentication data of TOE users (administrators and auditors), which shall be protected in
confidentiality and integrity.
— non-confidential user/role related data (identifier, access control lists, role definitions, etc.).
These data shall be protected in integrity.
— R.AUDIT_DATA. Internal audit records and that shall be protected in integrity.
Table 1 correlates the TOE internal data types explained above with those data types considered in the
formalization of the security functional requirements (SFR):
Table 1 — TOE internal data and TOE internal data
TOE internal data type SFR-related data type
R.REQUEST
R.TIMESTAMP_TOKEN
R.CONTEXT
a
R.DATE_AND_TIME User data
R.KEY_PAIR_PUB
R.KEY_PAIR_PRIV
R.AUDIT_DATA
b
R. TSF_DATA TSF data
a
Data for the user that does not affect the operation of the TSF (TOE Security Functionality). For example, in the
case of R.AUDIT_DATA, the audit records generated internally in the TOE are intended to be revised by the
Auditor.
b
Data for the operation of the TOE upon which the enforcement of the SFR relies.
6.2 Threats
6.2.1 General
The expected attackers are qualified so as to have Enhanced-Basic attack potential, in accordance with
the security assurance given by AVA_VAN.3 Focused vulnerability analysis.
The expected threat agents are:
— TA.EXTERNAL
This agent represents an entity that does not hold any authorized role to operate or interact with the
TOE. This agent may operate through the remote or local interfaces of the TOE, or even have direct
physical access to the TOE. Examples of this threat agent are: unauthorised TOE personnel,
cybercriminals, and hackers in general.
— TA.INSIDER
This agent represents an entity that holds an authorized role to operate or interact with the TOE, and
which has the intention to compromise the TOE assets. This agent may operate through the remote
or local interfaces of the TOE, or even have direct physical access to the TOE. Examples of this threat
agent are: auditors and administrators, such as the system administrator.
— TA.INADVERTENT
This agent represents an entity that holds an authorized role to operate or interact with the TOE, but
which does not have the intention to compromise the TOE assets. This agent may operate through
the remote or local interfaces of the TOE, or even have direct physical access to the TOE. Examples of
this threat agent are: auditors and administrators.
The expected threats to the TOE may be:
— T.CONTEXT_ALTERATION
A TA.INSIDER or TA.INADVERTENT might change the operational time-stamping context
(R.CONTEXT) with the purpose to or with the consequence of using a context with weaker security
attributes (e.g. weak hash algorithms), a compromised private key for which the certificate
revocation has not been processed yet, etc.
— T.DATE_AND_TIME_ALTERATION
A TA.INSIDER might change the reference date and time and/or the synchronisation state of
R.DATE_AND_TIME with the purpose to make the TOE issue signed time-stamps with an intended
time that deviates from the actual UTC date and time. The threat can be materialised in two ways:
(1) The TA.INSIDER sets the time of the internal clock with an arbitrary date in the past or in the
future that is outside the range of clock accuracy.
(2) The TA.INSIDER sets the time of the internal clock with an arbitrary date in the past or in the
future that is inside the range of clock accuracy, and performs this attack over again until a gap
greater than the range of the clock accuracy is reached.
— T.PRIVATE_KEY_ALTERATION
A TA.EXTERNAL or a TA.INSIDER might modify or alter the R.KEY_PAIR_PRIV while being operated
inside the TSU, resulting in a loss of integrity and/or availability of the R.KEY_PAIR_PRIV.
For instance, a TA.INSIDER such a malicious auditor without authorization to change the
R.KEY_PAIR_PRIV reference to another private key that may not be stored in a HSM or that may
produce non verifiable timestamps.
— T.PUBLIC_KEY_ALTERATION
A TA.EXTERNAL or a TA.INSIDER might modify or alter the R.KEY_PAIR_PUB before creating the
certificate request for further export, resulting in a loss of integrity of the R.KEY_PAIR_PUB.
— T.PRIVATE_KEY_DERIVATION
A TA.EXTERNAL or a TA.INSIDER might derive all or parts of private key referred by
R.KEY_PAIR_PRIV using knowledge gained about, for example, the corresponding public key, the
cryptosystem and the key generation process. This knowledge might enable the attacker to conduct
certain cryptanalysis attacks that does not require access to the environment w
...