Demo Long Range Identification and Tracking System

Demo Long Range Identification and Tracking System

7 DEC 2006

Demo Remote Data Center operational

Demo remote data center VMS_SG (10000 ships) is operational and now part of the system. Proof that a unified, secure LRIT system can be built from distributed, existing data centers running straightforward, open standards based, software. As someone pointed out on the blog, now any registry can create its own LRIT profit center without the overhead cost of intermediate entities.

1 DEC 2006

Now you can get your digital certificate and submit VMS info on-line

Instructions at http://lrit.info/swdwn.html are now live. A demo package to setup your own Data Center demo will be forthcomming.

28 NOV 2006

Sometimes you just have to try to build it first to understand it
(to lay down suitable specifications)

Having been intimately involved in the initial LRIT design efforts at the IMO I saw the need early on to explore the technical details of this distributed communications system before anything resembling final specifications could be written down.

So I embarked on developing a fully functional demo system with the help of a few fellow engineers. Here are the humble results of my efforts. I would be happy to present my findings in person if there is sufficient interest and likely make the computer source code available as Open Source Software for the benefit of all. Note: This is a work in progress - fixes and improvements will appear depending on when us volunteers have time. Comments are welcome at the blog site: here.

Disclaimer: This work is for demonstration, research and learning purposes only. None of the entities referenced, named, or identified are in any way involved in this effort or have any connection to it. Every reference is by way of example only.

All ship movement information is simulated and accelerated 100x (so that we don't have to wait a week to see if something worked). As you can see I am neither a graphics expert (maybe there is one out there) nor well versed on where to find ship designation or port information. I looked at AMVER plots and used Google Earth to come up with a few routes.

FEATURES

  • Fully distributed secured communication via SSL/AES-256 encryption
  • Centrally controlled (i.e., IMO) Public Key Infrastructure
  • Each Data Center has complete control and responsibility for its own security
  • Minimal static DDP information requirements (vessel flags, data center list, contours)
  • Limited central entity requirements (audit and review)
  • Automated bill generation
  • Open Standards based, multi-threaded, prioritized (for SAR), Unix implementation
  • Support for legacy formats (IMO/NAFO) as well as XML

HOW IT WORKS (refer to Figs 1,2)

The demo has two main parts. One is for communication (csrv) and the other generates simulated vessel position reports (feed). There are also ancillary conversion modules that convert between IMO, NAFO, and XML formats (tx_cvt, encxmlout). It uses standard software libraries for database manipulation and Secure Socket Layer (SSL) communication.

Simulation

Feed reads in tables of waypoints representing routes between ports then arbitrarily creates a number of ship entries with IMO numbers, flag state, and initial destination port. IMO number/flag state information is stored in a common database corresponding to the DDP. All other information is stored locally on a per DC basis. Feed then "starts" each of them along a route, incrementing each ship's position every hour. Once the ship reaches the end of the route, another route with the same end point is randomly selected and the ship "moves" along that path.

Lrit Information Processing

At each step along the way a DC local table is consulted to see if the specific ship should be emitting an automated position report. If not, the simulation continues to step along. If so (Fig 2), encxmlout is handed the position information to a) determine if any country has an outstanding request for information on this ship, b) the requesting country is entitled to receive this information (i.e., not on a blocked list, headed toward a port in that country or in its coastal waters). Note: Should encxmlout "discover" that a country that was once not entitled to receive lrit info is now so entitled (e.g. entered its coastal region), the transmission interval requested by that country is used to update the automated position reporting time for that ship. Similarly for when a country becomes un-entitled according to b). These are the feedback arrows in Fig 2. If it does not pass these tests, encxmlout simply discards the info.

Otherwise, it determines which DC should get this information (sending only one copy to DCs that may have multiple countries requesting and entitled for the info), formats the info into XML and places the result into queues corresponding to each remote DC for csrv to encrypt and deliver.

