1. Home
  2. Countermeasure
  3. On-board Message Encryption

On-board Message Encryption

Authentication controls on the spacecraft internal bus verify the identity of communicating components but do not protect the confidentiality of the data in transit; an adversary with access to the bus, whether through a compromised component, a hardware implant, or a physical access event, can observe all unencrypted inter-component communications regardless of whether authentication is enforced. Encrypting data traversing the spacecraft internal bus protects the confidentiality of selected message content from entities that can observe the bus but do not possess authorization and the applicable cryptographic keys. The protection does not prevent disclosure to a compromised component that legitimately possesses the decryption key, and it may not conceal unencrypted protocol headers, addressing information, message timing, or traffic volume. Bus encryption should be considered for bus segments or message types carrying information whose unauthorized disclosure would create unacceptable mission, security, privacy, or operational risk. Criticality alone does not establish a confidentiality requirement. Where confidentiality is required, encryption must be combined with message integrity, source authentication, and replay protection through an approved authenticated-encryption mechanism or an appropriately composed set of cryptographic protections.

Sources

  • CCSDS 350.0-G-3 — The Application of Security to CCSDS Protocols
  • CCSDS 352.0-B-2 — CCSDS Cryptographic Algorithms
ID: CM0050
Tier: II
Onboard SV CM 
Created: 2022/10/19
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should address onboard bus encryption as a recommended security design objective, with the decision to implement encryption on specific bus segments documented through a formal security trade analysis that weighs the confidentiality risk of unencrypted bus communications against the computational, latency, and power overhead of encryption for each bus type and mission profile. Where bus encryption is required by the mission's security classification or threat assessment, contract language should specify the buses subject to encryption, the cryptographic mechanisms to be used, and the key management approach for onboard bus encryption keys, with the architecture documented as a security engineering deliverable subject to government review. Requirements should specify that bus encryption, where implemented, be integrated with the mission's overall cryptographic key management infrastructure rather than implemented as an isolated, independently managed capability. Evaluation criteria should assess offerors' proposed approach to onboard bus encryption, including their analysis of resource overhead, their key management design, and their experience implementing encryption in resource-constrained spacecraft bus environments. Verification should include testing that confirms encryption is active on required bus segments and that bus traffic cannot be read in cleartext by components not authorized to access the protected data.

Pre-Operations Developer/Supplier

The decision to implement onboard bus encryption should be driven by a threat-informed analysis conducted during the system design phase, identifying which bus segments carry data whose confidentiality loss would materially affect mission security or operational integrity, and evaluating the feasibility of encryption on each segment given the bus protocol, processor resources, and timing constraints of the spacecraft. Bus encryption must use a defined key-establishment and lifecycle-management architecture. Onboard bus keys may be securely provisioned before launch, loaded or replaced through an authenticated ground process, transported between trusted onboard cryptographic components, derived from existing keying material, established through an onboard key-agreement mechanism, or managed through an approved combination of these methods. Secret keys must be protected during generation, establishment, storage, distribution, use, replacement, recovery where authorized, compromise response, and destruction, with hardware-protected storage used where required by mission risk. Encryption overhead, including processing latency and power consumption, must be characterized through hardware testing or high-fidelity simulation before the design is finalized, ensuring that encrypted bus communications do not violate timing budgets for real-time control functions or degrade link throughput below operational requirements. Where encryption of all bus traffic is not required or feasible, encryption may be applied selectively to confidentiality-sensitive message types, communication relationships, logical channels, or bus segments. The architecture must clearly identify protected and unprotected fields, prevent sensitive content from being transferred through unprotected paths, and ensure that routing, gateway, and endpoint behavior does not inadvertently expose plaintext outside the approved cryptographic boundary. Bus encryption must be governed by the spacecraft’s overall cryptographic architecture and key-management policy. Algorithms, modes, key lengths, cryptoperiods, key domains, and protocol mechanisms may differ from external-link protections where required by the onboard bus protocol, assurance level, resource limits, or operational purpose. Keys should be scoped to their intended security domain and must not be reused across unrelated onboard and external-link functions unless specifically justified by the approved cryptographic design.