MFP Cryptographic Module (B)

Certificate

Approved Algorithms (31)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for MFP Cryptographic Module (B)
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>Boot Firmware Version: 0x00010000, Main Firmware…</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Monotonic Counter Increment</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-Test<br/>XTS-shell Enable<br/>Status Check</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C1 --> I1 --> R1 --> E1
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C1,C2,C3,C5,C6 clue;
  class I1,I2,I3,I5,I6 infer;
  class R1,R2,R3,R5,R6 risk;
  class E1,E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for MFP Cryptographic Module (B)
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>Boot Firmware Version: 0x00010000, Main Firmware…</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Monotonic Counter Increment</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-Test<br/>XTS-shell Enable<br/>Status Check</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C1,C2,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

MFP Cryptographic Module(B) KYOCERA Document Solutions Inc. MFP Cryptographic Module (B) Version: 1.1 Prepared by: KYOCERA Document Solutions Inc. 1-2-28 Tamatsukuri Chuo-ku Osaka, Osaka 540-8585 Japan +81-6-6764-3355 https://www.kyoceradocumentsolutions.com/

MFP Cryptographic Module(B) Table of Contents 1. 1.1. 1.2. 1.3. 1.2. 1.5. 2. 2.1. 2.2. 2.3. 2.4. 2.5. 3. 4. 4.1. 4.2. 5. 6. 7. 8. 9. 9.1. 9.2. 10. 10.1. 10.1.1. 10.2. 10.2.1. 10.2.2. 11. 11.1. 11.2. 12.

1.1. Introduction This is a non-proprietary Cryptographic Module Security Policy for the MFP Cryptographic Module (B). Notice. This Security Policy describes how the module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian government requirements for cryptographic modules. More information about the FIPS 140-3 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Communications Security Establishment (CSE) Cryptographic Module Validation Program (CMVP) website at https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program. This policy was prepared as part of the Level 2 FIPS 140-3 validation of the module. The MFP Cryptographic Module (B) is referred to as the module in this document. The individual clause levels and overall level are listed in the table below. Table 1-1 Security Levels N/A N/A 1.2. N/A The module is intended to meet requirements of FIPS 140-3 at an overall Security Level 2. Table 1-1 shows the security level claimed for each of the twelve sections that comprise the validation. “Operational 1.3. Purpose There are three major reasons that a security policy is required

MFP Cryptographic Module(B)

• It is required for FIPS 140-3 validation.
• It allows individuals and organizations to determine whether the implemented module satisfies the stated security policy.
• It allows individuals and organizations to determine whether the described capabilities, the level of protection, and access rights provided by the cryptographic module meet their security requirements. 1.2. Target Audience This document is a part of the package of documents that are submitted for FIPS 140-3 conformance validation of the module. It is intended for the following people: ・Developers working on the release ・FIPS 140-3 testing lab ・Cryptographic Module Validation Program (CMVP) 1.5. Additional References [FIPS 140-3] Security Requirements for Cryptographic Modules, https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf, 2019 [FIPS 140-3 IG] Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS%20140-3%20IG.pdf, 2021 [SP800-90A Rev.1] Recommendation for Random Number Generation Using Deterministic Random Bit Generators, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf, 2015 [SP 800-90B] Recommendation for the Entropy Sources Used for Random Bit Generation, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf, 2018 [SP 800-38A] Recommendation for Block Cipher Modes of Operation: Methods and Techniques, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf, 2001 [SP 800-38B] Recommendation for Block Cipher Modes of Operation: the CMAC Mode for Authentication, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf, 2016 [SP 800-38D] Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf, 2007 [SP 800-38F] Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf, 2012

MFP Cryptographic Module(B) [SP 800-56A Rev. 3] Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf, 2018 [SP 800-56C Rev. 1] Recommendation for Key-Derivation Methods in Key-Establishment Schemes, https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr1.pdf, 2018 [SP 800-108] Recommendation for Key Derivation Using Pseudorandom Functions (Revised), https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf, 2009 [FIPS 198-1] The Keyed-Hash Message Authentication Code (HMAC), https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf, 2008 [FIPS 197] Advanced Encryption Standard (AES), https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf, 2001 [FIPS 180-4] Secure Hash Standard (SHS), https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf, 2015

2.1. Module Description MFP Cryptographic Module(B) is a cryptographic security chip for encrypting data written to a storage device and other security functions of Kyocera multifunction printer. The module is a hardware cryptographic module implemented as a sub-chip system running on a singlechip standalone processor and is classified as a sub-chip cryptographic subsystem contained within a single chip embodiment for the purpose of FIPS 140-3 validation. The module is identified by three points: that it is implemented in the Kyocera SCH134 SoC (System-On-Chip), Hardware Version and Firmware Table 2-1 Cryptographic Module Tested Configuration N/A There are four kinds of packages of the chip (the Kyocera SCH134). Four kinds of opaque packages of the chip are shown in the figures below.

