Secure AIS with Identity-Based Authentication and Encryption

Abstract

The Automatic Identification System (AIS) offers automatic traffic control and collision avoidance services to the maritime transportation sector worldwide. Because AIS lacks security mechanisms, it is vulnerable to misuse and exploitation by unlawful adversaries (e.g. sea-pirates, terrorists, smugglers). To address the security issues of the AIS, in an earlier paper [1], we proposed the deployment of a Maritime Certificate-less Identity-Based (mIBC) public-key cryptography infrastructure that enhances AIS with on-demand anonymity, authentication, and encryption capabilities. In this paper we address implementation aspects of that infrastructure. In particular, we propose to use the Sakai-Kasahara Identity-Based Encryption (IBE) approach to implement the mIBC infrastructure, following the IEEE 1363.3-2013 standard for Identity-Based Cryptography.

I. Introduction

The Automatic Identification System (AIS) is a maritime navigation safety communications system [2]; its main aim is to improve the maritime domain awareness beyond the limitations of the radars. Radars give a good perspective of the shoreline and of moving targets but their accuracy is limited by the presence of obstacles (e.g., small islands), the Radar-Cross Section (RCS) value of the targets and the weather conditions. In contrast, AIS transmissions remain accurate, with good or adverse weather conditions, in areas with many physical obstacles or heavy marine traffic (e.g., Malacca Straits). Shipborne AIS devices periodically transmit static data (i.e. vessel's name, MMSI, IMO-number, type, dimensions, departure port, arrival port, cargo, etc.) and dynamic real-time navigation data (i.e., Global Navigation Satellite System (GNSS), steering, speedometer, etc.) [3]. When this information, as received from all nearby AIS devices, is aggregated and overlaid on a vessel's electronic navigation chart, the officer-on-watch obtains a good overview of the nearby marine traffic. The use of the AIS is regulated by "Regulation 19" of SOLAS Chapter V, under the supervision of the International Maritime Organization (IMO) and the International Telecommunications Union (ITU).

Many shore stations equipped with AIS receivers forward received AIS data to various publicly available internet sites. Undoubtedly, this practice offers a valuable tool for the international maritime community but may also become a convenient tool for unlawful adversaries. Unrestrained disclosure of the AIS broadcasted data via the internet can be an aid to sea-pirates and may violate the privacy of passengers [4], [5]. Additionally, the authentication of the transmitted data is missing, as source authenticity of AIS data relies on the transmitted MMSI number of the ship and its name. However, none of these is officially hardcoded on the AIS devices, nor are the relevant messages signed and certified. Thus, anyone with little knowledge of AIS workings can use an AIS transmitter to create fake AIS data that impersonate non-existing ships, AtoN (Aid to Navigation) or SAR (Search And Rescue Operations) [6], [7]. Without AIS authentication, the maritime domain may be the true one or a fake representation of the marine traffic in the area. A possibly fake representation of the marine traffic in an area poses a very severe threat to the international maritime community. The threat landscape of the AIS ecosystem has been examined in [8]. Accordingly, enhancing the security of AIS becomes an issue of importance to the maritime community. The VHF Data Exchange System (VDES) is seen as an effective and efficient use of radio spectrum, building on the capabilities of AIS and addressing the increasing requirements for data through the system, including some security aspects. VDES is also secure by design. However, full take up of VDES is not expected to happen soon [9].

In [1] we introduced the concept of the Maritime Certificate-less Identity-Based Public Key Cryptography infrastructure (annotated for simplicity "maritime IBC" or "mIBC"), and proposed a solution to enhance the security of the AIS. In this paper, we refine and build upon that work and discuss implementation issues. Specifically, we discuss the implementation of the additional AIS modes of operation proposed in [1] using the AIS protocol and message structure specifications, the IEEE 1363.3-2013 standard, and the Sakai-Kasahara IBE scheme.

The remaining of this paper is organized as follows: In section two we discuss related work. Section 3 briefly reviews the AIS security proposal in our earlier work [1], so as to make the present paper self-sustained. In section 4 we discuss the seamless implementation of AIS usage modes over the conventional AIS transport protocol. The initial setup and the operation of the three mIBC-AIS usage modes (3, 4, 5) that use cryptography and divert from the standard ones are discussed in section 4. Section 5 presents the structure of the AIS messages in the mIBC-AIS and describes the operation of the mIBC-App, an application designed to ensure transparent transmission/reception of the mIBC-AIS messages over the conventional AIS protocol. In Section 6 we discuss the operational overhead imposed by the proposed mIBC. Finally, section 7 summarizes our conclusions.

II. Related Work

In [10] a new protocol for AIS that relies on a three-tiered approach to security with vessel identity verified by certificates assigned by an approving authority was proposed. This solution assumes the existence of a cryptographic infrastructure that provides the maritime community with some source cryptographic capabilities that AIS lacks. The authors in [11] use AIS, the Maritime Mobile Service Identities (MMSIs) of the vessels and Trusted Third Parties to propose a three-step mutual authentication scheme that uses AIS as the communication means to provide authentication capabilities to the ships rather than endowing the AIS itself with additional security capabilities.

The authors in [12] proposed a solution based on the creation of a global, x.509-like Maritime PKI, where the registration and Certification Authorities would be the IMO and the National Maritime Authorities. This proposal suffers from implementation difficulties, because implementing a PKI infrastructure in a global maritime environment may prove to be quite a demanding and complicated task, and because certificates are very resource demanding in the challenging and costly maritime wireless communication environment. For these same reasons, works that aim at improving the security of similar systems, such as the Automatic Dependent Surveillance-Broadcast (ADS-B) in aviation, and propose the use of identity-based cryptography and symmetric cryptography [13], [14] are inapplicable in the maritime environment. Work that is not yet clear whether or how it may affect the future of AIS security is also underway [15]. Commercial AIS products that use symmetric cryptography exist (e.g. [16]). Nevertheless, they provide proprietary encrypted AIS only in vessels equipped with the same AIS product. Additionally, a worldwide adoption of a symmetric cryptography system that would need to manage symmetric keys on a vast number of vessels worldwide is a very complex if at all possible task. Therefore, such a solution is insecure for systems with characteristics similar to those of AIS [17].

The cryptographic schemes that we use to implement mIBC are identity-based cryptographic schemes founded on the q-Bilinear Diffie-Hellman Inversion problem (q-BDHIP), based on the Sakai-Kasahara Identity-Based Encryption scheme [18], whose security was proved in [19]. The IEEE 1363.3-2013 "Standard for Identity-Based Cryptographic Techniques using Pairings" [20] specifies identity-based cryptographic schemes based on the bilinear mappings over elliptic curves known as pairings. This standard describes eight identity-based cryptographic schemes that use pairings in their implementation. The schemes include approaches to encryption, digital signatures, signcryption, and key exchanges. These schemes may be used to encrypt both stored data as well as data in transit. The standard describes algorithms for calculating pairings and gives parameters suitable for implementing the specified schemes at industry-standard security levels [21]. Applications of certificate-less Identity-Based Cryptography (IBC) to navigation are described in [17], [22]. The use of pseudonyms in transportation applications is discussed in [23], [24].

III. Secure AIS Through the Maritime IBC (mIBC)

In [1], we proposed the security enhancement of AIS with the use of Identity-Based Public Key Cryptography (IBC) [25], [20] as the foundation of an International Maritime Identity-Based Cryptographic infrastructure (mIBC), under the supervision of the IMO. IBC is a variation of public key cryptography proposed by Shamir in 1985 [25]. On public-key cryptography infrastructures (PKIs), each entity has a pair of mathematically connected keys, a Private (Secret) key and a Public Key. Data that are encrypted with the Private (Secret) key are decrypted with the corresponding Public Key and vice versa. A disadvantage of the PKIs [26] is that the participating entities have to somehow obtain the public keys of the other participating entities. The solution is the use of special certificates that bind the name of the entity with its public key. However, this poses a new problem; the participating entities in the PKI should have the ability to obtain securely the certificates of the other participants. Instead of certificates, the IBC variations use a publicly known unique identification of an entity as its Public key (e.g., entity's name, email address, MMSI or pseudo-MMSI number in [1]).

Unfortunately, that convenience comes with a cost; IBC infrastructures need the existence of a trustworthy central coordinator. The trusted central coordinator sets up the IBC infrastructure, and generates all the Private (Secret) keys of the IBC participated entities. Then, the participating entities obtain, by means of a secure channel, their Private (Secret) keys from the trusted central coordinator. The main disadvantage of the IBC is that, beyond the owner of the key, the Trusted Central Coordinator knows the Private (Secret) keys. On the other hand, the main advantages of IBC over traditional PKI are the simplicity of the infrastructure, resources savings, and self-proved information on the public key [22], [27], [28], [29].

The mIBC-PKG functionality can either be implemented by a single authority (e.g. IMO) or by a number of multiple inter-trusted mIBCs operating in parallel. For simplicity, in the sequel we assume the existence of only one International Maritime mIBC Private key generator (IMO-mIBC-PKG) as an IMO agency. However, the implementation of the other option is straightforward. The approach involves defining five distinct AIS usage modes with various security features to choose from, according to the needs of the vessel during the trip, as follows:

1. mIBC-Typical-AIS (mode 1): The AIS as is today, for routine use.
2. mIBC-Authenticated-AIS (mode 2): Offers source authentication via cryptographically-signed AIS transmitted messages. Under mIBC, an AIS device signs the transmitted AIS data with its mIBC Private (Secret) key, and the receivers authenticate the signed AIS data by using only the MMSI of the transmitter.
3. mIBC-Anonymous-AIS (mode 3): Offers legitimate anonymous AIS transmitted messages via cryptographically-signed "Pseudo-MMSIs." An AIS device transmits, instead of the real MMSI of the vessel, a pseudo-MMSI generated and cryptographically signed by the IMO-mIBC-PKG. From a cryptographic point of view the mIBC-Anonymous-AIS (mode 3) is identical with the mIBC-Authenticated-AIS (mode 2) but uses pseudo-MMSI instead of the real MMSI of the vessels [1].
4. mIBC-SK-IBE-AIS (mode 4): Allows the transmission of encrypted AIS messages to a specific entity via an appropriate encryption scheme, such as the Sakai-Kasahara Identity Based Encryption scheme.
5. mIBC-AES-AIS (mode 5): Allows the transmission of encrypted AIS messages to a group of participants (i.e. trustworthy vessels in an insecure area) via symmetric cryptography (e.g., AES [30]).

Their interrelationships are depicted in Figure 1. Details on the structure of the messages are given in Section 5.

IV. Implementing the Maritime IBC (mIBC)

The entities involved with the implementation of the mIBC are a trusted coordinator (also referred to as Key Server [20] or Private Key Generator - PKG [1]) and the mIBC participants. The trusted coordinator is an entity trusted by all the participants of the scheme. In this work, for efficiency and simplicity, we assign this role to a part of the IMO that we call International Maritime Organization mIBC Private Key Generator (IMO-mIBC-PKG). mIBC participants can be AIS devices, coast guards, patrol vessels, shipping companies, vessels, etc. mIBC participants may assume the role of sender or receiver of AIS messages, or both. The IMO-mIBC-PKG is responsible for two initial operations of the mIBC, namely the initial setup of the scheme and the extraction (creation) of the Private (secret) keys of each participating entity. These are described in the sequel.

A. Setting up the Maritime IBC (mIBC)

In practice, the first operation of the IMO-mIBC-PKG is to define a number of cryptographic parameters, as specified in [20] and [31], that lead to the generation of the Master Secret Key and of the corresponding Master Public Key. Specifically: establish a random number generator (e.g. following the RFC5091, FIPS186-2 or X9.62 standards); choose the security parameter t, which is the size (in bits) of a prime number p that will be the order of the generated bilinear map cyclic groups G1, G2, GT (the larger the value of t, the more secure the scheme is); find a prime number p where p > 2^t [31]; generate three bilinear map cyclic groups G1, G2, GT of prime order p, by following [19], [32], [31]; choose PG2, a random generator of G2; find PG1 in G1 as a random generator of G1, so that an efficient isomorphism from G2 to G1 mapping PG2 to PG1 exists; define the bilinear pairing mapping e from G1 x G2 to GT; pick a random Master (Server) Secret key (Mskey) in Zp; pre-calculate the pairing value e(PG1, PG2) in GT; and compute the corresponding Master (Server) Public key (MPUB). The second operation of the IMO-mIBC-PKG is to define the cryptographic hash functions to be used by all the participating entities: (H1) for hashing the MMSI of the receiver of the encrypted data; (H2) as a cryptographic hash function for signature verification; (H3) for XOR-ing with the AIS data or AES key; (H4) for deriving a blinding coefficient; and (H5) for XOR-ing with the plaintext. Finally, the IMO-mIBC-PKG publishes/disseminates the mIBC Public Parameters (mIBC-PP) to all mIBC-enabled AIS equipment, using a secure channel (e.g., smart cards, smart tokens, etc.). The IMO-mIBC-PKG is also responsible for safekeeping the secrecy of the Master (Server) Secret key (Mskey). Because the Master (Server) Secret key (Mskey) plays the role of the Private Key of a Certification Authority in an X.509 Public Key Infrastructure, it requires the same level of advanced protection and disaster recovery plans must exist in case of compromise.

B. Extracting the private keys of the participating entities

The IMO-mIBC-PKG uses the MMSI (or the pseudo-MMSIs) as the publicly known ID of a vessel and combines it with the Public Parameters (PP) and the Master (Server) Secret key (Mskey) of the mIBC to extract the corresponding Private (Secret) Key (SK_MMSI) of the vessel. The mandatory use of the Master (Server) Secret key (Mskey) on the extraction operation prohibits an adversary to create fake Private (Secret) Keys even when they know the (publicly available) MMSI of the entity and the (publicly available) Public Parameters of the mIBC. The steps are: represent the MMSI or the pseudo-MMSI as a string of bits; compute the cryptographic hash H1(MMSI) or H1(pseudo-MMSI); then compute the Private (Secret) Key SK_MMSI equal to (H1(MMSI) plus Mskey) raised to the power minus one multiplied by Q2 in G2. Note that the main disadvantage of the Identity Based Cryptography scheme lies in this operation. Because, in contrast to the PKI, the Private (Secret) Key SK_MMSI is generated centrally by the IMO-mIBC-PKG, two problems arise. First, the IMO-mIBC-PKG knows the Private (Secret) Key of the entity. Thus the security and especially the non-repudiation of the infrastructure relies heavily on the trustworthiness of the IMO-mIBC-PKG. Second, the Private (Secret) Key should be transferred from the IMO-mIBC-PKG to the AIS-device of the entity on a secure channel (e.g., smart cards, smart tokens, etc.). In [1] we proposed the manual transfer on tamper-proof devices by authorized personnel, but more convenient solutions can be found (e.g., secure internet connections).

C. Operating the mIBC: Modes 2 and 3 (Authentication and Anonymity)

The AIS device of the sending entity (the sender) signs the AIS data to be transmitted with its private key (SK_MMSI). The sender uses the Public Parameters of the mIBC, its MMSI, its Private (Secret) Key, a random number and the AIS data to be signed. Then, the sender transmits the signed AIS data. The operation is: the inputs are the message to be signed AISdata, the Public Parameters mIBC-PP, a random integer r (0 < r < p-1) generated with the random number generator, and the Private (Secret) Key of the signer. The computation is: u equals e(PG1, PG2) raised to r; h equals H2(AISdata, u); S equals (r minus h) multiplied by SK_SIGNER. The output is the signed message, the triplet (AISdata, h, S). Any receiving entity can verify the authenticity of the received AIS data by using the (publicly available) MMSI (or the pseudo-MMSI) of the sender and the mIBC Public Parameters (mIBC-PP). The verifier may be any equipment (hardware/software) that can receive AIS data directly (e.g. an AIS device) or forwarded AIS data via satellites or the internet (e.g., special software on law enforcement units, port authorities, shipping companies, etc.). The operation is: the inputs are the signed message triplet (AISdata, h, S), the official Public Parameters, and the MMSI of the signer (note that H3, H4, H5 are not used in this operation). The computation is: u equals e(S, H1(MMSI_SIGNER) PG1 plus MPUB) multiplied by e(PG1, PG2); verification: the signature is Valid if h equals H2(AISdata, u) and Invalid otherwise. The output is a valid or invalid signature, and accordingly valid or invalid AIS data.

D. Operating the mIBC: Mode 4 (SK-IBE Encryption)

The sender/transmitter uses the Public Parameters of the mIBC and the MMSI of the receiver to encrypt the AIS data (that can be an AES key), and transmits the ciphertext via a typical AIS device. The encryption operation steps are: the inputs are the cleartext AISdata, the official Public Parameters, a random integer sigma, and the MMSI of the receiver. The computation is: r equals H4(sigma, AISdata); gr equals e(PG1, PG2) raised to r; U equals r multiplied by (H1(MMSI_RECEIVER) PG1 plus MPUB); V equals sigma XOR H3(gr); W equals AISdata XOR H5(sigma). The resulting ciphertext is the triplet c equal to (U, V, W). All the AIS-enabled devices in range can receive the encrypted data, but only the receiver who knows the mIBC Private (Secret) key corresponding to the MMSI of the receiver can decrypt the data. The steps are: the inputs are the official Public Parameters, the Private (Secret) Key of the receiver, and the ciphertext c equal to (U, V, W). The computation is: g equals e(U, SK_RECEIVER); sigma equals V XOR H3(g); the cleartext AISdata equals W XOR H5(sigma); r equals H4(sigma, AISdata). The output is: valid if U equals r multiplied by (H1(MMSI_RECEIVER) PG1 plus MPUB), else the received data is not valid.

E. Operating the mIBC: Mode 5 (Symmetric Cryptography)

The use of encrypted AIS between the vessels of a so-called "blue-force" is not new and commercial products that implement it using symmetric cryptography exist. Nevertheless, they provide proprietary encrypted AIS only in vessels equipped with the same AIS product. For example, the SAAB R5 Supreme W-AIS System supports the DES, AES, and Blowfish symmetric ciphers. Another example of an approach that is compatible with our work is the Encrypted Automatic Identification System (EAIS) proposed by the United States Coast Guard in [33]. Our innovation is the use of the mIBC-SK-IBE-AIS (mode 4) for disseminating the symmetric key to allow the maritime community and law enforcement units to create ad-hoc "blue forces," or AIS Ad-hoc NETworks (AISANETs) [1]. Following the analysis in [33], the 128-bit AES key is sufficient for encrypted AIS data between the members of a law-enforcement "blue-force". However, "blue-forces" tend to use strong combinations of ciphers and key sizes, because the symmetric key in the current approach is generated once, it is pre-loaded on the AIS devices, and it is expected to be secure for a time-period far longer than a day or two. On the other hand, our approach for the AIS Ad-hoc NETworks (AISANETs) uses a symmetric key only for a period of some hours, and then a new key will be generated and disseminated to the participating vessels.

V. mIBC-AIS Messages

mIBC needs to be as transparent as possible to current AIS implementations. Therefore, new mIBC-AIS modes should not alter the currently used AIS protocol. To achieve this goal we introduce a new application, named "mIBC-AIS-App", described in section 5.3, to be used as an interface to implement the mIBC-AIS scheme over the currently available AIS infrastructure. It is important to note that we use the AIS protocol only as the underlying transportation carrier protocol to transmit the signed/encrypted mIBC-AIS data of mIBC. In particular, mIBC-AIS data are encapsulated by the mIBC-AIS-App in the data payload subsection of existing AIS messages with ID 6 and ID 8. As we shall see, the latter are special AIS messages that permit the encapsulation of data of non-AIS dependent, arbitrary applications. The sender mIBC-AIS-App creates the appropriate mIBC data and then encapsulates it into the special AIS messages (ID 6, 8) that are transmitted via the standard AIS infrastructure. On the other end, the receiver mIBC-AIS-App decapsulates and processes the received mIBC data. This is analogous to the encapsulation of the Transmission Control Protocol (TCP) data inside the Internet Protocol (IP) packets.

AIS defines 27 different types of AIS messages that are identified by their Message-ID [2]. Messages with Message-ID 1, 2, and 3 are Position Reports, Messages with Message-ID 4 are Base Station Reports, Messages with Message-ID 21 are Aid-to-Navigation (AtoN) AIS station Reports etc. Each AIS message may use one to five timeslots. The available payload data in each timeslot is 168 bits, and there exist AIS message types (e.g. "AIS ADDRESSED BINARY MESSAGE" (MESSAGE ID: 6) and "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID: 8)) that may use the maximum of the 5 timeslots i.e. just over 900 bits of payload data. AIS messages are also classified according to their priority (1 to 5) in the timeslot sequence. The majority of the AIS messages with priority one occupy only one timeslot i.e. 168 bits of payload data. A notable exception is the AIS AIDS TO NAVIGATION (ATON) REPORT (MESSAGE ID 21) that needs 272-360 bits. Table 1 shows an example of a typical Class A AIS position report (Message ID 1) of 168 bits comprising: Message ID (6 bits), User ID i.e. MMSI number (30 bits), Navigational status (4 bits), Rate of turn (8 bits), Speed over ground (10 bits), Position accuracy (1 bit), Longitude (28 bits), Latitude (27 bits), Course over ground (12 bits), True heading (9 bits), Timestamp (6 bits), Special maneuver indicator (2 bits), Spare (3 bits), RAIM-flag (1 bit), and Communication state (19 bits). The AIS standard dictates the exact structure of each message, including generic parameters found in all AIS messages and message-specific parameters. AIS messages include a Timestamp (6 bits long) that is the Coordinated Universal Time (UTC) second when the report was generated by the electronic position fixing system (EPFS).

Two AIS messages, namely Message ID 6 and Message ID 8 are particularly interesting for the transmission of the signed/encrypted AIS data from/to the mIBC-AIS-App. Their useful characteristic is the existence of an isolated data payload subsection that registered applications, not related to AIS, may use to transport their data [2]. Specifically, Message ID 6 and Message ID 8 allocate their Binary Data parameter packet section as follows: a) 16 bits as Application Identifier and b) 920/952 bits for Arbitrary Application Data payload for registered applications. Thus, the mIBC-AIS-App can be registered as an add-on AIS application with a unique ID and the Application Data payload of Message ID 6 and Message ID 8 can be used for the transport of mIBC-AIS-App data. The "AIS ADDRESSED BINARY MESSAGE" (MESSAGE ID 6) offers a maximum of 920 bits space for arbitrary application data addressed to a specific receiver (i.e., all the AIS devices that will not have the specific addressed MMSI will discard the received message ID 6). Table 2 depicts a typical AIS ADDRESSED BINARY MESSAGE (MESSAGE ID 6) with mIBC-AIS-App data encapsulated in its "Binary Data" section. This section includes two subsections to be used for the transmission of the mIBC-AIS data necessary for the implementation of secure AIS mode 4. According to the AIS specifications for Message ID 6, only the application denoted by its ID in the "Application identifier" subsection is responsible for the encapsulated data inside the "Application data" subsection. Therefore, we use the "Application identifier" to denote the mIBC-AIS-App as the responsible application for the mIBC-AIS data encapsulated inside the "Application data" subsection. Because the standard AIS infrastructure does not interact with the data payload stored inside the "Binary Data" section of the Message ID 6, the encapsulated mIBC-AIS data are isolated.

An identical approach can be followed for the transparent transmission of the mIBC-AIS data with the "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID 8). The "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID 8) offers a maximum of 952 bits space to broadcast arbitrary application payload data. This type of AIS message is used to transfer data necessary for the implementation of Secure AIS modes 2, 3, and 5. The structure of the AIS BROADCAST BINARY MESSAGE (MESSAGE ID 8), as shown in Table 3, is identical with that of Message ID 6, with the notable exception that the "Destination ID" section is absent in the (broadcast) Message ID 8, resulting in a savings of 30 bits. The isolation of the encapsulated mIBC-AIS data payloads makes the proposed mIBC-AIS implementation transparent to the current standard AIS infrastructure. A mIBC-Authenticated-AIS (mode 2) message is a broadcasting transmission that we encapsulate inside a typical "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID 8), which offers a maximum of 952 bits space for arbitrary application data. If we use MNT curves, with a 128 bit key, the signature alone is 768 bits long; this allows for a useful payload of 168 bits for the original AIS data. The majority of the typical "priority" AIS messages broadcasted by the AIS are shorter than 168 bits. Hence, it is feasible to encapsulate them, together with their mIBC-AIS signature, inside a single "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID 8). Unfortunately, there are important AIS messages, such as the AIDS TO NAVIGATION (ATON) REPORT (MESSAGE 21), that need 272-360 bits of space; these cannot be encapsulated together with their signature inside one "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID 8). Besides, a higher mIBC security level may use cryptographic parameters that will yield longer signatures which would be impossible to encapsulate within only one MESSAGE ID 8. To resolve this, the proposed implementation provides for the partition of the signature and the original AIS data into multiple "AIS BINARY BROADCAST MESSAGE" (MESSAGE ID 8) messages, as in Figure 2. The mIBC-AIS-App at the two ends of the communication channel is responsible for the appropriate partition and reconstruction of the signature and of the original AIS data into the multiple ID 8 messages. The first and second messages are structured as in Tables 4 and 5 respectively. As will be seen in the next section, the overhead bandwidth for the mIBC-SK-IBE-AIS (mode 4) encryption is considerable. This is why we propose to use mIBC-SK-IBE-AIS (mode 4) mainly for the dissemination of the new AES symmetric keys of the mIBC-AES-AIS (mode 5). We believe that the 128-AES algorithm with a key length of 128 bits provides more than adequate security for the AIS in insecure areas. Bear in mind that in our case we do not need to store secret data for years but only to protect AIS transmitted data for hours or up to a few days. In this case, the ciphertext will be almost equal with the key, i.e. 128 bits long. Therefore, at most two AIS ADDRESSED BINARY MESSAGES (MESSAGE ID: 6) with over 1800 bits of combined payload packets will be enough to transfer the mIBC-SK-IBE-AIS (mode 4) data. The message partitioning details are identical to the message construction for the mIBC-Authenticated-AIS (mode 2). The structure of the 1st "AIS ADDRESSED MESSAGE" (MESSAGE ID 6) encapsulating a 128-bit AES key in mIBC-SK-IBE-AIS (mode 4) is shown in Table 6. Note that the mIBC-AIS-App computes the total size of the AES key plus the encrypted ciphertext triplet (U, V, W) and determines how many Message ID 6 (i.e., parts) have to be transmitted. A possible encrypted AIS message structure via the mIBC-AIS-App in encryption (mode 5) is shown in Table 7. Note that the mIBC-AIS-App computes the total size of the encrypted AIS data. Depending on the symmetric cipher (e.g., AES128), the mode (e.g., CBC, CTR) and other parameters, the overhead varies from 16 bytes (e.g. for the IV plus the padding of 1 to 16 bytes for PKCS#5 padding if we use the CBC mode). Therefore, for a standard AIS message, one AIS BROADCAST BINARY MESSAGE (MESSAGE ID: 8) (i.e., 1 to 5 slots) suffices.

