DID for Secure AIS Messages and Data Delivery for Maritime Vessels

Every vessel at sea announces who it is and where it is over AIS, and every receiver simply believes it. AIS messages are broadcast in plain text with no encryption, no signature and no hash, and the position inside them comes from GNSS signals that can be replayed. In this post we walk through our work on giving each vessel a Decentralized Identifier (DID), using it to sign AIS messages and protect them against replay, and then building on those signed messages to deliver time-bound Galileo artefacts to vessels far from shore.

This is a follow-up to The Day Ships Sailed Over Airports, where we looked at relay attacks on Galileo OSNMA.

Introduction

Advanced maritime communication supports the use of satellite infrastructure for low-latency services. In recent years, Low Earth Orbit (LEO) satellite-based services have been explored as a viable option for shore-to-ship communication. Besides being affordable and low latency, their operation is sometimes affected by extreme weather conditions and by geographic censorship of LEO constellations. In such scenarios, proximity-based routing that supports ad-hoc data transmission can be an alternative, and the proximity information comes from the vessel's Automatic Identification System (AIS) messages.

The Global Navigation Satellite System (GNSS) lets maritime vessels precisely locate themselves in the ocean. GNSS comprises constellations of Earth-orbiting satellites that broadcast their location in space. Receivers capture these signals and calculate ground positions, and from them a vessel also determines its navigation, velocity and time. Maritime self-reporting systems such as AIS depend heavily on GNSS to calculate the Position, Navigation and Timing (PNT) information they transmit.

Ensuring that these parameters are calculated correctly from the received signals is a challenge. GNSS signals transmitted from space can be received by any compatible receiver, which opens the door to different sorts of attacks. An attacker can capture a GNSS signal and relay it later, making the legitimate receiver on a vessel calculate valid but incorrect parameters. Most GNSS systems lack an authentication mechanism. Addressing this is of prime importance, because such attacks can result in catastrophes such as accidents: the position values obtained from the received signals are shared with nearby vessels over AIS messages, for example for hull-to-hull docking.

Galileo attempts to solve this problem with Open Service Navigation Message Authentication (OSNMA), an authentication mechanism for its signals. OSNMA lets the receiver verify that a signal is not outdated or modified beyond a certain timeframe. It is still unable to address spoofing and meaconing attacks. More recently, Galileo released the Signal Authentication Service (SAS), which ensures that the signal received by a receiver is coming directly from one of the Galileo satellites and not from any other entity. This rules out signal spoofing.

There is a prerequisite for SAS to work. The receiver must possess certain artefacts, called Re-Encrypted Code Sequences (RECS), before signal verification can take place. RECS files are made available through the Galileo servers, and receivers can download them in advance, but no more than 7 days into the future. That is acceptable for on-ground receivers with internet access. It is a bottleneck for offshore vessels sailing in the middle of the ocean: long-haul vessels, such as transportation vessels, can be at sea for weeks, away from internet infrastructure, and storing RECS files for more than 7 days of verification is considered insecure [5]. Periodic download of RECS files from the Galileo servers can also result in behaviour profiling of the vessels, which is a concern for shipping businesses, and there are reported incidents of service disruption because of unplanned Galileo server downtime [11].

This calls for a decentralized, secure and privacy-preserving approach to RECS file dissemination. In this work we introduce a satellite-assisted and ad-hoc peer-to-peer data transfer mechanism for maritime vessels. We use a decentralized identity (DID) to authenticate AIS messages, provide replay protection, and deliver SAS artefacts. The work relies on LEO constellations for data delivery and falls back to peer-to-peer data sharing when needed.

Related work

AIS is now a fundamental part of maritime communications and is used for applications including collision avoidance, self-reporting, maritime surveillance and voyage safety [1]. An AIS-based routing protocol to extend shore-based networks to near-shore waters is proposed in [4], and an opportunistic network routing protocol for maritime voluntary observation vessels is provided in [14]. AIS supports a number of message types, each carrying different information. Because these messages are unencrypted and unauthenticated, they are prone to attacks such as replay and spoofing [3].

