Zebra 8887 Cryptographic Module

Certificate

Approved Algorithms (4)

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

flowchart LR
  %% Deterministic review-risk graph for Zebra 8887 Cryptographic Module
  %% 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<br/>self-test</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["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 Zebra 8887 Cryptographic Module
  %% 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<br/>self-test</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C6 clueLow;

Security Policy, page by page

Zebra Technologies Corporation Non-Proprietary FIPS 140-3 Security Policy For Zebra 8887 Cryptographic Module Firmware-Hybrid Module HW ID:9134 Firmware Versions: FIPS Driver Firmware Version 2.1 and NXP Firmware Version 15.68.19.p59 Documentation Version 1.1 Last Update: June 18, 2024 Zebra Technologies Public Material

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

1. General This document defines the Security Policy for Zebra 8887 Cryptographic Module from Zebra Technologies Corporation; hereinafter referred to as the Module. The module resides in the wireless LAN (WLAN) data plane of several Zebra Technologies devices. The Module meets FIPS 140-3 overall Level 1 requirements. The module is intended for use by US Federal agencies and other markets that require FIPS 140-3 validated Zebra devices. The below table indicates the individual cause levels and over levels. ISO/IEC 24759 Section 6 FIPS 140-3 Section Titles Security Level [Number Below]

1 General 1

2 Cryptographic Module Specification 1

3 Cryptographic Module Ports and Interfaces 1

4 Roles, Services, and Authentication 1

5 Software/Firmware security 1

6 Operational environment 1

7 Physical Security 1

8 Non-invasive security N/A

9 Sensitive security parameter management 1

10 Self-Tests 1

11 Life-cycle assurance 1

12 Mitigation of Other Attacks N/A

Overall Level Security Level 1 Table 1 - Security Levels The module has an overall security level of 1. 2. Cryptographic Module Specification The module is a multi-chip standalone Firmware-hybrid module. The module’s cryptographic boundary includes the NXP 88W8887 CPU and the driver firmware providing the interface to the 88W8887 CPU. The module’s cryptographic boundary includes the following components: Component Type FW/HW Version Module’s Firmware Component: Zebra WLAN Library running Firmware FW: FIPS driver FIPS driver firmware binary file: devnp-mv8887-fips.so Firmware Version 2.1 Module’s Firmware Component: Zebra WLAN Core running Firmware FW: NXP Firmware NXP firmware binary file: sd8887_uapsta.bin Version 15.68.19.p59 Module’s Hardware Component: Zebra WLAN Core Hardware HW ID: 9134 Table 2

• Module’s HW/FW Components Zebra Technologies Public Material
• May be reproduced only in its original entirety (without revision).

The module has been tested on the following platforms: # Operating System Hardware Platform Processor PAA/Acceleration

1 QNX 7.0.4 Zebra ZQ521 Printer NXP i.MX 6ULL ARM Cortex-A7 None

and NXP ARMv5TE Table 3

• Tested Operational Environments The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Modes of Operation By design, the module can only support approved mode of operation and does not implement any NonApproved Security Functions. The module does not claim the implementation of a degraded mode of operation. The table below lists all approved security functions of the module, including specific key size(s) -in bits unless otherwise noted- employed for approved services, and implemented modes of operation. There are some algorithm modes that were tested but not implemented by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in this table. CAVP Algorithm and Mode/Method Description/Key Use/Function Standard Size(s) / Key Strenth(s) A1146 AES AES-ECB 128 bits Prerequisite algorithms for [FIPS 197; SP800-38A] AES-CCM A1146 AES AES-CCM 128 bits Authenticated Symmetric [FIPS 197; SP 800-38C] Encryption/Decryption A2718 HMAC HMAC-SHA-1 160 bits Keyed Hash. Used in [FIPS 198-1] Firmware Integrity Check A2718 SHS SHA-1 N/A Prerequisite algorithm of [FIPS 180-4] HMAC-SHA-1 Table 4
• Approved Algorithms As the module can only be operated in the Approved mode of operation, and any algorithms not listed in table 4 above will be rejected by the module while in the approved mode, the tables defined in SP800140B for the following categories are missing from this document.
• Non-Approved Algorithms Allowed in Approved Mode of Operation
• Non-Approved Algorithms Allowed in Approved Mode of Operation with No Security Claimed
• Non-Approved Algorithms Not Allowed in Approved Mode of Operation Zebra Technologies Public Material
• May be reproduced only in its original entirety (without revision).

Cryptographic Boundary The module is defined as a multi-chip standalone Firmware-hybrid module (thin red line area), with the boundary of the Tested Operational Environment’s Physical Perimeter (TOEPP) being defined as the physical perimeter of the tested platform enclosure around which everything runs. Figure 1 - Module’s Hardware Component (Zebra WLAN Core) Figure 2

• Block Diagram Zebra Technologies Public Material
• May be reproduced only in its original entirety (without revision).

3. Cryptographic Module Interfaces The module’s physical perimeter encompasses the case of the tested platform mentioned in Table
4. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data input, data output, control input, control output and status output) as follows. Physical Port Logical Interface Data that passes over port/interface SDIO Interface Data Input Arguments for an API call that provide the data to be used of processed by the module. SDIO Interface Data Output Arguments output from an API call. SDIO Interface Control Input Arguments for an API call used to control and configure module operation. The control input interface also includes the registry values used to control module behavior. SDIO Interface Status Output Returns values from firmware API commands used to obtain information on the status of the module. The status output interface also includes the log files where the module messages are output. N/A Control Output N/A Power Interface N/A Module’s hardware component power supply. Table 5 – Ports and Interfaces
5. Roles, Services, and Authentication The module supports Crypto Officer (CO) role. The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services to the Crypto Officer role. Role Service Input Output Cryptographic Self-tests Command to conduct self-tests Status of self-tests Officer (CO) Cryptographic Show Status Command to check status Module’s current status Officer (CO) Cryptographic Show Version Command to read module’s version Module’s name/ID and Officer (CO) versioning information Cryptographic Load Key Command to set key Updated key message Officer (CO) Cryptographic Encrypt/Decrypt Command to conduct the encryption Encrypted or Decrypted Officer (CO) and decryption operation message Cryptographic Zeroize Command to zeroize all SSPs Key zeroize message Officer (CO) Table 6 – Roles, Service Commands, Input and Output Zebra Technologies Public Material – May be reproduced only in its original entirety (without revision).

