The 'scsp' Uniform Resource Identifier (URI) Scheme and Space Command & Telemetry Security Protocol (SCSP)

1.1. Problem Statement and Orbital Security Models

Spacecraft operational security models currently divide into two distinct paradigms:¶

1. Legacy Unprotected Spacecraft: Many heritage, commercial, and smallsat missions transmit unencrypted and unauthenticated CCSDS frames. These links remain vulnerable to telecommand hijacking, telemetry spoofing, and RF command replay.¶

2. SDLS-Protected Spacecraft (CCSDS 355.0-B-2): Established defense and agency missions utilize the CCSDS Space Data Link Security (SDLS) protocol [CCSDS355]. SDLS provides frame-level authentication and MAC integrity using pre-shared symmetric keys (AES-GCM / AES-CMAC) and anti-replay sequence windows.¶

SCSP is an application-layer protocol that MAY be carried within CCSDS 355.0-B-2 protection. It does not modify or redefine the SDLS Security Header, Security Trailer, or Security Association structures:¶

• End-to-End Command Authentication: SCSP adds application-layer digital signatures and authorization policy processing that can remain meaningful across multiple underlying links.¶

• High-Level Payload Addressing: SDLS protects data-link transfer frames; SCSP introduces structured `scsp://` URIs and ground-side resolution to mission-defined CCSDS routing parameters.¶

• Profile-Driven Enclave Attestation: SCSP binds command execution to hardware TPM 2.0 / TEE quotes where provisioned.¶

• Mission-Specific Replay Policy: SCSP defines persistent replay state and permits mission profiles to account for propagation delay and clock uncertainty.¶

1.2. Scope and Non-Scope Boundaries

SCOPE: SCSP defines an application-layer cybersecurity protocol for authenticating, authorizing, encrypting, and routing telecommands and telemetry between authorized ground control stations and spacecraft sub-systems over the 'scsp' URI scheme.¶

NON-SCOPE: SCSP does NOT define physical RF modulation, orbital mechanics algorithms, low-level antenna pointing, or replacement of CCSDS data link framing standards. Fragmentation and reassembly of SCSP frames that exceed the maximum Transfer Frame size of an underlying CCSDS TC/TM/AOS link (which may be smaller than the 3,404-byte minimum for a SigID 0x3 zero-payload frame) is delegated to the mission profile and lower-layer link configuration.¶

1.3. Protocol Goals & Disambiguation from RFC 9260 (SCTP)

To prevent acronym collision with Stream Control Transmission Protocol (SCTP, [RFC9260]), this specification defines the Space Command & Telemetry Security Protocol (SCSP) using the single canonical 'scsp' URI scheme. The central architectural thesis of SCSP is that it provides a zero-trust, application-layer security and authorization envelope for space commands and telemetry across heterogeneous links, while underlying CCSDS protocols (SDLS, Space Packet Protocol, TC/TM) remain responsible for lower-layer link framing and physical transport. SCSP provides:¶

• Standardized addressing of orbital spacecraft payloads via 'scsp://' URIs.¶

• Binary wire formats with explicit algorithm agility (PureEd25519, ML-DSA-65 PQC & AES-GCM AEAD).¶

• Byte-level encapsulation inside CCSDS 355.0-B-2 (SDLS) frame headers and trailers.¶

• Profile-driven space-grade hardware attestation (TPM 2.0 / Space TEE).¶

• Adaptive Doppler epoch counters supporting both Low-Earth Orbit (LEO) and Deep-Space One-Way Light Time (OWLT) missions.¶

1.4. Standardization Roadmap (Potential IETF Standardization Path & Intended CCSDS Interoperability)

SCSP is designed for multi-stakeholder governance across international space and security bodies:¶

• Potential IETF Standardization Path: Targeted for discussion within IETF SECDISPATCH and ART Working Groups.¶

• Intended CCSDS Interoperability: SCSP is designed to coexist with CCSDS protocols and is intended to be evaluated for compatibility with CCSDS SDLS deployments (Security Working Group, SecWG).¶

• Open Source Reference Implementations: Reference spacecraft flight agent implementations released under Apache 2.0 for FreeRTOS, NASA cFS, and Linux space-grade platforms.¶

• Intended Status Rationale: This draft is submitted with an intended status of Standards Track to establish a uniform, interoperable IETF/CCSDS standard for space URI addressing and security envelopes. However, as an initial individual -00 submission, the authors recognize that the IESG and relevant Working Groups (e.g. SECDISPATCH / ART) may designate the document as Experimental or Informational during early review cycles prior to formal WG adoption.¶

1.5. Mission Profile Abstraction

To allow SCSP implementations to operate flexibly across diverse satellite hardware (from resource-constrained CubeSats to deep-space probes), SCSP strictly separates core protocol wire formats from mission-specific policies via the Mission Profile abstraction. A Mission Profile MUST specify:¶

• Supported cryptographic signature algorithms (`SigID`) and ciphers (`CipherID`).¶

• Key provisioning, rotation intervals, and revocation policies.¶

• Sliding-window anti-replay size (W in {64, 256, 1024} bits).¶

• Onboard clock synchronization precision, Doppler compensation parameters, and OWLT tolerance bounds (delta_t_clock).¶

• Mission Endpoint Resolution Table and Onboard Authorization Policy Matrix.¶

• Hardware attestation requirements (TPM 2.0 / TEE quote enforcement).¶

• Lower-layer CCSDS SDLS integration parameters (including explicit mode selection: `sdls_integration_mode` in {`"NATIVE_SA_TABLE"`, `"DIRECT_OVERLAY"`}).¶

3.1. ABNF Syntax Definition ('scsp')

The single canonical 'scsp' URI scheme syntax is specified using Augmented Backus-Naur Form (ABNF) as defined in [RFC5234], importing core productions from [RFC3986].¶

scsp-URI       = "scsp://" scsp-authority "/" subsystem
                 [ "/" command-path ] [ "?" query ]

scsp-authority = host [ ":" port ]
host           = IP-literal / IPv4address / reg-name
port           = 1*DIGIT
subsystem      = segment-nz
command-path   = segment-nz *( "/" segment-nz )
segment-nz     = 1*pchar
pchar          = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved     = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded    = "%" HEXDIG HEXDIG
sub-delims     = "!" / "$" / "&" / "'" / "(" / ")" /
                 "*" / "+" / "," / ";" / "="
query          = *( pchar / "/" / "?" )

URI Authority Semantics: The `scsp-authority` component identifies the SCSP Mission Namespace Authority (such as a satellite constellation tracking domain or ground control station identifier) and does not itself constitute spacecraft authorization credentials. Ground-side resolvers map the authority and path components to specific physical link parameters (NORAD ID, CCSDS SCID, VCID, APID) via the Endpoint Resolution Table.¶

3.2. URI Normalization, Ground-Side Resolution, Onboard Key Caches & Monotonic In-Pass KRL

Implementations MUST normalize 'scsp' URIs prior to processing:¶

• Scheme name MUST be converted to lowercase ("scsp://").¶

• Internationalized hostnames MUST be processed according to applicable IDNA rules; ASCII DNS labels are compared case-insensitively and emitted in lowercase.¶

• Path segments equal to `.` or `..` MUST be rejected to prevent path traversal.¶

• Resolvers MUST NOT connect to private-use or loopback IP ranges to prevent SSRF.¶

GROUND-SIDE RESOLUTION & IN-ORBIT CACHING: Spacecraft MUST NOT perform live DNS resolution as part of SCSP frame processing. A ground system MAY use DNSSEC or another authenticated configuration mechanism to resolve a ground transport endpoint, but SCSP does not define a DNS record type. DNS results MUST NOT be treated as spacecraft authorization credentials. Spacecraft flight computers maintain a pre-provisioned, cryptographically authenticated Onboard Key Cache containing permitted controller public keys and authorization metadata.¶

