ID-One PIV 243 in NPIVP & CIV Configurations

Certificate

Approved Algorithms (24)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for ID-One PIV 243 in NPIVP & CIV Configurations
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Manage SD Keys and PIV Global Reference Data<br/>Manage SD Data<br/>Personaliz e PIV Data (Cleartext )</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>NPIVP (612431XX00)<br/>CIV+ FIPS (612432XX10)<br/>AES-ECB</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</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["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"]
    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"]
    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
  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 C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for ID-One PIV 243 in NPIVP & CIV Configurations
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Manage SD Keys and PIV Global Reference Data<br/>Manage SD Data<br/>Personaliz e PIV Data (Cleartext )</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>NPIVP (612431XX00)<br/>CIV+ FIPS (612432XX10)<br/>AES-ECB</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</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 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

IDEMIA ID-One PIV 243 in NPIVP & CIV Configurations Document Version 1.3 Last update: 2025-05-14 Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Table of Contents © 2025 IDEMIA / atsec information security.

ID-One PIV 243 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 List of Tables List of Figures © 2025 IDEMIA / atsec information security.

This document defines the Security Policy for the ID-One PIV 243 cryptographic module from IDEMIA when configured by IDEMIA in FIPS 140-3 Level 2 mode of operation, and hereafter denoted the module. The module, validated to FIPS 140-3 overall Security Level 2, is a single chip module implementing the Global Platform operational environment, with Card Manager and ID-One PIV 243 Applet.

The FIPS 140-3 security levels for the module are as follows: N/A N/A Table 1: Security Levels © 2025 IDEMIA / atsec information security.

Purpose and Use: The ID-One PIV 243 in NPIVP & CIV Configurations module implements cryptographic services for the Global Platform operational environment, with Card Manager and ID-One PIV Applet. Module Type: Hardware Module Embodiment: SingleChip Cryptographic Boundary: The module is designed to be embedded into a plastic card body, with a contact plate and/or contactless antenna connections, or in a USB token or other standard IC packaging, such as SOIC, QFN or MicroSD. The physical form of the module is depicted in Figure 1 below. The cryptographic boundary of the module is the surface and edges of the die and associated bond pads for the module's interfaces, shown as circles in the figure. See Table 12: Ports and Interfaces for the function of each interface. Figure 1: Depiction of Physical Form © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Figure 2: Block Diagram Section 4 describes applet functionality in greater detail. The JavaCard and Global Platform APIs are internal interfaces available only to applets. Only applet services are available at the card edge (the interfaces that cross the cryptographic boundary). In the figure above, the Security Domain Verifier prevents loading an unauthorized (unsigned) code package into the module and does not provide separate services. The POST application provides on-demand execution of the conditional Cryptographic Algorithms Self-Test (CAST) and the MSFT PNP application provides identification of the associated minidriver when the module is used within a Microsoft Windows Environment. All code is executed from ROM and NVM. The chip family provides accelerators for AES, RSA, ECC, CRC and an SP800-90B ESV. The communications options for contact and contactless configurations are present in the physical circuitry of all members of the processor family but are selectively enabled during module manufacturing. © 2025 IDEMIA / atsec information security.

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware Figure 3: Bottom View Figure 4: Top View

There are no components within the cryptographic boundary excluded from the FIPS 140-3 requirements.

Modes List and Description: © 2025 IDEMIA / atsec information security.

Table 3: Modes List and Description The mode of operation is defined by IDEMIA during manufacturing and cannot be changed. The module does not allow the changing of modes after manufacturing.

Approved Algorithms: The module only implements approved algorithms and does not implement any non-approved algorithms. Therefore, the module only has approved mode of operation. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Table 4: Approved Algorithms Vendor-Affirmed Algorithms: Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Non-Approved, Allowed Algorithms with No Security Claimed: Table 6: Non-Approved, Allowed Algorithms with No Security Claimed Non-Approved, Not Allowed Algorithms: N/A for this module.

s (FIPS1864): (A4945) (FIPS1864): (A4945) © 2025 IDEMIA / atsec information security.

ID-One PIV 243 s DigSigSigGen (FIPS1864): (A4945) DigSigSigGen (FIPS1864): (A4945) DigSigSigVer (FIPS1864): (A4945) h f Sp80056Ar3: CDHComponent (FIPS1864): (A4945) © 2025 IDEMIA / atsec information security.

ID-One PIV 243 s DigSigSigGen (FIPS1864): (A4945) DigSigSigGen DigSigSigVer (FIPS1864): (A4945) Sp80056Br2: HMACSHA2-256: HMACSHA2-512: KDF SP800108: © 2025 IDEMIA / atsec information security.

