Protected AIS: A Demonstration of Capability Scheme to Provide Authentication and Message Integrity

Abstract

The Automatic Identification System (AIS) provides situational awareness for vessels at sea. AIS has a number of known security vulnerabilities that can lead to several types of attacks on AIS, including the ability to create ghost vessels, false warning or meteorological messages, or bogus virtual aids-to-navigation (AtoN). A number of methods, with varying levels of complexity, have been proposed to better secure AIS and, indeed, emerging AIS protocols will implement some of these mechanisms. Nevertheless, little has been done to secure the current standards, which will remain in use for some time. This paper presents Protected AIS (pAIS), a demonstration of capability implementation using public-key cryptography methods to address several AIS security vulnerabilities, maintain backward compatibility, and be able to interoperate with non-pAIS devices.

1. Introduction

This paper discusses the Automatic Identification System (AIS), some of its security vulnerabilities, and a proof-of-concept software project called Protected AIS (pAIS) that addresses some of the identified vulnerabilities. Sections II and III of this paper provide a high-level overview of AIS and its security exposures, respectively. Section IV describes public-key cryptography, the basis for the protections provided by pAIS. Sections V and VI, respectively, provide an overview and detailed example of the operation of pAIS. Section VII offers some of the limitations of pAIS as a solution and suggests further development, followed by Summary and Conclusions in Section VIII.

AIS is a tracking system that allows vessels at sea to be aware of each other's presence (within 10–20 nautical miles or so), authorities to identify and monitor vessels in their area of responsibility, and ships and shore stations to exchange navigation, meteorological, safety, and other items of information. Following the oil spill caused when the oil tanker Exxon Valdez ran aground in Alaska in 1989, AIS was designed as a maritime situational awareness system in the 1990s and adopted internationally in the 2002 International Convention for the Safety of Life at Sea (SOLAS).

Chapter V of the SOLAS agreement, titled "Safety of Navigation," mandates that ships of a certain size and/or function carry AIS transceivers as an additional safety measure; this same mandate is found in 33 CFR 164.46 in the United States Code of Federal Regulations. Vessels required to operate AIS are referred to as Class A and include ships of 300 or more gross tons traveling internationally, commercial power vessels of 65 or more feet (19.8 or more meters) in length, and power vessels certified to carry more than 150 passengers; warships are exempted from these requirements although all modern warships have AIS capability. Class B refers to those vessels carrying AIS at the option of the captain or that do not have a requirement to carry Class A equipment. AIS devices generally transmit position information messages every 2–180 seconds, depending upon the ship's class, speed, and rate-of-turn.

2. AIS Overview

AIS is used today primarily for situational awareness and collision avoidance, vessel traffic management, and coastal surveillance. The system is designed so that a ship fitted with appropriate receivers can view the local traffic and quickly determine another ship's name, its International Maritime Organization (IMO) registration number, size (e.g., length, beam, and draft), position (latitude and longitude), course, bearing, destination, status (e.g., anchored, moored, underway under power or sail, etc.), and other information.

The National Marine Electronics Association (NMEA) provides a family of standards describing electrical and serial communications for the interconnection of marine electronics. NMEA 0183 defines character-based AIS messages and low-speed communication over the Controller Area Network (CAN) serial bus. NMEA 2000 describes a higher speed, binary-based AIS message scheme, also running over the CAN bus. The emerging OneNet standard will describe a protocol of high-speed, binary messages over the Internet Protocol (IP) and Ethernet; OneNet will also introduce security mechanisms for transmissions.

Ships and boats are not the only active components in the AIS network. Mobile stations within the AIS network also include AIS search-and-rescue transponders (AIS-SART), man-overboard (MOB) AIS transmitters, Emergency Position Indicating Radio Beacon (EPIRB) AIS devices, AIS-equipped satellites, and AIS-equipped search-and-rescue aircraft. Fixed AIS stations include AIS base stations, repeaters, and specially equipped aids to navigation (AtoNs). Global Navigation Satellite Systems (GNSS) are not a direct component of AIS, but they provide essential geographic positioning information to all of the mobile components.

3. Cybersecurity Vulnerabilities in AIS

AIS was designed during an era when security was not the imperative that it is today; indeed, it was designed during the very earliest days of the commercial Internet. Many researchers have discussed security vulnerabilities in AIS, including Balduzzi et al., Goudossis and Katsikas, Kessler, Craiger, and Haass, and Trend Micro. This section will review some of the AIS security issues, particularly those addressed by the pAIS software.

As stated above, AIS broadcasts messages on public maritime VHF radio frequencies. Not only can any listener hear all of the traffic, but anyone can transmit messages. In years past, relatively expensive AIS hardware was required in order to transmit; today, there are many ways to build inexpensive systems to both receive and transmit AIS messages.