Communication

Csrv encrypts and delivers each message to their corresponding DCs in parallel (as csrv is multi-threaded), establishing connections and authenticating as necessary with their peer csrv processes. At the remote end(s) the information is stored in a local database for processing and display as needed (in our case a program that periodically reads the track data and plots it on a Web page).

Note that for test purposes, feed can be replaced with a remote, legacy VMS that would supply vessel position information. These are designated by "REMOTE VMS" in the figures and communication is via e-mail. The program tx_cvt is provided for the purposes of converting from IMO and NAFO formats into the internal format used by encxmlout.

Request Processing

Figure 1 shows how the requests described in a) above are lodged with a DC. Again we use encxmlout to create an XML formatted message (see formats below) and csrv to distribute the request to all who can act on it. A wildcard IMO number would have csrv distributing the request to all DCs. A specific IMO number request is routed by looking up its flag then the DC responsible for that flag. At the destination DC, outstanding requests for the specified ship(s) are created, along with the interval at which they are desired, and feed's automated position report interval is updated if needed. For a REMOTE VMS, an attempt at a suitable format is made and the update e-mailed for what its worth.

That's it for the meat. A host of other support routines also exist for billing, statistical, pki management, web page management, and plotting purposes.
Figure 1 - path of a "request"


Figure 2 - path of lrit info

Formats

Here are the pre-encrypted XML formats I used to exchange data between DCs in the current demo. As you can see they may have started with some formats proposed at COMSAR but with my additions probably do not follow W3C XML rules. I look to the experts among you for suggestions. For the demo I just wanted to get something working as soon as possible using a simplified XML parser.

LRIT Information

XML:

<Message id=feed_1594635ed460_tmp>
<ShipPositionReport>
<<ReportType>periodic</ReportType>
<ShipIdentity>
<IMO>0002711</IMO>
</ShipIdentity>
<Position>
<Lat>34.3167</Lat>
<Lon>-142.4667</Lon>
<Date>1972-06-10 14:20:00</Date>
</Position>
<DataASP>
<ASPID>humble tracking service</ASPID>
<TimeStampIn>1972-06-10 14:20:00</TimeStampIn>
<TimeStampOut>1972-06-10 14:20:00</TimeStampOut>
</DataASP>
<DataLDC>
<LDCID>vms_na</LDCID>
<TimeStampIn>1972-06-10 14:20:00</TimeStampIn>
<TimeStampOut>1972-06-10 14:20:00</TimeStampOut>
</DataLDC>
</ShipPositionReport>
</Message>

IMO:

AMVER/PR//IMONO/2143521//B/281330Z NOV//C/4200N/17544W//Z/EOR//

NAFO:

//SR//TM/POS//IMONO/2143521//LA/N4816//LO/W3351//TI/2025//DA/981219//ER

Request

XML:

<Message id=tx_e0dbb81_tmp00000000>
<SendShipPosition>
<ShipIdentity>
<IMO>0500074</IMO>
</ShipIdentity>
<Interval>3600</Interval>
<RequestingCountry>US</RequestingCountry>
</SendShipPosition>
</Message>

IMO: 

AMVER/REQUEST//FROMCC/ES//IMONO/0500074//INTERVAL/3600//Z/EOR//

NAFO: 

//SR//REQUEST//FROMCC/US//IMONO/0500074//INTERVAL/3600//ER

Port Information

XML:

<Message id=feed_1594635ed460_tmp>
<ShipSailPlan>
<ReportType>periodic</ReportType>
<ShipIdentity>
<IMO>0002711</IMO>
</ShipIdentity>
<Position>
<Port>US</Port>  or  <Port>-</Port>  
<Date>1972-06-10 14:20:00</Date>
</Position>
<DataASP>
<ASPID>humble tracking service</ASPID>
<TimeStampIn>1972-06-10 14:20:00</TimeStampIn>
<TimeStampOut>1972-06-10 14:20:00</TimeStampOut>
</DataASP>
<DataLDC>
<LDCID>vms_na</LDCID>
<TimeStampIn>1972-06-10 14:20:00</TimeStampIn>
<TimeStampOut>1972-06-10 14:20:00</TimeStampOut>
</DataLDC>
</ShipSailPlan>
</Message>