The table below lists all approved services that can be used in the approved mode of operation. The abbreviations of the access rights to keys and SSPs have the following interpretation: 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 = Zeroize: The module zeroizes the SSP. N/A = The service does not access any SSP during its operation. Access Approved Keys rights to Service Description Security and/or Roles Keys Indicator Functions SSPs and/or SSPs Self-tests Perform cryptographic AES-ECB; Firmware CO N/A Self-Tests algorithm self-tests via AES-CCM; Integrity completion power cycle or API HMAC- Test Key status log command SHA-1; (non-SSP) message SHA-1; Show Show cryptographic module N/A N/A CO N/A N/A status status Show Show module’s name/ID N/A N/A CO N/A N/A version and versioning information Load key Load cryptographic key N/A AES Key CO W Key Load completion log message Encrypt / Perform AES-CCM AES-ECB; AES Key CO R, E Encryption or Decrypt generation/verification AES-CCM; Decryption completion message Zeroize Zeroize all CSP’s contained N/A All SSPs CO Z Zeroization in memory completion message Table 7

• Approved Services 5. Software/Firmware security Integrity Techniques The module is provided in the form of binary executable code. To ensure the firmware security, the module is protected by HMAC-SHA-1 (HMAC Cert. #A2718) algorithm. The firmware integrity test key (non-SSP) was preloaded to the module’s binary at the factory and used for firmware integrity test only at Zebra Technologies Public Material
• May be reproduced only in its original entirety (without revision).

the pre-operational self-test. At module initialization, the HMAC value is recalculated and compared to the hardcoded build-time generated MAC value. If at load time the signature does not match, the crypto module library exits with error. If at any point the integrity checks or known answer test fails, the module will go into an error state and will not be useable until the module is power cycled, and the integrity checks and known answer tests are run again. Integrity Test On-Demand While the integrity test is performed as part of the Pre-Operational Self Tests, the operator can also run the on-demand tests at any time using the API or by power cycling the device.

6. Operational Environment The module operates QNX 7.0.4, which is a non-modifiable operational environment installed on a generic operating platform (e.g., printer). The firmware driver component of the module is loaded onto the embedded OS prior to deployment to the end user. The QNX 7.0 embedded operating system runs in single operator mode only. The module has been tested on QNX 7.0 running on a Zebra ZQ521 printer with i.MX6ULL CPU.
7. Physical Security The module’s physical boundary is drawn at the casing of the tested operational platform (Zebra ZQ521 printer). The physical components that comprise the module are production grade. All ICs are coated with industry standard passivation.
8. Non-Invasive Security The module does not claim any non-invasive security.
9. Sensitive Security Parameters Management The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module. Key / Stren Security Gener Import / Establish Storage Zeroization Use & SSP gth Function ation Export -ment related Name and Cert. keys / Type # AES 128 AES-ECB; N/A Import: N/A Module API Used to Key bits AES-CCM; This key is Hardware Zeroization protect entered Component’s function module’s into the RAM wireless Cert. # module via radio A1146 API within data GPC’s INT pathways in plaintext Export: No Table 8 – SSPs Zebra Technologies Public Material – May be reproduced only in its original entirety (without revision).

10. Self-Tests When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs pre-operational self-tests. The operating system is responsible for the initialization process and loading of the library. The module is designed with a default entry point (DEP) which ensures that the self-tests are initiated automatically when the module is loaded. Prior to the module providing any data output via the data output interface, the module performs and passes the pre-operational self-tests. Following the successful pre-operational self-tests, the module executes the Conditional Cryptographic Algorithm Selftests (CASTs). The self-test success or failure results are an output of the return value of the library load API call, which is functioning as the self-test status indicator. If any one of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state. Below are the details of the self-tests conducted by the module.
11. Pre-Operational Self-Tests: • Pre-operational Firmware Integrity Test o HMAC-SHA-1 KAT o SHA-1 KAT o Firmware Integrity Test (HMA-SHA-1)
12. Conditional Self-Test: • Conditional Cryptographic Algorithm Self-Tests (CASTs) o AES-ECB 128 bits Encrypt KAT o AES-ECB 128 bits Decrypt KAT o AES-CCM 128 bits Authenticated Encrypt KAT o AES-CCM 128 bits Authenticated Decrypt KAT o HMAC-SHA-1 KAT o SHA-1 KAT
13. Life-Cycle Assurance Secure Operation The validated firmware binary files, including the Zebra 8887 FIPS driver firmware binary file: devnpmv8887-fips.so, and the NXP firmware binary file: sd8887_uapsta.bin, were loaded/installed into the module while being manufactured, and cannot be updated by the operator. The module is enabled by default (and hence used automatically) as part of the device without any user configuration. The module always runs in the Approved Mode of Operation and does not implement any Non-Approved Security Functions. When the module is instantiated (after being powered off, rebooted, etc.), the module runs pre-operational self-tests without any operator intervention. The Module will be operated in an approved mode of operation when pre-operational self-tests have completed successfully. The module is provided directly to solution developers and is not intended for direct download by the general public. Zebra Technologies Public Material – May be reproduced only in its original entirety (without revision).

The module supports a Crypto Officer role only. The module provides no authentication. When the module has not been placed in a valid role, the operator shall not have access to any cryptographic services. The operator shall be capable of commanding the module to perform the power up self-tests by cycling power or resetting the module. Power-up self-tests do not require any operator action. Data output shall be inhibited during self-tests, zeroization, and error states. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. There are no restrictions on which keys or CSPs are zeroized by the zeroization service. The module does not support concurrent operators. The module does not support a maintenance interface or role. The module does not support manual key entry. The module does not have any external input/output devices used for entry/output of data. The module does not output plaintext CSPs. The module does not output intermediate key values. 12. Mitigation of Other Attacks The module has not been designed to mitigate any specific attacks outside the scope of FIPS 140-3 requirements. Zebra Technologies Public Material

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