The mIBC-AIS-App is a piece of code that may be implemented either as a firmware update on current AIS devices or on separate hardware to be connected between the AIS device and the AIS antenna. In either case, the mIBC-AIS-App will be an intermediate between the currently running AIS and the AIS antenna of the vessel. The mIBC-AIS-App assumes sole responsibility for the transmission of all mIBC enabled AIS messages. It intercepts the AIS messages, exports their data, cryptographically manipulates them, encapsulates them in AIS Messages ID 6 and/or ID 8 and forwards them to the AIS antenna. In particular, the mIBC-AIS-App: forwards the typical AIS messages unaltered to the AIS antenna/AIS device, respectively, when in mIBC-Standard-AIS (mode-1) usage mode; implements the mIBC-AIS modes 2, 3, 4, 5; stores (or accesses) the cryptographic parameters (i.e., Public Parameters, MMSI or Pseudo-MMSI, mIBC key-pair of the vessel); carries out all the cryptographic operations, computations and procedures; forwards the signed/encrypted AIS data to the appropriate end devices, i.e. AIS or ECDIS displays or any other compatible software/hardware of the vessel; and encapsulates/decapsulates the mIBC-AIS data to/from AIS Messages ID 6 and ID 8. Figures 3 and 4 depict the use of the mIBC-AIS-App and its interaction with the AIS devices. In Figure 3 the mIBC-AIS-App is switched to mIBC-Standard-AIS (mode 1) and thus does not interfere with the AIS operation. The Transmitter-AIS device transmits - via a standard AIS Message ID 1 - the collected static, voyage, positional and navigational data of the vessel. The Receiver-AIS device receives the AIS data and displays them to the appropriate navigational equipment. In both cases, the mIBC-AIS-App forwards the original Message ID 1 without altering it. In contrast, in Figure 4 the mIBC-AIS-App is switched to one of the AIS secure modes (i.e. modes 2-5). The Transmitter-AIS device collects static, voyage, positional and navigational data of the vessels and creates a standard AIS positional AIS Message ID 1. The mIBC-AIS-App of the transmitter: a) intercepts the AIS positional AIS Message ID 1 before its transmission; b) reads the data of the AIS Message ID 1; c) signs or encrypts the appropriate data according to the mIBC-AIS usage mode; d) encapsulates the signed/encrypted data inside the "Application data" section of the Messages ID 6 and/or ID 8; e) transmits - via the AIS antenna - the newly created Messages ID 6 and/or ID 8. On the receiver side, the mIBC-AIS-App: a) intercepts the Messages ID 6 and/or ID 8 received by the AIS antenna; b) decapsulates and concatenates the mIBC data from each received Message ID 6 and/or ID 8; c) verifies or decrypts the received mIBC data according to the mIBC-AIS usage mode; d) reconstructs and forwards to the Receiver AIS device the original AIS Message ID 1; e) the original AIS Message ID 1 is displayed on the navigational equipment.

