Satellite Communication Protocols Deep Dive | Satellite Security

Overview

Satellite communication protocols govern every aspect of how data moves between ground stations, spacecraft, and end users. Unlike terrestrial networking stacks that evolved with decades of security iteration, many satellite protocols were designed in an era where the cost of access was itself considered a security barrier. That assumption has collapsed. Software-defined radios cost under $30, satellite signal databases are publicly indexed, and open-source demodulation tools have democratized interception.

This page dissects the major protocol families used across commercial, civil, and military satellite systems. For each, we examine the frame structure, authentication mechanisms (or lack thereof), encryption capabilities, and known weaknesses that attackers exploit today. Understanding these protocols at the bit level is a prerequisite for both offensive satellite security testing and meaningful defensive architecture.

For how these protocol weaknesses translate into practical attacks, see the Attack Vectors & Threat Landscape page.

1. CCSDS Protocol Suite

The Consultative Committee for Space Data Systems (CCSDS) defines the dominant protocol standards used by virtually all space agencies — NASA, ESA, JAXA, ISRO, CNSA — and an increasing number of commercial operators. CCSDS specifications cover everything from physical-layer coding to application-layer file transfer.

Protocol Stack Architecture

The CCSDS protocol stack mirrors the OSI model but with space-specific adaptations at every layer. Understanding the full stack is essential because security controls (or their absence) at one layer directly affect the threat model of layers above and below.

graph TB
    subgraph "CCSDS Protocol Stack"
        direction TB
        A["Application Layer<br/>CCSDS File Delivery Protocol (CFDP)<br/>Asynchronous Message Service (AMS)<br/>Mission-specific applications"]
        B["Transport / Network Layer<br/>Space Packet Protocol<br/>Encapsulation Service<br/>Bundle Protocol (DTN)"]
        C["Security Layer<br/>Space Data Link Security (SDLS)<br/>CCSDS Cryptographic Algorithms"]
        D["Data Link Layer<br/>TM Transfer Frame<br/>TC Transfer Frame<br/>AOS Transfer Frame<br/>Proximity-1"]
        E["Synchronization & Coding<br/>Frame Sync / ASM<br/>Reed-Solomon / LDPC / Turbo<br/>Randomization"]
        F["Physical Layer<br/>RF Modulation (BPSK, QPSK, 8PSK)<br/>Carrier Frequency & Bandwidth"]
    end
    A --> B --> C --> D --> E --> F

    style A fill:#1a1a2e,stroke:#e94560,color:#eee
    style B fill:#1a1a2e,stroke:#e94560,color:#eee
    style C fill:#1a1a2e,stroke:#0f3460,color:#eee
    style D fill:#1a1a2e,stroke:#e94560,color:#eee
    style E fill:#1a1a2e,stroke:#e94560,color:#eee
    style F fill:#1a1a2e,stroke:#e94560,color:#eee

Telemetry (TM) Transfer Frames

Telemetry frames carry data from spacecraft to ground. The TM frame is defined in CCSDS 132.0-B and has a fixed structure:

Field	Size (bits)	Purpose
Transfer Frame Version	2	Protocol version identifier
Spacecraft ID	10	Identifies the transmitting spacecraft
Virtual Channel ID	3	Multiplexes logical channels
OCF Flag	1	Indicates Operational Control Field presence
Master Channel Frame Count	8	Sequence counter for all VCs
Virtual Channel Frame Count	8	Per-VC sequence counter
TF Data Field Status	16	First Header Pointer, sync flags
Data Field	Variable (up to 8920 bits)	Payload data
Operational Control Field	32	Optional: CLCW for TC feedback
Frame Error Control	16	CRC-16-CCITT

Security implications: The Spacecraft ID and Virtual Channel ID are transmitted in the clear and are not authenticated in legacy implementations. An attacker who can receive telemetry can trivially identify the spacecraft, determine the virtual channel allocation scheme, and map the operational profile. The frame counters enable traffic analysis — monitoring frame count gaps reveals periods of activity and silence, which may correlate with mission operations.

Telecommand (TC) Transfer Frames

TC frames carry commands from ground to spacecraft. Defined in CCSDS 232.0-B, these are the most security-critical frames in any mission because a compromised command path means total loss of spacecraft control.

