X5 Postal Security Device (PSD)

Certificate

Approved Algorithms (13)

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

flowchart LR
  %% Deterministic review-risk graph for X5 Postal Security Device (PSD)
  %% 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/>Rollback<br/>recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>status output</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>bootloader<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 X5 Postal Security Device (PSD)
  %% 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/>Rollback<br/>recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>status output</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>bootloader<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

Pitney Bowes, Inc. X5 Postal Security Device (PSD) Version 1.0 This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document defines the Security Policy for the Pitney Bowes, Inc. (PB) X5 Postal Security Device (PSD) cryptographic module, hereafter “the module”. The physical form of the module is depicted in Figure 1. The module is a single-chip embodiment as defined by FIPS 140-3 and conforms to Security Level 3.

The module meets the overall requirements of FIPS 140-3 Security Level 3. Table 1: Security Levels

The X5 Postal Security Device (PSD) is a single-chip (hardware) cryptographic module designed by PB to conform with FIPS 140-3 Security Level 3 requirements. The module provides cryptographic services to a host device (i.e., Digital Postage Meter), to support postage evidence in the form of an indicium. A PSD provides protection that includes ensuring the secrecy of critical security parameters (CSPs) such as cryptographic keys and providing data This document may be freely reproduced and distributed, but only in its entirety and without modification.

integrity protection for funds relevant data items (FRDIs 1) such as accounting data. CSPs and FRDIs reside inside the strong physical protection of the PSD. Figure 1 – X5 Postal Security Device (PSD) Purpose and Use: The module is designed to function as a postal security device. Postal security devices act as the core security component within postage evidencing systems (PES). Module Type: The module is defined as hardware module (refer to ISO/IEC 19790, Section 7.2.2). Module Embodiment: The module is defined as a single-chip cryptographic module. Module Characteristics: The critical components within the module are encapsulated within a single, integrated circuit. Cryptographic Boundary: The module’s cryptographic boundary is defined as the IC package that comprises the Maxim Integrated MAX32590 DeepCover Secure Microcontroller.

1 FRDIs are not applicable to FIPS 140-3 and are not CSPs. The FRDIs’ authenticity and integrity are critical for

postal functionality, and they should never be zeroized. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module is designed to meet the requirements of FIPS 140-3 Security Level 3 (refer to Table 1). The module is available in the following configuration (refer to Table 2): Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware N.B. The module versioning can be verified using the ‘Get Module Versions’ command which returns the module’s hardware ID (00000005) and firmware versions. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: This document may be freely reproduced and distributed, but only in its entirety and without modification.

N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

Modes List and Description: The module only supports an Approved and non-Approved mode of operation. The module provides an explicit mode of operation indicator: the ‘Approved mode status flag’ is returned in every response from the module. The Approved Mode Status Flag is set to zero when a service utilizes an approved cryptographic algorithm, security function or process in an approved manner or to one for non-Approved cryptographic algorithms, security functions or process in a non-approved manner. The module’s mode of operation can only be configured within manufacturing. Once configured, the module does not have the ability to change modes. Table 3: Modes List and Description

The module supports the approved cryptographic algorithms shown in Table 4. Approved Algorithms: The module supports the following approved cryptographic algorithms. Table 4: Approved Algorithms

2 Key sizes 128 and 192 are included in the algorithm certificate, but are not used in Approved mode.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

3 Key sizes 128 and 192 are included in the algorithm certificate, but are not used in Approved mode.

4 Key sizes 128 and 192 are included in the algorithm certificate, but are not used in Approved mode.

5 RSA PKCS1 v1.5 and ANSI X9.31 are not used by the module in Approved mode. Only the modulus size of

This document may be freely reproduced and distributed, but only in its entirety and without modification.

