mToken CryptoID

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for mToken CryptoID
  %% 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>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>IPSEC<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    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 mToken CryptoID
  %% 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>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>IPSEC<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/>linux<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,C5,C6 clueLow;

Security Policy, page by page

Century Longmai Technology Co. Ltd mToken CryptoID Document Version: 1.1 Date: 2024-10-15 Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for a Security Level 3 module. In this document, the terms “token”, “cryptographic module” or “the module” are used interchangeably to refer to the mToken CryptoID.

The FIPS 140-3 security levels for the Module are as follows from Table 1: Table 1: Security Levels

The Longmai mToken CryptoID is a new generation smartcard chip based two-factor authentication device utilizing CCID drivers. The smartcard chip design utilizes the built-in mCOS to communicate with a General Purpose Computer (GPC) via the USB interface in a “plug-and-play” manner. The mToken CryptoID implements the USB Circuit Cards Interface Device (CCID) protocol to communicate with the host application running on a computer device. CCID drivers work to protect the device and are less susceptible to packet sniffing thus providing stronger authentication. The Application Protocol Data Unit (APDU) command-response protocol is transferred via the USB interface and is compatible with ISO/IEC 7816-4 standards. It provides the security services needed to interact with the Public Key Infrastructure (PKI) applications, including Digital Signature Generation/Verification for online authentication and Data Encryption/Decryption for online transactions. Here is the list of main functions provided by the

• Transportation Management
• File System Management
• Secret PIN Management
• Access Control Management Longmai Public Material
• May be reproduced only in its original entirety (without revision).

• Session Key Management
• Key Pair Management
• Data Digest Management
• Algorithm Management
• Algorithm Hardware Engine Purpose and Use: The Module is intended to be used by Certificate Authorities, Digital Signature Service Providers or other markets that require FIPS 140-3 validated hardware cryptographic module. The Module is intended to be used in a General Purpose Computer (GPC) within the following temperature range: -30oC ~ 80oC, voltage range 2.7V~5.8V. Module Type: Hardware Module Embodiment: MultiChipStand Module Characteristics: Longmai Public Material
• May be reproduced only in its original entirety (without revision).

Cryptographic Boundary: The physical form of the Module is depicted below in Figure 1 and the block diagram is depicted in Figure 2 below. The Module is a hardware module with a multi-chip standalone embodiment. The cryptographic boundary of the Module is defined by the hard, semi-transparent, polycarbonate (plastic) or metal casing of the USB token. The Module is comprised of a SCC-XE microcontroller sitting atop a Printed Circuit Board (PCB). The PCB carries the signals and instructions of the microcontroller to the other components contained within the Module. All cryptographic functions and firmware are stored within the microcontroller package and executed by a 32-bit CPU (Core Processing Unit). Figure 1 - mToken CryptoID-K9 and mToken CryptoID-A3 Longmai Public Material – May be reproduced only in its original entirety (without revision).

Tested Module Identification

• Hardware: The Module operates in a non-modifiable operational environment and does not implement a General Purpose Operating System. Once the firmware of the Module is loaded on the mToken CryptoID, it cannot be modified or erased, firmware cannot be upgraded/updated. The operational environment requirements do not apply to the Module. Table 2: Tested Module Identification
• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. Tested Module Identification
• Hybrid Disjoint Hardware: Longmai Public Material
• May be reproduced only in its original entirety (without revision).

N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

NOTE: No Components were excluded from the cryptographic boundary

Modes List and Description: Table 3: Modes List and Description Configuration of the Approved Mode of Operation The mToken CryptoID module is originally non-compliant and must be configured to operate in an approved mode of operation. The Approved mode of operation is configured by the Issuer (CO) prior to being distributed to the end users. Please see Section 11.1 Installation, Initialization, and Startup Procedures for initial Approved mode configuration. command which indicates that all self-tests have completed successfully. In Approved mode, only approved algorithms are allowed and available to the services. Please refer to the LED status table for the details of the LED status indicator of the module. Longmai Public Material – May be reproduced only in its original entirety (without revision).

