The Automatic Identification System (AIS) is so beyond utterly botched

that it is practically made for use by Spies, etc...



Abstract

The Maritime Automatic Identification System (AIS) Protocol was "thrown together" in the very late 1990s with existing technologies to help large vessels not run into each other -- and for port authorities to manage these vessels.

AIS was only meant to provide a basic informational system for large vessels.

In spite of AIS's botched design, the protocol worked so well that its use may become mandatory by the 2020s.

The original Maritime AIS protocol was intended for use by Class A maritime vessels (Oil Tankers, Passenger Liners, LPG Carriers, Bulk Ore Carriers, ...) operating in the open ocean. Knowing "where everyone is, and is going" via AIS was so successful that a Class B Vessel Protocol Subset was developed.


Even overblown rowboats can have AIS transponders for "safety of life" use and for situational awareness. 

The AIS Protocol was deeply flawed from the beginning as there is no support for TRAFFIC VERSION NUMBERS. Nor does AIS have any support for SOFTWARE VERSION NUMBERS or PROTOCOL VERSION NUMBERS. Version Numbers are just the beginning : a 200 page book should be written pointing out all of AIS's flaws, as it makes for a good read.


There is another highly successful transmission protocol that has this same "Version Numbers" problem :

The Radio Data System (RDS). No Audofile since the 2000s would want an FM Stereo receiver that can't do RDS. The extra IF stage filtering involved to make RDS work can help in the decoding of the normal stereo signal. The RDS 3.0 Standard, now "officially ready for use" fixes some of the version number problems -- but not all of them.


In spite of AIS's deep flaws, the protocol seems only to be updated every 6 months -- so the IMO has not been entirely negligent as a custodian of the protocol. However, the deep flaws in the protocol are probably not going to be fixed any time soon -- by the IMO or any other entity.

Yet, the general public worldwide pays little attention to Maritime AIS and its usefulness. Port Authorities and national security agencies have only begun to monitor AIS traffic for general malfeasance, but even then there are huge gaps.  

Since the Snowden US NSA data releases, it seems that both the US NSA and GCHQ don't care at all about AIS surveillance. In the UK-USA system, any and all boating activity is reserved for the ruling elite (and the shipping and transport system that is mostly owned by them).

The US and UK security intelligence agencies view AIS monitoring as "an activity mostly to be left to some regional monitoring agencies" (and a few limited national shipping monitoring agencies). In terms of tracking down every AIS packet ever transmitted over the entire surface of nation (and its EEZ) over decades at a time -- there is only an ocean of beyond total negligence.


In a nutshell :

The MARITIME AIS STANDING ORDER : The ruling elite own yachts, and wish only for their owned shipping entities to be tracked!

All Signals Intelligence Collection Agencies (in the UK-USA system) must obey this AIS standing order unthinkingly (and without question). Their only purpose (or reason for existence) is to be beyond totally expendable sacrificial lambs. The Signals Intel Agency salary rate tables tells one everything one needs to know.

[Note that for the secrets Snowden held, he was paid the equivalent of below slave wages. Snowden should have been paid "real wages" -- this means something like 967000 SDR/s per year. In the NZ part of the system this means 567000 SDRs/year; for Australia : 677000 SDRs/year. The value of money (and goods and services) in an economy set these rates, and "anyone paid below these rates" has the unlimited right to sell the secrets they have access to for profit.]

 

In order to understand why Maritime AIS is "no more and no less" than an "open and free free communications system" for the transmission of (hopefully double) encrypted datagrams from spies to their headquarters, one must know and understand AIS's profound design (and regulatory) flaws.  

AIS's Deep Flaws

There literally are hundreds of large and small design and implementation flaws in Maritime AIS.

