2. Vulnerability of AIS to spoofing attack

AIS makes use of two frequencies in the maritime VHF band, namely 161⋅975 MHz and 162⋅025 MHz (VHF channels AIS 1 and AIS 2) (International Telecommunication Union, 2014). The AIS protocol allows the exchange of short messages in certain specified formats with a bit rate of 9⋅6 kbps. The available AIS bandwidth is shared between its users by way of time division multiple access (TDMA). This divides the bandwidth of each AIS channel into 2,250 time slots established every 60 s. Each time slot can thus represent up to 256 bits of information with the majority of ‘ordinary’ AIS messages typically taking up one time slot. Transmission time slots are allocated to users through a system of self-organisation (SOTDMA) or, in the case of AIS equipment fitted to non-SOLAS vessels, by carrier sensing (CSTDMA).

AIS is primarily used as a situational awareness tool with vessels, and some maritime aids to navigation (AtoN), conveying their identity and position (usually obtained from a local global navigation satellite systems [GNSS] receiver) via AIS to nearby vessels and shore stations. This data is then typically displayed to the end-user via an electronic chart display and information system (ECDIS), though other display types are also prevalent.

The AIS protocol was developed on the basis that all vessels, shore stations and AtoN need to be able to transmit location (and other) data to each other freely and openly. As such, the civilian AIS protocol was developed with no encryption or authentication mechanism. This makes it possible for a malicious actor to transmit (spoof) any conceivable AIS message and it will be taken at face value; processed by any AIS receiver within range as if the message was genuine.

Such AIS spoofing attacks may be used to spoof the presence of AtoN or vessels on ECDIS and other AIS displays; however, a range of more serious attacks are possible, including:

• • Driving a vessel off course or re-routing it by spoofing the presence of virtual aids to navigation (VAtoN) via a spoofed ‘AIS Message 21’. VAtoN have no physical presence, but instead provide data via an AIS message which is used to display the presence of AtoN electronically on an ECDIS. Legitimate uses for VAtoN include the marking of new hazards (such as a dangerous wreck) whilst authorities arrange for a physical AtoN, or in instances where a physical AtoN is not appropriate.

• • Spoofing a vessel's reported position by providing it with false DGNSS corrections via a spoofed ‘AIS Message 17’. Such an attack could interfere with a vessel's ability to navigate safely and has the potential to lead a vessel into harm (depending on how this data is used on the bridge).

• • Performing denial of service attacks by misusing AIS channel management broadcasts via spoofing ‘AIS Message 22’. Such broadcasts could be used to instruct all AIS transceivers within range to cease operation or switch their AIS broadcasting onto an inappropriate maritime VHF channel, thereby interfering with other maritime communicationsFootnote ¹.

The above are all particularly nefarious forms of attack as, unlike spoofing the presence of a physical AtoN or vessel, these spoofing attacks cannot be verified visually or against data from another system, such as radar, and the mariner is reliant solely on AIS data.

By ignoring TDMA allocations, one single transmitter may occupy multiple consecutive AIS transmission time slots and thus spoof thousands of AIS messages per minute. This could allow a malicious actor to spoof the presence of a very large number of vessels (which could be used to hinder vessel traffic services operations) and/or simultaneously spoof very large numbers of AtoN and/or VAtoN using just a single transmitter. Such a ‘mass’ spoofing attack could mask the presence of a genuine virtual AtoN by surrounding the area with spoofed examples; the mariner would then have no way of identifying which is genuine. Mass spoofing attacks could also spoof the presence of multiple vessels, AtoN or VAtoN at the same coordinates as a legitimate radar return, thereby hindering identification of the return.

AIS spoofing attacks have been observed ‘in the wild’, a number of which are described by Androjna et al. (Reference Androjna, Perkovič, Pavic and Mišković2021). These include an incident of mass AIS spoofing identified off the island of Elba in December 2019 where 3,741 vessels were spoofed, all densely packed into a small sea area.

3. Cryptographic authentication of AIS

