FUJIFILM BI Cryptographic Kernel Module for WRL

Certificate

Approved Algorithms (27)

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

flowchart LR
  %% Deterministic review-risk graph for FUJIFILM BI Cryptographic Kernel Module for WRL
  %% 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>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for FUJIFILM BI Cryptographic Kernel Module for WRL
  %% 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>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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,C6 clueLow;

Security Policy, page by page

Document Version 1.0.0 FUJIFILM BI Cryptographic Kernel Module for WRL Software version: 1.2.L9A57 / 1.1.L6A15

1.1. Overview The FUJIFILM BI Cryptographic Kernel Module for WRL (Wind River Linux) meets the overall (module). The primary purpose of the Module is to provide encryption/decryption of data. 1.2. Security Levels The module meets the security level 1 requirements for the applicable sections documented within ISO/IEC 19790 Section 7 as shown in Table 1. Table 1 - Security Levels

2. Cryptographic Module Specification 2.1. Description The FUJIFILM BI Cryptographic Kernel Module for WRL is an object file used to extend the kernel of the WRL. Purpose: The primary purpose of the FUJIFILM BI Cryptographic Kernel Module for WRL is to provide encryption/decryption of data for multifunction devices. Module Type: The module is defined as a software module (refer to ISO/IEC 19790, Section 7.2.2). Embodiment: The module and operating environment (OE) are defined as a multi-chip standalone module. Module Characteristics: The module comprises a single, kernel object file built for WRL6 and WRL9 respectively. No assurance of minimum security of SSPs (e.g., keys, bit strings) that are externally loaded, or of SSPs established with externally loaded SSPs. Cryptographic Boundary: The cryptographic boundary is defined as the FUJIFILM BI Cryptographic Kernel Module for WRL. The boundary encompasses the entire monolithic object file: − wrl6_fips_1403_module.ko on Wind River Linux 6 − wrl9_fips_1403_module.ko on Wind River Linux 9 2.1.1. TOEPP & Cryptographic Boundary The block diagram in Figure 1 depicts the module’s cryptographic boundary and Tested Operational Environment’s Physical Perimeter (TOEPP) and dataflows.

Figure 1 - Cryptographic Boundary 2.2. Tested & Vendor Affirmed Module Version and Identification The FUJIFILM BI Cryptographic Kernel Module for WRL is a software cryptographic module developed to meet the requirements of FIPS 140-3 Security Level 1 (refer to Table 1). The module is built according to its underlying OE (i.e., Wind River Linux 6 or Wind River Linux 9). Table 2 – Tested Module Identification 2.2.1. Tested Operational Environments The module has been tested on the operating environments shown below in Table 3. Table 3 - Tested Operational Environments N.B. There are no vendor affirmed operating environments.

2.3. Excluded Components The module does not exclude any components from the requirements of FIPS 140-3. 2.4. Modes of Operation The module is designed to continually operate in an approved mode of operation. There are no undefined or ‘non-approved’ modes or services within the module. By default, the approved mode is entered into when successfully powering on the module. If the module does not successfully initialize it transitions to its error state. N.B. The module does not incorporate a degraded mode of operation (refer to ISO/IEC 19790 Section 7.2.4.3). 2.5. Algorithms 2.5.1. Approved Algorithms The FUJIFILM BI Cryptographic Kernel Module for WRL supports the approved cryptographic algorithms shown in Table 4. Table 4 - Approved Algorithms

Algorithm

Caveat

Use/Function

Algorithm

Caveat

Use/Function

Algorithm

Caveat

Use/Function

Algorithm

Caveat

Use/Function

Name

Type

Description

SF Properties

Algorithms / CAVP Cert.

2.5.2. Vendor Affirmed Algorithms The module does not implement any Vendor Affirmed algorithms. Table 5

• Vendor Affirmed Algorithms N/A N/A N/A 2.5.3. Non-Approved Algorithms The module does not implement any non-approved algorithms. Table 6
• Non-Approved, Allowed Algorithms N/A N/A N/A 2.5.4. Non-Approved, Allowed Algorithms with No Security Claimed The module does not implement any non-approved algorithms. Table 7
• Non-Approved, Allowed Algorithms N/A N/A N/A 2.5.5. Non-Approved, Allowed Algorithms with No Security Claimed The module does not implement any non-approved algorithms. Table 8
• Non-Approved, Not Allowed Algorithms N/A N/A N/A 2.6. Security Function Implementation (SFI) Table 9
• Security Function Implementation N/A N/A N/A N/A N/A 2.7. Algorithm Specific Information The module utilizes only approved algorithms that are tested and validated under the Cryptographic Module Validation Program (CMVP): − AES per FIPS 197, NIST SP 800-38A and SP 800-38E