This brief list here "is merely skimming the surface" :

  1. There is no existing IMO "Standard AIS State Machine" written in ADA 95 or Java 2015 (in code that is 90% devoid of any object orientation) -- to verify transceiver or receiver operation. The lack of a "standardized test bed" can lead to Safety of Life Software being written (and deployed) with many bugs. The IMO should forbid any language but ADA 95 (or selectively ADA 2015, or a subset of Java 2015) from being used for Class A Vessel AIS Transceivers.
  2. All AIS speed indications probably should have been forced into announcing speeds in {Meters/Second} only, instead both Kilometers and Knots are used incoherently.
  3. Turning Rates were made to be "Degrees Exclusive" -- but this is a mistake for the docking of Class A vessels with dangerous cargos. For the safety of Tugboat Docking (or Shunting) "Gradients" should have been made available, when a vessel longer than 50m is being moved.
  4. Shunting : there is no way for Class A Vessels (nor Tugboats) to notify that a shunting operation is going on. There is an IMO rule (or at least standing order) to avoid travel within 300m of a Class A Vessel shunting operation in a Port or at Sea. 
  5. There is no "32 bit Floating Point" indication of {GPS, GLONASS, WAAS} (GNSS) position. Nor is available as an option to indicate one's posision in value limited 32 floating point number.  Modified AIS specific 32 Floats would be best here -- with about 3 bits of "x10 Exponent" field replaced by higher precision bits of the Mantissa.
  6. No version numbers exist in the protocol at all : There should be support for at least 8192 in the major version, and 512 in the minor version (but not for traffic type versioning). Each protocol and embedded software version (and protocol version) must be indicated.
  7. Beyond terrible Error Detection and Error Correction : The NMEA CRC-16 checksum was inherited for the verification of packets, when MD2 or CRC 32 MPEG should have been used within each protocol packet. So all received AIS packets still have to be submitted to deeper packet inspection and content sanity checking than needed. This slows down processing, and is a minor [but not insignificant] safety of life issue.
  8. No AIS "modular replaceable (and upgradeable) security verification system" exists for Class A or Class B vessels. The AIS Protocol simply does not support vessel verification at a national (regional) or global level. Something like a "Television Selective Access Module", like those used in Japan (and most Set Top Boxes) would work here. Namely the vessel user or owner would have to obtain the security module from the local or national maritime authority, test and verify its use -- and allow for its use near port authorities.
  9. Ship, Fleet or Owner Contact Data : There is no UTF8 (& Unicode 3 encoded) data transmittable about vessel ownership. About 26 different fields would be needed for each, with headers and footers for each. About 6 bits would be needed for this, with 4 bits for the contact subtype.
  10. All AIS equipment uses UTC time for synchronizing transmissions, with no "Absolute Deep Time" (like perhaps a multimodal POSIX / TAI / UT1 Timestamp in 64 bit signed int form) system as fallback. This leads to bugs that affect AIS slot allocations and is an actual safety issue. 


AIS Standards

If one has any doubt about the problems and flaws in AIS. Spend some time (and to go to the source documents) of the current standards in force.

A nation's national maritime authority probably has collected this information in a manner similar to this and made it available to the general public in the usual local languages.

This text is from : http://www.navcen.uscg.gov/?pageName=typesAIS

Class A | IEC 61993-2

Shipborne mobile equipment intended to meet the performance standards and carriage requirements adopted by IMO. [...]

Class A stations are also capable of text messaging safety related information (message 6/8) and AIS Application Specific Messages (message 6,8,25,26), such as meteorological and hydrological data, electronic Broadcast Notice to Mariners, and other marine safety information (see IMO Safety of Navigation Circular 289, GUIDANCE ON THE USE OF AIS APPLICATION-SPECIFIC MESSAGES (ASM) or the IALA Application Specific Message Collection).

Class B | IEC 62287-1 and 62287-2

Shipborne mobile equipment which is interoperable with all other AIS stations, but, does not meet all the performance standards adopted by IMO. Similar to Class A stations, they report every three minutes or less when at anchor or moored, but, their position (message 6/8) is reported less often and at a lower power. 

Likewise, they report the vessel’s static data (message 18/24) every 6 minutes, but, not any voyage related information. They can receive safety related text and application specific messages, but, cannot transmit them. There are two types of Class B AIS, those using carrier sense Time-Division Multiple Access (CS-TDMA) technology and those like the Class A using Self-Organizing Time-Division Multiple Access Technology (SO-TDMA). 

Search and Rescue Aircraft (IEC standards yet to be developed)

AIS Aid to Navigation (ATON) | IEC 62320-2