Configuration of the Non-Approved Mode of Operation The Module is sent from manufacturing to the Issuer (CO) in Non-Approved mode. When the Module operates in Non-Approved mode, the green LED is off and the steady red LED is on. The Module returns “00” from the calling GetData APDU command which indicates that the module is in Non-Approved mode, and the module returns “0000000000000000” to the calling GetHealthStatus APDU command which indicates that the self-test have completed successfully. The GetData APDU command returns an error when the Module is uninitialized. Both Approved services and Non-Approved services are listed in Table 19: Approved Services and Table 20: Non-Approved Services are allowed in Non-Approved mode. Mode Change Instructions and Status [O]: Once the Module is initialized, the Issuer can switch the mode of operation by calling the ChangeWorkingMode APDU command with “P1” parameter. If “P1” is 1, the module is configured to operate in Approved mode; if “P1” is 0, the module is configured to operate in Non-Approved mode. The Module is zeroized as part of the switching process preventing the sharing of CSPs between modes. After the successful completion of the pre-operational self-tests, the Module automatically enters Approved mode or Non-Approved mode based on the value of the “P1” parameter.

Approved Algorithms: The Module implements the Approved cryptographic algorithms listed in the table below. Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 4: Approved Algorithms Note: KAS [56Ar3] - Per [IG] D.F Scenario 2 path (2), [56Ar3] compliant key agreement scheme where testing is performed end-to-end for the shared secret computation and a KDF compliant with onestepkdf. without key confirmation. Vendor-Affirmed Algorithms: The Module implements the Approved Vendor Affirmed cryptographic algorithms listed in the Table below. Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: Note: The Module does not implement any Non-Approved, Algorithms Allowed in the Approved Mode of Operation. N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: Note: The Module does not implement any Non-Approved, Algorithms Allowed with No Security Claimed in the Approved Mode of Operation. N/A for this module. Non-Approved, Not Allowed Algorithms: The Module implements the Non-Approved, Not Allowed cryptographic algorithms listed in the table below. Table 6: Non-Approved, Not Allowed Algorithms

The table below shows the Security Function Implementations that the module implements: Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

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

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

Table 7: Security Function Implementations

Note: There is no Algorithm Specific Information.

Table 8: Entropy Certificates The Module uses the following entropy source: Table 9: Entropy Sources

For Key Generation, see Section 2.5 and Section 2.6 above.

For Key Establishment, see Section 2.5 and Section 2.6 above.

Note: The Module does not provide any industry protocols. Longmai Public Material – May be reproduced only in its original entirety (without revision).

The Module’s ports and associated FIPS defined logical interface categories are listed in the table below. Table 10: Ports and Interfaces The mToken CryptoID uses an LED to encode various status conditions as shown in the table below: Table 11 – LED status

The mToken CryptoID supports Identity-Based Authentication to authenticate the operators. The Module supports External Authentication with KEY_EA which authenticates the host application running on a computer to the module. The Module also supports Internal Authentication with KEY_IA which the module authenticates itself to the host application. Longmai Public Material – May be reproduced only in its original entirety (without revision).