MONOTONIC IN-PASS EMERGENCY KEY REVOCATION LIST (KRL): In the event of ground key compromise mid-pass, an offline Master Root Authority (whose public key is permanently fused into spacecraft ROM / OTP memory during manufacturing) MAY issue an immediate emergency Key Revocation List (KRL) frame signed by the Master Root Key. To prevent replay attacks of historical KRL frames, Master KRL frames MUST include a 64-bit monotonic `krl_sequence_number`. Flight computers ONLY process KRL frames where `krl_sequence_number > nvram.krl_sequence_number`, updating `nvram.krl_sequence_number` in OTP/NVRAM upon execution and purging the revoked key from key caches.¶

3.3. Example URIs

scsp://norad-48219.orbit.spacecraft/payload/imager
  ?mode=zero-trust&norad=48219
scsp://ground-station-alpha.idevsec.space/command/orbit-burn
  ?seq=10492&auth=tpm20
scsp://constellation-mesh.internal/sat-04/laser-link?channel=2

3.4. SCSP URI Canonicalization Algorithm & RFC 8785 JCS Payload Formatting

SCSP strictly distinguishes between URI Canonicalization and JSON Payload Canonicalization:¶

1. SCSP URI Canonicalization Algorithm (For Signature Input Generation): Prior to computing digital signatures over URIs or generating message hashes, implementations MUST process 'scsp' URIs using the SCSP URI Canonicalization Algorithm:¶

   • Convert scheme to lowercase (`scsp://`).¶

   • Convert hostname to lowercase per IDNA [RFC5890].¶

   • Percent-decode all unreserved characters (`A-Z`, `a-z`, `0-9`, `-`, `.`, `_`, `~`).¶

   • Uppercase all percent-encoding hexadecimal digits (`%2f` -> `%2F`).¶

   • SCSP query components MUST use `key=value` pairs separated by `&`. Parameter names and values MUST NOT contain unescaped `&` or `=`. During canonicalization, query parameters MUST be sorted by their percent-encoded UTF-8 key, then by their percent-encoded UTF-8 value. Duplicate keys MUST be preserved and sorted stably by value.¶

2. RFC 8785 JSON Canonicalization Scheme (JCS) (For Payload Formatting): JSON command payloads (`command.json`) and telemetry response documents (`telemetry.json`) MUST be canonicalized strictly per JSON Canonicalization Scheme (JCS, [RFC8785]). RFC 8785 is applied EXCLUSIVELY to JSON payload structures, enforcing UTF-8 encoding, exact IEEE 754 number representation, and lexicographical sorting of JSON object keys.¶

3.5. Mission Endpoint Resolution Table (NORAD/SCID Disambiguation, VCID & APID Mapping)

SCSP defines an explicit distinction between space domain identifiers and CCSDS link routing parameters:¶

• NORAD Catalog Identifier (32-bit uint32): Unsigned 32-bit numeric NORAD Catalog Identifier. Alpha-5 catalog notation and COSPAR International Designators are separate identifier forms and MUST NOT be treated as alternate encodings of this field unless a separate deterministic catalog lookup establishes the numeric NORAD identifier.¶

• CCSDS Spacecraft ID (SCID, 16-bit uint16): Identifies the physical spacecraft node on the CCSDS link.¶

• CCSDS Virtual Channel ID (VCID, 6-bit uint8): Identifies the logical data channel onboard.¶

• CCSDS Application Process ID (APID, 11-bit integer 0..2047): Identifies the onboard software endpoint handler.¶

DISAMBIGUATION: NORAD Catalog Numbers and CCSDS SCIDs belong to separate identifier namespaces. A ground station MUST NOT assume NORAD ID equals SCID. Resolution is performed via a mission-provisioned SCSP Endpoint Resolution Table:¶

Example SCSP Endpoint Resolution Table:
+----------------------------------+-------+-------+------+------+
| Target URI Path                  | NORAD | SCID  | VCID | APID |
+----------------------------------+-------+-------+------+------+
| scsp://norad-48219.../imager     | 48219 | 10492 | 2    | 104  |
| scsp://norad-48219.../burn       | 48219 | 10492 | 4    | 301  |
| scsp://scid-10492.../orbit       | 48219 | 10492 | 3    | 201  |
+----------------------------------+-------+-------+------+------+

Ground Transport Port Rule (`:port`): Optional URI `:port` components (e.g. `:8080`) are used exclusively for ground-side IP socket transport routing between ground control centers and antenna stations, and MUST be stripped prior to binary CCSDS frame encapsulation.¶

3.6. Endpoint Resolution Table Lifecycle & Trust Governance

The Endpoint Resolution Table is a mission-provisioned trust anchor stored in radiation-hardened FRAM/NVRAM. Each Endpoint Resolution Table MUST include explicit metadata attributes: `table_version` (32-bit uint32), `activation_epoch` (64-bit uint64 continuous TAI microseconds), `issuer` (Authority ID), `signature_algorithm` (SigID), `signature` (Master Root digital signature over table binary structure), `validity_state` (ACTIVE, STAGED, SUPERSEDED), and `rollback_policy` (strictly monotonic `table_version` increase required).¶

To prevent unauthorized routing modifications and service disruptions:¶

1. The Endpoint Resolution Table MUST be cryptographically signed by the Master Root Authority prior to onboard provisioning.¶

2. Onboard updates to the resolution table MUST be delivered via authenticated, signed Master Control Frames.¶

3. Flight computers MUST support in-memory staging: while a new table update is being staged and verified, the existing table remains active in memory. Upon successful signature validation and when `current_epoch >= activation_epoch`, flight computers accept table updates where `cmd.table_version > nvram.table_version`, updating `nvram.table_version` and table contents atomically in FRAM/NVRAM.¶

3.7. Architectural Justification for the 'scsp' URI Scheme

SCSP requires a dedicated URI scheme (`scsp://`) rather than relying on existing generic URNs or transport-layer socket strings for fundamental architectural reasons:¶

1. Endpoint Resolution & Security Binding: Ground-side control software resolves canonical `scsp://` URIs into normative binary routing parameters (`NORAD ID`, `SCID`, `VCID`, `APID`). These resolved parameters are encoded directly into the 26-byte binary header, and digital signatures compute over `Header_Bytes || Command_Payload`, securing the resolved endpoint routing and payload against substitution. The canonical `scsp://` URI string serves strictly as an addressing and resolution input. The resolved endpoint tuple encoded in the SCSP header is the cryptographically authenticated representation of the destination.¶

2. Transport-Agnostic Endpoint Addressing: Space missions transition dynamically across multiple underlying links (ground RF S-band/X-band, optical laser inter-satellite links, and Delay-Tolerant Networking bundles). A uniform `scsp://` URI provides persistent, link-independent application addressing across these changing networks.¶

3. Formal Namespace Disambiguation: Establishing a dedicated scheme explicitly disambiguates SCSP from Stream Control Transmission Protocol (SCTP, [RFC9260]) and provides standard IANA registration governance under BCP 35 ([RFC7595]).¶

URI Resolution and Authentication Pipeline:¶

scsp:// URI -> Canonicalization -> Endpoint Resolution Table ->
  Header Tuple (NORAD/SCID/VCID/APID) + Payload -> Signature / AEAD

4.1. Binary Frame Field-Width (KeyID 0x0000, 11-bit APID, DMA Sizing & Authoritative Header Rules)

All SCSP binary control packets MUST use Network Byte Order (Big-Endian). Multi-byte fields MUST NOT use little-endian byte ordering. To enable O(1) public key selection from onboard caches, prevent inter-satellite routing loops, and support AEAD payload encryption, the binary header includes an explicit 16-bit `KeyID`, 8-bit `Hop Limit (TTL)`, and split `AlgID` (SigID + CipherID).¶

Reserved KeyID 0x0000 Rule: `KeyID 0x0000` is STRICTLY RESERVED for the Master Emergency Root Authority Key. Operational ground controller keys MUST use key indices in the range `0x0001` through `0xFFFF`. Emergency Time-Resynchronization control frames and Master Key Revocation Lists (KRL) MUST be signed strictly by the Master Root Key (`KeyID 0x0000`).¶