VI. Operational Overhead

The bandwidth overhead of mIBC-Authenticated-AIS (mode 2) is the bits additional to the cleartext AIS data required for each signed transmission. The transmitted signed data is the triplet (AISdata, h, S). According to Table 7 in [32], we estimate the bandwidth overhead, with "point compression" on Super Singular (SS) curves at 80 bit security, MNT curves at 80 bit security and MNT curves at 128 bit security. The values h in Zq are 160 bits, 160 bits and 256 bits respectively, and S in G1 is 512 bits, 171 bits and 512 bits respectively, so the estimated bandwidth overhead, the sum (h plus S), equals 672 bits, 331 bits and 768 bits respectively.

All the participating entities in the infrastructure have plenty of computational power, and thus the computational overhead should not be a problem. However, as an example, we present the following computational overhead estimates: the general computational overhead comparison methodologies count the separate mathematical operations needed in each proposed IBC implementation. The mathematical operations are exponentiations, scalar point multiplications, and pairing evaluations. In the proposed IBC scheme the signing process uses two scalar point multiplications and the verification process one scalar point multiplication and one pairing evaluation. Thus according to [31], the above implementation needs 1.56 milliseconds to sign a message, and 3.60 milliseconds to verify a signature. However, we must take into account that [31] was published back in 2005 and used C++ based implementations on an Athlon XP at 2GHz to compute the authentication and signcryption schemes under a supersingular curve (SS) of embedding degree k=6 over F397. It is expected that modern technology will achieve far better speeds.