The use of a shared broadcast frequency for AIS is very efficient in terms of communications resources but foreshadows another potential AIS security vulnerability, namely, an attacker usurping the bandwidth in order to block other devices from transmitting, negatively impacting the shared time slot synchronization process, or changing slot reservation/assignment information. Any of these attacks can effectively knock other AIS stations off of the air. Balduzzi et al. originally described many types of attack on AIS due to some specific AIS protocol weaknesses, including: lack of validity checks, as AIS messages include no geographic validation information, meaning that it is possible for a bad actor to send an AIS message from any location while purporting to be in another location; lack of timing checks, as AIS messages contain no timestamp verification information, meaning that a cyberattacker can replay valid AIS information at a later time of their choosing; lack of authentication, as the AIS protocol provides no mechanism to authenticate the sender, thus anyone with the ability to craft or otherwise transmit an AIS packet can impersonate any other AIS device; and lack of integrity checks, as AIS messages are transmitted in an unencrypted and unsigned form, making it simple for an interloper to intercept and/or modify transmissions.

From these vulnerabilities, a bad actor can spoof a non-existent vessel or AtoN, replay past AIS events, trigger false SOS or collision alerts, send bogus weather or other meteorological information, launch a denial-of-service attack on the AIS broadcast system, or modify vessel information being broadcast on the air. Practical examples include ghost vessels off the coast of Daytona Beach, Florida, and spoofed virtual AtoNs at Ponce De Leon Inlet directing boaters toward the shallow side of the inlet — with no mechanism to authenticate the sender of this information even though the U.S. Coast Guard has sole authority in the U.S. for transmitting virtual AtoN information.

4. Public-Key Cryptography

The primary security element of pAIS — and, indeed, all methods that provide security to AIS transmissions — is the use of cryptography. Protected AIS employs public-key cryptography (PKC) methods. The PKC concept was first described in 1976; the first implementation, in 1977, was the Rivest, Shamir, and Adleman (RSA) scheme, which remains the most common PKC algorithm in use. Unlike secret-key cryptography that uses a shared secret key for both encryption and decryption, PKC methods use two keys with the following properties: the two keys are mathematically related and derived as a pair; knowledge of one key does not yield knowledge of the other key; and either key can be used to encrypt data while the other key is then used to decrypt the data (for this reason, PKC is also referred to as asymmetric cryptography).

The PKC model shows two communicating parties, Alice and Bob. Each has a private (PVT) key file that stores their private key locally (i.e., on their own device). They both also have access to a large number of public (PUB) keys through a shared database which could be on the Internet or corporate network, or could just be shared amongst all of the users. If Alice wishes to send a private message to Bob, she encrypts it with Bob's public key; only he possesses the private key so only he can decrypt the message. If Alice wants to authenticate a message that she sends — i.e., prove that she is the sender — she will encrypt the message with her own private key; this message can be read by anyone who can access her public key and successful decryption proves that she was the sender since only she possesses her private key.

It is the ability to authenticate the sender of AIS messages that makes PKC applicable to pAIS.

5. Protected AIS Operational Overview

A number of solutions to the security weaknesses of AIS have been proposed. Encrypted AIS (EAIS) and other cryptography-based variants have seen use for special-purpose or limited fleets. Even when using a shared key, EAIS solves the problems described above by carefully introducing vessels into the "trusted" group. It has limited utility, however, for other vessels and the situational awareness of "public" maritime traffic. Goudossis and Katsikas provide an overview and critique of several other solutions to AIS security; these solutions are encryption-based and address the issues mentioned above but require significant changes to the AIS protocol and/or add several layers of complexity to the communication network.

The pAIS project is a proof-of-concept effort to address security issues of AIS with a solution that is computationally simple, does not add a noticeable delay time in transmission, is backward compatible with existing protocols, could be implemented by a simple software upgrade, and would be able to communicate with the embedded base of equipment. While created independently, pAIS is essentially a realization of Mode 2 (authentication and integrity) security described by Goudossis and Katsikas in their proposal for a Secure AIS protocol. Protected AIS is a mode of operation designed to address three specific security vulnerabilities: lack of message integrity, lack of timing integrity, and lack of sender authentication.

These vulnerabilities are addressed as follows: first, to provide message integrity, pAIS calculates an 8-bit checksum over the entire AIS message rather than merely the individual sentence fragments. The message is a binary string composed of 6-bit bytes; the pAIS checksum is computed as a byte-by-byte exclusive OR (XOR) of the entire binary string. Second, to provide timing integrity, a timestamp string is appended (e.g., 20191014103714). Third, to provide sender authentication, the checksum and timestamp are combined to create a 16-character string, which is encrypted with the private key associated with the sending AIS device's MMSI. This creates the so-called protect string.

6. Protected AIS Software Overview

