SECURITY TARGET distributed remote Qualified Signature Creation Device (drQSCD) drQSCD-ST 2 / 147 public Contents 1. ST INTRODUCTION............................................................................................................................................. 5 1.1 ST REFERENCE......................................................................................................................................................5 1.2 TOE REFERENCE ...................................................................................................................................................5 1.3 TOE OVERVIEW....................................................................................................................................................5 1.3.1 TOE type ...........................................................................................................................................................5 1.3.2 TOE usage.........................................................................................................................................................6 1.3.3 Major security features of the TOE...................................................................................................................8 1.3.4 Required non-TOE hardware/software/firmware ..........................................................................................10 1.4 TOE DESCRIPTION...............................................................................................................................................11 1.4.1 The physical scope of the TOE ........................................................................................................................12 1.4.2 The logical scope of the TOE...........................................................................................................................13 1.4.3 Features and Functions not included in the TOE Evaluation...........................................................................24 2. CONFORMANCE CLAIMS........................................................................................................................................25 2.1 CC CONFORMANCE CLAIM ....................................................................................................................................25 2.2 PP CLAIM..........................................................................................................................................................25 2.3 PACKAGE CLAIM .................................................................................................................................................25 2.4 CONFORMANCE RATIONALE ..................................................................................................................................25 3. SECURITY PROBLEM DEFINITION............................................................................................................................32 3.1 GENERAL ..........................................................................................................................................................32 3.1.1 Assets of the Cryptographic Module (CM) ................................................................................................32 3.1.2 Assets of the Signature Activation Module (SAM) ....................................................................................32 3.1.3 Additional assets.......................................................................................................................................34 3.1.4 Subjects of the Cryptographic Module (CM) .............................................................................................34 3.1.5 Subjects of the Signature Activation Module (SAM) .................................................................................35 3.1.6 Threat agents of the TOE ..........................................................................................................................35 3.2 THREATS ...........................................................................................................................................................35 3.2.1 Threats for the Cryptographic Module (CM).............................................................................................35 3.2.2 Threats for the Signature Activation Module (SAM).................................................................................36 3.2.3 Additional threats .....................................................................................................................................39 3.3 ORGANIZATIONAL SECURITY POLICIES..............................................................................................................................40 3.3.1 Organizational Security Policies for the Cryptographic Module (CM) ............................................................40 3.3.2 Organizational Security Policies for the Signature Activation Module (SAM) ................................................41 3.4 ASSUMPTIONS............................................................................................................................................................41 3.4.1 Assumptions for the Cryptographic Module (CM)..........................................................................................41 3.4.2 Assumptions for the Signature Activation Module (SAM)..............................................................................43 4 SECURITY OBJECTIVES.......................................................................................................................................45 4.1 SECURITY OBJECTIVES FOR THE TOE................................................................................................................................45 4.1.1 Security Objectives for the Cryptographic Module (CM) ................................................................................45 4.1.2 Security Objectives for the Signature Activation Module (SAM) ....................................................................48 4.1.3 Additional Security Objectives for the TOE .....................................................................................................50 4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ..............................................................................................50 4.2.1 SOs for the Operational Environment of the TOE (CM+SAM).........................................................................50 4.2.2 SOs for the Operational Environment of the Cryptographic Module (CM).....................................................51 4.2.3 SOs for the Operational Environment of the Signature Activation Module (SAM).........................................52 4.3 SECURITY OBJECTIVES RATIONALE...................................................................................................................................54 4.3.1 Security objectives coverage (backtracking) ..................................................................................................54 4.3.2 Security Objectives Sufficiency .......................................................................................................................56 drQSCD-ST 3 / 147 public 5 EXTENDED COMPONENTS DEFINITION .............................................................................................................62 5.1 GENERATION OF RANDOM NUMBERS (FCS_RNG).............................................................................................................62 5.2 BASIC TSF SELF TESTING (FPT_TST_EXT)......................................................................................................................63 6 SECURITY REQUIREMENTS................................................................................................................................64 6.1 SECURITY FUNCTIONAL REQUIREMENTS............................................................................................................................64 6.1.1 Use of requirement specifications ..................................................................................................................64 6.1.2 SFRs of the Cryptographic Module (CM) ........................................................................................................67 6.1.3 SFRs of the Signature Activation Module (SAM) ............................................................................................89 6.1.4 Additional SFRs.............................................................................................................................................118 6.2 SECURITY ASSURANCE REQUIREMENTS...........................................................................................................................120 6.3 SECURITY REQUIREMENTS RATIONALE ............................................................................................................................121 6.3.1 Security requirements coverage...................................................................................................................121 6.3.2 Satisfaction of SFR dependencies .................................................................................................................127 6.3.3 Satisfaction of SAR dependencies.................................................................................................................132 6.3.4 Rationale for chosen security assurance requirements................................................................................132 7 TOE SUMMARY SPECIFICATION.......................................................................................................................133 7.1 SECURITY FUNCTIONALITY...........................................................................................................................................133 7.1.1 Roles, Authentication and Authorisation (SF_IA_CM and SF_IA_SAM)........................................................133 7.1.2 Security management (SF_Management_CM and SF_Management_SAM) ...............................................134 7.1.3 Key Security (SF_Crypto_CM, SF_Crypto_SAM and Crypto_extCM) .............................................................134 7.1.4 Access and information flow control (SF_Control_CM and SF_Control_SAM) .............................................136 7.1.5 TSF data protection (SF_FPT_CM and SF_FPT_SAM) ...................................................................................137 7.1.6 Audit (SF_Audit_CM and SF_Audit_SAM) ....................................................................................................137 7.1.7 Communication protection (SF_Comm_CM and SF_Comm_SAM)...............................................................138 7.1.8 Distributed structure (SF_Distributed_TOE) .................................................................................................138 7.2 TOE SUMMARY SPECIFICATION RATIONALE .....................................................................................................................139 8 REFERENCES AND ACRONYMS........................................................................................................................143 8.1 REFERENCES.............................................................................................................................................................143 8.2 ACRONYMS ..............................................................................................................................................................145 List of Figures 1.1. FIGURE: THE TOE IN THE “LOCAL” USE CASE ...............................................................................................................6 1.2. FIGURE: THE TOE IN THE “REMOTE” USE CASE.............................................................................................................7 1.3. FIGURE: TOE IN MULTI-PARTY CONFIGURATION ...........................................................................................................10 1.4. FIGURE: MPCA ARCHITECTURE...................................................................................................................................11 1.5. FIGURE: PHYSICAL APPEARANCE OF AN MPCA ............................................................................................................12 1.6. FIGURE: DIAGRAM OF THE DIFFERENT STATES AND STATE TRANSITIONS OF AN MPCA....................................................23 List of Tables TABLE 1.1 KEY ATTRIBUTES ............................................................................................................................................15 TABLE 1.2 SUPPORTED CRYPTOGRAPHIC OPERATIONS AND ALGORITHMS .........................................................................17 TABLE 2.1 THREATS ..........................................................................................................................................................26 TABLE 2.2 ORGANIZATIONAL SECURITY POLICIES ............................................................................................................27 TABLE 2.3. ASSUMPTIONS .................................................................................................................................................27 TABLE 2.4 SECURITY OBJECTIVES FOR THE TOE ..............................................................................................................29 TABLE 2.5 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT.........................................................................29 TABLE 4.1 MAPPING OF SECURITY PROBLEM DEFINITION TO SECURITY OBJECTIVES FOR CM...........................................54 TABLE 4.2 MAPPING OF SECURITY PROBLEM DEFINITION TO SECURITY OBJECTIVES FOR SAM ........................................55 TABLE 4.3 MAPPING OF SECURITY PROBLEM DEFINITION TO SECURITY OBJECTIVES FOR THE DISTRIBUTED STRUCTURE...56 drQSCD-ST 4 / 147 public TABLE 6.1 FUNCTIONAL SECURITY REQUIREMENTS FOR THE DISTRIBUTED STRUCTURE OF THE DRQSCD.......................67 TABLE 6.2 TSF DATA RELATED TO THE UNBLOCKING........................................................................................................82 TABLE 6.3 KEY ATTRIBUTES INITIALISATION TABLE........................................................................................................84 TABLE 6.4 KEY ATTRIBUTES MODIFICATION TABLE ........................................................................................................85 TABLE 6.5 SUBJECTS OF THE SAM ...................................................................................................................................89 TABLE 6.6 OBJECTS OF THE SAM.....................................................................................................................................89 TABLE 6.7 OPERATIONS SUPPORTED BY THE SAM............................................................................................................89 TABLE 6.8 ASSURANCE REQUIREMENTS: EAL4 AUGMENTED BY AVA_VAN.5 AND ALC_FLR.3...................................120 TABLE 6.9 CM SECURITY OBJECTIVES MAPPING TO SFRS ..............................................................................................122 TABLE 6.10 SAM SECURITY OBJECTIVES MAPPING TO SFRS..........................................................................................125 TABLE 6.11 ADDITIONAL SECURITY OBJECTIVES MAPPING TO SFRS ..............................................................................127 TABLE 6.12 SATISFACTION OF DEPENDENCIES FOR CM ...................................................................................................129 TABLE 6.13 SATISFACTION OF DEPENDENCIES FOR SAM.................................................................................................131 TABLE 6.14 SATISFACTION OF DEPENDENCIES FOR ADDITIONAL SFRS ............................................................................131 TABLE 6.15 SATISFACTION OF DEPENDENCIES FOR ASSURANCE REQUIREMENTS .............................................................132 TABLE 7.1 MAPPING OF SFRS AND SFS...........................................................................................................................142 drQSCD-ST 5 / 147 public 1. ST Introduction 1.1 ST reference ST reference: drQSCD-ST ST version: 1.2 ST date: May 2, 2019 CC version 3.1, revision 4 Assurance level: EAL4 augmented by AVA_VAN.5 and ALC_FLR_3 ST author: I4P-informatikai Kft. (I4P Ltd.) 1.2 TOE reference The TOE reference is "drQSCD version 1.0". Note: The TOE reference is displayed on the LCD screen of the Multi-Party Cryptographic Appliances (MPCAs) as "drQSCD v1.0" with the same serial number as also printed on a sticker. After starting the appliance, the very same serial number and version information are displayed on an attached monitor, as well as the configuration marks. Configuration marks for the evaluated configurations of the TOE are also displayed on the attached monitor as: 1. "Operation mode: multi-party" for the multi-party configuration, where the drQSCD consists of three identical TOE parts to operate as a logical whole in order to fulfill the requirements of this Security Target, 2. "Operation mode: standalone" for the standalone configuration, where the drQSCD consists of only one MPCA, and that alone fulfills the requirements of this Security Target, but of course cannot offer the additional services described in 6.1.4 and 7.1.8. 1.3 TOE overview 1.3.1 TOE type The drQSCD is a multi-user, multi-key device. The drQSCD is composed of two main components which can work together to fulfill different sets of requirements: • The Cryptographic Module (CM) component of the drQSCD is a general-purpose cryptographic module suitable for cryptographic support needed by its legitimate users (eg. service providers supporting local or remote electronic signature and electronic sealing operations, certificate issuance and revocation, time stamp operations and authentication services). The drQSCD can also be configured to generate, store and activate signer’s keys in one or more external CMs for speed enhancement or legacy reasons. • The Signature Activation Module (SAM) component of the drQSCD is a local application deployed within the tamper protected boundary of the drQSCD and implements the Signature Activation Protocol (SAP). It uses the Signature Activation Data (SAD) from a remote signer to activate the corresponding signing key for use in a cryptographic module. drQSCD-ST 6 / 147 public 1.3.2 TOE usage The drQSCD is a QSCD and is suitable for both (“Local” and “Remote”) use cases of [EN 419221- 5] Protection Profile. 1.3.2.1 The “Local” use case This use case (see 1.1 Figure and 1.3.2.1 in [419221-5]) is aimed at local key owners applying their own electronic signatures or seals. In this use case only the CM functionality of the TOE is used, which performs local cryptographic operations, and associated key management. These operations can be used by a client application to create qualified and non-qualified electronic signatures and electronic seals for the local key owner natural or legal person. Examples include TSPs issuing certificates and time-stamps, as well as supporting application services such as e-invoicing and registered e-mail where the service provider applies its own seal or signature. In this use case the local key owner is responsible for the security of the environment in which the drQSCD is used and managed. In this use case the drQSCD generates, stores and uses only keys that belong to and represent the local end entity, apart from its infrastructural support keys (used in internal protection mechanisms). The drQSCD provides its own development API (called CMAPI enabling the easy integration with a wide range of applications) and other well-known APIs (eg. the PKCS#11 and OpenSSLAPI). 1.1. Figure: The TOE in the “Local” use case 1.3.2.2 The “Remote” use case This use case (see 1.2 Figure and 1.3.2.2 in [419221-5]) is aimed at TSPs supporting requirements for remote signing, or sealing, as specified in [eIDAS]. In this case the inbuilt CM, as well as other external CMs configured to be used (if there are any) and the SAM functionality of the drQSCD drQSCD-ST 7 / 147 public together meets the requirements for QSCDs in the context of remote signing set out in Annex II of [eIDAS]. The SAM functionality of the drQSCD meets the requirements for Sole Control Assurance Level 2 as defined in [EN 419241-1]. In this use case the CM functionality of the drQSCD, as well as other external CMs configured to be used (if there are any) performs cryptographic operations, and associated key management, which can be used by an application using server signing, as defined in [EN 419241-1], to create qualified electronic signatures and qualified electronic seals on behalf of a legal or natural person which is distinct from and remote from the TSP which manages the drQSCD. The CM functionality of the drQSCD, as well as other external CMs configured to be used (if there are any) generates, stores and uses signing, sealing keys in a way that maintains the remote control of an identified signatory or seal creator who operates through the use of a client application. The CM functionality of the drQSCD, as well as other external CMs configured to be used (if there are any) deals with ensuring the security of keys and their use for signature or seal creation. 1.2. Figure: The TOE in the “Remote” use case The Signer’s Interaction Component (SIC) is a piece of software and/or hardware, operated on the signer’s environment under its sole control. The Server Signing Application (SSA) uses the drQSCD in order to generate, maintain and use the signing keys. The Signature Activation Protocol (SAP) allows secure use of the signing key for the creation of a digital signature to be performed by a Cryptographic Module (CM part of the drQSCD or other external CMs configured to be used, if there are any) on behalf of a signer. The use of the Signature Activation Data (SAD), which is the essential part of the SAP, ensures control over the signer’s key. The Signature Activation Module (SAM) is a software part of the drQSCD, which uses the SAD in order to guarantee with a high level of confidence that the signing keys are used under sole control of the signer. The Cryptographic Modules (CM part of the drQSCD or other external CMs configured to be used, drQSCD-ST 8 / 147 public if there are any) implement the main security functions, including cryptographic algorithms and key generation. Signature activation for the drQSCD is the following: • Signing key confidentiality and integrity are ensured by the CM part of the drQSCD, as well as other external CMs configured to be used (if there are any) (located in a tamper protected environment). • The drQSCD (SAM + CM) as well as other external CMs configured to be used (if there are any) are under control of the SSA. • The SAM part of the drQSCD participates in SAP and ensures that the signature operation is under the legitimate signer’s control. • The SSA interfaces via a secure channel the SAM which verifies the SAD in order to activate the corresponding signing key. • The signer authentication can remain for a given period and/or for a given number of signatures. • SAD computation shall be done for each signature operation, but the SAD may be linked to a set of DTBS/R, this allows the SSA to be used for bulk/batch signature purposes. • Signer authentication is done using the SIC creating a link between the signer and the signature as part of the SAD. • The SAD is transferred securely from the SIC to the SAM for verification. 1.3.3 Major security features of the TOE The drQSCD can provide both SAM and CM functionality. In the multi-party configuration different parts of the drQSCD implement secure multi-party computation (MPC) protocols. 1.3.3.1 CM functionality Based on its CM component the drQSCD is a cryptographic module. CM functionality includes but is not limited to: • generating, storing, using, backing up, restoring and destructing AES and RSA keys, • ensuring the security (confidentiality and integrity) of symmetric (AES and 3DES) keys and asymmetric (RSA, ECDSA) private keys, and pre-generated primes for RSA key pairs, • creating qualified electronic signatures and electronic seals, • performing additional supporting cryptographic operations, such as creation of non-qualified electronic signatures and seals, verification of electronic signatures and seals, cryptographic hash function, keyed-hash message authentication, AES encryption and decryption, RSA en- cryption and decryption, key derivation, TOTP verification, • supporting of authentication of client applications or authorised users of secret keys, and support of authentication for electronic identification, as identified by [eIDAS], • allowing the key owners to use TOTP one-time-passwords when activating their keys. The cryptographic services/functions above are available for ECAs and LCAs through an API. The CM functionality of the drQSCD allows to use external Cryptographic Modules (based on a configuration parameter). drQSCD-ST 9 / 147 public In this case some keys are generated, stored and used by an external CM configured to be used. The CM does not perform cryptographic operations, but invokes the external CM with appropriate pa- rameters whenever a cryptographic operation is required. This invocation is performed through a Local Client Applications (CMbr on the 1.4 Figure) using Standard PKCS#11 API. 1.3.3.2 SAM functionality Based on its SAM functionality drQSCD ensures that the remote signer has sole control of his signature keys, according to [EN 419241-1] SCAL2 for qualified signatures. SAM functionality includes but is not limited to: • authenticating the remote signer based on two authentication factors (a password and a one- time-password calculated from a shared secret), • authorising the signature operation, • activating the signing key within the internal CM functionality (and the external CM if configured, see 1.3.3.1 for details). SAM and the signer (via the SIC) communicate in order to generate the SAD. The SAD binds together signer authentication with the signing key and the data to be signed (DTBS/R). Using the SAM functionality is optional: the SAM functionality of the drQSCD can also be performed by an External Client Application, using CM APIs (see Figure 1.1). 1.3.3.3 MPC functionality In case of multi-party configuration, the drQSCD consists of three identical TOE parts (Multi-Party Cryptographic Appliances or MPCAs) to operate as a logical whole in order to fulfill the requirements of this Security Target (see 1.3. Figure). Generation of the RSA key pairs (and the pre-generated primes for them) for end users is not performed in a single MPCA, but in a distributed way, the three MPCAs jointly generate the RSA key pairs. Similarly, the three MPCAs jointly create the electronic signatures or decrypt the encrypted messages, using a multi-step signing / decrypting method. A single MPCA never knows (neither processes nor stores) the whole private key. Authentication of the end users is also performed in a distributed way, the three MPCAs jointly authenticate the end users. The drQSCD ensures the consistency among the MPCAs (eg. their databases, internal states). drQSCD-ST 10 / 147 public 1.3. Figure: TOE in multi-party configuration If one of the three MPCAs becomes dysfunctional, the other two MPCAs can ensure a limited functionality. In case of standalone configuration, the drQSCD consists of only one MPCA, and that alone fulfills the requirements of this Security Target (but of course cannot offer the additional services described in 6.1.4 and 7.1.8). 1.3.4 Required non-TOE hardware/software/firmware The following hardware, firmware and software supplied by the IT environment are excluded from the TOE boundary (see Figure 1.1): • Signer’s Interaction Component (SIC) used locally by the signer to communicate with the remote systems. • Server Signing Application (SSA) that handles communications between SAM in the drQSCD and SIC in the signer device. • Signature Creation Application (SCA) that manages the document to be signed and transfers that to the SSA through the SIC. • External Client Applications (ECAs) which can use the cryptographic services of the drQSCD, including: o Certificate Generation Application (CGA) that issues signer certificates, or o other SAM used by the remote key owner entity for qualified electronic signature, or o other applications used by the local key owner entity for qualified electronic signature and electronic sealing operations, time stamp operations, authentication services, etc. • Other external CMs configured to be used (if there are any). • CMbr which transfers the PKCS#11 commands from MPCMd to an external Crypto Module (configured to be used, if there is any) and optionally other Local Client Applications (LCAs). • Standard APIs (e.g. a PKCS#11, OpenSSL API) through which end users can securely access the drQSCD besides the evaluated CMAPI interface. drQSCD-ST 11 / 147 public 1.4TOE description Depending on its configuration the drQSCD consists of one or three MPCAs. The generic architecture of an MPCA is shown in (1.4. Figure). 1.4. Figure: MPCA architecture Physical enclosure: the MPCA is a metal, rack mountable box. Computing Hardware: a hardware platform from the CC evaluated configurations of the Operating System. Operating System: Red Hat Enterprise Linux, Version 7.1 (RHEL v7.1 has a Common Criteria EAL 4 augmented by ALC_FLR.3, certification: BSI-DSZ-CC-0999-2016) with security fixes LCA container manager: the service managing the Local Client Applications, which provide isolated execution environments for the LCAs LCA: Local client applications are embedded application running inside the physical boundary of the MPCA: • the SAM is one example of the LCAs (it is TOE part), • the CMbr is a non-TOE part LCA, • others LCAs (LCA1, LCAn in the Figure 1.4) are also non-TOE parts. LCAs can use cryptographic services/functions provided by MPCMd only through the same API which is enable for all ECAs. SAM daemon: Signature Activation Module daemon implements the Signature Activation Protocol (SAP), using the Signature Activation Data (SAD) from a remote signer to activate the corresponding signing key. In case of the multi-party configuration, the three SAM daemon jointly provide the SAM functionality. drQSCD-ST 12 / 147 public CMbr: Embedded application which transfers the PKCS#11 commands from MPCMd to an external Crypto Module (configured to be used, if there is any). ECA: External client applications communicate remotely with the TOE through a network connection. MPCMd: Multi-party Cryptographic Module daemon (also called Multi-party Cryptographic Module or MPCM) provides cryptographic services/functions for the LCAs (including SAM daemon) and the ECAs. In case of the multi-party configuration, the three MPCMd jointly provide the CM functionality. PTRNG: a smartcard chip is based on the Infineon chip SLE78600P with IDPrime 840 Smart Card. This chip has a Common Criteria EAL 5 augmented by ALC_DVS.2, AVA_VAN.5, certification: ANSSI-CC-2014/50. Tamper Detection Module: An electronic component for detecting different tamper events and capable of communicating the tamper events to the microprocessors of the CM. CM: The Cryptographic Module component of the drQSCD. The arrows on the 1.4 Figure indicate a mutual communication. 1.4.1 The physical scope of the TOE The evaluated configuration of the drQSCD includes the following items: • one or three MPCAs, and • guides, which provides guidance on the evaluated configuration and refers the reader to the relevant product guides to enable him to install and operate the drQSCD correctly: o Set-up and administration (configuring and administering the MPCMd), o Operational User Guidance (using the externally and internally available CMAPI), o Set-up and administration of SAM (configuring and administering the SAM daemon), o Signature Activation Module API (using the externally available SAMAPI). 1.5. Figure: Physical appearance of an MPCA All MPCAs include the following items: a metal, rack mountable box with external power supply unit physical interfaces of the MPCA: • network interfaces (3 Ethernet Interfaces using TCP/IP), drQSCD-ST 13 / 147 public • 2 USB interfaces for local console administration and backup purposes, • display connector for a local display, • power connector, • chargeable battery holder and battery health LED, • Power/Reset and Tamper/Confirm buttons, • LED indicators, • LCD display for version information. the internal hardware: • motherboard and CPU from the OS’s certified list, • HDDs that maintain the MPCA’s software and data (files and data records), • a Tamper Detection Module that automatically deletes sensitive information and shut downs the appliance when trying to open the appliance, • different tamper sensors, • PTRNG that provides true random seed for different cryptographic operations (eg. key generations). the internal software: • the hardened OS (based on the CC certified Red Hat Enterprise Linux, Version 7.1), • limited shell, • Multi-Party Cryptographic Module (in case of multi-party configuration, the three MPCAs jointly provide the CM functionality), • Signature Activation Module local client application (in case of multi-party configuration, the three SAM LCAs jointly provide the SAM functionality), • OpenSSL FIPS Object module v2.0.16, the FIPS 140-2 validated version of the OpenSSL (Certificate No. #1747, #2398 and #2473), which performs the TLS protocol and all non- distributed cryptographic functions, supports distributed cryptographic functions, and provides base functions for DRNG. • others LCAs (non-TOE parts). 1.4.2 The logical scope of the TOE 1.4.2.1 CM functionality Roles and available functions The CM (i.e. CM functionality of the drQSCD) maintains the following roles, associating users with roles: • Administrator, a privileged subject who can perform CM specific management operations, through a local console or the externally available CMAPI, including the following: o Create_New_Administrator (creating a new account with security attributes for an Administrator). Creating the initial (first) Administrator requires entering an installation code. o Public RSA key export (using a PKCS#10 or a CMC ([RFC 2797]) certificate request for exporting the public RSA key components). o Unblocking (unblocking access to a blocked key) o Modifying attributes of keys (Key Usage), o Audit data export/deletion (exporting and deleting the local audit file and the ErrorLog) o Backup and restore functions (restore function is under dual control). • Key User, a normal, unprivileged subject who can invoke operations on a key according to the authorisation requirements for the key. This role acts through a local client application (e.g. SAM) or through an external client application. drQSCD-ST 14 / 147 public • Local Client Application, application running inside the physical boundary of the MPCA. • External client application, application communicating remotely with one of the MPCA through a network connection. Authentication and Authorisation The CM uses a common method for identification and authentication in case of each role: a unique user identifier (sent by the user during authentication) + (static password). The password is checked against the RAD (salted, hashed and encrypted password) stored in the user’s account as a security attribute. The CM blocks the account after a predefined number of consecutive failed authentication attempts, where these administrator configurable numbers can be different for each role. Before using a secret key in a cryptographic operation an authorisation or a re-authorisation as a user of the key is always required. The CM blocks the secret key after a predefined number of consecutive failed authorisation attempts. Key Security The CM ensures the security of its keys for their whole lifecycle. The generic key lifecycle includes the methods by which a key may arrive in the drQSCD (import, generation or restore from backup), resulting in binding of a set of attributes to the key, storage of the key, and finally the ways in which a stored key may then be processed (export, use in a cryptographic function, backup, destruction). Key export/import The CM does not provide facilities to export or import Assigned keys. The CM allows import and export of secret (non-Assigned) keys only in encrypted form. Public keys may be imported and exported in a manner that protects the integrity of the data during transmission. Key generation The CM generates different types of keys for its supported cryptographic operations: • RSA key pairs (2048, 3072, 4096 bits) for end users, • infrastructural RSA key pairs (2048 bits) for internal security mechanisms, • AES keys (256 bits) for file and record encryption/decryption, • shared secrets (256 bits) for TOTP, • master secrets (384 bits) for TLS. The CM uses approved standards for key generation. The security attributes of the newly generated keys have restrictive default values. The end user’s RSA key pairs can be generated in a distributed or in a non-distributed way. The generation of all keys (including all shares of the private keys and of the pre-generated prime numbers) based on an appropriate hybrid deterministic random number generator, whose internal state uses a physical true RNG as a random source. Key restore from backup The CM provides a function to restore secret keys from backup. Only two Administrators are able to perform the restore function (dual control). In the backups, all data (including keys, key attributes, authentication data) are signed and encrypted. Consequently, any restore operation preserves their integrity (including the binding of each set of attributes to its key) and confidentiality. Binding of a set of attributes to the key The CM binds the following set of attributes to the Key User’s keys, which determine their use: drQSCD-ST 15 / 147 public Attribute Description Initialisation/Modification Key ID key identifier uniquely identifies the key within the system of which the CM is a part. Initialised by generation process Cannot be modified Owner ID identifies the Key User who owns the key. Initialised by generation process Cannot be modified Key Type identifies whether the key is a AES key or a RSA key. Initialised by generation process Cannot be modified Authorisation Data Value of data that allows a secret key to be used for cryptographic operations. The CM does not store the value of the Authorisation data, but uses it for encrypt/decrypt (share of) the key. Initialised by authenticated Key User Modified only when modification operation includes successful validation of current (pre- modification) authorisation data Re-authorisation conditions The constraints on uses of the key that can be made before reauthorisation, and which determine whether a subject is currently authorised to use a key. Initialised by generation process Cannot be modified Key Usage The cryptographic functions that are allowed to use the key Initialised by creator during generation Cannot be modified Assigned Flag indicates whether the key has currently been assigned. For an Assigned Key, its authorisation data can only be changed on successful validation of the current authorisation data – it cannot be changed or reset by an Administrator – and the re-authorisation conditions and key usage attributes cannot be changed. Allowed values are ‘assigned’ and ‘non-assigned’. Initialised by generation process Cannot be modified Uprotected Flag indicates whether the stored key is protected only with an infrastructural key, or additionally with a password established by the Key User (key’s owner). This flag is initialised by key generation process, setting its value to “no”. When the Key User establishes his/her Authorisation Data, the value of this flag is set to “yes”. Initialised by generation process Modified only when the Key User establishes his/her Authorisation Data Operational Flag indicates whether the key is in operational state. This flag is initialised by key generation process to “non- operational”. A key can be used for cryptographic operations only in “operational” state. Only the Key User (key’s owner) is able to change the value of this flag from “non-operational” to “operational” and vice versa. Initialised by generation process Can be modified only by Key User Integrity Protection Data is a digital signature created by an infrastructural key for key data record which contains the key and its attributes Cannot be modified by users (maintained automatically by TSF) Key Device Type indicates whether the key is generated, stored and used by the TOE itself (default) or by an external CM (configured to be used) Initialised by creator during generation Cannot be modified Table 1.1 Key Attributes Storage of the key The CM protects the integrity of keys and their attributes: • All stored data records (including keys with their security attributes) have a “record signature” element which is a PKCS#1 RSA signature with an infrastructural key. • Before any use of a key a signature verification is performed for its “record signature”. • Upon detection of a data integrity error, the CM prohibits the use of the altered data and notifies the error to the user. drQSCD-ST 16 / 147 public The CM protects the confidentiality of secret keys and their sensitive attributes: • All stored secret keys and all sensitive key attributes are encrypted with an infrastructural key. • The CM explicitly denies the access to the plaintext value of any secret key (neither directly nor through intermediate values in an operation). Key export The CM controls the key export: • only authorized Administrators are able to perform key export, • only non-Assigned keys are allowed to export, • only keys with “Export Flag”=”exportable” are allowed to export. The CM protects the confidentiality of secret keys during export: • key export requires a secure channel, • key export is allowed only in encrypted form. Key usage An authorisation is required before use of a key and the key can only be used as identified in its Key Usage attribute. In addition, the initial authorisation, a re-authorisation is required depending the re-authorisation conditions such as expiry of a time period or number of uses of a key, or after explicit rescinding of previous authorisation. The CM protects the authorisation data: minimizes the time that authorisation data is held; stores only in RAM; zeroises before deallocation. The CM blocks the access to a key on reaching an authorisation failure threshold. Only an administrator is able to unblock a key, but the unblocking process does not itself allow the keys to be used. Unblocking access to a key does not allow any subject other than those authorised to access the key at the time when it was blocked. The CM supports different approved algorithms for different purposes identified in the Table 1.2. cryptographic operations cryptographic algorithms cryptographic key sizes applicable standards supported operations creation of digital signatures and seals RSA 2048, 3072, 4096 bits [TS 119312], [PKCS #1], [FIPS 186-4] local signing, remote server signing verification of digital signatures and seals RSA 2048, 3072, 4096 bits [TS 119312], [PKCS #1], [FIPS 186-4] checking the integrity protection data cryptographic hash function SHA-1 SHA-224, SHA256, SHA384, SHA512 none [TS 119312], [FIPS 186-4] TLS protocol, signing a log or a database record or a stored file, generating or checking the integrity protection data keyed-hash message authentication HMAC_ SHA256 384 bits message digest sizes: 256 bits [RFC 2104] TLS protocol, PBKDF2 key derivation cipher-based message authentication code AES-CMAC sizes: 256 bits [RFC 4493] TLS protocol, PBKDF2 key derivation encryption and decryption AES (in CBC, CCM, CFB1, CFB8, CFB, CTR, ECB, GCM, OFB, XTS mode) 128, 192, 256 bits [FIPS 197], [SP 800- 38A] data encrypting/decrypting TLS protocol, SAP protocol, writing/reading a stored file or data record drQSCD-ST 17 / 147 public cryptographic operations cryptographic algorithms cryptographic key sizes applicable standards supported operations encryption and decryption 3DES (in ECB, CBC, CFB1, CFB8, CFB, OFB mode) 192 bits [SP 800- 38A] data encrypting/decrypting secure messaging - encryption and decryption RSAES-PKCS1- v1_5 2048 bits [PKCS#1] TLS protocol, SAP protocol, wrapping/unwrapping the AES keys key derivation PBKDF2 length of password [PKCS#5] encrypting passwords, deriving key encryption keys TOTP verification HOTP 256 bits [RFC4226] [SP 800-90A] using for HOTP cryptographic support for one time password (TOTP verification) HOTP 256 bits [RFC4226], [RFC6238] possession-based authentication of the Signer random number generation CTR_DRBG x bytes [SP 800-90A] genaration of keys, IVs, session IDs, salt key exchange ECDH elliptic curves: secp224k1 secp256r1 secp384r1 secp521r1 sect233k1 sect283k1 sect409k1 sect571k1 sect233r1 sect283r1 sect409r1 sect571r1 [SP 800- 56A] key exchange digital signature creation and verification ECDSA elliptic curves: secp224k1 secp256r1 secp384r1 secp521r1 sect233k1 sect283k1 sect409k1 sect571k1 sect233r1 sect283r1 sect409r1 sect571r1 c2pnb208w1 c2tnb239v1 c2tnb239v2 c2tnb239v3 c2pnb272w1 c2pnb304w1 c2tnb359v1 c2pnb368w1 c2tnb431r1 [SEC 2] [X9.62] [FIPS 186-4] local signing, remote server signing Table 1.2 Supported cryptographic operations and algorithms Key backup The CM provides a function to backup the TOE, thus the stored secret keys. Only Administrators are able to perform the backup function. All backups are signed, Consequently, any backup preserves their integrity (including the binding of each set of attributes to its key). All backups are encrypted. Consequently, any backup preserves their confidentiality. Key destruction drQSCD-ST 18 / 147 public All secret keys and all authorisation data are zeroised (with physically overwriting) at the end of their lifecycle or after they have been deallocated. TSF data protection The CM ensures the security of its TSF data, implementing self-tests, and providing secure failure and tamper protection capability. Self tests The CM provides a suite of self tests, which check and demonstrate the correct operation of the CM security functionality. The CM implements these self tests: • during initial start-up (including software/firmware integrity test, cryptographic algorithm tests and random number generator tests), • periodically during normal operation (e.g. checking the environmental resources, checking whether the environmental conditions (including temperature and power) are outside normal operating range), • at the request of the Administrator (software/firmware integrity tests), • at the conditions (e.g. RSA pair-wise consistency tests during the RSA key pair generation) Each MPCA performs the same self-tests, but at different times. Secure failure In case of critical failures, the CM enters a secure error state, in which it no more services its end users, but only performs infrastructural services. These critical errors include but are not limited to the following: self-test fails, environmental conditions are outside normal operating range, failures of critical TOE hardware components (including the RNG) occur. Tamper protection The CM implements a tamper detection security function: • The MPCAs are protected by using uniquely identifiable tamper-evident seals and an appropriate physical design that allows the Administrator to verify the physical integrity of the MPCAs as part of a routine inspection procedure. • This requires regular visual inspection of the MPCAs for signs of tamper at a frequency determined by the risk assessment of the specific operational environment. The CM has a tamper resisting architecture: • All secret keys are stored in different hardware components (MPCAs) in a distributed way. • All shares of the secret keys and all sensitive key attributes stored permanently in the CM are encrypted with an infrastructural key. • Authorisation data are not stored permanently in the TOE. The CM implements a tamper response security mechanism: • Tamper response is based on active protection of the MPCA. It is a combination of tamper sensors, temperature and voltage monitor. • If any MPCA detects a physical tampering (eg. removing the cover of the closed physical enclosure) the CM enters a Tamper state. • A result of the entering the Tamper state: o all processing of end users’ requests are halted, o all authentication and authorisation data, all key shares and all sensitive key attributes stored temporarily in RAM are immediately zeroized with physically overwriting, o the internal state of the DRNG is zeroized with the uninstantiate function. • If the CM is in Tamper state, the CM does not perform any cryptographic operation and does not respond to any user request. Audit drQSCD-ST 19 / 147 public The CM audits all security related events. The audit records do not include any data which allow to retrieve sensitive data, Every audit record includes the time of the event, subject identity (if applicable) and a human readable descriptive string about the related event. The CM detects unauthorised modification (including deletion and insertion) to the stored audit records in the audit trail. Every block of audit record includes a serial number, a reliable time stamp (date and time of the event), an identifier of the related MPCA, and are signed with an infrastructural key. The CM automatically transfers the blocks of audit records to an external audit server. If the transfer of an audit block has failed, the CM temporarily accumulates audit blocks locally in an audit directory, and periodically retries the transfer to the external audit server. If the audit sub-system doesn’t work for a reason, a special file (ErrorLog) is created and the audit records are appended to it while the system shuts down. When local audit storage exhaustion is detected, the CM requires the local audit file to be successfully exported and deleted before allowing any other security related actions. Only the Administrator is able to export and delete the local audit file and the ErrorLog. Trusted communication The CM implements and enforces: • a secure channel based on TLS protocol, for communication with Administrators (through the SSA) and ECAs, • a secure channel based on SSH protocol, for communication with Administrators (using the console command interface in the provided limited shell), • a direct channel for communication with Administrators (using the console command inter- face with a physical keyboard), The internal communication among different CM parts (among MPCAs) is also protected by TLS protocol. MPCM and CMbr are located within the physical boundary of the same hardware appliance then the communication between them is a trusted communication (the trusted path may be mapped to the physical configuration). Optional using of external CMs The CM functionality of the drQSCD allows to use external Cryptographic Modules (based on a configuration parameter). If a key initialised by creator during generation other than ‘default’, the CM functionality does not perform cryptographic operations, but invokes the external CM with appropriate parameters when- ever a cryptographic operation is required. This invocation is performed through a Local Client Applications (CMbr on the 1.4 Figure) using Standard PKCS#11 API. This invocation is related the following “Key Security” CM functionalities detailed above: Key generation The CM can invoke the extended CM: to generate RSA key pairs (2048, 3072, 4096 bits) for end users, the security attributes of the newly generated keys have restrictive default values, the end user’s RSA key pairs can be generated only in a non-distributed way. Binding of a set of attributes to the key drQSCD-ST 20 / 147 public Same as in case of the CM. Key usage Initial authorisation, re-authorisation, protection of the authorisation data, blockin/unblocking key: same as in case of the CM: Supported cryptographic operations and algorithms: Key destruction The CM can invoke the extended CM: to delete a RSA key pair (with physically overwriting) cryptographic operations cryptographic algorithms cryptographic key sizes applicable standards supported operations creation of digital signatures and seals RSA 2048, 3072, 4096 bits [TS 119312], [PKCS #1], [FIPS 186-4] local signing, remote server signing verification of digital signatures and seals RSA 2048, 3072, 4096 bits [TS 119312], [PKCS #1], [FIPS 186-4] protection data Table 1.3 Supported cryptographic operations and algorithms in case of extended CM Random numbers needed by the SAM functionaly for use as keys, in protocols or seed data for another random number generator that is used for these purposes always are generated by MPCMd (and not by an external CM). 1.4.2.2 SAM functionality Roles and available functions The SAM (i.e. SAM functionality of the drQSCD) maintains the following roles: • Privileged User, who can perform SAM specific operations, through a local console or the externally available SAMAPI, including the following: o Create_New_Signer (creating a new account with security attributes for a Signer), o Signer_Maintenance (e.g. deleting a Key_Id from the Signer's account), o Create_New_Privileged_User (creating a new account with security attributes for a Privileged User). Creating the initial (first) Privileged User requires entering an installation code, o SAM_Maintenance (creating and modifying the SAM configuration data record and SAM configuration file), o Backup and Restore functions (Restore function is under dual control), o Signer Key Pair Generation (have the CM generate a new RSA key pair and assigning it to a Signer's account). • Signer, who communicates remotely with the SAM (invoking different SAP commands), drQSCD-ST 21 / 147 public and is able to perform the following operations: o Signer Key Pair Generation Request (requesting a new RSA key pair generation and assigning it to his/her account), o ChKeyPwd (establishing or modifies the key Authorisation Data for his/her key), o Signing (utilizing his/her signing key in the CM, transmitting the required data, including the unique user ID, two different authentication factors, the key ID, the key Authorisation Data and one or more DTBS/R), o Signer_Maintenance (deleting a Key_Id from his/her account and querying the security attributes of his/her account). Authentication For the Privileged Users, the SAM uses the same identification and authentication method as the CM: a unique user identifier and a password. For the Signers, the SAM requires two different authentication factors: a password (knowledge-based factor) and a TOTP (possession-based factor). Cryptographic Support The SAM does not perform cryptographic operations for its users: especially it does not generate/store/destruct, export/import, backup/restore, or use user key. The SAM invokes the internal CM (or the external CM if configured, see 1.3.3.1 for details) with appropriate parameters whenever a cryptographic operation for the Signer is required. The SAM uses different infrastructural keys to protect its stored files and database records, and data transmitted or received via communication channels. Audit The SAM audits all security related events. The audit records do not include any data which allow to retrieve sensitive data. The SAM’s audit functionality is the same as the CM’s. Trusted communication The SAM implements and enforces: • a secure channel based on TLS protocol, for communication with Privileged Users (through the SSA), • a secure channel based on SSH protocol, for communication with Privileged Users (using the console command interface in the provided limited shell), • a secure channel based on the proprietary SAP protocol, • a direct channel for communication with Privileged Users (using the console command in- terface with a physical keyboard). The internal communication among different SAM parts (among MPCAs) is also protected by TLS protocol. The communication between SAM and Signer based on a proprietary Signature Activation Protocol. The SAP is protected against replay, bypass and forgery attack, using a nonce, a time stamp and a shared secret. The SAP provides confidentiality and integrity protection for all transmitted data, including the authentication and authorization data and DTBS/R(s). Using the SAM functionality is optional: the SAM functionality of the drQSCD can also be performed by an External Client Application, using CM APIs (see Figure 1.1). drQSCD-ST 22 / 147 public 1.4.2.3 MPC functionality In case of multi-party configuration, the drQSCD consists of three separate TOE parts (MPCAs) to operate as a logical whole in order to fulfill the requirements of this Security Target. This security function based on the distributed structure of the drQSCD ensures the following: • Distributed cryptography, • Secret sharing, • Consistency protection, • Fault tolerance. Distributed cryptography Generation of the RSA key pairs (and the pre-generated primes for them) for Key Users is not performed in a single MPCA, but in a distributed way. The three MPCAs jointly generate the RSA key pairs so that at the end of the generation: • the public RSA key part is publicly known, but • none of the MPCAs holds the whole private RSA key part, only a share of it. Similarly, the three MPCAs jointly create the digital signatures or decrypt the encrypted messages, using a multi-step signing/decrypting method. Each MPCA computes a partial cryptographic operation with own RSA private key share so that at the end of the operation: • the result is a standard digital signature (or a decrypted message) in accordance with RSA cryptographic algorithm, • after signature creation (or message decryption) the shares of the private RSA key remain secret, none of the MPCAs revealed its private RSA shares to the other MPCAs. The Key Users can interact with any MPCA (permitted by the configuration of the IT environment, eg. firewall rules) through the externally available APIs. The distributed operation of the drQSCD and internal communication among the MPCAs (in order to synchronize their databases) takes place behind the scenes. Secret sharing Based on distributed RSA key pairs generation and distributed cryptographic operation, the drQSCD achieves a new guarantee for ensuring the sole control of Key User’s private keys: a single MPCA never knows (neither processes, nor stores) the whole private key. Authentication of the end users is also performed in a distributed way, the three MPCAs jointly authenticate the end users. The three MPCAs store shared values for password and TOTP secrets. Consistency protection The drQSCD ensures that TSF data are consistent when they are replicated between TOE parts (MPCAs). When MPCAs are disconnected, the drQSCD ensures the consistency of the replicated TSF data upon reconnection before processing requests for any secure relevant management or user function. This security function is based on the nested transactions capability of the used database engine (LMDB). Fault tolerance In case of multi-party configuration, the drQSCD ensures a fault tolerance capability: if one of the three MPCAs becomes dysfunctional (a result of a fatal error or a network unavailability) the other drQSCD-ST 23 / 147 public two MPCAs can ensure a limited functionality. The available functions in this case are: • the following distributed cryptographic services: • RSA signature creation, • RSA decryption. • the following non-distributed cryptographic services: • RSA/ECDSA signature creation, • RSA/ECDSA signature verification, • Random number generation, • RSA encryption/decryption, • AES and 3DES encryption/decryption, • Hybrid (RSA, AES) and (RSA, 3DES) file encryption, • Cryptographic hash function, • Keyed-hash, • Key derivation, • TOTP verification, • Cipher-based message authentication code operation, • ECDH key exchange, • Identification and authentication, • Audit record protection. 1.4.2.4 States and lifecycle stages of the drQSCD The 1.6. Figure illustrates the different states of an MPCA: Delivered (D), Operational-power_on (O_on), Operational-power_off (O_off), Error (E) and Tampered (T). The supplier (developer/manufacturer) delivers the drQSCD (i. e. the one or the three MPCAs) to the customer in Delivered state. In this state, all software and hardware components of the MPCA(s) are installed, pre-configured and initialized. The physical enclosure is closed, and all MPCAs assure active tamper detecting and tamper resistance functionalities. In this state users cannot perform any functions of the drQSCD described in 1.3.3 and 1.4.2. 1.6. Figure: Diagram of the different states and state transitions of an MPCA drQSCD-ST 24 / 147 public Powering off an MPCA triggers the transition from Operational-power_on state to Operational- power_off state, just like powering on launches the transition from Operational-power_off state to Operational-power_on state. Detecting a fatal error (according to FPT_FLS.1) triggers the transition from Operational-power_on states to Error state. The Error state indicates an appliance malfunction that requires a security log analysis (to determine the reason of the error) and then resetting or repairing of the MPCA. Detecting a tampering triggers the transition from Operational-power_off and Operational- power_on states to Tampered state. The Tamper state indicates the detection of a physical tampering that requires a deep and wide investigation (including security log analysis) to determine whether an error or a tampering has occurred. Depending on the conclusions, the result could be a resetting, a restoring or a repairing. In Error and Tampered states users cannot perform any functions of the drQSCD, except that the Administrator can try to export the local audit and Errorlog file. 1.4.2.4.1 In the case of multi-party configuration: If all three MPCAs are in Operational-power_on state, users can activate all functions of the drQSCD. If two of the three MPCAs are in Operational-power_on state, users can activate the limited functionality of the drQSCD, which contains almost all functions, except management and key generation functions (see “Fault tolerance” above). In case of only one MPCA is in Operational-power_on state, only the non-distributed end user services function. 1.4.2.4.2 In the case of standalone configuration: If the only MPCA is in Operational-power_on state, users can activate all functions of the drQSCD. 1.4.3 Features and Functions not included in the TOE Evaluation The drQSCD is capable of a variety of functions and configurations which are not covered by the PPs that this ST claims conformance to. Although the TOE is capable of these functionalities, the following features have not been examined within the framework of this evaluation: • building up the system from any number of identical MPCAs (n= 2, 4, 5, …), • using any t-out-of-n combination with the Threshold Signature RSA-typed Scheme (where private RSA key is shared among the n participating parties and at least t parties are required for creating a signature, where t