To guard against spoofing, the direction of arrival of AIS transmissions could be used to indicate if they originate from their reported source of transmission. Direction-finding techniques are, however, useless against those AIS message types which do not state their transmission coordinates and are therefore useless in guarding against the more serious VAtoN, DGNSS and channel management spoofing attacks described above; none of which state their transmission coordinates within the AIS message.

Unlike direction-finding techniques, prior work by the authors has identified a cryptographic authentication system, using PKC to ‘digitally sign’ messages, as capable of providing unequivocal evidence that all AIS message types originate from genuine sources and so can be trusted (Wimpenny et al., Reference Wimpenny, Šafář, Grant, Bransby and Ward2018). PKC is explained further in earlier work by the authors (Wimpenny et al., Reference Wimpenny, Šafář, Grant, Bransby and Ward2017); however, a summary of how it is used for authentication is provided here for convenience.

PKC uses two mathematically related keys, a public and a private key, together known as a key pair. The public and private key (both stored as computer files) are used to encrypt and decrypt data. The public key is openly distributed to all users, whereas the private key is kept secret and known only to the message sender. To authenticate a message, the sender encrypts the message using their private key. In so doing, the message may only be decrypted with the public key. This does not provide secrecy as the message may be decrypted by any user with the openly available public key, but provides authentication; by decrypting the message with the public key the user knows it can only have been encrypted by the holder of the private key (the message sender) and therefore cannot have been spoofed or otherwise manipulated by a malicious actor.

Rather than encrypt the entire message with the private key (and so prevent a recipient without the public key from reading it), the preferred approach is to broadcast the message unencrypted in plain sight with an accompanying digital signature. To accomplish this, the sender first uses a ‘hash function’ on the message they wish to sign. This is an algorithm that maps message data of arbitrary size to a separate fixed-size string of characters. This separate string of characters, unique to the message, is known as a digest. The digest (not the message) is then encrypted with the private key to produce a digital signature. This digital signature may be sent separately, alongside the unencrypted message to provide authentication of the message.

When using PKC for authentication, numerous algorithms with varying key sizes are available which provide varying levels of security, speed and subsequent size of digital signature. The PKC algorithms recommended for use in authenticating AIS are the SHA-256 hashing algorithm and the elliptic curve digital signature algorithm (ECDSA) with a key size of 256 bits and using the ‘secp256r1’ curve (Wimpenny et al., Reference Wimpenny, Šafář, Grant, Bransby and Ward2018). These algorithms and key sizes were chosen as it was shown that they give relatively small digital signatures, 512 bits in size, which are capable of fitting within a multi-part AIS message. The algorithms and key sizes also provide robust security, as indicated in a report authored by the then European Union Agency for Network and Information Security (ENISA, 2013) and by the US National Institute for Standards and Technology (NIST) (Barker, Reference Barker2020).

To maintain backwards compatibility with the current use of AIS, authentication is accomplished not by modifying existing AIS data messages, but instead by including the digital signature in a separate ‘follow-on’ message, in the form of either an AIS binary ‘Message 6’ or ‘Message 8’. This is represented in Figure 1 where a Data Message (Message 21) containing details of a VAtoN is followed by a separate Signature Message (Message 8) containing the digital signature.

Figure 1. Representation of a virtual AtoN (Message 21) broadcast, followed by a broadcast containing a digital signature (Message 8) (Wimpenny et al., Reference Wimpenny, Šafář, Grant, Bransby and Ward2018)

For the recipient to link the Data Message with the correct Signature Message, a unique identifier is needed. AIS messages do not contain a unique identifier and backward compatibility would be lost should the AIS messages be modified to include one; whilst the Maritime Mobile Service Identity Number (MMSI) is routinely included in the headers of all AIS messages, the MMSI alone is unsuited for this task as multiple AIS messages will naturally contain the same MMSI, making it impossible to relate a Signature Message to an individual Data Message.

To overcome this, the approach used by Wimpenny et al. (Reference Wimpenny, Šafář, Grant, Bransby and Ward2018) is to include in the Signature Message a 64-bit timestamp relating to the time of the message being signed i.e. the time of the previous Data Message. It was further reasoned that by using a combination of timestamp and MMSI, the correct Signature Message could be uniquely linked to the correct Data Message and that this approach would retain backwards compatibility with the existing AIS protocol.