IMO:

AMVER/SP//IMONO/0500074//PORTSTATE/US//Z/EOR//

NAFO:

//SR//TM/DST//IMONO/0500074//PORTSTATE/US//ER

Public Key Infrastructure - PKI

The approach described here utilizes a Public Key Infrastructure (PKI) to:

  • preserve message integrity (using digital signatures)
  • eliminate the possibility of easedropping (using any number of encryption algorithms)
  • attest to the identities of entities in a transaction (using signed certificates for authentication)
and has the advantages of
  • DC controlled security
  • IMO controlled access
  • based on global industry standards

Before you can participate in the demo LRIT System you must generate a public/private encryption key pair. You make the public key available to all and you reveal the private key to no one. One is used to encrypt, the other is used to decrypt. Although their roles may be reversed, one is useless without the other.

Once you have generated this pair, your identity is electronically attested to by IMO and you can conduct secured and authenticated communication with other LRIT Data Centers (DCs). You may want to update your key pair once a year as a further security measure but unless you feel your private key has been compromised, this is not necessary as the underlying crypto algorithm used to generate these keys (RSA) is very difficult to break.

When sending LRIT information, it is digitally signed by encrypting the message digest (SHA/MD5) or "fingerprint" of the data with your private key. This encrypted fingerprint is referred to as the Digital Signature of the information and ensures any modifications en-route would immediately be detected.

The information along with this digital signature are sent to the destination DC via SSL which automatically verifies the identity and the integrity of the information by decrypting the digital signature portion with your published, publicly available (and scrutinized) public key.

The same digital signature calculation that was done by the sender is performed by the destination DC and the result compared with the decrypted value above.

If they match, the information has not been tampered with and the information is accepted for further processing and/or delivery.

If not, the information is discarded.

Once again, only the holder of the corresponding private key to the public key can decrypt data encrypted with the public key. Since each DC alone controls their private key and ensures it is never revealed to anyone, only the DC controls its information.

For speed, after the identity of both ends of a communication link are established, a bulk encryption method, in our case AES-256, is used to efficiently transfer data using automatically generated key exchanged using the above public key encryption.

Before a DC and their corresponding certificate can be used to exchange information with other DCs it must be signed by IMO. IMO has final say over who can participate. The regular expiry (typically one year) of certificates and other certificate verification tools give the IMO further access control over LRIT participants.

In a real system, initial proof of the authenticity and origin of the public key request would be confirmed via diplomatic note. This signed version of the public key is known as a Digital Certificate for that DC.

Note: This is the same mechanism used in everything from securing banking transactions on the Internet to ensuring software updates for the majority of computers in the world is done accurately (automatic software updates).

Make your own connection to the demo

Since the demo is based on open standards and the specific message formats are shown above, should you feel so motivated, feel free to connect to the demo with any software you write. Create a Certificate Signing Request and submit under IMO site, Certificate Management, Signing and, as this is a demo, it will automatically get signed right away (I trust you :-) so that you can participate. In the near future I will make a downloadable package available to make this easy.

LESSONS LEARNED

In running the demo I stumbled on a few issues that may be worth studying if they haven't been already. Specifically,

Information Fields Exchanged Between DCs:

In order for a receiving DC to properly process a request for lrit info from another DC, the request record should have the actual requesting country in it in addition to the other info in a request (like the IMO number and interval in which the country would like, and is willing to pay for, lrit info on this ship). Without this, the DC receiving this request will not be able to calculate the coastal, port, or blocked disposition of the vessel and therefore whether to send lrit info;