MFP Cryptographic Module(B) Figure 2-1 Module Seal Application Locations

• package A Figure 2-2 Module Seal Application Locations
• package B Figure 2-3 Module Seal Application Locations
• package C

MFP Cryptographic Module(B) Figure 2-4 Module Seal Application Locations

• package D

MFP Cryptographic Module(B) 2.2. Cryptographic Module Boundary The module was tested as a sub-chip cryptographic subsystem implemented in the Kyocera SCH134 SoC. The following figure shows the block diagram of SCH134 and the module. Power In Data In Res Req AXI4 Crypto Engine Data Out NDRNG Status Out SRAM ROM Interrupt Signal Registers/Interrupts Processing System Req Data/Control In Res APB4 Microcontroller Mailbox Data/Status Out MFP Cryptographic Module (B) Data Out NVM IF Data In Logical Boundary Req Res OTP Data In Req XTS-shell IF Data Out Res XTS-shell : Requester Port Res : Responder Port Req Physical Boundary Figure 2-5 MFP Cryptography Module (B) Block Diagram The physical boundary of the module is the physical boundary of SCH134. Consequently, the embodiment of the module is a single-chip cryptographic module. The cryptographic boundary of the module is the MFP Cryptographic Module (B). The module is classified as a single-chip hardware module for the purpose of FIPS 140-3 validation. SRAM in the Figure 2-1 is referred to as “the SRAM” and OTP in the Figure 2-1 is

MFP Cryptographic Module(B) referred to as “the OTP” in the rest of this document. Boot firmware which is for initialization and loading main firmware is located in ROM. Boot firmware and main firmware are referred to as “ROM Firmware” and “RAM Firmware” respectively in the rest of this document. 2.3. Approved, Allowed or Vendor Affirmed Security Functions The following table shows the approved or allowed security functions used in the module. No nonapproved security functions or vendor affirmed security functions are performed in the module. Table 2-2 Approved Algorithms C.H

*1: AES-XTS key is parsed as the concatenation of two AES key, denoted by Key_1 and Key_2, that are 256 bits long. The module checks whether Key_1 ≠ Key_2. If there is no difference between Key_1 and Key_2, the module returns an error code. *2: The module supports 2 modes for AES-GCM Encryption IV listed in the table below. Here, AES-GCM *3: V is a string binary zeros, then B = U (i.e., the output of an approved RBG). 2.4. Modes of Operation The module only supports approved mode of operation and only supports approved and allowed security functions. No other modes of operation and security functions are implemented by the module. Therefore, when the module is powered up and successfully completes pre-operational self-test and cryptographic algorithm tests, the module enters the approved mode of operation. When the approved mode, the configuration ID indicates 0x2. The configuration ID is specified by the initialization procedure. Details of the initialization procedure are described in chapter 11.

MFP Cryptographic Module(B) 2.5. Rules of Module operation The module is an embedded security subsystem within the Kyocera SCH134 SoC. No user installation or maintenance is required. This section describes operations based on security rules.

1. This module executes the self-tests by turning on the power supply or releasing the reset.
2. If the self-test is successful, the authentication process will be executed upon command input from the Crypto Officer.
3. After the authentication process is completed successfully, the firmware will be loaded from external memory, transitioning to a state where general commands (such as encryption commands and authentication commands) can be executed.
4. If an error occurs in any state, the module will transition to the Error state. In the Error state, no commands will be accepted. To exit this state, it is needed to perform a power cycle or apply a reset.5. AES-XTS can only be used for storage. The other sections of this document provide additional details on the design of the module and rules for its operation.

MFP Cryptographic Module(B) 3. Cryptographic Module Interfaces The module supports interfaces listed in the table below. Table 3-1 Interfaces

MFP Cryptographic Module(B) The “Mailbox over APB” means access to the Mailbox via APB4 shown in Figure 2-1. The mailbox consists of the SRAM and is used for command/data input and data output. The “DMA IF over AXI” means access from the Crypto Engine via AXI4 in Figure 2-1. Basically, the module is controlled by command input via the mailbox but interrupt related control is done by registers. The module does not implement a control output interface.

MFP Cryptographic Module(B) 4. Roles, Services, and Authentication 4.1. Roles and Authentication The module supports two roles: a Crypto Officer and a User. The Crypto Officer is basically for module setup and initialization. The User is for general cryptographic services. Table 4-1 lists all operator roles supported by the module and their related services. Table 4-1 Roles, Service Commands, Input and Output