Several works study security challenges in AIS [17], and several research efforts have tried to counter them:

1. Su et al. [18] propose a privacy-preserving vessel authentication scheme using AIS. It relies on a digital certificate-based identity authentication scheme to give authenticity to AIS messages, and on a mixzone and blind signature-based scheme for trajectory privacy. It depends on a centralized trust authority, the Certificate Authority (CA), and unavailability of the CA may make the entire approach ineffective.
2. SecAIS [12] is a secure automatic identification system, and there are also a couple of works that use identity-based cryptography for secure AIS [13].
3. Auth-AIS [2] uses TESLA and Bloom filters for authentication, with security provided by an HMAC-based approach. Because it uses HMAC with a symmetric key, it raises several issues. If the same key is used between two vessels, it is difficult to determine which one is the sender and which one is the receiver. If different keys are used, there are key management issues. It also needs a secure mechanism to deliver the key to each vessel before communication takes place, which is not a scalable idea.

We have also not found any work in the literature that attempts to bring confidence to the PNT calculation made by the vessel before it is transmitted as part of the AIS message.

Motivation

Despite several efforts in recent years, there is a lack of scalable, secure and privacy-preserving mechanisms for AIS message delivery. Existing works mainly rely on centralised infrastructure, which is neither reliable nor highly available. Decentralised technologies such as blockchain and decentralised identity are possible contenders for a secure and privacy-preserving AIS mechanism, and DIDs have already been used for seamless control, especially in IoT. Building on these technologies, this work aims to address the challenges described in [15]. The goals are:

1. Provide a geographic location validity check
2. Provide an order check for AIS messages
3. Provide a secure and privacy-preserving authentication mechanism for AIS messages
4. Provide integrity checks for AIS messages

In addition, the work gives the vessel self-sovereign control over its data. This is extremely useful when interacting with non-trusting entities such as border security in international waters. The vessel can decide which information to disclose based on the requirement, and then disclose that specific information only.

Background

Galileo OSNMA

On July 24, 2025 [7], the Galileo OSNMA service became active, making Galileo the first civilian GNSS constellation to offer cryptographic authentication of its navigation signals. OSNMA employs the TESLA (Timed Efficient Stream Loss-tolerant Authentication) protocol [8], which makes signal forgery computationally infeasible for an attacker, as any receiver that implements the full TESLA key chain verification can verify signal authenticity. This is a decisive advance against the dominant class of GNSS spoofing attacks.

OSNMA authenticates Galileo I/NAV navigation messages as follows:

1. A one-way key chain K[0], K[1], …, K[N] is generated such that K[i] = H(K[i+1]), where H is SHA-256 truncated to 128 bits.
2. Each key K[i] is used to generate HMAC authentication tags for navigation messages transmitted during epoch i, and is disclosed two epochs later (a 60-second delay, as specified in ICD v1.1 [8]).
3. Receivers verify the integrity of the disclosed keys by checking the one-way chain relation K[i] = H(K[i+1]), anchored by the ECDSA-P256-signed root key (KROOT) distributed by EUSPA.
4. Galileo I/NAV messages are transmitted in 30-second subframes, each comprising fifteen 2-second pages.

Because the TESLA key schedule is defined globally, honest receivers observing the same Galileo System Time (GST) epoch are expected, under nominal reception conditions, to validate the same disclosed TESLA key and accumulate authentication tags generated with the same current key for commonly observed satellites.

However, OSNMA is acknowledged, in the OSNMA ICD itself and in the academic literature, to not protect against meaconing (relay) attacks [20][16]. A relay attack retransmits genuine, OSNMA-authenticated signals from an actual location to a receiver located elsewhere. Since the signals are legitimate, OSNMA verification is successful.

The crisis in the Strait of Hormuz in 2026, where more than 1,100 vessels faced synchronized GPS disruptions within a single day [9], along with the 1,900 recorded GPS interference incidents at eight airports in India from 2023 to 2025 [6], highlights the pressing need to address this vulnerability.

