IDCore 3230 / 230 Platform

Certificate

Approved Algorithms (27)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for IDCore 3230 / 230 Platform
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>[IDCore 230-BUILD6.11, Demonstration Applet…</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Lifecycle: Modify the card or applet life cycle…<br/>Manage Content: -Load, install, and delete…<br/>Manage Content3</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Module Reset - Power cycle or reset the Module.…<br/>Module Info (Unauth)<br/>Module Reset</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"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input 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"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["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
  C1 --> I1 --> R1 --> E1
  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 C1,C2,C3,C6 clue;
  class I1,I2,I3,I6 infer;
  class R1,R2,R3,R6 risk;
  class E1,E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for IDCore 3230 / 230 Platform
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>[IDCore 230-BUILD6.11, Demonstration Applet…</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Lifecycle: Modify the card or applet life cycle…<br/>Manage Content: -Load, install, and delete…<br/>Manage Content3</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Module Reset - Power cycle or reset the Module.…<br/>Module Info (Unauth)<br/>Module Reset</i><br/>src: securityPolicy.services"]
    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 C1,C2,C3 clueHigh;
  class C6 clueLow;

Security Policy, page by page

IDCore 3230 / 230 Platform FIPS 140-3 Cryptographic Module

IDCore 3230 / 230 Platform Document Information Release Date July 24, 2024 Thales and/or its subsidiaries and are registered in certain countries. All other trademarks and service marks, whether registered or not in specific countries, are the property of their respective owners. Disclaimer All information herein is either public information or is the property of and owned solely by Thales and/or its subsidiaries who shall have and keep the sole right to file patent applications or any other kind of intellectual property protection in connection with such information. Nothing herein shall be construed as implying or granting to you any rights, by license, grant or otherwise, under any intellectual and/or industrial property rights of or concerning any of Thales’s information. This document can be copied or distributed for informational, non-commercial, internal and personal use only provided that:  appear in all copies.  This document shall not be posted on any network computer or broadcast in any media other than on the NIST CMVP validation list and no modification of any part of this document shall be made. Use for any other purpose is expressly prohibited and may result in severe civil and criminal liabilities. The information contained in this document is provided “AS IS” without any warranty of any kind. Unless otherwise expressly agreed in writing, Thales makes no warranty as to the value or accuracy of information contained herein. Thales hereby disclaims all warranties and conditions with regard to the information contained herein, including all implied warranties of merchantability, fitness for a particular purpose, title and non-infringement. In no event shall Thales be liable, whether in contract, tort or otherwise, for any indirect, special or consequential damages or any damages whatsoever including but not limited to damages resulting from loss of use, data, profits, revenues, or customers, arising out of or in connection with the use or performance of information contained in this document. Thales does not and shall not warrant that this product will be resistant to all possible attacks and shall not incur, and disclaims, any liability in this respect. Even if each product is compliant with

IDCore 3230 / 230 Platform current security standards in force on the date of their design, security mechanisms' resistance necessarily evolves according to the state of the art in security and notably under the emergence of new attacks. Under no circumstances, shall Thales be held liable for any third party actions and in particular in case of any successful attack against systems or equipment incorporating Thales products. Thales disclaims any liability with respect to security for direct, indirect, incidental or consequential damages that result from any use of its products. It is further stressed that independent testing and verification by the person using the product is particularly encouraged, especially in any application in which defective, incorrect or insecure functioning could result in damage to persons or property, denial of service or loss of privacy.

IDCore 3230 / 230 Platform ISO/IEC 24759:2017 (Corrected 2017-03, IDT) Information technology –

IDCore 3230 / 230 Platform [SP 800-90B] NIST, SP 800-90B, “Recommendation for the Entropy Sources Used for Table 1

• References

IDCore 3230 / 230 Platform Table 2

• Acronyms and Definitions

IDCore 3230 / 230 Platform Table of Contents 2.1 2.1 2.2 2.3 2.4 3.1 4.1 4.2 4.3 4.3.1 4.3.2 9.1 9.2 10.1

IDCore 3230 / 230 Platform Table of Tables

IDCore 3230 / 230 Platform Table of Figures

IDCore 3230 / 230 Platform This document defines the Security Policy for the Thales IDCore 3230 / 230 Platform cryptographic module, herein denoted the Module. The Module, validated to FIPS 140-3 overall Level 3, is a single-chip “contact” or “contact and contactless” module implementing the Global Platform operational environment, with Card Manager and Demonstration Applet. The Demonstration Applet is available only to demonstrate the complete cryptographic capabilities of the Module for FIPS 140-3 validation and is not intended for general use. The term platform herein is used to describe the chip and operational environment, not inclusive of the Demonstration Applet. The Module has a limited operational environment. The Module includes a firmware load function to support necessary updates. New firmware versions within the scope of this Security Policy and certificate must be validated through the FIPS 140-3 CMVP. Any other firmware loaded onto this module is out of the scope of this validation and requires a separate FIPS 140-3 validation. The FIPS 140-3 security levels for the Module are as follows: [Number Below] N/A N/A N/A Table 3

• Security Levels

IDCore 3230 / 230 Platform Cryptographic Module Specification The IDCore 3230/230 platform cryptographic module is a single chip hardware module. The platform is available in both 'contact' or 'contact and contactless' variants implementing the Global Platform operational environment, with Card Manager and a Demonstration Applet. Figure 1 below depicts the Module’s block diagram, with a red outline highlighting the cryptographic boundary. The cryptographic boundary encompasses all the components included on the single chip. IDCore 3230 IDCore30 platform Javacard Layer layer Platform Javacard Applet Layer Demonstration Applet API JavaCard2.2.2 3.1.0/ JavaCard &Gemalto Thales Proprietary Proprietary Card Manager GP API 2.2.1 2.1.1 IDPrimeMD Applet Runtime Environment JC 3.1.0 2.2.2 Virtual Machine JC 3.1.0 2.2.2 Native / Hardware Abstraction layer Memory Manager Communication (I/O) Crypto Libraries Hardware RAM CLK Clock Clock Mngt Mgmt MMU Sensors Reset Mngt Reset Mgmt IC Layer VCC GND VCC, , GND Power Power Mngt Mgmt RST DES Engine CRC AES Engine Timers EEPROM RSA / ECC Engine ISO 7816 (UART) FLASH ROM HW RNG ISO 14443 (RF) CPU CPU (SLC37) LA, LB (RF) Figure 1

• Cryptographic Boundary

IDCore 3230 / 230 Platform The CM is fully compliant with two major cards industry standards: Oracle Java Card 3.1.0 Classic Edition and GlobalPlatform (GP) Card Specification version 2.2.1. The CM supports [ISO7816] T=0, T=1 and T=CL communication protocols. The CM provides an execution sandbox for Applets, performing the requested services as described in this security policy. Applets access module functionality via internal API entry points that are not exposed to external entities. External devices have access to CM services by sending APDU commands. The CM inhibits all data output via the data output interface while the module is in error state and during self-tests. The JavaCard API (JCAPI) is an internal interface, available to applets. Only applet services are available at the card edge (the interfaces that cross the cryptographic boundary). The Javacard Runtime Environment (JCRE) implements the dispatcher, registry, loader, and logical channel functionalities. The Virtual Machine (VM) implements the byte code interpreter, firewall, exception management and byte code optimizer functionalities. The Card Manager is the card administration entity, allowing authorized users to manage the card content, keys, and life cycle states. The Card Manager behaves similarly to an applet but is properly represented as a constituent of the platform. In case of delegated management (DM), the Supplementary Security Domain (SSD) behaves similarly to the Card Manager in term of card content, keys and life cycle states. The Memory Manager implements functions such as memory access, allocation, deletion and garbage collection. The Communication handler implements the ISO 7816 and ISO 14443 communications protocols in contactless mode and dual mode. The Cryptography Libraries implement the Approved services listed in Section 2.2. The Module is designed to be embedded into a plastic card body, passport, USB key, secure element etc., with a contact plate connection and/or RF antenna. The Module’s single chip is the SLC37GDA512. It can be presented in three different form factors: WORLD RLT module (contact) WORLD Combi RLT module (contact and contactless) PICO RLV module (contact)

2.1 Test Configuration The following tested configurations are covered in this security policy: Table 4

• Cryptographic Module Tested Configuration

IDCore 3230 / 230 Platform 2.1 Tested Operational Environment Physical Perimeter The physical form of the Module is depicted in Figure . The Tested Operational Environment’s Physical Perimeter (TOEPP) is defined as the surfaces and edges of the packages. The Module relies on [ISO 7816] and/or [ISO 14443] card readers as input/output devices. Figure 2 - Models 2.2 CM Identification The CM is always in the approved mode of operation, it does not support a non-approved mode of operation To verify that a CM is in the approved mode of operation, select the Card Manager and send the GET DATA commands shown below:

Table 5

• Tags for Tracking Data (Approved Mode) The CM production life cycle data can be checked using GET DATA command with tag ‘9F7F’. The Module responds with 42 bytes composed of: 1-2 3-4 5-6 7-8

Table 6

• Card Production Life Cycle Data The CM identification data can be checked using GET DATA command with tag ‘0103’. The Module responds with 29 bytes composed of: 7-8 Table 7
• Versions and Operations Indicators The status of the Approved mode of operation can be checked using GET DATA command with tag ‘012F’. The Module responds with 16 bytes composed of:

1 Bytes 5 and 6, as indicated in Table 7 above collective indicate the validated Firmware version number, “IDCore 3230-BUILD6.11”.

The Demonstration Applet version can be checked using GET VERSION command, after having selected the applet: Table 8

• get data command to output Demonstration applet version (Approved Mode)

IDCore 3230 / 230 Platform 2.3 Approved Algorithms The CM implements the following approved services: [SP 80038A] [SP 80038B] [SP 80038A]

IDCore 3230 / 230 Platform [SP 80090Ar1] [SP 80090B]

IDCore 3230 / 230 Platform HMACSHA2-256 [SP 80056Ar3] KAS-ECCSSC [SP 80056Ar3] [SP80056Cr2] [SP80056Cr2]

IDCore 3230 / 230 Platform [SP 80067r2] [SP 800133r2] Table 9: Approved Algorithms NOTE The following algorithms are present in the module and have completed CAVP testing (under CAVP #A2877) but this code is not executed

• ECDSA KeyGen (FIPS 186-4), ECDSA SigGen (FIPS 186-4), ECDSA SigVer (FIPS 186-4), KTS-IFC (KTS-OAEP-basic, rsa std 2048), KTS-IFC (KTS-OAEP-basic, rsa CRT 2048, 3072, 4096), RSA KeyGen (FIPS 186-4), RSA SigGen (FIPS 186-4), RSA SigVer (FIPS 1864), RSA Decryption Primitive (SP 800-56B), SHA1

IDCore 3230 / 230 Platform 2.4 Non-Approved Algorithms The module only implements approved services/algorithms and does not support any nonapproved algorithms. Cryptographic Module Interfaces The Module is designed to be embedded into a plastic card body, passport, USB key, secure element etc., with a contact plate connection and/or RF antenna. 3.1 PIN Assignments and Contact Dimensions The WORLD Combi RLT module has access to contact and contactless interfaces. The WORLD RLT module and the PICO RLV module have only access to a contact interface. The contact interface is the same for all the module variants. Figure 3 - Contact and Contactless Interfaces The Module does not support a Control Output interface. I/O Table 10

• Ports and Interfaces

IDCore 3230 / 230 Platform For contact interface operation, the Module conforms to [ISO 7816] part 1 and part

2. The electrical signals and transmission protocols follow the [ISO 7816] part
3. The operating conditions for the contact interfaces of this module are: Table 11 - Voltage and Frequency Ranges For contactless interface operation, the Module conforms to [ISO 14443] part 1 for physical connections, and to [ISO 14443] parts 2, 3 and 4 for radio frequencies and transmission protocols. The operating conditions for the contactless interfaces of this module are: Table 12 – Contactless voltage and Frequency Ranges Frequency of the internal clock as supplied by the CLK physical interface.

IDCore 3230 / 230 Platform Roles, Services, and Authentication 4.1 Roles The module supports two authenticated roles, the Cryptographic Officer (CO) and the User (USR). The CO is responsible for card issuance and management of card data via the Card Manager Authenticated using the SCP authentication method with SD-SENC. The USR is for FIPS 140-3 validation purposes, authenticated as described in Demonstration Applet Authentication below. The module also supports unauthenticated services, which are implicitly invoked by the Unauthenticated Role (UA). Authentication of each operator and their access to roles and services is as described below, independent of logical channel usage. Only one operator at a time is permitted on a channel. Applet deselection (including Card Manager), card reset, or power down terminates the current authentication; re-authentication is required after any of these events for access to authenticated services. Applet reselection (except Card Manager that close systematically the GlobalPlatform secure channel) is leaving the secure channel unchanged and it is up to the applet policy to close it or not. The module clears previous authentications on each power cycle. It also supports Global Platform SCP logical channels, allowing concurrent operators in a limited fashion. 4.2 Approved Services All approved services implemented by the Module are listed in the tables below. The module does not support any non-approved services.

IDCore 3230 / 230 Platform N/A N/A Table 13 - Roles, Service Commands, Input and Output OPACITY (Open Protocol for Access Control Identification and Ticketing with privacY) is a compact flexible secure and fast authentication protocol with secure messaging capability. This secure messaging is based on symmetric session keys derived using the key establishment protocol. The key establishment protocol authenticates the card application to the client application and establishes two parties. Once session keys are established and the card is authenticated, subsequent communication This is a one way authentication protocol. The reader is not authenticated by the card. This secure channel is based on the card key: DEM-OPACITY-PRI and an ephemeral key generated by the host. The section 4.1 of SP 800-73-4 specification describes the key establishment protocol used to support The strength depends on cipher suite CS2 and CS7:

• Cipher Suite 2 (AES 128, ECDSA with SHA-256 using an ECDSA (Curve P-256) key) provides

• Cipher Suite 7 (AES 256, ECDSA with SHA-384 using an ECDSA (CurveP-384) key) provides

All usage of SSPs by the services implemented by the Module are listed in the table below:

IDCore 3230 / 230 Platform All of the above commands use the SD-SENC and SD-SMAC keys for secure channel communications, and SD-SMAC for firmware load integrity. The card life cycle state determines which modes are available for the secure channel. In the SECURED card life cycle state, all command data must be secured by at least a MAC. As specified in the GP specification, there exist earlier states (before card issuance) in which a MAC might not be necessary to send Issuer Security Domain commands. Note that the LOAD service enforces MAC usage. The provided demonstration applet enforces the restrictions of algorithms, modes, and key sizes per NIST SP 800-131A Revision 1.

IDCore 3230 / 230 Platform 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 = Zeroize: The module zeroizes the SSP. IND_1: The status conditions for successfully completed execution is 90 00 Z:

IDCore 3230 / 230 Platform DAP-SYM, DMTOKEN-SYM, DMRECEIPT-SYM, E:

IDCore 3230 / 230 Platform Z: W: DAP-SYM, DAPASYM; DM-TOKENSYM, DM-TOKENASYM, DMRECEIPT-SYM E: W: E:

IDCore 3230 / 230 Platform HMAC-SHA2256 N/A E: E: N/A N/A N/A N/A N/A N/A Z: N/A N/A N/A

IDCore 3230 / 230 Platform N/A Verify OSGLOBALPIN N/A N/A E: E: OPACITYSCONFIRMATION G: OPACITYSCONFIRMATION OPACITYSCONFIRMATION W: Z:

IDCore 3230 / 230 Platform OPACITYSCONFIRMATION Table 14 –Approved Services

IDCore 3230 / 230 Platform 4.3 Authentication Methods The module provides Identity-based authentication using either the Security Channel Protocol The following table lists the roles supported by the cryptographic module as well as how they are authenticated: N/A N/A Table 15

• Roles and Authentication The Module does not support a maintenance role. 4.3.1 The CO role is authenticated to the module by an Open Platform Secure Channel Protocol authentication method. This method is performed when the EXTERNAL AUTHENTICATE command is invoked after successful execution of the INITIALIZE UPDATE command. The CO is individually and uniquely identified. The SD-KENC and SD-KMAC keys are used along with other information to derive the SD-SENC and SDSMAC keys, respectively. The SD-SENC key is used to create a cryptogram; the external entity participating in the mutual authentication also creates this cryptogram. Each participant compares the received cryptogram to the calculated cryptogram and if this succeeds, the two participants are mutually authenticated). In accordance with SP 800-63B, this Authenticator type is best described as Single-Factor Cryptographic Software (Section 5.1.6). The strength of Global Platform mutual authentication relies on AES key length, and the probability that a random attempt at authentication will succeed is:
•  1     2128  for AES 16-byte-long keys
•  1     2192  for AES 24-byte-long keys
•  1     2 256  for AES 32-byte-long keys

IDCore 3230 / 230 Platform The probability that a single random attempt will succeed with the smallest (16-byte long key) is 1/(2128). Additionally, the module also enforces a maximum count of 15 consecutive failed authentication attempts. After 15 consecutive unsuccessful attempts, the secure channel authentication is permanently blocked. All services that require the secure channel authentication return the status word: SW_SECURITY_STATUS_NOT_SATISFIED. 4.3.2 Demonstration Applet Authentication Method (USR) The USR role is authenticate to the module by verifying a PIN value. This authentication method compares a PIN value sent to the Module over an encrypted channel to the stored OS-GLOBALPIN value; if the two values are equal, the operator is authenticated. In accordance to SP 800-63B, this Authenticator type is best described as Memorized Secrets (Section 5.1.1). The module enforces OS-GLOBALPIN string length of 8 bytes minimum (16 bytes maximum), allowing all characters, so the strength of this authentication method is as follows:

• The probability that a random attempt at authentication will succeed is 1/2568.
• Additionally, the module also enforces a maximum count of 15 consecutive failed authentication attempts of the Global PIN. After 15 consecutive unsuccessful attempts, the Global PIN verification is blocked permanently. All services that require the Global PIN verification will return the status word: SW_AUTHENTICATION_METHOD_BLOCKED.

IDCore 3230 / 230 Platform Software/Firmware Security The CM’s firmware integrity is checked on startup and when periodic self-test period is over. Periodic Self-Tests (PST) are performed and run the firmware integrity tests. The integrity technique is based on EDC (CRC-16), which is approved for a hardware module. The firmware image size covered by the integrity technique is roughly 200 KB. The integrity test can be triggered on demand by setting the specific flag with the proprietary command “autotest management”. Failure of firmware integrity self-tests during Periodic Self-Tests (PST) will trigger a module halt. Recovery from this state will require the module to be restarted and for the detected fault to have cleared. Otherwise, the module will re-halt during POST following restart. The module’s FIPS error log is updated regarding the encountered issue and the card goes into an error state.

IDCore 3230 / 230 Platform Operational Environment The module includes a limited Operating Environment. Only authorized applets can be loaded at post-issuance under control of the Cryptographic Officer. Their execution is controlled by the CM operating system following its security policy rules.

IDCore 3230 / 230 Platform The module is a hardware module claiming level 3 physical security and of embodiment single-chip. The CM meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. The CM uses standard passivation techniques and is protected by passive shielding (metal layer coverings opaque to the circuitry below) and active shielding (a grid of top metal layer wires with tamper response). A tamper event detected by the active shield places the Module permanently into the Card Is Killed error state. The Module is designed to be mounted in a plastic smartcard or similar package; physical inspection of the epoxy side of the Module is not practical after mounting. Table 16 - Physical Security Inspection Guidelines Table 17 - Voltage and Temperature Ranges The module’s hardware is designed to sense and respond to out-of-range temperature conditions as well powered-on state. The module supports an EFP mechanism that will trigger module shutdown if low or high temperature extremes and out-of-range voltage conditions are detected whilst the module is active. In the event that the module senses an out-of-range temperature or over voltage the module will reset itself, clearing all working memory.

IDCore 3230 / 230 Platform The module can be reset and placed back into operation when in-bound operating conditions have been restored . The following table covers the limits enforced by the module:

Table 18 - EFP/EFT The following table lists the temperature tested during the assessment of the module: Table 19 - Hardness testing temperature ranges

IDCore 3230 / 230 Platform Non-invasive security No assured mitigations to ‘other attacks’ are covered in this security policy.

IDCore 3230 / 230 Platform Sensitive security parameter management All SSPs used by the CM are described in this section. All usages of these SSPs by the CM are described in the services. In addition, all keys stored in RAM are zeroized upon power-cycle of the CM. The following table lists Sensitive Security Parameters (SSP) used to perform approved security function supported by the cryptographic module. The following notes should be observed when reading the table:

• Keys with the “SD” prefix pertains to a Global Platform Security Domain key set. The module supports the Issuer Security Domain at minimum, and can be configured to support Supplemental Security Domains The “PRI” suffix indicates that this is a private key The “PUB” suffix indicates that this is a public key The “SYM” suffix indicates that this is a symmetric key The “ASYM” suffix indicates that this is an asymmetric key Keys with the “DEM” prefix are used by the demonstration applet The methods to zeroise SSPs, using the relevant CM services, are described below: -Power-cycling the module: Explicit zeroization method using the Module Reset service, the CM is able to destroy the SSPs by overwriting with zero values (in RAM memory). -Closing SCP secure channel: Explicit zeroization method using the Secure Channel service of the CO, the CM is able to destroy the SSPs of this service, at the closing of SCP secure channel by overwriting with zero values. -Module entering TERMINATED state: Explicit zeroization method using the Manage Content / Lifecycle service of the CO, the CM is able to enter the TERMINATED state, through the Set Status command, destroying the SSPs by overwriting with zero values. -Uninstallation of demonstration applet: Explicit zeroization method using the Manage Content / Delete service of the CO, the CM is able to destroy the SSPs of the demonstration applet, through the Delete command (uninstall method). Indication of success is determined by the status response 90 00. As per FIPS 140-3 IG D.L, the DRBG parameters Entropy Input String (“OS-DRBG-EI”), Seed (“OS-DRBGS”), DRBG Internal State values V and Key (“OS-DRBG-V” and “OS-DRBG-KEY”) are considered CSPs by the module.

IDCore 3230 / 230 Platform N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function Sensitive Security Parameters Summary Strength Key / SSP Name / Type 9.1 N/A N/A

N/A N/A N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform

OSGLOBALPIN N/A N/A AESECB g N/A N/A N/A Use and Related Keys Storage Establishment Import/ Export Generation Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform

AESCBC AESCMAC N/A N/A N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform

AESCBC AESCBC N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform N/A N/A

DM-TOKENSYM / AESCMAC AESCMAC AESCMAC Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform N/A N/A N/A N/A N/A N/A

DMRECEIPTSYM / AESCMAC N/A N/A N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform

OPACITYSENC / OPACITYSMAC / AESCBC N/A N/A N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform

OPACITYSRMAC / OPACITYSCONFIRM AESCMAC N/A N/A Use and Related Keys Zeroisation Storage Import/ Export Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform AESCMAC N/A N/A

DM-TOKENASYM / N/A N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function and Cert Number Strength Key / SSP Name / Type IDCore 3230 / 230 Platform

Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform AESECB AESCBC TDESECB TDESCBC N/A N/A

Use and Related Keys Zeroisation Storage Establishment Import/ Export Generation Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform DEM-COMEDK / AESCMAC N/A AESECB AESCBC N/A N/A N/A

DEM-COMMAC / DEM-SGVPRI / AESCMAC N/A Use and Related Keys Zeroisation Storage Establishment Import/ Export Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform N/A P-384, P521) N/A

DEM-KGSPRI / DEM-KAPPUB / P-384, P521) KASECC KASECC Use and Related Keys Zeroisation Storage Establishment Import/ Export DEM-KAPPRI / Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform N/A N/A N/A

DEM-SGVPUB / P-384, P521) Use and Related Keys Zeroisation Storage Establishment Import/ Export DEM-KGSPUB / Security Function Strength Key / SSP Name / Type IDCore 3230 / 230 Platform N/A N/A Table 20