CCSDS 11-Bit APID & 6-Bit VCID Zero-Padding Rules: While the `CCSDS APID` field (Offset `0x0B..0x0C`) is allocated 16 bits in the binary header, the upper 5 bits MUST be set to zero (`0b00000`), restricting active APID values to the range `0` through `2047` per CCSDS 133.0-B. Similarly, while `CCSDS VCID` (Offset `0x0A`) is allocated 8 bits, the upper 2 bits (bits 7..6) MUST be set to zero (`0b00`), restricting active VCID values to the range `0` through `63` per CCSDS TC and AOS data link standards.¶

Normative Onboard DMA Receive Buffer Sizing (B_min): To prevent buffer overflow panics on embedded space processors (Cortex-R5, LEON4 SPARC, RISC-V), spacecraft flight computers MUST allocate static DMA receive buffers satisfying the normative mathematical formula: B_min >= 26 + N_max + SigLen_max where N_max is the maximum value of the Payload Length field (Offset 0x18..0x19), 26B represents the fixed binary header width, and SigLen_max represents the maximum signature length supported by the mission profile. For hybrid PQC profiles (SigID 0x3, SigLen_max = 3378B), the allocation MUST satisfy B_min >= 26 + N_max + 3378 bytes per TC link channel.¶

Authoritative Binary Header & Outer CCSDS Cross-Layer Validation Rules: The 26-byte binary header is strictly authoritative for transport, link routing, cryptographic agility, and authorization metadata. Flight computers MUST enforce two validation rules during Stage 6 (PAYLOAD_VALIDATE):¶

1. JSON Payload Parity: When higher-layer command payloads (command.json) contain duplicated metadata fields (e.g. norad_id, key_id, ccsds_routing, sequence_epoch, alg_id), flight computers MUST verify that JSON payload fields match binary header fields exactly.¶

2. Outer CCSDS Primary Header Cross-Layer Validation: When SCSP operates in Direct Overlay Mode (`sdls_integration_mode == "DIRECT_OVERLAY"`), flight computers MUST cross-verify that the inner signed SCSP header fields (SCID, VCID) match the outer physical CCSDS Transfer Frame Primary Header parameters (SCID, VCID) exactly. Any discrepancy between inner signed header routing values and outer physical link header parameters MUST cause immediate frame rejection under error code 0x0C (ERR_LINK_HEADER_MISMATCH).¶

Sequence Epoch Microsecond Continuous TAI Scale Specification: The `Sequence Epoch` field (Offset `0x10..0x17`) is a 64-bit unsigned integer representing elapsed SI microseconds since `1970-01-01T00:00:00 TAI`. It is a continuous TAI timescale, not a POSIX/UTC timestamp. Implementations MUST convert civil-time sources using a mission-authorized time-conversion source. Leap seconds do not create repeated or skipped SCSP epoch values. If `sequence_epoch` reaches `0xFFFFFFFFFFFFFFFF` (uint64 max) or an integer overflow wrap occurs, the flight computer MUST reject the frame under error code 0x02 (ERR_EPOCH_EXPIRED) and mandate a Master Root key rollover for that KeyID.¶

Payload Length N Definition & Zero-Payload (N=0) Boundary Rule: The `Payload Length N` field (Offset `0x18..0x19`) specifies the TOTAL byte count of the `Command Payload` on the wire. When payload encryption is disabled (`CipherID 0x0`), N MAY equal 0. When N=0 (zero-payload ping/noop telecommands), the `Command Payload` field is 0 bytes in width, and the `Signature Block` begins immediately at offset `0x1A`. When AEAD payload encryption is enabled (`CipherID 0x1` or `0x2`), N MUST be >= 28 bytes (N = Plaintext Length + 12B IV + 16B Tag). The 12-byte AEAD IV is prepended explicitly to `Command Payload` on the wire. During AEAD_DECRYPT, the receiving flight computer MUST verify that the prepended wire IV matches the header-derived IV_96 (`Sequence_Epoch || KeyID || 0x0000`). If the prepended wire IV does not equal IV_96, the frame MUST be rejected under error code 0x08 (ERR_AEAD_DECRYPT_FAILED). An encrypted empty-plaintext telecommand has N=28 (0B Plaintext + 12B IV + 16B Tag). Any frame with `CipherID != 0` declaring N < 28 MUST be rejected immediately under error code 0x08 (ERR_AEAD_DECRYPT_FAILED).¶

Binary Header Memory Layout (32-Bit Word Alignment Grid):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Magic Header ("SC")     |  Version (1)  |  AlgID (Split)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       NORAD Catalog ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          CCSDS SCID           |   CCSDS VCID  |  CCSDS APID...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...CCSDS APID (11b active, 5b0)|  KeyID / Slot | Hop Limit TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Sequence Epoch...                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...Sequence Epoch (Continuous TAI Microseconds, 64-bit)        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Payload Length N        | Command Payload (N Bytes)...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...Command Payload             | Signature Block...            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...Signature Block (64B / 3309B / 3378B)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Field-Width Specification Table:
+------------------+--------------+---------+------------------+
| Field Name       | Offset       | Width   | Description      |
+------------------+--------------+---------+------------------+
| Magic Header     | 0x00..0x01   | 16 bits | Fixed 0x53 0x43  |
| Version          | 0x02         | 8 bits  | Version (0x01)   |
| AlgID            | 0x03         | 8 bits  | SigID | CipherID |
| NORAD Catalog ID | 0x04..0x07   | 32 bits | uint32 NORAD ID  |
| CCSDS SCID       | 0x08..0x09   | 16 bits | uint16 SCID      |
| CCSDS VCID       | 0x0A         | 8 bits  | VCID (6b active) |
| CCSDS APID       | 0x0B..0x0C   | 16 bits | uint16 APID(11b) |
| KeyID / Slot     | 0x0D..0x0E   | 16 bits | Key Index        |
| Hop Limit (TTL)  | 0x0F         | 8 bits  | ISL Hop Counter  |
| Sequence Epoch   | 0x10..0x17   | 64 bits | uint64 TAI Us    |
| Payload Length N | 0x18..0x19   | 16 bits | uint16 Payload B |
| Command Payload  | 0x1A..End-1  | N bytes | Payload Bytes    |
| Signature Block  | (0x1A+N)..   | SigLen  | Signature Block  |
+------------------+--------------+---------+------------------+

4.2. Cryptographic Agility, Signature Scope, Deterministic IVs & HKDF AEAD Derivation

SCSP mandates explicit cryptographic agility via the 8-bit `AlgID` field, structured as a split 4-bit `SigID` (bits 0..3) and 4-bit `CipherID` (bits 4..7): AlgID = (CipherID << 4) | SigID¶

Digital Signature Algorithms (bits 0..3, `SigID`):¶

• `SigID 0x1` (PureEd25519): Ed25519 signature (64 bytes) per [RFC8032] (see also Curve25519 [RFC7748]).¶

• `SigID 0x2` (ML-DSA-65): Post-Quantum ML-DSA-65 signature (3,309 bytes) per [FIPS204].¶

• `SigID 0x3` (Hybrid Ed25519 + ML-DSA-65): Dual signature block (3,378 bytes including 5-byte sub-header).¶

AEAD Encryption Ciphers (bits 4..7, `CipherID`):¶

• `CipherID 0x0` (Plaintext): Unencrypted JSON/binary command payload.¶

• `CipherID 0x1` (AES-256-GCM): Authenticated payload encryption with 96-bit (12B) IV prepended to `Command Payload` and 128-bit (16B) AEAD Tag appended.¶

• `CipherID 0x2` (ChaCha20-Poly1305): AEAD payload encryption per [RFC8439].¶

