Zebra DCS Cryptographic Library

Certificate

Approved Algorithms (20)

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

flowchart LR
  %% Deterministic review-risk graph for Zebra DCS Cryptographic Library
  %% 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<br/>Firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output<br/>Show Status</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 DCS Cryptographic Library
  %% 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<br/>Firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output<br/>Show Status</i><br/>src: text:keyword"]
    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 DCS Cryptographic Library Firmware Module Firmware Versions: DAACUS00-002-R00 on Zebra CR6080 DAACWS00-002-R00 on Zebra CS6080 DAAHIS00-002-R00 on Zebra DS8288 DAAHGS00-002-R00 on Zebra CR8288 Documentation Version : 1.6 Last Update : October 20, 2025 This document may be freely distributed in its entirety without modification

1. General The Zebra DCS Cryptographic Library provides data encryption/decryption functionality to devices such as wireless barcode scanners and cradles. These devices are used in a variety of environments such as retail and manufacturing. Figure
2. Zebra CR6080 Cradle Figure
3. Zebra CS6080 Scanner Figure
4. Zebra DS8288 Scanner Figure
5. Zebra CR8288 Cradle

Figure

5. Zebra DS8178 Scanner and CR8178 Cradle Figure
6. Zebra DS3678 Scanner and STB3678 Cradle The module is a FIPS 140-3 compliance firmware module with a multi-chip standalone embodiment. The main purpose of the module is to encrypt/decrypt data. The following table indicates the actual security levels for each area of the cryptographic module. Table 1-1 Security Levels

The module has an overall security level of 1.

2. Cryptographic Module Specification The module was performed at Security Level
3. The following configurations were tested by the lab: Table 2-1 Tested Operational Environments Table 2-2 Vendor Affirmed 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. The table below lists approved cryptographic algorithms employed by the module: Table 2-3 Approved Algorithms Notes: • There are some algorithm modes that were tested but not used by the module. Only the algorithms, modes, and key sizes that are implemented by the module are shown in this table. • Algorithm Cert. #A1639 was tested for Zebra DCS Cryptographic Module running on Zebra Cradle

• Algorithm Cert. #A1640 was tested for Zebra DCS Cryptographic Module running on Zebra Scanner (Zebra CS6080) tested platform. • Algorithm Cert. #A6772 was tested for Zebra DCS Cryptographic Module running on Zebra Scanner (Zebra CS8288) tested platform. • Algorithm Cert. #A6773 was tested for Zebra DCS Cryptographic Module running on Zebra Cradle (Zebra CR8288) tested platform. Mode of Operation The module can only be operated in Approved mode of operation. The module does not support nonApproved algorithms or services. Block Diagram Figure 5 below depicts the module’s Block Diagram. Please note that the bold RED rectangle in the block diagram represents the Tested Operational Environment’s Physical Perimeter (TOEPP) containing the Module (the thin RED rectangle). Tested Operational Environment’s Physical Perimeter (TOEPP) Operating System Zebra DCS Cryptographic Library (DAACWS00-002-R00.DAL/DAACUS00-002-R00.DAL/DAAHIS00-002R00.DAL/DAAHGS00-002-R00.DAL) Figure

7. Module Block Diagram
8. Cryptographic Module Interfaces The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2-1. 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. Table 3-1 Ports and Interfaces

4. Roles, Services and Authentication The module supports Crypto Officer (CO). The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based Table 4-2 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as:

• R = Read: The module reads the CSP. The read access is typically performed before the module uses the CSP.
• E = Execute: The module executes using the CSP.

• W = Write: The module writes the CSP. The write access is typically performed after a CSP is imported into the module, when the module generates a CSP, or when the module overwrites an existing CSP.
• Z = Zeroize: The module zeroizes the CSP. Table 4-2 Approved Services

