DIGIPASS FX Crypto Module

Certificate

Approved Algorithms (34)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for DIGIPASS FX Crypto Module
  %% 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>[Platform ID J3R6000373181200 and ROMID…</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Secure Channel<br/>SEMS Lite Authentication<br/>SEMS Lite Root Key Update</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Lifecycle (Show status and Perform zeroisation)<br/>Info (Show status and Perform self- tests)<br/>Card Reset</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    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?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    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"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    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
  C5 --> I5 --> R5 --> E5
  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,C5,C6 clue;
  class I1,I2,I3,I5,I6 infer;
  class R1,R2,R3,R5,R6 risk;
  class E1,E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for DIGIPASS FX Crypto Module
  %% 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>[Platform ID J3R6000373181200 and ROMID…</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Secure Channel<br/>SEMS Lite Authentication<br/>SEMS Lite Root Key Update</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Lifecycle (Show status and Perform zeroisation)<br/>Info (Show status and Perform self- tests)<br/>Card Reset</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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 C5,C6 clueLow;

Security Policy, page by page

DIGIPASS FX Crypto Module Document Version: 1.0 Date: 24 April 2025 OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Contents List of Figures List of Tables OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

General Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a sensitive but unclassified (SBU) environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140-3 program. The National Voluntary Laboratory Accreditation Program (NVLAP) provides accreditation to independent testing labs performing FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-modulevalidation-program. About this Document This non-proprietary Cryptographic Module Security Policy for the OneSpan NV DIGIPASS FX Crypto Module provides an overview of the product and a high-level description of how it meets the overall Security Level 3 requirements of FIPS 140-3. The DIGIPASS FX Crypto Module may also be referred to as the “Secure Element” or “module” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. OneSpan NV shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

The following table lists the level of validation for each area in FIPS 140-3: [Number Below] N/A Table 1

• Security Levels The module claims an Overall Security Level 3. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Cryptographic Module Specification The Digipass FX Crypto module validated to FIPS 140-3 overall Level 3, is a single chip module implementing the GlobalPlatform operational environment (Card Manager (ISD/SSD)) and the following applications to perform cryptographic calculations: The module is designed for use in smart cards, IoT and automotive applications. Table 2

• Cryptographic Module Tested Configuration OneSpan NV 2025 Public Material
• May be reproduced only in its original entirety (without revision).

The module is validated at an Overall Security Level 3 with Physical Security at Level 4 and all other areas at Level 3. The Operational Environment requirements do not apply to the module given that it meets Physical Security Level 4 requirements. Cryptographic Boundary The module is designed to be used as a part of a larger system. It works as an auxiliary security device attached to a host controller. The physical form of the module is depicted in Figures 1 and 2 (to scale); the outline depicts the cryptographic boundary, representing the surface of the chip and the bond pads. The red outline in Figure 3 also depicts the cryptographic boundary. In production use, the module is delivered to either vendors or end user customers either on film frame carrier (FFC) or various packages such as PDM1.1, NXD6.2, MOB6/10 or HVQFN20 package. The package is outside the cryptographic boundary and thus excluded from the FIPS 140-3/ISO/IEC 19790 security testing. The contactless ports of the module require connection to an antenna. The module relies on [ISO 7816] and [ISO 14443] card readers as input/output devices, or a [NXP I2C] connection to a host controller. No components have been excluded from within the cryptographic boundary. Approved Mode of Operation The module only supports an Approved mode of operation. The NXP SEMS Lite applet can support the NIST P256 curve or the vendor Approved and NIST allowed Brainpool256r1 elliptic curve to perform the ECDSA or KASECC operations. In the Approved mode of operation, the NXP SEMS Lite applet supports the Brainpool256r1 elliptic curve by default. The CO role may use SEMS Lite Module Management service to load NIST P-256 curve parameters. The P71D600 GlobalPlatform operational environment component can be identified by using the IDENTIFY APDU command (Info service). This command returns the card identification data, which includes a Platform ID, a Patch ID and other information that allows the identification of the content in ROM, NVM and loaded patches. The Platform ID is a data string that allows the identification of the P71D600 Card Manager component. The IDENTIFY APDU command is formatted as follows: CLA INS P1 P2 Lc Data Le Code ‘80’ ‘CA’ ‘00’ ‘FE’ ‘02’ ‘DF28’ ‘00’ Value Parameter settings GlobalPlatform GET DATA (IDENTIFY) - ISD High order tag value Low order tag value - proprietary data Length of data field Module identification data Length of response data OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

The command answers the content of the DF28 file: • • • Tag 02 identifies the Patch ID (see Table

2. Tag 03 identifies the Platform Build ID which is made up of the Platform ID (16 Bytes, see Table 2) and the platform build fingerprint (8 Bytes) Tag 08 identified the ROM ID (see Table
3. To verify that the GlobalPlatform operational environment runs in the Approved mode of operation, use the IDENTIFY APDU (as described above). The DF28 file tag ‘05’ contains the status of the Approved mode compliancy, where ‘00’ identifies Approved mode not active and ‘01’ - Approved mode active. Both NXP IoT applet and NXP SEMS Lite applet of the module are configured to always run in an Approved mode of operation. The personalized product shall have: • NXP IoT applet v7.2.22 identification: o Package ID: A00000039654530000000103000200H o Applet ID: A0000003965453000000010300000000H o Instance ID: A0000003965453000000010300000000H • NXP SEMS Lite applet v2.0.2.11 identification: o Package ID: A00000039654530000000103300000H o Applet ID: A0000003965453000000010330000000H o Instance ID: A0000003965453000000010330000000H The operator can verify that NXP IoT applet v7.2.22 is in an Approved mode of operation by sending the two (2) following commands to the module:
4. The SELECT APDU command (Context service) will be called with the following parameters: CLA = 00, INS = A4, P1 = 04, P2 = 00, Lc = 10, Incoming Data = A0000003965453000000010300000000, and Le =
5. The module shall answer 07021626F2FFFF followed by status code 9000. The response includes the BCD encoded applet version (070216) and the supported applet feature bitmap (26F2). This encoded applet version (070216) corresponds to the decimal version v7.2.22 of the IoT Applet as specified in Table 2 in this document and the module certificate. It is not possible in any way to modify the applet version or the supported features bitmap after the device leaves the factory.
6. The GetVersion APDU command (IoT Applet Management service) shall be called to get the extended feature bitmap. This command is 80040021 and shall return 26F20000011D81C1E101000E0000000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F to be in Approved mode of operation. OneSpan NV 2025 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

The operator can verify that NXP SEMS Lite applet v2.0.2.11 is an Approved mode of operation by sending the three (3) following commands to the module:

1. The SELECT APDU command (SEMS Lite General service) shall be called with the following parameters: CLA = 00, INS = A4, P1 = 04, P2 = 00, Lc = 10, Incoming Data = A0000003965453000000010330000000, and Le =
2. Return code shall be 90 00 (OK)
3. The GET DATA APDU command (SEMS Lite General service) shall be called with the following parameters: CLA = 80, INS = CA, P1 = 00, P2 = DE, and Le =
4. The command shall return DE04020002119000 with 02000211 indicating the NXP SEMS Lite applet version. This encoded applet version (02000211) corresponds to the decimal version v2.0.2.11 of the IoT Applet as specified in Table

3. The GET DATA APDU command (SEMS Lite General service) shall be called with the following parameters: CLA = 80, INS = CA, P1 = 00, P2 = C6, and Le =
4. The command shall return C601019000 with C60101 indicating the NXP SEMS Lite applet is configured in Approved mode of operation. The module does not support a degraded operation. In addition to the configurations tested by the laboratory, vendor-affirmed testing was performed on the following platforms: • • SE052 NCJ37 Note: The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys if the specific operational environment is not listed on the validation certificate. Cryptographic Algorithms The module implements the following Approved cryptographic algorithms. OneSpan NV 2025 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Sp80056Ar3/A2713 Sp80056Cr1/A2714 Sp80056Ar3/A2713 Sp80056Cr1/A2715 (2) Sp80056Ar3/A2713 Sp80056Cr1/A2713 OneSpan NV 2025 Public Material

• May be reproduced only in its original entirety (without revision).

AESCBC/A2713 AESCMAC/A2713 AESKW/#A2714 Table 3

• Approved Algorithms Table 4
• Non-Approved Algorithms Allowed in Approved Mode of Operation The following non-Approved but allowed EC curves (per IG C.A) are implemented by the module for use in ECDSA and KAS-ECC: Singular Field Co-Factor [RFC5639] No IFp Singular Field Co-Factor [RFC5639] No IFp Brainpool320r1 [RFC5639] No IFp OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Brainpool384r1 [RFC5639] No IFp Brainpool512r1 [RFC5639] No IFp Secp224k1 [SEC2] No IFp Secp256k1 [SEC2] No IFp The module does not support Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed and Non-Approved Algorithms Not Allowed in the Approved Mode of Operation. Figure 1

• P71D600 OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Figure 2

• P71D600 Physical Form (Schematic) Figure 3 below depicts the module operational environment. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Card Manager (ISD/SSD) NXP SEMS Lite Applet NXP IoT Applet Firmware Platform Global Platform API JavaCard API JCOP OS Hardware Power Mgmt VDD, VSS GND Timers EEPROM Flash Reset Mgmt AES Engine NXP T1I2C (I2C) SDA/SCL (I2C) RSA/ECC Engine ISO 7816 (UART) I/O (Contact) HW RNG ISO 14443 (RF) LA/LB (RF) CPU Sensors RST CRC DES Engine MMU Clock Mgmt CLK RAM ROM Figure 3

• Module Block Diagram The JavaCard and Global Platform APIs are internal interfaces available to applets. Only NXP applets and Card Manager (ISD/SSD) services are available at the card edge (the interfaces that cross the cryptographic boundary). The product is delivered with:
• NXP IoT applet installed and configured before product’s delivery to customer. The end-user can personalize the module with its objects but cannot modify the configuration of the module, the Module always operates in an Approved mode of operation.
• NXP SEMS Lite Applet installed and configured before product’s delivery to customer. The enduser cannot modify the configuration of the module, the module always operates in an Approved mode of operation. Thus, the end-user cannot bring unauthorized changes to the Approved configuration of the module. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Overall Security Design and Rules of Operation PBKDF Operation details

• Password strength The password is stored in an APP-HMAC-KEY object as input to the PBKDF2 function. This key requires a minimum of

112 bits. The probability that a random attempt will end up with the same output is:

• 1/(2^112) = 1.9E‐34 (using a minimum size for the password) Iteration Count and Justification Iteration count should be at least 1000, following the recommendation in SP800-132r2. If an application desires less iterations, the iteration count can be lower than 1000, but in any case, the iteration count shall be 2 or more.
• Storage Only Statement Output of PBKDF Operation service shall be used in storage applications. AES GCM IV The module enforces the use of an Approved DRBG in accordance with IG C.H scenario 2; the internal Approved CTR_DRBG, which has a security strength of 128 bits, is used to generate the 96-bit IV. TLS 1.2 Support The module supports the TLS KDF Functions service. This service provides support for TLS v1.2 calculations. It does not implement the TLS v1.2 protocol. Per FIPS 140-3 IG D.C, no parts of this protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

Table 5

• Ports and Interfaces The module does not support control output. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

The module supports the following roles:

• Cryptographic Officer (CO): Manages module content and configuration, including management of module data via the SSD. Authenticated as described in Table 7 below.
• User (the device Holder (applet user)): Performs Approved cryptographic operations. Authenticated as described in Table 7 below. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

OneSpan NV 2025 Public Material

• May be reproduced only in its original entirety (without revision).

OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

N/A Perform selftests) OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Authentication of each operator and their access to roles and services is as described below, independent of logical channel usage (identity-based authentication methods implemented).

• Only one operator at a time is permitted on a channel. Applet de-selection (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. CO authentication method does not exchange plaintext CSP. User authentication data is encrypted and authenticated during entry with GlobalPlatform SCP03, is stored encrypted with OS-MKEK and is only accessible by authenticated services. This includes user identifier (UserID) in case of UserID session method. Table 7
• Roles and Authentication Platform Authentication (Secure Channel Protocol 03 Authentication Method) The Secure Channel Protocol authentication method is provided by the Secure Channel service. The SD-KENC and SDKMAC keys are used to derive the SD-SENC, SD-SMAC, and SD-RMAC session keys. These sessions keys are used with AES-CBC and AES-CMAC to provide an end-to-end confidential and authenticated protected channel (Approved KTS) between the external entity (User) and the module. The external entity participating in the mutual authentication sends a 64-bit challenge to the Secure Element. The Secure Element generates its own challenge and computes a 64-bit cryptogram with SD-SMAC key and both challenges. The Secure Element cryptogram and challenge are sent to the external entity which checks the Secure Element 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 external entity cryptogram with AES-CMAC and SDSMAC key. The MAC is concatenated to the command, and the command is sent to the Secure Element. The Secure Element 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). The probability that a random attempt will succeed using this authentication method is:
• 1/(2^128) = 2.9E‐39 (MAC||cryptogram) using a 128‐bit block for authentication. This authentication method includes a counter of failed authentication called “velocity checking” by GlobalPlatform. The counter is decremented prior to any attempt to authenticate and is only reset to its threshold (maximum value) upon successful authentication. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

The module enforces a maximum of 60 failed Global Platform SCP03 authentication attempts before permanently blocking the card. The probability that a random attempt will succeed over a one-minute interval is (with the assumption here that one attempt is possible per second):

• 60/(2^128) = 1.7E-37 (MAC||cryptogram), using a 128‐bit block for authentication IoT applet Authentication The applet allows creating an authenticated session using an Authentication Object which can be either UserID session, AESKey session, or ECKey session. An authenticated session allows users to protect and safeguard their credentials against third party use as only the authenticated user has proper rights on the credentials. This is ensured by applying correct policies to the credentials. A policy binds functional access to an Authentication Object where an Authentication Object represents a user. The different authentication methods are described in the sub-sections below. UserID Session An UserID session authentication method is provided by the Session management service. During a UserID session, the session user identifier (UserID) is verified in order to allow setting up a session. If the UserID is correct, the session establishment will succeed; otherwise, the session will not be opened. An UserID can be configured from a minimum of four (4) bytes up to a maximum of 16 bytes (128 bits). In the worstcase scenario, a 4-byte UserID is used, the probability that a random attempt will succeed using this authentication method is:
• 1/(2^32) = 4.3E-9 The number of authentication attempts is configurable. It can be an infinite attempt number, or it can be limited by a counter comprised between 1 and 255 attempts. A maximum of 4700 authentications can be performed in one minute. In the worst-case scenario, the probability that a random attempt will succeed over a one-minute period is:
• 4700/(2^32) = 1.0E-6. AESKey Session The AESKey session authentication method is provided by the Session management service. The APP-AES-KEY-AUTH key is used to derive the APP-SENC, APP-SMAC keys, and APP-RMAC. These sessions keys are used with AES-CBC and AES-CMAC to provide an end-to-end confidential and authenticated protected channel (Approved KTS) between the external entity (User) and the module. The external entity participating in the mutual authentication sends a 64-bit challenge to the Secure Element. The Secure Element generates its own challenge and computes a 64-bit cryptogram with APP-SMAC key and both OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

challenges. The Secure Element cryptogram and challenge are sent to the external entity which checks the Secure Element 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 external entity cryptogram with AES-CMAC and APPSMAC key. The MAC is concatenated to the command, and the command is sent to the Secure Element. The Secure Element 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 CO/User role). The probability that a random attempt will succeed using this authentication method is:

• 1/(2^128) = 2.9E‐39 (MAC||cryptogram, using a 128‐bit block for authentication) The number of authentication attempts is configurable. It can be an infinite attempt numbers or it can be limited by a counter comprised between 1 and 32767. A maximum of 4700 authentications can be performed in one minute. In the worst-case scenario, the probability that a random attempt will succeed over a one-minute period is:
• 4700/(2^128) = 1.3E-35 (MAC||cryptogram, using a 128‐bit block for authentication). ECKey Session An ECKey session authentication method is provided by the Session management service. The ECKey session authentication method consists of verifying a P-256 ECDSA signature. The P-256 EC public key is either initially imported by the User (APP-EC-PUBLIC-KEY-USER) or provisioned during the manufacturing (APP-ECPUBLIC-KEY-CO). The user will own the corresponding ECDSA private key. In addition to User’s authentication, ECKey session is used to establish APP-KAS-IOT-SS/APP-KAS-SEMS-SS with the Approved KAS algorithm. The shared secret is used to derive the AES-128 APP-AES-KEY-AUTH which is itself used to derive the APP-SENC, APP-SMAC and APP-RMAC session keys. These sessions keys are used with AES-CBC and AES-CMAC to provide an end-to-end confidential and authenticated protected channel (Approved KTS) between the external entity (User) and the module. First, the user requests the module public key, APP-KAS-SSC-EC-PUB-KEY; this key is signed with the private key APPKAS-SSC-EC-PRIV-KEY by the module. Then, the User sends the ephemeral KAS public key signed with User’s ECDSA private key. Finally, the module verifies the ECDSA signature of the ephemeral key with either APP-EC-PUBLIC-KEYUSER or APP-EC-PUBLIC-KEY-CO before initiating the KAS shared secret computation. The probability that a random attempt will succeed using this authentication method is:
• 1/(2^128) = 2.9E‐39 (using a 256‐bit EC key for authentication) The number of authentication attempts is configurable. It can be an infinite attempt numbers or it can be limited by a counter comprised between 1 and 32767. A maximum of 4700 authentications can be performed in one minute. In the worst-case scenario, the probability that a random attempt will succeed over a one-minute period is:
• 4700/(2^128) = 1.4E-35 (using a 256-bit EC key for authentication) OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

SEMS Lite Applet Authentication The SEMS Lite applet is provided by the SEMS Lite Authentication service. The service provides authentication, confidentiality, and integrity of each authenticated service. The SEMS Lite Applet authentication consists of verifying a Brainpool256r1 ECDSA signature computed on a 113-byte data generated off the module and the CO public key APP-ECC-RT-PUB-AUT, see section 5.1.4 of [GP] Amendment-I. The probability that a random attempt will succeed using this authentication method is:

• 1/(2^128) = 2.9E‐39 (using a 256‐bit EC key for authentication) To keep the SEMS Lite Applet from blocking, an infinite number of attempts is allowed. A maximum of 4700 authentications can be performed in one minute. In the worst-case scenario, the probability that a random attempt will succeed over a one-minute period is:
• 4700/(2^128) = 1.4E-35 (using a 256-bit EC key for authentication) The module does not support bypass or self-initiated cryptographic output capabilities. The module is a limited operational environment under the FIPS 140-3 definitions. The module includes a firmware load function to support necessary updates, but these are only limited to the vendor, OneSpan NV. New firmware versions within the scope of this validation must be validated through the CMVP. Any other firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140-3 validation. OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto KDF SP800108 OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E, G, W

FIPS 140-3 Security Policy - DIGIPASS FX Crypto KDF SP800108 OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E E, G, Z

FIPS 140-3 Security Policy - DIGIPASS FX Crypto KDF SP800108 APP-TRANSPORTCIPHER OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E, G, R, W, Z

FIPS 140-3 Security Policy - DIGIPASS FX Crypto N/A APP-TRANSPORTCIPHER OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E, R E, Z

FIPS 140-3 Security Policy - DIGIPASS FX Crypto E E, G, Z E, G, Z OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E

FIPS 140-3 Security Policy - DIGIPASS FX Crypto E E E OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E

FIPS 140-3 Security Policy - DIGIPASS FX Crypto E E E, G, W, Z n OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E

FIPS 140-3 Security Policy - DIGIPASS FX Crypto OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision). E, G, W, Z E, G, W, Z

FIPS 140-3 Security Policy - DIGIPASS FX Crypto N/A N/A Unauthorised N/A N/A Unauthorised N/A N/A N/A Unauthorised N/A N/A N/A Unauthorised N/A N/A Table 8

• Approved Services The modes of access shown in the table above are defined as:
• G = Generate: The service generates or derives the CSP/Public Key.
• W = Write: The service inputs the CSP/Public Key.
• E = Execute: The Module executes using the CSP/Public Key.
• Z = Zeroize: The Module zeroizes the CSP/Public Key after usage. A zeroised CSP is not retrievable or reusable. OneSpan NV 2025 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Software/Firmware Security The cryptographic module is considered a hardware module with firmware components. An error detection code (32-bit CRC performed over all code located in Flash) is applied to all firmware components within the module. If the integrity test fails, the module enters the hard error (MUTE) state. An operator of the module can perform the integrity test on demand with the GET DATA APDU command. As a single-chip hardware module, the executable form of the code, i.e., firmware is binary format. The module does not support loading of firmware from an external source. ROM endurance has been proven to be more than 10 years after manufactured date. Therefore, per FIPS 140-3 IG 5.A, no pre-operational ROM integrity self-test has been implemented. The module’s endof-life procedures must be applied prior to the degradation of the ROM by setting the module to the TERMINATE state. All data and control inputs, and data and status outputs of the cryptographic module and services are directed through the module’s defined interfaces. OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Operational Environment The module claims to meet Physical Security Level 4 and thus the requirements per this section do not apply. OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto The module is a single-chip implementation that meets commercial-grade specifications for power, temperature, reliability, and shock/vibrations. The module uses standard passivation techniques. The module includes Environmental Failure Protection features such as temperature and voltage sensors. Fault Induction mitigation techniques are light sensors and spike sensors on the supply voltage lines. Identification of internal features such as sensitive components or interconnections is impeded by a fine mesh of metal shield lines that resides at the outermost layers of the chip. Delivery forms of the module are QFN package, contactless chip card module, or sawn wafer. Therefore, the module does not rely on any physical security based on a package. N/A Table 10

• EFP/EFT N/A N/A Table 11
• Hardness Testing Temperature Ranges OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Non-Invasive Security Please see Section 12 below for information regarding non-invasive security countermeasures. OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Sensitive Security Parameter Management Generation Establishment N/A N/A via SP80090Ar1 N/A N/A via SP80090Ar1 N/A N/A OS-DRBGSTATE OS- DRBGKEY

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Establishment via SP80090Ar1 N/A N/A via SP80090Ar1 N/A N/A N/A manufacturing/ personalization N/A N/A N/A OS-DRBGOUTPUT OneSpan NV 2023 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Generation Establishment N/A personalization (using SDKDEK) N/A N/A N/A ring/personalization (using SDKDEK) OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto KDF SP800108 Generation Establishment N/A N/A KDF SP800108 N/A N/A OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto APPTRANSPORTCIPHER KDF SP800108 KDF SP800108 Generation Establishment N/A N/A KDF SP800108 N/A N/A KDF SP800108 N/A N/A N/A OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto APPTRANSPORTMAC Generation Establishment N/A N/A N/A APP-KASSSC-EC-PRIVKEY N/A N/A N/A N/A N/A SP80056Arev3 OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto KDF SP800108 Generation Establishment N/A N/A N/A KDF SP800108 OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto KDF SP800108 KDF SP800108 Generation Establishment N/A N/A KDF SP800108 N/A N/A KDF SP800108 OneSpan NV 2023 Version 1.0 Zeroisation Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto APP-USERIDFILE Establishment N/A N/A N/A P-224, P256, B.4.2 ; N/A N/A OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Establishment B.4.2 ; N/A N/A N/A OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto APP-HMACKEY Generation N/A N/A by GPAmd-I N/A N/A N/A N/A SP80056Arev3 KAS OneSpan NV 2023 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Generation Establishment Zeroisation N/A N/A Rev3 KASSCC N/A by GPAmd-I N/A N/A N/A N/A

• N/A OneSpan NV 2023 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto APP-KASSSC-EC-PUBKEY Generation Establishment N/A N/A N/A N/A N/A N/A OneSpan NV 2023 Zeroisation N/A

• N/A
• N/A
• Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Establishment B.4.2 ; N/A N/A OneSpan NV 2023 Zeroisation N/A

• Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto B.4.2 ; N/A N/A N/A N/A N/A OneSpan NV 2023 Zeroisation N/A

• N/A
• Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Generation Establishment N/A N/A N/A N/A N/A APP-CERTAUT N/A N/A N/A N/A N/A N/A Zeroisation N/A

• N/A
• N/A
• N/A
• Table 12
• SSPs OneSpan NV 2023 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto The module implements a NIST SP800-90Ar1 Approved CTR_DRBG. The unmodified outputs of the DRBG are used for Cryptographic Key Generation (CKG) of Symmetric Keys and seeds for Asymmetric Key Generation as noted in Table 3 in this document per Section 4 in NIST SP800-133r2. Table 13

• Non-Deterministic Number Generator Specification Per FIPS 140-3 IG 9.5.A, the module supports AD/EE (Automated Distribution/Electronic Entry). OneSpan NV 2023 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Self-Tests On power-on or on demand, the module performs self-tests described below. The pre-operational self-test must be completed successfully prior to any other use of cryptography by the module. The Cryptographic Algorithm Self-Tests are either performed at boot or prior to first use. The conditional self-tests are performed when the corresponding conditions occur. If one of the self-tests fails, the system is halted and will start again after a reset. ROM endurance has been proven to be more than 10 years after manufactured date. Therefore, no pre-operational ROM integrity self-test has been implemented. The module’s end-of-life procedures must be applied prior to the degradation of the ROM by setting the module to the TERMINATE state, The Flash Firmware Integrity check is performed on every reset or on demand. Pre-operational Self-Tests

• Firmware Integrity: 32-bit CRC performed over all code located in Flash. Conditional Self-Tests
• Cryptographic Algorithm Self-Tests
• AES CBC 128-bit Encrypt KAT
• AES CBC 128-bit Decrypt KAT
• AES CMAC 128-bit Encrypt KAT
• AES CMAC 128-bit Decrypt KAT
• CTR_DRBG 256-bit KAT (Health Tests: Generate, Reseed, Instantiate functions per Section 11 in NIST SP800-90Ar1)
• ECDSA P-521 SHA-256 Signature Generation KAT
• ECDSA P-521 SHA-256 Signature Verification KAT
• HMAC-SHA2-256 KAT
• KAS-ECC-SSC P-256 KAT
• KDF TLS 1.2 KAT
• KDA KAT (One-Step KDF per SP800-56Cr1 for both Cert. #A2714 and #A2715)
• KDA KAT (Two-Step KDF KAT (HKDF) per SP800-56Cr1 for Cert.#A2713)
• NIST KDF SP800-108 KAT (Counter mode with AES-128)
• NIST KDF SP800-108 KAT (Feedback Mode with HMAC-SHA1)
• NIST SP800-132 KDF KAT (with HMAC-SHA-1)
• RSA 2048-bit SHA2-256 Signature Generation KAT
• RSA 2048-bit SHA2-256 Signature Verification KAT
• SHA-1 KAT (for both Cert. #A2713 and #A2714)
• SHA2-256 KAT (for both Cert. #A2713 and #A2714 (inclusive of SHA2-224, per IG 10.3.A))
• SHA2-512 KAT (for both Cert. #A2713 and #A2714 (inclusive of SHA2-384, per IG 10.3.A)) OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto NIST SP800-90B ENT (P) Repetition Count Test (RCT) performed on raw data NIST SP800-90B ENT (P) Developer Defined Heath Test Transition Count Test performed on the raw data

• NIST SP800-90B ENT (P) Developer Defined Heath Test Chi‐Square Test performed on the conditioned data
• NIST SP800-90B ENT (P) Developer Defined Heath Test Amplitude Limiter Analog Test on the analog data Pairwise Consistency Tests
• Generate PCT: Pairwise consistency test performed when an asymmetric key pair is generated for RSA or ECC. The conditional test is implemented at the applet level
• Signature PCT: Pairwise consistency test performed when a signature is generated for RSA or ECDSA Firmware Load Test: Signature Verification based on ECDSA P-256 with SHA2-256 o o
• Note: The module does not support loading of external firmware by the operator (it is limited to the vendor, OneSpan NV, at factory pre-shipment of the module). The Firmware Load Test above is performed by the module in support of the same. All the Self-Tests can be performed on-demand with the GET DATA APDU command (Info service) with the following parameters: CLA = 80, INS = CA, P1 = 00, P2 = FE, Lc = 04, Incoming Data = DF4B0120, and Le = 00. The expected result is FE04DF4B0120. In case of a failure, the module enters a hard error (MUTE) state and returns a code/status indicator. The APDU code 9000 signifies success and 66A7 is the error indicator corresponding to the MUTE error state. The JCOP OS is intended to execute pre-operational self-tests (rather than conditional self- tests) periodically, since these tests are pre-defined to be executed post resets. The periodic time will thus always start from zero. RAM can be used to manage the periodic time interval which is the number of execution events e.g., number of APDUs/commands received (the tests are repeated after every 500,000 CAPDUs/commands). OneSpan NV 2025 Version 1.0 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Life-Cycle Assurance All configuration management items are managed using an automated configuration management system. The module is designed to allow the testing of all provided security-related services. All firmware is implemented using a high-level language and is designed in a manner that avoids the use of code, parameters, or symbols not necessary for the module’s functionality and execution. While the module can be delivered with the Approved mode enabled by default, customers also have the option to receive a module which is in the unconfigured state, i.e., non-Approved mode. To comply with and maintain the FIPS 140-3 validation, it would be the CO’s responsibility to enable the Approved mode of operation as follows (this information can also be found in the JCOP 4.5 User guidance and administrator manual document):

1. Install SEMS Lite applet to run in Approved mode of operation.
2. Install the IoT applet and configure the applet to run in Approved mode of operation.
3. Configure the Operation System to run in Approved mode of operation. In each of these steps, it is in the CO’s responsibility to apply proper security conditions and to ensure that once the device is put into Approved mode of operation, it will not be set into non-Approved mode of operation ever again. The operator can verify that the module is operating in the Approved mode by following instructions specified in Section 2 in this document. There are no specific maintenance requirements for this module. OneSpan NV 2025 Version 1.0 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto Mitigation of Other Attacks The module is protected against the following non-invasive attacks: SPA, DPA, Timing Analysis and Fault Induction using a combination of firmware and hardware countermeasures. Protection features include detection of out-ofrange supply voltages, frequencies or temperatures, fault induction mitigations like light sensors, voltage glitch sensors and an active shield, and detection of illegal address or instruction. All cryptographic computations and sensitive operations such as critical data comparison provided by the module are designed to be resistant to timing and power analysis. Sensitive operations are performed in constant time, regardless of the execution context (parameters, keys, etc.), owing to a combination of hardware and firmware features. In addition to the non-invasive attacks, the module also uses standard passivation techniques and is protected by active shielding (a grid of top metal layer wires with tamper response) which qualifies for classification under mitigation of other attacks. OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - DIGIPASS FX Crypto END OF DOCUMENT OneSpan NV 2025 Version 1.0 Public Material

• May be reproduced only in its original entirety (without revision).

Referenced URLs

• https://csrc.nist.gov/projects/cryptographic-module-