Mandatory-To-Implement (MTI) Baseline: Conformant SCSP flight agents and ground controllers MUST support `SigID 0x1` (Ed25519) and `CipherID 0x1` (AES-256-GCM) as the baseline Mandatory-To-Implement algorithm suite. Frames declaring unsupported or reserved algorithm identifiers (`SigID 0x0`, `0x4..0xE` or unsupported `CipherID`) MUST be rejected at Stage 1 (`FRAME_PARSE`) under error code `0x0D` (`ERR_UNSUPPORTED_ALGORITHM`).¶

DETERMINISTIC 96-BIT AEAD IV & ADDITIONAL AUTHENTICATED DATA (AAD): SCSP version -00 supports exactly one encrypted application payload per SCSP frame. Consequently, no intra-frame sub-counter exists in version -00. Ground stations construct the prepended 96-bit (12-byte) AEAD IV deterministically: `IV_96 = Sequence_Epoch || KeyID || 0x0000`, where Sequence_Epoch is 8 octets and KeyID is 2 octets in Network Byte Order. The final two octets are strictly fixed to 0x0000.¶

AEAD Additional Authenticated Data (AAD) Specification: To cryptographically bind binary header routing and metadata to the AEAD encryption layer, the entire 26-byte binary header MUST be passed as AEAD Additional Authenticated Data (AAD) during AEAD encryption and decryption: AAD = Header_Bytes [0x00..0x19] (26 bytes). Ciphertext || Tag = AEAD_Encrypt(K_aead, IV_96, Plaintext, AAD). During AEAD_DECRYPT, the receiving flight computer MUST verify the 16-byte AEAD tag over (IV_96, Ciphertext, AAD). If tag verification fails or wire_iv != IV_96, the frame MUST be rejected under error code 0x08 (ERR_AEAD_DECRYPT_FAILED).¶

AEAD Nonce Invariants:¶

1. GLOBAL AEAD NONCE UNIQUENESS INVARIANT: For every symmetric AEAD key K_aead, the tuple Nonce(K_aead, Sequence_Epoch, KeyID) = Sequence_Epoch || KeyID || 0x0000 MUST NEVER repeat under key K_aead. Ground control stations MUST assign a strictly monotonic `Sequence_Epoch` to every transmitted frame under a given `KeyID`. An implementation MUST NOT reuse the tuple `(KeyID, Sequence_Epoch)` under the same AEAD key. Reusing a `Sequence_Epoch` value under the same `KeyID` is STRICTLY FORBIDDEN.¶

2. Multi-Ground-Station Key Isolation: When multiple ground stations or controllers transmit under the same key K_aead, the mission profile MUST enforce global non-overlapping sequence epoch ranges or partition `Sequence_Epoch` high bits per ground station to guarantee strict multi-sender uniqueness across all operational controllers.¶

3. Following a reboot, power brownout, or radiation reset, flight computers MUST restore monotonic sequence_epoch watermarks from radiation-hardened NVRAM/FRAM prior to accepting encrypted frames, or re-key the session.¶

MANDATORY DIGITAL SIGNATURE SCOPE: To prevent header tampering attacks (where an attacker on the RF link modifies `Sequence Epoch`, `APID`, or `NORAD ID`), digital signatures MUST be computed over the byte concatenation of the ENTIRE binary header (bytes `0x00` through `0x19`) and the Command Payload (bytes `0x1A` through `0x1A + N - 1`): `Signed_Bytes = Header_Bytes [0x00..0x19] || Command_Payload [0x1A..(0x1A + N - 1)]`¶

HYBRID SIGNATURE BINARY SUB-FRAMING (`SigID 0x3`): To eliminate parsing ambiguity inside the `Signature Block` for hybrid signatures (`SigID 0x3`), the signature block MUST use an explicit binary sub-header layout totaling 3,378 bytes: `[Ed25519_Len (16 bits: 0x0040)] [Ed25519_Sig (64 B)] [PQC_AlgID (8 bits: 0x02)] [PQC_Len (16 bits: 0x0CED)] [PQC_Sig (3,309 B)]`¶

4.3. SCSP Key Establishment & Out-of-Band Key Management

SCSP version -00 does not specify an on-wire key-establishment protocol. AEAD symmetric keys MUST be provisioned or established through a mission-approved mechanism prior to telecommand transmission. Static-static X25519 ECDH [RFC7748] with HKDF-SHA256 [RFC5869] is an optional out-of-band key-establishment mechanism and is outside the SCSP wire protocol:¶

1. Out-of-Band X25519 Key Derivation: When X25519 key derivation is selected by the mission profile, ground control stations and spacecraft flight computers calculate a shared secret Z = X25519(sk_ground_x25519, pk_sat_x25519).¶

2. Normative AEAD Key Derivation (HKDF-Extract & HKDF-Expand): Ground stations and flight computers derive the 256-bit symmetric AEAD key (K_aead) from shared secret Z using HKDF [RFC5869] with a 32-zero-byte salt and normative info string "SCSP-Payload-AEAD-v1": PRK = HKDF-Extract(Salt_32zero, Z), K_aead = HKDF-Expand(PRK, "SCSP-Payload-AEAD-v1", 32).¶

4.4. Spacecraft Execution State Machine, Configurable NVRAM Windows & Error Codes (0x01..0x0C)

Spacecraft flight computers MUST process SCSP frames through a strict 9-stage execution state machine supporting AEAD decryption, payload consistency validation, and profile-driven conditional attestation:¶

IDLE --> FRAME_PARSE --> KEY_INDEX --> EPOCH_VERIFY -->
         SIGNATURE_VERIFY
          |
   [CipherID != 0?] --> YES: AEAD_DECRYPT --> PAYLOAD_VALIDATE
          |                                        |
          +-------------- NO (Plaintext) ----------+
                                                   |
            [Attestation?] --> YES: ATTESTATION_CHECK --+
                                    |                   |
                                    +-- NO -> AUTH_CHECK -> EXECUTE

Execution Processing Stages:¶

1. FRAME_PARSE: Validates Magic Header (`0x53 0x43`), Version (`0x01`), 11-bit APID zero-padding (`0b00000`), payload length bounds (`N >= 28` if encrypted), supported algorithm suite (`0x0D`), frame length consistency (`0x01`), and non-zero Hop Limit TTL (`0x06`). (TTL decrement is performed by intermediate ISL forwarding nodes only, per Section 5.3.)¶

2. KEY_INDEX: Looks up `KeyID` in Onboard Key Cache (`0x05`). Verifies key revocation status (`0x07`). For emergency KRL control frames, evaluates monotonic `krl_sequence_number` against `nvram.krl_sequence_number` (`0x09`). `KeyID 0x0000` is strictly reserved for Master Emergency Key.¶

3. EPOCH_VERIFY (Read-Only Tentative Evaluation): Evaluates continuous TAI microsecond timestamp against NVRAM sliding window bitmask (W in {64, 256, 1024} bits) (`0x02`). `EPOCH_VERIFY` is a read-only, tentative check performed prior to `SIGNATURE_VERIFY` to drop replayed or expired packets in O(1) time without writing to NVRAM or wasting CPU cycles on signature verification.¶

4. SIGNATURE_VERIFY & ATOMIC TRANSIENT RESERVATION: Verifies Ed25519 / ML-DSA-65 / Hybrid digital signature over `Signed_Bytes` (`0x03`). Atomically reserves `sequence_epoch` in transient volatile memory to prevent concurrent transmission races.¶

5. AEAD_DECRYPT (If CipherID != 0): Decrypts payload ciphertext using K_aead and verifies 16-byte AEAD authentication tag (`0x08`).¶

6. PAYLOAD_VALIDATE & CROSS_LAYER_HEADER_CHECK: If `mission_profile.sdls_integration_mode == DIRECT_OVERLAY`, cross-verifies that outer physical CCSDS Transfer Frame Primary Header fields (`SCID`, `VCID`) match inner signed SCSP header fields (`SCID`, `VCID`) byte-for-byte; rejects mismatch under `0x0C` (`ERR_LINK_HEADER_MISMATCH`). Parses JSON payload (`command.json` per RFC 7493) and verifies that duplicated metadata fields match binary header values exactly (`0x0B`).¶

