Christie IMB-S4 4K Integrated Media Block (IMB)

Certificate

Approved Algorithms (3)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Christie IMB-S4 4K Integrated Media Block (IMB)
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Digital Signature<br/>Secure Hash<br/>Upgrade</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Get Module Information<br/>Get Status<br/>Perform Self-test (power cycle)</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>Ingest USB</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>no library/version identified</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
  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?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  C5 --> I5 --> R5 --> E5
  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,C4,C5 clue;
  class I2,I3,I4,I5 infer;
  class R2,R3,R4,R5 risk;
  class E2,E3,E4,E5 evidence;

flowchart LR
  %% Deterministic clue tier for Christie IMB-S4 4K Integrated Media Block (IMB)
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Digital Signature<br/>Secure Hash<br/>Upgrade</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Get Module Information<br/>Get Status<br/>Perform Self-test (power cycle)</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>Ingest USB</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>no library/version identified</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,C4 clueHigh;
  class C5 clueLow;

Security Policy, page by page

Christie Digital Systems Canada Inc. Christie IMB-S4 4K Integrated Media Block (IMB)

This document is the Cryptographic Module Security Policy for the Christie IMB-S4 4K Integrated Media Block (IMB) (also referred to herein as the Christie IMB-S4, the cryptographic module, or simply the module). This policy is a specification of the security rules under which the Christie IMB-S4 operates and meets the requirements of FIPS 140-3 Level 2.

Purpose and Use: The Christie IMB-S4 is a multi-chip embedded cryptographic module. The IMB-S4 enables playback of encrypted cinema content packaged as an industry standard Digital Cinema Package (DCP). The IMB-S4 supports playback of digital cinema content from on-board storage (SSDs) as well as a network attached storage (NAS) device. Module Type: Hardware Module Embodiment: MultiChipEmbed Module Characteristics: Cryptographic Boundary: The illustrations below indicate the cryptographic boundary and the physical ports defined on the boundary.

Cryptographic Boundary Security Enclosure S4-Power Battery 1 Battery 2 SSD M.2 NAS SYNC In S4-Data Service Door LED FIPS Storage LED LEDs Aux Audio SYNC Out Media Figure 1 Top View of Christie IMB-S4 LTC Out Ingest USB AES3 Audio

Cryptographic Boundary DAD (not used) Figure 2 Bottom View of Christie IMB-S4 The cryptographic boundary is the outer physical perimeter of the module’s PCB board as represented by the blue boundary in the above photos.

Cryptographic Boundary Aux Audio Projector I/O (S4-Data) (latent

• reserved for future use) Sync Out Video SERDES (S4-Data) (latent
• reserved for future use) Sync In Aux SERDES (S4-Data) (latent
• reserved for future use) Carrier FPGA DAD LTC (latent
• reserved for future use) AES3 Audio Storage LEDs Ingest USB SSDs M.2 Ethernet (S4-Data) IMB CPU NAS FIPS LED Service Door LED Marriage (S4-Data) Data Input Data Output Control Input Control Output Status Output Power Service Door (S4-Data) Security Monitor Battery 1&2 S4-Power Figure 3 Block Diagram

Tested Module Identification

• Hardware: 000-20169901 1.0.05494@a Table 2: Tested Module Identification
• Hardware N/A

The Get Module Information approved service listed in section 4.3 Approved Services can be Specifically, each item is mapped to: Table 3 Get Module Information Service Response Fields

The following components are outside the security enclosure and are non-security relevant. Table 4 Excluded Components Modes List and Description: NonApproved NonApproved Table 5: Modes List and Description As per FIPS 140-3 IG 2.4.A, the non-approved mode services of the module do not share, access, nor use any SSP used by the module in approved mode of operation. The SSPs used by the “Upgrade” service are not used in non-approved mode.

Mode Change Instructions and Status: The module enters the approved mode of operation immediately after the self-test is completed. The module enters the non-approved mode of operation as soon as the first non-approved service is called. The module can transition from non-approved to approved mode by rebooting the module and letting the self-test complete.

Approved Algorithms: Table 6: Approved Algorithms Vendor-Affirmed Algorithms: N/A for this module. 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: Table 7: Non-Approved, Not Allowed Algorithms

Table 8: Security Function Implementations

As per FIPS 140-3 IG C.K, the module supports a FIPS 186-4 algorithm (RSA 2048 SigVer) that was tested in 2019 prior to the Feb 5, 2024, transition. The FIPS 186-4 CAVP test (RSA 2048 SigVer) is mathematically identical to FIPS 186-5 CAVP tests (RSA 2048 SigVer), therefore this module will claim FIPS 186-5 compliance for this test (RSA 2048 SigVer). Please also note that the SHA-1 algorithm has a transition date of December 31st, 2030. SHA-1 will be disallowed for applying cryptographic protection effective January 1st, 2031.

N/A for this module. N/A for this module.

N/A N/A N/A N/A Table 9: Ports and Interfaces

Table 10: Authentication Methods Authentication for the Ethernet Control Input Interface is accomplished via identity-based

Run preoperational Ethernet (S4Data) Z Table 12: Approved Services As per FIPS 140-3 IG 2.4.C, module supports a separate indicator per approved security service. HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant)

DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) HMAC (noncompliant) DRBG (noncompliant) Table 13: Non-Approved Services