Current methods for detecting relay interference fall into two groups. Single-receiver strategies, such as clock offset anomaly, Doppler consistency and IMU divergence [19], can be circumvented by adept attackers. Multi-receiver geometric techniques, like TDOA double differences, require the receivers to be physically close. Neither approach is suitable for a globally distributed fleet, such as a naval organisation or a shipping company, whose receivers are spread across vast ocean regions.

Galileo SAS

A replay attack can be performed even when an authenticated GNSS service like OSNMA is used. To address this, the Signal Authentication Service (SAS) is being introduced. SAS complements OSNMA by proving that the signal received by the GNSS receiver originates from a satellite of the Galileo constellation. Galileo SAS uses the existing Galileo E6C signal, encrypted, in combination with OSNMA. Portions of E6C are re-encrypted with the OSNMA future keys and published on a server [10]. These Re-Encrypted Code Sequences (RECS) are published on the GSC servers, from where receivers can download them.

Automatic Identification System (AIS)

AIS plays a crucial role in traffic management, search and rescue, and collision avoidance [15]. It is a situational awareness system that allows vessels at sea and maritime authorities to be aware of each other's presence by broadcasting identification and position information. AIS was conceived in the early 1990s, particularly for collision avoidance, as an availability-only feature, and security was never considered.

AIS messages are broadcast in plain text without any encryption, signature or hashes, which allows any malicious entity to capture a broadcast message with a Software Defined Radio (SDR). The captured messages can later be forged and replayed, deceiving a vessel into changing its course. A malicious entity, such as a group of pirates, can capture and replay AIS messages to force a shipping vessel into a vulnerable area.

Each AIS device is identified by a unique Maritime Mobile Service Identity (MMSI). Although the MMSI is considered to be unique and specific to a vessel, there are no guarantees, because AIS has no authentication support. MMSI numbers are prone to forgery and tampering, and there are reports of the same MMSI being shared across several vessels at different time instances [18].

Proposed system

System model

The system model consists of three different entities: the vessels, the LEO satellites, and the shore-based ground stations.

Each vessel has an OSNMA receiver, a SAS processing module and AIS installed, and is uniquely identified with a DID. The private key associated with the DID is securely stored on the vessel and remains under the sole control of the vessel. Vessels can now digitally sign AIS messages and encrypt communications with their peers. To sign an AIS message the vessel uses its private key, and peer vessels that receive the signed message verify it against the public key of the signing vessel.

Vessel capabilities

1. OSNMA receiver module. It receives and processes Galileo E1-B signals, verifies TESLA authentication chains, and maintains local authentication-state evolution.
2. SAS processing module. Software capable of processing encrypted E6-C signals for generating anti-spoofing and anti-replay PVT data.
3. Secure TPM. A trusted platform module responsible for storing private keys securely. In our case it stores the private key of the DID.
4. Communication interface. It exchanges telemetry with fleet infrastructure. Data can be transferred over maritime networks, including VDES, AIS extensions, Wi-Fi mesh, LTE/5G, satellite links and delay-tolerant opportunistic networks, while remaining resilient to packet loss, communication delays, network partitions and the absence of shore-side infrastructure.

LEO satellite

LEO satellites provide low-latency data delivery because they fly at relatively low altitudes, typically between 200 and 2000 km [21]. In our system, a LEO satellite is given a DID registered on the blockchain, and the key pair associated with that DID is used for authentication. The LEO satellite talks, through the ground station, to the maritime server hosting the artefacts. The maritime server in turn fetches the latest artefacts periodically from the GSC via the internet. The LEO satellite is also responsible for delivering updated Merkle root information to offshore vessels.

Decentralized identity

While Galileo OSNMA guarantees the authenticity and integrity of navigation messages transmitted by Galileo satellites, it does not authenticate the identity of the vessels exchanging observations. To establish trust among collaborating vessels, we need a robust, decentralized authentication mechanism with high availability. Decentralized Identity (DID) is a strong candidate.

