GNSS Anti-CRPA System: Code Domain Anti-Spoofing Mechanism Explained

Spoofing is not jamming. Jamming blinds you. Spoofing lies to you. A jammer shouts noise into the band and your receiver sees nothing. A spoofer transmits fake GNSS signals that look perfectly real — same structure, same timing, same navigation message — and your receiver follows them willingly into the wrong position. The difference matters enormously for CRPA systems, because spatial filtering alone cannot stop a spoofer. A spoofed signal arrives from a real direction, passes through the nulls unchanged, and corrupts your navigation solution from the inside.

Code domain anti-spoofing is the first line of defense against this threat. It operates before the signal ever reaches the beamformer. It examines the structure of the ranging codes themselves — the C/A code on GPS L1, the E1B code on Galileo, the B1I code on BeiDou — and decides whether the signal is genuine or fabricated.

Why Spoofing Is a Different Problem From Jamming

Jamming is a power problem. The interferer is louder than the satellite. Spatial filtering works because the jammer and the satellite come from different directions. Null the jammer direction, keep the satellite direction, done.

Spoofing is a structure problem. The spoofer transmits signals that mimic the satellite waveform so closely that a conventional receiver cannot tell the difference. The spoofed signal can even arrive from the correct direction — a sophisticated spoofer uses the same antenna pattern as a real satellite. The CRPA beamformer sees a signal coming from the right angle with the right power level. It passes it through without suppression. The spoofing succeeds.

This is why code domain verification is mandatory inside any serious anti-spoofing architecture. The spatial filter handles jammers. The code domain handles spoofers. They solve different problems and must work together.

The Spoofer's Advantage Over the Receiver

A real GNSS signal arrives at the antenna with about -130 dBm of power. A spoofer can transmit at -80 dBm or higher from a few meters away. That is a 50 dB advantage. The spoofed signal overwhelms the authentic signal in the correlation process. The receiver locks onto the spoofer and tracks it exclusively. The authentic satellite signal gets rejected as multipath or noise.

This is called the capture effect. The stronger signal wins. A CRPA system cannot overcome this with spatial filtering because the spoofer is transmitting from a direction that overlaps with the satellite. The only way to break the capture effect is to verify that the signal's code structure matches what a real satellite would transmit.

How Code Domain Verification Actually Works

Code domain anti-spoofing examines the ranging codes embedded in the GNSS signal. Every GNSS satellite transmits a unique pseudorandom noise (PRN) code that the receiver uses to measure distance. The receiver generates a local replica of that code, slides it in time, and looks for a correlation peak. When the peak aligns, the receiver has measured the code phase — and from that, the pseudorange.

A spoofer has to generate a fake PRN code that correlates with the receiver's local replica. But generating a perfect replica in real time is extremely difficult. The spoofer has to guess the receiver's code phase, Doppler, and navigation data. Any mismatch shows up as anomalies in the correlation function. Those anomalies are what code domain anti-spoofing looks for.

Cross-Correlation Analysis Between Code Channels

Every GNSS receiver tracks multiple satellites simultaneously. Each satellite has a unique PRN code. The codes are designed to have very low cross-correlation with each other — ideally zero. In practice, the cross-correlation between any two GPS C/A codes is bounded by about -24 dB relative to the auto-correlation peak.

A spoofer typically transmits one fake signal that tries to impersonate multiple satellites. It modulates different navigation messages onto the same carrier. The receiver sees what looks like several satellites, but they all share the same underlying code structure. The cross-correlation between the spoofed channels is abnormally high — much higher than -24 dB.

The anti-spoofing monitor computes the cross-correlation matrix between all tracked channels in real time. If the off-diagonal elements exceed a threshold, the system flags a spoofing attack. This works even when the spoofed signal is stronger than the authentic signal, because it does not rely on signal power — it relies on code structure.

Secondary Code and Pilot Channel Verification

Modern GNSS signals carry more than just the primary ranging code. GPS L1C has a pilot channel that carries no data — just a known bit sequence. Galileo E1 has a secondary code that modulates the primary code. BeiDou B1C has a pilot component. These secondary codes are much harder to spoof because they are longer, more complex, and in some cases cryptographically protected.

