Value chain · CLM-0763
In plain terms
The civil space link security standards deliberately do not say which encryption to use, do not describe how to build a real system, and leave the choice of algorithm to the mission; a companion document adds the key management, rekeying and replay protection needed to run the protocol.
The claim as recorded
Both CCSDS space data link security standards state that they mandate no particular cryptographic algorithm and are not designs for real systems: the base standard states it does not mandate the use of any particular cryptographic algorithm, does not specify individual implementations or products, the implementation of service interfaces within real systems, the methods or technologies required to perform the procedures, or the management activities required to configure and control the service, and that it is neither a specification of nor a design for real systems; the Extended Procedures companion supplies what the base standard omits operationally, defining key management, security association management and SDLS monitoring and control services, including over-the-air rekeying, key activation, deactivation and verification, anti-replay sequence number commands, logging and self-test, plus a new telemetry Operational Control Field type called the Frame Security Report, and it likewise mandates no particular cryptographic algorithm and does not specify the space-link security protocol itself.
Evidence behind this: Two sources, both registered T1 (SRC-232, SRC-233), so the weakest is T1.
Scope and limits
Decision-relevant consequence, stated plainly: because the standard mandates no algorithm and is expressly not a design for real systems, conformance to CCSDS 355.0-B-2 does not by itself establish any security level, and a compliance argument that stops at "the mission uses SDLS" is not checkable. The base standard also states that where options are allowed, their implementation is subject to specific bilateral cross-support agreements between agencies, so two conformant systems may differ materially. This claim describes the standards' own scope statements, not any implementation, and not the strength of any algorithm. SRC-233's procedure list is drawn from its contents pages and should be re-checked against its normative sections before use.
What it assumes
That the SRC-233 list of figures accurately names the procedures the normative sections define. Only SRC-233's front matter, purpose, scope and rationale were read; its normative sections 3 to 7 were not mined, and the register row for SRC-233 records it as cover metadata only.
Where it comes from
Algorithm neutrality, SRC-232 PDF p.10, verbatim: "This Recommended Standard does not mandate the use of any particular cryptographic algorithm with the Security Protocol. Reference [4] provides a listing of algorithms recommended by CCSDS; any organization should conduct a risk assessment before choosing to substitute other algorithms." Exclusions, same page, verbatim: "It does not specify: a) individual implementations or products; b) the implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the management activities required to configure and control the service." Same page, verbatim: "It is neither a specification of, nor a design for, real systems that may be implemented for existing or future missions." Companion scope, SRC-233 PDF p.11, verbatim: "It defines the Key Management, Security Association Management, SDLS Monitoring and Control Services, and data structures required to operate the SDLS protocol over a space link." Companion exclusions, same page, verbatim: "It does not specify a) individual implementations or products; b) the implementation of service interfaces within real systems; c) the methods or technologies required to perform the procedures; or d) the space-link security protocol itself." and "This Recommended Standard does not mandate the use of any particular cryptographic algorithm for key generation and management." Frame Security Report, SRC-233 PDF p.12, verbatim: "specify a new type of telemetry frame Operational Control Field (OCF), the Frame Security Report (FSR), for reporting of link security status events". Named procedures from the SRC-233 list of figures, PDF p.10: OTAR, Key Activation, Key Deactivation, Key Verification, Start SA, Stop SA, Rekey SA, Expire SA, Set ARSN, Read ARSN, Ping, Log Status, Dump Log, Erase Log, Self-Test and Alarm Flag Reset command protocol data units.
Basis: normative scope and exclusions of the standard set
Related records
- Answers question
- QST-011 not published in this release
Cite this
energyaperture.com/c/clm-0763
CLM-0763, Energy Aperture, as of 2022-07.
Connected records
Other published records linked to this one. A list, not a judgement.