A DID is a globally unique cryptographic identifier, anchored preferably on a distributed ledger such as a blockchain. For a vessel, it is issued by the flag state authority at registration. It is analogous to the MMSI, but unlike the MMSI it is cryptographically bound to a key pair stored on the vessel. The vessel's DID document is publicly resolvable by anyone on the ledger and contains the vessel's public key, communication endpoints and other non-PII. It is a machine-verifiable identity card for the vessel.

{
  "@context": ["https://www.w3.org/ns/did/v1"],
  "id": "did:vessel:0xb96ab6f1A9a20276512F731A455Ed21784eEcb5c",
  "controller": "did:vessel:0x14149d43c82f08a3bb5a07586A00a55126A41107",
  "verificationMethod": [{
    "id": "did:vessel:0xb96ab6f1A9a20276512F731A455Ed21784eEcb5c#key-ais-1",
    "type": "JsonWebKey2020",
    "publicKeyJwk": { "kty": "EC", "crv": "P-256" }
  }],
  "service": [
    { "type": "RevocationStatus", "endpoint": "https://registry.vessel.eu/..." }
  ],
  "authentication": [
    "did:vessel:0xb96ab6f1A9a20276512F731A455Ed21784eEcb5c#key-ais-1"
  ]
}

A DID-based approach provides several security benefits:

1. Authentication: confirms the identity of the vessel producing each observation.
2. Authorization: ensures that only credentialed vessels participate in the system.
3. Non-repudiation: cryptographically binds every transmitted observation to its originating vessel.

The vessel DID is bound to the vessel's hardware, which makes it immune to identity theft, as a compromise of the keys alone will not allow the attacker to sign messages on behalf of the vessel. A successful attack would instead require compromising the vessel's hardware, which needs physical access to the vessel and is much more difficult.

Vessel DID registration and revocation

A new vessel joining the fleet generates its public and private key pair on its own, and forms its DID from the generated public key. This DID uniquely identifies the vessel in the ocean, and the private key is used for signing the transmitted data. A competent authority, such as the shipping company, is responsible for registering the DID of the vessel. The authority forms a DID document containing the characteristics of the vessel, and the DID document is bound to the DID of the vessel. The registration is done on a trusted shared platform, such as the blockchain. The same shipping company is entrusted with vessel DID revocation.

Vessel DID resolution

A vessel DID needs to be resolved to obtain information specific to the vessel. A vessel that receives a vessel DID from its peers resolves that DID. We introduce a two-level approach for DID resolution.

At Level 1, vessels maintain a local datastore of known vessel DIDs and their corresponding DID documents. When a vessel DID arrives, it is searched for in the local datastore with the help of a resolver. If no entry is found in the local datastore, a query is made to the public Verifiable Data Registry (VDR). This comes in handy when the vessel is operating in the middle of the ocean, where proper communication infrastructure is unavailable. Vessels can sync periodically or opportunistically with the Level 2 VDR to update the state of the local datastore.

Design goals

Functional goal. The approach aims to provide a privacy-preserving authentication mechanism for standard AIS messages. Unlike MMSIs, which are reused by different vessels, our DID-based vessel identity is unique throughout the system. The work also extends to a secure data delivery mechanism for offshore vessels, which relies on secure AIS messages.

Security goal. The approach should provide secure authentication and tamper-proof data delivery.

Privacy goal.

1. Privacy guarantees for peer-to-peer: a vessel should not learn any details about its peer besides its DID and operation status.
2. Privacy guarantees for file download: the centralised artefact server, in our case the Galileo GSC, should not be able to identify an individual vessel.

The approach should not leak any vessel-associated private information.

Attack model

We assume there are active as well as passive attackers in the system. The attacker listens to the communications happening in and around it, including the ones in which the adversary is participating. The attacker is eager to learn from the communication and also to modify the messages being communicated for personal gain.

Proposed scheme

This section covers the setup, signature, verification and data delivery mechanism of our approach.

Setup