A receiver that verifies the secondary code against the expected sequence can detect a spoofer that only replicated the primary C/A code. The spoofer might get the C/A code right but fail on the secondary code. The verification fails. The spoofed signal gets rejected.

This is why multi-frequency receivers have a significant anti-spoofing advantage. A single-frequency receiver only sees the primary code. A dual-frequency receiver sees both the primary and secondary codes, plus the pilot channel. More data means more things to verify, which means more chances to catch a spoofer.

Cryptographic Authentication — The Code Domain's Heavy Artillery

Code domain verification based on correlation properties is good. Cryptographic authentication is better. It does not just check whether the code looks right. It proves that the code came from a real satellite.

How OSNMA Works at the Code Level

Galileo's Open Service Navigation Message Authentication (OSNMA) and GPS's upcoming Chimera authentication both operate by embedding digital signatures into the navigation message. The signature is computed over the navigation data using a key that only the satellite possesses. The receiver verifies the signature using a public key distributed through a trusted channel.

But the authentication covers more than just the navigation message. It covers the signal structure itself — the timing of the code, the data bits, the ephemeris. A spoofer that transmits correct navigation data but with wrong code timing will fail the authentication check. The signature verification fails. The signal is rejected.

OSNMA uses a scheme called TESLA — Timed Efficient Stream Loss-tolerant Authentication. The satellite sends a chain of keys. Each key authenticates the next one. The receiver verifies the chain backward using a delay that prevents a spoofer from replaying old keys. This is elegant because it does not require real-time communication between the satellite and the receiver. The authentication is self-contained in the signal.

Chip-Level Authentication on BeiDou and Galileo

BeiDou's B1C signal and Galileo's E1C signal both support chip-level authentication. Instead of authenticating the navigation message as a block, the authentication tag covers individual code chips. This is much harder to spoof because the attacker has to replicate the authentication tag for every single chip in real time.

A spoofer that gets the navigation message right but fails on a few chips will be detected. The authentication check operates at the code chip level, which is the finest granularity possible. This is the state of the art in code domain anti-spoofing, and it is only available on the newest signals from Galileo and BeiDou.

How CRPA Systems Integrate Code Domain Anti-Spoofing

The CRPA beamformer operates on the RF signal before it reaches the receiver. Code domain anti-spoofing operates inside the receiver after correlation. These two functions must share data without interfering with each other.

The Monitoring Path Runs Parallel to the Beamforming Path

The CRPA array produces N parallel digitized streams. The beamforming processor combines them with adaptive weights to produce a cleaned output. That output goes to the GNSS receiver for tracking. But before the beams are combined, a copy of each element's data goes to the anti-spoofing monitor.

The monitor runs cross-correlation analysis, secondary code verification, and authentication checks on the raw element data. It does not wait for the beamformer output. This is important because a spoofed signal might look clean after beamforming — the beamformer does not know it is spoofed. The monitor catches it before the beamformer passes it along.

If the monitor detects a spoofing event, it flags the affected channels. The beamforming algorithm can then exclude those channels from the constraint set. The LCMV weights recompute without the spoofed satellite directions. The spoofed signal gets nulled not because of its direction, but because the system refuses to treat it as a valid satellite.

Per-Element Spoofing Detection

A sophisticated spoofer might transmit different fake signals to different array elements — trying to create a false direction of arrival that matches a real satellite. The CRPA system can detect this by comparing the code domain measurements across elements.

If element 1 sees a C/A code with chip sequence X and element 2 sees the same satellite with chip sequence Y, something is wrong. Real satellite signals arrive as plane waves. Every element sees the same code sequence, just with a different phase offset. If the code sequences differ across elements, the signal is not a real satellite. It is a spoofing attack targeting the array directly.

This per-element comparison is computationally expensive. It requires running the correlation and verification pipeline on every element independently. But it catches a class of spoofing attacks that conventional receivers miss entirely.

Real-World Spoofing Scenarios and How Code Domain Handles Them

Meaconing — The Simple But Effective Attack