It is noted that to timestamp and correctly identify the Data Message, this approach requires both the message sender and recipient to have a local trusted clock synchronised to UTC. For simplicity, this should be the same local UTC clock synchronised to a GNSS time source as used for TDMA message synchronisation by the AIS transceivers.

It is further noted that the proposed technique verifies only the authenticity and integrity of AIS messages and does not prevent position tampering by feeding the AIS transponder with spoofed GNSS data. Addressing GNSS spoofing is beyond the scope of this paper.

4. Comparison of approaches to secure AIS

In recent years, several alternative approaches have been proposed to secure AIS. Of these, Hall et al. (Reference Hall, Lee, Benin, Armstrong and Owen2015) proposed an approach based on the IEEE 1609 standard for wireless access in vehicular environments. Whilst Hall's technique is robust, it is not backwards compatible with the existing AIS protocol, meaning its use would require a new AIS standard to be adopted. Furthermore, Hall takes steps to encrypt (as well as authenticate) some AIS data for privacy. Whilst there are advantages to encryption, such as preventing those engaged in piracy from reading AIS messages, the potential for legitimate users to be prevented from reading them suggests the routine use of encryption is inappropriate.

Stewart et al. (Reference Stewart, Rice and Safonov2018) proposed a backwards compatible approach to AIS authentication using a technique similar to that proposed by Wimpenny et al. (Reference Wimpenny, Šafář, Grant, Bransby and Ward2018) (described previously) in which an AIS Data Message is followed by a separate message containing a digital signature. However, Stewart does not address how the Data and Signature Messages can be linked together. Stewart therefore proposes an alternative method in which the follow-on message contains both data (repeated from the first message) and signature combined. A correctly equipped AIS receiver could then simply discard the first (unsigned) Data Message and opt to display only the signed follow-on message.

Whilst this combined message approach is both feasible and backwards compatible, it is considered by the authors as potentially unsuitable for authenticating those AIS messages that may take up more than one time slot, such as AIS Message 21. This is because (noting that Wimpenny et al. [2018] showed a secure digital signature requires four time slots) the combined data-signature message would exceed the five-slot maximum permissible size of AIS Messages 6 and 8. However, the possibility exists that a multi-slot Data Message might be compressed to fit the limited space, albeit this would add complexity. This possibility is not addressed here but could be considered as a future research option.

Goudossis and Katsikas (Reference Goudossis and Katsikas2019) proposed an approach, further developed in their later work (Goudossis and Katsikas, Reference Goudossis and Katsikas2020), that uses ‘identity based encryption’ (IBC) to both authenticate and/or encrypt AIS messages. Goudossis and Katsikas state that their proposed approach is unsuited to authenticating multi-slot AIS messages due to data-signature message sizes exceeding the five-slot maximum size of Message 6 and 8. IBC also has a potential disadvantage in that this technique requires a trusted third party to be employed to handle private keys. This may cause security and logistical difficulties.

Kessler (Reference Kessler2020) proposed an approach in which an AIS Data Message is followed directly by a digital signature as part of the same transmission, thereby avoiding difficulties linking a separate Data Message and Signature Message together. Kessler suggests this method is backwards compatible as a conventional AIS receiver not equipped to verify signatures would simply ignore the appended signature. This assumption is questionable, as receivers may instead reject the entire transmission as corrupt. This approach also violates the existing AIS standard described by ITU-R M.1371-5 (International Telecommunication Union, 2014). In a bid to minimise digital signature sizes, Kessler's approach uses the RSA cryptographic algorithm with 256-bit key sizes. Such small RSA keys are not considered adequately secure by NIST (Barker, Reference Barker2020).