ID-One PIV 243 g g s Table 7: Security Function Implementations

Compliance to SP 800-56ARev3 assurances For KAS-ECC, the module satisfies IG D.F Scenario 2 path (2) (i.e., tested compliance with One Pass DH key agreement schemes followed by the derivation of the key as shown in Section 5.8 of SP 800-56Arev3). The key derivation function complies to SP 800-56C rev2 (i.e., One-Step KDF). Furthermore, the module obtained the appropriate assurances, as required in Sections 5.6.2 of SP 800-56A rev3.

5.6.2.1.1 Owner Assurance of Correct Generation: The module performs key generation for

ephemeral keys. Using the key generation algorithm validated by the CAVP (ECDSA KeyGen Cert. #A4945). For static keys, a trusted third party (TTP) generates the key pair and securely enters the module using SP800-38F key wrapping (AES + CMAC). The module will perform a pairwise consistency check upon generating ECDH keys.

5.6.2.1.2 Owner Assurance of Private-Key Validity: For ephemeral key pair, the module provides

the assurance since the module generates it. For static key pairs, after receiving the key pair, the module performs a separate check to determine that the private key is in the correct interval.

5.6.2.1.3 Owner Assurance of Public-Key Validity: For both static and ephemeral key pairs, the

module performs a full public-key validation as a separate process from the key-pair generation process.

5.6.2.1.4 Owner Assurance of Pair-wise Consistency: The module performs a pair-wise

consistency test when the module generates ephemeral key pairs and when static key-pairs are entered into the module.

5.6.2.1.5 Owner Assurance of Possession of the Private Key: For ephemeral key pairs, The owner

generates the key pair as specified in Section 5.6.1 and for ephemeral key pairs, the module performs a pair-wise consistency test when the key pairs are entered. © 2025 IDEMIA / atsec information security.

5.6.2.2.1 Recipient’s assurance Static Public-Key Validity: The module makes used of approved

EC curves listed in SP800-140D and performs a successful full public-key validation of the received public key i.e., ECC Full Public-Key Validation Routine specified in SP800-56A rev3 section 5.6.2.3.3.

5.6.2.2.2 Recipient Assurance of Ephemeral Public-Key Validity: Not applicable. The module

generates ephemeral keys and does not ever receive them.

5.6.2.2.3 Recipient’s assurance of owner’s possession of private key can be met via the use of a

Trusted Third party that requires the key confirmation procedure. Both of which are handled by the entity outside of the module that requested the ECDH Key Agreement service from the module. That is, such checks are out of the module's scope.

5.6.2.2.4 Recipient Assurance of the Owner’s Possession of an Ephemeral Private Key: Not

applicable. The module generates ephemeral keys and does not ever receive them.

The module performs the required public key validation before initiating the handshake following

Compliance to SP 800-56BRev3 assurances For KTS RSA, the tester verified the implementation satisfies IG D.G by employing an approved RSA-based key transport scheme as specified in SP 800-56Brev2. The following summary of assurances, as defined in Sections 5 and 6 of SP 800-56Brev2: Section 5.1 – The module uses an approved hash function (SHS, Cert. #A4945) for mask generation during RSA-OEAP encryption. Section 5.2 and Section 5.6 – N/A, The module does not implement key confirmation. Section 5.3 - The module uses an approved random bit generator (CTR_DRBG, Cert. #A4945) when generating random values. Section 5.4 and Section 5.5 – N/A, The module does not implement a key agreement scheme (i.e., KAS1). For addition assurances found in its Section 6 (specifically SP800-56Brev2 Section 6.4 Required Assurances):

1. The entity requesting the RSA key unwrapping (decapsulation) service from the module, shall only use an RSA private key that was generated by an active FIPS validated module that implements FIPS 186-4 compliant RSA key generation service and performs the key pair validity and the pairwise consistency as stated in section 6.4.1.1 of the SP 800-56Brev2. Additionally, the entity shall renew these assurances over time by using any method described in section 6.4.1.5 of the SP 800-56Brev2.
2. For use of an RSA key wrapping (encapsulation) service in the context of key transport per IG D.G, a) the entity using the module, shall verify the validity of the peer's public key using the public key validation service of the module. b) the entity using the module, shall confirm the peer's possession of private key by using any method specified in section 6.4.2.3 of the SP 800-56Brev2. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Only after the above assurances are successfully met, shall the entity use the peer's public key to perform the RSA key wrapping (encapsulation) service of the module."

Table 8: Entropy Certificates Table 9: Entropy Sources RNG Information: The module implements an approved SP 800-90Ar1 Deterministic Random Bit Generator in the form of CTR_DRBG. The DRBG seed is generated from the SP 800-90B

The module implements key generation services for RSA, ECDSA, EC Diffie-Hellman, and AES keys in compliance to SP800-133rev2 Cryptographic Key Generation (CKG, vendor affirmed).

The module provides an approved SP800-56Arev3 EC Diffie-Hellman Key Agreement Scheme that is fully compliant with IG D.F scenario 2 path (2). The module provides an approved SP800-38F Key Transport that is fully compliant to IG D.G i.e., employing an approved key-wrapping technique using a “combination” method: AES-CBC together with an approved authentication method AES-CMAC.

The GP Secure Channel Protocol '03' establishment provides mutual authentication service as well as establishment of a secure channel to protect confidentiality and integrity of the transmitted data. The PIV Secure Messaging protocol defined in SP800-73-4 and ANSI 504-1 establishes a secure channel to protect confidentiality and integrity of transmitted information and allows the off-card entity initiating the PIV Secure Messaging to authenticate the module. Unlike GP Secure Channel, the PIV Secure Messaging does not allow the module to authenticate the off-card entity. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 The PIV Secure Messaging protocol conforms to SP800-56A for the establishment of a shared secret and key derivation for session keys. © 2025 IDEMIA / atsec information security.

Table 10: Ports and Interfaces The module does not implement any control output interface.

The module does not implement a trusted channel. The control interface is inhibited while in the error state without any exceptions. © 2025 IDEMIA / atsec information security.

On-CardComparison Table 11: Authentication Methods The SD-DAK and SD-DMK keys are used to derive the SC-ENC and SC-C-MAC keys, respectively. The off-card entity participating in the mutual authentication sent a 64-bit challenge to the Smart Card together with the key set version to use. The Smart Card together with the key set version to use. generates its own challenge and computes a 64-bit cryptogram with SC-C-MAC key and both challenges. The Smart Card cryptogram and challenge are sent to the off-card entity which checks the Smart Card 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 SC-C-MAC key, the MAC is concatenated to the command, and the command is sent to the Smart Card. The Smart Card 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 role). The probability that a random attempt will succeed using this authentication method is:

