Blog: Maritime Cyber Security
Maritime AIS, or ‘Automatic Identification System’ is used for broadcast and reception of vessel position and information alerts. It has proved invaluable since its introduction in the 1990s and has undoubtedly helped prevent many marine accidents, collisions and related incidents.
Previous research by Trend Micro noted significant issues both server side and over RF. One could tamper with vessel position data as the protocol was unencrypted. There’s a great paper here.
Picture credit: Trend Micro
However, there is so much more that one can do with AIS than just tamper with position
What chaos could one cause?
First, it’s worth a quick look at the encoding method for AIS data. Here’s a sample message:
Messages may be fragmented owing to the NMEA0183 82-character maximum sentence size, hence there may be multiple sentences for one message.
!AIVDM refers to AIS from another vessel, !AIVDO refers to AIS data from one’s own vessel.
Whilst the message body encoding looks complex, it’s simply 6-bit ASCII!
Finally, there’s a message checksum as expected with NMEA0183 – CRC16
Decoding the sample message
1 – 000001
3 – 000011
a – 101001
E – 010101
O – 011111
Stringing this together:
Field 1-5: message type
Field 42-49, 4 character ROT
Field 61-88, 28 character longitude
Field 89-115, 27 character latitude
From this we can construct the vessel position:
Attacks with AIS
Owing to the lack of encryption and message validation, Trend showed several years ago that it was possible to spoof AIS over RF or server side.
Very little equipment is required as the transmission is over VHF. The antenna is less than a metre and only about 20 watts of power is required for short range transmission.
Therefore it is easy & cheap to overpower legitimate AIS signals in the local area.
However, what was not widely discussed in other AIS hacking research is the potential to use other AIS message types to interfere with shipping.
So, what could you do?
Causing chaos with AIS?
AIS supports a large number of message types. The most common are types 1, 2 & 3 for navigational information.
However, an IMO289 Area Notice has plenty of message types that can be sent over AIS.
Fields 98-104 of the area notice describe the notice description, for example:
Type 25: High waves
Type 38: Drifting mines
Type 72: Distress area: Vessel listing/capsizing
That would make for uncomfortable navigation! Yes, one could verify the area notice by consulting with shore authorities, though why would a ships officer think to consider that AIS data could be erroneous?
IMO236 Meteorological and Hydrological Data notices contain fields that describe wind speed.
Fields 318-321 cover the Beaufort Scale, so one could broadcast a force 13 gale.
EMMA Warning Reports are used for inland navigation, usually capable of being auto populated on an ECDIS if suitable interfaces exist.
Fields 222-225 describe weather type.
Type 4: storm would be of concern. Hopefully the ships master would check other sources of weather information before solely trusting AIS.
Causing more chaos with AIS?
I spoke at SEADEVCON 2018 recently, a fascinating conference for those developing apps to provide useful ‘big data’ analysis of shipping from AIS data.
For example, fishing patterns can be analysed. Illegal fishing can be tracked and prosecuted.
Ocean currents can be tracked using AIS.
Container and tanker shipments can be made more efficient, ensuring transport capacity is in the right part of the globe to optimise use.
Even vessel fuel use can be optimised by studying speed and course data using AIS.
Yet, the AIS data that these decisions are made on is unencrypted. Vessel operators could be fooled through tampered AIS data in to making bad investments and business decisions.
AIS is used to monitor fisheries and undersea pipelines
A rogue operator might send a trawling message to confuse authorities:
AIS message type 3, fields 232-239, code 30 describes a fishing vessel.
That vessel then appears to be fishing illegally, particularly if the AIS plot is modified to show typical fishing movements.
Code 33 describes a dredger. One could display dredging activity over submerged cables and pipelines.
Whilst these aren’t genuine, false alarms will damage response to genuine incidents.
It is possible to encrypt AIS data. Warship AIS already supports this facility. However, if nearby vessels don’t have the ability to decrypt the data, the safety benefit of AIS is lost.
If all AIS transceivers were to support encryption, AIS could be relied on more heavily, however the problems with key distribution and backward compatibility is significant.
Finally, even if all transceivers featured and used encryption, a rogue user could simply purchase a legitimate transceiver from which to transmit tampered data.
AIS signals have already been tampered with in order to obscure activities of vessels from countries facing sanctions. There is money at stake, so transmitting rogue data may allow those under sanction to evade detection.
Finally, we haven’t touched on the security of AIS transceiver hardware as an attack vector. Based on our experience of shipping hardware security to date, we don’t have high expectations.