Field	Size (bits)	Purpose
Transfer Frame Version	2	Protocol version
Bypass Flag	1	Bypass sequence-controlled service
Control Command Flag	1	Distinguishes data from control
Reserved	2	Spare bits
Spacecraft ID	10	Target spacecraft
Virtual Channel ID	6	Logical channel
Frame Length	10	Total frame length
Frame Sequence Number	8	Sequence counter
Data Field	Variable	Command payload
Frame Error Control	16	CRC-16-CCITT

Security implications: Without SDLS, the only protection on a TC frame is the CRC-16, which is an error-detection code — not a cryptographic integrity check. An attacker who understands the frame structure can forge commands with valid CRCs. The Bypass Flag is particularly dangerous: when set, it tells the spacecraft to execute the command immediately without sequence checking, bypassing the one built-in protection against replay attacks.

Space Data Link Security (SDLS) Protocol

SDLS (CCSDS 355.0-B) adds cryptographic protection to TM and TC transfer frames. It defines three security modes:

Authentication Only: Appends a Message Authentication Code (MAC) to each frame using AES-128-GMAC or HMAC-SHA-256. This prevents command forgery but does not protect telemetry confidentiality. Recommended minimum for all missions.

Encryption Only: Encrypts the data field using AES-128-GCM or AES-256-GCM. Protects confidentiality but without a separate integrity check on the header fields, an attacker can potentially manipulate routing information (Spacecraft ID, VCID) without detection.

Authenticated Encryption: Combines both. AES-GCM provides authenticated encryption in a single pass. This is the recommended mode for all new missions, but many legacy spacecraft launched before SDLS adoption cannot be upgraded.

Key management challenges: SDLS requires pre-shared symmetric keys loaded before launch. In-orbit rekeying is possible but adds complexity and risk — a failed rekey operation could lock operators out of their own spacecraft. The CCSDS Key Management specification (352.0-B) defines procedures, but implementation varies significantly across agencies.

Adoption reality: As of 2025, SDLS adoption remains incomplete across the industry. Many commercial LEO constellation operators treat SDLS as optional overhead, relying instead on application-layer encryption or VPN tunnels at the ground segment. This leaves the space link itself unprotected.

SDLS implementation challenges:

Challenge	Description	Impact
Processing overhead	AES-GCM per frame on rad-hard processors with limited clock speeds	Limits achievable data rates on older spacecraft
Key storage	Symmetric keys must be stored in tamper-resistant memory on the spacecraft	Adds cost, weight, and power requirements
Rekeying risk	Failed rekey could lock operators out permanently	Risk-averse operators avoid rekeying
Multi-mission support	Ground stations serving multiple missions need per-mission key management	Increases operational complexity
Legacy interoperability	Older ground systems may not support SDLS	Requires ground segment upgrades before spacecraft launch

CCSDS File Delivery Protocol (CFDP)

CFDP (CCSDS 727.0-B) handles reliable file transfer between ground and space entities. It operates in two modes:

Unreliable (Class 1): Fire-and-forget. Used when link conditions make acknowledgments impractical (deep space, store-and-forward).
Reliable (Class 2): Uses NAK-based retransmission. The receiver reports missing segments and the sender retransmits.

Security implications: CFDP has no built-in authentication or encryption. File metadata — including filenames, sizes, and destination paths — is transmitted in the clear. An attacker intercepting CFDP transactions can reconstruct complete files, potentially including mission data, software updates, or configuration changes. When CFDP is used for software uploads to spacecraft, a man-in-the-middle attack could substitute malicious firmware. CFDP relies entirely on SDLS at the link layer for security.

Proximity-1 for Inter-Satellite Links

Proximity-1 (CCSDS 211.0-B) governs short-range communication between spacecraft, most commonly used for relay communications between Mars surface assets and orbiters. It defines a full protocol stack including a data link layer with ARQ error control.

Security implications: Proximity-1 was designed for cooperative assets operated by the same agency. It has no authentication mechanism — any transmitter on the correct frequency using the correct frame format will be accepted. As more nations and commercial operators deploy assets around Mars and the Moon, the assumption of a cooperative RF environment becomes increasingly dangerous.

2. DVB-S2/S2X