− HMAC per FIPS 198-1 − SHS per FIPS 180-4 2.8. RBG [Random Bit Generator] and Entropy The module does not support a random bit generator (RBG) or an entropy source for the generation of cryptographic keys. 2.9. Key Generation The module does not support the generation of cryptographic keys or key material. 2.10. Key Establishment The module does not support key establishment techniques. 2.11. Industry Protocols The module is not reliant on any specific industry protocols.

3. Cryptographic Module Interfaces 3.1. Ports and Interfaces The physical ports for the module are the same as the multifunction devices on which it is executing. The logical interface is a C-language application program interface (API) through which applications request services. Table 10 summarizes the logical interfaces that the module supports. Table 10 - Ports and Interfaces N/A Status Output Module status As a software module, control of the physical ports is outside module scope. However, when the module is performing self-tests, or is in an error state, all output on the data output interface is inhibited. The module is single-threaded and in error scenarios returns only an error value (no data output is returned).

Role

Authentication Method

Authentication Strength

4. Roles, Services, and Authentication 4.1. Authentication Methods The module does not implement any authentication methods. 4.2. Roles The module supports two distinct operator roles: Crypto-Officer (CO) role and User role. The CO and User roles are implicitly assumed by the entity accessing the services implemented by the module. Only one role can be active at a time and the module does not allow concurrent operators. The module does not support a Maintenance role. Table 11 - Roles, Service Commands, Input and Output User Show Status N/A Status User Show Module Info N/A Module name, Module version Table 12 - Roles and Authentication

4.3. Approved Services Table 13 defines the relationship between SSP access modes and module services. The access modes shown in Table 13 are defined as follows: −     G:          Generate: The module generates or derives the SSP. −     R:          Read: The SSP is read from the module. −     W:          Write: The SSP is updated, imported, or written to the module. −     E:          Execute: The module uses the SSP in performing a cryptographic operation. −     Z:          Zeroise: The module zeroises the SSP. Table 13 – Approved Service The zeroization service is performed under the following conditions: -       Automatic zeroization is performed when deallocating structure or when the system is powered off. -       Keys are zeroized when destroying the appropriate context object.

Name

Description

Algorithms Accessed

Role

Indicator

4.4. Non-Approved Services The module does not implement any Non-Approved Services. Table 14 – Non-Approved Services N/A N/A N/A N/A N/A 4.5. External Software Loading The module does not support the loading of software from external sources. 4.6. Additional Information 1. The operator shall be capable of commanding the module for WRL to perform the powerup self-test on demand by performing the Initialization service or by re-loading the module with rmmod/insmod commands.

5. Software Security 5.1. Integrity Techniques The module performs the HMAC-SHA-1 (128-bit key) software integrity test on power-up automatically. 5.2. Initiate on Demand The operator can perform the test on demand by performing the Initialization service or by reloading the module with rmmod/insmod commands. Please refer to Section 10 for integrity test details.
6. Operational Environment 6.1. Operational Environment Type & Requirements The module’s operational environments (OEs) include − Wind River Linux 6 running on an ARM Cortex A15 tested on FFBI Clipper8 hardware platform and − Wind River Linux 9 running on ARM Cortex A57 tested on FFBI Palacios2 K502 hardware platform. These OEs are defined as modifiable operational environments. There is no restriction to the configuration of it. The tested operating systems segregate user processes into separate process spaces. Each process space is logically separated from all other processes by the operating system software and hardware. The module functions entirely within the process space of the calling application.
7. Physical Security Physical Security requirements are not applicable, as the module is a FIPS 140-3 Security Level

8. Non-invasive Security The module was not designed to mitigate non-invasive attacks. Therefore, this section is not applicable.