MFP Cryptographic Module(B) *Key Wrap Key is AES-GCM Key which is 256-bits. All roles authenticate to the module using identity-based authentication. The Crypto Officer and the User are authenticated using the ID and password (a 32-bit password). In addition, a 256-bit ECDSA signature and ID is used to authenticate the Crypto Officer role by the Authentication CO service. Table 4-1 lists the roles supported by the module, the authentication methods, and the strengths of the authentication mechanism.

MFP Cryptographic Module(B) Table 4-2 Roles and Authentication

MFP Cryptographic Module(B) 4.2. Services The module supports services following table shows. All services require authentication except for SelfTest, Status Check, Version Check and CFG-ID Check. The following table lists services implemented by the module along with their description. Table 4-3 Approved Services X E R X X E X X E

MFP Cryptographic Module(B) X X E G X X E

1. N/A X X yQ2=xQ3+axQ+b
2. X X G W E

MFP Cryptographic Module(B) X Z In the following table, lists of type of access to SSPs are shown. The access types to SSPs are denoted as follows:

• ‘E’: the item is used for executing for the service.

MFP Cryptographic Module(B)

5. Software/Firmware Security 5.1. Integrity Techniques The module verifies the integrity of the ROM Firmware before executes one. 32-bit CRC check is used for the technique of integrity check. Also, the integrity check of RAM Firmware, which is located in the memory outside of the module, is performed by verifying the ECDSA signature. 5.2. On-Demand Integrity Test The ROM Firmware integrity tests can be performed with the reset applied, and RAM Firmware integrity tests can be performed with the Authentication CO service, which is the service that loads the RAM firmware for the module.
6. Operational Environment The module is a limited operational environment.

MFP Cryptographic Module(B) The module is implemented in silicon as part of the Kyocera SCH134 SoC. The chip is enclosed by an opaque package which prevents unauthorized physical access to the chip. There are four kinds of packages of the chip. The module consists of production-grade components that include standard passivation techniques. The following table lists requirement to maintain the physical security. Four kinds of opaque packages of the chip are shown in the figures below. Figure 7-1 Module Seal Application Locations

• package A

MFP Cryptographic Module(B) Figure 7-2 Module Seal Application Locations

• package B Figure 7-3 Module Seal Application Locations
• package C Figure 7-4 Module Seal Application Locations
• package D 8. Non-invasive Security Not Applicable.

MFP Cryptographic Module(B) 9. Sensitive Security Parameter Management 9.1. Sensitive Security Parameters The following table summarizes the strength, generation, import, export, storage, zeroization and uses of Keys and SSPs that are used by the cryptographic services implemented in the module. Table 9-1 SSPs -

MFP Cryptographic Module(B) HMACSHA2025 KYOCERA Document Solutions Inc. Page 38

MFP Cryptographic Module(B) 9.2. Random Number Generation The module uses the HASH_DRBG for following purposes.: Generation a random number which is output by Random Number Generation service, Generation Key Derive key, Generation ECDSA and ECDH Private Key, Generation AES-GCM Encryption IV used as KTS, and Generation a secret random number for use the signature generation process of ECDSA and RSA-PSS. The inputs to the HASH_DRBG, that is the entropy input and the nonce input, are random bits which are collected from the ENT that consists of a series of ring oscillators. The ENT specification is listed in the table below. The minimum size of the entropy input and nonce input is 256 bits and 0 bits respectively. Therefore, in this case, Min-entropy of the seed (the entropy and the nonce) is approximately 183-bits (=

256 * 0.75) at least. The module generates SSPs whose strengths are modified by available entropy.

However, it is recommended that the size of the nonce is more than half of the entropy input (i.e., more than 128-bits) as security cushion. In this case, approximately 288-bits of security strength is provided for the HASH_DRBG at least. Table 9-2 Non-Deterministic Random Number Generator Specification

MFP Cryptographic Module(B) 10. Self-Tests 10.1. Pre-operational self-tests Pre-operational self-tests consist of integrity tests. Pre-operational self-tests are specified individually for 10.1.1. Integrity Tests The following table shows the list of integrity tests that is part of the pre-operational self-test of the Table 10-1 Integrity Test If the integrity test fails, the module enters the Error state. When command result bit 31 is 1, it indicates an error due to the integrity test failure, and the return value of the Status Check service is 0x00008000 10.2. Conditional Self-Tests The module performs conditional self-tests. Conditional self-tests consist of the cryptographic algorithm tests and the other tests. 10.2.1. Cryptographic Algorithm Tests The cryptographic algorithm tests for ROM Firmware can be performed by applying the reset, and the cryptographic algorithm test for RAM Firmware except for AES-XTS encryption/decryption KAT can be performed by successfully loading the firmware in Authentication CO service. AES-XTS encryption/decryption KAT can be performed by invoking XTS-shell enable service when the XTS-shell is disabled. Table 10-2 Cryptographic Algorithm Test for ROM Firmware Table 10-3 Cryptographic Algorithm Test for RAM Firmware