Digital Video Broadcasting - Satellite Second Generation (DVB-S2, ETSI EN 302 307) is the dominant standard for satellite broadcast and broadband services. Its extension, DVB-S2X (EN 302 307-2), adds finer granularity modulation and coding options. While designed for broadcast television, DVB-S2 carries an enormous amount of internet traffic, enterprise data, and even some government communications.

Physical Layer Security Considerations

DVB-S2/S2X supports a range of modulation schemes, each with different capacity and Signal-to-Noise (SNR) requirements:

Modulation	Bits/Symbol	Typical Use	Security Notes
QPSK	2	Wide-beam broadcast, low SNR	Easy to receive with consumer equipment
8PSK	3	Broadcast, moderate SNR	Standard DVB-S2 receivers work
16APSK	4	Broadband, higher SNR	Still receivable with prosumer SDR
32APSK	5	High-throughput, spot beams	Requires better equipment, tighter pointing
64APSK	6	DVB-S2X, very high SNR	Narrower beams reduce casual interception
128APSK	7	DVB-S2X, point-to-point	Harder to intercept but not immune
256APSK	8	DVB-S2X, maximum throughput	Most resistant to casual eavesdropping

Key insight: Higher-order modulation schemes require better SNR and are typically used on narrower spot beams, which provides some incidental protection against eavesdropping — an attacker must be within the beam footprint and have sufficient antenna gain. However, this is security through obscurity, not a cryptographic guarantee. A sufficiently motivated adversary with appropriate antenna infrastructure can intercept any of these signals.

Adaptive Coding and Modulation (ACM/VCM)

DVB-S2 supports three operating modes relevant to security:

Constant Coding and Modulation (CCM): Fixed modulation and code rate for all users. Simplest to intercept because parameters are static.
Variable Coding and Modulation (VCM): Parameters change per time slot based on pre-planned scheduling. An attacker must track the schedule but this is typically signaled in-band.
Adaptive Coding and Modulation (ACM): Parameters change dynamically based on channel conditions reported by receivers. The modulation/coding information is carried in the Physical Layer Header (PLHeader), which is always transmitted in a fixed, known format — meaning an attacker can read the PLHeader to determine how to demodulate every subsequent frame.

Generic Stream Encapsulation (GSE)

GSE (ETSI TS 102 606) encapsulates IP packets and other network-layer PDUs into DVB-S2 Base-Band frames. GSE replaced the older Multi-Protocol Encapsulation (MPE) and provides:

Support for IPv4 and IPv6 natively
Label-based filtering (6-byte MAC, 3-byte shorthand, or broadcast)
Fragmentation and reassembly for large packets

Security implications: GSE labels (which are effectively MAC addresses) are transmitted unencrypted. An attacker capturing the DVB-S2 signal can filter traffic by GSE label to isolate individual subscriber streams. Combined with the fact that many VSAT operators do not encrypt user traffic at the DVB-S2 layer, GSE labeling provides a convenient index for targeted eavesdropping.

DVB-CSA and Its Weaknesses

DVB Common Scrambling Algorithm (DVB-CSA) was designed to protect pay-TV content. It uses a combination of a 64-bit block cipher and a stream cipher, keyed by a 48-bit common word.

Known weaknesses:

Short key length: The 48-bit effective key space is brute-forceable with modern FPGAs. Dedicated hardware implementations can exhaust the keyspace in hours.
Known-plaintext vulnerability: DVB transport streams contain predictable headers (sync bytes, PID values, adaptation fields), providing ample known plaintext for cryptanalytic attacks.
CSA2 improvements insufficient: CSA2 increased the key length to 64 bits, which delays brute force but does not address the structural weaknesses.
CSA3 (AES-based): Uses 128-bit AES in a DVB-specific mode. Cryptographically stronger but adoption has been slow due to hardware upgrade requirements.

For satellite broadband: DVB-CSA was never intended for IP traffic protection. Most satellite broadband operators use IPsec or proprietary encryption rather than DVB-CSA to protect subscriber data. The concern is operators who rely on DVB-CSA as their sole confidentiality mechanism.

Timeline of DVB-CSA compromise:

Year	Development	Impact
1994	DVB-CSA v1 specified (48-bit effective key)	Considered adequate for broadcast pay-TV
2002	First academic analysis of CSA block cipher structure	Identified theoretical weaknesses
2011	GPU-accelerated brute force demonstrated	48-bit keyspace exhaustible in hours
2012	FPGA-based crackers commercially available	Real-time decryption of CSA streams possible
2014	CSA3 (AES-based) specified	Adequate strength but requires hardware upgrade
2020+	Legacy CSA v1/v2 still widely deployed	Cost of hardware replacement delays migration

DVB-CI+ Conditional Access

DVB Common Interface Plus (CI+) provides a trust chain between the receiver hardware and the conditional access module. It uses RSA-based authentication and AES content key distribution.

Security implications: CI+ has been subject to multiple bypass attacks. Researchers have extracted root keys from specific hardware implementations, enabling cloning of conditional access modules. While primarily a content piracy concern, the same bypass techniques could be applied to any service using DVB-CI+ for access control, including enterprise VSAT services that repurpose broadcast conditional access for subscriber management.

3. VSAT Protocols

Very Small Aperture Terminal (VSAT) systems provide the majority of commercial satellite broadband and enterprise connectivity. The VSAT protocol landscape is dominated by a few proprietary platforms, each with distinct security properties.

Major VSAT Platforms

Platform	Vendor	Access Scheme	Typical Use	Encryption Default
iDirect (Dialog/Velocity)	ST Engineering iDirect	MF-TDMA / SCPC	Enterprise, maritime, military	AES-256 available, not always enabled
Hughes Jupiter	Hughes Network Systems	MF-TDMA	Consumer broadband, enterprise	Proprietary scrambling, optional IPsec
Newtec Dialog	ST Engineering (Newtec)	Mx-DMA (dynamic SCPC)	Broadcast, broadband, government	AES-256 available
Comtech	Comtech EF Data	TDMA / SCPC	Military, government	AES-256 / Type 1 available
Gilat SkyEdge	Gilat Satellite Networks	MF-TDMA	Enterprise, cellular backhaul	AES-128/256 available

Access Schemes and Security Implications

TDMA (Time Division Multiple Access): Multiple terminals share a carrier by transmitting in assigned time slots. Security concern: all terminals on a TDMA carrier can potentially see each others’ traffic at the physical layer. The hub demultiplexes by time slot, but a modified terminal (or SDR receiver) can capture all slots.

SCPC (Single Channel Per Carrier): Each terminal gets a dedicated carrier. Slightly harder to intercept because the attacker must identify and tune to the specific carrier, but the carrier frequencies are typically coordinated and discoverable.

MF-TDMA (Multi-Frequency TDMA): Combines frequency and time division. Terminals hop between frequencies and time slots. Adds complexity for an attacker but the hopping pattern is deterministic and signaled by the hub.

Mx-DMA (Newtec): Dynamically adjusts between TDMA and SCPC based on traffic demand. The most efficient access scheme but the dynamic nature means an attacker must continuously track allocation changes.

Hub-Spoke vs. Mesh Topologies

Hub-Spoke (Star): All traffic routes through a central hub. The hub is a single point of compromise — an attacker who gains access to the hub sees all traffic for the entire network. However, terminal-to-terminal traffic is double-hop (terminal -> hub -> terminal), which means it crosses the satellite link twice, providing two interception opportunities.

Mesh (Direct Terminal-to-Terminal): Terminals communicate directly via satellite without hub involvement. Reduces latency but distributes the encryption responsibility to every terminal. If any terminal is compromised, it may expose the keys used for mesh communication with all its peers.

Why VSAT Is Particularly Vulnerable

VSAT systems have historically been among the most vulnerable satellite communication platforms for several compounding reasons:

Unencrypted by default: Many VSAT platforms ship with encryption disabled. Operators must explicitly configure encryption, and many — particularly in maritime and aviation — do not. A 2020 study by James Pavur at Oxford captured over 18 GB of unencrypted VSAT traffic from maritime vessels using a standard DVB-S2 receiver and a 1.2m dish.
Shared medium: The forward link (hub to terminals) is a broadcast signal. Every terminal — and every eavesdropper — receives the same signal. Traffic isolation depends entirely on upper-layer addressing and encryption.
Predictable framing: VSAT protocols use well-documented frame structures. Open-source tools like gr-dvbs2 (GNU Radio) can demodulate and decode VSAT forward links in real time with commodity hardware.
Static beam footprints: Geostationary VSAT beams cover vast geographic areas (continental or regional). An attacker anywhere within the beam footprint can receive the forward link.
Metadata exposure: Even when payload encryption is enabled, VSAT systems frequently leak metadata — terminal IDs, IP addresses, DNS queries, and NTP synchronization patterns — that enables traffic analysis and terminal geolocation.
Ground segment centralization: The VSAT hub infrastructure (typically located at a teleport) is a high-value target. A compromised hub can decrypt all traffic, inject commands to terminals, and modify routing.

4. GNSS Signals

Global Navigation Satellite Systems broadcast positioning signals that are critical infrastructure for timing, navigation, and synchronization across civilian and military systems. The security properties of these signals vary dramatically between civilian and military services.

GPS Signal Structure

Signal	Band	Center Freq (MHz)	Code	Security	Status
L1 C/A	L1	1575.42	Coarse/Acquisition (1.023 Mcps)	None — publicly documented	Operational
L1 P(Y)	L1	1575.42	Precision, encrypted (10.23 Mcps)	Anti-spoofing (W-key encryption)	Military only
L1 M-code	L1	1575.42	Military code (BOC modulation)	Encrypted, jam-resistant	Operational (GPS III)
L2 P(Y)	L2	1227.60	Same P(Y) code as L1	Anti-spoofing	Military only
L2C	L2	1227.60	Civilian code (CM + CL)	None	Operational
L5	L5	1176.45	Civilian safety-of-life	None (authentication planned)	Operational

Why civilian GPS is trivially spoofable: The L1 C/A signal structure — including the PRN codes for every satellite, the navigation message format, the modulation scheme, and the signal power levels — is fully documented in public Interface Control Documents. A GPS spoofer needs only to generate signals that match this specification with slightly higher power than the genuine satellites. Consumer GPS receivers have no mechanism to distinguish authentic from spoofed signals. The equipment to do this (an SDR and open-source software like gps-sdr-sim) costs under $300.

Galileo Signal Structure

Signal	Band	Service	Authentication	Notes
E1 OS	E1 (1575.42 MHz)	Open Service	OSNMA (operational since 2023)	First GNSS with civilian authentication
E1 PRS	E1	Public Regulated Service	Encrypted, government-only	Resistant to spoofing and meaconing
E5a	E5a (1176.45 MHz)	Open Service	OSNMA cross-authenticated	Dual-frequency improves robustness
E5b	E5b (1207.14 MHz)	Open/Commercial	Planned authentication	Future commercial authentication service
E6	E6 (1278.75 MHz)	Commercial/HAS	Encrypted authentication	High Accuracy Service

OSNMA (Open Service Navigation Message Authentication): Galileo’s OSNMA is the most significant advancement in civilian GNSS security. It uses a TESLA (Timed Efficient Stream Loss-tolerant Authentication) protocol to authenticate navigation messages. The system works by:

Broadcasting a MAC over the navigation data using a key that is revealed after a delay
Receivers store the data and MAC, then verify when the key is released
A chain of keys is authenticated back to a root key distributed via a separate trust chain

Limitations of OSNMA: OSNMA authenticates the navigation message (ephemeris, clock corrections) but does not authenticate the signal itself (the spreading code). A sophisticated attacker can still perform signal-level spoofing by replaying genuine navigation messages on a fabricated carrier. OSNMA also introduces a Time-To-First-Authenticated-Fix (TTFAF) of approximately 10-30 minutes, during which the receiver is still vulnerable.

GLONASS and BeiDou

GLONASS: Uses FDMA (each satellite on a different frequency) rather than CDMA. No civilian signal authentication. The open signal (L1OF) is fully documented and spoofable. GLONASS modernization (CDMA signals on L3OC) does not include authentication.

BeiDou (BDS): China’s system broadcasts B1C, B2a, and B3I open signals without authentication. The military/authorized service signals are encrypted. BeiDou includes a Regional Short Message Communication (RSMC) capability that is unique among GNSS systems and creates an additional attack surface — compromised RSMC messages could deliver malicious payloads to BeiDou-equipped terminals.

5. IP over Satellite

