JCOP 4.5 on P71D600

Certificate

Approved Algorithms (34)

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

flowchart LR
  %% Deterministic review-risk graph for JCOP 4.5 on P71D600
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status output<br/>Show status</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"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    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 JCOP 4.5 on P71D600
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status output<br/>Show status</i><br/>src: text:keyword"]
    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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 JCOP 4.5 on P71D600 Document Version: 1.6 Date: 20 March 2025 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Revision History: Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Contents List of Figures List of Table Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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/cryptographicmodulevalidation-program. About this Document This non-proprietary Cryptographic Module Security Policy for the NXP Semiconductors JCOP 4.5 on P71D600 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 JCOP 4.5 on P71D600 may also be referred to as the “Secure Element” or “module” in this document. The module is available under several commercial type names addressing the different market segments relevant for NXP, such as:
• JCOP 4.5 on P71D600
• JCOP ID 2 on P71D600
• SE052F
• NCJ37B0HN Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. NXP Semiconductors 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. Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 The following table lists the level of validation for each area in FIPS 140-3: Table 1

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

The module, validated to FIPS 140-3 overall Level 3, is a hardware module with single chip embodiment named the applications: The module is designed for use in smart cards, IoT and automotive applications. Table 2

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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 P-

256 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: Code Value Parameter settings CLA ‘80’ GlobalPlatform INS ‘CA’ GET DATA (IDENTIFY) - ISD P1 ‘00’ High order tag value P2 ‘FE’ Low order tag value - proprietary data Lc ‘02’ Length of data field Data ‘DF28’ Module identification data Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Le ‘00’ Length of response data 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

2. 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:
3. 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 =
4. 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.
5. 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. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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 = 00.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. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Cryptographic Algorithms The module implements the following Approved cryptographic algorithms. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 (2) Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Table 3

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

EC Diffie-Hellman with non-NIST recommended curves

Provides between 112 and 256 bits of encryption strength Per IGs D.F and C.A

Shared secret computation using non-NIST curves [Brainpool224r1, Brainpool256r1, Brainpool320r, Brainpool384r1, Brainpool512r1, Secp224k1, Secp256k1 with strengths ]112, 128, 192 and 256 bits]

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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: EC                 Standard            Strength               Singular                Field          Co-Factor Brainpool224r1             [RFC5639]                 112                    No                    IFp               1 EC                 Standard            Strength               Singular                Field          Co-Factor Brainpool256r1             [RFC5639]                 128                    No                    IFp               1 Brainpool320r1             [RFC5639]                 128                    No                    IFp               1 Brainpool384r1             [RFC5639]                 192                    No                    IFp               1 Brainpool512r1             [RFC5639]                 256                    No                    IFp               1 Secp224k1                  [SEC2]                    112                    No                    IFp               1 Secp256k1                  [SEC2]                    128                    No                    IFp               1 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. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Figure 1

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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. Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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. Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Table 5

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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. Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Table 6

• Roles, Service Commands, Input and Output 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. Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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. 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 Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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 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 (APPECPUBLIC-KEY-CO). The user will own the corresponding ECDSA private key. In addition to User’s authentication, ECKey session is used to establish Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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-PUBLICKEYUSER 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) 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, NXP. 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. Public Material
• May be reproduced only in its original entirety (without revision).

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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.
• R = Read: The service outputs the CSP/Public Key. CSP are always protected with the approved KTS.
• Z = Zeroize: The Module zeroizes the CSP/Public Key after usage. A zeroised CSP is not retrievable or reusable. Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

The module claims to meet Physical Security Level 4 and thus the requirements per this section do not apply. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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 N/A N/A Table 10

• EFP/EFT Table 11
• Hardness Testing Temperature Ranges Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

Please see Section 12 below for information regarding non-invasive security countermeasures. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 B.4.2 ; d G Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 B.4.2 ; d G Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 N/A Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 B.4.2 s ; G Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 B.4.2 s ; G Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 Table 12

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

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 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). Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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))
• NIST SP800-90B ENT (P) Repetition Count Test (RCT) performed on raw data Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

• 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 Note: The module does not support loading of external firmware by the operator (it is limited to the vendor, NXP Semiconductors, 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). Public Material
• May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600

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 outofrange 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. Public Material – May be reproduced only in its original entirety (without revision).

FIPS 140-3 Security Policy - JCOP 4.5 on P71D600 END OF DOCUMENT