The Issuer is authenticated by providing the Main Control Key (KEY_MC) with ExternalAuth APDU command. Only the manufacturer or the distributor can be authenticated as an Issuer. When the Module is delivered to the end user, they can authenticate themselves by providing their KEY_PIN (i.e., Admin PIN or User PIN) with Verify PIN APDU command. The operators can logout by calling the ClearSecureState APDU command or by unplugging the module from the GPC. The Module uses the “challenge-response” method for all types of authentications. module for verification. The Module decrypts the ciphertext with the AES-256 symmetric algorithm and compares the result with the original random value from the GetChallenge command. If the results are the same, the authentication is completed successfully; otherwise, the authentication fails, and the Module will decrement the value pre-defined in “LeftRetryTimes”. Once the value stored in “LeftRetryTimes” reaches 0, the key is locked. The authentication data uses default keys and are required to be changed upon first login. For PIN-based authentication, the host application calls the GetChallenge command to get a random generates a SHA2-256 hash value from the PIN provided by the operator. The random value is encrypted with the SHA2-256 hash value of the PIN using an AES-128 symmetric algorithm. The PIN ID and ciphertext are transmitted to the Module for verification. The Module generates a SHA2-256 hash value from the PIN based on the PIN ID, decrypts the ciphertext with the SHA2-256 hash value using the predefined symmetric algorithm, and compares the result with the original random value from the GetChallenge command. Once the default PIN is used, changing it is required upon first login. If the results are the same, the authentication has been completed successfully; otherwise, the authentication fails, and the module will decrement the “LeftRetryTimes” variable. Once the value stored in “LeftRetryTimes” reaches 0, the PIN is locked. No visible display of the authentication data is allowed from the Module. The host application running on the GPC interacting with the module obscures the authentication data during data entry. The authentication data is stored in the key files which can never be exported outside the mToken CryptoID. Longmai Public Material – May be reproduced only in its original entirety (without revision).

The Module supports three (3) distinct operator roles, Issuer (CO), Admin and User. The cryptographic module enforces the separation of roles by associating the current connection with the most recent authenticated user identity. The Module does not support a maintenance role or bypass capability. The Module does not support concurrent operators. The current operator status is stored in the security context in memory. When the operator logs out or if another operator attempts to login, the security context will be cleared, and the operator will be logged out automatically. The security context will also be cleared when the Module is powered off. The Roles table and the Approved Services table lists all operator roles (Issuer (CO)

• “I”, Admin
• “A” and User
• “U”) supported by the Module and their related services. In addition, the Module supports services which do not require to be authenticated, listed as Role “N” in The Roles table and the Approved Services table. Note, all services return an indication of success or specific error in addition to the output indicated. When in Non-Approved mode the services annotated with an * allow the NonApproved algorithms and key sizes indicated in Table 7. Unless annotated with an ~, services are available using secure messaging using S_ENC and S_MAC. The Roles Table below lists all operator roles supported by the Module. Longmai Public Material
• May be reproduced only in its original entirety (without revision).

The Module does not support concurrent operators. Table 13: Roles

All approved services implemented by the Module are listed in the table below: Unless annotated with an ~, the service is available using secure messaging which uses S_ENC with CBCAES256 and S_MAC with CMAC-AES256 with access rights of E as defined below. The SSPs modes of access shown in the table below are defined as:

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

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

Z Z Z 4): Z Z Z W G,E G,E G,E Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

G,W,E,Z G,R,W,E, Z 4): G,W,Z G,E 4): G,W,Z G,E G,E 4): G,W,Z G,E 4): Z Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

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

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

W,Z W,Z W,Z R,G,E R,G,E R,G,E E E E E E Longmai Public Material – May be reproduced only in its original entirety (without revision).

E E E E E 4): W,E Longmai Public Material – May be reproduced only in its original entirety (without revision).

4): R,E 4): E 4): E 4): E 4): E 4): E 4): E 4): E 4): E 4): E Longmai Public Material – May be reproduced only in its original entirety (without revision).

4): E 4): E 4): E G,W,Z G,W,Z G,W,Z G,W,Z G,E G,W,Z Longmai Public Material – May be reproduced only in its original entirety (without revision).

G,W,Z G,W,Z G,W,Z W,Z 4): E W,Z 4): E W,Z W,Z 4): E Longmai Public Material – May be reproduced only in its original entirety (without revision).

4): E W,Z 4): E 4): E 4): E 4): E Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