• 1/(2128) = 2.9E‐39 (MAC||cryptogram using a 128‐bit block for authentication) © 2025 IDEMIA / atsec information security.

ID-One PIV 243 The module enforces a “slowdown mechanism” that increases the response time between two authentications attempts following a failed authentication, such that no more than nine (9) attempts are possible in a one-minute period. The probability that a random attempt will succeed over a one-minute interval is:

• 9/(2128) = 2.6E‐38 (MAC||cryptogram using a 128‐bit block for authentication) 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. GP Secure Channel Protocol Authentication Method using Pseudo Random The module supports Global Platform Authentication using an optional Pseudo Random method, described in "GP Secure Channel Protocol '03' Card Specification v2.2 Amendment D". The CO can determine the challenge which will be generated by the module. The use of a pseudorandom card challenge allows the offline preparation of personalization scripts while the module is not present and the processing of these scripts on the module without an online connection to the entity that prepared the scripts. When this option is called, the card challenge mentioned in the above section is the result of an AES-CMAC computed on a 24-bit counter value, a constant AID value, and a host challenge. The counter is initialized to 0 when the key is created or replaced, and the module returns an error when the counter reached 224-1. The use of the optional pseudo random card challenge does not impact the probabilities listed above. PIV Symmetric Key Authentication Method The external entity obtains a 16-byte challenge from the module, encrypts the challenge, and sends the cryptogram to the module. The module decrypts the cryptogram, and the external entity is authenticated if the decrypted value matches the challenge. This method is used by the PIV Application Administrator Authentication services. The minimum key strength used for this method is AES-128, using 16 bytes (a single AES block). The probability that a random attempt will succeed using this authentication method is:
• 1/(2128) = 2.9E-39 The module enforces a “slowdown mechanism” that increases the response time between two authentication attempts following a failed authentication, such that no more than nine (9) attempts are possible in a one-minute period. The probability that a random attempt will succeed over a one-minute interval is:
• 9/(2128) = 2.6E-38 PIV Secret Value Authentication Method The external entity submits an identifier and corresponding secret value. The format of the secret value is checked for conformance to a defined format template (Numeric in ASCII, Alphanumeric with at least one upper case, one lower case, one digit and one special character, Alphanumeric with at least three of the previous 4 categories, Numeric in BCD, HEX value, etc.), and for its minimum number of characters before padding. If the check passes, the module compares all eight (8) or sixteen (16) bytes to the appropriate stored reference instance (e.g. Cardholder PIN, Pin Unblocking Key or Administrator PIN). The enforcement of minimum number of characters before padding is not the same as a fixed length for the secret. For example, a minimum of six (6) characters means secrets can be created from six (6) to eight (8) characters, © 2025 IDEMIA / atsec information security.

