WEBVTT 00:00.000 --> 00:08.820 I'm going to go ahead without you necessarily seeing my smiling face, but it is indeed, well, except for technical difficulties, it's otherwise smiling. 00:09.260 --> 00:14.020 So, hello and welcome to Saturday at Hack to C. 00:14.720 --> 00:18.480 So let me get around to my PowerPoint presentation here. 00:18.480 --> 00:23.060 And let me just basically go through this and I've got some other things to show you. 00:23.160 --> 00:28.840 So, I'm going to talk today about some work that I'm doing on something called Protected AIS. 00:28.840 --> 00:38.620 And I'll just quickly give you a little bit of an overview of what I'm working on and what the problem is and what quasi-solution I worked on. 00:38.840 --> 00:45.880 So, automatic identification system is the system used by vessels at sea for situational awareness. 00:45.980 --> 00:48.420 We'll see some examples of this coming up in a minute. 00:48.580 --> 00:56.020 But obviously, this is the way ships let each other know where they are and what kind of ship they are and those kind of things. 00:56.020 --> 01:05.240 And as we've discussed, and certainly part of the talk yesterday, and you may know from other sources, AIS suffers from a number of security vulnerabilities. 01:05.780 --> 01:16.100 And so, because of those vulnerabilities, it makes it prone to some spoofing type attacks, replay type attacks, and things like that. 01:16.100 --> 01:20.020 And so, basically, a bad guy can send bogus messages. 01:20.020 --> 01:29.200 So, I came up with a proof of concept that uses some public key cryptography methods and provides something that I call Protected AIS. 01:29.200 --> 01:46.280 And it addresses some of the vulnerabilities, but one of the keys that I also wanted to be able to employ was that whatever solution I designed needed to be backward compatible with the existing protocols, or else it really wouldn't be very much of a demonstration capability. 01:47.030 --> 01:50.260 So, here are acronyms and abbreviations. 01:50.620 --> 01:57.660 So, again, for those of you who didn't sit in yesterday, a quick two-minute overview. 01:57.660 --> 02:10.160 AIS, as I said, it's a situational awareness system used between vessels and ground stations so that vessel traffic management systems know where vessels are that are in their area of responsibility. 02:10.340 --> 02:13.880 Maritime administrations know about vessels in their AOR. 02:14.440 --> 02:16.540 Ports can keep track, things like that. 02:16.540 --> 02:24.000 But also, equally, and possibly even more importantly, vessels can keep track of other vessels with whom they are in proximity. 02:24.040 --> 02:41.880 And they can get some idea from those other vessels what type of vessel they're looking at, possibly information about their cargo, the size of the vessel, speed, course, bearing, rate of turn, current position, destination, all that kind of stuff. 02:41.880 --> 02:51.160 And there are a class of vessels, mostly big ones, that are required to transmit AIS information. 02:51.600 --> 03:02.360 And for the work that I'm doing, this is important because there's two different types of AIS position information broadcasts, Class A and Class B. 03:02.420 --> 03:09.520 The vessels listed here, the big vessels, are the ones that are required to transmit Class A. 03:09.520 --> 03:14.940 And Class A really gives more information than Class B. 03:14.940 --> 03:20.100 Actually, for some of the work I was doing, I needed to know stuff like rate of turn, and Class B didn't say that. 03:20.100 --> 03:24.780 But Class A and Class B gives me sufficient information about vessels. 03:25.280 --> 03:34.700 Warships are exempted from being required to use AIS, so warships can transmit AIS, but they are not required to. 03:36.060 --> 03:39.620 So here's an example of an ECTIS display. 03:39.760 --> 03:42.360 I'm going to try, actually, another display. 03:42.360 --> 03:44.040 Let's hope I have the right screen up. 03:44.040 --> 03:45.000 I don't. 03:45.640 --> 03:54.960 This is a display coming from the feed that I have at Emory Riddle Aeronautical University in Daytona Beach. 03:54.960 --> 04:03.640 And so you can see right now, here's the university, we can see right now about 10 vessels. 04:03.940 --> 04:06.200 A second ago, we could see 11. 04:06.220 --> 04:12.740 Anyway, and the furthest vessel we can see is only actually about 14 kilometers away. 04:12.740 --> 04:18.620 But if I mouse over, it tells me, well, it tells me that there's that vessel there. 04:18.620 --> 04:26.220 But if I click on it, I can actually get a lot more information. 04:26.560 --> 04:28.380 So this is a Pleasurecraft. 04:28.520 --> 04:31.160 You can see it's only about a 33 footer. 04:31.440 --> 04:34.700 Right now, it's offshore, a little bit in Daytona. 04:34.700 --> 04:44.120 But you can get an idea of where it's located, when we last saw it, course, heading, speed, latitude and longitude. 04:44.120 --> 04:46.260 Tells us that last saw us a minute ago. 04:46.340 --> 04:50.800 And we're getting everything here from terrestrial AIS as opposed to satellite. 04:52.920 --> 04:55.500 And the name of this boat is Fishizzle. 04:55.500 --> 05:04.420 So anyway, here's the other vessel I was seeing that for some reason just disappeared for a moment. 05:08.000 --> 05:09.360 Give it a second. 05:09.360 --> 05:11.060 You know, it'll come up, hopefully. 05:11.720 --> 05:13.400 OK, this is something called the Janus. 05:13.400 --> 05:15.340 This is a sailing vessel, sailboat. 05:16.560 --> 05:20.020 And again, you know, we can get additional information. 05:20.020 --> 05:22.780 Note in this case, we can find out it's from Fort Lauderdale. 05:23.180 --> 05:30.420 They may not have programmed in what their destination is, but sometimes, you know, we will get that information as well. 05:30.420 --> 05:38.000 And then I spent a lot of time the last day talking to you about OpenCPN. 05:38.220 --> 05:43.320 And OpenCPN, again, here's the Fishizzle. 05:43.320 --> 05:46.160 That other boat may be right around in here. 05:46.160 --> 05:48.580 I've been losing boats underneath that marker. 05:51.600 --> 05:53.620 Let me just go back here. 05:53.620 --> 05:54.420 OK. 05:57.360 --> 06:01.480 Anyway, so like I said, this is an example of what you see in an ECDIS display. 06:01.540 --> 06:04.620 There are a variety of other applications you can use. 06:04.620 --> 06:06.460 This is FindShip. 06:06.460 --> 06:08.740 It's a mobile app that I have on my phone. 06:08.760 --> 06:12.080 I'm getting AIS information from here as well. 06:12.600 --> 06:15.000 I can use a web browser application. 06:15.000 --> 06:17.000 This is again from FindShip. 06:17.000 --> 06:26.260 And, you know, again, you look up a boat by name or MMSI or IMO number and you can, you know, find out where they are. 06:27.740 --> 06:36.280 Now, the AIS communication protocol largely, it's defined in a couple of international telecommunication union recommendations. 06:36.280 --> 06:43.520 And generally for radio, it employs this self-organized time division multiple access scheme. 06:44.320 --> 06:54.100 And so basically each vessel is finding its slot and is transmitting during its slot times, pretty short. 06:54.820 --> 07:05.620 And during its slot transmissions, it can also reserve other slots that it wants to use that are presumably haven't already been reserved by other boats. 07:07.740 --> 07:15.960 Now, I told you that, again, just to give a real brief high level overview of what matters for AIS as far as my little project here is concerned. 07:16.640 --> 07:20.640 The other thing that my project obviously needed was encryption. 07:20.880 --> 07:26.940 And so here, you know, real quick, we have three different types of crypto functions. 07:26.980 --> 07:32.900 And I'm classifying them in a pretty standard way based upon the number of keys that they use. 07:32.900 --> 07:36.060 So a hash function doesn't really have a key. 07:36.060 --> 07:40.520 It's one way encryption and it's used for message integrity. 07:40.900 --> 07:45.260 And secret key cryptography uses a single key for both encryption and decryption. 07:45.480 --> 07:50.900 And we largely use secret key crypto for privacy and confidentiality. 07:50.960 --> 07:57.620 The stuff that I'm working on, I have no desire to keep private or confidential, so I don't even really use any secret key crypto. 07:57.620 --> 08:02.120 And then public key crypto, which is really the most interesting out of this. 08:02.120 --> 08:05.680 We've got two keys. 08:05.680 --> 08:07.780 One key is used for encryption. 08:07.780 --> 08:10.400 The other key is used for decryption. 08:10.700 --> 08:14.740 And the keys are mathematically related. 08:14.800 --> 08:20.960 But, of course, knowledge of one key doesn't yield knowledge of another key. 08:20.960 --> 08:32.060 So, therefore, what we can do is we can keep one key a secret, but, you know, my own personal secret, my private key. 08:32.060 --> 08:35.200 And then the other key I can put out there for the rest of the world to use. 08:36.220 --> 08:44.020 Public key crypto generally used for authentication as well as non-repudiation and secret key exchange. 08:44.320 --> 08:49.760 For purposes of my work, all I really care about is message integrity and sender authentication. 08:49.760 --> 08:55.860 So we'll see a little bit more with hashes or something like that and a little bit more with public key crypto. 08:57.200 --> 09:04.100 So, again, hash functions and checksums, for that matter, cyclic redundancy checks, you know, do the same thing. 09:04.140 --> 09:11.580 Basically, these are just mathematical formulas that provide you with the digital fingerprint, if you will, of any sort of binary string. 09:11.580 --> 09:22.460 It can be a message, a file, a frame, frame in the terms of, you know, like a data link layer transmission, a message packet segment, whatever you whatever you want to call it. 09:22.460 --> 09:41.880 The cool part about hash functions and, again, checksums as well, is that a particularly sized checksum, like a CRC16 or an MD5, is going to give you the same size hash value or checksum value, regardless of the size of the input. 09:42.020 --> 09:45.500 So if you're using MD5, you're going to get a 128-bit output. 09:45.500 --> 09:48.700 Use a CRC16, you're going to get a 16-bit output. 09:49.610 --> 10:04.060 The value of your checksum or your hash makes it impossible to determine what was the length of the original message and certainly makes it impossible to figure out the contents of the original message. 10:04.060 --> 10:07.940 So that's, of course, why they always call these things one-way encryption. 10:08.840 --> 10:13.280 Now, public key crypto, of course, is a tad more complicated. 10:13.280 --> 10:19.240 But as I suggested before, I can keep one of the keys, my own closely held secret. 10:19.240 --> 10:21.000 So, again, that's my private key. 10:21.120 --> 10:23.460 The other key I can post anywhere I want. 10:23.460 --> 10:28.700 So, for example, on my website, I have posted my public GPG key. 10:28.960 --> 10:31.780 I also have it posted at multiple key servers. 10:32.630 --> 10:34.720 And so the idea is this. 10:34.720 --> 10:40.080 If I've got two parties to a communication, Alice and Bob, we always have Alice and Bob. 10:40.420 --> 10:52.520 If Alice uses Bob's public key to encrypt a message and send it to Bob, Bob presumably is the only one that can decrypt the message by using his own private key. 10:52.520 --> 10:56.240 So that's one way of having secure communication from Alice to Bob. 10:56.240 --> 11:06.280 Now, if Alice encrypts a message with her own private key, anybody who can get to her public key could decrypt it. 11:06.280 --> 11:11.200 But what that does is it proves that Alice is the only one who could have sent it. 11:11.680 --> 11:22.640 So , despite the little typo that I have here, that method can be used to authenticate Alice as the sender. 11:22.640 --> 11:29.240 And if you like pictures, I know these look like Lois and Clark, but that's supposed to be Alice and Bob. 11:29.240 --> 11:34.120 So, presumably, everybody has their own private keychain. 11:34.180 --> 11:37.360 And in their private keychain, they have their private keys. 11:37.560 --> 11:44.300 Now, they can also have a public keychain, and there may be a shared database of public keychains. 11:44.300 --> 11:47.160 And that's really the direction I want to go in. 11:47.260 --> 11:51.380 But again, this page sort of replicates what I said on the previous page. 11:51.380 --> 12:00.520 If Alice sends a message encrypted with her own private key, Bob can decrypt it using her public key, and he can get the public key from the database. 12:00.520 --> 12:02.980 And again, that authenticates Alice as the sender. 12:03.040 --> 12:13.580 If she wants to send a message to Bob, she can use that same database to get Bob's public key, send it to Bob, Bob's the only one who can decrypt it. 12:13.580 --> 12:17.940 And again, that's where I get my private... that's one way of getting privacy. 12:17.940 --> 12:25.360 Although, typically, we don't use public key cryptography for, you know, that kind of communication. 12:27.280 --> 12:31.160 Now, I told you all of that so I can tell you this. 12:31.160 --> 12:32.820 Here's my problem statement. 12:33.080 --> 12:38.060 AIS, as we've described before, has a number of security weaknesses. 12:38.160 --> 12:42.820 One of them is there's no geographic validity check for the sender. 12:43.560 --> 12:47.760 There is no timing check on when the message was sent. 12:47.940 --> 12:51.720 There's no authentication of who the sender actually was. 12:51.720 --> 12:54.840 And there's no message integrity check. 12:54.840 --> 13:01.500 So, in fact, there's no way to prove that the message that you received is the message that I sent. 13:01.600 --> 13:04.760 Now, there are a number of issues that this brings up. 13:04.900 --> 13:10.660 Obviously, I can spoof messages, make bogus vessels if I want. 13:10.660 --> 13:14.860 I showed an example yesterday of making virtual ATONs that were bogus. 13:14.860 --> 13:20.680 I can also send out false SOS messages via AIS. 13:20.680 --> 13:27.580 I can send out closest point of approach messages that are fake, fake weather reports, all that kind of stuff. 13:28.580 --> 13:35.580 So, this page is also another way of looking at this. 13:35.580 --> 13:47.800 This is all the message pathways from vessel to vessel or to AIS gateways, vessel traffic management, that kind of stuff. 13:47.800 --> 13:55.420 And the two hooded fellows there on the chart are supposed to represent bad guys. 13:55.420 --> 13:58.080 And this is merely showing different attack vectors. 13:58.480 --> 14:09.420 So, if you're attacking a vessel or, in some cases, some of the land shore facilities as well, you can do this via radio. 14:09.740 --> 14:17.960 In some cases, you can also attack the system using software-based threats just via the Internet. 14:18.640 --> 14:22.960 And actually, for my purposes, it doesn't really matter what your vector is. 14:26.720 --> 14:44.730 The National Marine Electronics Association, NMEA, is one of the organizations that standardizes what these messages look like and is certainly the go-to place internationally for connecting devices to each other on board vessels. 14:45.010 --> 14:52.550 A lot of the NMEA work has gone forward as an international organization for standardization ISO work. 14:52.550 --> 15:07.770 But in any case, the NMEA 0183 specification, which has been around now for about 35 years, is probably the most commonly used over the air because that's what the ITU is using. 15:08.230 --> 15:14.930 There is, of course, a significant embedded base of 183 equipment, particularly on large ships. 15:14.930 --> 15:22.830 And there are newer standards, NMEA 2000 and OneNet, which is coming out sometime this year. 15:23.050 --> 15:26.510 Right now, they're not used so much over the air. 15:26.510 --> 15:28.890 They're used within a vessel. 15:29.450 --> 15:40.570 And NMEA 2000 actually is used quite a lot on recreational vessels or personally owned vessels, much more than it is in the commercial world. 15:42.570 --> 15:53.610 Now, I told you all of that so I could show you... I want to show you what an AIS message actually looks like, because that's important to the protocol work that I did. 15:54.590 --> 15:57.570 And again, if I go back here to OpenCPN... 15:59.050 --> 16:02.150 So, oh, this is an interesting... there's Fishizzle again. 16:02.150 --> 16:08.790 I'm going to go right here because, unfortunately, it's a Class B, so it's not telling me my rate of turn. 16:08.790 --> 16:13.610 But you can see here, this is its course, 172. 16:13.610 --> 16:16.650 Its head... actually, I'm sorry, its course is 172. 16:16.650 --> 16:19.210 Its heading is 217 degrees. 16:19.670 --> 16:27.490 I mean, I would be very interested in knowing its rate of turn right now, particularly since it's been a couple minutes since we heard from them. 16:27.850 --> 16:34.890 But in any case, if I go up here and I show my NMEA debug window... 16:36.830 --> 16:40.990 I can see the messages that are coming out over the air. 16:45.290 --> 16:47.190 And actually, I normally can. 16:47.190 --> 16:49.410 I'm not sure why I am not now. 16:50.830 --> 16:54.490 Well, again, the hazards of doing a live demonstration. 16:55.030 --> 16:56.170 Okay, we'll come back. 16:56.170 --> 16:58.170 We'll have some data in here later, I hope. 16:58.170 --> 17:03.610 But in any case, this is what the messages look like. 17:03.610 --> 17:07.270 So let me try to interpret a little bit what you're looking at here. 17:07.710 --> 17:15.790 So a 0183 AIS sentence has, for purposes of my discussions, it has a header. 17:15.790 --> 17:18.750 And in the header, there is a prefix. 17:19.010 --> 17:23.350 There is an identifier of what type of device you are looking at. 17:23.350 --> 17:30.270 And then there's some sequencing information, if it's AIS, and a channel number, so you know what channel the transmission is on. 17:30.270 --> 17:31.990 Then you have the content. 17:31.990 --> 17:36.470 The content in AIS, it's called an encapsulated payload. 17:37.110 --> 17:39.010 And we'll talk a little bit about that. 17:39.010 --> 17:40.290 And then there's a trailer. 17:40.290 --> 17:47.670 And the trailer mainly has information telling me how many padding bits am I going to have to make sure that I have six bit alignment. 17:47.690 --> 17:53.670 And what is the checksum for this particular transmission? 17:53.670 --> 17:58.090 Not the message as a whole, but the individual transmission. 17:58.090 --> 18:02.790 And the padding bits and the checksum just covers the content area. 18:02.870 --> 18:09.790 So put another way, here is a standard AIS message. 18:09.790 --> 18:19.590 So, for example, the exclamation point at the beginning says this is an NMEA formatted message and it has special encapsulation. 18:19.590 --> 18:25.930 So, for example, if you look at a GPS message, GPS messages start, I think, with a dollar sign. 18:26.630 --> 18:32.430 That just indicates, yeah, this is an NMEA formatted message, but there's nothing special about the format. 18:32.430 --> 18:34.070 You can basically just read everything. 18:34.070 --> 18:36.650 You don't have to translate it to a different format. 18:37.370 --> 18:42.730 The next field, the AIVDM, identifies the talker ID. 18:42.730 --> 18:44.250 That's the device. 18:44.250 --> 18:46.890 In this case, AI means AIS. 18:47.110 --> 18:52.010 And then the encapsulation format is identified in the next three characters. 18:52.010 --> 18:53.590 That's the VDM. 18:53.590 --> 18:56.870 In this case, VDM stands for VHF data link message. 18:56.870 --> 19:00.090 That means it's a message coming from another source. 19:01.250 --> 19:07.310 Now, the transmission that I'm showing you here is referred to as a sentence. 19:07.890 --> 19:16.430 A message may be composed or will be composed of one or more sentences, usually never more than five sentences. 19:16.430 --> 19:25.910 But in any case, the first number here tells me how many sentences are required to fully compose this message. 19:25.910 --> 19:28.390 In this case, there's only one sentence. 19:28.650 --> 19:34.010 The next number is the sentence or the fragment number of the message. 19:34.010 --> 19:38.910 Now, in this case, there's only one sentence, so this is going to be sentence number one. 19:38.910 --> 19:46.310 But as you can imagine, if the number of sentences, say, were three, well, then I'm going to have a sentence number one, two, and three. 19:46.370 --> 19:50.290 But how do I reassemble that? 19:50.370 --> 19:58.610 Well, that's the next field, which is usually null when you only have a one-sentence message, but it's a serial number. 19:58.790 --> 20:01.590 So you could use pretty much any number you want here. 20:01.590 --> 20:04.430 This provides for the reassembly of the fragments. 20:04.430 --> 20:16.810 So if I had that message I just mentioned, you know, a three-sentence message, let's say it's got serial number seven, I would have something here that would be a 317-327-337. 20:17.330 --> 20:21.210 The next identifier is going to be an A or a B. 20:21.210 --> 20:25.330 It tells me which channel number, which frequency I'm using for AIS. 20:25.550 --> 20:27.570 Then I actually have the content. 20:27.770 --> 20:35.310 I'm not going to get into what the encapsulated payload looks like, but it's in something called Armored ASCII and everything's put into six-bit bytes. 20:36.870 --> 20:47.170 Then I have a number telling me what is the number of padding bits that I need to add to get six-bit alignment for my content. 20:47.490 --> 20:49.630 And then lastly, I have a checksum. 20:49.690 --> 20:52.170 The checksum is actually a pretty naive checksum. 20:52.170 --> 20:57.570 It basically is nothing more than an exclusive OR of everything in the content field. 20:59.710 --> 21:02.090 Now, I told you that so I can tell you this. 21:03.170 --> 21:13.770 Some of the tools that I've mentioned, one of the tools I have allows me to create any, pretty much, AIS message I want. 21:13.770 --> 21:15.290 I can create most messages. 21:15.290 --> 21:24.630 There are some message types I actually just have not built in yet, largely because they're not commonly used and largely because I just haven't added them yet. 21:24.630 --> 21:31.330 But if I go around here, so here's this menu program that I have. 21:31.750 --> 21:36.170 So, for example, let's say I want to create a type one message. 21:36.170 --> 21:40.930 A type one message, as you can see there, is a position report, class A position report. 21:40.930 --> 21:42.270 So there we go. 21:42.370 --> 21:44.270 It wants to know the talker ID. 21:44.310 --> 21:48.530 I can choose all sorts of different talker IDs. 21:49.230 --> 21:54.570 And in this case, I'm just going to accept the defaults because I want an AIVDM message. 21:55.230 --> 21:58.130 And then I need to have an MMSI. 21:58.130 --> 22:00.930 That's the Maritime Mobile Service Identifier. 22:01.310 --> 22:09.070 And actually, for purposes of what I'm doing, you can choose any nine digit number you want. 22:09.150 --> 22:13.570 For the protected part, you have to choose ones for which there are key pairs. 22:14.210 --> 22:25.590 And I'm just going to take all the defaults here, with the exception of when I get to my latitude and longitude. 22:25.950 --> 22:31.270 My latitude, I'm going to put it 29.1 because I wanted to match the example in the book. 22:31.590 --> 22:36.410 The longitude is minus eight zero, zero eight zero. 22:36.410 --> 22:38.630 This is actually off the coast of Daytona Beach. 22:38.630 --> 22:41.250 I'm not going to use protected mode for this. 22:41.770 --> 22:44.010 And I'm just going to let this go out channel A. 22:44.010 --> 22:46.090 And I get a message that looks like this. 22:46.250 --> 22:54.830 Now, what this allows me to do is I could then copy this and paste it as a command, and it will now create for me the message that I want. 22:54.850 --> 23:03.570 Now, you can actually batch all this together so that you don't have to, you know, do this all stepwise. 23:03.570 --> 23:12.350 But when I just ran that command, the PAIS underscore ping command, it then created, you know, the binary of the encapsulated payload. 23:12.350 --> 23:15.190 Anyway, that's what I'm showing here. 23:15.310 --> 23:17.610 So I ran that ping command. 23:17.610 --> 23:23.390 Then I ran the other command that gives me the encapsulated payload. 23:23.390 --> 23:30.770 And now I can run another program called AIS NMEA, and it now creates for me an AIS message. 23:30.770 --> 23:37.670 And so from here, I can either transmit this, I can put it into a file with some timestamps, and I can make things happen. 23:38.310 --> 23:54.750 Some of you, if you heard me talk yesterday and you saw that I created some virtual ATONs, well, basically what I did is I determined what's the latitude and longitude of where I wanted the ATON to be, what type of ATON did I want it to be, and I just created a bunch of these messages, 23:54.750 --> 23:59.230 put them in a file, and just sent it up to OpenCPN so that they would appear. 24:01.750 --> 24:05.610 Now, once I've created the message, I need to be able to parse it. 24:05.830 --> 24:12.070 So here, again, is the AIS message right there. 24:12.830 --> 24:23.730 And so this parser shows, basically, obviously parsing it, telling me what the talker ID is, verifying the checksum, and then, you know, showing me what all the contents were. 24:23.730 --> 24:28.430 And you'll notice the only contents of real interest, well, it's a message type one. 24:28.430 --> 24:30.710 That's the one we put in. 24:30.710 --> 24:32.770 There's the latitude and the longitude. 24:33.290 --> 24:38.470 And again, if you wanted, you could take that URL and, you know, look it up in Google Maps or something like that. 24:38.470 --> 24:42.310 But in any case, that's the tool that I have. 24:42.470 --> 24:45.210 Now, where I'm going with this is this. 24:45.210 --> 24:58.450 I could take that same message, I could go to a public AIS message parser, like I've done here at AGGsoft, put in the message, decode it, and it tells me all the stuff that's there. 24:58.650 --> 25:06.690 One thing I would like you to notice is it is telling me that it is showing all 26 of 26 entries. 25:07.870 --> 25:12.310 And this will be important later on when I talk about the backward compatibility stuff. 25:14.570 --> 25:19.790 Here, by the way, are the 27 different AIS message types. 25:20.750 --> 25:26.090 Like I said, my tools deal right now, I think, with 17 or 18 of these. 25:26.450 --> 25:31.550 But in any case, what I'm also showing you here is the length of the message. 25:32.470 --> 25:36.490 A lot of the messages are exactly 168 bits. 25:36.730 --> 25:40.410 Some of the messages are different sizes. 25:40.410 --> 25:42.430 Some are variable length. 25:42.990 --> 25:50.010 And anyway, I mention this because, again, this will be something that will come up a little bit later on. 25:52.270 --> 25:57.210 So here is what my demonstration and capability tool did. 25:57.210 --> 26:05.890 First thing, I decided that I can use crypto methods to deal with the problem of message bit integrity. 26:05.890 --> 26:09.050 Again, not just individual sentence integrity. 26:09.090 --> 26:17.130 If I've got a message that's 1,000 bits, well, a standard message can only be about 168 bits. 26:17.150 --> 26:22.490 So a 1,000-bit message is going to need multiple fragments, multiple sentences. 26:22.490 --> 26:31.250 The way the checksum works in NMEA right now is there's a checksum on each sentence, but there's no checksum on the message as a whole. 26:32.250 --> 26:35.790 There's no timing integrity, so I needed a timestamp. 26:35.790 --> 26:44.210 There's no validity and authentication of the sender, so this sounds like public-key cryptography is just screaming for that. 26:44.210 --> 26:46.850 But I also needed to have backward compatibility. 26:46.850 --> 26:53.090 I needed to have a method that I could apply, and it wouldn't screw up the system just by being used. 26:53.450 --> 26:56.070 So here is my proposed solution. 26:56.310 --> 26:59.250 I call this working in protected mode. 26:59.250 --> 27:02.290 So I'm a sender, and I have a message to send. 27:02.290 --> 27:15.250 What my equipment will do is it creates a 16-character what I call protect string, and the protect string comprises a timestamp and a checksum for the entire payload. 27:15.250 --> 27:30.850 That protect string is now encrypted with the sender's private key, and that protection string is now just appended to the normal content of an NMEA sentence. 27:31.030 --> 27:49.090 If you're a receiver and you're operating in protected mode, when you get a message and you detect that there is a protect string, what you do is the first thing is you know the MIMSY of the sender, so you can decrypt it with the sender's public key. 27:49.090 --> 27:52.750 That allows you then to recover the timestamp and the checksum. 27:52.750 --> 28:08.270 You now compute a checksum, make sure it matches the received checksum, and then you compare the timestamp to the current time to see, well, is this message arriving anywhere near in a reasonable time? 28:09.830 --> 28:23.490 Now, as far as public key cryptography is concerned, I decided to use the MIMSY as the key, and the reason being was MIMSYs are different from the IMO number of a vessel. 28:24.490 --> 28:28.010 IMO numbers are attached to a vessel. 28:28.170 --> 28:31.370 MIMSYs are pretty much attached to AIS equipment. 28:31.750 --> 28:48.730 And so my idea was, well, if each MIMSY has an assigned private-public key pair, then the AIS device keeps as a closely held secret its private key, and the public key we now have to make somehow available. 28:48.890 --> 28:50.810 And we'll talk about that later. 28:51.830 --> 28:56.050 So anyway, graphically, here again is the example. 28:56.050 --> 29:00.270 I've got my AIS device there on the left. 29:00.270 --> 29:04.510 It has some sort of certificate where it has its own private key. 29:04.510 --> 29:16.550 It has access to a public key database when it prepares its outgoing messages, just like it always has, if it's going to be using this so-called protect mode. 29:16.550 --> 29:21.790 It creates the protect string, encrypted again with the device's private key. 29:21.790 --> 29:25.050 It gets appended to the AIS message. 29:25.150 --> 29:30.570 And now it needs to get all of the time slots that it needs to send out the entire message. 29:30.710 --> 29:45.210 When it receives an incoming message and it detects the presence of a protect string, it can then, you know, again, it knows the MIMSY, go get the public key of the sender, and it can then decrypt everything. 29:46.070 --> 29:49.710 So my new sentence structure then looks like this. 29:49.770 --> 29:51.470 I still have a header. 29:51.750 --> 29:53.550 I have content. 29:54.210 --> 30:01.950 And if the message were small enough, actually, there would be a protect string, and then there would be trailer. 30:02.050 --> 30:09.030 I actually think I've misdrawn this picture, and I will actually redraw it before it gets out into the wild. 30:09.030 --> 30:11.210 The sentence structure doesn't change. 30:11.210 --> 30:13.870 The protect string gets added to the content. 30:13.870 --> 30:19.310 And if it requires more than one sentence, every sentence looks the same, header, content, trailer. 30:19.310 --> 30:22.450 But now the protect string is part of the content. 30:24.670 --> 30:26.790 So what does my protect string look like? 30:26.790 --> 30:28.470 Well, I mentioned it's a timestamp. 30:28.730 --> 30:30.530 I've got a four-digit year. 30:30.670 --> 30:34.910 I've been writing Y2K-compliant code since 1973. 30:35.250 --> 30:41.170 Anyway, I've got a four-digit year, month, day, hour, minute, second, all that kind of stuff. 30:41.170 --> 30:44.330 It should be clear that you need to have the year. 30:44.330 --> 30:51.310 If you don't have the year, if you only had month and day, somebody could do a replay attack one year later. 30:51.690 --> 30:55.790 And so, like I said, you need to have a complete timestamp. 30:56.870 --> 30:58.390 Then I have a checksum. 30:58.650 --> 31:05.870 Right now, I've only used an 8-bit exclusive or checksum because it's the same as that's used for the rest of the NME message. 31:05.870 --> 31:07.850 And I figured, well, you know, code reuse. 31:08.230 --> 31:10.530 It'd be trivial to put in a CRC8. 31:10.530 --> 31:12.090 I'll talk about that in a minute. 31:12.150 --> 31:21.290 Anyway, and then I use a 256-bit RSA key to encrypt the timestamp and checksum. 31:21.370 --> 31:27.410 Now, I need to slow down here for a second because there really is a reason that I chose this. 31:27.410 --> 31:40.510 I chose RSA because when I was looking at the various crypto libraries, the RSA library had a feature that I wasn't finding in any of the other libraries. 31:40.510 --> 31:44.030 And when we talk about the library in a minute, I'll tell you what that feature was. 31:44.030 --> 31:55.990 The second thing is when I use a 256-bit key, I generate a 258-bit encrypted string. 31:55.990 --> 32:06.850 And as you can see here from the slide, that generates a 26 to 154% protocol overhead, which is awful. 32:06.970 --> 32:20.070 But the first time I ran this, when I was doing my experiments and I had a standard RSA key, you know, two kilobits, four kilobits, I was generating a several thousand-bit encrypted string. 32:20.070 --> 32:29.590 Well, if 258 bits is 154% overhead, you can imagine what a, you know, 3000-bit encrypted string was. 32:29.610 --> 32:38.590 So I found the 256-bit key was the shortest length key that would encrypt the 16-byte protection string. 32:38.610 --> 32:43.710 If I used a 128-bit key, I could only encrypt a 5-byte string. 32:43.710 --> 32:49.410 And if I used a 512-bit key, I got a 540-bit protect string. 32:49.410 --> 33:02.010 So, again, you can see what I was trying to do here was trade off getting the protection of encryption, but at the same time not overwhelming the protocol with a ton of overhead. 33:03.550 --> 33:13.270 So the OpenSSL RSA Crypto library has the functions that are listed there that generate key functions, encrypt, decrypt, and all that kind of stuff. 33:13.270 --> 33:23.090 But when you use the encrypt function, it not defaulted, it meant you encrypted using the public key. 33:23.370 --> 33:26.830 And when you decrypted, you decrypted with the private key. 33:26.930 --> 33:31.890 If you wanted message authentication, you had to use the sign function. 33:32.190 --> 33:40.010 But a digital signature is huge because they add all sorts of other things that I didn't want to add. 33:40.010 --> 33:53.390 What I wanted was merely the feature of a signature that provided me authentication for the sender, but I didn't need everything and all the baggage that came with the signature. 33:53.390 --> 34:01.990 So the OpenSSL RSA library also has functions called private encrypt and public decrypt. 34:01.990 --> 34:12.850 So that allowed me to encrypt with my private key so that you could decrypt with my public key and now you would know that I was the real sender. 34:12.850 --> 34:22.070 So the only functions out of this Crypto library that I use are the generate key, so I can generate a public-private key pair, and private encrypt and public decrypt. 34:22.190 --> 34:27.570 Those were, no pun intended, those were the keys to making this all work. 34:28.430 --> 34:31.570 Anyway, so here's another example. 34:31.610 --> 34:38.930 This is the same message that we had before, but when I do the ping command, everything differents in red. 34:38.930 --> 34:44.510 So what I did is I added a switch called the protect switch. 34:44.510 --> 34:46.650 So this tells me we're in protected mode. 34:46.650 --> 34:57.570 So now what happens when I ran this program, or ran this particular message, it tells me that the payload is going to be appended with a timestamp and a checksum. 34:57.570 --> 35:04.450 So there's the timestamp and the checksum, and it's going to be encrypted with the private key associated with that particular MNSI. 35:04.730 --> 35:09.930 Now, if I go back here for a second, I always forget where I put these things. 35:09.950 --> 35:12.830 You'd think that after all this time I would know. 35:12.830 --> 35:15.550 I have my public and private key ring. 35:15.550 --> 35:20.950 So if I do an ls-la of my public key ring... 35:20.950 --> 35:28.650 So here are all the public keys that I have stored in my experimentation. 35:28.650 --> 35:30.050 I just needed numbers. 35:30.050 --> 35:38.130 And you can probably imagine that I have their private keys in a different key ring, and so there's the private keys. 35:38.130 --> 35:49.010 So in any case, when I run the program, that's why it's important that I use a key that I have my public and my private keys for. 35:49.010 --> 35:54.810 In any case, so now I run my next program that's going to create my binary string. 35:55.090 --> 36:02.910 If you were to go back to the other slide and do a comparison, everything here in black matches what was in example number one. 36:02.910 --> 36:05.150 Everything here in red has been appended. 36:05.710 --> 36:12.670 So now, when I create this message, it's now 426 bits. 36:12.670 --> 36:14.290 It's going to be using two fragments. 36:14.290 --> 36:16.310 I've decided to use serial number seven. 36:16.310 --> 36:17.870 I don't know why seven's so hot. 36:17.870 --> 36:22.770 But in any case, you can see down here, here are the two sentences that get generated. 36:24.250 --> 36:30.190 And when I parse it, again, I have now two sentences that need to be parsed. 36:30.190 --> 36:40.370 The first sentence now is sentence number one of two, and again has jazz that we didn't see before. 36:40.650 --> 36:42.570 The checksum, you know, works. 36:42.570 --> 36:43.510 That's good. 36:43.510 --> 36:52.090 And if I go down here, you'll notice that when I parse the message, everything in black is the exact same as it was before. 36:52.090 --> 36:54.270 But now we have some additional information. 36:54.270 --> 36:56.730 We've got the protected AIS information. 36:56.730 --> 36:58.670 So I know my sender is Mimsy. 36:58.670 --> 37:03.430 I know that it's authenticated because I compared it to the certificate that I have. 37:04.150 --> 37:05.630 There's the timestamp. 37:05.630 --> 37:07.890 I compare it to the received timestamp. 37:07.890 --> 37:13.950 Well, you can see it got there about six months later, but or at least six months later. 37:14.710 --> 37:15.890 Now, I guess I'm sorry. 37:15.890 --> 37:17.270 That's only about 10 days later. 37:17.270 --> 37:19.850 I have some examples that are even worse. 37:19.850 --> 37:27.290 I just set a threshold saying here's a I'll tell you how many seconds since the message was sent to when you received it. 37:27.530 --> 37:30.130 If it's over 30, I just say it's over 30. 37:30.130 --> 37:32.790 You could actually tune that, presumably. 37:33.450 --> 37:36.850 But in any case, and then I've got the checksum and it's verified. 37:36.930 --> 37:39.250 And again, that's the checksum over the entire message. 37:39.250 --> 37:42.230 So then I know the message hasn't been screwed with. 37:43.070 --> 37:54.270 When I take these two sentences and I poke them in to the AGGsoft decoder, you will notice I get the same AIS information I got before. 37:54.270 --> 38:03.990 And if you recall, the last time we saw this, I wanted you to pay attention to the fact that it was giving me one to 26 of 26 entries. 38:04.030 --> 38:06.650 That's what the software is telling me now as well. 38:06.650 --> 38:11.230 So basically, a Type 1 message is 168 bits. 38:11.250 --> 38:18.190 The AGGsoft software and OpenCPN as well will just say, oh, Type 1. 38:18.190 --> 38:20.150 Type 1 is 168 bits. 38:20.150 --> 38:21.410 That's all I'm looking at. 38:21.410 --> 38:24.310 And it ignored all the other bits. 38:24.330 --> 38:29.150 So this was a way of saying, OK, I can demonstrate I've got some backward compatibility. 38:31.110 --> 38:34.890 So what my little project was able to show was this. 38:34.890 --> 38:38.750 I can solve the message integrity problem using a checksum. 38:38.890 --> 38:41.770 I can solve timing integrity by using a timestamp. 38:41.770 --> 38:49.910 I can deal with validity and authentication because I have public key cryptography and I can use the sender's private key. 38:49.910 --> 39:00.210 I can get backward compatibility because it appears that what my experimentation so far is that software and devices will ignore any of the excess bits. 39:00.230 --> 39:03.410 Geographic integrity, I didn't even try to work on that. 39:03.410 --> 39:15.290 Because geographic integrity needs to say, you know, I'm a device telling you that I'm at latitude 29 north, 80 degrees longitude west or longitude 80 west. 39:15.290 --> 39:17.050 How do I prove that? 39:17.050 --> 39:20.230 And I need to have some other methods to do that. 39:21.350 --> 39:24.470 So obviously, the big problem is key distribution. 39:24.770 --> 39:29.210 This only works if you can figure out how to distribute your public and private key pairs. 39:29.670 --> 39:36.270 However, the method that I've described isn't dependent upon your key distribution method. 39:36.270 --> 39:38.970 It just observes, yeah, you probably need to have one. 39:40.090 --> 39:42.950 So the other nice thing is this. 39:42.950 --> 39:54.630 Let's say your device, and it's going to take you 10 seconds to figure out somebody else's or get access to their public key. 39:54.910 --> 40:03.710 The fact is, I can accept the message for what it's worth and display it, even though it's taking me 10 seconds to go figure out whether the message is valid or not. 40:03.710 --> 40:10.610 So, you know, in my ideal world, I see that you could have messages that you have authenticated, and they're in one color. 40:10.610 --> 40:20.930 You've got other messages that are being authenticated, they're in another color, and messages that cannot be authenticated, they're in third color. 40:21.610 --> 40:25.610 But in any case, there are a variety of ways of doing key distribution. 40:25.610 --> 40:34.710 We could use existing public key infrastructure methods, such as, you know, X.509 certificates that we use today with things like SSL. 40:34.750 --> 40:39.610 We could use a model, a distributed hierarchical database, such as the DNS. 40:39.650 --> 40:50.630 There are currently a billion hosts in the DNS, and yet we can get an IP address from a host name in, you know, milliseconds. 40:50.630 --> 40:54.670 Well, there's way less than a billion assigned MIMSIs. 40:54.790 --> 40:58.150 So maybe we could do some sort of database like that. 40:58.150 --> 41:03.390 And that probably is the way a lot of the literature suggests we could go. 41:03.930 --> 41:06.550 You could do something like PGP's Web of Trust. 41:06.550 --> 41:10.270 I will observe that a Web of Trust just isn't scalable. 41:10.270 --> 41:20.850 I mean, PGP Web of Trust is barely scalable between me and the other, you know, couple hundred people I know that use PGP. 41:21.230 --> 41:27.770 But it's certainly not going to be scalable to a very mobile industry, such as maritime. 41:28.650 --> 41:33.110 And I mentioned here, there's some other papers that have talked about a number of other things. 41:33.830 --> 41:42.470 And in terms of using public key crypto or using some sort of identity based crypto, there are all sorts of ways of doing this. 41:42.530 --> 41:47.190 Most are observing if they don't want to change the entire AIS protocol. 41:47.290 --> 41:53.210 We don't want to have a centralized certificate authority that doles it out to everybody. 41:53.210 --> 41:55.630 And you have to go back to that central CA. 41:55.650 --> 41:58.590 Most are talking about having some sort of hierarchy. 41:58.910 --> 42:01.390 So, for example, and I'm making this up. 42:01.390 --> 42:04.670 I haven't talked to anybody about this, certainly in a formal way. 42:04.670 --> 42:07.750 But let's say you use the MIMSI. 42:07.830 --> 42:11.190 Well, every country has its own maritime authority. 42:11.190 --> 42:15.350 And within the MIMSI, there is an identifier that identifies the country. 42:15.350 --> 42:17.970 So maybe every country has its own database. 42:18.210 --> 42:20.710 So I'm able to look at the MIMSI. 42:20.710 --> 42:22.610 I can figure out the country ID. 42:22.610 --> 42:24.030 I go to that country ID. 42:24.030 --> 42:26.610 It's been pre-programmed in where their database is. 42:26.610 --> 42:28.470 You know, all ships are connected to the Internet. 42:28.470 --> 42:29.890 So they could be able to do that. 42:29.890 --> 42:33.530 So anyway, like I said, I'm just sort of making that up as a possible example. 42:34.010 --> 42:36.870 There are still open issues with this. 42:37.410 --> 42:47.290 What I've described here certainly does not protect me against a bad actor who legitimately has an AIS device that can operate in protected mode. 42:48.450 --> 42:54.630 And it also doesn't stop anybody who's got a device from sending purposely false information. 42:54.690 --> 42:59.050 Now, presumably, they're only going to be able to do it once. 43:00.050 --> 43:05.310 Because, you know, once they've started to send bad information, everybody's on them. 43:05.590 --> 43:13.250 The other thing is backward compatibility means I'm willing to accept messages that can't be authenticated. 43:13.250 --> 43:18.350 Well, that means nothing stops a bad actor from just never being authenticated. 43:18.350 --> 43:32.970 But if you're differentiating between authenticated messages being authenticated and unauthenticated, so, you know, it puts the bad actor in the unauthenticated space. 43:33.390 --> 43:36.990 Anyway, any number of places to go for future research with this. 43:37.170 --> 43:40.530 Right now, like I said, I use a checksum that's a bitwise exclusive. 43:40.530 --> 43:42.590 Or I could use a CRC8. 43:42.590 --> 43:44.690 Hell, I could use a CRC16. 43:45.090 --> 43:46.590 Both would be better. 43:46.590 --> 43:53.150 Both would keep the protect string well within what a 128-bit key could manage. 43:53.270 --> 43:56.770 My current timestamp is 112 bits. 43:56.810 --> 44:04.010 I could use a Unix epic time and not human readable time if I wanted to make it smaller. 44:04.010 --> 44:13.970 It turns out if I make it smaller, it still doesn't make the protect string any smaller because I still have to use a 128-bit key. 44:13.970 --> 44:16.310 A 256-bit key, rather, sorry. 44:16.610 --> 44:20.590 I still end up with a 258-bit protected string. 44:22.010 --> 44:25.690 So, like I said, I could manipulate that, make it a little bit less human readable. 44:26.490 --> 44:28.310 Public sharing I'm doing. 44:28.310 --> 44:31.070 My public key sharing is done via a web of trust. 44:31.070 --> 44:36.670 I think at some really official level, you need something way more dynamic and distributed. 44:36.670 --> 44:39.470 But this is sort of where I ended doing my research. 44:39.570 --> 44:46.030 And I was able to get this to work with almost all message types that I support. 44:46.030 --> 44:52.270 I couldn't get it to work with message types that were hugely of variable length. 44:52.270 --> 45:02.870 Because the problem is one way in which you detect that you've got a protect string, like on a type one message, is you see I'm expecting 168 bits. 45:02.870 --> 45:11.290 Anything beyond that, I'm just going to assume is a protect string, particularly if it is whatever 168 plus 258 is. 45:11.290 --> 45:14.610 You know, if that's how long the message is, I've got a protect string. 45:14.610 --> 45:23.270 If I've got a variable length message, though, I don't know, well, was the message, you know, a thousand bits? 45:23.270 --> 45:28.750 Or was the message 650 bits and I've got another 350 bits of protect string out there? 45:28.750 --> 45:30.330 You know, you got the idea. 45:30.330 --> 45:35.490 Variable length was a little bit difficult, unless I could flag that I had a protected string attached. 45:35.490 --> 45:38.830 But there's no way within the current protocol to do that. 45:39.970 --> 45:45.770 So anyway, I've got some references for further reading, if people would like to furtherly read. 45:46.530 --> 45:49.390 And obviously, here's my contact information. 45:49.390 --> 45:54.890 I've not yet put this software up online, although I'm being incented. 45:54.890 --> 45:55.710 Well, not incented. 45:55.710 --> 45:58.550 I'm being encouraged to do so, and I probably will. 45:58.550 --> 46:09.550 One thing I do have to say, though, is that the tools that I currently have up on my website, I believe, are usable by people. 46:09.550 --> 46:14.330 If they can read my readme.txt file, they'll be usable. 46:14.590 --> 46:18.530 The protected AIS is not quite as ready for primetime. 46:18.530 --> 46:26.170 But if people want to play with it, like I said, I will put it up at one of the sites I've been talking to to read out about that. 46:26.170 --> 46:31.590 But if you want to ping me earlier, I'm at the point of not minding sharing them. 46:32.970 --> 46:39.990 In any case, that's pretty much what I had to say about that. 46:40.310 --> 46:44.070 And so let me come back around to here. 46:45.570 --> 46:49.790 And I've got, well, let's see, I've got a number of comments. 46:50.770 --> 46:53.930 Okay, they can see my desktop now. 46:54.270 --> 46:57.610 Let me see what readout's got here for me. 47:01.360 --> 47:05.480 Yeah, readout makes the point that I could have used elliptic curve. 47:07.480 --> 47:09.480 I'd have to look at elliptic curve. 47:09.480 --> 47:12.480 Again, the real... 47:12.480 --> 47:15.700 Again, I hesitate to use the word key here. 47:15.700 --> 47:27.140 The issue that I have is I need a library that will allow me to encrypt with a private key and decrypt with a public key. 47:27.380 --> 47:29.260 But other than that, absolutely. 47:29.260 --> 47:37.660 And I, you know, I will freely admit, though, I never got around to looking at the ECC libraries, because as soon as I found RSA, I got real excited. 47:37.660 --> 47:43.740 But clearly, ECC will give me the same level of protection with a far smaller key. 47:48.840 --> 47:51.960 And let me go back to here. 47:52.740 --> 47:56.940 And let's see. 47:57.100 --> 47:58.660 There's a message here somewhere. 47:58.660 --> 47:59.900 I just don't know where it is. 48:02.680 --> 48:07.480 Anyway, if there are other questions, absolutely let me know. 48:07.480 --> 48:09.200 I will have these slides. 48:09.400 --> 48:10.560 There are a couple of corrections. 48:10.560 --> 48:11.960 I'm embarrassed about this. 48:11.960 --> 48:17.600 Believe it or not, you probably will believe it, I was editing this slide deck up until about 15 minutes before the talk. 48:18.340 --> 48:21.640 So there are a couple errors that I found as I was going through. 48:21.640 --> 48:28.140 I will fix them and I will get these slides out and so that they get posted as soon as they can get posted. 48:50.450 --> 48:52.370 I'm hearing lots of beeps. 49:03.820 --> 49:07.600 Well, I've got another talk coming up in about five minutes. 49:10.300 --> 49:16.900 And so what I will do is, well, I'll hang out here for a couple minutes. 49:16.900 --> 49:18.840 They'll reset me in a few minutes. 49:18.900 --> 49:24.280 And I have a little like challenge problem that I want to share with people. 49:24.520 --> 49:27.240 It'll only take about 15 or 20 minutes to go through that. 49:27.240 --> 49:29.900 But otherwise, you know, thank you all very, very much. 49:29.900 --> 49:40.180 And like I said, ping me one way or another if you've got questions or comments and, you know, my pleasure to be here and thanks for listening to this. 57:32.820 --> 57:36.520 Okay, folks, I think we are back. 57:36.960 --> 57:40.560 Let me try once again sharing my screen. 57:46.100 --> 57:51.620 And once again, I'm going to live dangerously and show the whole thing. 57:53.160 --> 58:10.500 So when we were talking about ideas for talks and projects and things like that, one of the things that I just happened to mention and somebody said, well, this seems like it'd be an interesting, you know, little challenge type of project to do. 58:10.500 --> 58:15.700 And I'm going to talk to you about something called AIS point prediction. 58:16.160 --> 58:18.220 So so here's the general idea. 58:18.220 --> 58:22.660 And if I was better at drawing graphics, I could have drawn you some graphics. 58:22.760 --> 58:29.180 So I'm going to try going out here to OpenCPN to see what kind of things we got going out here. 58:29.700 --> 58:32.020 What I really need and I probably don't have. 58:32.020 --> 58:33.820 Well, actually, I probably do have. 58:33.820 --> 58:38.820 But you see these vessels out here. 58:39.660 --> 58:42.460 This vessel right here, the Janus, we know is a sailboat. 58:42.460 --> 58:44.560 It looks like it's about to come in Ponce Inlet. 58:44.840 --> 58:47.600 The Sea King, I don't know anything about the Sea King. 58:47.740 --> 58:48.900 It's also a Type B. 58:48.900 --> 58:50.540 That's too bad, but that's OK. 58:51.400 --> 59:03.060 On AIS messages, vessels that are by Code of Federal Regulations required to transmit, Class A type of vessels. 59:03.060 --> 59:09.960 So the really big ones have a lot of passengers, have a certain tonnage or horsepower. 59:09.980 --> 59:11.700 They're Class A. 59:11.720 --> 59:16.840 And a Class A is going to be telling me all the information that's down here. 59:16.840 --> 59:20.940 They'll be telling me a speed, course, heading and turn rate. 59:21.260 --> 59:27.080 They'll also be communicating relatively frequently. 59:27.440 --> 59:33.940 Class B vessels, the smaller ones, aren't required to transmit. 59:34.160 --> 59:40.660 And in fact, in a Class B position report, there's no way to even tell me about a turn rate. 59:40.660 --> 59:43.980 So the reason I'm telling you that is so that I can tell you this. 59:43.980 --> 59:53.040 My question is, and here's an example of Louisiana, which was just offshore pretty recently, a tanker, offshore Daytona. 59:53.040 --> 01:00:08.700 So if I know a ship's latitude, longitude, speed over ground, course over ground and turn rate, can I predict where they will be the next time they give me a position report? 01:00:09.440 --> 01:00:13.880 And in some ways, this sounds like a trivial exercise. 01:00:14.440 --> 01:00:16.460 I fooled around a little bit with it. 01:00:16.460 --> 01:00:17.320 Not a lot. 01:00:17.320 --> 01:00:19.920 It's a really interesting exercise. 01:00:21.660 --> 01:00:30.100 And the idea came to me some time ago, the idea being, you know, I'm at a particular place. 01:00:30.100 --> 01:00:36.320 And suppose a bad guy spooks their AIS latitude, longitude of a vessel. 01:00:36.320 --> 01:00:39.300 And they try to, let's say, knock Louisiana off the air. 01:00:39.300 --> 01:00:41.760 And now they spook, bing, Louisiana. 01:00:42.220 --> 01:00:51.080 Well, suppose their next position report puts me five miles away. 01:00:51.320 --> 01:00:56.420 Well, there's no way that I can move five miles in a minute. 01:00:56.420 --> 01:01:07.720 So my AIS receiver could maybe flash red to say, we just got something that just doesn't seem right. 01:01:08.640 --> 01:01:22.680 Now, the other thing, by the way, that this AIS message will tell us, this position message, this and other things, is you'll notice that this is also giving me the destination and ETA of when I plan on getting there. 01:01:22.680 --> 01:01:33.280 So this vessel, which I saw the other day, probably about four or five days ago, is expected tomorrow morning at seven in the morning UTC to be in Texas. 01:01:33.280 --> 01:01:37.580 So it must have, well, it must have been several days ago. 01:01:37.860 --> 01:01:41.120 Anyway, so where I'm going with this is this. 01:01:41.120 --> 01:01:46.680 Again, an AIS type one, two or three message is a class A position report. 01:01:46.760 --> 01:01:50.900 And the information that matters to me is it's going to give me a latitude. 01:01:51.580 --> 01:02:00.240 For those of you that are not familiar with the relationship between latitude, longitude and distance, it is vaguely as follows. 01:02:00.240 --> 01:02:03.860 One degree of latitude is 60 nautical miles. 01:02:03.860 --> 01:02:07.180 One minute of latitude is one nautical mile. 01:02:08.900 --> 01:02:17.720 Longitude is about, one degree of longitude is about 60 nautical miles at the equator, which is zero degrees latitude, of course. 01:02:17.720 --> 01:02:28.800 But for every other, any other latitude, a degree of longitude, the linear distance is going to be some function of the latitude. 01:02:29.220 --> 01:02:32.560 And think about a globe. 01:02:32.560 --> 01:02:40.080 And of course, as you get closer and closer to the North Pole, one degree of longitude gets to be almost nothing. 01:02:40.140 --> 01:02:44.940 Whereas one degree of longitude at the equator is 60 nautical miles. 01:02:44.940 --> 01:02:47.420 Anyway, I mentioned that later on. 01:02:47.880 --> 01:02:52.160 Then we're going to have the course in degrees, zero degrees being true north. 01:02:52.160 --> 01:02:56.780 And so an actual course will be somewhere between zero and 359. 01:02:56.920 --> 01:03:05.160 The speed in knots, a knot, of course, is a nautical mile per hour, which translates to about 1.15 miles per hour. 01:03:05.580 --> 01:03:10.840 I'm going to have a rate of turn, which is generally expressed in the number of degrees per minute, left or right. 01:03:10.840 --> 01:03:19.200 And the time between transmission is going to be a function of what is your speed and what is your rate of turn. 01:03:20.060 --> 01:03:22.400 And it turns out there's a standard for this. 01:03:22.400 --> 01:03:25.860 And if only the standard matched the reality, life would be a good thing. 01:03:26.280 --> 01:03:33.040 But here is actually an example and talks about some of the additional issues related to the problem. 01:03:33.340 --> 01:03:38.980 So I only care about the class A transponder types, although I'm showing you class Bs as well. 01:03:38.980 --> 01:03:45.760 So technically speaking, if you're a class A vessel and you're an anchor, you just need to transmit every three minutes. 01:03:45.920 --> 01:03:48.760 Now, you may be saying, but I'm an anchor. 01:03:48.760 --> 01:03:50.180 I'm not moving. 01:03:50.180 --> 01:03:58.320 Well, again, AIS class A devices, you might be talking about a vessel that is several hundred meters in length. 01:03:58.320 --> 01:04:18.540 If it's anchored or moored, the position of the bridge might be actually composing a circle that if that ship were to swing around its anchor in a 360 degree circle, you might be talking about a radius of many hundreds of meters. 01:04:18.540 --> 01:04:25.240 Well, a nautical mile is about 2,000 yards. 01:04:25.740 --> 01:04:31.860 So I might, like I said, I might have a pretty big swing radius. 01:04:31.860 --> 01:04:41.680 In any case, if I'm sailing, not sailing, obviously, but underway, between zero and 14 knots, I'm supposed to be transmitting every 10 seconds. 01:04:41.700 --> 01:04:50.700 If I am sailing at a speed of zero to 14 knots and changing course, I need to be transmitting every 3.33 seconds. 01:04:50.700 --> 01:04:54.360 So that's how you read the chart in terms of transmission rate. 01:04:54.440 --> 01:05:01.220 What I did is I then translated this and said, well, what's the maximum distance I can travel in that amount of time? 01:05:01.220 --> 01:05:09.920 Well, if I'm going 14 knots and I'm transmitting every 10 seconds, I'm only going to be traveling 77 yards. 01:05:09.920 --> 01:05:11.480 That's not very far. 01:05:11.780 --> 01:05:24.920 And you can sort of see as my, as I progressed here, what I was trying to give was an idea of exactly how far might I be going between transmissions. 01:05:25.580 --> 01:05:31.900 Now, I mentioned, I wish the reality were, you know, match the standard. 01:05:31.960 --> 01:05:36.920 Sometimes we will see vessels going by that are class A vessels and they're pretty big class A vessels. 01:05:36.920 --> 01:05:43.640 And like the Louisiana, the Louisiana was going at 15 knots. 01:05:43.640 --> 01:05:48.700 Well, at 15 knots, even in a straight line, they should be transmitting every six seconds. 01:05:48.720 --> 01:05:53.220 But we had like a minute, that slide that I showed. 01:05:53.220 --> 01:06:01.960 So in any case, you know, so the distance or rather the rate between transmissions is something else we need to take into account. 01:06:02.280 --> 01:06:06.780 So then I said, well, okay, I've got, I've got a ship here. 01:06:07.380 --> 01:06:08.960 That's supposed to be a ship. 01:06:08.960 --> 01:06:13.460 And it's at some latitude and longitude, which I'm calling lat zero and long zero. 01:06:13.500 --> 01:06:15.460 I know my course over ground. 01:06:15.480 --> 01:06:17.380 I know my rate of turn. 01:06:17.680 --> 01:06:21.840 And so the question is, all right, well, I've got a triangle in here. 01:06:21.840 --> 01:06:24.280 I've got some angle theta. 01:06:24.280 --> 01:06:28.980 Now, this may or may not be the right approach to go, by the way, but I've got some angle theta. 01:06:29.260 --> 01:06:37.900 And so at some T time later on, I've got my new latitude and longitude, lat one and long one. 01:06:38.260 --> 01:06:49.340 And so I will observe that I can figure out the radius of this circle because it's going to be related to the speed over ground and the rate of turn. 01:06:49.340 --> 01:06:57.920 I can figure out the distance that I've traveled, that circular distance, that arc, if you will. 01:06:57.920 --> 01:07:03.600 That's going to be somehow related to the velocity times the time between the transmissions, the actual time. 01:07:03.600 --> 01:07:06.940 And then I've got this delta x and delta y. 01:07:06.940 --> 01:07:15.920 Well, delta x is going to be a function of the angle of the circle, the speed over ground and the time, which as will my delta y. 01:07:15.920 --> 01:07:31.820 But then my actual change in latitude and longitude has got to be a function of the course plus theta, meaning that if I was just going due north or due anything, it'd be easy. 01:07:31.820 --> 01:07:46.880 But as we start to change off of zero degrees, we start to see, you know, some complications because, again, a degree of latitude is the same everywhere in terms of linear length. 01:07:46.880 --> 01:07:51.260 But the linear length of a degree of longitude is not going to be the same. 01:07:51.420 --> 01:07:56.540 So, like I said, we have, you know, that issue to deal with. 01:07:58.940 --> 01:08:12.600 So, again, my targets that I'm going for is if there's no rotation of the ship and the ship is moving in a straight line, well, that's almost easy to do. 01:08:13.220 --> 01:08:17.040 If the rate of turn is not zero, my ship is turning. 01:08:18.300 --> 01:08:31.300 And so then the other thing I was thinking of is not only can I, how well can I predict my next point, but, you know, we just had a tropical storm down here last week, went up the East Coast. 01:08:31.300 --> 01:08:38.320 And so we always look at the National Hurricane Center and they give us this cone of certainty for 01:09:11.940 --> 01:09:16.380 , so that if my next point is in the box, do I claim victory? 01:09:16.560 --> 01:09:23.600 And am I looking for, well, a really small box or how big will I let my box be? 01:09:23.600 --> 01:09:26.740 If I'm going in a straight line, they really are sort of boxes. 01:09:26.740 --> 01:09:33.120 If my rate of turn isn't zero, then the boxes actually become a cone. 01:09:33.120 --> 01:09:35.900 Am I anywhere in the right range at all? 01:09:37.200 --> 01:09:46.200 So, like I said, in terms of a problem, I was just thinking that this sounds like an interesting problem to tinker with. 01:09:46.460 --> 01:09:51.740 And, and there's all sorts of places to look at historical information. 01:09:51.740 --> 01:10:03.860 What you need to work on, though, if you get historical information, and I could even provide you some, is you need type one, type two, or type three position reports from the same vessel. 01:10:04.500 --> 01:10:09.440 And, and the type one, again, because you need rate of turn. 01:10:09.440 --> 01:10:15.360 Now, I mentioned something about the length of the degree of latitude and longitude. 01:10:15.420 --> 01:10:27.320 So, again, the length of the degree of latitude in meters, there's, there's a formula that I know is used at a number of the government sites. 01:10:27.320 --> 01:10:37.400 It was actually easy to find the formula because they have these pages where they have like a JavaScript and you can, you know, put in, you know, what your latitude is. 01:10:37.400 --> 01:10:40.340 It will tell you the length of a degree of latitude in meters. 01:10:40.340 --> 01:10:44.400 Well, of course, if you right click and look at the page source, you can see their formula. 01:10:44.400 --> 01:10:48.100 But it's been used a lot and I've seen it documented in a few places. 01:10:48.260 --> 01:10:56.380 In any case, the length of the degree of longitude, again, you will also notice is a function of the latitude. 01:10:57.100 --> 01:11:04.420 The length of the degree of latitude and longitude, here, here's, here's a table that I produced largely from those formulas. 01:11:04.420 --> 01:11:11.720 And you will notice that a degree of latitude, in terms of nautical miles, it almost doesn't matter where you are. 01:11:11.720 --> 01:11:16.860 It's about 60 miles, 60 nautical miles to a degree. 01:11:16.860 --> 01:11:23.280 If you look at a degree of longitude, the number of nautical miles, again, at the equator, it's about 60. 01:11:23.280 --> 01:11:36.320 And then as you go towards the poles, it increasingly gets smaller and smaller, and then rapidly gets smaller once you get above about, you know, 45 degrees, either north or south. 01:11:36.320 --> 01:11:38.800 And that actually, you know, makes sense. 01:11:38.800 --> 01:11:43.020 Until, of course, you get to the pole and then the degree of longitude is zero nautical miles. 01:11:45.000 --> 01:11:49.220 And again, I've given you some websites where they have more information about this. 01:11:49.400 --> 01:11:54.460 And that, more or less, was the challenge. 01:11:54.940 --> 01:11:59.020 And as I said, I think it's sort of an interesting problem. 01:12:00.100 --> 01:12:05.240 And for a few people, I don't know where we sort of go from there. 01:12:05.780 --> 01:12:11.720 I, like I said, I talked to Reid out about this, and I think he talked to a couple of other people. 01:12:11.720 --> 01:12:12.800 Interesting problem. 01:12:12.800 --> 01:12:19.860 I think what we're looking for is maybe to have some intermediaries, intermediate solutions at some point in the next year. 01:12:19.860 --> 01:12:25.360 Maybe revisit this at, have to see, 3.0 next year. 01:12:25.500 --> 01:12:29.300 And anyway, so that's where I am. 01:12:30.880 --> 01:12:33.380 So, questions, comments? 01:12:33.960 --> 01:12:35.900 Let me go back up here. 01:12:37.120 --> 01:12:37.720 I... 01:12:39.240 --> 01:12:43.120 I'm no longer at Hack the C village. 01:12:49.860 --> 01:12:53.040 So I'll sit here for a couple of minutes while we go into Q&A. 01:13:20.390 --> 01:13:23.090 Well, where I'm sitting is a lot of dead air. 01:13:23.810 --> 01:13:25.830 I'm going to hang out for another few minutes. 01:13:26.330 --> 01:13:29.290 Clearly, if anybody's got anything, let me know. 01:13:29.570 --> 01:13:35.110 And again, contact me by email or, you know, whatever seems to work. 01:13:37.150 --> 01:13:42.150 And, you know, let me know if you have questions and how we might, you know, go forward with this. 01:13:42.310 --> 01:13:47.210 And other than that, I thank everybody for attending whatever talks of mine you attended. 01:13:47.210 --> 01:13:48.010 I had a blast. 01:13:48.010 --> 01:13:49.090 Hope you had a blast. 01:13:49.090 --> 01:13:50.370 And go from there.