The Day Ships Sailed Over Airports - Detecting Maritime GPS Deception with Scurid.

On the morning of 28 February 2026, within hours of the first US-Israel strikes on Iran, something strange started appearing on maritime traffic screens across the Gulf. More than 1,100 vessels experienced AIS interference across the Middle East Gulf within a single 24-hour period, with Windward Maritime AI identifying at least 21 new jamming clusters across UAE, Qatari, Omani, and Iranian waters. Ships' AIS signals were falsely placed at UAE airports, over the Barakah Nuclear Power Plant, into inland locations inside Iran, and into circular crop-pattern distortions across Gulf waters. Vessel positions were displaced onto impossible locations "clearly inconsistent with physical reality. 1,2,3,4.

None of it was real. But the maritime traffic management system in the region was displaying it as fact. The maritime traffic management system uses AIS (Automatic Identification System)5 ; a mandatory VHF radio broadcast protocol that continuously transmits a vessel's position, speed, and course to other ships and shore stations. It operates with no cryptographic authentication 5 , any receiver trusts whatever any transmitter claims. The AIS relies on the GNSS signals coming from satellites. GNSS is the technology that uses satellite systems to provide positioning, navigation, and timing (PNT) anywhere on Earth. There are several global and regional systems, such as GPS (USA), GLONASS (Russia), Galileo (EU), BeiDou (China), NavIC (India).

In this article we only focus on Galileo GNSS. Galileo with its OSNMA (Open Service Navigation Message Authentication) brings authentication to civilian GNSS signals something that is missing from its counterparts.

Here is the property of OSNMA that at any given second of Galileo System Time, every honest receiver on Earth — regardless of its geographic location — is in the same cryptographic state.

What OSNMA Actually Does — and What It Doesn't

OSNMA prevents signal forgery — the manufacture of fake navigation messages that appear to come from a Galileo satellite. Any receiver running OSNMA verification will reject messages that fail the TESLA authentication chain. This directly addresses the most common form of GPS/GNSS spoofing, where an attacker generates counterfeit satellite signals.

authenticate where the receiver is when it receives those messages.

Galileo OSNMA uses the TESLA (Timed Efficient Stream Loss-tolerant Authentication) protocol. TESLA 6, 7 maintains a global one-way key chain: a sequence of keys K[0], K[1], K[2], … where each key is derived from the next by a one-way hash function. Every 30 seconds — one I/NAV subframe — Galileo discloses the key from two epochs ago, and begins accumulating message authentication codes under the current epoch's key.

The key disclosure schedule is deterministic and global. A receiver in Rotterdam and a receiver in the Strait of Hormuz — if both are honest and tracking Galileo E1 — will have verified the same key, accumulated tags under the same current key, and be on the same page within the same subframe. The TESLA state is a global heartbeat. Every honest receiver pulses together.

This is not a new observation. The global synchronisation is explicitly documented in the OSNMA ICD and is the foundation of TESLA's security model. What is new is treating this global heartbeat as a relay detection mechanism.

The TESLA epoch is 30 seconds. An I/NAV page is 2 seconds. A typical RF-over-IP relay introduces 10 to 360 milliseconds of link latency — far below the 30-second epoch. This means naive epoch-index comparison between receivers will not catch most relay attacks. That much was always known and is why this approach was never pursued.

But the epoch is not the only granularity available. Within each 30-second epoch, the receiver progresses page by page — 15 pages of 2 seconds each. The sub-epoch page counter advances identically for every honest receiver on Earth. A relay that introduces even a 2-second delay puts the victim receiver one page behind every other ship in the fleet. A relay that introduces 10 seconds of delay puts it five pages behind. The server, comparing page counters across 100 signed AIS bundles, sees the outlier immediately.

A relay attack—also called meaconing—forwards genuine, OSNMA-authenticated Galileo signals from a real location to a spoofed environment. The receiver at the spoofed location processes authentic signals and produces a valid, OSNMA-verified position fix. But the position it outputs corresponds to the geometry of the relay source, not its actual location. OSNMA passes. The position is wrong.

This is the vulnerability the remainder of this article addresses.

The non-repudiation comes from a Decentralised Identity(DID). When each vessel signs its TESLA state report with a hardware-rooted Decentralised Identifier key stored on the vessel, that the attacker cannot intercept the report and replace it with a fabricated one showing the correct consensus state. The vessel's own signed record becomes the evidence of the relay.

Galileo OSNMA solves — signal authenticity. To address location non-repudiation reported by the vessel, we need a different class of technology. Decentralised Identity (DID), specified by the W3C as a formal Recommendation since 2022, provides the identity infrastructure that AIS has never had.

In this PoC we use our Scurid platform - “Scurid is a trust infrastructure for robotics and edge systems, enabling verifiable device identity, secure data, and accountable autonomous operations.". With Scurid each device is uniquely identified with a DID. These DID’s are managed on the publically verifiable distributed ledger. Similarly, they can be resolved to obtain the DID Document and various Verifiable Credentials associated with them.

What a vessel DID looks like