A meaconing attack records authentic GNSS signals and rebroadcasts them with a delay. The receiver sees real codes, real navigation data, real Doppler. The only difference is a constant time offset. Code domain anti-spoofing based on cross-correlation catches this because the meaconed signal's cross-correlation with other channels is abnormal. The delay also shows up as an inconsistent pseudorange that does not fit the navigation solution.

But a meaconing attack that delays only one channel is harder to detect. The code itself is correct. The cross-correlation with other channels is normal. The only clue is the pseudorange residual. This is why code domain anti-spoofing must be combined with navigation solution consistency checks.

Generative Spoofing — The Hard Case

A generative spoofer creates fake signals from scratch. It does not record and replay. It synthesizes PRN codes, navigation data, and Doppler in real time. The codes are close to correct but not perfect. The navigation data is plausible but not accurate. The Doppler is consistent but slightly off.

Code domain verification catches generative spoofing through correlation shape analysis. A real C/A code produces a triangular correlation peak with a specific width. A fake code produces a peak with a slightly different shape — maybe narrower, maybe with side lobes. The monitor measures the correlation peak shape and compares it to the expected template. Deviations flag the signal as spoofed.

Secondary code verification catches generative spoofing when the spoofer fails to replicate the secondary code. Most generative spoofers only implement the primary C/A code. They skip the secondary code because it is harder to generate in real time. A receiver that checks the secondary code finds the spoofer immediately.

Array-Targeted Spoofing — The CRPA-Specific Threat

An array-targeted spoofer transmits different signals to different elements, creating a fake direction of arrival that points at a real satellite. The CRPA beamformer sees a signal from the correct direction with the correct power level. It passes the signal through. The receiver tracks it. Navigation is compromised.

Code domain anti-spoofing is the only defense against this. Per-element code comparison detects the inconsistency. If element 3 sees a different code than element 5 for the same satellite, the system knows it is under attack. The beamformer drops the spoofed channel from its constraint set. The null steering recomputes without the fake satellite direction.

This is why code domain verification is not optional in a CRPA system. It is the layer that spatial filtering cannot replace.

Limitations and Failure Modes

Code Domain Cannot Stop a Perfect Spoofer

If a spoofer has access to the actual satellite signals — for example, by being co-located with a real receiver — it can replay the exact code, the exact navigation data, and the exact timing. Code domain verification sees nothing wrong. The correlation peak is perfect. The cross-correlation is normal. The secondary code matches. The authentication passes.

This is the theoretical limit of code domain anti-spoofing. It assumes the spoofer does not have access to the real signal. In practice, this assumption holds for most attacks. But a well-resourced adversary with physical access to a real GNSS signal can defeat code domain verification entirely.

Processing Latency Creates a Window of Vulnerability

Code domain verification takes time. The cross-correlation matrix must be computed. The secondary code must be checked. The authentication must be verified. Each step adds milliseconds of latency. During that window, the receiver is tracking the spoofed signal and producing a wrong navigation solution.

For a receiver moving at 100 meters per second, 100 milliseconds of vulnerability means 10 meters of position error. For a missile or a fast aircraft, that is unacceptable. This is why high-dynamic platforms combine code domain verification with inertial navigation. The IMU holds the solution during the verification window. If the code domain check passes, the GNSS solution corrects the IMU drift. If it fails, the IMU keeps the solution alive until the spoofing event ends.

Multi-Constellation Spoofing Is Getting Easier

Early spoofers targeted GPS only. A receiver tracking Galileo or BeiDou was safe. Modern spoofers can generate multiple constellations simultaneously. They transmit fake GPS, Galileo, BeiDou, and GLONASS signals all at once. The receiver sees spoofed signals from every constellation. Code domain verification on one constellation does not help if all constellations are spoofed.

This is why cross-constellation consistency checks matter. If GPS says you are at position X and Galileo says you are at position X plus 50 meters, something is wrong. Real satellites from different constellations produce consistent positions. Spoofed signals from different constellations often do not, because the spoofer has to maintain consistency across multiple independent navigation data sets in real time. That is much harder than spoofing one constellation.