7. ATTESTATION_CHECK (Profile-Driven): Validates TPM 2.0 / TEE quote if provisioned; skips if unconfigured (`0x04`).¶

8. AUTHORIZATION_CHECK: Evaluates `KeyID` against Onboard Authorization Policy Matrix (verifying SCID, VCID, APID, and Command Class privileges) (`0x0A`).¶

9. EXECUTE: Dispatches command payload to FSW sub-system handler and updates NVRAM sequence watermark atomically.¶

Normative State Machine Pseudocode:¶

def process_scsp_frame(frame_bytes, outer_ccsds_header=None):
    # Stage 1: FRAME_PARSE
    if len(frame_bytes) < 26:
        return drop_silently(ERR_INVALID_MAGIC) # 0x01
    header = parse_binary_header(frame_bytes[0:26])
    if header.magic != 0x5343 or header.version != 0x01:
        return drop_silently(ERR_INVALID_MAGIC) # 0x01
    if header.sig_id not in mission_profile.supported_sig_ids or \
       header.cipher_id not in mission_profile.supported_cipher_ids:
        return drop_silently(ERR_UNSUPPORTED_ALGORITHM) # 0x0D
    expected_sig_len = get_signature_length(header.sig_id)
    if len(frame_bytes) != 26 + header.payload_len + expected_sig_len:
        return drop_silently(ERR_INVALID_MAGIC) # 0x01
    if header.ttl == 0:
        return drop_silently(ERR_TTL_EXPIRED) # 0x06
    if header.cipher_id != 0 and header.payload_len < 28:
        return drop_silently(ERR_AEAD_DECRYPT_FAILED) # 0x08

    # Stage 2: KEY_INDEX & KRL_CHECK
    key_entry = onboard_key_cache.get(header.key_id)
    if key_entry is None:
        return drop_silently(ERR_KEY_ID_NOT_FOUND) # 0x05
    if key_entry.is_revoked:
        return drop_silently(ERR_KEY_REVOKED) # 0x07
    if is_krl_frame(header) and \
       header.krl_seq <= nvram.krl_sequence_number:
        return drop_silently(ERR_KRL_REPLAY) # 0x09

    # Stage 3: EPOCH_VERIFY (Read-Only Tentative Check; no NVRAM writes)
    if not is_valid_epoch_window(header.key_id,
                                header.sequence_epoch):
        return drop_silently(ERR_EPOCH_EXPIRED) # 0x02

    # Stage 4: SIGNATURE_VERIFY & ATOMIC TRANSIENT RESERVATION
    signed_bytes = frame_bytes[0 : 26 + header.payload_len]
    sig_bytes = frame_bytes[26 + header.payload_len :]
    if not crypto_verify(key_entry.pubkey, signed_bytes,
                         sig_bytes, header.sig_id):
        return drop_silently(ERR_SIGNATURE_INVALID) # 0x03

    if not atomic_reserve_transient_sequence(
            header.key_id, header.sequence_epoch):
        return drop_silently(ERR_EPOCH_EXPIRED) # Replay

    # Stage 5: AEAD_DECRYPT (If encrypted with Header AAD)
    if header.cipher_id != 0:
        wire_iv = frame_bytes[26 : 38]
        expected_iv = build_iv(header.sequence_epoch,
                               header.key_id, 0x0000)
        if wire_iv != expected_iv:
            commit_nvram_sequence_watermark(
                header.key_id, header.sequence_epoch)
            return drop_silently(ERR_AEAD_DECRYPT_FAILED) # 0x08
        ct_bytes = frame_bytes[38 : 26 + header.payload_len]
        aad_bytes = frame_bytes[0:26]
        plaintext = aead_decrypt(key_entry.k_aead,
                                 wire_iv, ct_bytes, aad_bytes)
        if plaintext is None:
            commit_nvram_sequence_watermark(
                header.key_id, header.sequence_epoch)
            return drop_silently(ERR_AEAD_DECRYPT_FAILED) # 0x08
    else:
        plaintext = frame_bytes[26 : 26 + header.payload_len]

    # Stage 6: PAYLOAD_VALIDATE & CROSS_LAYER_HEADER_CHECK
    if mission_profile.sdls_integration_mode == "DIRECT_OVERLAY":
        if outer_ccsds_header is None:
            commit_nvram_sequence_watermark(
                header.key_id, header.sequence_epoch)
            return send_signed_telemetry_error(
                ERR_LINK_HEADER_MISMATCH) # 0x0C
        if (outer_ccsds_header.scid != header.scid or
            outer_ccsds_header.vcid != header.vcid):
            commit_nvram_sequence_watermark(
                header.key_id, header.sequence_epoch)
            return send_signed_telemetry_error(
                ERR_LINK_HEADER_MISMATCH) # 0x0C

    if is_json(plaintext):
        cmd_json = parse_jcs(plaintext)
        if not metadata_matches_header(cmd_json, header):
            commit_nvram_sequence_watermark(
                header.key_id, header.sequence_epoch)
            return send_signed_telemetry_error(
                ERR_PAYLOAD_METADATA_MISMATCH) # 0x0B

    # Stage 7: ATTESTATION_CHECK
    if mission_profile.attestation_required:
        if not verify_tpm_quote(cmd_json.attestation):
            commit_nvram_sequence_watermark(
                header.key_id, header.sequence_epoch)
            return send_signed_telemetry_error(
                ERR_TPM_QUOTE_FAILED) # 0x04

    # Stage 8: AUTHORIZATION_CHECK
    if not check_policy_matrix(key_entry.policy, header):
        commit_nvram_sequence_watermark(
            header.key_id, header.sequence_epoch)
        return send_signed_telemetry_error(
            ERR_AUTHORIZATION_DENIED) # 0x0A

    # Stage 9: EXECUTE & ATOMIC NVRAM COMMIT
    result = dispatch_subsystem_command(cmd_json)
    commit_nvram_sequence_watermark(header.key_id,
                                    header.sequence_epoch)
    return send_signed_telemetry_success(result)

KEYID-ISOLATED CONFIGURABLE-WIDTH NVRAM SLIDING-WINDOW REPLAY PERSISTENCE: The flight computer maintains independent radiation-hardened Sliding-Window Bitmasks in NVRAM / FRAM scoped per `KeyID` namespace. The sliding-window bitmask size W is configurable per mission profile (W in {64, 256, 1024} bits). Key rotation or revocation events MUST NOT reset epoch sequence watermarks; sequence numbers remain strictly monotonic per `KeyID`.¶

Mathematical Sliding-Window Bitmask Equations (Tentative Stage 3 Evaluation): The following equations describe the read-only, tentative evaluation performed at Stage 3 (EPOCH_VERIFY). Writes to NVRAM (Bitmask, S_max) are strictly deferred until post-signature validation commit semantics. Let S be the incoming continuous TAI microsecond sequence_epoch, S_max be the highest verified sequence epoch committed in NVRAM for that KeyID, and W be the bitmask window width in bits.¶

• Case 1: In-Order Arrival (S > S_max): Shift = S - S_max. Tentatively evaluate new_Bitmask = (Bitmask << Shift) | 1, and new_S_max = S. The window tentatively advances rightward by Shift bits, bit 0 is set to 1, and S_max is updated to S upon commit.¶

• Case 2: Out-of-Order Arrival Within Window (S_max - W < S <= S_max): Bit index k = S_max - S (0 <= k < W). If bit k == 1, REJECT frame as duplicate replay under error code 0x02 (ERR_EPOCH_EXPIRED). If bit k == 0, ACCEPT out-of-order frame and set bit k <- 1.¶

• Case 3: Expired Frame (S <= S_max - W): Frame is older than window boundary. REJECT immediately under error code 0x02 (ERR_EPOCH_EXPIRED).¶