Vendor-Affirmed Algorithms: The module supports the following vendor affirmed algorithms in accordance with IG D.H (refer to Table 5). Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: The following cryptographic algorithms are used solely in a non-Approved mode of operation (this includes specified CAVP-validated algorithms). There exists no mechanism to allow the use of these algorithms in an Approved mode of operation. Table 6 – FIPS Non-Approved, Not Allowed Algorithms This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 7: Security Function Implementations This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module utilizes only approved algorithms that are tested and validated under the Cryptographic Algorithm Validation Program (CAVP).

The module incorporates a NIST SP 800-90A Hash-DRBG (Cert. #A2436) that is seeded with 512 bits of entropy and a 512-bit nonce from an external source during manufacturing of the module. The unmodified output of the DRBG is used for generating cryptographic key material or random nonces. Given that the entropy is imported from outside the device, there is no assurance of the minimum strength of generated SSPs. The module generates symmetric cryptographic keys in conformance with NIST SP 800-133r2 using a NIST SP 80090A conforming DRBG (Cert. #A5176) for the encryption and protection of data and cryptographic keys. The module generates asymmetric cryptographic key pairs in conformance with FIPS 186-5 for the verification of digital signatures, or for the facilitation of key agreement in conformance with NIST SP 800-56ar3.

The module supports the establishment of cryptographic keys using elliptic curve cryptography (ECC) in conformance with NIST SP 800-56ar3 and IG D.F – Scenario #2. The module implements KAS-ECC-SSC per NIST SP 800-56A Rev3 (Cert. #A2439), used in conjunction with KDA per NIST SP 800-56Cr1 (Cert. #A2439). Key establishment methodology provides at least 128 bits of encryption strength. This is used to establish secure communication sessions. The module also incorporates KTS in conformance with NIST SP 800-38F using AES-KW (Cert. #A2435), or when using AES-CBC (Cert. #A2435) with HMAC-SHA2-256 (Cert. #A2438).

The module relies upon the standard USB and other serial protocols for communication with general purpose computer (GPC) systems. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module incorporates physical ports and logical interfaces. The MAX32590 is supplied in a 324-pin Ball Grid Array (BGA) package where all power input, data input, data output, control input, and status output interfaces are supported. The module does not support a control output interface. The physical ports are defined within Table 8 below: Table 8: Ports and Interfaces This document may be freely reproduced and distributed, but only in its entirety and without modification.

separate authentication methods as indicated in Table 9.

Table 10: Roles The module does not support concurrent operators. Only one operator is allowed to access the device at any time. Operator authentication does not persist beyond power-cycling the module. The selection of roles is implicit. This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

The non-Approved Mode of the module implements the same roles and services as the Approved Mode of operations, but this mode also allows the use of the algorithms specified in Section 2.10. This document may be freely reproduced and distributed, but only in its entirety and without modification.

There is no complete image replacement process. New firmware may be downloaded by the module for the country-specific postal application. The postal application firmware is signed by PB, with an ECDSA P-256 digital signature. On downloading, the device verifies the firmware digital signature.

The module includes the following firmware components that include separate firmware integrity tests: − Bootloader: RSA 2048 Digital Signature Verification (RSA, Cert. #A2440) − Postal Application Firmware: ECDSA P-256 Digital Signature Verification (ECDSA, Cert. #A2437) The module will transition to its error state upon the failure of either firmware integrity test.

Self-tests may be initiated on demand by power cycling the module (‘Reboot PSD’) or invoking the ‘Perform Diagnostic Test’ or ‘Perform Full Diagnostics’ services.

Type of Operational Environment: Limited How Requirements are Satisfied: The module does not contain a modifiable operational environment. The module’s operational environment is limited. The module includes a firmware load service to support necessary updates. Firmware versions validated through the FIPS 140-3 CMVP will be explicitly identified on a validation certificate. Any firmware not identified in this Security Policy does not constitute the module defined by this Security Policy or covered by this validation. This document may be freely reproduced and distributed, but only in its entirety and without modification.

The device includes automatic tamper detection and response. CSPs are zeroized automatically and immediately upon a tamper event being detected. On detection of a tamper event, the device is to be returned to PB. Table 13: Mechanisms and Actions Required extremes (refer to Table 14). Table 14: EFP/EFT Information

The module has been tested at the operational, storage and distribution temperatures listed in Table 15. The module’s epoxy hardness is assured within these ranges. Table 15: Hardness Testing Temperatures This document may be freely reproduced and distributed, but only in its entirety and without modification.

The module does not provide protections against non-invasive security methods.

The module supports both volatile and persistent storage of SSPs. Table 16: Storage Areas

Table 17: SSP Input-Output Methods

The zeroization methods described within Table 18 are supported by the module. Zeroization services explicitly overwrite SSPs with zero values. This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 18: SSP Zeroization Methods This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 19: SSP Table 1 This document may be freely reproduced and distributed, but only in its entirety and without modification.

Table 20: SSP Table 2 This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

The following pre-operational tests are performed upon power-up, on-demand and periodically. Prior to the PreOperational firmware integrity self-tests being performed, the module performs the required known answer test (KAT) on the implementation. Table 21: Pre-Operational Self-Tests The module also includes critical function tests that test the real time clock (RTC) and BRAM.

The following conditional tests are performed upon power-up, on-demand and periodically. Table 22: Conditional Self-Tests This document may be freely reproduced and distributed, but only in its entirety and without modification.

This document may be freely reproduced and distributed, but only in its entirety and without modification.

The pre-operational and conditional algorithm self-tests are also automatically run on a periodic basis every 24 hrs. Table 23: Pre-Operational Periodic Information Table 24: Conditional Periodic Information This document may be freely reproduced and distributed, but only in its entirety and without modification.

ERROR STATES The module incorporates a single error state (refer to Table 25). Table 25: Error States

Self-tests may be triggered by the user on demand by power cycling the module (‘Reboot PSD’) or invoking the ‘Perform Diagnostic Test’ or ‘Perform Full Diagnostics’ services, which allows either individual or all tests to be run.

There are no specific maintenance requirements.

The module is initialized within PB manufacturing and installed into a PB manufactured PES. The PES is authorized and shipped to an end customer.

The device will only be provided to or retrieved from PB customers as part of a postage evidencing system. Administration guidance, in the form of API definitions, exists for PB engineers involved in the development of PES equipment.

The device will only be provided to customers as part of a postage meter. Any user guidance will be provided as part of that equipment.

The following security rules are enforced by the cryptographic module to ensure the FIPS 140-3 security requirements are met. This document may be freely reproduced and distributed, but only in its entirety and without modification.

1. The module must support an Approved and non-Approved mode of operation. The Approved mode indicator must be returned to the end user.
2. The module must not allow unauthenticated operators to have any access to the module’s cryptographic services.
3. The module must inhibit data output during self-tests, firmware load, zeroization and error states.
4. The module must logically disconnect data output from the processes performing zeroization and key generation.
5. The module must enforce identity-based authentication.
6. The module must not retain the authentication of an operator following power-off or reboot.
7. The module must support the following roles: Cryptographic Officer and User.
8. The module must not permit the input or output of plaintext cryptographic keys or other CSPs.
9. The module must not support a bypass mode or maintenance mode.
10. The module must not support the following logically distinct interfaces: − Data input interface − Data output interface − Control input interface − Status output interface − Power interface.
11. The module must protect critical security parameters from unauthorized disclosure, modification and substitution.
12. The module must perform power-on, on-demand and periodic self-testing.
13. The module must log errors whenever an error state is entered.
14. The module must not perform any cryptographic functions while in an error state.
15. The module must not support multiple concurrent operators.

Once a module is no longer needed by a customer, they will walk through a process called withdrawal and return the PSD to PB where an operator will perform the “re-initialize” operation, zeroizing the KEK. Once a module has been zeroized, it must be returned to the factory for software loading and parameterizing prior to being usable by a customer.

The module is not purposefully designed to mitigate any attacks beyond the scope of FIPS 140-3 requirements. This document may be freely reproduced and distributed, but only in its entirety and without modification.