ID-One PIV 243 determined by the user (or six (6) to sixteen (16) if the module was configured during production to support 16-byte PINs). The minimum length of the PIN is 6 bytes and the maximum 8 or 16 bytes depending on configuration. The worst-case scenario permitted by the module is a minimum length of six (6) characters with the Numeric in ASCII character set and a maximum length of eight (8) characters. The character space for the first six (6) bytes in this scenario is 10 (the values ‘30’ through ‘39’ are permitted) and in the last two (2) characters is 11 (the values ‘30’ through ‘39’ and ‘FF’ are permitted). The probability that a random attempt will succeed using this authentication method is:

• 1/(106 *112) = 8.3E-9 The maximum number of consecutive failed authentication attempts can be configured up to 15, so the probability that a random attempt will succeed over a one-minute interval is:
• 15/(106 * 112) = 1.2E-7 BIO Authentication method The module performs a biometric person authentication On-Card-Comparison (OCC) using one of the following methods:
• A live fingerprint template as defined by FIPS 201-2. (BIT Format Owner = 0x0101) An iris template. (BIT Format Owner = 0x001D) A facial template. (BIT Format Owner = 0x001D) The default threshold applied to scores from the fingerprint OCC algorithms has been set to achieve false match rates (FMR) at or below the respective values defined by NIST in Table 16 of SP800-76-2, i.e., an FMR of 0.001 for on-card fingerprint minutia matching. As required by SP800-76-2 section 5.7.4.1, the on-card-matching algorithm matches single-finger native templates with False Non-Match Rate (FNMR) less than or equal to 0.02 when the FMR is at or below 0.0001. The default threshold for Facial OCC has been set to achieve false match rates (FMR) of 0.001. The default threshold for Iris OCC has been set to achieve false match rates (FMR) of 0.001. The above default threshold values can be adjusted by the Crypto-Officer and/or the PIV Application Administrator. The maximum number of consecutive failed Bio authentication attempts can be configured up to

15 per modality (Fingerprints, Iris, Facial) so the probability that a random attempt will succeed

over a one-minute interval is:

• 15/(103) = 0.015

© 2025 IDEMIA / atsec information security.

ID-One PIV 243 Table 12: Roles The module does not include a maintenance role. The module clears previous authentications on power cycle.

The following convention is used to specify access rights to SSPs:

• Generate (G): The module generates or derives the SSP. Read (R): The SSP is read from the module (e.g. the SSP is output). Write (W): The SSP is updated, imported, or written to the module. Execute (E): The module uses the SSP in performing a cryptographic operation. n N/A N/A N/A Run SelfTests N/A F' © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n N/A - OS-DRBGSEED: G,E - OS-DRBGSTATE: G,E g N/A - OS-DRBGSEED: G,E - OS-DRBGSTATE: G,E - SM-RMAC: G,E G,E - PIV-SMPUB: R N/A - OS-DRBGSEED: G,E - OS-DRBGSTATE: G,E G,E G,E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n G,E ) N/A N/A N/A ) N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n 4.1.A. 4.1.A. N/A 4.1.A. N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) 4.1.A. 4.1.A. N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n 4.1.A. ) with SP80073-4. N/A with SP80073-4. N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. ) with SP80073-4. with SP80073-4. N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. N/A ) with SP80073-4. N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. with SP80073-4. ) N/A with SP80073-4. N/A with SP80073-4. N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. N/A ) with SP80073-4. N/A with SP80073-4. N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. N/A ) with SP80073-4. N/A with SP80073-4. N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. N/A ) N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n N/A ) N/A N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) with SP80073-4. 7.1.2 N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n 7.1.2 with SP80073-4. 7.1.2 N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) with SP80073-4. 5.7.1.2. with SP80073-4. 5.7.1.2. N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. 5.7.1.2. N/A ) with SP80073-4. N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n with SP80073-4. N/A with SP80073-4. N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) with SP80073-4. with SP80073-4. N/A m, :E with SP80073-4. N/A m, :E N/A m, :E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) with SP80073-4. with SP80073-4. with SP80073-4. m, N/A m, :E N/A m, :E :E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) N/A m, - MUTUALAUTH: E N/A m, - MUTUALAUTH: E N/A m, - MUTUALAUTH: E N/A E E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n N/A N/A E,Z E,Z E,Z - OS-DRBGSEED: Z - OS-DRBGSTATE: Z Z Z - SM-RMAC: Z Z - OCCFingerprints :Z - OCCFacial: Z Z Z :Z D © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - MUTUALAUTH: Z - SAMCMAC: Z Z - SAM-KDFENC: Z - TOTPSHA1: Z - TOTPSHA256: Z - TOTPSHA512: Z - PIV-SMPUB: Z - PIV-AUTHPUB - PIV-DSPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - DS-HASHPUB N/A N/A E N/A W,E E E W W W W © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W - OCCFingerprints :W - OCCFacial: W W N/A E E N/A E E N/A - OCCFingerprints :Z - OCCFacial: Z Z Z :Z © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - MUTUALAUTH: Z - SAMCMAC: Z - SM-RMAC: Z Z - TOTPSHA1: Z - TOTPSHA256: Z - TOTPSHA512: Z - PIV-SMPUB: Z - PIV-AUTHPUB - PIV-DSPUB - PIV-KMKPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - DS-HASHPUB ) N/A Z Z N/A E,Z - SM-RMAC: E,Z N/A E E ) N/A Z Z © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W - OCCFingerprints : W,Z N/A E,Z - SM-RMAC: E,Z W - OCCFingerprints : W,Z N/A E E W - OCCFingerprints : W,Z On-BoardKeyGeneratio N/A s © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n ) On-BoardKeyGeneratio N/A s Z Z - PIV-AUTHPUB - PIV-DSPUB - PIV-SMPUB: G - DS-HASHPUB E,Z - SM-CMAC: E,Z - SM-RMAC: E,Z © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n On-BoardKeyGeneratio - PIV-AUTHPUB - PIV-DSPUB - PIV-SMPUB: G - DS-HASHPUB N/A s E E - PIV-AUTHPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n On-BoardKeyGeneratio ) - PIV-DSPUB - PIV-SMPUB: G - DS-HASHPUB N/A s Z Z - PIV-AUTHPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - PIV-SMPUB: G - DS-HASHPUB On-BoardKeyGeneratio N/A s E,Z - SM-CMAC: E,Z - SM-RMAC: E,Z - PIV-AUTHPUB - PIV-DSPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - DS-HASHPUB On-BoardKeyGeneratio N/A s E E - PIV-AUTHPUB - PIV-DSPUB - PIV-SMPUB: G © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n N/A & E,Z - SM-RMAC: E,Z : W,Z W,Z - PIV-AUTHPUB W,Z W,Z - PIV-DSPUB W,Z W,Z - PIV-KMKPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W,Z W,Z - PIV-SMPUB: W,Z - MUTUALAUTH: W,Z W,Z - DS-HASHPUB W,Z - SAMCMAC: W,Z W,Z - SAM-KDFENC: W,Z W,Z - TOTPSHA1: W,Z - TOTPSHA256: W,Z - TOTPSHA512: W,Z E,Z - SM-RMAC: E,Z © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n : W,Z W,Z - PIV-AUTHPUB W,Z W,Z - PIV-DSPUB W,Z W,Z - PIV-KMKPUB W,Z W,Z - PIV-SMPUB: W,Z - MUTUALAUTH: W,Z W,Z - DS-HASHPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W,Z - SAMCMAC: W,Z W,Z - SAM-KDFENC: W,Z W,Z - TOTPSHA1: W,Z - TOTPSHA256: W,Z - TOTPSHA512: W,Z N/A & E E : W,Z W,Z - PIV-AUTHPUB W,Z © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W,Z - PIV-DSPUB W,Z W,Z - PIV-KMKPUB W,Z W,Z - PIV-SMPUB: W,Z - MUTUALAUTH: W,Z W,Z - DS-HASHPUB W,Z - SAMCMAC: W,Z W,Z - SAM-KDFENC: W,Z W,Z - TOTPSHA1: W,Z - TOTPSHA256: © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W,Z - TOTPSHA512: W,Z E E : W,Z W,Z - PIV-AUTHPUB W,Z W,Z - PIV-DSPUB W,Z W,Z - PIV-KMKPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n W,Z W,Z - PIV-SMPUB: W,Z - MUTUALAUTH: W,Z W,Z - DS-HASHPUB W,Z - SAMCMAC: W,Z W,Z - SAM-KDFENC: W,Z W,Z - TOTPSHA1: W,Z - TOTPSHA256: W,Z - TOTPSHA512: W,Z ) N/A E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n - OCCFingerprints :E - OCCFacial: E N/A E - OCCFingerprints :E - OCCFacial: E N/A E - OCCFingerprints :E - OCCFacial: E ) N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n E - OCCFingerprints :E - OCCFacial: E N/A E - OCCFingerprints :E - OCCFacial: E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n N/A E - OCCFingerprints :E - OCCFacial: E N/A - SAMCMAC: E E - SAM-KDFENC: E © 2025 IDEMIA / atsec information security.