In the United States ATON stations are solely operated by the US Coast Guard. ATONs report (message 4) every ten seconds and are identified by a 0036xxxxx MMSI. Their private sale or use by any other private entity is prohibited (47 CFR §§ 2.803, 80.371). Stations that also act as AIS ATONs or transmit ASMs are denoted in the Coast Guard Light List.

AIS Base Station | IEC 62320-1
 
Shore-based station providing identity, time synchronization, text messages, which can also act as an AIS ATON station or transmit Application Specific Messages (message 6/8, see the IALA Application Specific Message Collection) for meteorological or hydrological information, marine safety information, etc.

Data Broadcast From Each AIS Station Type

Note: U.S. AIS carriage requirements can only be met with Federal Communications Commission (FCC) type-certified and USCG type-approved equipment; use of non-certified radio equipment is prohibited (see 47 CFR § 80.203(a). For a listing of FCC type-certified AIS equipment search the FCC Equipment Authorization Search Page [..]


How Spies Can Use AIS with full Encryption, the legal and technical issues

In order for anyone to rely secure messages (of security intelligence value) to their headquarters in a radio band (or bands) there must be some legal justification to do so. There must also be a technical justification to do so as well.



BF AIS : Lack of oversight and interoperability have not been fully considered

Note that in North America the "Blue Force AIS System" (BF AIS) is already using Encrypted AIS.

BF AIS is not well known to the general public in North America. It is unclear to what extent it is BF AIS can be abused or misused by the entities that are already using it. The US FCC (and the Canadian CRTC) have not fully authorized BF AIS's use, nor is there any civilian oversight of it.

(via a blog entry, modified for readability) Very recently while reading a US NTSB boating accident investigation report [...] a mention of an encrypted AIS method that was being used by law enforcement vessels came up. After a bit of research on encrypted AIS I found the term "Blue Force AIS" was often used in conjunction with this method.

Blue Force AIS (or encrypted AIS) refers to a method of vessel automatic identification system transmission in which the data about the vessel, such as its name, course, speed, and so on, is sent with encryption so that it cannot be received by standard AIS receivers. This permits vessels (particularly military or law enforcement vessels) which employ the encrypted transmission and reception equipment to track each other, but at the same time appear invisible to other vessels AIS receivers or transponders.

In addition to data encryption, it appears that the Blue Force AIS transponders can also use different frequencies, specifically a band of radio frequencies known as MURS (Multi Use Radio Service). Transmitting vessel data on a different frequency than the standard AIS ones -- insures that it cannot be received by standard AIS equipment.

Here are excerpts from two vendor's literature describing the encrypted AIS or Blue Force AIS capabilities of their product : -

The Blue Force Tracker uses a unique combination of AIS VHF radio channels and the MURS group of VHF frequencies which are reserved worldwide for two-way communications.

MURS allows for encryption of terrestrial and marine movements.

The Blue Force Tracker employs the MURS frequencies for encrypted transmissions while maintaining the option to monitor public AIS marine traffic, making it a state-of-the-art tool for applications such as law enforcement, border protection and port security. Officers and agents can maintain surveillance over AIS traffic while only disclosing their own locations to a specified group.

Furthermore, unlike the AIS system, MURS enables encrypted short-text messaging for secure boat-to-boat and boat-to-base communication.

And also another vendor's literature says : -

Blue Forces is a common term for friendly forces.

The AIS 200 Blue Force is an AIS class A mobile station that offers secure communication in addition to standard AIS functionality.

This means that all users of the Blue Force units can monitor each other and be monitored by AIS Base Stations prepared with Blue Force tracking capabilities which are covering the area. In secure mode this AIS mobile station will still be able to see all AIS Mobile Stations within the coverage area, without revealing its position to anyone but friendly forces. NATO STANAG 4668 is used as guidance for implementation of this functionality.

The term Multi Use Radio Service (MURS) appears to refer to a group of five VHF channels in the (151 to 155) MHz range which are available to residents of the USA for use without a license, as long as the transmitter power is 2 Watts or less, and is subject to some use restrictions.

The US NTSC report states this : -

Coast Guard AIS policy guidance, issued in August 2008 by the Admiral in charge of the Eleventh Coast Guard District, stated the following with respect to the three AIS modes (but not MURS AIS Modes) :

-- Standard Mode : The AIS unit will perform similarly to standard commercial shipboard AIS units, broadcasting the vessel's position and information to all other AIS receivers within VHF range. This mode is recommended for increased navigation safety and overt operations.

-- Disabled Mode : The AIS unit will not transmit data at all. This mode is recommended for increased operations security and covert operations.

-- Restricted Mode : The AIS unit will transmit encrypted AIS data that will be available only for friendly or so called "Blue Force" units with similar encryption capabilities. This mode is recommended as the default setting for "Blue Force Boats" with AIS units.


Note the next comment on the same blog page :

In Canada, their Coast Guard is not operated as a military service. It is run more like a regular civil-service operation. In the United States, the USCG seems, now more than ever, to have become an adjunct of the military services. Their operations have become more strictly paramilitary, a distinct change from their previous and historical life saving, rescue, and safety mission.

Above note that encrypted AIS is done in accordance with NATO STANAG 4668. A little research on NATO STANAG 4668 shows it is a warship automatic identification system. Apparently when Homeland Security talks about the war on terrorism they are not kidding. Your local USCG small boat now operates like a warship in hostile combat environment in regard to encrypted AIS.

I have a very good friend who was a CWO4 in the US Coast Guard Reserve and only recently retired from reserve duty. He used to say that often they'd conduct patrols which he described as "showing the flag" exercises. This means just having a presence on the water and letting people see the USCG vessel underway and on duty.

It seems a bit incongruous that the USCG would recommend its vessels use only encrypted AIS transmissions while they were conducting routine, overt, and normal patrols. What better way to "show the flag" than electronically via an AIS transmission?


Mainly, all of the above points are interesting but do not tell the full story. Indifferent (to mildly corrupt, to excessively militarized) mismanagement of the AIS frequencies is a global problem. 



AIS's "Channel Reassignment Command" Design Flaw



There is an AIS "Channel Reassignment Command" (for use by Port Authorities, Coast Guards or Home Water Navies only, on a temporary basis only) that forces AIS transponders to move to channels other than the default allocated Channels (87 and 88).

This AIS feature clearly needs to be revised as soon as possible by the IMO to only support a spherical granularity of perhaps 350 Nautical Miles, and a duration of 6 hours or less.

Minimum   : 100 NM
Maximum  : 500 NM
Increments Permissible : 50 NM
Canal Mode : 20 NM (but it would have to be added as a new feature)

The current time duration maximum is FIVE WEEKS, with a (Permissible) Surface Area of 2000 Nautical Miles. Both of these settings are too extreme for any reasonable hope of maritime safety. 

This text is derived from an archived US Coast Guard snafu relating to the accidental use (or misuse) of this botched AIS feature :

One of the lesser known and potent features of AIS is its ability to operate on multiple channels within the VHF-FM marine band.

This frequency agility ensures AIS can be used even when the default channels are otherwise unavailable or compromised.

In such conditions, competent authorities, such as the Coast Guard, can use an AIS base station to tele-command shipborne AIS devices to switch to other more appropriate channels when within defined regions of 200 to 2000 square nautical miles.

This dynamic reallocation can be done automatically (and without user intervention) through receipt of the AIS channel management message (AIS message 22) or manually entered via the AIS Minimal Keyboard Display (MKD) or similar input device.

Once commanded or manually entered, the channel management information will stay in memory for 5 weeks or until an affected vessel moves more than 500 nautical miles from the defined region.

AIS channel management commands can only be manually overridden or erased by the user via the unit’s channel (regional frequencies) management function or automatically overridden via another channel management message for the same defined region.

Reinitializing or resetting your AIS or transmission channels will not necessarily reprogram your unit back to the default channels.



AIS Has Text Messaging, and Secure Messages are being sent without further inspection


However, the previous problems pointed out miss entirely the fact that AIS can already transmit text messages, and has no real distributed mechanism to prevent their misuse.

There is not Port Authority or Base Station message to tell AIS transponders to slow down their texting, only a message to tell all users to speed up or slow down their reporting rate. AIS "Texting" (broadcast or point to point) must be separated from general message reporting, because its impact on "safety of life" issues is both direct and indirect. 

AIS texting was devised to reduce the need for continuous voice radiotelephone transmissions.

The goal was to free up the VHF Maritime Band at the local level from excess voice traffic. However, this messaging is 6 bit ASCII only -- with no UTF8 support and not Unicode Support. 

Usage During Navigation : The AIS safety related text message is a mere 156 characters long, and maybe not used as much as it should be.

However, there are three AIS traffic types that literally permit a secret messaging net to be formed and to carry out communications with little if any oversight by essentially anyone.

The only key point here is that the transmitter and receiver must have MMSI numbers of "Paper Boats" that are not in active use.

There literally are thousands of boats with AIS B Type transponders that are not in continuous use in any given port region -- or inland river or lakes system. So real and paper boats can be used, if one has adequate intelligence about their users.  



AIS ADDRESSED BINARY MESSAGE (MESSAGE 6)

The addressed binary message should be variable in length, based on the amount of binary data.

The length should vary between 1 and 5 slots. 

Since the data content of this binary message is defined by the application, Message 6 is an Application Specific Message (click on this link for a registry of recognized Application Specific Messages).

 

Parameter

Number of bits

Description

Message ID

6

Identifier for Message 6; always 6

Repeat indicator

2

Used by the repeater to indicate how many times a message has been repeated. 0-3; default = 0; 3 = do not repeat any more

Source ID

30

MMSI number of source station

Sequence number

2

0-3

Destination ID

30

MMSI number of destination station

Retransmit flag

1

Retransmit flag should be set upon retransmission: 0 = no retransmission = default; 1 = retransmitted

Spare

1

Not used. Should be zero. Reserved for future use

Binary data

Maximum

936

Application identifier

16 bits

Bit

Description

15-6

Designated area code (DAC). This code is based on the maritime identification digits (MID). Exceptions are 0 (test) and 1 (international). Although the length is 10 bits, the DAC codes equal to or above 1 000 are reserved for future use

5-0

Function identifier (FI). The meaning should be determined by the authority which is responsible for the area given in the designated area code

Application data

Maximum 920 bits

Application specific data

Maximum number of bits

Maximum

1 008

Occupies up to 3 slots, or up to 5 slots when able to use FATDMA reservations. For Class B “SO” mobile AIS stations the length of the message should not exceed 3 slots

For Class B “CS” mobile AIS stations should not transmit;

 

Additional bit stuffing will be required for these message types.  The table below gives the number of binary data bytes (including application ID and application data), so that the whole message fits into a given number of slots.

It is recommended that any application minimizes the use of slots by limiting the number of binary data bytes to the numbers given, if possible:

 

Number of slots

Maximum binary data bytes

1

8

2

36

3

64

4

92

5

117

 





AIS BINARY BROADCAST MESSAGE (MESSAGE 8)

This message will be variable in length, based on the amount of binary data.

The length should vary between 1 and 5 slots. 

Since the data content of this binary message is defined by the application, Message 8 is an Application Specific Message (click on this link for a registry of recognized Application Specific Messages).


 

Parameter

Number of bits

Description

Message ID

6

Identifier for Message 8; always 8

Repeat indicator

2

Used by the repeater to indicate how many times a message has been repeated. 0-3; default = 0; 3 = do not repeat any more

Source ID

30

MMSI number of source station

Spare

2

Not used. Should be set to zero. Reserved for future use

Binary data

Maximum 968

Application identifier

16 bits

Bit

Description

15-6

Designated area code (DAC). This code is based on the maritime identification digits (MID). Exceptions are 0 (test) and 1 (international). Although the length is 10 bits, the DAC codes equal to or above 1 000 are reserved for future use

5-0

Function identifier (FI). The meaning should be determined by the authority which is responsible for the area given in the designated area code

Application data

Maximum 952 bits

Application specific data

Maximum number of bits

Maximum 1 008

Occupies up to 3 slots, or up to 5 slots when able to use FATDMA reservations. 
For Class B SO mobile AIS stations the length of the message should not exceed 3 slots

For Class B CS mobile AIS stations should not transmit

 

The table below gives the number of binary data bytes (including application ID and application data), so that the whole message fits into a given number of slots.

It is recommended that any application minimizes the use of slots by limiting the number of binary data bytes to the numbers given, if possible:

 

Number of slots

Maximum binary data bytes

1

12

2

40

3

68

4

96

5

121


 



AIS SINGLE SLOT BINARY MESSAGE (MESSAGE 25)


This message is primarily intended short infrequent data transmissions.

The single slot binary message can contain up to 128 data-bits depending on the coding method used for the contents, and the destination indication of broadcast or addressed. The length should not exceed one slot. 

This message should not be acknowledged by either Message 7 or 13. 

Since the data content of this binary message is defined by the application, Message 25 is an Application Specific Message (click on this link for a registry of recognized Application Specific Messages).

 

Parameter

Number of bits

Description

Message ID

6

Identifier for Message 25; always 25

Repeat indicator

2

Used by the repeater to indicate how many times a message has been repeated. default = 0; 3 = do not repeat any more

Source ID

30

MMSI number of source station

Destination indicator

1

0 = Broadcast (no Destination ID field used)
1 = Addressed (Destination ID uses 30 data bits for MMSI)

Binary data flag

1

0 = unstructured binary data (no Application Identifier bits used)
1 = binary data coded as defined by using the
      16-bit Application identifier

Destination ID

0/30

Destination ID (if used)

If Destination indicator = 0 (Broadcast); no data bits are needed for the Destination ID.
If Destination indicator = 1; 30
 bits are used for Destination ID and spare bits for byte alignment.

Spare

0/2

Spare (if Destination ID used)

Binary data

Broadcast Maximum 128
Addressed Maximum 96

Application identifier
(if used)

16 bits

Bit

Description

15-6

Designated area code (DAC). This code is based on the maritime identification digits (MID). Exceptions are 0 (test) and 1 (international). Although the  length is 10 bits, the DAC codes equal to or above 1 000 are reserved for future use

5-0

Function identifier (FI). The meaning should be determined by the authority which is responsible for the area given in the designated area code

Application binary data

Broadcast Maximum 112 bits
Addressed Maximum 80 bits

Application specific data

Maximum number of bits

Maximum 168

Occupies up to 1 slot subject to the length of sub-field message content

Class B CS mobile AIS stations should not transmit

 

Table 81 gives the maximum number of binary data-bits for settings of destination indicator and coding method flags, such that, the message does not exceed one slot.

 

Destination indicator

Coding method

Binary data (maximum bits)

0

0

128

0

1

112

1

0

96

1

1

80

 



On top of this, Traffic Types [32 ... 64] are essentially totally unused.

How Might A Secret Communications Net Operate?

An openly obtainable [aka non-secret design] AIS transponder (with a USB interface, and terminal monitoring software) is needed that is capable of at least 5 Watts but for the transmitting party, but having the ability to output 25 Watts might be preferred.

Having internal transponder expansion ports would be a good idea, in that it would permit the transponder to operate a secondary high bandwidth transmitter for the transmission of bulk data at about the same power level.

The reviving part unit should use that same slot for additional signal processing, so as to allow the unit to operate close to the theoretical limits of the AIS transmission system. 

The transponder unit (for the transmitting or receiving parties) does not need to have a user interface, just the right plug inputs to onward devices with user interfaces.

Openly obtainable AIS transponders designed for telecommunications experimentation are as of the 2015s somewhat hard to come by, and not really inexpensive either.

This lack of repurposeable kit has actually slowed down the uptake of AIS use for small boats -- that need 150 SDR AIS transponders not 450 SDR ones.



Receiving Party


Transmitting Party

The transmitting party should have a computer that interfaces with an AIS transponder that is not connected to the Internet. Raspberry Pi and similar systems (like Ardriono) should have flash and USB disk drives, as well as monitors and keyboards. This system should probably be disguised as an offline AIS monitoring system. 







References

Checksums

Safe Computer Coding Languages

AIS

Transmission Kit

Videos (Generally YouTube)

  1. 1
  2. 2
  3. 3




Initial Ideas
Document Created
Last Revised
Last Revision
Version
Revision State

15 May 2013
25 October 2015
23 April 2016
Readability

0.08b
Revisable