EN 419221-5:2018

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Schutzprofile für kryptographische Module von Vertrauensdienstanbietern - Teil 5: Kryptographisches Modul für vertrauenswürdige DiensteProfils de protection pour les modules cryptographiques de prestataires de services de confiance - Partie 5: Module cryptographique pour les services de confianceProtection profiles for Trust Service Provider Cryptographic modules - Part 5: Cryptographic Module for Trust Services35.240.30Uporabniške rešitve IT v informatiki, dokumentiranju in založništvuIT applications in information, documentation and publishing35.040.01Kodiranje informacij na splošnoInformation coding in generalICS:Ta slovenski standard je istoveten z:EN 419221-5:2018SIST EN 419221-5:2018en,fr,de01-julij-2018SIST EN 419221-5:2018SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 419221-5
May
t r s z ICS
u wä r v rä r sâ
u wä t v rä u r English Version
Protection Profiles for TSP Cryptographic Modules æ Part
wã Cryptographic Module for Trust Services Profils de protection pour les modules cryptographiques de prestataires de services de confiance æ Partie
wã Module cryptographique pour les services de confiance
Schutzprofile für kryptographische Module von Vertrauensdienstanbietern æ Teil
wã Kryptographisches Modul für vertrauenswürdige Dienste This European Standard was approved by CEN on
t March
t r s zä
egulations which stipulate the conditions for giving this European Standard the status of a national standard without any alterationä Upætoædate lists and bibliographical references concerning such national standards may be obtained on application to the CENæCENELEC Management Centre or to any CEN memberä
translation under the responsibility of a CEN member into its own language and notified to the CENæCENELEC Management Centre has the same status as the official versionsä
CEN members are the national standards bodies of Austriaá Belgiumá Bulgariaá Croatiaá Cyprusá Czech Republicá Denmarká Estoniaá Finlandá Former Yugoslav Republic of Macedoniaá Franceá Germanyá Greeceá Hungaryá Icelandá Irelandá Italyá Latviaá Lithuaniaá Luxembourgá Maltaá Netherlandsá Norwayá Polandá Portugalá Romaniaá Serbiaá Slovakiaá Sloveniaá Spainá Swedená Switzerlandá Turkey and United Kingdomä
EUROPEAN COMMITTEE FOR STANDARDIZATION COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre:
Rue de la Science 23,
B-1040 Brussels
t r s z CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Membersä Refä Noä EN
v s { t t sæ wã t r s z ESIST EN 419221-5:2018

Mapping to Regulation (EU) 910/2014 . 74 Bibliography . 79
Tables Table 1 — Key Attributes Modification Table
................................................................................................. 56 Table 2 — Key Attributes Initialisation Table 82 ............................................................................................. 57 Table 3 — Security Assurance Requirements .................................................................................................. 61 Table 4 — Security Problem Definition mapping to Security Objectives ............................................... 66 Table 5 — TOE Security Objectives mapping to SFRs .................................................................................... 68 Table 6 — SFR Dependencies Rationale ............................................................................................................. 71 Table A.1— Mapping between [Regulation, Annex II] and this PP ........................................................... 74
Figures Figure 1 — Generic TOE Architecture . 12 Figure 2 — Generation of Random numbers - Component Levelling . 29 Figure 3 — Basic TSF Self Testing – Component Levelling . 30 Figure 4 — Architecture of Key Protection SFRs . 32 Figure 5 — Architecture of User, TSF Protection and Audit SFRs . 33 Figure 6 — Generic Key Lifecycle and Related SFRs . 34 SIST EN 419221-5:2018

1 As described in footnote 6, this Protection Profile includes a refinement to ADV_ARC.1 to consider support keys used in the implementation of the TOE and its protection measures. SIST EN 419221-5:2018

Figure 1 — Generic TOE Architecture The hardware appliance boundary in Figure 1 represents the enclosure of the computing appliance which hosts the TOE. This can be a server, a PC or equivalent. Local client applications reside in the same hardware appliance as the TOE, e.g. in the case of the TOE being a PCIe card inside a server, local client applications are the applications running within the same server boundary and using the TOE’s services through the PCIe bus. Another example of local client application is an embedded application running inside the physical boundary of the TOE. External client applications communicate remotely with the TOE through a network connection. In all cases, the Client Application is outside the scope of the TOE. A specific TOE will not necessarily include all of the elements shown in Figure 1. A TOE that comprises a PCIe card located in a server may have only local interfaces, e.g. for local client applications and storage of audit and TOE data within the server hardware boundary (which in this case is the hardware appliance boundary in Figure 1), but a dedicated cryptographic module might not include any such local storage and may use only external interfaces. The Security Target for each specific TOE is required to make clear what resources and channels are provided by that TOE. The TOE is intended to support the provision of cryptographic functions for use by trust service providers. SIST EN 419221-5:2018

2 In this document ‘authentication’ implies that the user is specifically identified, whereas ‘authorization’ implies that the authority of the user to use the key is established but the identity of the individual may not be known (e.g. where a single key is available to a number of individuals using a shared passphrase). As noted elsewhere, it is the responsibility of client applications to ensure that they use the correct mechanism for the context of the relevant keys and cryptographic functions. 3 More details of these requirements and the definitions of natural and legal persons can be found in [10]. 4 A TOE may provide some additional channels that provide only authentication and integrity protection, but it shall provide at least one channel that is also capable of protecting confidentiality. SIST EN 419221-5:2018

5 Some cryptographic operations, such as creating message digests, do not require keys. SIST EN 419221-5:2018

— Deletion of keys within the TOE. The TOE supports at least one of the following techniques for establishing keys7: 1) Generation of cryptographic keys using a random number generator and implementing the key generation algorithms depending on the intended use of the keys; 2) Import of cryptographic keys in encrypted form or cryptographic key components using split-knowledge procedures; 3) Key agreement protocols establishing common secrets with external entities; 4) Derivation of keys from shared knowledge. Secret keys are associated with attributes that determine their use, such that the correct association between the key and its attributes shall be protected against unauthorised modification. The specific key attributes maintained by a particular TOE are required to be specified in its Security Target. In generic terms these attributes include8: — The identifier of the key (this enables it to be linked by an application to a particular owner); — The type of the key (e.g. whether the key is a secret key of a symmetric cryptographic algorithm or the secret (commonly called private) key of an asymmetric cryptographic algorithm); — Authorization data that enables access to the key (required only for secret keys); — Re-authorization conditions such as determining a time period or number of uses of a key that are enabled by a single presentation of the correct authorization data for the key, after which the authorization will have to be re-presented in order to authorize any further uses of the key (re-authorization conditions are required only for secret keys, and may not be the same for all types of secret keys: the details of the re-authorization conditions for a specific TOE are described by completing the selections and assignments in FIA_UAU.6/KeyAuth in 9.4.3);
6 This Protection Profile distinguishes support keys from user keys, as described in the refinement to ADV_ARC.1 in 9.5.2. Requirements are placed by the Protection Profile on user keys, and support keys are considered an aspect of the TOE implementation that is therefore required to support the requirements for user keys, but where different structures and mechanisms (including aspects such as critical attributes) may be used. 7 SFRs are defined in Clause 9 only for random number generation and import; however a Security Target may add SFRs for additional techniques supported by the TOE. 8 In particular these attributes shall be sufficient to allow a secret key to be identified as one that is used to produce qualified electronic signatures and qualified electronic seals that meet the requirements of [Regulation], as interpreted for a specific TOE according to the definition in item 1 of the refinement to AGD_OPE.1 in 9.5.2. SIST EN 419221-5:2018
...