ID-One PIV 243 n N/A - SAMCMAC: E E - SAM-KDFENC: E One-TimePassword N/A One-TimePassword N/A - TOTPSHA1: E - TOTPSHA256: E - TOTPSHA512: E Table 13: Approved Services The module supports unauthenticated services which perform cryptographic operations yet do not claim any security provided by the module but instead serve to identify the module to an external entity for attestation services. Item '1b' in IG 4.1.A "Additional Comments" section provides a list of rationales for which exemption can be claimed. These are: © 2025 IDEMIA / atsec information security.

ID-One PIV 243 a) the referenced algorithms and services do not create, disclose, modify, substitute, access, or make use of the module’s CSPs, and PSPs are not modified or substituted; or b) that the referenced algorithms and services do not affect the security of the module, or the security of the information being protected by the module. The module implements PIV card validation and attestation services that use symmetric keys and asymmetric private keys purely to provide the module's cryptographic identity to an external entity. The use of cryptographic challenge-response schemes with symmetric keys use of asymmetric signature verification schemes to validate private keys embedded within the module are not claimed to provide protection of data but rather only serve to confirm the module's identity to an external entity. For this, the module provides a signed message using its device specific private key contained within. In addition, - The message being signed is predefined i.e., not a user defined message that can be offered as service to the caller. - This attestation specific key cannot be reused for any other purpose. - The signature generation operation is performed during boot time before any User has a chance to interact with the module. So, the service is not handling or protecting any user data. Based on above facts it is clear that the referenced algorithms (SHA, AES-ECB, ECDSA and RSA) and services (signature generation, message digest) do not affect the security of the module, or the security of the information being protected by the module. Therefore, the module complies to exception '1b' in additional comment of IG 4.1.A.

The module includes a firmware load process (Manage Content service) to support necessary updates. New firmware versions within the scope of this validation must be validated through the FIPS 140-3 CMVP. Any other firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140-3 validation. When new firmware is loaded into the module using the "Load FW with RSA DAP" and "Load FW with AES DAP" services, the Module verifies the SHA-256 digest computed over the all firmware, and the AES-CMAC authentication code computed with SD-SMAC on each block of the firmware and the SHA-256 digest. In addition to the previous method, the firmware load process verifies an RSA PSS signature computed with DAP-PUB or an AES-CMAC authentication code computed with DAP-AES key on the firmware SHA-256 digest. © 2025 IDEMIA / atsec information security.

The module performs an integrity test over the executable firmware loaded in non-volatile memory (NVM) (i.e. Javacard Packages) and over the ROM Code (i.e. Operating System). The integrity test uses a 16-bit CRC. The module does not provide any services via the HMI, SFMI, HFMI, or HSMI interface that allow the operator to examine the executable code.

The pre-operational integrity test can be performed on demand by power cycling or resetting the module. The module may perform conditional cryptographic algorithm self-tests on demand through the "Context" service. © 2025 IDEMIA / atsec information security.

Type of Operational Environment: Limited The module is classified as a single chip hardware module running on limited modifiable firmware, the requirements of this section are not applicable. © 2025 IDEMIA / atsec information security.

Table 14: Mechanisms and Actions Required Table 15: EFP/EFT Information

Table 16: Hardness Testing Temperatures © 2025 IDEMIA / atsec information security.

This module implements non-invasive security techniques that are not listed in SP800-140F. These techniques are mentioned in Section 12. © 2025 IDEMIA / atsec information security.

Table 18: SSP Input-Output Methods © 2025 IDEMIA / atsec information security.

Table 19: SSP Zeroization Methods © 2025 IDEMIA / atsec information security.

The table below summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. h y OS-DRBGSEED OS-DRBGSTATE © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y OCCFingerprints N/A - N/A N/A - N/A N/A - N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y ECDSA P224, P256, P384, P521 RSA: t ECDSA P224, P256, Pt © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y ECDSA P224, P256, P384, P521 RSA: 80, t MUTUALAUTH © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y 224, P256, P384, P521 RSA: SAM-KDFENC © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y TOTPSHA256 TOTPSHA512 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y PIV-AUTHPUB ECDSA P224, P256, P384, P521 RSA: ECDSA P224, P256, P384, P521 RSA: PIV-KMKPUB ECDSA P224, P256, P384, P521 RSA: t © 2025 IDEMIA / atsec information security.

ID-One PIV 243 h y DS-HASHPUB ECDSA P224, P256, P384, P521 RSA: Table 20: SSP Table 1 The following table continues to summarize the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. OS-DRBGSEED OS-DRBGSTATE SCENC:Derives © 2025 IDEMIA / atsec information security.