MFP Cryptographic Module(B) Table 10-4 AES-XTS Cryptographic Algorithm Test for RAM Firmware If KAT fails, the module enters the Error state. When command result bit 31 is 1, it indicates an error due to KAT failure, and the return value of Status Check service is 0x00008000 indicating the Error state. 10.2.2. Other Conditional Self-Tests The conditional self-tests are performed in the following cases. (1) When firmware load service is executed ECDSA Signature Verification with ECDSA P-256 as Firmware load test for the loaded firmware image is performed. If the Firmware load test fails, the module enters the Error state. The error code of 0x80000020 or 0x80000022 indicates an error due to a public key hash digest mismatch or a signature verification failure, respectively. (2) When Random Number Generator Configuration service is executed A Repetition Count Test (RCT) and an Adaptive Proportion Test (APT) are performed as a startup health-test, whenever the DRBG is seeded. If RCT or APT fails, the module enters the Error state. The error code being 0x8000002c indicates an error due to startup health-test failure.

MFP Cryptographic Module(B) (3) When key derivation service is executed for ECDSA and ECDH A pair-wise consistency test on asymmetric keys generated for either ECDSA or ECDH is performed. If the conditional self-test fails, the module enters the pairwise consistency test error state. Error code being 0x80000026 indicates an error due to the pairwise consistency test failure.

MFP Cryptographic Module(B) 11. Life-cycle Assurance 11.1. Crypto Officer Guidance The following descriptions are the services for startup the module, which are invoked by Crypto Officer. Assumptions regarding user behavior that is relevant to the secure operation of the module are described in Section 11.2. Delivery and Installation The module in the silicon chip manufactured by the vendor is delivered thorough a trusted delivery courier. When the administrator receives the chip, they shall check whether the package is disclosed or not before installation. Initialization Procedure The initialization procedure is referred to as Provisioning. If Provisioning has not been invoked yet, the administrator shall initialize the module. Initialization service is invoked only one time. In Provisioning, the module authenticates the administrator with default Crypto Officer ID and Password, and administrator shall update Crypto Officer ID and Password and enter followings.

• Hash calculated value of Public Key to verify signature to be used in Authentication CO service Provisioning can be invoked on ROM firmware only. Provisioning shall be operated appropriately under the control of the administrator without third party intervention. The administrator shall monitor the chip while the operation of Provisioning. Authentication CO and Firmware Load If Provisioning has been already invoked, Crypto Officer shall get Crypto Officer Password and load RAM Firmware stored in the memory where is out of the module by Authentication CO service. Firmware Load can be performed as a part of Authentication CO service. Crypto Officer shall specify the data included whole RAM Firmware as the target message in ECDSA signature that is verified by Authentication CO service. Load has been performed, then Self-Test is executed by the module with RAM Firmware. After Self-Test has been succeeded, Crypto Officer shall get Crypto Officer Password by Authentication CO service. Key Zeroisation To prevent to output any data while key is zeroizing, XTS-shell disable service shall be invoked before Delete Key service, Delete All Keys service and Clear OTP service performs. Sanitization When a dealer collects a product to be disposed of, all sensitive information (such as SSP) shall be zeroised by Delete All Keys service and then the module shall be handed over to designated disposal contractor for their disposal.

MFP Cryptographic Module(B) 11.2. User Guidance ● The Shared Secret which is output of Export Key service shall be managed properly by a user. ● In order to meet the FIPS 140-3 IG 2.3.B requirement, a user shall not input any keys in plaintext, if those are input directly from outside of the cryptographic physical boundary. ● If AES-GCM IVs are deterministically generated by the module using the protocol such as TLS, IPsec and MACsec, a user shall generate the IV to meet the requirement per the FIPS140-3 IG C.H. Case

1. In this case, the IVs shall be constructed in compliance with the provisions of a peerto-peer industry standard protocol. And if the IVs are generated regardless of the protocols, the IVs shall be generated as required per IG C.H. Case
2. In this case, the 96 bits IV provided from inside of the Kyocera SCH134 SoC but the outside of the module shall include an encoding of the module name. The name field shall allow for at least 232 different names. ● The size of the nonce that is input to the HASH_DRBG should be more than half of the size of the entropy input.
3. Mitigation of Other Attacks The module has not been designed to mitigate any specific attacks outside the scope of FIPS 140-3 requirements.

Referenced URLs

• https://www.kyoceradocumentsolutions.com/
• https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf
• https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-
• 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/Legacy/SP/nistspecialpublication800-38a.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38b.pdf
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.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-56Cr1.pdf
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.198-1.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf