| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Firmware |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 3/26/2029 |
| Caveat | None |
| Vendor | Zebra Technologies Corporation |
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;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
| # | Section | Page |
|---|
Figure
The module has an overall security level of 1.
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 CAVP Cert Algorithm and Mode/ Description/Key Use/Function Standard Method Size(s) / Key strength(s) AES Certs. #A1639, AES AES-CBC 256 bits Data #A1640, #A6772 and [FIPS 197] encryption/decryption A6773 AES Certs. #A1639, AES AES-ECB 256 bits Prerequisite algorithm and #A1640, #A6772 [FIPS 197] for AES-KWP and A6773 KTS (AES Certs. AES-KWP AES-KWP 256 bits Key wrapping #A1639, and [SP800-38F] #A1640, #A6772 and A6773) HMAC Certs. HMAC HMAC- 256 bits Firmware integrity and #A1639, #A1640, [FIPS 198-1] SHA2-256 Firmware load test A6772 and A6773 (MAC: 256 Key Length: 256) SHS Certs. #A1639, SHS SHA2-256 N/A Hash operation #A1640, A6772 and [FIPS 180-4] (Message A6773 Length: 065528 Increment 8) Notes:
• 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
N/A Control Output N/A Interface N/A Status Output Return values from firmware API commands used to obtain Interface information on the status of the module. The Status Output Interface also includes the log file where the module messages are output. 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 on the service requested. The module provides the following services to the Crypto Officer. Table 4-1 Roles, Service Commands, Input and Output Role Service Input Output Crypto Officer Run pre-operational and Commands to initiate the pre- Self-Tests conditional self-tests operational or conditional self-tests Pass/Fail status code Crypto Officer Show Status Commands to check the module’s Status output code status Crypto Officer Set AES Encryption Key Commands to set AES Encryption Success or error Key status code Crypto Officer Set Shared Key (Current) Commands to set Shared Key Success or error (Current) status code Crypto Officer Set Shared Key (Default) Commands to set Shared Key Success or error (Default) status code Crypto Officer Wrap/Unwrap AES Commands to wrap/unwrap AES Success or error Encryption Key Encryption Key with Shared Key status code (Current) or Shared Key (Default) Crypto Officer Wrap/Unwrap Shared Key Commands to wrap/unwrap Shared Success or error (Current) Key (Current) with Shared Key status code (Default) Crypto Officer Protect Data using AES Commands to encrypt and decrypt Encrypted data or Encryption Key the data with AES Encryption Key error status code Crypto Officer Zeroize Commands to conduct zeroization All SSPs were zeroized with “0”s Crypto Officer Conduct Firmware Integrity Command to conduct the Firmware Success or error Test Integrity Test Crypto Officer Conduct Firmware Load Test Command to conduct the Firmware Success or error Load Test Crypto Officer Show Version Command to get Firmware version Firmware version 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:
Service Description Approved Keys Roles Access Indicator Security and/or Rights to Functions SSPs SSPs Zeroize Zeroize all Keys N/A All keys Crypto Z Zeroization and CSPs upon Officer status demand or output request via the API Zeroization function. Conduct Firmware Check Firmware HMAC- Firmware Crypto R, E Success or Integrity Test Integrity SHA2-256 Integrity Officer error code Message Test Key Authentication (non-SSP) Code (MAC) during the firmware integrity test Conduct Firmware Check MAC HMAC- Firmware Crypto R, E Success or Load Test during the SHA2-256 Load Test Officer error code firmware load Key test Show Version Get version of N/A N/A Crypto N/A N/A the current Officer Firmware 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-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 On-Demand 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 ondemand.
Key/SSP/ Strengt Security Generatio Import/ Establis Storage Zeroizat Use & Name h Function n Export hment ion related Type and Cert. keys Shared Key by Access (Current); Key) Export: No Shared 256 bits AES-ECB; N/A Imported to N/A Stored in Assume Used for Key AES-KWP; the module the tested the CO wrapping or (Default) in platform’s role, and unwrapping Certs. plaintext; Flash (key call the AES #A1639, store) in zeroizati Encryption #A1640, Export: No ciphertext on API Key or #A6772, (encrypted function Shared Key and by Access (Current) #A6773 Key) Shared 256 bits AES-ECB; N/A Imported to MD/EE Stored in Assume Used for Key AES-KWP; the module the tested the CO wrapping or (Current) in platform’s role, and unwrapping Certs. ciphertext Flash (key call the AES #A1639, wrapped store) in zeroizati Encryption #A1640, with ciphertext on API Key #A6772, Shared Key (encrypted function and (Default); by Access #A6773 Key) Export: No Firmware 256 bits HMAC- Pre-loaded Import: No N/A Stored in N/A User for Load Test SHA2-256 at the tested Firmware Key factory (in Export: No platform’s load test Certs. the Flash #A1639, module’s (executable #A1640, executable binary #A6772, binary) image) in and plaintext #A6773 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 module with HMAC-SHA2-256 algorithm. Prior to the firmware integrity test, the module conducts a 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:
General Guidance