| SPR-10 |
The [spacecraft] shall protect authenticator content from unauthorized disclosure and modification.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),IA-5,IA-5(6),RA-5(4),SA-8(18),SA-8(19),SC-28(3)}
|
Authenticators (keys, tokens, counters, certificates) are primary targets for persistent access attacks. Disclosure or modification enables command spoofing, replay, and privilege escalation. Protecting authenticator content preserves command integrity and prevents adversaries from maintaining covert control. Integrity protections must apply both at rest and in use.
|
| SPR-11 |
The [spacecraft] encryption key handling shall be handled outside of the onboard software and protected using cryptography.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(1),SC-28(3)}
|
Key management separated from modifiable flight software reduces exposure to software compromise. If keys are accessible to onboard applications, malicious code could extract or misuse them. Hardware-anchored or externally managed key handling reduces persistence risk. This supports trust-chain assurance and mitigates firmware-level compromise.
|
| SPR-12 |
The [spacecraft] encryption keys shall be restricted so that the onboard software is not able to access the information for key readout.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)}
|
Even privileged software must not be able to retrieve plaintext keys. Preventing readout mitigates malware harvesting and insider misuse. Key usage should be mediated through cryptographic modules rather than direct exposure. This enforces least privilege at the cryptographic boundary.
|
| SPR-13 |
The [spacecraft] encryption keys shall be restricted so that they cannot be read via any telecommands.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-8(19),SA-9(6),SC-8(1),SC-12,SC-28(3)}
|
Telecommand paths are high-value targets for adversarial exploitation. Allowing keys to be retrieved via command interfaces creates a catastrophic failure mode. This constraint prevents exfiltration even under partial compromise of command processing logic. It ensures encryption protections cannot be remotely dismantled.
|
| SPR-17 |
The [spacecraft] shall protect the confidentiality and integrity of all information at rest using cryptography.{SV-CF-1,SV-CF-2,SV-AC-3}{AC-3,SA-8(19),SC-28,SC-28(1),SI-7(6)}
|
* The intent as written is for all transmitted traffic to be protected. This includes internal to internal communications and especially outside of the boundary.
|
| SPR-119 |
The [spacecraft] shall implement cryptography for the indicated uses using the indicated protocols, algorithms, and mechanisms, in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards: [NSA- certified or approved cryptography for protection of classified information, FIPS-validated cryptography for the provision of hashing].{SV-AC-1,SV-AC-2,SV-CF-1,SV-CF-2,SV-AC-3}{IA-7,SC-13}
|
Use of NSA-certified or FIPS-validated cryptography ensures compliance with federal mandates and high-assurance algorithms. Standardized implementations reduce algorithmic weaknesses. Alignment with policy ensures interoperability and trustworthiness. Proper certification mitigates cryptographic implementation flaws.
|
| SPR-122 |
The [spacecraft] shall produce, control, and distribute symmetric cryptographic keys using NSA Certified or Approved key management technology and processes per CNSSP 12. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers.{SV-AC-1,SV-AC-3}{AC-17(6),CM-3(6),SA-9(6),SC-12,SC-12(1),SC-12(2),SC-12(3)}
|
Centralized and approved key management prevents unauthorized key generation or rotation. Protecting private keys from external service providers reduces supply chain risk. Controlled lifecycle management supports confidentiality and integrity. Strong governance reduces key compromise likelihood.
|
| SPR-123 |
The [organization] shall use NIST Approved for symmetric key management for Unclassified systems; NSA Approved or stronger symmetric key management technology for Classified systems.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(2)}
|
FIPS-complaint technology used by the Program shall include (but is not limited to) cryptographic key generation algorithms or key distribution techniques that are either a) specified in a FIPS, or b) adopted in a FIPS and specified either in an appendix to the FIPS or in a document referenced by the FIPS.
NSA-approved technology used for symmetric key management by the Program shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria.
|
| SPR-124 |
The [organization] shall use NSA approved key management technology and processes.NSA-approved technology used for asymmetric key management by The [organization] shall include (but is not limited to) NSA-approved cryptographic algorithms, cryptographic key generation algorithms or key distribution techniques, authentication techniques, or evaluation criteria.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)}
|
Asymmetric keys underpin authentication and trust chains. Approved algorithms and processes ensure robustness against cryptanalytic attack. Formal evaluation criteria provide confidence in implementation strength. This protects digital signatures and secure exchange mechanisms.
|
| SPR-125 |
The [spacecraft] shall produce, control, and distribute asymmetric cryptographic keys. Private cryptographic keys shall be generated, stored, and rotated under [organization] control only and shall not be exposed to external service providers.{SV-AC-1,SV-AC-3}{SC-12,SC-12(1),SC-12(3)}
|
In most cased the Program will leverage NSA-approved key management technology and processes.
|
| SPR-214 |
The [spacecraft] root of trust shall be an ECDSA NIST P-384 public key.{SV-AC-3,SV-IT-3,SV-SP-4,SV-SP-5}{SI-7(9),SI-7(10)}
|
Strong elliptic curve cryptography ensures robust digital signature validation. P-384 provides long-term cryptographic assurance. Root of trust underpins secure boot and update integrity. High-strength algorithms mitigate future cryptanalytic advances.
|
| SPR-375 |
The [organization] shall develop and document program-specific system and communications protection policies in accordance with CNSSP 12. {SV-AC-7,SV-CF-1,SV-AC-3}{SC-1}
|
Alignment with CNSSP 12 ensures compliance with national security requirements. Standardized communications protection strengthens cryptographic assurance. Program-specific tailoring ensures relevance. Policy integration strengthens governance.
|
| SPR-387 |
The [organization] shall define policy and procedures to ensure that the developed or delivered systems do not embed unencrypted static authenticators in applications, access scripts, configuration files, nor store unencrypted static authenticators on function keys.{SV-AC-1,SV-AC-3}{IA-5(7)}
|
Hard-coded or static authenticators create high-value targets for reverse engineering and credential reuse. Preventing embedded unencrypted credentials reduces insider and supply chain exploitation risk. Credential hygiene is critical in long-lived space missions. Eliminating static secrets strengthens identity assurance.
|
| SPR-388 |
The [organization] shall produce, control, and distribute asymmetric cryptographic keys (where applicable) using NSA Certified or Approved key management technology and processes per CNSSP 12.{SV-AC-3,SV-AC-7}{SC-12(3)}
|
Using NSA-certified key management ensures cryptographic integrity and compliance with federal mandates. Proper generation, distribution, and control reduce key compromise risk. High-assurance key lifecycle management underpins command authentication and secure updates. Governance over keys preserves mission trust.
|
| SPR-390 |
The [organization] shall ensure that cryptographic mechanisms, including authentication schemes and command dictionaries, are under strict configuration management.{SV-AC-3,SV-IT-2}{CM-3(6)}
|
Cryptographic algorithms, keys, and command dictionaries are foundational trust elements. Strict configuration control prevents unauthorized changes that could weaken security. Version tracking supports forensic reconstruction. Governance ensures cryptographic integrity across lifecycle phases.
|
| SPR-451 |
The [spacecraft] shall ingest [organization]-defined revocation updates to onboard access control lists and attribute sets and shall enforce revocation within [Program-defined time] of receipt.{SV-AC-4,SV-AC-3}{AC-3(8)}
|
Timely revocation prevents continued access by compromised identities. Defined enforcement timelines reduce residual exposure. Structured update ingestion strengthens identity governance. Rapid revocation reduces insider and key compromise risk.
|
| SPR-455 |
The [spacecraft] shall restrict access to flight software executables, cryptographic material, command dictionaries, and [organization]-defined sensitive payload data to the privileged execution domain and shall deny all other access by default.{SV-AC-1,SV-AC-3,SV-IT-3}{AC-3(11),AC-6}
|
Flight executables and cryptographic materials are high-value targets. Restricting access reduces exploitation pathways. Default deny enforces least privilege. Segmentation enhances resilience.
|
| SPR-457 |
The [spacecraft] shall verify cryptographic integrity and origin of data at each relay hop before forwarding information between internal components, payloads, crosslinks, and ground.{SV-IT-1,SV-IT-2,SV-AC-3}{CA-3(7),SC-8(1),SC-13,SC-23}
|
End-to-end security alone is insufficient in multi-hop spacecraft architectures. Verifying integrity and origin at each relay prevents compromised subsystems from forwarding malicious data laterally. Hop-by-hop validation limits propagation of injected commands or payload tampering. This enforces zero-trust principles internally.
|
| SPR-463 |
The [spacecraft] shall maintain configuration and cryptographic synchronization required to activate alternate processing or storage and shall verify the alternate before activation.{SV-SP-9,SV-AC-3}{CP-2(6),CM-2}
|
Activation of alternate nodes requires synchronized keys and configurations. Unsynchronized failover risks data corruption or exposure. Verification before activation prevents propagation of compromised states. Coordinated readiness supports secure recovery.
|
| SPR-466 |
The [spacecraft] shall support rapid rollover of communications credentials to restore secure operations with an alternate provider.{SV-AC-3}{SC-12,IA-5}
|
Credential compromise requires immediate remediation capability. Rapid rollover restores secure communications without prolonged outage. Agility prevents mission interruption. Cryptographic agility is foundational to resilience.
|
| SPR-471 |
The [spacecraft] shall preserve trusted boot and cryptographic key storage functionality under EMP conditions by locating those functions within hardened, power-conditioned domains.{SV-IT-3,SV-AC-3}{PE-21}
|
Electromagnetic disruption is a realistic space threat. Hardening trusted boot and key storage ensures continuity of secure startup. Protection of root-of-trust preserves system integrity. Resilient design supports adversarial environments.
|
| SPR-477 |
The [organization] shall require independent testing and inspection of mission-critical components prior to integration to verify hardware integrity and cryptographic module assurance.{SV-SP-5,SV-AC-3}{PM-30(1),SR-11}
|
Third-party validation reduces conflict-of-interest risk. Independent inspection verifies hardware integrity and cryptographic assurance. External attestation strengthens confidence. Verification supports mission-critical trust.
|
| SPR-489 |
The [spacecraft] shall host privileged functions, including flight control and cryptographic key management, in physically separate processing domains that have no direct data bus connectivity to non privileged domains. {SV-AC-6,SV-AC-3}{SC-3,SC-32(1),SC-39}
|
Hardware-level separation prevents software bypass. Isolation protects flight control and key management. Physical boundaries strengthen trust. Segmentation enforces zero-trust architecture.
|
| SPR-492 |
The [spacecraft] shall update signal parameter selections using cryptographically sound PRNG inputs at [organization]‑defined intervals or triggers, coordinated with TRANSEC and Traffic Flow Security.{SV-CF-2,SV-AC-3}{SC-8,SC-12,SC-40(4)}
|
Predictable signal patterns enable adversary exploitation. Strong PRNG inputs ensure randomness integrity. Coordinated update intervals prevent synchronization attacks. Cryptographic randomness strengthens concealment.
|
| SPR-494 |
The [spacecraft] shall preserve and protect a golden backup of security credentials and integrity anchors and shall restore them automatically when corruption is detected.{SV-AC-3,SV-IT-3}{SI-13,CP-9}
|
Protected backups enable secure recovery from corruption. Automatic restoration reduces downtime. Integrity anchors preserve trust. Backup governance strengthens resilience.
|
| SPR-497 |
The [spacecraft] shall verify the standby component integrity before activation using stored signatures and shall revert if verification fails.{SV-SP-4,SV-AC-3}{SI-13(4)}
|
Failover to compromised standby defeats purpose. Signature verification ensures trust continuity. Reversion prevents propagation of corruption. Validation strengthens resilience.
|
| SPR-498 |
The [spacecraft] shall minimize persistence of sensitive data and cryptographic material by using ephemeral session keys stored only in volatile memory and purging them upon session end, mode change, or power cycle.{SV-AC-3}{SI-14}
|
Minimizing persistence reduces exposure window. Volatile storage prevents residual compromise. Automatic purge enforces key hygiene. Ephemerality strengthens confidentiality.
|
| SPR-500 |
The [spacecraft] shall avoid storing sensitive operational data in nonvolatile memory unless required by mission, and if stored, it shall be encrypted and retained only for [organization]-defined durations.{SV-AC-3,SV-IT-2}{SI-14}
|
Minimizing nonvolatile storage reduces compromise surface. Encrypted storage protects required retention. Defined retention periods prevent indefinite exposure. Controlled persistence supports compliance.
|