Integrity Techniques The module is provided in the form of binary executable code. To ensure the firmware security, the module is protected by HMAC-SHA2-256 (HMAC Certs. #A1639, #A1640, #A6772 or #A6773) algorithm. The Firmware Integrity Test Key (non-SSP) was pre-loaded to the module’s binary the factory and used for firmware integrity test only at the pre-operational self-test. At Module’s initialization, the integrity of the runtime executable is verified using a HMAC-SHA2-256 digest which is compared to a value computed at build time. If at the load time the MAC does not match the stored, known MAC value, the module would enter to an Error state with all crypto functionality inhibited. The firmware module was saved in the Flash memory in the DAL format. The module also supports the firmware load test by using HMAC-SHA2-256 (HMAC Certs. #A1639, #A1640, #A6772 or #A6773) algorithm. The Firmware Load Test Key was pre-loaded to the module’s binary the factory and used for firmware load test. The operator can update the module’s firmware upon successful verification, the module will load the new update upon reboot. The update attempt will be rejected if the verification fails. Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at poweron. The operator can power-cycle or reboot the tested platform to initiate the firmware integrity test on-

6. Operational Environment The module is operated in limited operational environment per FIPS 140-3 level 1 specifications. The operating system is restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded), no other settings or restrictions to the operational environment are required. The application that makes calls to the modules is the single user of the modules, even when the application is serving multiple clients. The module’s firmware version running on each tested platform is detailed below. • DAACUS00-002-R00 on Zebra CR6080/CR8178/STB3678 • DAACWS00-002-R00 on Zebra CS6080/DS8178/DS3678 • DAAHIS00-002-R00 on Zebra DS8288 • DAAHGS00-002-R00 on Zebra CR8288
7. Physical Security The module is running on the multi-chip standalone production grade platform to meet physical security requirements from FIPS 140-3 level
8. The module’s Tested Operational Environment’s Physical Perimeter (TEOPP) is drawn at the casing of the tested platform (Zebra CS6080. Zebra CR6080, Zebra CS8288 or Zebra CR8288). The module’s tested platforms consist of production-grade components. All ICs are coated with industry standard passivation.
9. Non-invasive Security The module does not support Non-invasive Security. Thus, the security requirements from Section Noninvasive Security in FIPS 140-3 are not applicable.
10. Sensitive Security Parameter Management Table 9-1 SSPs

10. Self-Tests. When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs preoperational 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 would perform and pass the pre-operational self-tests. A firmware integrity test is performed on the runtime image of the HMAC-SHA2-256 Cryptographic Algorithm Self-test (CAST). If the CAST on the HMAC-SHA2-256 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value pre-computed at compilation time. Following the successful pre-operational self-tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs) for all approved cryptographic algorithms implemented by the module during power-up as well.

The self-test success (return code ‘0’) or failure (return code ‘-5’) is output as a return value of the library load API call, which is functioning as the self-test status indicator. If one of the self-tests fails, the module transitions into an error state with the return code ‘-5’ output from 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. ❖ Pre-Operational Self-Tests:

• Pre-operational firmware integrity test
• HMAC-SHA2-256 KAT
• Firmware Integrity Test (using HMAC-SHA2-256) ❖ Conditional Self-Tests.
• Conditional cryptographic algorithm tests
• AES-CBC with 256 bits Encryption Know Answer Test (KAT)
• AES-CBC with 256 bits Decryption KAT
• AES-KWP with 256 bits Encryption KAT
• AES-KWP with 256 bits Decryption KAT
• HMAC-SHA2-256 with 256 bits KAT
• SHA2-256 KAT Please note that the module conducts all CASTs successfully prior to the first operational use of the cryptographic algorithm.
• Conditional firmware load test
• Firmware Load Test (HMAC-SHA2-256) 11. Life-cycle Assurance The module always runs in the Approved Mode of Operation and does not implement any Non-Approved Security Functions. The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-

General Guidance

1. The validated module’s firmware binary files, DAACUS00-002-R00.dal (on Zebra CR6080/CR8178/STB3678). DAACWS00-002-R00.dal (on Zebra CS6080/DS8178/DS3678), DAAHIS00-002-R00.dal (on Zebra DS8288), or DAAHGS00-002-R00.dal (on Zebra CR8288), was installed into the respective tested platform (Table 2-1) while being manufactured.
2. The module is provided directly to Zebra solution developers and is not available for direct download or purchase by the general public.
3. To initialize the module, the operator needs to power on the tested platform.
4. The module is operated in a limited Operational Environment and only supports single user operator. The module provides one operator role: Crypto Officer

5. The module does not support concurrent operators.
6. The module does not support a maintenance interface or role.
7. The module does not have any external input/output devices used for entry/output of data.
8. The module does not output the plaintext CSPs.
9. The module does not output intermediate key values.
10. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module.
11. The Crypto Officer shall load the FIPS 140-3 validated firmware only to maintain validation.
12. Please conduct the periodic self-tests no more than 30 days (i.e., once/month) in order to avoid any conditions that may result in the interruption of the module’s operations.
13. Mitigation of Other Attacks The module does not support Mitigation of Other Attacks. Thus, the security requirements from Section Mitigation of Other Attacks in FIPS 140-3 are not applicable.