• SSPs

IDCore 3230 / 230 Platform 9.2 The module includes a non-deterministic Random Number Generator within the cryptographic boundary. This non-deterministic RNG (also called TRNG) is used exclusively to feed the approved DRBG with Table 21

• Non-Deterministic Random Number Generation Specification ESV certificate (#E107) has been procured for this entropy source. As per the Public Use Document for #E107, the settings under the Configuration Settings section are followed to by the factory prior to delivery of the module for operating the entropy source in a compliant manner. The output of the entropy source is used to directly feed the DRBG. The DRBG uses CTR_DRBG from [SP800-90Ar1] with Derivation Function (DF) enabled. 1024-bits of entropy at 13.376 bits per 32-bits min-entropy are fed to the DF which accounts for 428.032 -bits of entropy which exceed the 256-bits required by CTR_DRBG to claim full entropy output of the DRBG. A separate nonce is created for the DRBG based on output from entropy source.

On power-on or reset, the Module performs integrity testing using an EDC (16-bit CRC) performed over all code located in FLASH and EEPROM memory (for OS and Applets). All flags for cryptographic algorithm self-tests are cleared.

The module maintains a flag in RAM memory that stores the state (self-test passed or not) for each Cryptographic algorithm that is approved. This flag indicates if an algorithm has been already self-tested. The Module performs self-test of an algorithm prior the first operational use (corresponding flag is not set) and if the self-test succeeds, the corresponding flag is set otherwise the card logs the self-test error and entered into a Card Is Mute error state or Card is Killed error state, depending on number of failures. On each reset of the CM, it performs only “Firmware Integrity test”. The cryptographic KATs are executed automatically, in a mode named “on demand”, when a cryptographic service is requested. Self-tests can be also played by any operator using the “autotests management” APDU command, corresponding to the “Run Cryptographic KAT” service. The operator can choose the list of self-test execution giving in data of the APDU the self-test flag. Self-Tests are based on known answer tests (KATs):

IDCore 3230 / 230 Platform Table 22 –Conditional Algorithm Self-Tests

When any asymmetric key pair is generated, the CM performs a pairwise consistency test. For RSA keys, the pairwise consistency test is based on keys encryption / decryption. For ECC keys, the pairwise consistency test is based on signature / verify.

When new firmware (applet) is loaded into the CM (or into a SSD having the Delegated Management privilege) using the Manage content service, the CM (or the SSD) verifies the authenticity (MAC or signature) of the new firmware (applet) using respectively the DAP-SYM key or DAP-ASYM key. The signature or MAC in this scenario is generated by an external entity using the key corresponding to the asymmetric key DAP-ASYM or the secret key DAP-SYM.

The module performs a validity check of the public static key and the ephemeral keys according to the SP 800-56Ar3 specification.

The Module supports an internal counter and an associated maximum value. The counter is set to its maximum value on power on and it is decremented when receiving an APDU. When the counter reaches its zero, the integrity test is executed (see 10.1), the counter is reset to its maximum value again and the flag for on-demand tests is also reset so that at next cryptographic algorithm usage, the self-tests are executed again (see 10.2.1). No interruption to the module’s operation is expected while the self-tests are executed.

The CM meets the Level 3 Design Assurance section requirements.

Some additional documents (‘Delivery and Operation’, ‘Reference Manual’, ‘Card Initialization Specification’ documents) define and describe the steps necessary to deliver and operate the CM securely. Once the module has been delivered outside of the factory, the CM is always in the Compliant state. Once the module has been powered on, it always functions in the approved mode of operation. There are no additional steps for installation, initialization, and configuration required for the CM after delivery. The configuration cannot be changed outside the factory.

The Guidance document provided with CM is intended to be the ‘Reference Manual’. This document includes guidance for secure operation of the CM by its users as defined in the Roles, Services, and Authentication chapter.

The Module implementation also enforces the following security rules:

• No additional interface or service is implemented by the Module which would provide access to SSPs. Data output is inhibited during key generation, self-tests, zeroisation, and error states. The zeroisation service is applied with no restrictions on all keys or SSPs of the CM. The Module does not support manual key entry, output plaintext SSPs or output intermediate key values. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the Module.

No assured mitigations to ‘other attacks’ are covered in this security policy. END OF DOCUMENT

Referenced URLs

• http://www.globalplatform.org