Running IP traffic over satellite links introduces unique protocol challenges that have direct security implications. The high latency (250ms+ one-way for GEO), high bandwidth-delay product, and asymmetric link characteristics require protocol modifications that often weaken security.

Performance Enhancing Proxies (PEPs)

PEPs (RFC 3135) are middleboxes deployed at the satellite gateway and sometimes at the terminal to improve TCP performance over satellite links. They work by:

TCP splitting: Breaking the end-to-end TCP connection into three segments (client-to-PEP, PEP-to-PEP over satellite, PEP-to-server). Each segment uses optimized TCP parameters.
TCP spoofing: Generating premature ACKs to keep the sender’s congestion window open during the satellite delay.
Compression: Reducing header overhead and compressing payload data.

Security implications of PEPs:

Issue	Impact	Severity
Breaks end-to-end encryption (TLS/IPsec)	PEP cannot optimize encrypted traffic it cannot inspect	High
Man-in-the-middle position	PEP terminates and re-originates TLS connections (split-TLS)	Critical
Certificate substitution	Some PEPs generate on-the-fly certificates signed by a local CA	Critical
Caching of sensitive data	PEPs may cache HTTP content including authenticated sessions	Medium
Single point of failure	PEP compromise exposes all transiting traffic	High

The fundamental tension: PEPs provide necessary performance improvement for satellite links, but they require breaking the end-to-end security model. Operators must choose between performance and security integrity, and most choose performance. QUIC and TLS 1.3 with 0-RTT are gradually reducing the need for PEPs, but adoption over satellite is slow due to UDP blocking and legacy infrastructure.

DVB-RCS2 Return Channel

DVB-RCS2 (ETSI EN 301 545) defines the return channel (terminal to hub) for interactive satellite systems. It uses MF-TDMA for the return link and includes:

Logon and authentication: Terminals authenticate to the Network Control Center (NCC) during logon. Legacy implementations used weak challenge-response protocols vulnerable to replay attacks; newer implementations support EAP-based authentication with TLS tunneling.
Capacity requests: Terminals request bandwidth allocation from the hub using Capacity Request (CR) messages. These requests are typically unencrypted, enabling an eavesdropper to profile terminal activity patterns — a terminal requesting high bandwidth likely has significant data to transmit.
Burst structures: The return link burst format includes known preamble sequences (unique words) that aid synchronization — and also aid an attacker in identifying and demodulating return-link signals.
Terminal burst time plan (TBTP): The hub broadcasts bandwidth allocation tables on the forward link. These tables reveal which terminals are active, their assigned time slots and frequencies, and their allocated bandwidth — providing a complete operational picture of the network to any eavesdropper.

DVB-RCS2 security profile: The standard includes an optional security sublayer that supports AES-128-CCM for return-link encryption and HMAC-SHA-256 for integrity protection. However, enabling this security sublayer is at the operator’s discretion, and it adds overhead to the already bandwidth-constrained return link. Many operators disable it for performance reasons, particularly for consumer broadband services where the return link capacity is the primary bottleneck.

Encapsulation Overhead

IP over satellite involves multiple layers of encapsulation, each adding overhead and potential information leakage:

IP Packet (20-60 byte header)
  → GSE Encapsulation (+12 bytes minimum)
    → DVB-S2 Base-Band Frame (header + padding)
      → Physical Layer Frame (PLHeader + pilots)
        → RF Carrier

Each encapsulation layer adds headers that are typically unencrypted even when the IP payload is protected. These headers leak information about traffic patterns, addressing, and protocol usage.

Latency Mitigation and Security Trade-offs

Satellite operators employ several latency mitigation techniques that affect security:

Pre-fetching / speculative loading: Proxy servers fetch linked content before the user requests it. This requires deep packet inspection of HTTP traffic — incompatible with end-to-end encryption.
DNS pre-resolution: Hub-side DNS resolvers cache and pre-resolve domains. DNS queries from terminals are visible to the hub operator and any eavesdropper on the forward link.
Connection pooling: Persistent connections between PEPs reduce TCP handshake overhead. But pooled connections may mix traffic from multiple users, creating isolation concerns.

TCP Acceleration Techniques

Beyond PEPs, satellite operators deploy several TCP optimization techniques that affect security:

Window scaling: Satellite links require large TCP windows (bandwidth-delay product for a 10 Mbps GEO link is approximately 625 KB). Window scaling negotiation is visible to any observer of the TCP handshake, revealing that the connection traverses a satellite link.
Selective acknowledgment (SACK): Essential for satellite performance but SACK processing vulnerabilities (CVE-2019-11477, CVE-2019-11478) have been exploited for denial-of-service attacks. Satellite terminals running older kernels may remain unpatched.
Explicit Congestion Notification (ECN): Some satellite PEPs manipulate ECN bits to manage congestion, which can interfere with end-to-end congestion signaling and create opportunities for traffic manipulation.
HTTP/2 and HTTP/3 implications: Multiplexed protocols reduce the effectiveness of PEP-based optimization because the PEP can no longer correlate individual request-response pairs. This is driving operators toward transparent proxy architectures that require even deeper protocol inspection.

6. Emerging Protocols

The satellite communications landscape is undergoing rapid transformation. Several emerging protocol families introduce new capabilities — and new attack surfaces.

3GPP NTN (Non-Terrestrial Networks)

3GPP Release 17 introduced NTN specifications that integrate satellite access into the 5G architecture. This enables standard 5G handsets to connect directly to satellites (direct-to-device, or D2D).

Architecture: The satellite acts as a transparent or regenerative relay. In transparent mode, the satellite simply amplifies and frequency-shifts the signal — all baseband processing happens on the ground. In regenerative mode, the satellite includes a gNB (5G base station) and processes signals on board.

Security implications:

Authentication: NTN uses standard 5G AKA (Authentication and Key Agreement), which provides mutual authentication between the UE and the network. This is a significant improvement over legacy satellite protocols.
Encryption: NTN supports 5G NAS and AS encryption (NEA1/NEA2/NEA3 and NIA1/NIA2/NIA3). User plane traffic can be encrypted with 128-bit keys.
New attack surface: The extended propagation delay (up to 540ms RTT for GEO) strains 5G timing assumptions. Timer extensions required for NTN may create windows for replay attacks or race conditions in the authentication protocol.
Doppler and handover: LEO-based NTN requires frequent handovers as satellites move overhead. Each handover is an opportunity for an attacker to attempt to insert a rogue base station.
SUPI exposure risk: The delay in completing authentication could expose the Subscription Permanent Identifier (SUPI) for longer windows than terrestrial 5G.

Free-Space Optical (FSO) Links

Optical inter-satellite links and satellite-to-ground optical links use laser communication instead of RF. ESA’s EDRS (European Data Relay System) and SpaceX’s Starlink constellation use optical inter-satellite links operationally.

Security properties:

Narrow beam divergence: Optical beams are orders of magnitude narrower than RF beams (microradians vs. degrees). Interception requires physically positioning a receiver in the beam path, which in space is extremely difficult.
No side lobes: Unlike RF antennas, laser transmitters produce negligible side-lobe emissions. There is no equivalent of the RF spillover that enables passive eavesdropping.
Atmospheric limitations: Ground-to-satellite optical links are affected by weather, clouds, and atmospheric turbulence. This forces fallback to RF links, which may have weaker security properties — creating a protocol downgrade vulnerability.
Quantum detection: Any attempt to tap a free-space optical beam disturbs the photon stream in a theoretically detectable way, although practical detection of sophisticated tapping is still challenging.

Quantum Key Distribution (QKD) via Satellite

Satellite-based QKD enables the distribution of cryptographic keys with information-theoretic security guarantees. China’s Micius satellite demonstrated satellite-to-ground QKD in 2017, and several commercial QKD satellite programs are in development.

How it works: The satellite generates entangled photon pairs or transmits quantum states (BB84 protocol) to ground stations. Any measurement by an eavesdropper disturbs the quantum state, which is detected during key reconciliation. The result is a shared secret key guaranteed to be uncompromised.

Current limitations:

Low key rates: Current satellite QKD achieves key rates of approximately 1-10 kbps — sufficient for key exchange but not bulk encryption.
Trusted node problem: In most architectures, the satellite is a trusted node that holds the key material. A compromised satellite defeats the security guarantee.
Daylight operation: Background photon noise during daylight severely reduces key rates and increases error rates, limiting operational windows.
Distance and weather: Cloud cover blocks optical QKD channels, requiring ground station diversity.