Our estimates for mIBC-SK-IBE-AIS (mode 4) are based on the work in [32] and in [31]. We highlight that in case where the confidential transmitted data is a symmetric key (i.e., AES key) the security level offered by mIBC-SK-IBE-AIS (mode 4) should be equal with the security level offered by the disseminated AES key. In general, the security level of a hybrid cryptographic scheme is the minimum between the level of the security offered by the cryptographic key and the security level of the mechanism that disseminates that cryptographic key. The bandwidth overhead is the bits additional to cleartext AIS data required to be transmitted for each mIBC-SK-IBE-AIS (mode 4) confidential data transmission. The transmitted encrypted data is the ciphertext triplet (c) equal to (U, V, W). According to Table 8 in [32], we estimate the bandwidth overhead, with "point compression" on Super Singular (SS) curves at 80-bit security, MNT at 80-bit security and MNT at 128-bit security: the Public Parameters (not transmitted via mIBC-AIS, thus not adding to the mIBC-AIS bandwidth overhead) are 2048 bits, 1368 bits and 4096 bits respectively, and the ciphertext (excluding the message) mIBC-AIS overhead bandwidth equals 672 bits, 331 bits and 768 bits respectively. The same conditions stand here as in the example for authentication. The general computational overhead estimates presented here are based on the work in [32]: for the Super-Singular (SS) elliptic curve at 80-bit security the sizes are Zp=160 bits, G1=512 bits, G2=512 bits, GT=1024 bits; for the MNT elliptic curve at 128-bit security they are Zp=256 bits, G1=512 bits, G2=3072 bits, GT=3072 bits. Also [32] defines an "indicative" time-unit as the time needed for point multiplication on a random 171-bit elliptic curve for a random 160-bit exponent. Under the above settings, the following indicative results for SK-IBE are derived: for the Super-Singular (SS) elliptic curve at 80-bit security, secret (private) key extraction costs 2 time units, encryption costs 6 time units and decryption costs 104 time units; for the MNT elliptic curve at 128-bit security, secret (private) key extraction costs 100 time units, encryption costs 36 time units and decryption costs 1506 time units. Finally, the BLMQ signcryption scheme that has similar characteristics needs 2.65 milliseconds to sign and encrypt for one group exponentiation and two scalar point multiplications [31]. The processing time for decryption and verification is 6.09 milliseconds for one group exponentiation and two pairing evaluations.

