WEBVTT 00:04.920 --> 00:06.860 Hi, my name is Brandon Bailey. 00:06.860 --> 00:26.540 I work within the Cybersecurity Subdivision at the Airspace Corporation and we're excited to be here today in conjunction with the Space ISAC and the Airspace Village to be discussing the topic on some spacecraft research that we've been working on specifically related to exploitation of some of the implementations upon the spacecraft. 00:26.540 --> 00:28.440 So we'll jump right into it. 00:28.440 --> 00:37.800 I would like to refer people to the paper linked in the front for more information about how you can apply certain cybersecurity controls for a spacecraft. 00:37.800 --> 01:00.460 So from an introduction perspective, when you look at vulnerabilities in information systems, particular satellites, they're often overlooked in the wider discussions when you talk about critical infrastructure, but that's changing quite rapidly currently where there's a lot more people discussing spacecraft vulnerabilities, 01:00.460 --> 01:04.520 ground system vulnerabilities, and how it relates to our critical infrastructure as a country. 01:04.520 --> 01:18.600 So there's been a lot of misunderstanding and somewhat complacency in this regard because there's been a lack of real-life events that's known in the public space of attacks against space vehicles. 01:18.780 --> 01:22.840 But the space systems are similar to other systems. 01:23.200 --> 01:28.900 One that you would kind of know about is the industrial control systems or operational technology field. 01:28.900 --> 01:36.280 So you see some good parallels that can be drawn between the spacecraft and the space systems arena with that. 01:36.280 --> 01:52.880 So malicious insiders, external threats, splotching threats, those are all various threat factors that people can get in to affect spacecraft from the sensors to the data being uplinked or downlinked. 01:52.920 --> 02:03.720 So there's a lot of different areas where you could have impact that could disrupt military, government, or even commercial activity for our day-to-day activities. 02:03.880 --> 02:09.200 So the threats are changing quite rapidly in this arena. 02:09.200 --> 02:14.140 So there's a lot more knowledge about space and things of that nature. 02:14.780 --> 02:19.720 And then when they would have happened, there'd be an absence of warning. 02:19.720 --> 02:25.560 So you know there's not real-time consistent communication between ground and space a lot of times. 02:25.560 --> 02:29.920 So there could be times where you're not aware that there's attacks ongoing. 02:30.380 --> 02:34.980 And attribution is difficult in the IT world and it's even more difficult in the space world. 02:35.340 --> 02:38.340 And there definitely needs to be more research in this area. 02:38.340 --> 02:42.740 And that's one of the reasons why we're presenting this material. 02:42.740 --> 02:51.380 And I'm assuming one of the reasons why the Aerospace Village exists is because there's a lot more collaboration and research that needs to happen in this arena. 02:51.660 --> 02:55.620 And the CubeSat arena is just exploding as we all know. 02:55.640 --> 03:00.120 And the barrier to entry into space is being reduced quite extensively. 03:00.120 --> 03:12.220 So the good thing is in recent years there's been some open source technology that's been put out there that can help people learn more about space, space protocols, things like that. 03:12.220 --> 03:23.840 So Cosmos, which is linked here, NASA's CoreFlight executive or CoreFlight software, OpenSatKit was put out by NASA to help people get started with CubeSats. 03:24.560 --> 03:31.520 NOS3 was put out by NASA's Independent Verification and Validation Program to help people build simulators for space. 03:31.520 --> 03:34.680 So there's a lot of good open source material out there now. 03:34.680 --> 03:37.900 So people can actually start researching this for themselves, which is great. 03:38.300 --> 03:49.760 But I will caveat that with one thing is please change your default configs if you're pulling the CoreFlight executive or CoreFlight software from GitHub and running it accordingly. 03:49.760 --> 03:52.100 You want to make sure that you can change those default configs. 03:52.100 --> 03:55.580 So let's move on to some basics. 03:55.580 --> 04:07.240 So for people who aren't necessarily living and breathing space communications and commanding and telemetry and that terminology, here's just an introduction slide to kind of explain what we're talking about. 04:07.240 --> 04:14.580 Command and Data Handling or referred to as CDH is essentially how data is relayed to and from the spacecraft. 04:14.580 --> 04:19.280 So that's where the encoding and decoding happens for the commands and the telemetry. 04:19.900 --> 04:23.960 There's kind of generically four pieces of a space system. 04:23.960 --> 04:31.800 You have the user terminal where you do the commanding and the telemetry and process telemetry that runs the ground software. 04:31.800 --> 04:46.300 There's some sort of front-end processor that does the conversions of the information from the ground system to get it connected to a modem or an antenna that you can send the information to the spacecraft and get it back down. 04:46.480 --> 04:54.480 So from a cyber perspective, the attack surface is quite large because there's a lot of standard IT equipment in there. 04:54.480 --> 05:05.660 You know, like with the ground terminals, the front-end processors, there's a lot of operational technology, industrial control systems that operate within these facilities that run these systems or control the antennas. 05:05.660 --> 05:08.580 And of course the RF link is the obvious one. 05:09.260 --> 05:21.420 So something to note on this diagram is the bulk encryption component is kind of left out for people that are more accustomed to satellite communication where you have cryptos on each end. 05:21.420 --> 05:30.700 So I left that out just for ease, for simplicity, but sometimes you do have that bulk encryption there in the middle. 05:31.440 --> 05:50.420 And this is just a quick animation of kind of what this looks like where the user would say turn this heater on and then the software translates that to some, you know, hex numbers and then it gets converted by the front-end processor to get framed appropriately and sent to the modem to get modulated up to the bird and back down. 05:50.420 --> 05:55.520 So that's just a simple animation to kind of articulate what we're talking about here. 05:55.960 --> 06:17.160 And slide five here is something, a paper that was put out by NASIC, the National Air and Space Intelligence Center, which is a pretty good resource if you want to understand the high-level architecture of space systems and where cyber threats could have an impact and the types of cyber threats there are. 06:17.160 --> 06:34.950 So in this diagram it's basically just outlining that you have the user segment where you have the the ground software terminals and then the interacts with the ground segment where you have the antennas at times or in the link segment with the RF and the space segment for space. 06:34.950 --> 06:39.730 So vulnerabilities exist in all these segments and there's cyber threats within all these segments. 06:40.090 --> 06:58.930 Obviously, you know, the user segment is the highest likelihood for a cyber attack given that it may have some level of internet connection where it's operated by people and we understand as being a security researchers or pin testers or red teamers that the people are generally the weakest link in the cyber paradigm. 06:58.930 --> 07:03.470 So the user segment is one of the easier areas to get in. 07:03.470 --> 07:12.210 But we're going to focus more on the space segment and the link segment specifically because that's where there's less research and less publicized information. 07:12.210 --> 07:24.010 So we're going to focus on three types of attacks today with some demonstration screenshots and to discuss how they work, what they are, and how you can mitigate these things. 07:24.010 --> 07:34.670 So we're going to talk about a replay attack, which is where you record the command signal and replay it to the vehicle and see if it processes it. 07:34.670 --> 07:45.510 So we'll do that and we'll talk about command link intrusion where you basically simulate modulating your own signal to a satellite and seeing if it processes those commands. 07:45.510 --> 07:55.030 And then we'll do a denial of service where you could do some GPS jamming to maybe cause the denial of service condition on a satellite depending on the implementation for the satellite. 07:55.030 --> 08:02.410 So we'll jump in to the command replay first and discuss that attack vector. 08:02.410 --> 08:16.390 So in the real world, which is not what we're operating with this demonstration, we're operating within simulation, but in the real world you have your ground terminals antenna that sends a RF signal to a satellite. 08:16.390 --> 08:27.930 So in the real world, if you were to do a command replay attack, you would need some sort of sniffing device to sniff the RF signal from the ground antenna while it's transmitting the uplink to the satellite. 08:28.050 --> 08:39.690 Well, in our simulated world, because we're using some high fidelity simulation capabilities that have been built that we can use simply UDP gets translated from the antenna to the satellite. 08:39.690 --> 08:45.030 So we're not, you know, sending RF signals from a ground station to a simulated satellite. 08:45.030 --> 09:00.450 Although you could do that, but for our purposes, we're going to use a simulator that just essentially takes the TCP IP traffic from the front end processor and then it translates it to UDP and then sends it to a spacecraft simulator that's running. 09:00.650 --> 09:07.170 So if we're doing that with UDP, then we can obviously use something as simple as TCP for our research. 09:07.170 --> 09:09.590 So that's, that's, that's kind of how we're set up. 09:09.590 --> 09:16.250 So this is the simulator that we're using, and it's, it's got some real components to it. 09:16.930 --> 09:22.470 That's, you know, runs in operations today for various missions that are flying. 09:22.470 --> 09:36.310 So there's a ground software component, there's a front end processor, there's the ground station sim that is used to translate the information to UDP, and then that sends it to the spacecraft that has a dynamic simulator with it. 09:36.310 --> 09:41.510 So we're using real ground software in this simulation. 09:41.510 --> 09:43.770 We're using real front end processor software. 09:43.770 --> 09:44.810 None of these have been modified. 09:44.810 --> 09:48.990 They're using the same software baselines as operational missions are using. 09:48.990 --> 09:54.670 It uses the same communication protocols, CCSDS, TC and AOS. 09:55.050 --> 09:58.010 So you can google those if you want to learn more about it. 09:58.010 --> 10:00.270 We'll get a little bit more into that detail later. 10:00.570 --> 10:06.530 But we aren't using any type of encryption, so there's no point-to-point encryption or bulk encryption anywhere in this. 10:06.810 --> 10:12.610 And we'll explain why, because that's the point of the demonstration is to show when you don't have encryption what can happen. 10:13.690 --> 10:21.310 We have some real flight software that runs on several operational missions currently, but it's cross-compiled for Linux. 10:21.310 --> 10:28.210 So it's not running on an embedded processor, a power PC, or an arm, or some FPGA. 10:28.370 --> 10:38.070 It's running just in Linux for our purposes, because we're just focused on the software testing at this point and not being too high fidelity. 10:38.070 --> 10:44.010 But there are technologies that exist where you can get super high fidelity, and we've used those in the past for several things. 10:44.590 --> 10:49.970 Things like Simix, or QEMU, or TCM. 10:49.970 --> 10:58.530 These are different technologies that you can use to have higher fidelity simulations to run software compiled for target. 10:58.530 --> 11:01.310 So those can be integrated in these simulators as well. 11:01.310 --> 11:08.190 So the ground station sim is kind of what mimics the RF transmission for us, but for us it just translates to UDP as I said earlier. 11:08.190 --> 11:17.470 So there's a simulation that's out there called 42 that's put out by NASA that helps do the attitudes, orbit dynamics, and environmental models. 11:17.470 --> 11:22.210 So that helps us understand the orbit and how we're progressing there. 11:22.210 --> 11:23.850 So here we go. 11:24.470 --> 11:28.610 And you can build your own one of these with some sources from GitHub. 11:28.610 --> 11:36.370 So these are linked here, OpenSATKit and NOS3 have some great components that you can construct something similar for yourself. 11:37.010 --> 11:48.970 Okay, so for our specific demonstration for command replay, our satellite in this scenario orbits the earth and is scheduled to uplink, downlink when it's over top of three different ground sites. 11:48.970 --> 11:51.950 One in California, one in Spain, one in Australia. 11:51.950 --> 11:58.710 So one would be Australia's in Canberra, Spain, Madrid, California, out near LA. 11:58.710 --> 12:07.090 So the point of our demonstration is we're going to capture the UDP traffic with TCP dump as it's leaving the ground station during the uplink pass. 12:07.090 --> 12:11.010 So this mimics an RF sniffing capture. 12:11.010 --> 12:13.410 And then we're going to replay that with TCP replay. 12:13.410 --> 12:25.790 So we did a quick, you know, Google search on the internet looking for what type of hardware and technologies needed to reproduce this type of an attack in real life. 12:25.810 --> 12:34.710 And basically it's around $7,000 and you could get some equipment that could record, capture, and transmit signal to a lower orbit. 12:34.710 --> 12:39.390 So it's definitely achievable for, you know, people who have a little bit of money. 12:39.390 --> 12:45.930 But then with the advent of some of these new technologies that are coming out today, like AWS Ground Station, the barrier could be much lower. 12:45.930 --> 12:57.150 So you may not need so much equipment, you may need sniffing capabilities, but we're a little unsure on what practices are going to be in place for AWS in the future. 12:57.210 --> 12:59.470 So to prevent, you know, these type of things from happening. 12:59.470 --> 13:11.290 But with that being said, it's just trying to articulate that the barrier for doing, you know, communications to a vehicle is getting less and less. 13:11.470 --> 13:14.230 Okay, so setting up the attack. 13:14.230 --> 13:21.210 So in our simulation, the satellite is visible to the ground station over the Madrid ground station. 13:21.210 --> 13:22.430 So it's there. 13:22.430 --> 13:30.070 And then in the bottom middle here, you see a signal lock in that window, it says, okay, it's locked, it's acquired. 13:30.070 --> 13:33.210 So it's sending the connect message, and then it's uplinking the command. 13:33.210 --> 13:36.430 So you see several commands being transmitted. 13:36.750 --> 13:38.230 You know, that's a bunch of numbers there. 13:38.230 --> 13:44.090 But what that does is you look in the far right, you see the flight software that's running. 13:44.090 --> 13:50.730 That's the, you know, that's kind of like the UART window of a flight software, where you have the flight software responding. 13:50.890 --> 13:53.030 You see it processes these NOOP commands. 13:53.030 --> 14:01.250 So in this example, we just hit some simple NOOP commands, which is kind of like a ping, you know, in our terminology. 14:01.250 --> 14:05.050 So just to see if the application running on board is alive. 14:05.430 --> 14:12.290 So upon receiving that command, the flight software indeed does process that command and downloads the event messages, and the command counters increment. 14:12.290 --> 14:17.270 So you see here in the ground, you see that the event messages are processed. 14:17.270 --> 14:20.870 It says, hey, there was a NOOP command, and it's downlinked to the ground. 14:20.870 --> 14:23.890 And then you see the command counters increment accordingly. 14:23.890 --> 14:34.050 So you see that the CMDPC, which is short for command processed, for each of those applications that were sent commands processed to increment to one was zero. 14:34.050 --> 14:35.170 So it goes to one. 14:35.570 --> 14:41.970 Now the satellite in our scenario is in transit between Madrid and Canberra. 14:42.130 --> 14:45.550 And you see in the ground station simulation that it's lost signal. 14:45.550 --> 14:47.530 So it's no longer in view. 14:47.530 --> 14:50.930 So now here's where we could actually do our replay attack. 14:50.930 --> 14:57.330 So in a real world scenario, you would need equipment, obviously, in the Madrid area to capture the RF traffic. 14:57.330 --> 15:05.590 And then somewhere over India, in this example, you would need transmit capability to be able to send transmit the information to the satellite. 15:05.810 --> 15:11.050 So in our scenario, it's a lot easier, obviously, because we're using just the TCP replay. 15:11.050 --> 15:13.250 And here's just a simple command. 15:13.250 --> 15:16.850 It replays the PCAP file that was captured. 15:16.850 --> 15:23.850 And then you see the flight software respond accordingly with the same event messages within the UART. 15:24.010 --> 15:31.730 But what you don't see is any event messages on the ground station because you were in between passes at that point. 15:31.730 --> 15:39.430 And the command counters, you notice when you establish the downlink again over Canberra that the command counters went up. 15:39.430 --> 15:48.190 So the flight software is reporting, hey, I received another command and, you know, in between ground passes, which would be odd. 15:48.190 --> 16:06.990 So from a, you know, defensive cyber operations perspective on the ground or, you know, C&D perspective, if you're not monitoring certain key telemetry points on your vehicle, you may not be aware that, you know, someone has tried to make a connection or send commands. 16:06.990 --> 16:17.590 So it's very important to understand what the telemetry values are that you could be monitoring that could provide you insight into potential attack vectors. 16:17.590 --> 16:21.690 So there's a lot of telemetry points out there that could help with that. 16:21.770 --> 16:24.430 So that wraps up the command replay. 16:24.430 --> 16:32.850 So essentially what we did was capture the command link up and then we replayed it and we saw that it processes. 16:32.850 --> 16:38.150 So we'll move on to command link intrusion, which is a little bit different. 16:38.150 --> 16:43.790 It's a slight different take on a command command link attack. 16:43.930 --> 17:01.190 So since there's no encryption in our environment, our simulated environment here, and there's no authentication, theoretically, the thought was, well, if you just inspect the traffic and understand the packet structure and understand what information is in there, 17:01.190 --> 17:06.970 theoretically, you could craft your own packet that matches that structure and just send it up and see if it processes the command. 17:06.970 --> 17:08.190 So you're not really replaying anything. 17:08.190 --> 17:14.830 You're just constructing your own raw command packet and then uplinking it and seeing what happens. 17:14.970 --> 17:17.250 So let's try that out and see how it works. 17:17.750 --> 17:27.850 So once you've inspected the traffic and understand there's no encryption, you see in one of the telemetry values, and you can obviously do this with RF as well. 17:27.850 --> 17:31.270 You can record the RF on the downlink and record it as well. 17:31.270 --> 17:40.910 But you see, once you have the information and you see here in the middle, you see CFE, TBL, NOOP, CFE version 6.6.0.0. 17:40.910 --> 17:49.930 So you see that information there and that implies that they're using CoreFlight executive or CoreFlight software. 17:50.170 --> 17:53.950 And so then you can say, well, that's available on GitHub, I believe. 17:53.950 --> 17:59.210 So this is where that comment about default configs really comes into play. 17:59.210 --> 18:06.150 So you go look on GitHub and you understand that CFE CFS uses the CCSDS protocol. 18:06.150 --> 18:13.790 So then you get into this research study on command packet structures, which is a fun study. 18:13.790 --> 18:21.430 I would not recommend it for people if they're not really interested in it because it's a little bit of a read. 18:21.750 --> 18:28.090 So we're looking, we start to break down how these systems work from a protocol perspective. 18:28.090 --> 18:35.010 So we have space packets and then we're gonna get into some really space buzzword bingo here. 18:35.010 --> 18:36.410 So I apologize for that. 18:36.410 --> 18:40.690 But for the people who know what this is, you'll get it. 18:40.690 --> 18:53.970 But for the people who don't know, forgive me for kind of speaking in this lingo, but the space packets get wrapped in these transfer frames and then the transfer frames are wrapped in what's called these command link transmission units, CLTUs. 18:53.970 --> 19:01.630 So that's kind of how this structure works is CLTU, transfer frame headers, space packet, and then the trailers. 19:01.630 --> 19:09.050 So then we start looking in the CCSDS protocol and we understand, okay, this is the space packet. 19:09.050 --> 19:11.130 These are the octets that are there. 19:11.130 --> 19:17.950 And then we start really diving into some of these documents and we say, okay, well, this is what the primary header is. 19:17.950 --> 19:19.810 This is what a transfer frame looks like. 19:19.810 --> 19:22.630 This is what the transfer frame primary header looks like. 19:22.630 --> 19:24.510 This is what the CLTU looks like. 19:24.510 --> 19:31.250 And then so we're kind of in this overload of terminology, protocol breakdown, things like that. 19:31.250 --> 19:37.170 So it gets a little cumbersome and confusing, but it's important to understand all these things. 19:37.170 --> 19:41.470 And it's also important to realize that these protocols are open source protocols. 19:41.470 --> 20:00.710 So a lot of the, a lot of missions, spacecraft that are out there today, leverage CCSDS because that is an international standard that the CCSDS group is a consortium of many space agencies from across the world who get together and standardize on protocols and things like that. 20:00.710 --> 20:02.770 So it's easy. 20:02.770 --> 20:09.650 You just kind of, you can just Google the standards and find them and they'll have these diagrams in there and you can break down, you know, the bit patterns and things. 20:10.190 --> 20:17.730 So from our transmission, since there's no encryption on that, you just basically have the raw number structure. 20:17.810 --> 20:34.730 And to the, to the kind of uninformed, this looks just like a bunch of gibberish, but what we're going to do is take the knowledge we gained from reading the hundreds and hundreds of pages of those CCSDS protocols and see what we can find out. 20:34.730 --> 20:36.170 So let's look here. 20:36.170 --> 20:41.690 We see the, the fives in our scenario is the acquisition sequence. 20:42.030 --> 20:45.530 And then we've determined where the CLTU is. 20:45.870 --> 20:47.950 So we've now, we've got the CLTU. 20:47.950 --> 20:49.830 So let's break that down and see what we can get. 20:49.830 --> 20:53.130 So then we take off the headers and trailers in this example. 20:53.130 --> 21:02.790 And then now we have this subset, and then we have this code blocks and these check bytes, and we take those out. 21:02.810 --> 21:10.690 So now we've identified the actual TC transfer frame, which is, which is where the, the command information is stored on, on the uplink. 21:10.690 --> 21:12.350 So now we've got that. 21:12.350 --> 21:14.630 So let's take out the header on that. 21:14.630 --> 21:16.850 And now we have the command packet. 21:16.850 --> 21:19.350 So this is the one that we were looking for. 21:19.350 --> 21:23.030 So with all those numbers, this is really what we were looking for. 21:23.030 --> 21:29.410 We're looking for this command packet, because it's going to tell us hopefully what kind of command was sent up on that uplink. 21:30.010 --> 21:36.030 So from that, from the telemetry stream, we've kind of discussed, we see this no op command that came down. 21:36.030 --> 21:50.150 So we've, we look on the GitHub repo, and we've realized that in our example, that the spacecraft that's we're looking at seems to be using these default command and telemetry IDs. 21:50.150 --> 22:00.130 So because if you look at the, the header file for the message IDs, for the CFE table, command message ID, you see 1804. 22:00.190 --> 22:09.210 So that would indicate like the high likelihood of actually the software's using these default message ID types. 22:09.210 --> 22:19.850 So what that does is allow you to basically transmit information to the, you're going to try to transmit information using this knowledge you've gained to the simulated spacecraft to see kind of what will happen. 22:19.850 --> 22:26.050 So let's see if we can, we can reconstruct a packet with this knowledge and see what we can do with it. 22:26.350 --> 22:29.730 So with this knowledge, let's play around a little bit and see what we can do. 22:29.730 --> 22:40.530 So we've got our knowledge of the command structure from GitHub, and since we can't construct a new command, maybe something else to see what happens, just to see if the command, the spacecraft will actually process it. 22:40.850 --> 22:47.670 So you have to do a little digging and understand the functionality of this software, but luckily all that information is open source. 22:47.670 --> 22:57.010 So once you dig in a little bit, you see, you notice there's this functionality within the CoreFlight software called ES. 22:57.010 --> 23:02.690 It's an ES application where you can potentially, you know, have control over the applications on board. 23:02.690 --> 23:08.010 So we're going to see if we can reconstruct a packet to do a reboot of a particular application. 23:08.010 --> 23:14.510 So in the real world, you know, you would have to reverse engineer the packet structure of the RF signal. 23:14.510 --> 23:22.490 But in our scenario, we're going to transmit the UDP packet with the following information and see if we can get a reset of one of the applications. 23:22.490 --> 23:30.030 So we use that 1806 because that's the default message ID for the ES application. 23:30.030 --> 23:38.350 So that tells the flight software, hey, this command is meant for the ES application to process once it gets on the satellite. 23:38.730 --> 23:54.010 And then the rest of the numbers is just, you know, understanding the... translating the command and telemetry database into this format, which I won't bore you with all the details that had to happen for that to occur, but you can get there, essentially. 23:54.110 --> 23:59.830 It just takes a while to figure out what the structure is and what numbers need to go where and what those values need to be. 23:59.830 --> 24:04.030 So let's send this raw packet up and see what we can do. 24:04.370 --> 24:09.290 So we send that raw packet up to the satellite and look at that. 24:09.290 --> 24:15.550 So we see in the UR of the actual flight software that we have some sort of response. 24:15.750 --> 24:22.230 So you see at the top of the window, you see CFE ES restart app initiated for HK. 24:22.230 --> 24:24.130 So it looks like it was successful. 24:24.130 --> 24:37.230 So we essentially have reconstructed our own packet based on information that we've gained from GitHub and then transmitted it to our spacecraft simulator and it indeed did process it. 24:37.230 --> 24:46.350 So that's an example of, you know, a command-link intrusion where you've basically put your own command structure and sent it up and got it to process. 24:46.350 --> 24:48.150 So that's kind of the response. 24:48.150 --> 24:52.990 So the question is like, okay, why does the replay attack work? 24:52.990 --> 24:55.770 Why does this command-link intrusion attack work? 24:55.950 --> 25:03.270 So part of it's the open sourceness of the information out there so you can pull that data from GitHub and do your own research. 25:03.270 --> 25:07.170 But it really gets down to the protocols and some of the protections. 25:07.170 --> 25:19.110 So in this example, there's a communications operational procedure that typically runs on a satellite, at least ones that operate CCSDS called COP1. 25:19.250 --> 25:27.310 And that helps with sequencing to make sure that the sequence of the commands and the packets received are proper. 25:27.410 --> 25:38.130 On our example, COP1 wasn't turned on by design in our example, but there's a lot of actual spacecraft who don't leverage COP1 for various reasons. 25:38.130 --> 25:46.270 So COP1 would have provided some level of protection, but that can be fudged and gotten around if you know what you're doing. 25:46.310 --> 25:56.290 So in example, I redid the same example for replay with COP1 enabled, and you see here that the command is not processed because they were out of sequence. 25:56.490 --> 26:05.250 So I could have really fudged the data around with sequencing and probably got the process, but we didn't really want to get into that. 26:05.250 --> 26:12.790 But the point was just to articulate that there are sequencing protections that you can put in to help with the replay. 26:12.950 --> 26:18.890 But the real control that you want is encryption and authentication. 26:18.890 --> 26:23.910 So you really need to encrypt and authenticate the command link. 26:23.910 --> 26:33.670 So it's not enough to just do encryption because you theoretically could just replay an encrypted link and it would process accordingly. 26:33.670 --> 26:36.470 So you need the authentication on the command link as well. 26:36.470 --> 26:37.150 So that's important. 26:37.150 --> 26:38.570 So you need both. 26:38.630 --> 26:50.690 So to properly protect from a replay or an intrusion attack, like here are some just guidelines for pseudo requirements, sample requirements about cryptography and authentication. 26:50.690 --> 26:57.130 So you need to authenticate and you need to do cryptography to ensure that these attacks won't work. 26:57.630 --> 27:02.910 Okay, so now we're going to jump into denial of service via GPS jamming. 27:02.910 --> 27:07.190 So the first two were particularly to the command link. 27:07.190 --> 27:10.690 So those were intrusion and replay. 27:10.690 --> 27:23.650 This one's a little bit different and it's going to use a different simulator, but we won't get into the specifics on the sim, but it's a high fidelity simulator that has a lot of dynamics and a lot of command and data handling and GNC capabilities. 27:23.690 --> 27:41.230 So what we're going to do is get the vehicle in an operational state where it's doing a mission operations, and then we're going to simulate the denial of service with GPS signal, which is basically cut off the GPS, and then we're going to see how the system responds. 27:41.870 --> 27:51.090 So jamming, for those who aren't necessarily aware, is the intentional or sometimes unintentional interference of the signal that prevents it from being received. 27:51.090 --> 27:53.430 So it's relatively simple to do. 27:54.550 --> 28:03.050 It's easy to overpower at close range and jammers can be on the ground, it could be in the ocean, airspace, jammers can be about anywhere. 28:03.150 --> 28:22.110 So in our scenario, the spacecraft simulator is set up to be in what's called mission science mode or operational mode, and once it reaches this mode, we're going to simulate the GPS signal by stopping the flow on the space wire bus, which is where the GPS sends its data to the Singapore computer, 28:22.110 --> 28:23.110 the flight software. 28:23.510 --> 28:33.170 So here is just a graphical representation of some of the telemetry and dynamics data for this particular sim as it's operating. 28:33.470 --> 28:46.230 And we are, you know, it shows, you see the attitude control mode previous to attitude control mode current, which is MSM, which is the mission science, which is the operations mode. 28:46.690 --> 28:56.550 So what we're going to do here is we're going to block that data from getting to the Singapore computer, the flight software from the GPS sensors, and we're going to see what happens. 28:56.550 --> 29:01.070 So in the middle here, you see the GPS data packet counts increasing. 29:01.070 --> 29:03.990 So you see it go from 920 to 944. 29:03.990 --> 29:05.170 So everything's optimal here. 29:05.170 --> 29:12.310 We're operating, we're flying in orbit, GPS signal is being processed, and everything is fine. 29:12.310 --> 29:26.490 So here, now we're going to, in our simulation, we're going to basically leverage a capability that was built into the simulator to block data across the Spacewire bus based on whichever values we want. 29:26.490 --> 29:34.670 So we can block about anything that's flowing across the Spacewire bus, or 5053 bus for that matter, and see what happens. 29:34.670 --> 29:40.130 So once you initiate this block sequence, you see the ground telemetry values freeze. 29:40.130 --> 29:43.290 So you see, which indicates the gray background there. 29:43.290 --> 29:48.550 So at this, the ground station is reporting, hey, I don't, I'm not receiving GPS data anymore. 29:48.550 --> 29:51.030 For some reason, it's not being downlinked. 29:51.030 --> 29:54.650 And that's because it's not being actually provided to the Singapore computer for downlink. 29:54.650 --> 29:56.570 So you see that freeze. 29:57.190 --> 30:10.930 So, and you know, for spacecraft, you know, one thing to understand is, you know, you can't, you can't go up there, you can't like a, obviously a real computer, go, you know, hit the reset button. 30:11.290 --> 30:16.350 There's a lot of autonomy built in, there's a lot of fault management, and a lot of testing goes around fault management response. 30:16.610 --> 30:31.930 So what you should know is like, typically, when you have a satellite in orbit, and some anomalous thing happens, the last-ditch effort to save it basically is to go into what's called a sun pointer safe mode. 30:31.930 --> 30:41.890 So it basically takes the solar arrays and points it to the sun and says, I'm just going to hang out here until I hear from the people who control me in the ground station. 30:42.330 --> 30:48.030 So what we're going to do here is see what the autonomous flight response is once the GPS signal is blocked. 30:48.590 --> 30:54.310 So safe mode is an operational mode, where a lot of non-essential systems are shut down. 30:54.310 --> 31:03.810 It's very similar to Windows, you know, when Windows goes in safe mode, it shuts off a lot of the features of Windows from that perspective. 31:03.810 --> 31:07.230 So preservation of the spacecraft is the highest priority. 31:07.230 --> 31:16.310 So here you see in the downlink telemetry, the flight software is starting to do its autonomous fault management. 31:16.310 --> 31:21.570 It's running what are called RTSs, so relative time sequences. 31:21.570 --> 31:25.110 So these are things, these are just automated flight responses that are there. 31:25.210 --> 31:34.750 And it's starting to do various things, it's doing movements, it's stopping antennas, it's transitioning to some point mode from an attitude control perspective. 31:34.750 --> 31:36.590 So it's starting to safe itself. 31:37.030 --> 31:43.670 And in the telemetry you see from the attitude control mode perspective, it's reached its desired some point state at this point. 31:44.010 --> 31:50.510 So why would you perform a denial service, you know, like GPS jamming on something? 31:50.510 --> 31:59.110 So, you know, maybe you're just wanting to have a little fun, maybe you're just trying to disrupt and degrade some sort of mission operations for a specific time. 31:59.350 --> 32:02.610 Maybe you're wanting a mission to not achieve any objectives. 32:02.610 --> 32:04.810 But what if you're a little bit smarter than that? 32:05.290 --> 32:10.990 And you understand the autonomous fault response for satellites, and you understand the design and fault management a little bit more. 32:10.990 --> 32:20.330 So a more strategic, you know, attacker understands that there's a lot of autonomous fault response for a mission to put itself in a really safe state. 32:20.510 --> 32:26.610 So if you just think about the safe mode for Windows, you know, a lot of the security features get disabled while you're in safe mode. 32:27.270 --> 32:29.650 Similar things do happen for spacecraft. 32:29.650 --> 32:36.030 So forcing a spacecraft into safe mode could potentially open up additional vectors that aren't there. 32:36.030 --> 32:51.770 So think about a, you know, maybe if you've jammed the GPS signal, maybe your fault management response is to save yourself, turn off cryptography, you know, and open up your command link for any signal that you can process. 32:51.770 --> 32:54.410 Just depends on the fault management response. 32:54.530 --> 32:56.590 That's a design decision. 32:56.730 --> 33:07.390 But just think about that as you're doing your design that you may not think through, like, hey, maybe adversaries may know that I can be more vulnerable, get put in a more vulnerable state. 33:07.390 --> 33:17.670 So maybe I need to design in something, you know, the terminology that we put in the paper that was linked in the front, defending the spacecraft in the cyber domain paper. 33:17.730 --> 33:20.190 We talk about the cyber safe mode. 33:20.190 --> 33:26.110 That's a slight transition from the traditional safe mode terminology. 33:26.110 --> 33:31.990 But it's basically it's a safe mode that's cyber hardened to a degree. 33:32.190 --> 33:42.990 And you have a high integrity mode that you're in, that you know you're in a good state and everything's valid, and you still have authentication encryption going on. 33:42.990 --> 33:45.390 So that's a concept. 33:45.390 --> 33:49.850 That's a kind of newer concept that's being discussed in the space sectors. 33:49.850 --> 33:52.350 But it should be there. 33:52.370 --> 33:59.550 Because knowing, you know, more and more people that understand space and understand fault management response may use that against you. 33:59.550 --> 34:03.330 So you may want to think about that a little bit more as you do your design. 34:03.990 --> 34:07.790 So here's some recommendations for just generalized protection. 34:07.790 --> 34:14.310 This isn't specifically GPS jamming because there's a whole there's papers upon papers out there that talk about how to protect against jamming. 34:14.310 --> 34:20.270 But this is more in line with protecting against, you know, leveraging fault management against you. 34:20.270 --> 34:29.790 So you need to really protect that documentation because that's just basically providing an adversary a pathway to get you in a more vulnerable state if your design is built that way. 34:30.230 --> 34:35.990 And other design considerations about always encrypting information, especially on the downlink. 34:35.990 --> 34:44.850 So some people think that the downlink on the telemetry side should not necessarily be encrypted because it's not, you know, it's not controlling the vehicle. 34:44.850 --> 34:49.430 But there could be a lot of good information that is ascertained from telemetry. 34:49.430 --> 34:58.810 So it could be you could have adversaries monitoring your telemetry stream looking for various, you know, indicators that you are in a less secure state. 35:00.210 --> 35:03.110 And these are other some design considerations that are that are here. 35:03.110 --> 35:04.110 I won't read them all to you. 35:04.110 --> 35:16.090 But basically getting, you know, the cyber safe mode, getting, you know, only report error messages when needed and encrypting it accordingly and getting make sure you have ability to recover and reconstitute to a known state. 35:16.090 --> 35:22.770 So these are just some considerations to think about as you're building your design for a spacecraft. 35:23.390 --> 35:28.990 So with that being said, those are just an example of doing some protection. 35:28.990 --> 35:38.570 So let's talk about what it takes to let's transition the discussion a little bit and talk about what it takes to just protect the overall ground system. 35:38.570 --> 35:45.210 So at this point, we've talked about, you know, the command link intrusion. 35:45.210 --> 35:49.210 We've talked about command replay, some denial of service. 35:49.390 --> 35:52.330 But let's talk more generically about space systems in general. 35:52.330 --> 36:02.570 So I like to use defense in depth as a presentation material and discuss and a principle for design as many people do. 36:02.570 --> 36:06.930 I mean, I think anyone in the security community really understands the fits and depth. 36:07.190 --> 36:12.110 But with the fits and depth, I like to illustrate basically using an onion. 36:12.110 --> 36:22.410 So in the typical, you know, IT sense, the onion diagram, you have, you know, the hardened server configuration wrapped with intrusion prevention firewall type stuff. 36:22.410 --> 36:25.890 But in the space domain, it's a little bit different, but it's somewhat similar. 36:25.890 --> 36:33.790 But so here's some graphics that I wanted to provide that give you a representation of the fits and depth for both ground and space. 36:33.790 --> 36:37.810 So this first graphic here is kind of the ground system. 36:37.810 --> 36:50.550 So it starts with the data that runs, you know, on the endpoints, wrapped by software, supported by endpoints, connected by networks, protected by intrusion detection and perimeter controls and physical controls. 36:51.030 --> 36:58.170 So there's, you know, this isn't all inclusive, not every subcategory, you know, within each block is listed. 36:58.190 --> 37:05.970 Due to space, but it provides a good list of things that you would expect to be at each layer of the onion. 37:05.970 --> 37:13.190 So from a data perspective, you may have, you know, data at rest encryption, you may have Tempest that you need to worry about. 37:13.410 --> 37:25.250 From a ground software perspective, you know, SDLC, secure coding, common weakness enumeration prevention, things like that, binary analysis, dynamic analysis, static code analysis, stuff like that. 37:25.570 --> 37:32.650 Your endpoints, your heads, your hips, your AV malware, DLP, file integrity, things like that. 37:32.650 --> 37:38.950 So we won't dive into every one of these, but it's kind of important to understand that you can pick and choose to apply controls at each layer. 37:38.950 --> 37:40.750 And it's important to apply controls to each layer. 37:40.750 --> 37:52.650 So you don't want to just put all your eggs in the perimeter basket and say, I'm going to stand up a good DLP, a good firewall, and security zones on the perimeter. 37:52.790 --> 38:00.150 And then hope that gets me there because you have insiders, you have other avenues where you need monitoring capability, you need protections. 38:00.310 --> 38:02.310 So that's pretty common. 38:02.410 --> 38:05.250 You know, that's nothing groundbreaking from a ground perspective. 38:05.250 --> 38:09.930 But similarly, you can do the kind of the exact same approach for the vehicle itself. 38:09.930 --> 38:14.130 So this is a onion representation for the vehicle. 38:14.130 --> 38:30.850 So you have, you know, similarly the data that's on board the vehicle, wrapped and processed by some sort of software on board that has a single board computer or, you know, a processor and a bus, hopefully protected by some sort of onboard intrusion detection prevention. 38:30.850 --> 38:32.870 So that's kind of a new area. 38:32.870 --> 38:38.450 What's being researched today is kind of onboard cyber monitoring and intrusion detection prevention. 38:38.450 --> 38:42.390 That's not typical on a lot of missions right now. 38:42.390 --> 38:49.830 What you see currently, a lot of the focus on protecting space vehicles is really geared around the crypto comms area. 38:49.910 --> 38:58.730 So, you know, the authentication encryption and the comms link, the transect, things like that. 38:58.910 --> 39:09.290 But there are controls that you can apply and there are threat vectors that exist for basically every one of these blocks on the vehicle as well as on the ground. 39:09.290 --> 39:20.910 So since there's threats and vulnerabilities that can be exploited, that can happen on kind of each block, it's important to put controls in each block, honestly, so that you can have a better chance of protecting yourself. 39:22.030 --> 39:32.350 So in conclusion, we've talked, you know, kind of three attack vectors, but those are just three examples and there's many more that can be discussed. 39:32.350 --> 39:47.850 But it's kind of convenient, to ignore security, honestly, because there's not been this, you know, windfall of events that have happened that are cyber related on a vehicle. 39:47.870 --> 39:51.010 But it's not really an option moving forward. 39:51.350 --> 39:57.630 Satellites are too critical to our everyday life or operations of our nation and the world, honestly. 39:57.630 --> 40:06.090 And it's kind of important to understand that the barrier to entry into space has been dramatically reduced in the last five, 10, 15 years. 40:06.090 --> 40:16.390 I mean, with small sats and launch services, and AWS ground stations, it's getting real easy to get a lot cheaper to get information. 40:17.050 --> 40:21.110 It's a lot cheaper to get assets into space. 40:21.810 --> 40:25.010 So, and defensive depth needs to be a big part of the solution. 40:25.010 --> 40:29.450 So we need to design security at the beginning, which is kind of cliche, but obvious. 40:29.890 --> 40:38.670 And it's going to be more and more important as we, you know, start to deploy all these small sats in a peripheral-related constellation moving forward. 40:39.030 --> 40:44.890 So, you know, from a defense in depth perspective, and, you know, understanding security, it's important. 40:44.890 --> 40:52.810 So I mean, there's a little bit of a interesting parallel you can draw, you know, with space systems, and in the industrial control system arena. 40:52.810 --> 41:00.710 So it's, you know, for years and years, you see this at, you know, at the IoT village as well. 41:00.710 --> 41:07.430 For years and years, people have kind of ignored security in the industrial control systems, OT, IoT arena. 41:07.710 --> 41:12.450 And it's not just been the last few years, people have really started understanding that threat factor. 41:13.450 --> 41:20.390 And, and mainly it's due to, there's been documented attacks, and a lot of bad things have happened as a result of that. 41:20.390 --> 41:26.030 So let's try to learn from that lesson and not wait till something really bad happens to make corrections. 41:26.030 --> 41:30.610 Because we know there are vulnerabilities, we know there are corrections, we know there are things we can do. 41:30.610 --> 41:32.990 So we should be doing that. 41:33.710 --> 41:39.090 And the small set marketplace, you know, and the embedded security community is evolving. 41:39.150 --> 41:43.470 There's a lot of commercial things that are being put out, there's some open source solutions that are out there. 41:43.690 --> 42:00.390 And we need, you know, accountability, we need people who are researching this to understand the security ramifications of these things and, and need to be somewhat agile to get these things verified and validated and accepted and put out in the community. 42:01.430 --> 42:06.110 As opposed to some niche areas, niche markets, people doing things. 42:06.110 --> 42:13.270 So it's important for us to get, you know, leverage the explosion in this market. 42:13.270 --> 42:26.890 But it's also, we need the security researchers and, you know, ethical hackers and things like that to really, you know, hold people accountable for the things we're putting out. 42:27.190 --> 42:31.210 Because, you know, the path of least resistance is often used. 42:31.210 --> 42:41.390 So if no one's looking at your, looking at your work and understanding the security ramifications of your design and what you're doing, you know, people kind of get lazy with their implementation at times. 42:41.390 --> 42:49.790 So it's important that we all get out there and research this stuff and look, look into it to understand the ramifications, some of these design choices that are being made. 42:50.970 --> 43:00.790 So we need to really, you know, the government industry, I think we're coming to a very good, you know, agreement that cybersecurity is super important for, for space programs. 43:00.970 --> 43:05.110 And there's a lot of investment that needs an education, training and talent development and retention. 43:05.110 --> 43:10.670 So I, I feel like there's a huge step forward this year at DEF CON with the hack-a-sat. 43:10.670 --> 43:20.830 I mean, that, that is a fantastic event that, you know, that's ongoing within the Aerospace Village to, to, you know, hack into to representative satellite systems. 43:21.710 --> 43:27.670 And it, you know, there's these open source technologies that are put out that you can build your own ground-to-space simulation. 43:27.670 --> 43:28.830 You can start learning. 43:29.030 --> 43:32.790 You know, five years ago, there was not that much out there to learn. 43:32.790 --> 43:43.230 So the, the activation energy and the level of access to information was, wasn't there for the security community to get into it. 43:43.490 --> 43:56.630 So I think it behooves us, you know, within the government, within the industry to start getting this information out there and making this stuff available for the researchers so they can, you know, we can find some of these vulnerabilities and get them fixed. 43:57.090 --> 44:07.190 And technology has evolved from a simulation perspective so much in the last 10 years with the advent of, you know, digital twin type technology for space. 44:07.250 --> 44:19.750 The embedded arena is getting there, you know, with open source, things like QEMU, with commercial things like Simics or TCM, you can get really high fidelity simulators running software. 44:20.370 --> 44:24.830 And that's, you know, built for target and running a lot of tests. 44:24.830 --> 44:27.730 You don't have to buy these million dollar space platforms. 44:28.270 --> 44:38.970 And there, and also these, you know, these CubeSats that you can buy, and these embedded processors, you can buy some of these things kind of commercially off the shelf, start doing your own research if you have some of the budget. 44:40.010 --> 44:52.210 But the last point is, you know, the reason I wanted to do this presentation and be a part of the Aerospace Village and work with the Space Ice Act is information sharing is a must. 44:52.210 --> 45:01.230 I mean, coming from the government arena, you really get into this compartmentalization of information and the need to know and things like that. 45:01.230 --> 45:13.130 So, but we really need to have information sharing, we need to do research, we need to have events like this, the Aerospace Village, we need to come together as a community and start doing this research together. 45:13.650 --> 45:18.570 And we're not trying to point fingers at people and, you know, say that, oh, your implementation is bad. 45:18.570 --> 45:26.230 It's just we need to learn together and make things better and share what we learn and do presentations like this. 45:26.750 --> 45:29.950 So, with that being said, that's about all I have to present. 45:29.950 --> 45:40.750 But I do have here on slide 29 a link to some resources, the Space Ice Act, there for information on it, the HackASAT link. 45:40.950 --> 45:49.830 Something that's going to be really cool is they, the HackASAT was, you know, they had qualification rounds and they have the finals at DEF CON this year. 45:49.830 --> 45:55.330 And they're going to open source a lot of those CTFs qualifications and things. 45:55.330 --> 46:05.250 So keep an eye on the HackASAT URL to, you know, maybe pull down some of those CTFs once they get published and give them a try yourself and learn. 46:05.530 --> 46:08.710 This is a really exciting exercises that were put together. 46:08.710 --> 46:19.270 If you want to build some of your own simulators, these links are there with for OpenSATKit, Noscubed, 42, things like that, Open Source Flight Software, CPCFS. 46:19.730 --> 46:24.450 And there's some info here on, you know, jamming if you want to learn a bit more about that. 46:24.450 --> 46:31.150 And the paper that was published in November 2019 is also linked here for your reference. 46:31.150 --> 46:36.730 So with that being said, that is all I have to present. 46:36.730 --> 46:38.070 And thank you so much. 46:38.070 --> 46:40.970 And I'll take questions in the offline session. 46:40.970 --> 46:41.890 Appreciate it.