REPLAY PROTECTION CLAIM VS. COMMIT SEMANTICS & ATOMIC RESERVATION: Atomic Transient Sequence Reservation (Stage 4): Immediately after successful digital signature verification (`SIGNATURE_VERIFY`), the sequence reservation operation MUST be atomic with respect to all spacecraft frame-processing contexts. The flight computer atomically claims `sequence_epoch` in transient volatile memory. Only the first frame successfully claiming a `(KeyID, Sequence_Epoch)` tuple MAY proceed to decryption and execution. Concurrent or duplicate frames attempting to claim an already reserved tuple MUST be rejected immediately as replays under error code `0x02` (`ERR_EPOCH_EXPIRED`). Atomic FRAM/NVRAM Watermark Commit (Stage 9): Sequence watermarks and sliding-window bitmasks are written atomically to radiation-hardened FRAM/NVRAM strictly at `EXECUTE` (Stage 9). Exactly-Once Acceptance & Error State Retention: If an authenticated frame fails authorization (`0x0A ERR_AUTHORIZATION_DENIED`), payload parity checks (`0x0B`), outer link header validation (`0x0C`), or attestation (`0x04`), the reserved sequence number remains permanently consumed in transient memory and is committed to NVRAM to prevent retransmission of unauthorized or invalid telecommands.¶

MONOTONIC NVRAM-PROTECTED EMERGENCY TIME-RESYNCHRONIZATION FALLBACK: Emergency Time-Resynchronization commands MUST include a 64-bit monotonic `master_resync_counter`. The flight computer ONLY accepts resync commands where `cmd.master_resync_counter > nvram.master_resync_counter`, updating its RTC baseline and atomically incrementing `nvram.master_resync_counter` in NVRAM upon execution.¶

Error Codes:¶

• `0x01` (ERR_INVALID_MAGIC): Frame header magic bytes, protocol version, or frame length check failed.¶

• `0x02` (ERR_EPOCH_EXPIRED): Epoch timestamp outside sliding window or OWLT ephemeris.¶

• `0x03` (ERR_SIGNATURE_INVALID): Cryptographic signature check failed.¶

• `0x04` (ERR_TPM_QUOTE_FAILED): Hardware enclave quote check failed.¶

• `0x05` (ERR_KEY_ID_NOT_FOUND): KeyID not present in Onboard Key Cache.¶

• `0x06` (ERR_TTL_EXPIRED): ISL Mesh Hop Limit reached zero.¶

• `0x07` (ERR_KEY_REVOKED): KeyID is present in onboard cache but revoked by Master KRL.¶

• `0x08` (ERR_AEAD_DECRYPT_FAILED): AEAD payload authentication tag check or ciphertext decryption failed (or N < 28 for encrypted frame).¶

• `0x09` (ERR_KRL_REPLAY): Master KRL frame sequence counter less than or equal to nvram.krl_sequence_number.¶

• `0x0A` (ERR_AUTHORIZATION_DENIED): Telecommand failed onboard Authorization Policy Matrix verification (unauthorized SCID, VCID, APID, or command class).¶

• `0x0B` (ERR_PAYLOAD_METADATA_MISMATCH): Decrypted payload JSON metadata field does not match authoritative binary header field.¶

• `0x0C` (ERR_LINK_HEADER_MISMATCH): Outer physical CCSDS Transfer Frame Primary Header (SCID, VCID) does not match inner signed SCSP binary header fields under Direct Overlay Mode.¶

• `0x0D` (ERR_UNSUPPORTED_ALGORITHM): Declared SigID or CipherID is not supported by the mission profile or uses reserved/unassigned algorithm identifiers.¶

4.5. Onboard Command Authorization Policy Matrix

SCSP explicitly separates Command Authentication (signature verification) from Command Authorization (privilege verification):¶

• Authentication verifies: "This telecommand was signed by ground controller KeyID X."¶

• Authorization verifies: "KeyID X is explicitly permitted to issue telecommands to target SCID, VCID, APID, and Command Class."¶

Every entry in the Onboard Key Cache MUST include a normative Authorization Policy Record. Formal structure:¶

Authorization_Record {
    uint16 key_id;
    uint8  public_key_bytes[];
    uint32 allowed_scid[];
    uint8  allowed_vcid[];
    uint16 allowed_apid[];
    uint8  allowed_command_classes[];
    uint64 validity_not_before; // Continuous TAI Microseconds
    uint64 validity_not_after;  // Continuous TAI Microseconds
    uint32 policy_version;
}

JSON Representation in Key Cache:¶

{
  "key_id": 1,
  "public_key": "ed25519:z99aP...",
  "allowed_scid": [10492],
  "allowed_vcid": [2, 3],
  "allowed_apid": [104, 105],
  "allowed_command_classes": ["TELEMETRY_READ", "PAYLOAD_CONTROL"],
  "validity_not_before": 1788500000000000,
  "validity_not_after": 1820000000000000,
  "policy_version": 1
}

Flight computers MUST evaluate incoming telecommands against the caller's Authorization Policy Record during the `AUTHORIZATION_CHECK` stage prior to command dispatching. Telecommands attempting unauthorized APID or command class access MUST be rejected under error code `0x0A` (`ERR_AUTHORIZATION_DENIED`). The command class identifiers (e.g. `"TELEMETRY_READ"`, `"PAYLOAD_CONTROL"`) specified in Authorization Policy Records are mission-profile defined strings. Profiles MAY define an explicit registry or schema for mission-specific command classes.¶

4.6. Complete Example Payload Document (command.json, I-JSON RFC 7493)

All JSON command payloads MUST strictly conform to the I-JSON message format ([RFC7493]). Any URI-valued fields (such as `target_spacecraft`) MUST be in SCSP URI Canonical Form (per Section 3.3) prior to applying JSON Canonicalization Scheme ([RFC8785] JCS) for digital signature calculation.¶

{
  "version": "1.0",
  "target_spacecraft":
    "scsp://norad-48219.orbit.spacecraft/subsystem/thruster",
  "norad_id": 48219,
  "key_id": 1,
  "ccsds_routing": {
    "scid": 10492,
    "vcid": 2,
    "apid": 104
  },
  "sequence_epoch": 1788500000000000,
  "alg_id": 17,
  "command_payload": {
    "action": "orbit_correction",
    "delta_v_ms": 1.25,
    "burn_duration_sec": 4.2
  },
  "execution_attestation": {
    "required_tpm_pcr_hash": "sha256:8f31b...",
    "key_slot_id": "slot-01",
    "nonce": "c901a8f2e104b"
  },
  "signature": {
    "type": "Ed25519Signature2020",
    "created": "2026-09-04T01:00:00Z",
    "verificationMethod":
      "scsp://ground-station-alpha.idevsec.space/keys/1",
    "proofValue": "z99aP...kL04=="
  }
}

4.7. Complete Example Telemetry Document (telemetry.json, Signed Error Responses)

ALL telemetry response frames generated for authenticated commands MUST be cryptographically signed by the spacecraft's hardware-bound key (`sk_sat`). To prevent battery and RF downlink exhaustion Denial-of-Service attacks, flight computers MUST NOT generate or transmit signed telemetry response frames for unauthenticated or malformed frames (e.g. `0x01 ERR_INVALID_MAGIC`, `0x03 ERR_SIGNATURE_INVALID`, `0x05 ERR_KEY_ID_NOT_FOUND`). Unauthenticated frames MUST be dropped silently or logged to local internal diagnostic registers. Signed telemetry error responses are generated strictly for authenticated telecommands that fail authorization (`0x0A ERR_AUTHORIZATION_DENIED`) or sub-system execution.¶

{
  "version": "1.0",
  "source_spacecraft": "scsp://norad-48219.orbit.spacecraft",
  "norad_id": 48219,
  "sequence_epoch": 1788500000000500,
  "status": "SUCCESS",
  "execution_result": {
    "command_apid": 104,
    "execution_status_code": 0,
    "delta_v_achieved_ms": 1.25
  },
  "hardware_attestation": {
    "tpm_version": "2.0",
    "pcr_quote": "9f8a1b02...",
    "quote_signature": "z88bQ...mL05=="
  },
  "signature": {
    "type": "Ed25519Signature2020",
    "created": "2026-09-04T01:00:00Z",
    "verificationMethod":
      "scsp://norad-48219.orbit.spacecraft/keys/sat-1",
    "proofValue": "a77bR...mM09=="
  }
}