More recently, Sciancalepore et al. (Reference Sciancalepore, Tedeschi, Aziz and Pietro2021) proposed a technique using the TESLA authentication algorithm. This algorithm reduces data overheads by broadcasting a Signature Message relating to the previous N Data Messages. This approach therefore introduces a delay before Data Messages can be verified and is thus thought less suited for use with infrequent AIS broadcasts; including AIS Message 21 which is normally broadcast at 3 minute intervals. Sciancalepore et al. use small, 80-bit security equivalent key sizes that are not considered adequately secure by NIST (Barker, Reference Barker2020).

5. Improved approach to AIS authentication

Improvements to the AIS authentication scheme first proposed by Wimpenny et al. (Reference Wimpenny, Šafář, Grant, Bransby and Ward2018), described in section 3, are identified which improve Data Message and Signature Message linking, address a security weakness and help avoid false positives to spoofing caused by changes to message syntax. These are described as follows.

5.2. Preventing vulnerability to a ‘replay attack’

A security weakness was identified with the authentication scheme as the timestamp (shown in Figure 1 as the ‘Tx time of message 21’) is not signed and therefore cannot be verified (it is noted that the authentication scheme proposed by Stewart et al. [2018] suffers from a similar weakness). This makes it possible for a malicious actor to record both the Data Message and Signature Message broadcasts, modify the timestamp to a later time and rebroadcast both messages at the new later time. Such a ‘replay attack’ would be undetectable as it effectively reuses a genuine digital signature. To protect against such an attack the authentication scheme must be adapted such that both the Data Message and timestamp are signed.

A procedure for accomplishing this is shown in Figure 2 where a Data Message (in this example, an AIS Message 21 broadcast) and timestamp (the transmission time of the AIS Message 21) are first merged into a new sentence. The new combined sentence is then hashed and signed to form the signature. The Signature Message (AIS Message 8) is then composed as previously, from the signature followed by the timestamp. The Data Message and Signature Message may then be broadcast from an AIS transceiver in the ordinary manner.

Figure 2. Modified digital signing procedure to guard against replay attacks

Upon receiving the Data Message the recipient will be able to read the message as normal without hindrance. The recipient may, if in possession of the sender's public key and having also identified and be in receipt of the Signature Message, then verify the Data Message using the procedure shown in Figure 3. Here it can be seen that the Signature Message is first split into its signature and timestamp components. Two operations then take place:

• • The Data Message and timestamp component are merged into a new sentence which is then hashed to obtain a digest.

• • The Signature component is decrypted with the public key to obtain the digest.

Figure 3. Verifying the Digital Signature

If both digests match then the Data Message is genuine, as only the private key holder could possibly produce a signature (an encrypted digest) that could be correctly decrypted with the public key. Any attempts to alter either the timestamp, Data Message or Signature Message will generate an incorrect digest and cause authentication to fail, alerting the recipient to the possibility of spoofing.

6. Impact of signatures on AIS channel loading

A Signature Message has a total payload of 576 bits; this consisting of a 512-bit signature and a 64-bit timestamp. It is shown by Wimpenny et al. (Reference Wimpenny, Šafář, Grant, Bransby and Ward2018) that the 576-bit payload fits into either an AIS Message 6 or Message 8 occupying four consecutive AIS time slots.

The vast majority of ‘ordinary’ AIS Data Messages occupy a single time slot. It is therefore evident that should each Data Message be followed by a Signature Message four times its size, then a significant impact on AIS channel loading will be seen.

This is shown in Table 1 where it can be seen that, unless only a small percentage of AIS messages are signed, the available AIS bandwidth will be quickly swamped by the inclusion of Signature Messages. The highlighted example shows that if AIS bandwidth is currently operating at 50% capacity (the base channel loading), then attempting to sign just 30% of these messages would exceed (110%) the available AIS bandwidth; this disregarding that AIS is unlikely to function optimally before its theoretical bandwidth limits are approached.

Table 1. AIS channel loading (%) due to the inclusion of four-slot Signature Messages

It is clear from Table 1 that AIS does not have sufficient bandwidth to routinely support the inclusion of digital signatures for all AIS messages. It is, however, likely that sufficient bandwidth is available to sign a small subset of AIS messages and that if this approach is pursued, consideration is given to signing only ‘high risk’ messages which have the potential to cause the most harm if spoofed. Consideration should therefore be given to signing only Message 21 (Aids to Navigation Reports), Message 17 (DGNSS Broadcasts) and Message 22 (Channel Management messages) previously identified as high-risk messages. This approach is likely to reduce the burden on available AIS bandwidth but may need to be reconsidered in areas of high AIS traffic where the base channel loading is already high.