Depending on how the lrit info is plotted, the transmission of new destination port/end of destination information to lrit info subscribers entitled to receive this information (port state) would clarify and simplify display. This could also serve as the notification to a port state of a pending arrival or visa versa.

DDP Simplification

The DDP may not necessarily have to be an active database since a vessel's destination port should be known by the DC responsible for it and therefore can determine which DC to send lrit info. Therefore, the DDP would only need to publish (via a Web page) relatively static items like country contours for coastal state calculations, vessel flags, and a list of current DC's and connection/contact/country information.

To VPN or Not to VPN

In general a VPN is an excellent idea, however to securely deploy one means a Public Key Infrastructure (PKI) must be created to handle certificates to configure routers, the alternative being what is called a pre-shared-key but a shared secret/key is never a secret. Outsourcing VPN management implies the ability to view/change all data is being given to a third party. If a PKI is to be created anyway, why not just use SSL. In this case security is under the complete control of each DC with IMO controlling access through its ownership of the root certificate-key pair.

E-mail Too Slow

Our simulation originally used e-mail (XML encrypted and authenticated using S/MIME PKI of course) to communicate between DCs. We found the processing of tens of thousands of e-mail per hour, where the lrit info only made a small part, to be stifling. Using SSL, an authenticated, encrypted connection is left up as opposed to being created and torn down on every transaction and only the lrit info is sent, not a bunch of email header information and digital signature. Hence, SSL is a much more effective way to communicate between DCs. However, this does not rule S/MIME email out for certain low usage situations.

Customers Only Pay for the Information They Requested

Although transmissions of lrit info is automated, a country only pays for information it has requested on the IMO number or numbers it has requested and at the interval it has requested. This added another layer to our demo for the determination of whether a DC sends lrit info to another DC or not depending on requests sent from that DC. This determination has to be on a per ship/IMO number and per country basis (although we aggregated when possible). The additional processing power needed (in addition to the processing needed for coastal state determination) should be taken into consideration. Note: It is not too far fetched to some day eliminate such fine level request/billing control (and its associated complexity) and just offer a few packages (like cable-tv or Internet) that would set default rules for each customer/country. E.g. send-all, send-all-coastal-only, send-all-at-graduated-intervals (original lrit proposal?), .etc.

The Power of a Distributed Network

Less of a new suggestion than a reaffirmation of IMO's decision supporting a distributed LRIT system: While trying to run the simulation with 50000+ ships on one computer, it became clear that keeping up with 50000 simultaneous per ship coastal/port/request determinations would be difficult at best (e.g., with countries requesting lrit info once per hour). Although processing time per lrit info was typically 0.010 seconds, 50000 of them takes almost 10min given full resources to one source. Add other processing such as logs, stats, display and the 10min backup floods the system. However by naturally distributing both processing and communications to different DCs according to the countries they serve, handling 50000+ bursts becomes possible not to mention reliable.

CONCLUSUIONS

Developing this demo has allowed me to uncover a few issues which I hope will help put together an otherwise excellent approach to secure, trusted lrit information distribution. It has also shown me the power that can be brought to bear from a distributed system and hopefully a distributed effort. My work is by no means complete and although fully functional is not meant to be a solution. However I would encourage any interested parties, be they academic or commercial to contact me for what I hope will become an open source software effort. This will not only greatly accelerate the deployment of LRIT but with such a group effort will result in a transparent, low-cost implementation based on global open standards that will lead to widespread participation in LRIT system.

WHO AM I

  • PhD from Massachusetts Institute of Technology (MIT).
  • Developed computer networking, e-mail, software for 20 years.
  • Started a few small computer networking software and hardware companies that got acquired.
  • Worked at US State Department for 3 years in information technology policy.
  • Had enough of bureaucracy.
Comments concerning the design of this site should be sent to info@lrit.info.
Copyright © 2006   Richard Lamb
All rights reserved.