4.8. Normative Binary Test Vectors

To ensure full wire-format interoperability across independent implementations (e.g. FreeRTOS, NASA cFS, Rust `libscsp`), this section provides an authoritative 26-byte binary header test vector, deterministic AEAD IV, and AAD byte layout.¶

Test Vector Parameters:¶

• Magic Header: ASCII "SC" (`0x53 0x43`)¶

• Version: `0x01`¶

• AlgID: `0x11` (CipherID `0x1` AES-256-GCM + SigID `0x1` PureEd25519)¶

• NORAD Catalog ID: `48219` (`0x0000BC5B`)¶

• CCSDS SCID: `10492` (`0x28FC`)¶

• CCSDS VCID: `2` (`0x02`)¶

• CCSDS APID: `104` (`0x0068`, 11-bit active integer)¶

• KeyID / Slot: `1` (`0x0001`)¶

• Hop Limit (TTL): `16` (`0x10`)¶

• Sequence Epoch: `1788500000000000` continuous TAI microseconds (`0x000659652298C000`)¶

• Payload Length N: `28` bytes (`0x001C`)¶

Canonical 26-Byte Binary Header Hex Stream:¶

534301110000BC5B28FC020068000110000659652298C000001C

Derived 96-Bit AEAD IV Hex Stream (`IV_96`):¶

000659652298C00000010000

AEAD Additional Authenticated Data Hex Stream (`AAD`):¶

534301110000BC5B28FC020068000110000659652298C000001C

5.1. Dual-Mode CCSDS 355.0-B-2 (SDLS) SPI & Extended Security Header Mapping

Per CCSDS 355.0-B-2 [CCSDS355] and CCSDS 355.1-B-1 [CCSDS3551], SCSP integrates directly into SDLS frames under dual operation modes:¶

• Native SDLS SA Table Mode (Recommended): The 16-bit SDLS Security Parameter Index (SPI) acts as an opaque index into the onboard SDLS Security Association (SA) database table. KeyID and AlgID are bound to the specific SA record ground-side and onboard. SDLS's native Message Authentication Code (MAC) covers the physical CCSDS Transfer Frame Primary Header (outer SCID, VCID, Frame Count), providing link-layer tamper protection. When operating in Native SDLS SA Table Mode, SDLS's native MAC occupies the SDLS Security Trailer (ST) to authenticate physical frame headers. Consequently, the SCSP application-layer digital signature block (64-byte Ed25519, 3,309-byte ML-DSA-65, or 3,378-byte Hybrid) is appended as a suffix inside the SDLS Protected Data Field, forming a complete end-to-end SCSP application envelope (`Header || Payload || Signature`) encapsulated within SDLS protection.¶

• Direct SCSP Overlay Mode: The 16-bit SDLS SPI field directly carries `AlgID` (bits 0..7) and `Version` (bits 8..15). Digital signatures cover the inner 26-byte SCSP header and command payload. Mandatory cross-layer header matching (`PAYLOAD_VALIDATE`) verifies physical link headers against inner signed SCSP headers (`SCID`, `VCID`) to prevent outer header routing spoofing under error code `0x0C` (`ERR_LINK_HEADER_MISMATCH`).¶

• SDLS Extended Security Header (ESH): Total ESH field width is profile-configurable; this document does not mandate a fixed ESH byte count.¶

Table 1: Native SDLS SA Table Mode Field Mapping (CCSDS 355.0-B-2)¶

• Security Parameter Index (SPI): 16-bit uint16 Opaque SA Table Index.¶

• SDLS Security Association (SA) Entry: Onboard SA Database Record (binds KeyID & AlgID).¶

• Extended Security Header (ESH) Seq: 64-bit uint64 ESH Anti-Replay Counter.¶

• Extended Security Header (ESH) Aux: 8-bit uint8 ESH Sub-Field (Hop Limit / TTL).¶

• SDLS Protected Data Field: SCSP 26-Byte Header + Command Payload (Encrypted / Plaintext Data).¶

• SDLS Protected Data Field (Suffix): SCSP Digital Signature Block (64B / 3309B / 3378B Application Suffix).¶

• SDLS Security Trailer (ST): SDLS Native MAC (AES-GCM / AES-CMAC outer header check).¶

Table 2: Direct SCSP Overlay Mode Field Mapping¶

• Security Parameter Index (SPI): 16-bit uint16 (AlgID: bits 0..7, Version: bits 8..15).¶

• SDLS Security Association (SA) Index: 16-bit uint16 SA Table Index / KeyID Slot.¶

• Extended Security Header (ESH) Seq: 64-bit uint64 ESH Anti-Replay Counter.¶

• Extended Security Header (ESH) Aux: 8-bit uint8 ESH Sub-Field (Hop Limit / TTL).¶

• SDLS Protected Data Field: Command Payload (N Bytes Encrypted / Plaintext Data).¶

• SDLS Security Trailer (ST): 64B / 3309B / 3378B Signature Block (Ed25519 / ML-DSA-65).¶

5.2. Profile-Driven Hardware Root-of-Trust (TPM 2.0 / TEE)

Spacecraft hardware attestation is an OPTIONAL, profile-driven capability. When provisioned in mission profiles, flight computers bind command execution to hardware TPM 2.0 or radiation-hardened Trusted Execution Enclaves (TEE).¶

3-STEP ATTESTATION QUOTE VERIFICATION ALGORITHM: When attestation_required is enabled in the active mission profile, the flight computer MUST execute a strict 3-step verification process during Stage 7 (`ATTESTATION_CHECK`):¶

1. Endorsement Signature Verification: Verify the digital signature on the attestation quote against the manufacturer or mission-provisioned Root CA certificate chain bound to the hardware enclave's Endorsement Key (EK).¶

2. Measurement Baseline Verification: Extract the Platform Configuration Registers (PCR) measurement vector from the quote and verify that the PCR digest matches the expected system software baseline (`required_tpm_pcr_hash`).¶

3. Nonce & Header/Payload Binding: Verify that the freshness nonce embedded in the attestation quote strictly matches the SHA-256 hash over the binary frame header and payload: Attestation_Nonce = SHA-256(Header_Bytes [0x00..0x19] || Command_Payload). When TPM 2.0 or TEE quotes are embedded in JSON payload documents (`command.json`), the attestation `nonce` field MUST contain the hex-encoded string of raw bytes `Attestation_Nonce` to bind the quote to the frame envelope.¶

An attestation quote failing any of these three verification steps MUST cause immediate command rejection under error code 0x04 (ERR_TPM_QUOTE_FAILED).¶

Unconfigured platforms skip `ATTESTATION_CHECK` and execute based on signature authentication and authorization matrix verification.¶

5.3. Inter-Satellite Link Forwarding and Hop Limits

SCSP does not specify link-layer mutual authentication protocols in version -00; link-layer security for optical/RF ISL meshes is mission-profile specific. When an SCSP frame is forwarded through an authorized ISL mesh, each forwarding node MUST decrement `Hop Limit` exactly once before forwarding. A frame received with `Hop Limit == 0` MUST NOT be forwarded under error code 0x06 (ERR_TTL_EXPIRED).¶

6.1. LEO vs Deep-Space Adaptive Epoch Windowing (OWLT & TAI Conversion)

SCSP adapts epoch timestamp verification based on the orbital mission profile. Stage 3 (`EPOCH_VERIFY`) MUST execute a unified 2-step verification algorithm:¶

STEP 1: CONTINUOUS TAI TIMESTAMP WINDOW VALIDATION¶

• LEO Profile: Enforces a strict time window between the incoming continuous TAI microsecond timestamp S and local spacecraft clock t_local: |S - t_local| <= delta_t_clock + Doppler.¶