A vessel generates a public-private key pair. It then derives a DID from its public key and approaches the Registration Authority (RA) for registration before it starts operating at sea. The RA is considered to be a trusted authority in the system. The vessel submits its public key and DID, along with other details, to the RA. The RA verifies the vessel details, such as the owner details, operating conditions and insurance. Once the due diligence is done, and if the vessel satisfies the ready-to-operate conditions, the RA makes an entry of the vessel's DID and public key in the VDR, adds the vessel DID to the Merkle tree as a leaf node, and updates the Merkle tree. It then signs the necessary details of the vessel and delivers them to the vessel as a credential.

Sign and send AIS data

The vessel generates the information to be transferred as AIS messages, using several onboard components such as the GNSS receiver to capture signals from space. Once the information for the AIS message is gathered, the vessel adds a nonce value, hashes the AIS message along with the nonce, and digitally signs it with its private key. Then the vessel broadcasts the message.

The vessel also shares its Merkle path: starting from the leaf node whose data is the vessel DID, it sends the adjacent leaf node, which is used together with the vessel DID to calculate the hash at the layer above, and so on up to the Merkle root.

Verify AIS data

The peer vessel, upon receiving the AIS message from the sender vessel, verifies the signature. The signature should match against the sender's vessel DID. Once the signature is matched, the verifier hashes the AIS message and compares it against the hash sent by the sender vessel.

The vessel also checks the validity of the DID, to determine whether the vessel DID is revoked or not. The check is made by tracing the Merkle path from the vessel DID leaf node to the Merkle root.

Algorithm 1: Merkle tree verification

procedure VerifyMerkleProof(leaf, proof, index, root)
    Input:
        leaf  ∈ Bytes         // the data block being verified
        proof ∈ List[Bytes]   // ordered array of sibling hashes from leaf to top
        index ∈ Integer       // 0-based position of the leaf in the tree
        root  ∈ Bytes         // the trusted Merkle root
    Output: Boolean           // true if valid, false otherwise

    // Step 1: compute initial leaf hash using leaf domain separation (0x00)
    currentHash ← Hash(0x00 ∥ leaf)

    // Step 2: iteratively climb the tree using the proof elements
    for each sibling in proof do
        if index mod 2 == 0 then
            // index is even: currentHash is left child, sibling is right
            currentHash ← Hash(0x01 ∥ currentHash ∥ sibling)
        else
            // index is odd: currentHash is right child, sibling is left
            currentHash ← Hash(0x01 ∥ sibling ∥ currentHash)
        // move to the parent level using integer division
        index ← ⌊index / 2⌋

    // Step 3: check if the final computed hash matches the trusted root
    return (currentHash == root)

Peer-to-peer data delivery

1. Satellite assisted. When connectivity to the LEO satellite exists, the vessel that needs to download the RECS file makes a request through the satellite. The satellite authenticates the incoming requests and delivers the artefacts.
2. Vessel to vessel. When satellite communication is unavailable or poor, either because of subscription issues or weather conditions, the vessel can request the latest RECS artefacts from nearby peer vessels that possess recent RECS artefacts. As in the satellite-assisted transfer, both vessels first authenticate themselves before initiating data transfer.

Once the received AIS message is verified, a vessel can be assured of the legitimacy of its peer. A vessel that needs to download a RECS file can now make a request to its peers. The requesting vessel periodically broadcasts request messages, and peer vessels with a valid RECS file can reply. Because of the overheads of public key encryption, we propose shared key encryption for encrypting the RECS file chunks.

Algorithm 2: Sign and transmit the RECS file

procedure SignAndTransmit(file, K)
    chunks ← Split(file)
    r ← 0
    while r ≠ Len(chunks) do
        data ← chunks[r]
        tag ← HMAC(data, K)
        Send(data, tag)
        r ← r + 1
    return true

Algorithm 3: Receive and verify the RECS file

procedure ReceiveAndVerify(K)
    fileBuffer ← List()
    while (data, tag) ← socket.Recv() ≠ EOF do
        b ← HMAC(data, K)
        if tag == b then
            fileBuffer.append(data)
    return fileBuffer

Security analysis