A DID is a globally unique cryptographic identifier anchored on a distributed ledger. For a vessel, it is issued by the flag state authority at registration — analogous to the MMSI, but unlike the MMSI, it is cryptographically bound to a keypair stored on the vessel.The vessel's DID Document—publicly resolvable by anyone on the ledger—contains the vessel's public key, pointers to its class society certificate, flag state registry entry, P&I club coverage, and a revocation endpoint. It is a machine-verifiable identity card for the vessel.

{
  "id":         "did:vessel:0xb96ab6f1A9a20276512F731A455Ed21784eEcb5c",
  "controller": "did:vessel:0x14149d43c82f08a3bb5a07586A00a55126A41107",
  "vesselName": "Zubeen",
  "operatedBy": "NavShip Ocean"
  "nationality": "Indian",
  "verificationMethod": [{
    "id":   "did:vessel:0xb96ab6f1A9a20276512F731A455Ed21784eEcb5c#key-ais-1",
    "type": "JsonWebKey2020",
    "publicKeyJwk": { "kty":"EC", "crv":"P-256" }
  }],
  "service": [
    { "type": "FlagStateRegistry",  "endpoint": "did:vessel:flagstate:MI"   },
    { "type": "ClassCertificate",    "endpoint": "did:vessel:classociety:dnv" },
    { "type": "RevocationStatus",   "endpoint": "https://registry.vessel.eu/..." }
  ]
}

The vessel DID is bound to the vessel hardware, which makes it immune to identity theft, as the only compromise of the keys will not allow the attacker to sign messages on behalf of the vessel. A successful attack would rather ask for compromise of the vessel’s hardware for which physical access to the vessel is needed, which is much more difficult.

Proposed Approach

The scenario : A maritime shipping company has a FLEET of 100 ships in the ocean operating across the globe. Each ship has a fully functional OSNMA receiver, an AIS, and a DID management utility. Ships can communicate with the FLEET central server.

The objective : The task is to detect an OSNMA meaconing attack on a ship or a cluster of ships operating in a bounded geographical region in the ocean (a global attack is not economical for an attacker, so this scenario can be safely ignored).

To address this, we propose a Scurid-based solution. Our approach works in the following steps:

Step 1 : Each vessel generates a Signed Observation Bundle (SOB). Alongside its standard AIS position report that includes the calculated latitude, longitude, GST etc. the vessel's OSNMA-capable transponder packages the current TESLA chain ID and epoch index, the highest verified key index, a hash of the last verified key, the sub-epoch page counter (0–14), and the pending MAC tag for each tracked Galileo satellite. All fields are signed with the vessel's hardware DID private key. The vessel runs Scurid EdgeAgent -- a lightweight software responsible for signing the AIS data and other metadata.

Step 2 : Bundles transmitted to the FLEET central server. The SOB travels alongside or embedded in the AIS transmission. We set the number of ships (n=100). The server receives 100 signed SOBs every 2 seconds from the fleet. In our PoC we use our Scurid central server, which acts as the FLEET central server.

Step 3 : Server verifies all DID signatures. Bundles with invalid or revoked DID signatures are immediately flagged. This step requires O(N) signature verifications.

Step 4 : Fleet consensus TESLA state computed. The server takes the majority value of epoch index, key hash, and page counter across all verified bundles. With 90% honest receivers and 10% relay victim, the consensus is unambiguous. The criteria can be further enhanced to weight reported OSNMA parameters against an anomaly detection function, rather than the traditional 51% (majority win) criteria.

Step 5 : Four detection checks run in parallel:

1. F-epoch : Any vessel reporting a different epoch index than the fleet consensus is flagged with certainty.
2. F-hash : Any vessel reporting a different verified key hash is flagged with certainty.
3. F-page : Any vessel with a page counter more than 1 behind the fleet median is flagged, with estimated relay delay = lag × 2 seconds.
4. F-tag : For vessels sharing visible satellites or with the same satellite visibility set, MAC tag values must be identical. Any mismatch flags the outlier.

Step 6 : Verdict signed and anchored. The fleet verdict — a per-vessel authentication status — is signed by the fleet central server and anchored to a distributed ledger. The relay evidence is non-repudiable and available for incident investigation.

Step 7 : Vessels informed about the findings. At the end of the execution, the FLEET server informs the vessels about the correct OSNMA parameters for the iteration. Using the received OSNMA parameters from the server, the vessel can self-assess whether it received a spoofed OSNMA signal or not.

Conclusion

The relay attack has been the one threat that OSNMA, for all its elegance, cannot touch. Our proposed DID-based solution solves the problem using a resource that was always there: the fact that every honest Galileo receiver on Earth is beating to the same cryptographic clock. When a vessel's AIS position is relay-attacked, its TESLA heartbeat falls behind the fleet's. That lag is written into a DID-signed record that the attacker cannot modify, transmitted to a central server that compares it against a hundred other vessels ticking in unison, and flagged within 2 seconds of the relay activating. No reference stations. No peer proximity. No external infrastructure.