7. Using the VDES to carry signatures

As AIS lacks the bandwidth to routinely support the inclusion of digital signatures for all AIS messages, consideration is given to carrying signatures in an alternative ‘side channel’. This is a preferred approach as the bandwidth required for the digital signatures will not impinge on the available AIS bandwidth. It also suggests the possibility of routinely signing and authenticating all AIS traffic, rather than only a small subset of high-risk messages.

The VHF Data Exchange System (VDES) allocates several channels in the maritime VHF band for data exchange (IALA, 2019). VDES offers higher bandwidths than AIS along with comparable propagation and thus has potential for use in carrying digital signatures for AIS messages. VDES also provides a benefit in supporting forward error correction (FEC) which will reduce the likelihood of digital signatures being corrupted in transit. Using this approach will require users to be equipped with suitable VDES hardware to send and receive the separate Signature Messages.

Two components of VDES are capable of carrying Signature Messages, namely the Application Specific Message (VDES ASM) component and the VHF Data Exchange (VDE) component. Their potential for use in carrying Signature Messages is described as follows.

7.1. Using VDES ASM to carry Signature Messages

Like AIS, there are two VDES ASM channels and the bandwidth of each channel is also divided into 2,250 time slots established every 60 seconds. Each time slot can represent up to 512 bits of information and VDES ASM messages may also be up to three consecutive time slots in length. This allows larger data payloads to be carried than is the case with AIS.

As with AIS, only a portion of each ASM message is available to carry the data payload as several bytes are needed for the message header and other overheads. Table 2 is derived from the International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) VDES specification (IALA, 2019) and describes the number of message bits available to carry a data payload for multi-slot VDES ASM messages. Noting that the IALA specification allows the use of FEC at a rate of 3/4, the maximum payloads available are given for when both no FEC is used and for 3/4 FEC.

Table 2. Available data bits for VDES ASM message payloads

From Table 2 it can be seen that a two-slot VDES ASM message is needed to carry a 576-bit Signature Message payload (regardless of whether no FEC or 3/4 FEC is used). The impact of VDES ASM channel loading due to carrying a two-slot Signature Message is shown in Table 3. This shows that whilst channel loading is not as severe as when AIS is used to carry Signature Messages, should AIS messages be routinely signed then the VDES ASM bandwidth will be swamped in areas of high AIS traffic. The highlighted example shows that if AIS bandwidth is currently at 50% occupancy, then signing every AIS message will use up the entire VDES ASM bandwidth.

Table 3. VDES ASM channel loading (%) due to the use of two-slot Signature Messages

Whilst VDES ASM will struggle to routinely carry digital signatures for all AIS messages, sufficient bandwidth is likely available to sign the smaller subset of ‘high risk’ messages described previously. Carrying digital signatures for these messages within VDES ASM channels is preferable to using AIS channels as this prevents increased channel loading on AIS.

7.2. Using VDES VDE to carry Signature Messages

VDE has components intended for terrestrial and satellite use. Here only the terrestrial component is considered for use in authenticating AIS messages.

As with AIS and VDES ASM, the VDE bandwidth is also divided into 2,250 time slots established every 60 seconds. There are four VDE channels available, each 25 kHz wide, thereby giving a total of 9,000 time slots every 60 seconds. (If desired the four channels may be concatenated together into two 50 kHz channels or a single 100 kHz channel, thereby reducing the number of time slots available in each 60 second period to 4500 and 2250 respectively.) VDE also has the option to use the π/4 QPSK, 8-PSK or 16-QAM modulation schemes, the net result of which is that VDE time slots will have a different data capacity depending on the channel bandwidth and modulation scheme used.