1. Non-repudiation. Non-repudiation is a mechanism to prevent a party that took part in a communication exchange from later denying that it sent a message.
2. Non-repudiation in AIS message delivery. This is achieved through the use of the DID, as each AIS message is digitally signed with the private key associated with the DID, whose sole possession lies with the vessel.
3. Non-repudiation in file transfer. When a vessel transfers a file to its peer, it calculates the HMAC on the data to be transferred and sends it alongside the plaintext data. The secret key used to derive the HMAC is securely shared with the existing PKI.
4. Anonymous authentication. A DID is a pseudonym that exposes no Vessel Identifiable Information (VII). The mapping of a DID to its VII is known only to the registration authority, which is a trusted authority in the system.
5. Efficient data transmission. The use of symmetric key cryptography and HMAC for file transfer provides efficient data transmission.
6. Replay-resistant AIS messages. The nonce field introduced in this work provides immunity against replay attacks in the system.

Experiment and results

We simulated the experiment on a personal computer, a MacBook Pro M2 with 8 GB of RAM and a 256 GB SSD. Both the sender and the receiver side of the AIS message were simulated.

Cryptographic latency

We measured the signature generation and verification time.

Message size comparison

The signed wrapper is 788 bits: a 20-bit nonce, 256 bits of AIS data (Type 1 plus padding) and a 512-bit ECDSA signature. Although our approach has a higher payload in comparison to plain AIS, it is still below the AIS payload limit of 1008 bits, as the budget bar in the message structure figure above shows.

Channel load comparison

DID resolution response time

We implemented the VDR on the Sepolia testnet, a public Ethereum test network, as a smart contract. The Certificate Authority deploys the VDR smart contract on the blockchain. The smart contract implements the data structure used to form the DID document, and exposes a getter function to retrieve the records needed to form the DID document. For the local data registry we used BadgerDB. We measured the response delay for resolving a DID to a DID document in three scenarios. The DID document size was found to be 571 bytes.

Algorithmic analysis of Merkle tree verification

Merkle tree verification consists of two main operations:

1. Leaf search: locate the index of the leaf node in the tree.
2. Inclusion proof computation: compute the Merkle tree root from the leaf node.

In our case the leaf search is not needed, because the sender sends the subtree from the concerned leaf to the Merkle tree root. Not all vessels can efficiently store the entire tree, as it needs frequent updates. The only task in hand is to compute the inclusion proof. The worst-case complexity of inclusion proof checking is O(log n), where n is the number of leaves in the tree.

Discussion

1. Location validity check. Location validity is assured by using the Signal Authentication Service from Galileo alongside the OSNMA service. OSNMA guarantees that the signal is generated from a valid Galileo satellite, and SAS guarantees that the signal is really transmitted directly from the satellite and not replayed from any other source.
2. Order check for AIS messages. The work introduces a nonce field to distinguish between two AIS messages. A receiver always waits for an AIS message with a nonce greater than the present nonce available for an AIS transmitter. Any AIS message with a lower nonce is considered stale and is discarded. This handles the replay attack.
3. Authenticated AIS. AIS transponders are provided with a DID. Each AIS message transmitted by a transponder is digitally signed with the transponder's private key.
4. Integrity check for AIS messages. The integrity of an AIS message is preserved, as the transponder digitally signs the AIS message hash. At the receiving end, the AIS receiver hashes the AIS message and compares it with the digitally signed hash.
5. Enhanced LEO satellite service management. As both the satellites and the vessels are registered on the blockchain with uniquely identifiable DIDs, a satellite provider can efficiently manage subscriptions.

Conclusion

Secure data delivery in the open ocean is a challenge. The messages relayed are available for capture, modification and replay by any adversary, and the same applies to AIS, an information-sharing protocol in maritime. In this work, a secure and privacy-preserving approach for data delivery to offshore vessels is proposed. It uses a DID for vessel identification and authentication. The DID provides privacy to the vessel, as it does not disclose identification details of the vessel beyond the pseudonym, and vessels can now securely share relevant data as needed. The vessel DID resolves to a DID document, which tells peer vessels how to interact with it.