G,W,E,Z G,R,W,E, Z E G,W,Z G,W,Z G,W,E,Z G,R,W,E, Z E G,W,Z G,W,Z Table 14: Approved Services Note: “use” is a parameter to specify the usage of the private-public key pairs. Option 1 means signature generation and verification only, Option 2 means key wrapping only, and Option 3 means the key pair can be used for both signature generation and verification, and key wrapping which is not allowed in Approved mode. Longmai Public Material – May be reproduced only in its original entirety (without revision).

Note: For Getdata, authentication is required for tag ID 0x4000- 0XFFFF according to the “Read” access control of EF 3F01. The key attribute can identify the type of key, ID, number of retries, whether it is unmodified, etc. These attributes are not CSP or PSP. You cannot obtain the specific content of the key through the properties of the key, nor can you use (signature, verify, encrypt and decrypt) or clear the key through the properties of the key. For example： Retry time is 10 PIN value is 12345678 Through GetSecretKeyInfo you can get the ID and Retry, but can't get the PIN value. For details regarding service inputs, corresponding service outputs, status return codes and description of each service listed, please refer to section 4 of [APDU].

All Non-Approved services implemented by the Module are listed in the table below: Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 15: Non-Approved Services

NOTE: There is no External Software/Firmware Loaded.

The Module is composed of a single firmware component. The mToken CryptoID uses ECDSA P256(SHA2-256) for the integrity test of its firmware. ECDSA digital SigVer is an Approved algorithm that is provided by the module. The known digital signature value of the firmware is stored in the firmware binary. When the Module is powered-up, the Module will generate the SHA2-256 hash value of the firmware of the Module. Then use ECDSA P-256 to digitally verify the generated SHA2-256 hash value along with the stored digital signature. If this fails, the integrity test fails, and the Module enters the Error state.

The operator can initiate the integrity test on demand via the HealthCheck service. Longmai Public Material – May be reproduced only in its original entirety (without revision).

Type of Operational Environment: Non-Modifiable How Requirements are Satisfied [O]:

The Module operates in a non-modifiable operational environment and does not implement a General Purpose Operating System. Once the firmware of the Module is loaded on the mToken CryptoID, it cannot be modified or erased, firmware cannot be upgraded/updated. The operational environment requirements do not apply to the Module.

The Module’s enclosure, which surrounds the SCC-XE microcontroller, is made of fully hardened production grade polycarbonate (plastic) or metal. A colored polycarbonate or metal enclosure blocks the clear view of internal hardware components. There is a hard, non-malleable metal casing around the USB connector. The SCC-XE microcontroller is covered in a black, opaque, tamper resistant epoxy resin coating thus completely covering all critical components from visual inspection. Any attempt to remove or penetrate the enclosure is highly likely to cause serious damage to the Module and hardware components inside the enclosure, which will expose clear evidence of tampering. Removing the metal around the USB connector will cause physical damage to the USB connector and its related pins, making the entire cryptographic module inoperable. If evidence of tampering occurs, the Module should be returned to the issuer immediately to be destroyed. Once the cryptographic Module is powered off, all plaintext keys and unprotected CSPs will be zeroized. Table 16: Mechanisms and Actions Required

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

Table 17: EFP/EFT Information

Table 18: Hardness Testing Temperatures The Module was only tested at nominal room temperature.

The Module does not implement any mitigation method against non-invasive attacks. Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 19: Storage Areas D.G D.G Table 20: SSP Input-Output Methods Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 21: SSP Zeroization Methods

All usage of these SSPs by the Module are described in the services detailed in Section 4.3 Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

Table 22: SSP Table 1 Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

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