ID-One PIV 243 SMENC:Derives © 2025 IDEMIA / atsec information security.

ID-One PIV 243 SMCFRM:Used PIVSM:Derived PIVSM:Derived PIVSM:Derived OCCFingerprints © 2025 IDEMIA / atsec information security.

ID-One PIV 243 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 MUTUALAUTH © 2025 IDEMIA / atsec information security.

ID-One PIV 243 SAM-KDFENC © 2025 IDEMIA / atsec information security.

ID-One PIV 243 TOTPSHA256 TOTPSHA512 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 PIV-AUTHPUB © 2025 IDEMIA / atsec information security.

ID-One PIV 243 © 2025 IDEMIA / atsec information security.

ID-One PIV 243 DS-HASHPUB Table 21: SSP Table 2 © 2025 IDEMIA / atsec information security.

The module performs the following self-tests: pre-operational firmware integrity test, conditional cryptographic algorithm test, conditional firmware load test and conditional pair-wise consistency The module does not support any of the following self-tests: Pre-operational Self-tests - preoperational bypass nor pre-operational critical functions test, conditional manual entry test, conditional bypass test, nor conditional critical functions test. Determination of pass or fail of each self-test is made by the module, without external controls, externally provided input test vectors, expected output results, or operator intervention. The module can also perform preoperational self-tests on demand for all pre-operational selftests by power cycling the module or by calling the “Run Self-Tests” service.

The module performs pre-operational firmware integrity test automatically as a first action at power on. The module first performs a CAST on the cryptographic algorithm test used to perform the approved integrity technique. The module will enter the error state if the either the conditional CAST or integrity test fails or proceed to test the conditional CASTs listed in Table 25 if both passes. Table 22: Pre-Operational Self-Tests

The module performs conditional CAST prior to the algorithm’s first use. The module performs Conditional Pair-wise Consistency Tests upon generating RSA, ECDSA or ECDH asymmetric key pairs. The test is implemented by calculating a signature on predetermined data and subsequently performing a verification of the signature. If the signature cannot be verified, the generated key-pair is discarded. The module performs a conditional firmware load test when the module loads new firmware. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Sp80056Ar3 HMACSHA2-256 N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 N/A Table 23: Conditional Self-Tests

The module has the capability to perform the pre-operational and conditional self-tests periodically. This may occur after a predefined number of -minutes passes, or, depending on the factory configuration, after invoking a predefined number of commands (APDUs). The default configuration triggers a Periodic Self-Tests every 2 weeks of uninterrupted power. That time can be adjusted by the Application Administrator from 1 to 32767 minutes. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 Table 24: Pre-Operational Periodic Information © 2025 IDEMIA / atsec information security.

ID-One PIV 243 N/A N/A © 2025 IDEMIA / atsec information security.

ID-One PIV 243 N/A Table 25: Conditional Periodic Information

zone called the “Kill Card Zone” records the reason for the failure. All cryptographic functions are inhibited while the module is in an error state. The table below describes the error states in detail: Table 26: Error States © 2025 IDEMIA / atsec information security.

The module must have been initialized, within IDEMIA factory, to run in FIPS 140-3 level 2 mode of operation (e.g., NPIVP, CIV, etc.).

After manufacturing, the module is locked by a PIN Activation Code. The PIN Activation Code allows the card holder to set his or her own PIN value upon getting possession of the card. The PIN Activation Code can only be used as an authentication value for the initialization of the PIV PIN. The card holder's PIV PIN is then used for card activation.

The module does not implement an administrator guidance.

The module does not implement a non-administrator guidance.

The module enforces the following security rules:

1. The module provides three distinct operator roles: Cryptographic Officer, PIV Application Administrator and User.
2. The module provides identity-based authentication.
3. The module clears previous authentications on power cycle.
4. The module’s firmware is in executable form that does not require further compilation and there is no dynamically modified code.
5. Pre-operational Integrity self-tests do not require any operator action.
6. Data outputs are inhibited during key generation, self-tests, zeroization, and error states.
7. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
8. There are no restrictions on which keys or CSPs are zeroized by the zeroization service.
9. The module does not support a maintenance interface or role.
10. The module does not support manual key entry.
11. The module does not have any proprietary external input/output devices used for entry/output of data.
12. The module does not output intermediate key values or plaintext CSPs. No additional interface or service is implemented by the module which would provide access to CSPs.

The module lifecycle service can be used to set the module's status to TERMINATED. All SSPs will be zeroized upon module reset. © 2025 IDEMIA / atsec information security.

The Module implements defenses against:

• Light attacks: The chip includes sensors to detect light attacks. A hardware attack event triggers the Kill Card behavior described below. Invasive fault attacks: The chip includes sensors for fault attacks. A hardware attack event triggers the Kill Card behavior described below. Side-channel attacks (SPA/DPA, timing analysis): The chip implements hardware countermeasures, such as induced clock jitter. The operating system enables the hardware counter measures and implements independent countermeasures in code, such as constant time execution. Electromagnetic attacks: This includes the defenses against side-channel attacks described above, where the detection mechanism is monitoring chip emissions rather than physical power connections. In addition, the hardware includes sensors to detect electromagnetic attacks, invoking Kill Card behavior if detected. Differential fault analysis (DFA): The operating system provides checks of expected conditions in areas of code deemed sensitive. If the check detects an error, the Kill Card behavior is initiated. 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., is removed from the reader) before completion of the protective function.

The Kill Card function logs the detected attack type in a table. The table has a preset limit; when the limit is reached, the module initiates card termination, including overwrite of the CSPs, and the module is no longer operable. © 2025 IDEMIA / atsec information security.

ID-One PIV 243 References ANS X9.632001 Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography 2001 https://webstore.ansi.org/standards/ascx9/ansix9632001 ANSI X9.62 Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA) September 1999 https://webstore.ansi.org/standards/ascx9/ansix9621998 ANSI 504-1 Information Technology - Generic Identity Command Set - Part 1: Card Application Command Set - Amendment 1 May 2016 https://webstore.ansi.org/standards/incits/incits5042013am12016 FIPS 140-3 FIPS PUB 140-3 - Security Requirements for Cryptographic Modules November 2023 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips140-3-ig-announcements FIPS 180-4 Secure Hash Standard (SHS) March 2012 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS 186-4 Digital Signature Standard (DSS) July 2013 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf FIPS 197 Advanced Encryption Standard November 2001 https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS 198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf © 2025 IDEMIA / atsec information security.

ID-One PIV 243 FIPS 201-3 Personal Identity Verification (PIV) of Federal Employees and Contractors January 2022 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf FIPS 202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions August 2015 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf GPC_SPE_014 GlobalPlatform Card Technology Secure Channel Protocol '03' Card Specification v2.2

• Amendment D Version 1.1.1 July 2014 https://globalplatform.org/wpcontent/uploads/2014/07/GPC_2.2_D_SCP03_v1.1.1.pdf GPC_SPE_014 GlobalPlatform Card Technology - Card Specification v2.3.1 March 2018 https://globalplatform.org/specs-library/card-specification-v2-3-1/ ISO 7816 Identification cards -- Integrated circuit cards 2004 ISO 14443 Identification cards
• Contactless integrated circuit cards 2016 ISO 24787 Information technology
• Identification cards
• On-card biometric comparison 2010 JavaCard JAVA CARD CLASSIC PLATFORM SPECIFICATION 3.1 CE February 2021 https://www.oracle.com/java/technologies/javacard-downloads.html PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt © 2025 IDEMIA / atsec information security.

ID-One PIV 243 SP 800-38A Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP 800-38B Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 https://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP 800-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP800-56B Rev2 Recommendation for Pair-Wise Key Establishment Using Integer Factorization Cryptography March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf SP 800-56Cr2 Recommendation for Key-Derivation Methods in Key-Establishment Schemes August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf SP 800-73-4 Interfaces for Personal Identity Verification

• Part 1: PIV Card Application Namespace, Data Model and Representation May 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf SP 800-76-2 Biometric Specifications for Personal Identity Verification July 2013 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-76-2.pdf SP 800-78-4 Cryptographic Algorithms and Key Sizes for Personal Identity Verification May 2015 https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-78-4.pdf © 2025 IDEMIA / atsec information security.

ID-One PIV 243 SP 800-85A-4 PIV Card Application and Middleware Interface Test Guidelines (SP 800-73-4 Compliance) April 2016 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-85A-4.pdf SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf SP 800-108r1 NIST Special Publication 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions August 2022 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf SP 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf SP 800-140Br1 CMVP Security Policy Requirements October 2022 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800140Br1.2pd.pdf © 2025 IDEMIA / atsec information security.

Referenced URLs

• www.atsec.com
• https://webstore.ansi.org/standards/ascx9/ansix9632001
• https://webstore.ansi.org/standards/ascx9/ansix9621998
• https://webstore.ansi.org/standards/incits/incits5042013am12016
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf
• https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
• https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
• https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.201-3.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
• https://globalplatform.org/wp-
• https://globalplatform.org/specs-library/card-specification-v2-3-1/
• https://www.oracle.com/java/technologies/javacard-downloads.html
• https://www.ietf.org/rfc/rfc3447.txt
• https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
• https://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Br2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-76-2.pdf
• https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-78-4.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-85A-4.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-