The work further shows how the enhanced AIS message can be used to deliver artefacts to vessels, with RECS file transfer as the use case. The vessel uses a symmetric key for data encryption during transmission, and the symmetric key is shared using the DID keys. The approach is implemented and its performance is measured. The channel load for authenticated AIS message transmission is within the 9600 baud rate limit.

References

1. Arifin, M.D., Muslim, M., Octaviani, F., Faturachman, D.: Review of automatic identification system: Application, challenge and limitations. Int. J. Mar. Eng. Innov. Res 9(3), 464–475 (2024)
2. Auth-AIS: Secure, flexible, and backward-compatible authentication of vessels AIS broadcasts (2021)
3. Balduzzi, M., Pasta, A., Wilhoit, K.: A security evaluation of AIS automated identification system. In: Proceedings of the 30th Annual Computer Security Applications Conference, pp. 436–445 (2014)
4. Duan, J., Jiang, S., Guo, L., Zhang, J.: An AIS-based routing protocol for extending shore-based networks to near-shore water areas. Ocean Engineering 341, 122562 (2025)
5. EUSPA: Galileo ACAS (2026)
6. Over 1,900 incidents of GPS spoofing of aircraft reported in two years, Centre tells Lok Sabha. The New Indian Express (2025)
7. EUSPA: Galileo Open Service Navigation Message Authentication (OSNMA) (2026)
8. RFC 4082: Timed Efficient Stream Loss-Tolerant Authentication (TESLA)
9. Windward: GPS jamming disrupts 1,100 ships in the Middle East Gulf (2026)
10. Fernandez-Hernandez, I., Winkel, J., O'Driscoll, C., Willems, T., Cancela, S., Ramirez, M.A., Terris-Gallego, R., Lopez-Salcedo, J.A., Seco-Granados, G., Fuchs, F., et al.: Prototyping Galileo signal authentication service: Current status and plans. Engineering Proceedings 126(1), 40 (2026)
11. Inside GNSS: Galileo outage update: service failure poses serious questions
12. Goudosis, A., Katsikas, S.: Secure automatic identification system (SecAIS): Proof-of-concept implementation. Journal of Marine Science and Engineering 10(6), 805 (2022)
13. Goudosis, A., Katsikas, S.K.: Secure AIS with identity-based authentication and encryption. TransNav: International Journal on Marine Navigation and Safety of Sea Transportation 14(2), 287–298 (2020)
14. Ji, M., Cui, X., Li, J., Zhang, H., Li, S., Liu, J.: An opportunistic network routing protocol for maritime voluntary observation ships. Procedia Computer Science 202, 390–393 (2022)
15. Kessler, G.C., Zorri, D.M.: AIS spoofing: A tutorial for researchers. In: 2024 IEEE 49th Conference on Local Computer Networks (LCN), pp. 1–7. IEEE (2024)
16. Lenhart, M.: Distributed relay/replay attacks on GNSS signals (2022)
17. Ray, C., Gallen, R., Iphar, C., Napoli, A., Bouju, A.: DeAIS project: Detection of AIS spoofing and resulting risks. In: OCEANS 2015 - Genova, pp. 1–6. IEEE (2015)
18. Su, P., Sun, N., Zhu, L., Li, Y., Bi, R., Li, M., Zhang, Z.: A privacy-preserving and vessel authentication scheme using automatic identification system. In: Proceedings of the Fifth ACM International Workshop on Security in Cloud Computing, pp. 83–90 (2017)
19. Suárez, P.G.: Python implementation of an anti-replay method for Galileo OSNMA using sample-level partial-correlation metrics. arXiv (2026)
20. Wang, H., Zhang, Y., Shen, Y., Zhu, J., Chen, Y., Jiang, X.: Novel replay attacks against Galileo open service navigation message authentication. In: Proceedings of the 36th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS+ 2023), pp. 3897–3907 (2023)
21. Yang, Q., Laurenson, D.I., Barria, J.A.: On the use of LEO satellite constellation for active network management in power distribution networks. IEEE Transactions on Smart Grid 3(3), 1371–1381 (2012)