VII. Conclusion

In our previous work [1] we introduced the concept of a secure AIS founded on Identity Based Cryptography. In this work, we focused on proving the feasibility of our idea by describing a working model based on specific AIS attributes and specific Identity Based Cryptographic schemes. We have proposed a Maritime Identity Based Cryptographic infrastructure (mIBC) under the IMO. We described five usage modes for the proposed secure mIBC-AIS. The mIBC-Typical-AIS (mode 1) works like the typical AIS; it is the default mIBC-AIS usage mode. The mIBC-Authenticated-AIS (mode 2) enhances AIS transmissions with source authentication capabilities; its implementation is based on the BLMQ identity-based signature operations formalized in the IEEE 1363.3-2013 standard. The mIBC-Anonymous-AIS (mode 3) uses pseudo-MMSIs to provide AIS with anonymity, as described in detail in [1]. When in mIBC-SK-IBE-AIS (mode 4) usage mode, the mIBC-AIS can send arbitrary encrypted data to any entity under mIBC without any previous contact or pre-configuration with the receiver entity. For the implementation of the mIBC-SK-IBE-AIS (mode 4), we used the security proof of Sakai-Kasahara's Identity-Based Encryption scheme in [19]. The last usage mode is the mIBC-AES-AIS (mode 5), which provides for encrypted AIS secure (group) communication with symmetric cryptography (e.g., AES). Today, encrypted AIS with symmetric ciphers (e.g., AES) is offered by various vendors of commercial AIS devices but always for pre-defined "blue-forces" that use pre-installed symmetric AES keys. In contrast, we use the mIBC-SK-IBE-AIS (mode 4) to disseminate the symmetric AES keys of the mIBC-AES-AIS (mode 5), to any trustworthy entity, ad-hoc, without any pre-communication or symmetric-key pre-installation. Responsible for the proposed mIBC-AIS functionality is the mIBC-AIS-App intermediate application, that lies between the typical AIS device and its AIS antenna. The mIBC-AIS-App is responsible for intercepting the original AIS data, performing the cryptographic operations and encapsulating/decapsulating the mIBC-AIS data into standard AIS Messages ID 6/8 as arbitrary data payloads. In this way, the implementation of the mIBC-AIS uses the currently available AIS infrastructure but does not directly interact with it. This enables the mIBC-AIS to be a transparent add-on to the currently available AIS infrastructure.

We conclude that a practical implementation of our approach is feasible. We intend to proceed with a prototype implementation of the proposed scheme, including the mIBC-App, and to experiment with it in order to assess its performance.