9. Sensitive Security Parameters (SSPs) Management 9.1. Storage Areas All SSPs are stored ephemerally in random access memory (RAM). 9.2. SSP Input-Output Methods The module is passed cryptographic keys in plaintext by the calling application. The module does not output any SSPs. 9.3. SSP Zeroization Methods SSPs are not persistently stored. During normal operation, the module explicitly erases copies of SSPs in volatile memory (e.g., RAM) by overwriting with zeros after their use. 9.4. SSPs The following SSPs are included in the FUJIFILM BI Cryptographic Kernel Module for WRL. Keys are not generated, or established, output. Keys are accessed from calling applications’ software within the General-Purpose Computer (GPC) that the module is installed on. Zeroization is performed by the Zeroization service.

10. Self-Tests The module performs the self-tests described in Tables 16 & 17 on power-up. All KATs must be completed successfully prior to any use of cryptography by the module. If one of the KATs fails, the module transitions to its error state. 10.1. Pre-Operational Self-Tests The module implements both pre-operational and conditional self-tests. Since the pre-operational the SHA-1 and HMAC-SHA1 KATs for the conditional self-tests are invoked prior to the software Table 16 - Pre-Operational Self-Tests binary. 10.2. Conditional Self-Tests The FUJIFILM BI Cryptographic Kernel Module for WRL shall perform the following tests: Table 17 –Self-Test

10.3. Periodic Self-Tests The FUJIFILM BI Cryptographic Kernel Module for WRL performs all self-tests on power-up automatically. The module can be reloaded to perform all the self-tests on demand. 10.4. Error States The module includes a defined error state in which it enters upon the failure of self-tests. Table 18 - Error States restarted. 10.5. Operator Initiation of Self-Tests The module allows the operator initiation of self-tests. The module can be reloaded to perform all 11. Life-cycle Assurance 11.1. Installation, Initialization & Startup Procedures This section will describe the configuration management used for the FUJIFILM BI Cryptographic

Kernel Module for WRL. The FUJIFILM BI Cryptographic Kernel Module for WRL is built and installed into the mobile device together with Wind River® Linux operating system by employees of FUJIFILM Business Innovation or subcontractors in a factory. Therefore, the module is delivered to User together with the mobile device and is not done in stand-alone form. 11.2. Administrator Guidance The CO's responsibility for the secure operation of the module is the correct installation of the module into the device. The module shall be installed through the following procedure: i. Reboot target device. ii. Install the module using the ‘insmod’ command. iii. Check the module information is correct and matches the Security Policy. When stopping employing the module, the CO should detach the module. Each buffer where SSPs are stored is zeroized immediately after processing, so CO does not have to perform the zeroization again. 11.3. Non-Administrator Guidance A User is an entity that utilizes the module’s cryptographic services. All the module operations must be performed via the module’s API. The User must pass into the module the necessary SSPs for each security function. The User’s responsibility for the secure operation of the module is to ensure that the module name and version match those indicated in the Security Policy before using the module. 11.4. Design and Rules The following security design and the rules of operation are applicable to the module: − The module shall be installed only on either Wind River Linux 6 with ARM Cortex A15 or Wind River Linux 9 on ARM Cortex A57. − The operator shall verify the correct version of software is installed by using the ‘Show Module Info’ service. − The module shall operate only in an approved mode of operation. − The module shall incorporate only approved algorithms validated under the cryptographic module validation program (CAVP). − The module shall not support concurrent operators. − The module shall not support a bypass mode or bypass capability. − The module shall not support a maintenance mode of operation.

Other Attack

Mitigation Mechanism

Specific Limitations

− The module shall not output cryptographic keys or key material. − The module shall not support the generation of cryptographic keys or key material. − The module shall not exclude any components from the requirement of FIPS 140-3 Security Level 1. − The module shall only use AES-XTS for data at rest (i.e. for storage applications). − The module shall not support a self-initiated cryptographic output capability. − No assurance of minimum security of SSPs (e.g., keys, bit strings) that are externally loaded, or of SSPs established with externally loaded SSPs. 12. Mitigation of Other Attacks The FUJIFILM BI Cryptographic Kernel Module for WRL was not designed to mitigate other attacks outside of the specific scope of FIPS 140-3. Therefore, this section is not applicable. Table 19 – Mitigation of Other Attacks N/A N/A N/A

13. Definitions and Acronyms Table 20 – Definitions and Acronyms XTS XEX Tweakable Block Ciphertext Stealing