FIPS Applet on RookySE

Certificate

Approved Algorithms (27)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for FIPS Applet on RookySE
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Firmware Load<br/>Update<br/>upgrade</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>unauthenticated<br/>Status output</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for FIPS Applet on RookySE
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Firmware Load<br/>Update<br/>upgrade</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>unauthenticated<br/>Status output</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C6 clueLow;

Security Policy, page by page

FIPS Applet on RookySE FIPS Applet v1.6.1.4 on RookySE ‘097153’ FIPS 140-3 Non-Proprietary Cryptographic Module Security Policy Version: 1.2 Revision Date: 30/09/2024

About IDEMIA OT-Morpho is now IDEMIA, the global leader in trusted identities for an increasingly digital world, with the ambition to empower citizens and consumers alike to interact, pay, connect, travel and vote in ways that are now possible in a connected environment. Securing our identity has become mission critical in the world we live in today. By standing for Augmented Identity, we reinvent the way we think, produce, use and protect this asset, whether for individuals or for objects. We ensure privacy and trust as well as guarantee secure, authenticated and verifiable transactions for international clients from Financial, Telecom, Identity, Security and IoT sectors. With close to €3bn in revenues, IDEMIA is the result of the merger between OT (Oberthur Technologies) and Safran Identity & Security (Morpho). This new company counts 14,000 employees of more than 80 nationalities and serves clients in 180 countries. | For more information, visit www.idemia.com / Follow @IdemiaGroup on Twitter Specifications and information are subject to change without notice. The products described in this document are subject to continuous development and improvement. All trademarks and service marks referred to herein, whether registered or not in specific countries, are the properties of their respective owners. - Printed versions of this document are uncontrolled 2/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

TABLE OF CONTENT 3/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

4/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

TABLE OF ILLUSTRATIONS 5/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

TABLE OF TABLES Table 4 Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed 14 Table 11 Approved Services - ISO19790:2012 7.4.3 Services, Non Security-Relevant Services, or Services Using 6/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

This document defines the Security Policy for FIPS Applet on RookySE with firmware FIPS Applet v1.6.1.4 on RookySE ‘097153’ cryptographic module. FIPS Applet on RookySE is a Hardware Security Module made by Idemia, hereafter denoted the module. The module, validated to [NIST.FIPS.140-3] overall Level 3, meets security levels of following individual areas. FIPS Applet on RookySE is a cryptographic module intended to be used as hardware security module. It is designated for creating, storing, and operating keys with some cryptographic operations capabilities, and it relies on a secure element hardware with a tamper-protection.

This cryptographic module, is a hardware module, and is a single chip. It is operated by embedded Global Platform OS with card manager capability for firmware (applet) loading, installation, or deletion. FIPS Applet is loaded at manufacturing and is part of the module. The module boundary is shown in red in the following picture: 7/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

Figure 1 Module Boundary The below picture shows the FIPS Applet on RookySE Cryptographic Module in a single chip (Module count is 1) in VQFN32 form factor with dual interface (ISO 7816 T0 Contact Protocol and SPI Protocol): 8/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Figure 2 FIPS Applet on RookySE Chip

Below components are part of the module: Table 2 Cryptographic Module Tested Configuration The module can be in one of the two configurations below. The configuration is set in the manufacturing stage. FIPS Certified Product (FCP) This product configuration is intended to meet FIPS requirements and be validated by validation authority. This Security Policy describes this configuration. Non-FIPS Certified Product (NFCP) This product configuration is not intended to meet FIPS requirements and is out of scope of the FIPS evaluation. The module does not implement any Vendor Affirmed Operational Environments.

The module supports an applet instance that is running only in one mode of operation that is an approved mode. All services provided by the module when set in configuration FCP are approved services as specified in the section 4.3.2. A global indicator via FIPS Applet GET INFO service (unauthenticated service) is provided to show the status mode of operation.

This mode means that the module is applying strictly rules of the FIPS requirements and the security policy is enforced. Access to some services is restricted and only approved services as specified in section 4.3.2 are available for users. 9/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

In this mode, customer is still allowed to load additional firmware but this is restricted to firmware (applet) that is already validated under [NIST.FIPS.140-3]. Any firmware (applet) that is not validated [NIST.FIPS.140-3] will cancel the FIPS status of the module. A procedure for firmware loading is described in [FQR 401 9097 Ed 4] section 3.4.2.

The module implements the ‘approved security functions’ and ‘non-approved but allowed security functions’ listed in Table 3 and Table 4 respectively.

Note that the full cryptographic algorithm implementation capabilities were tested for the Approved cryptographic functions but only algorithms / mode / key sizes / functionalities identified in the Table 3 are implemented by the module. 10/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Description / CAVP        Algorithm and       Mode/                       Key Size(s) /   Use Cert       Standard            Method                      Key             / Function Strength(s) AES A2912     [NIST.FIPS.197]      ECB, CBC                    128/192/256     Data encryption/decryption [NIST.SP.800-38A] AES                                                              MAC Generation/Verification, A2912                          CMAC                        128/192/256     SP800-108 KDF [NIST.SP.800-38B]

Establishment ECC P-224, ECC P-256, ECC P-384, ECC P-521,

Generation” of              TDES-128, Symmetric Keys              TDES-192, CKG Vendor                          6.2.1 Symmetric Keys                        Key generation Affirmed [NIST.SP.800-       Generated Using Key-                        Symmetric and Asymmetric HMAC 64, 133.Rev2]           Agreement Schemes           HMAC 128,

Derived from a Pre-         HMAC 224, existing Key                HMAC 256, HMAC 320, HMAC 384, HMAC 512, AES 128, AES 192, AES 256 DRBG                                                            Deterministic Random Bit A2912      [NIST.SP.800-       CTR                         256             Generation 90A.Rev1] CKG using method in         P-224,          ECDSA Key Generation, ECDSA               section 4 and 5.1           P-256, A2912 [NIST.FIPS.186-4]   [NIST.SP.800-133.Rev2]      P-384, P-521 P-192,          ECDSA Key Verification P-224, ECDSA A2912                                                      P-256, [NIST.FIPS.186-4]                               P-384, P-521 SHA2-224,                   P-224,          ECDSA Signature ECDSA               SHA2-256,                   P-256,          Generation A2912 [NIST.FIPS.186-4]   SHA2-384,                   P-384, SHA2-512                    P-521 SHA-1,                      P-192,          ECDSA Signature SHA2-224,                   P-224,          Verification ECDSA A2912                          SHA2-256,                   P-256, [NIST.FIPS.186-4]   SHA2-384,                   P-384, SHA2-512                    P-521 11/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Hardware True RNG used to seed the DRBG. The minimum number of bits of ENT (P)   Entropy Source        Physical                                       entropy is specified in the [NIST.SP.800-90B]                                                    Table 17 Non-Deterministic Random Number Generation Specification SHA2-256                                       Message Authentication; HMAC                                            Key strength : 112 A2912                          SHA2-384,                                      SP800-108 KDF [NIST.FIPS.198-1]                               (minimum) SHA2-512                                       MAC Generation SHA-1, HMAC                  SHA2-256,                 Key strength : 64    Message Authentication; A2912 [NIST.FIPS.198-1]     SHA2-384,                 (minimum)            MAC Verification SHA2-512 P-521       curve KAS-ECC                                         providing     256 with bilateral key                             KAS-ECC SP800-56Ar3 A2912    [NIST.SP.800-         confirmation              bits of encryption 56A.Rev3]                                       strength HMAC-64, HMAC-128, HMAC-160, HMAC-224, HMAC-256,            Key Derivation KDF                                             HMAC-320, A2912                          AES CMAC, HMAC            HMAC-384,            Symmetric Keys Derived [NIST.SP.800-108]                                                    from a Pre-existing Key HMAC-512 using KDF AES-128, AES-192, AES-256 KTS       (Secure                              256 bits keys SP 800-38F. KTS (key                           AES-CBC, AES-CMAC providing 256 bits A2912    Channel GP)           wrapping and of encryption [NIST.SP.800-38F]     unwrapping) per IG D.G. strength KTS       (Secure                              256 bits keys SP 800-38F. KTS (key                           AES-CBC, AES-CMAC providing 256 bits A2912    Session)              wrapping and of encryption [NIST.SP.800-38F]     unwrapping) per IG D.G. strength 128,192, 256 bits KTS        (Token    SP 800-38F. KTS (key      keys providing AES-CBC, AES-CMAC A2912    transport )           wrapping and              128,192, 256 bits [NIST.SP.800-38F]     unwrapping) per IG D.G.   of encryption strength A2912    RSA                   N/A 2048/3072/4096       RSA Key Generation [NIST.FIPS.186-4] SHA2-224, RSA Signature Generation A2912    RSA                   SHA2-256, 2048/3072/4096       using PCKS1 v1.5 and PSS [NIST.FIPS.186-4]     SHA2-384, Scheme SHA2-512 SHA-1,                                         RSA Signature Verification SHA2-224,                                      using PCKS1 v1.5 and PSS A2912    RSA                                             1024/2048/3072/4 SHA2-256,                                      Scheme [NIST.FIPS.186-4]                               096 SHA2-384,                                      (SHA-1 and module 1024 SHA2-512                                       allowed for legacy use) 12/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Primitive RSA (CVL)                                                The RSA SigGen (CVL) shall A2912 [NIST.FIPS.186-4]                                        only be used within the context of a FIPS 186-4 signature generation SHA3-224, SHA-3                 SHA3-256, A2912                                                   N/A      Message Digest [NIST.FIPS.202]       SHA3-384, SHA3-512 SHA-1, SHA2-224, SHS A2912                          SHA2-256,                N/A      Message Digest [NIST.FIPS.180-4]     SHA2-384, SHA2-512 Table 3 Approved Algorithms 13/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

These algorithms do not claim any security and are not used to meet [NIST.FIPS.140-3] requirements. Therefore, SSPs do not map to these algorithms. Algorithm Caveat Use / Function CSPs obfuscation with a nonCSPs obfuscation (no security claimed) Approved algorithm Table 4 Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation with security claimed.

The module provides a dual interface for communications that is available to all users: ISO7816 T0 Contact Protocol and Serial Peripheral Interface (SPI) Protocol. These two interfaces cannot be used simultaneously. Data output is inhibited during error states in any interface. The module acts as a slave device and does not

In the ISO7816 T0 protocol, data output is inhibited during key generation, self-tests, and zeroisation except for procedure byte NULL ‘60’ transmission in order to keep the communication between module and the interface device still alive. Table 5 Ports and Interfaces in ISO7816 T0 Contact Protocol

In the SPI protocol, data output is inhibited during key generation, self-tests, and zeroisation with exception for Check Alive SPI command. This command is used to check if the module is still alive or not. This command can temporarily interrupt the current execution of key generation, self-tests, or zeroisation. 14/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Table 6 Ports and Interfaces in Serial Peripheral Interface (SPI) Protocol

The FIPS Applet on RookySE Cryptographic module supports following user roles: User Role – Performing general security services including Key Management and Cryptographic services The standard user’s role is configurable based on access control list in a profile that is set by ADMIN for a user. E.g a user can be a standard user A that have role to do Crypto functions but no role for key management 15/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

The module does not support a maintenance role. Additionally, any user is allowed to perform non-sensitive services such as requesting status information, without prior authentication. There are three types of authentication methods employed by the Module:

1. Global Platform Secure Channel Protocol ‘03’ (GP SCP ‘03’) Authentication
2. FIPS Applet Password-based Authentication
3. FIPS Applet Smartcard-based Authentication In the FIPS applet implementation, the module does support authentication level up to two levels where the last authenticated user will override the access control of the first authenticated user. The active access control in the second level is based on second authenticated user’s profile. When this user logoff, the active access control is set back to the first authenticated user’s profile. This authentication level is only applicable for authentication number 2 and number 3 above that is designed for specific procedure such as Key Ceremony, System Reset, or System Unblock services.

4.2.1 Global Platform Secure Channel Protocol ‘03’ (GP SCP ‘03’) Authentication

The Secure Channel Protocol authentication method is provided by the Secure Channel service. The SDKENC and SD-KMAC keys are used to derive the SD-SENC and SD-SMAC keys, respectively. The off-card entity participating in the mutual authentication sends a 64-bit challenge to the Cryptographic Module. The Cryptographic Module generates its own challenge and computes a 64-bit cryptogram with SD-SMAC key and both challenges. The Cryptographic Module cryptogram and challenge are sent to the off-card entity which checks the Cryptographic Module’s cryptogram and creates its own 64-bit cryptogram with both challenges. A 64-bit message authentication code (MAC) is also computed on the command containing the off-card entity cryptogram with AES-CMAC and SD-SMAC key, the MAC is concatenated to the command, and the command is sent to Cryptographic Module. The Cryptographic Module checks the message authentication code and compares the received cryptogram to the calculated cryptogram. If all of this succeeds, the two participants are mutually authenticated (the external entity is authenticated to the Module in the AA role). GP Secure Channel Protocol establishment provides mutual authentication service as well as establishment of a secure channel to protect confidentiality and integrity of the transmitted data.

The FIPS Applet uses identity-based operator authentication to enforce the separation of roles and allow corresponding services within each role. FIPS Applet Password-based Authentication The operator must enter its user name and its password for authentication process. The username is an alphanumeric string. The password is a binary string of a minimum of eight (8) characters. Key Agreement technique ((Cofactor) Full Unified Model, C(2e, 2s, ECC CDH) with bilateral key confirmation is used for mutual authentication and to derive session keys (H-SKAuthEnc, HSKAuthMac, H-SKAuthKC). H-SKAuthKC is used to calculate MAC of user credential (user token) for 16/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

authentication. If this mutual authentication process is success, the user can be verified via Key Confirmation using USER AUTH service employing user token. Other session keys, H-SKAuthEnc and H-SKAuthMac are used for protecting the message in Secure Channel. This scheme protects from eavesdropping and provides perfect forward secrecy. FIPS Applet Smartcard-based Authentication The operator must use smartcard that owns unique user EC-key pair used for Key Agreement ((Cofactor) Full Unified Model, C(2e, 2s, ECC CDH) with bilateral key confirmation). The static user key is different per user and stored inside the smartcard which is considered as secure enclave. The user must enter his pin for verification by the smartcard in order to use his static key and to perform key agreement. The rest of user authentication process is similar with the password-based method, except there is no password involved in the user token. Upon correct authentication, the role is selected based on current logged user’s profile. During authentication session keys are negotiated which are used to secure subsequent services request from operator. Since the session keys (and session ID) are stored in volatile memory all information about the authentication and session is lost if the module is powered down. 17/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Table 8 Role and Authentication

All services implemented by the module are listed in the section 4.3.1 for each service description and its access for each Role. The module only provides approved services listed in the section 4.3.2 Approved 18/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Services. The module does not provide bypass or self-initiated output capabilities. Each service of the module returns completion status to indicate successful execution or specific error code.

The following table shows data input and output of each service employed by the module. Some services do not require an operator to assume an authorized role. In this case the associated role is marked with the role UU (Unauthenticated User) defined in Table 7 Completion Status that indicates execution status result (success or error with specific reason code) 19/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

20/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

21/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

22/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Table 9 Roles, Service Commands, Input and Output 23/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Services listed below are approved services: either FIPS-approved security services, [ISO/IEC 19790] 7.4.3 services, non security-relevant services, or services using non-approved algorithm but claiming no security. Those services are available when the module is running in approved mode of operation. 24/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

E Completion Status that indicates execution status result (success or error with specific reason code) 25/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

26/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

27/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

28/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

29/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

30/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

31/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

32/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Table 10 Approved Security Services G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. - = Not accessed by the service 33/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Table 11 Approved Services - ISO19790:2012 7.4.3 Services, Non Security-Relevant Services, or Services Using NonApproved Algorithm but Claiming No security The module does not support any non-approved services.

The module employs GP APDU Commands i. e Load command and Install command as specified in [GPC_Specification_v2.3] as part of GP Manage Content Services for firmware loading. Due to I/O buffer size of the module, the firmware loading process utilizes several Load commands and Install command. Data output is inhibited in each APDU command execution and during Load Test. The module performs Load Test specified in the section 10.2.2 during firmware loading process. If the load test is failed, specific Status Word of the command is returned to indicate failure on firmware loading and the firmware cannot be used. New firmware version within the scope of this validation must be validated through the [NIST.FIPS.140-3] CMVP. Any other firmware loaded into this module is out of the scope of this validation and requires a separate [NIST.FIPS.140-3] validation. A procedure for firmware loading is described in [FQR 401 9097 Ed 4] section 3.4.2. 34/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

Initial firmware is loaded through a chip loader (referenced as Initial Flash Loader) and provided by Hardware Manufacturer. The loader is used to decrypt a RookySE firmware delivered in an encrypted firmware. Once full firmware is received and deciphered, a final checksum is sent to the Flash Loader to compare against the internal computed checksum. From the RookySE firmware, OS checksum can be verified through a GP GET DATA command on DGI DF6E. During this command, the checksum is recalculated on the OS memory range. In case of memory corruption, the card might trigger a security event. OS checksum is checked using a 16-bit EDC and compared against a stored value in NVM. Beside OS Firmware verification, the module also ensures the Applet Packages integrity by computing a CRC16 on each package, and comparing against stored values. The laters are computed during application loading and stored as references. Upon a failed checksum verification, the OS Firmware will trigger a security event. The operator can perform a warm or cold reset to check OS integrity and NVM (applet packages) integrity is valid or not as specified in section 10.1.1 integrity self test.

The module consists of several components that have different forms of executable code. The following table shows the form of each component: Table 12 Form of Executable Code

The module permits operators to initiate the pre-operational self-tests on demand by power cycling the module.

Not Applicable (Remarks. The module is designated as a limited operational environment under the [NIST.FIPS.140-3] definitions. The module includes a firmware load process (GP Manage Content service) to support necessary updates. New firmware versions within the scope of this validation must be validated through the [NIST.FIPS.140-3] CMVP. Any other firmware loaded into this module is out of the scope of this validation and requires a separate [NIST.FIPS.140-3] validation.) 35/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

The module is a single-chip implementation that meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. actions required by the operator(s) to ensure that the physical security is maintained: N/A violation (reset) Table 13 Physical Security Inspection Guidelines 36/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

The following table shows temperature and voltage measurement for EFP that is required for modules with physical Security Level 3: Table 14 EFP/EFT The following table shows hardness tested at the lowest and highest temperatures within the module's intended temperature range of operation: Table 15 Hardness Testing Temperature Range

Not Applicable 37/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

38/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

39/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

42/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

with (H-Zs ||H43/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

47/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

48/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

H49/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

50/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

H51/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

52/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

H53/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

54/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

58/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

59/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Table 16 SSPs 60/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

SSPs are securely stored in the Cryptographic Module, a secure element hardware that is considered as secure enclave. The SSPs stored in the module is associated and accessible only via approved services as you can see in this section. The approved services itself are associated and accessible to some specific roles as described in the table section 4.3.1.

The RBG source within this module is from entropy source with tittle “ENT (P)” in the Table Approved Algorithm. Table 17 Non-Deterministic Random Number Generation Specification described below:

1. Generate random number for initial Nonce for key protection by CCMK during FIPS Applet Installation
2. Generate key for CCMK in “CCMK Export 1” service
3. Generate random numbers for Split procedure in “CCMK export” services and “Generate Key (for Split Knowledge)” service
4. Generate key for Customer key in “Generate Key (for Split Knowledge)” service
5. Generate key for Symmetric Key in “Generate Key” Service
6. Generate key for Asymmetric Key (RSA and EC Key pair) in “Generate Key Pair” Service
7. Ephemeral EC Key Generation during Key Agreement in the Mutual Authentication service
8. Utilized in Cipher process of RSA PKCS and PSS
9. Utilized in Signature Generation process using ECDSA
10. Utilized to generate card challenge in GP Initialize Update command
11. Utilized in GP Put Key Command
12. Utilized in the creation of OS-MKEK The approved services that uses DRBG are listed in the section 4.3.2 with link to “DRBG”.

For all SSP, an implicit indicator that the zeroization is completed is provided. This indicator is the successful completion of the requested service for SSP zeroized through a dedicated command (the command is indicated in column “zeroization” of Table 16 SSPs) or Answer-to-RESET (ATR) in case of module reset. For SSP that are automatically zeroized (e.g H-Zs and H-Ze), the implicit indicator is the completion of the command mentioned in Table 16 SSPs with a correct status or an error status. 61/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.1

The module has several self-tests that are triggered at pre-operational (manufacturing stage, power on, or prior to its first use), on demand, conditionally, and periodically. If any self-test fails other than the pairwise consistency, manual entry test, and firmware load test in the conditional self-test, the module will enter in the Kill Card state and emit an error code that identifies the type of test that failed. No further communication with the module is possible until the module is reset (Power-On). If it happens several times and reaches the error limit, the module will be terminated.

This section describes pre-operational self-test executed at startup (power on).

The software/firmware integrity is verified using a 16-bit EDC, referred to as CRC-16 hereafter. Table 18 Integrity Self-Test Target

This critical function self-test is performed in every power on before executing integrity self-test. Table 19 Critical Function Self-test

The module will automatically trigger specific self-test in some conditions. There are several types of conditional self-tests that are employed by the module described in the following section.

The module employs Known Answer Test (KAT) to perform Cryptographic Algorithm Self-test. For performance concern, not all algorithm are executed in the startup (power on) but prior to its first use. 62/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

63/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

64/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

) 65/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Algorith m or Test

Test Properties

Test method

Type

Indicator KillCar d state

Details

Condition s

Coverag e

Coverag e Notes

Period

Periodic Method

Table 20 CM Conditional CAST

The module relies on DAP Verification specified in [GPC_Specification_v2.3] section 9.2.1. The employed DAP Verification for Load Test is using AES-CMAC as approved data authentication technique to verify the validity of the firmware that is loaded. The AES Key with 128 bits key length (DAP-AES) is loaded at manufacturing stage used as authentication key to calculate the MAC of the loaded firmware.

When the module generating RSA and ECC Key Pair via ‘Generate Key Pair’ service, the module performs pairwise consistency test using sign and verify of known value technique. If pairwise consistency test is failed the module returns error code value ‘D6’ indicating error in Generate Key Service with reason pair-wise consistency self-test is failed. On five consecutive errors, the module will enter blocked state. An exit procedure from this state is described in [FQR 401 9097 Ed 4] section 7.3.

The module performs manual entry self-test on some services such as “CCMK Import” services done by each key custodian to enter each secret of CCMK and “CK Import” services done by each customer key custodian enter secrets of customer key. Those operators enter KCV along with its secret. The module performs manual entry self-test by comparing entered KCV and calculated KCV of given secret. If the entered KCV does not match with calculated KCV, the manual entry test is failed with error code ‘D7’. On five consecutive errors, the module enters blocked state. An exit procedure from this state is described in [FQR 401 9097 Ed 4] section 7.3. The module provides a periodic self-test that is executed in every certain number of FIPS Applet service execution. This number is configured on FIPS Applet installation with 2,097,151 as default value. This periodic self-test executes the self-test described in the section 10.1. Data output is inhibited during self-test execution. Only power reset, Hard-fault, procedure NULL (‘60’) byte in ISO7816 interface, and check alive command in SPI can interrupt the process. If it’s interrupted by the Hard-fault, the module enters error state of the hardware and requires power reset to exit from this state.

The module permits operators to initiate the pre-operational self-tests on demand by power cycling the module.

66/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Periodic Self-Test Failure

The module is delivered as single chip to the customer where its life cycle state is in SYSTEM INITIALIAZATION state. The customer shall follow below procedures for secure installation, initialization, startup and operation of the module:

1. The installation procedure of the module that supports two physical interface ISO7816 T0 protocol and SPI Protocol are described as follow: a. Each ISO7816 physical port defined in section 3.1.1 must be installed correctly by connecting each ISO port (VCC, GND, RST, CLK, IO) of the module to the corresponding ISO Reader’s port or terminal’s port. Electrical characteristics in each connected port, signal sequence in activation and deactivation, and transmission protocol shall follow [ISO/IEC 7816-3]. b. Each SPI physical port defined in section 3.1.2 must be installed correctly by connecting each SPI port (VCC, GND, RST, SPI_CLK, SPI_MISO, SPI_MOSI, SPI_CS) of the module to the corresponding SPI Reader’s port or SPI master device’s port. Electrical characteristics in each connected port and its transmission protocol shall follow chip manufacturer datasheet.
2. All module components specified in section 2.1.2 are already installed in the manufacturing. The configuration is set to FIPS Certified Product (FCP).
3. In the SYSTEM INITIALIZATION state: a. Super User shall create new credential and replace its default credential in the module. b. Then, Super User shall create new Administrator role in the module. When this procedure is successfully done, the module state is automatically changed to KEY CEREMONY state.
4. In the KEY CEREMONY state: a. Administrator shall create new roles for Auditor and three Key Custodians role. b. Then, Administrator shall initiate KEY CEREMONY session together with three Key Custodians to import or export CCMK of the module using split knowledge procedure. c. After that Administrator shall confirm either to keep the configuration still in FIPS Certified Product (FCP) or not. Please note that if Administrator is answering no, then the module will loose its FIPS Certified status. Customer cannot revert to FIPS Certified status unless the module is returned at IDEMIA to be erased and personalized with new SSPs. It is recommended for customer to perform System Reset before returning the module to the IDEMIA. When this procedure is successfully done, the module state is automatically changed to System USER (operational) state.
5. When the module is in operational state and configured as FIPS Certified Product (FCP): a. Only approved mode of operation is available for users. In this mode of operation, only approved services in section 4.3.2 is available for users. b. Only applet that is already validated under [NIST.FIPS.140-3] evaluation shall be loaded and installed in the module. Otherwise, the module will loose its FIPS certified status. This is not 67/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

automatically enforced by the module but must be obeyed by following procedure defined in [FQR 401 9097 Ed 4] section 3.4.2.

6. The module does not support maintenance role.
7. The Administrator shall update current date of the module. It is strongly recommended to update the current date of the module on daily basis.
8. Detailed information about module life cycle state and procedures for initialization and operation of the module at customer side, and the procedure to keep the module still in FIPS are described in document [FQR 401 9097 Ed 4] for Crypto Officer Role and [FQR 401 9098 Ed 3] for User Role.

Hardware version can be retrieved with the following steps:

• The current selected application shall be the CARD MANAGER APDU command: 00 A4 04 00 08 A0 00 00 01 51 00 00 00
• GP GET DATA command will return the hardware version under two possible DGI TAG.
• DGI ‘DF50’ APDU command: 80 CA DF 50 1B Hardware version is in the first byte of IC Type information in the returned data
• DGI ‘DF52’ APDU command: 80 CA DF 52 Hardware version is the first byte of the returned data
• The hardware version returned from GET DATA command is act as the hardware identifier and version at the same time OS Firmware information can be retrieved with the following steps:
• The current selected application shall be the CARD MANAGER APDU command: 00 A4 04 00 08 A0 00 00 01 51 00 00 00
• GP GET DATA command will return the OS firmware information under the following information:
• DGI ‘DF66’
• APDU command: 80 CA DF 66 0D
• Returned data is the OS Firmware Information
• OS Firmware Information retrieved by the GET DATA command contains the module identifier and version number. The detail is as follow:
• Complete OS Firmware Information: ‘097153’
• Module Identifier: ‘09715’
• Version number: ‘3’ Application Firmware FIPS Applet version number can be retrieved with the following steps:
• The current selected application shall be the FIPS APPLET APDU command: 00 A4 04 00 08 00 00 00 00 00 A1 12 58
• FRAME HSM GET INFO with tag option ‘FF’ will return the FIPS APPLET version number under tag ‘C0’ 68/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

Sanitization can be done by performing HSM Reset that is authorized by SUPER_USER and HSM Administrator credentials authenticated in Admin Session. HSM Reset service will perform zeroization that is created at customer side and set back module to Factory State like when the customer receives the module for the first time. For secure destruction procedure, it is recommended for customers to follow below step:

1. Under role ‘’AA” (Application Administrator) to set card manager state to TERMINATED.
2. Once, it is terminated, OS-MKEK that is used to encrypt all keys stored in the module is zeroised.
3. Once OS-MKEK is zeroised, all keys stored in the module cannot be retrieved in plaintext form. Event encrypted form, it is difficult to those keys which are stored inside the flash on single chip component which are protected with hard tamper-evident coating on the chip.

The Module implements defenses against:

• Fault attacks: the chip includes several sensors for detecting intrusion or fault attacks. Additionally, the operating system provides checks of expected conditions in areas of code deemed sensitive. If an error is detected by this mechanism, a security function is initiated: the detected attack type is logged in a table; when the number of attacks reaches a pre-set limit, the module initiates card termination, including overwriting of the CSPs, and the module is no longer operable.
• Side-channel attacks (SPA/DPA, timing analysis): the chip implements hardware countermeasures such that timing and current consumption are independent from processed data. The operating system enables the hardware countermeasures and implements independent countermeasures in code, such as constant time execution or randomized intermediate values.
• Card tearing attacks: the operating system implements methods to assure protective measures are completed in the next cycle if the module loses power (i.e., if the power line is cut) before completion of the protective function. APPENDIX 1. REFERENCES A.1 NIST References 69/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

70/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

A.3 Global Platform References A.4 FIPS Applet on RookySE References 71/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

APPENDIX 2. ACRONYMS AND DEFINITIONS 72/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2

73/73 FIPS Applet on RookySE FIPS 140-3 Non-Proprietary Security Revision Date: 30/09/2024 Policy V1.2