Perl's Crypt::OpenSSL::RSA module is employed for generation of PKC public-private key pairs, encryption, and decryption. The pAIS software employs 256-bit RSA keys, generating a 258-bit protect string (which adds 25–350% overhead to standard AIS messages). This particular encryption module was selected because it offers the options of encrypting or decrypting with either the public or private key. While encrypting a message with the private key is logically similar to the message signature function in most encryption libraries, experiments with message signatures found that the shortest usable RSA key was 512 bits in length. This large key and the signature function produced a 540-bit protect string which was deemed too much overhead even for the prototype system.

The prototype pAIS software is written in Perl and focuses on NMEA 0183 formatted messages. The software comprises a suite of programs that can be used to generate standard and protected AIS messages, as well as decode them. The following example shows how standard and protected AIS messages compare, using a Type 1 (Position Report Class A) message with the following parameters: MMSI = 369121053, longitude = −080.92°, speed = 17.2 knots, course over ground = 260°, and heading = 272°. A standard NMEA 0183 message with this information would be transmitted over the air, and the figures in the original paper show the AIS sentence, the binary string representing the message payload, and the decoded message.

In pAIS protected mode, the 258-bit protect string is appended to the standard data, generating a two-sentence AIS message (the highlighted bits represent the protect string). When the message is read by a pAIS device using protect mode, the information is interpreted as shown in Figure 10 of the original paper.

The pAIS message will also be decoded properly by well-behaving AIS devices and software unable to operate in protect mode because standard devices should ignore the unexpected data at the end of the transmission. Backward compatibility is thus realized in this scheme: an AIS transmitter operating in protect mode appends the protect string — encrypted with its private key — to its standard outgoing AIS transmission, a receiving station operating in protect mode decrypts the protect string using the key associated with the sending station's MMSI, while a non-protect-capable device simply ignores it.

7. Limitations and Areas for Further Development

The pAIS project was intended only as a demonstration of capability and, as such, is a prototype with operational limitations. The method described here does not use the strongest possible algorithms for some simple reasons; the intent of the prototype was to demonstrate simplicity, backward compatibility, and ease of integration into existing software. Some of pAIS's limitations include: the use of byte-wise XOR is not the strongest checksum available, but it adds simplicity to the system by re-using code, since the NMEA checksum algorithm is already part of AIS software, and this checksum is sufficient for our needs — while an attacker might be able to brute-force a bogus message with the same checksum as a valid message, this is unlikely to be used in a real-time attack, and in any case a number of strong eight-bit cyclic redundancy check (CRC-8) algorithms could be employed without adding additional size to the protect string; the current timestamp uses a 14-character, human-readable string containing month, day, year, hour, minute, and second, whereas the same information could be obtained using 10-byte Unix epoch time, which would shorten the amount of data to encrypt by four bytes, although upon testing the length of the protect string remained at 258 bytes; and a given timestamp might be duplicated if an AIS device transmits more than one message within a second or if two different AIS devices transmit a message within the same second, though this duplication is not a problem because the timestamp is only intended to provide timing integrity on a per-message basis and uniqueness is not required since it is not tied to message identification.

Protected AIS does not solve all of AIS's security problems. In particular, it does not counter an insider threat, when an authorized device already in the system is used to send bogus messages. Indeed, little can be done to protect against a bad actor who manually enters or otherwise configures bogus or incorrect information into an authenticated AIS device. The pAIS scheme also provides no geographic verification. Every AIS device and AIS message has an MMSI associated with it so that public and private keys could be tied to the MMSI, but the method described here does not specify how the public keys are distributed; for the pAIS prototype, the Pretty Good Privacy (PGP) model of shared keychains and a web of trust is used although that solution is not scalable to a world-wide network of tens of thousands of AIS devices. Goudossis and Katsikas describe an alternative mechanism based upon the creation of a global, X.509-like Maritime Public Key Infrastructure (PKI), where the registration and Certification Authorities would be managed and operated under the auspices of the International Maritime Organization (IMO) and national maritime authorities.

Finally, pAIS was designed to work with NMEA 0183 formatted messages. Conceptually, there is no reason why it could not be extended to protect NMEA 2000 binary messages.

8. Summary and Conclusion

This paper has described pAIS, proof-of-concept software that adds bit integrity, timestamp integrity, and sender authentication to NMEA 0183 AIS messages. The scheme is designed to be simple, backward compatible, and able to co-exist with non-pAIS implementations. This prototype software was developed for research applications to demonstrate that such a scheme was viable and feasible.

AIS is increasing in importance as new applications get attached to the system; autonomous ocean-going and near-coastal vessels are merely the latest in a long line of mission-critical uses for AIS. Every new use of AIS adds to the reasons that the industry has to find ways to better secure the system.

References

Full reference list (20 sources) available in the original PDF, including: Balduzzi et al. (2014) on AIS security evaluation; Goudossis & Katsikas (2019) towards a secure AIS; Kessler et al. (2018) maritime cybersecurity taxonomy framework; Hall et al. (2015) on IEEE 1609-influenced AIS; IALA, IMO, ITU and NMEA standards; and the U.S. Coast Guard Encrypted AIS (EAIS) interface design description.