D.G D.G Table 23: SSP Table 2 Longmai Public Material – May be reproduced only in its original entirety (without revision).

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 requirements, these are categorized as either pre-operational self-tests or conditional self-tests. When the mToken CryptoID is powered on, the Pre-Operational self-tests are executed automatically without any operator intervention. If the Module completes the Pre-Operational self-tests successfully, the Module will enter either Approved Mode or Non-Approved Mode depending on the initial configuration of the Module by the Manufacturer or Distributor. If the Module enters approved mode, a steady green LED will be observed; if the module enters Non-Approved mode, a steady red LED will be which indicates that the Pre-Operational self-tests have completed successfully. If any Pre-Operational self-test fails, the Module enters into the Error state. All data output is prohibited, and no further cryptographic operation is allowed. The green LED will blink quickly (flashing every 200ms), and the module will return an error code to indicate that the Module is in the Error state. The on-demand self-tests can be invoked by the HealthCheck APDU command or by unplugging the token and plugging it back in to reinitiate the Pre-Operational self-tests. The Module logs the last self-test error which can be retrieved via the APDU command GetHealthStatus.

1. The Error log is stored on RAM, which records two types of errors: self-test error and error returned from module function interface. For detail error definition, please refer to the table description of STATUS CODE+ algorithm self-test status of “mToken CryptoID APDU Specification V1.4”.
2. Obtain the error log via 80 05 command. No interface exists to modify/delete error log. While executing the read command, requires check the module’s authority, if is not login status of authorized user (CO/USR), then return error 0x6982. Authorized user may obtain certain log records after verifying PIN. By default, this will return “0”, if there are no errors; otherwise, the latest error will be returned. The Module performs the following pre-operational self-tests in table below: Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 24: Pre-Operational Self-Tests Longmai Public Material – May be reproduced only in its original entirety (without revision).

The Module performs the following conditional self-tests in the table below: Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 25: Conditional Self-Tests Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 26: Pre-Operational Periodic Information Longmai Public Material – May be reproduced only in its original entirety (without revision).

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

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

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

Table 27: Conditional Periodic Information

Installation and Initialization: Physical access to the Module shall be limited to the Crypto-Officer, and the CO shall be responsible for putting the module into the Approved mode upon initialization. First time access to the mToken CryptoID requires the CO to connect to the module and perform the initialization steps via the Factory Tool. The following steps must be performed by the CO to securely install, initialize and start up the cryptographic module in the FIPS 140-3 Approved mode of operation: Longmai Public Material – May be reproduced only in its original entirety (without revision).

1. The Issuer should open the Factory Tool, click Find button then Connect if the connected module is listed on the drop-down list next to the Find button. Select FIPS Mode checkbox and then click FormatDevice to initialize the Module. The process of FormatDevice is to clear all CSPs and set the module to Approved Mode. At this point, the Module’s LED will flash Green which indicates the operation has been done successfully.
2. The Issuer needs to re-plug the Module to continue the setting. Repeat the Find then Connect step. To ensure module’s security, the default keys must be changed upon the first use, thus no further steps are allowed until the default keys are changed. The Issuer should be responsible for keeping the new keys secure.
3. The Issuer needs to input correct KEY_MC, then click ExternalAuth to perform the Key Auth of the CO role., Later click SecureMessageKAS to establish an encrypted connection to initialize the device.
4. The Issuer needs click InstallPin to install KEY_PIN of Admin and User. Admin PIN is "admin123" by default; User PIN is "12345678" by default.
5. The Issuer may click ChangeWorkingMode to switch the module to Approved Mode or Non-Approved Mode accordingly, but the prerequisite is that the CO role is authenticated. Startup Procedures The security rules for Module usage are listed below for the Crypto Officer and User roles: • SecureMessageKAS service is required to be used to establish a secure channel between the Module and the host application running on a GPC before requesting any service. • The operator should check the LED status indicator to determine the state of the Module. • The operators should logout when they finish using the Module to maintain secure usage of the module. The operators can logout by calling the ClearSecureState APDU command or by unplugging the module from the GPC. The security rules for Module usage are listed below for the Crypto Officer role: • When installing the KEY_MC and KEY_PIN, the “LeftRetryTimes” field is required to be set to fifteen (15) so that the Module will block the KEY_MC and KEY_PIN after fifteen (15) failed login attempts. • The default value of KEY_MC is defined and exchanged between the Manufacturer and the Distributor as part of the contract. It is the Issuer’s responsibility to change the default key immediately once he/she receives the module. The Issuer can use the ChangeSecretKey APDU command to change the KEY_MC. • The Issuer should call the GetData APDU command to ensure that the module is configured to operate in approved mode. If the module is not configured to operate in approved mode, the Issuer should refer to Section 2.5 “Modes of Operation” for instructions on how to configure the module to operate in approved mode. • The Manufacturer provides a secure delivery and distribution process to maintain the integrity of the module. The Distributor should inspect the exterior of the delivered package and the tamper tab on each box that contains the modules and confirm the basic information matching with the received modules. Please refer to document “mToken CryptoID Configuration Management Plan” for more information. The security rules for module usage are listed below for the User role: • The default values of KEY_PIN (i.e., Admin PIN and User PIN) are required to be securely delivered to the end user by the Distributor to maintain the integrity of the module. It is the end Longmai Public Material – May be reproduced only in its original entirety (without revision).