• Deep-Space Profile: For deep-space missions with significant propagation delays, the receipt window formula distinguishes physical propagation time from timing uncertainties: Expected_Receipt_Epoch = Ground_Transmit_Epoch + OWLT, and Acceptance_Window = Expected_Receipt_Epoch +/- (delta_t_clock + delta_t_ephemeris + delta_t_margin), where OWLT is the computed One-Way Light Time delay, delta_t_clock accounts for clock drift and Doppler time-transfer error, delta_t_ephemeris accounts for spacecraft ephemeris position uncertainty, and delta_t_margin provides implementation margin. These parameters MUST NOT be combined into a single static tolerance.¶

• TAI Monotonic Conversion: Microsecond timestamps MUST perform TAI leap-second conversion (TAI = UTC + delta_t_LS).¶

STEP 2: KEYID-ISOLATED SLIDING-WINDOW BITMASK CHECK: Immediately following timestamp window validation, the flight computer evaluates sequence epoch S against the KeyID-scoped NVRAM sliding window bitmask W using the mathematical equations specified in Section 4.4. If S is expired (S <= S_max - W) or indicates a duplicate replay (bit k == 1), the frame MUST be rejected under error code 0x02 (ERR_EPOCH_EXPIRED).¶

6.2. Ground Station Authentication and Doppler Drift Mitigation

Ground stations MUST prove ownership of registered public keys before spacecraft accept uplink sessions. Ground-station authentication and session handshake mechanics are mission-profile specific.¶

7.1. Provisional URI Scheme Registration ('scsp')

The 'scsp' URI scheme registration follows procedures defined in BCP 35 [RFC7595] for Provisional registration:¶

Scheme name:
   scsp

Status:
   Provisional

Applications:
   Space cybersecurity, satellite telecommand authentication,
   constellation mesh protection.

Contact:
   kushaan Dua <kushaan@idevsec.com>

Change controller:
   kushaan Dua <kushaan@idevsec.com> (Provisional Registrant)

References:
   draft-dua-scsp-space-uri-00

7.2. SCSP Signature Algorithm Registry

If SCSP is standardized, IANA is requested to create the "SCSP Signature Algorithm Registry":¶

• `0x0`: Reserved¶

• `0x1`: PureEd25519 (RFC 8032)¶

• `0x2`: ML-DSA-65 (FIPS 204)¶

• `0x3`: Hybrid Ed25519 + ML-DSA-65¶

• `0x4..0xE`: Unassigned (Specification Required per [RFC8126])¶

• `0xF`: Private / Experimental Use¶

7.3. SCSP Cipher Algorithm Registry

If SCSP is standardized, IANA is requested to create the "SCSP Cipher Algorithm Registry":¶

• `0x0`: Plaintext (Unencrypted)¶

• `0x1`: AES-256-GCM (NIST SP 800-38D)¶

• `0x2`: ChaCha20-Poly1305 (RFC 8439)¶

• `0x3..0xE`: Unassigned¶

• `0xF`: Private / Experimental Use¶

7.4. SCSP Error Code Registry

If SCSP is standardized, IANA is requested to create the "SCSP Error Code Registry":¶

• `0x01` (ERR_INVALID_MAGIC), `0x02` (ERR_EPOCH_EXPIRED), `0x03` (ERR_SIGNATURE_INVALID), `0x04` (ERR_TPM_QUOTE_FAILED), `0x05` (ERR_KEY_ID_NOT_FOUND), `0x06` (ERR_TTL_EXPIRED), `0x07` (ERR_KEY_REVOKED), `0x08` (ERR_AEAD_DECRYPT_FAILED), `0x09` (ERR_KRL_REPLAY), `0x0A` (ERR_AUTHORIZATION_DENIED), `0x0B` (ERR_PAYLOAD_METADATA_MISMATCH), `0x0C` (ERR_LINK_HEADER_MISMATCH), `0x0D` (ERR_UNSUPPORTED_ALGORITHM).¶

8.1. Threat Matrix and Space Adversary Capabilities

Per [RFC3552], the protocol evaluates defenses against:¶

• Telecommand Spoofing: Defended via Ed25519 / ML-DSA-65 signatures (derived from CRYSTALS-Dilithium).¶

• RF Replay Attacks: Defended via NVRAM-persisted sliding-window sequence counters.¶

• Telemetry Poisoning: Defended via cryptographic frame signing.¶

• Rogue Ground Station Injection: Defended via signed onboard key caches and authorization matrices.¶

8.2. Command Hijacking and Thruster Tampering Mitigation

Enforcing Zero-Trust Telecommand & Telemetry Authentication (ZTTA) ensures that unauthenticated uplink signals cannot manipulate satellite attitude, orbit, or propulsion.¶

Outer CCSDS Link Header Tampering Defense: An RF adversary might attempt to tamper with outer physical CCSDS Transfer Frame Primary Header fields (such as physical Spacecraft ID or Virtual Channel ID) on the space link without modifying the inner SCSP payload. When SCSP operates in Native SDLS Mode, physical frame headers are cryptographically authenticated by SDLS's native Message Authentication Code (MAC). When SCSP operates in Direct Overlay Mode (where SDLS MAC is inactive), physical header tampering is neutralized through mandatory cross-layer header verification: the inner 26-byte SCSP binary header explicitly includes `SCID` (Offset `0x08..0x09`) and `VCID` (Offset `0x0A`) fields that are signed by the digital signature (`SigID`) and bound as Additional Authenticated Data (`AAD`) in AEAD frames. Flight computers MUST verify byte-for-byte identity between outer physical link headers and inner signed SCSP headers during Stage 6 (`PAYLOAD_VALIDATE`). Any physical link header modification forces immediate frame rejection under error code `0x0C` (`ERR_LINK_HEADER_MISMATCH`).¶

8.3. In-Pass Master Key Revocation and Emergency Safe-Mode Recovery

Master KRL frames include a 64-bit monotonic `krl_sequence_number` stored in spacecraft OTP/NVRAM. Any out-of-band safe-mode mechanism is mission-specific and is not defined by SCSP.¶

8.4. Secret-Dependent Constant-Time Execution & Microarchitectural Protection

Embedded flight computers (e.g. ARM Cortex-R5, LEON4, RISC-V) MUST use cryptographic implementations appropriate to the target processor and threat model, including constant-time or otherwise side-channel-resistant operations where secret-dependent timing or memory access could reveal key material. The protocol does not assume that an RF observer can directly measure individual instruction timing.¶

8.5. Zero-Payload (N=0) Boundary Enforcement & Resource Exhaustion Defense

To mitigate Denial-of-Service (DoS) attacks targeting onboard processor resource exhaustion, flight computers MUST validate frame header bounds prior to allocating memory or triggering cryptographic operations. Frames declaring N=0 MUST NOT allocate payload memory buffers. For an unencrypted frame, signature verification covers exactly the 26-byte header. An encrypted empty plaintext is represented by N=28 and is not a zero-payload frame.¶

8.6. Key Establishment Considerations & Downlink Exhaustion Mitigation

SCSP version `-00` does not define an on-wire key-establishment protocol. AEAD symmetric keys MUST be provisioned or established through a mission-approved out-of-band mechanism. When static-static X25519 ECDH key establishment is used out-of-band for encrypted payloads (`CipherID != 0`), it is combined with deterministic 96-bit nonces (`Sequence_Epoch || KeyID || 0x0000`). This design enables non-interactive single-frame telecommand encryption over asymmetric high-latency space links without multi-roundtrip handshakes. However, static-static keying does not provide perfect forward secrecy (PFS). Mission profiles MUST mandate periodic controller key rotation via Master Root re-keying to bound key exposure. Furthermore, to prevent battery and RF downlink exhaustion DoS attacks, flight computers MUST NOT generate or downlink signed telemetry error responses for unauthenticated frames (`0x01`, `0x03`, `0x05`); unauthenticated frames MUST be dropped silently.¶