Any firmware loaded into this module that is not shown on the module certificate, is out of scope of this validation and requires a separate FIPS 140-3 validation. Loading of External Firmware is performed through the Upgrade Service via the Crypto Officer role. Unauthorized firmware loading is not possible. Additionally, all firmware is digitally signed and checked as per section 5. Data Output and Control Output is inhibited during firmware load testing. The module also prevents firmware loading during any Data Output and/or Control Output operations. During firmware loading, requests for other services involving Data Output and/or Control Output are prohibited until firmware load is complete and the module is restarted. The module implements partial image replacement since there is a BIOS firmware component that is not upgradeable in the field and can only be modified by Christie at Christie’s secure facility.

The integrity of the module is verified by comparing the SHA2-256 (SHS Cert. # A4665) value of the firmware calculated at the time of construction of the firmware, with the SHA2-256 value of the currently running firmware. This is performed as part of the Pre-Operational Self-Tests. Please note the SHA2-256 implementation will perform a Cryptographic Algorithm Self-Test using a Known Answer Test, prior to performing the firmware integrity test.

The operator can initiate firmware integrity test by power-cycling the module.

The module operates in a limited operational environment that only allows the loading of a trusted and validated firmware binary image through an authenticated service. Firmware binary images are signed by an RSA key which is part of the Christie certificate chain. Type of Operational Environment: Limited

Table 14: Mechanisms and Actions Required The Christie IMB-S4 is a multi-chip embedded cryptographic module which is composed of production-grade components. The module satisfies Security Level 2 only for physical security. Figure 4 Physical Security Mechanisms

The physical security mechanisms of the module include a hard, opaque and tamper-evident metal security enclosure. The module includes four tamper evident seals (Figure 4 Physical Security Mechanisms) covering the screws that secure the metal enclosure to the module; said tamper evident seals are installed as part of the manufacturing process and shall not be removed (i.e. maintenance role is not supported, maintenance interface is not supported). The tamper evident metal security enclosure and the tamper-evident seals shall be periodically inspected to ensure the physical security of the module is maintained. All components which lie outside the metal enclosure are not security relevant and are listed under section 2.3 Excluded Components. NOTE: Although strictly outside the scope of physical security level 2, the metal security enclosure is monitored 24/7 by battery backed-up tamper detection and response mechanisms. Any attempt to remove the metal enclosure results in instantaneous active zeroization. Zeroization also occurs if both batteries become discharged.

N/A Table 16: SSP Input-Output Methods

Table 17: SSP Zeroization Methods The module explicitly zeroizes SSPs as per the methods above. Please see Section 9.4 for more details. Table 18: SSP Table 1 N/A N/A

N/A N/A N/A N/A N/A N/A Table 20: Pre-Operational Self-Tests The NXP SE050 referenced above is synonymous with TPM.

(FIPS1864) (C838) Table 21: Conditional Self-Tests The IMB-S4 has one conditional self-test related to firmware loading. Firmware loading requires are tested as part of the self-test on boot up and during the periodic self-tests. N/A N/A

Table 22: Pre-Operational Periodic Information

Table 23: Conditional Periodic Information

Table 24: Error States For more information about each error state, please see the relevant Self-Test section above.

The module is manufactured in a secure facility and placed into the approved mode of operation prior to shipping to the customer. On powering up the module (from battery to main power), the module goes through self-tests and an image integrity check to confirm that the non-modifiable operating environment has not been tampered with.

Any other failure will result in a hard FIPS error state to prevent use of the product in a nonapproved mode.

The module consists of a single Crypto Officer role (see 4.2 Roles) and there are no administrative specific procedures functions required to administer the module while it’s in its approved mode of operation. The module is fully secured and in the approved mode of operation once it is shipped from the factory. There is no additional user behavior expected for secure operation of the module. Physical Ports and logical Interfaces Please refer to section 3 Cryptographic Module Interfaces. Security Events Please refer to section 2.4 Modes of Operation. Approved & Non-approved Security Functions Please refer to section 4.3 Approved Services and section 4.4 Non-Approved Services. Security Parameters Please refer to section 9.4 SSPs.

As defined in section 4.1 Authentication Methods, the module supports identity-based operator authentication and there are no specific procedures required to maintain the operator authentication data and mechanisms functionally independent. The module enters the approved mode of operation immediately after self-test is completed. The module enters the non-approved mode of operation as soon as the first non-approved service is called. The module can transition from non-approved to approved mode by rebooting the module and letting the self-test complete. Please see section 2.4 Modes of Operation for more details.

The module supports both battery power and main power by design. Powering up is defined as the process of switching from battery power to main power. All pre-operational self-tests are performed during the powering up sequence and the model automatically transitions to the operational state when the self-tests have passed. Once in this state, the module awaits service requests from the operator.

Procedure for secure sanitization of the IMB-S4 at end-of-life:

1. Remove both battery boards from the IMB-S4. This causes tampering and zeroization of the IMB-S4 module.
2. Dispose of the board properly according to local e-waste regulations and laws.
3. Dispose of the batteries, which contain lithium, properly according to local regulations and laws. Please ensure all components of the IMB-S4 are disposed of properly according to local regulations and laws.

The IMB-S4 module does not mitigate any specific attacks beyond the scope of FIPS140-3.