user’s responsibility to change the default KEY_PIN immediately once they receive the module. The end user can use the ChangeSecretKey APDU command to change the KEY_PIN. Delivery: The Module is shipped from the manufacturer without initialization to the Issuer (CO). The following steps must be performed to securely deliver the mToken CryptoID cryptographic Module to the authorized operator:

1. The CO shall receive the Module from Longmai via trusted couriers (e.g., United Parcel Service, Federal Express, etc.).
2. On receipt, the CO must inspect the delivered package for any tampering and if any signs of tampering are found, the CO should contact Longmai.

This Module needs to negotiate a pair of AES Keys (S_ENC and S_ENC) to allow authentication and secure initialization of the Module. All communications to initialize the Module will require a secure session using this key pair which will encrypt and authenticate all data input. During module initialization, the operator of the Module will only operate it in approved mode and provide only approved and allowed security functions. To confirm operation in the Approved Mode of Operation, the operator can use the “Get Data” APDU command. All communication of the module will require a secure session using the S_ENC and S_ENC for encrypting and MACing all data input and output. Operators shall maintain physical possession of the device until keys are zeroized successfully. In this way, the zeroization technique is performed in a time that will not allow the CSPs to be compromised.

The Admin and User role can’t initialize the device, install KEY_MC, KEY_IA, KEY_EA or KEY_PIN, and can’t change the work mode either. After the Admin and User role performs KEY_PIN authentication, it can create and delete CSP files such as public and private keys.

Rules of Operation

1. The Module provides three (3) distinct operator roles: Issuer (CO), Admin, and User.
2. The Module provides identity-based authentication.
3. The Module clears previous authentications on power cycle. Longmai Public Material – May be reproduced only in its original entirety (without revision).

4. An operator does not have access to any cryptographic services prior to assuming an authorized role.
5. The Module allows the operator to initiate pre-operational and conditional self-tests via command as well as restarting the Module.
6. Pre-Operational self-tests do not require any operator action.
7. Data output is inhibited during key generation, self-tests, zeroization, and error states.
8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
9. There are no restrictions on which keys or SSPs are zeroized by the zeroization service.
10. The Module does not support concurrent operators.
11. The Module does not support a maintenance interface or role.
12. The Module does not support a manual SSP establishment method.
13. The Module does not have any proprietary external input/output devices used for entry/output of data.
14. The Module does not enter or output plaintext CSPs.
15. The Module does not output intermediate key values.
16. The Module does not provide bypass services for ports/interfaces.

After the end-of-life, the operator should send the device back to the Issuer (CO). The CO should zeroize all SSPs using the “FormatDevice“ service followed by shredding the Module.

The Module implement the following mitigation methods against other attacks. Longmai Public Material – May be reproduced only in its original entirety (without revision).

References and Definitions The following standards may be referred to in this Security Policy. Table 29 - References Longmai Public Material – May be reproduced only in its original entirety (without revision).

Table 30

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

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