lunar-attack-surface (scenario kind)

Scenario kind of the engine v0.38.0, family Lunar and cislunar. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. Every label here is the engine's or the verification matrix's; a kind is MODELLED unless the matrix says otherwise (how a label is earned: the README's Evidence section).

What it does#

Lunar surface-navigation signal-security attack surface (P1): composes the open signal-security analyses into one binary-reachable run. Reports (1) the AFS received power and its power SURPLUS versus a terrestrial GPS reference, plus the 12-18 dB sensitivity band as a genuine multi-axis sweep over the link inputs (reference level x EIRP x slant range) with the 25x-rounded / 28x-unrounded linear-factor reconciliation. REVISED (rule R4): this reported a 15.6 dB power DEFICIT and a 32x/36x factor until the GPS reference was corrected from -125 / -128.5 (which are the dBm figures) to -155 / -158.5 dBW, the ICD-GPS-200 values the jamming module has always carried. The sign inverts: the modelled lunar AFS signal is 14.4 dB STRONGER than terrestrial GPS L1 C/A, not weaker. The received power itself did not move by a bit, and the linear factor is the old one over exactly 1000, which is exactly the 30 dB dBm-to-dBW offset; (2) the required attacker transmit power to spoof (J/S = 3 dB) and to deny (J/S = 30 dB) at each standoff, the inverse of the J/S link; (3) the orbital capture footprint under a real uniform-aperture antenna pattern (Airy [2 J1(x)/x]^2), an altitude-limited sub-hemispheric cap whose limb is NOT captured; (4) a computed tracking-loop spoof-capture pull-in outcome (does a matched-code spoofer at a given power advantage and code offset actually drag the DLL/PLL) rather than the asserted 3 dB threshold; (5) the airless-body geometric horizon reach of a raised surface transmitter; and (6) the OSNMA/TESLA authentication budget (20 bit/s overhead = ~40 % of a 50 bit/s AFS nav message, key-disclosure latency, 2^-40 forgery). An empty body reproduces the P1 baseline; every input is defaulted and overridable. VALIDATED sub-results carry their source module's oracle (closed-form dB radiometry; inverse-J/S round trip; Airy pattern vs A&S Bessel and spherical-cap geometry; DLL/PLL pull-in vs Kaplan & Hegarty; spherical-tangent horizon identity vs eo_payload; OSNMA SIS-ICD field sizing). MODELLED: the representative geometry/power magnitudes and the specific capture-map cell values. Not a certified security product.

One run of scenarios/lunar-attack-surface.toml summarises as: lunar-attack-surface | AFS -140.6 dBW, surplus 14.4 dB (band -17.9–-12.0, 25×/28× surplus) | spoof@1000 m 0.000 W | footprint 3% cap, limb false | spoof-capture true (lock 0.00 s) | mast reach 21.0 km | OSNMA 20 bit/s (40% of 50 bit/s), 30 s latency | footprint sweep 7x5 (alt 20-500 km x HPBW 1.83-29.20 deg), capture 0.6-42.9% | limb NOT reached on this grid (best -0.8 dB, 3.8 dB short; needs 19.8 dBW vs 16.0 dBW)

Inputs#

From the schema (kshana kinds --json):

• Required fields: none
• Optional fields: afs_eirp_dbw, user_gain_dbi, slant_range_m, slant_range_max_m, carrier_hz, gps_reference_dbw, gps_reference_min_dbw, afs_isotropic_signal_dbw, transmitter_altitude_m, transmitter_power_dbw, antenna_diameter_m, footprint_grid, spoof_power_advantage_db, spoof_code_offset_chips, attacker_gain_dbi, spoof_capture_js_db, jam_denial_js_db, standoffs_m, mast_height_m, user_antenna_height_m, footprint_altitude_min_m, footprint_altitude_max_m, footprint_altitude_steps, footprint_altitude_scale, footprint_diameter_min_m, footprint_diameter_max_m, footprint_diameter_steps, footprint_diameter_scale

The example scenarios/lunar-attack-surface.toml sets, among others:

Run it#

kshana scenarios/lunar-attack-surface.toml

What it gives#

The scalar results of that run, with the units the engine states:

Evidence#

No matrix row names this kind by name; the label on its result is the engine's own, above.

The rows the run itself exercised, with the oracle the matrix gives each (the public sources are named there):

• MODELLED Geometry J/S link budget, anti-jam C/N₀, per-satellite loss-of-lock. Oracle (InternalConsistency): Anti-jam C/N₀ link-budget equation cross-checked against an independent numpy re-derivation (shares the same closed form → InternalConsistency) plus a real-JammerTest-2024 C/N₀ degradation characterisation. 0.30 round 2, blocked (stays MODELLED): the measured JammerTest 2024 C/N0 drop against a link-budget prediction (pre-registered 6a66994b, within 3 dB) was not run because the F8.1 antenna position and pointing at
• MODELLED Deterministic, scenario-hashed, SBOM + cross-platform golden gates. Oracle (ExternalDataset): SBOM conformance to the official CycloneDX 1.5 JSON Schema (+ valid SPDX identifiers) — an external published standard, zero validation errors over the full dependency graph; the FoM-determinism / byte-reproducibility part remains a pinned self-consistency check, so the row stays MODELLED
• MODELLED Two-axis sweep of the pattern-weighted, altitude-limited surface capture footprint over transmitter altitude and dish diameter, emitted one row per operating po. Oracle (InternalConsistency): Set inclusion: the jammer-to-signal ratio enters as a uniform decibel offset, so the captured set at a higher transmit power contains the set at a lower one and the fraction can only rise -- a property the Airy pattern does NOT give in beamwidth or altitude, where the captured region breaks into rings and the fraction is genuinely non-monotone. No published table gives the captured disk fraction of a lunar orbital tr

Limitations#

What the run's own report says is not modelled or not validated:

• MODELLED: the representative geometry/power magnitudes and the specific capture-map cell values. (kind catalogue (kshana kinds --json))
• GNSS-denied jamming resilience is MODELLED, not validated: checked against its own closed-form / analytic identity — catches transcription and coefficient errors, but is not an external oracle. (verification matrix (docs/MODELLED-RATIONALE.md))
• Reproducibility & software assurance is MODELLED, not validated: a sub-claim is externally checked, but the whole capability composes modelled pieces, so the capability stays Modelled. (verification matrix (docs/MODELLED-RATIONALE.md))
• Capture footprint against altitude and beamwidth is MODELLED, not validated: checked against its own closed-form / analytic identity — catches transcription and coefficient errors, but is not an external oracle. (verification matrix (docs/MODELLED-RATIONALE.md))

See also#

• Family page: Lunar and cislunar
• All kinds: KINDS.md