When using VDE, the VDE link layer specification specifies the use of certain pre-defined message types where each message type has differing overheads to which some modest data capacity will be lost (IALA, 2019). For simplicity, when determining the VDE channel loading we therefore consider only channel loading on the physical layer, acknowledging that the overall VDE channel loading will be slightly higher depending on the overheads of the VDE message type(s) chosen to send the Signature Messages.

Considering only the physical layer, it is seen from the IALA VDES specification (IALA, 2019) that by using a single 25 kHz channel with either the 8-PSK or 16-QAM modulation scheme, a single time slot is capable of carrying either a 972-bit or 1296-bit data payload respectively; thus a single time slot is capable of carrying a 576-bit Signature Message, plus any modest overheads. By using either of the above modulation schemes, the impact of VDE channel loading on the physical layer of the four 25 kHz channels due to carrying the Signature Messages in a single time slot is shown in Table 4. The highlighted example shows that if AIS bandwidth is at 100% occupancy, then signing every AIS message will use only 50% of the available VDE bandwidth (this translating to using 4,500 out of an available 9,000 VDE time slots every 60 seconds) and that surplus VDE bandwidth is therefore available for any modest link layer overheads.

Table 4. Channel loading (%) on the four VDE 25 kHz channels due to the use of single slot Signature Messages (necessitating using either 8-PSK or 16-QAM modulation schemes)

Note: This table shows only channel loading on the VDE physical layer.

Whilst the above table shows it is possible for VDE to routinely carry digital signatures for all AIS messages, it is noted that the burden on the available VDE bandwidth remains significant. It is the case that using a time slot capable of carrying a 972-bit or 1,296-bit message payload to carry a 576-bit Signature Message (plus message overheads) is perhaps wasteful of bandwidth. However, VDE message payload capacity is not the limiting factor, it is the number of VDE time slots available and this cannot exceed 9,000 every 60 seconds.

8. Public key infrastructure

An advantage of using PKC is that, unlike the case with symmetric cryptography, public keys needed to authenticate messages may be openly published without need for secrecy. This allows public keys to be distributed openly to users either via the internet, or by using a maritime AIS, VDES or NAVDATFootnote ² radio broadcast (subject to available bandwidth). However to use PKC safely, a user needs to be sure that a public key has not been tampered with, and that it belongs to the entity it says it belongs to and not an imposter (i.e., each public key must be associated with the correct identity, such as an MMSI number).

This may be accomplished by means of a certificate authority (CA), which is a third party universally trusted by all users. The CA carries out checks as to the ownership of public keys and once satisfied that the public key belongs to the entity it reports to belong to, will digitally sign the public key, creating an attached ‘security certificate’. Any user would see the CA's security certificate (the CA's trusted digital signature) on a public key and will know that the public key is genuine and unmolested, assuming they have trust in the CA.

An alternative to using a CA to verify public keys is using a ‘web of trust’ (WoT). This is a decentralised mechanism whereby any user (not just a CA) who has verified that a public key is genuine may sign the public key themselves and so issue their own security certificate. As a public key is verified by more and more users, the public key will have an increasing number of security certificates attached from many different users. A user may then determine their own ‘trusted introducers’, other users whose security certificates they trust. When the user then encounters a new, unfamiliar public key, the presence of one or more security certificates from a trusted introducer will verify the public key is genuine.

A WoT is useful in that it dispenses with the need for a centralised CA along with any associated administrative and financial overheads, though WoT may typically have difficulty scaling and are therefore a less preferred option.

To establish a maritime CA with the aim of authenticating AIS transmissions, different options are available, though this paper does not seek to make any recommendations. Some suggested options include that proposed by Stewart et al. (Reference Stewart, Rice and Safonov2018) whereby those organisations in countries already employed to handle the allocation of MMSIs take on an additional role as CA. Another option is to use the Maritime Identity Registry (MIR) (MCP, 2021). The MIR allows any maritime organisation to set itself up as a CA yet incorporates elements from the WoT in order to maintain a more decentralised approach.

It is suggested that a CA set up to verify AIS public keys may also be used to verify the public keys used by any future PKC system(s) developed for use with VDES, maritime 5G or other maritime communications services.