Inter-Satellite Laser Links (Starlink and Beyond)

SpaceX’s Starlink constellation uses inter-satellite laser links (ISLLs) to route traffic across the constellation without touching the ground. Each satellite connects to up to four neighbors via laser terminals.

Protocol details: Starlink uses a proprietary mesh routing protocol over the laser links. While specifics are not publicly documented, the architecture implies:

Onboard routing decisions: Each satellite makes forwarding decisions, creating a distributed routing fabric with an attack surface similar to terrestrial BGP — but with the added challenge that the routers are in orbit and cannot be physically secured.
Latency advantage: For long-distance traffic, the space path (speed of light in vacuum) is faster than fiber (speed of light in glass, ~0.67c). This creates an incentive for high-value, latency-sensitive traffic (financial trading) to route through space — raising the stakes of compromise.
Encryption: Likely AES-256 between satellites, but the key management and rotation scheme for thousands of inter-satellite links is a significant engineering challenge. Compromising one satellite’s key store could expose traffic transiting through that node.

7. Protocol Comparison: Security Properties

The following table summarizes the security posture of each major satellite communication protocol family:

Protocol	Authentication	Encryption	Integrity	Replay Protection	Key Management	Anti-Jam	Overall Security
CCSDS (no SDLS)	None	None	CRC only	Frame counter (weak)	N/A	None	Very Low
CCSDS + SDLS	AES-GMAC / HMAC	AES-GCM	Cryptographic MAC	Sequence + anti-replay window	Pre-shared, CCSDS KM	None (link-layer)	High
DVB-S2 (no encryption)	None	None	CRC-8 on BB header	None	N/A	None	Very Low
DVB-S2 + DVB-CSA	None	CSA (48-bit key)	None	None	ECM/EMM (conditional access)	None	Low
DVB-S2 + AES	Platform-dependent	AES-128/256	AES-GCM if used	Platform-dependent	Vendor-specific	None	Medium-High
VSAT (default)	Terminal login (weak)	None typical	None	None	Hub-managed	None	Low
VSAT (hardened)	Certificate-based	AES-256	HMAC / GCM	Sequence numbers	PKI or pre-shared	FHSS available	High
GPS L1 C/A	None	None	Parity only	None	N/A	None	Very Low
GPS P(Y)/M-code	Cryptographic	Encrypted PRN	Implicit in encryption	Implicit	Military KM (EKMS)	BOC modulation, higher power	Very High
Galileo OSNMA	TESLA MAC	None (open signal)	Navigation message MAC	Time-based	Root key via ICD	None	Medium
3GPP NTN (5G)	5G AKA (mutual)	NEA1/2/3	NIA1/2/3	5G counters	USIM-based	5G mechanisms	High
FSO / Laser ISL	Vendor-specific	AES-256 typical	Vendor-specific	Vendor-specific	Vendor-specific	Inherent (narrow beam)	Medium-High

Key Takeaways

Legacy dominates: The majority of operational satellite systems use protocols designed without cryptographic security. Retrofitting security onto deployed constellations is difficult and often incomplete.
The forward link is a broadcast: For DVB-S2 and VSAT systems, the satellite-to-ground transmission is inherently a broadcast medium. Any security model that does not assume the forward link is intercepted is fundamentally flawed.
GNSS authentication is arriving but incomplete: Galileo OSNMA represents a breakthrough in civilian positioning authentication, but it protects the navigation message, not the signal. GPS has no civilian authentication and no concrete plans to add it.
PEPs break the security model: Performance Enhancing Proxies are ubiquitous in satellite internet and fundamentally incompatible with end-to-end encryption. The industry must move toward protocols (QUIC, TLS 1.3) that reduce PEP dependency.
Emerging protocols raise the bar: 3GPP NTN inherits the mature 5G security framework, and optical inter-satellite links provide inherent physical-layer security. But these improvements apply only to new deployments — legacy systems will remain vulnerable for decades.
Protocol knowledge enables attacks: Every attack described on the Attack Vectors page depends on understanding the protocols discussed here. Protocol analysis is the foundation of both satellite penetration testing and satellite defense.