WEBVTT 00:00.000 --> 00:05.080 To kick off the Aerospace Village at DEFCON 31 is Henry Haswell. 00:05.080 --> 00:10.020 Henry is a research engineer at Southwest Research Institute or SWRI. 00:10.020 --> 00:15.780 His focus is primarily on cyber-physical system security and embedded software systems. 00:15.780 --> 00:23.380 He's no stranger to our stage as he presented a vulnerability assessment of a satellite simulator at the Aerospace Village during DEFCON 30. 00:23.780 --> 00:28.860 Now give a round of applause for Henry's presentation on secure micropatching on the ISS. 00:31.610 --> 00:41.030 Hey everybody, so the robot, the voice there, introduced me already, so my introduction slide here, it was supposed to be me doing that, but hey, we're covered. 00:41.750 --> 00:57.470 So since this is the very first presentation of the day, I'm just gonna, you know, we'll give a bit of background here, what we're looking at here, talk about what is, what the current state of, over there, updating is in for space. 00:57.730 --> 01:08.910 So, obviously space, the industry has been way back, the further you go, if you want to go down back to the 60s, 70s, over there, updating wasn't even a thing. 01:08.910 --> 01:12.710 You would program your satellite once, launch it, that's it, you're good. 01:13.010 --> 01:15.290 Or, well, you're done, I should say. 01:15.970 --> 01:20.950 But over there, updating has been a thing on more recent satellites. 01:21.110 --> 01:34.150 You usually have a pretty small window to send out these updates, because since they're in orbit, you have to be in range of the satellite, your ground station, to the satellite in order to be able to send out this update. 01:34.990 --> 01:45.250 At best, if you fail to send your update in that time frame that you have to send out your deployment, then you have to resend your update once you're back in range. 01:45.590 --> 01:54.950 At worst, if you have an update that fails and has some sort of error in the update, you could cause some sort of system error on the satellite. 01:55.710 --> 02:05.610 And if some bad actor is sending out their own malicious updates, they could even try to modify the behavior of the satellite in some way. 02:05.610 --> 02:17.410 Now, of course, space cybersecurity in general has been a growing focus to both the cyber industry and the space industry as well. 02:17.410 --> 02:28.210 You're looking at things like the Ukraine conflict recently, where there were internet satellites that were all hacked and shut down right before that invasion launched. 02:28.210 --> 02:31.130 And so there's been a lot more focus on this more recently. 02:31.990 --> 02:37.570 So these data errors, some common mitigations for these here. 02:37.810 --> 02:46.610 So it's pretty much standard these days in the CCSDS communication standard to use a CRC, which is a Cyclic Redundancy Check. 02:46.630 --> 03:00.710 And essentially what this is, is at the end of each CCSDS data packet that you're sending, there is an area which is some data to try to verify that the data in that packet is valid or correct. 03:00.910 --> 03:12.050 One of the most common ways is doing a checksum, basically sum up the bits and then add that sum to the end of the bits and you check, okay, yes, that checksum matches what I calculate for that summation, so we're good. 03:12.930 --> 03:34.790 There's also for error detection and correction, like when you have your data on your satellite to prevent, protect it from being altered while it's on there, whether that be bit flipping from radiation or other ways that in space with all sorts of interference can go on of altering that data, 03:34.790 --> 03:44.830 the error detection and correction is used to try to detect those bit errors and correct them without having to resend those updates. 03:45.030 --> 03:52.430 So BCH and Reed-Solomon are some common error detection and correction algorithms used on space assets today. 03:52.550 --> 04:07.670 Now, the thing about these EDAC methods is the larger these bit errors are, the greater the memory requirements are on the space system to be able to correct those bit errors. 04:07.670 --> 04:22.130 So for reference, our company, a lot of the satellite systems we work with, we have around three bits error detection and correction for our systems or give or take depending on the situation. 04:22.130 --> 04:36.890 So if you're dealing with really large files, if they have larger errors in them that are in the several bytes range, then it would just cause a large amount of memory to be able to address those. 04:37.130 --> 04:46.290 So one thing that we've worked on in the past has been secure micro-patching for ground systems. 04:46.290 --> 04:59.630 The idea behind the secure micro-patching is if you're seeing an over-the-air update, you are able to detect any modification of bits but also insertion or deletion of bits and try to correct those. 05:01.350 --> 05:03.470 There we go. 05:04.190 --> 05:07.550 So a bit of background on our previous work in secure micro-patching. 05:08.230 --> 05:14.090 So as I mentioned before, it allows for correction of insertion, deletion or modification of data. 05:14.090 --> 05:19.670 That's important because regular EDAC usually is only for correcting a modification of data. 05:19.670 --> 05:30.090 If you're adding in your own packets, if those packets were marked as authentic by whatever system you're using to authenticate your packets, then it'll be added into your data. 05:31.310 --> 05:42.110 The goal of our secure micro-patching is to reduce the transmit time of correcting an update when compared to having to resend that update. 05:42.110 --> 06:01.130 So if you're looking at a situation where you send out your update and then you check and oh well, it didn't send right for interference or the wrong file got sent or whatever, what have you, instead of having to resend that full update, only the bits that were corrupted will be resend. 06:01.250 --> 06:13.150 That's reducing your retransmit time and as we mentioned before, in space where you sometimes have a very limited time frame to transmit, that's valuable and every minute can count for that. 06:13.530 --> 06:16.030 In the past we've deployed this on ground vehicles. 06:16.030 --> 06:24.310 We've done work with DOD clients on ground vehicles deploying secure over there updating. 06:25.590 --> 06:34.510 And so we decided we want to do a demo of our secure micro-patching on the International Space Station. 06:34.850 --> 06:41.970 So we teamed with Axiom Space to do this demo. 06:41.970 --> 06:48.770 They have an AWS Snowcone that's riding along in the ISS on the US side. 06:49.830 --> 07:08.590 Then we did our micro-patching tool running on the AWS Snowcone and on a ground station on the ground communicating between each other in order to demonstrate a cyber use case of our secure micro-patching for space systems. 07:08.630 --> 07:23.790 But on the Axiom side, they're using this as a use case of space servers because their long-term business model is having servers running in space to communicate with other space assets and this is a potential use case for it. 07:24.830 --> 07:42.270 Now at a high level, what's going on here with this demo, we have, if you work up from the top left and then around here, you have some kind of data file, you know, whether that be a firmware update or any kind of binary file really could work for this. 07:42.270 --> 08:03.350 It's living on this Snowcone and there is, on the server side of the Snowcone, the data protection code script is running to send out this data file and get it sent through from the ISS down to a guy, uh, ground station through the T-distometric. 08:03.510 --> 08:10.790 Uh, that's the use case we used for this demo but the idea is this is something you could also use for deployment of, you know, space to space updating as well. 08:11.010 --> 08:30.470 Uh, and on this ground station, whether there's some sort of perturbation of the data, whether that be from, uh, RF interference, radiation, some, uh, bad actor trying to modify the data of that update and it has some sort of errors in there whether that be, 08:30.470 --> 08:34.670 you know, some data got inserted, some data, some packets got removed or modified. 08:34.690 --> 08:50.970 Uh, then on the ground station, uh, we have the other side of the micropatching script running and it's trying to communicate with the, uh, space side in order to verify which of these bits have been altered in whatever fashion. 08:51.030 --> 09:03.670 Uh, then it requests the, those bits to be recent so that it can, uh, patch or micropatch the file to have a, uh, corrected file which has the original intended data. 09:04.990 --> 09:09.210 So there's 3 phases, uh, to this, uh, research we did. 09:09.210 --> 09:24.590 Uh, it's, uh, the first phase we did a hardware in the loop test environment, uh, to, we had our own ADOS no-cone that we ordered and hooked it up to our own, uh, computer to simulate a ground, to be akin to the ground station. 09:24.770 --> 09:35.090 Uh, and then phase 2, uh, we made some modifications to our micropatching script to, uh, optimize them for the space environment for the ISS network. 09:35.090 --> 09:41.810 And then 3rd we, uh, did our demonstration of the micropatching on the, uh, IOSS snow cone. 09:41.810 --> 09:49.600 Uh, so first off, a little bit of background here on the AWS snow cone. 09:49.900 --> 09:58.880 The purpose of the AWS snow cone, it's a compact server for edge computing that is, they, they market it as a edge computing device. 09:58.880 --> 10:03.960 So not just space applications but also, you know, ground applications as well for that. 10:04.160 --> 10:09.160 Uh, it uses, uh, what they call, uh, Amazon EC2 Linux instance. 10:09.180 --> 10:11.960 It's kind of akin to Docker images. 10:11.960 --> 10:14.800 Uh, it's running a version of Linux on it. 10:14.800 --> 10:19.580 Uh, and they have a, despite being about the size of a shoebox, they're pretty beefy. 10:19.580 --> 10:28.960 You got about 14 terabytes of SSD storage in the model we were using, uh, because these are meant to be, like, data servers, uh, for their original use case. 10:28.960 --> 10:32.760 But we're all, in this case it's being used as a, uh, space server. 10:33.900 --> 10:39.960 For our ground simulation, so we have our snow cone on, on, acting as the space asset. 10:39.960 --> 10:43.360 We have our lab laptop acting as a ground station. 10:43.460 --> 10:48.400 And we implemented this, the client server communications for our micropatching script. 10:48.440 --> 10:52.020 And the, uh, you can see we have a little diagram here. 10:52.020 --> 10:59.880 Uh, on the left side we got our ground PC, which is really just our laptop, uh, running the ground part of the micropatching script. 10:59.880 --> 11:10.200 And then we have the, uh, AWS snow cone being the space system, which is getting the, the, uh, space server side of the script. 11:11.340 --> 11:30.420 So in our ground simulation, uh, we simulated what we expected the, uh, latency and network transmission, uh, limitations, uh, on our trend ground, uh, this simulated ground to space transmission to see how our algorithm would perform in this higher latency environment. 11:30.600 --> 11:47.100 Because compared to a ground system set up, uh, for ground to ground communications, if you're talking to a ground vehicle, you have a much lower latency because you're, you know, communicating across, you know, maybe a few miles versus going all the, 11:47.100 --> 11:50.320 going all the way up, uh, to the ISS, right? 11:50.320 --> 12:17.440 Uh, and we, for, to act as a benchmark, a point of reference, what we have is we, uh, did a, uh, we full resend of the packets that were, uh, detected as being corrupted through, uh, like a legacy edep script, uh, that was running a Python, uh, implementation of edep on a lot of space systems. 12:17.440 --> 12:26.360 You'd probably be running, uh, you know, hardware level or, or see, uh, edep script, which may be faster than the one we're using, but we're using this as a starting, uh, point of reference. 12:26.720 --> 12:46.280 Uh, and in our simulations, we saw that in, uh, most cases when we're, depending on the file size you're using, uh, it was faster for us to use, uh, one of the, use our, uh, micropatching algorithm to correct these, uh, uh, errors rather than rely on, 12:46.280 --> 12:51.080 uh, using the edep or, uh, resending the, uh, packet. 12:51.080 --> 12:59.460 There was some situations though when we were looking at very small size, size files, like less than a megabyte, uh, where doing the full resend was actually faster. 12:59.460 --> 13:14.340 And what we realized was in this situation, uh, the, the issue was actually the, uh, sending the message count because this, the micropatching script, it uses more messages compared to just doing a full resend all at once. 13:14.400 --> 13:18.700 And when you're dealing with high latency environments, uh, that could become a bottleneck. 13:18.700 --> 13:35.280 So what we did is we have our second, uh, algorithm, which we're calling a recursive algorithm, uh, which try, try to, uh, reduce the amount of messages needed to be used in order to do the micropatch in order to, uh, reduce how that latency impacts our, 13:35.280 --> 13:37.720 uh, micropatching script. 13:38.540 --> 13:44.820 So we realized we needed to, uh, reduce the latency of our micropatching to, to be efficient here. 13:44.820 --> 13:48.060 And we also needed to account for, uh, potential loss of service. 13:48.060 --> 13:57.140 So in the network that we were testing on, uh, around, on an average of around every 40 minutes, there was a loss of service. 13:57.180 --> 14:13.900 So by default in the network that was used to send out update files to the Snowcone, uh, if you had that loss of service while you were sending, uh, update file out, well, you lose the file and you have to start from the beginning once you have service again and resend that full file. 14:14.080 --> 14:23.300 Um, but because we had our micropatching script running, uh, the way we implemented it, you, you're basically just pausing the update while, while you have that loss of service. 14:23.300 --> 14:26.320 Then once you have a connection, you continue right from where you left off. 14:29.120 --> 14:35.740 Now for running the actual demo, uh, we worked with, uh, the Axiom Space on, they, uh, staff on the ground. 14:35.740 --> 14:44.900 They have a ground station that, uh, communicates up to the AWS Snowcone, uh, that, and we worked with them to run the ground side of the micropatching script. 14:45.020 --> 14:52.500 And on the space side, we had an astronaut who, you know, powered up the Snowcone and started up the space side of the script. 14:52.500 --> 14:59.940 Uh, we have a little, uh, I, I like, this is my favorite picture in this presentation of the Snowcone, uh, floating on the space station there. 15:00.100 --> 15:09.480 Uh, and so just so you know what type of network we're dealing with here, uh, on the uplink we had about 5 megabits per second of transfer speed. 15:09.700 --> 15:11.500 Uh, on the downlink we had way less. 15:11.500 --> 15:14.440 It was like 0.1 megabits per second, I think. 15:14.440 --> 15:24.100 Uh, and then we had around 8 me- me- millisec- 100, sorry, 100 milliseconds of latency to send a message from ground to space or vice versa. 15:24.180 --> 15:30.740 So, we're talking about almost a second from the time you send the message to when it gets to, uh, the space station. 15:30.880 --> 15:40.460 And we also expected based on, uh, you know, previous, uh, network communications on this network that every 40 minutes or so we'd get a, a loss of service. 15:41.560 --> 16:01.040 Now, on the actual demo of our script on the international space station, uh, we saw that our micropatching script in, if you, if you're dealing with, uh, around larger than a megabyte file, uh, it was faster in terms of pure, uh, time needed to do, to, 16:01.040 --> 16:06.340 uh, correct the update than just relying on our Python implementation of EDAC. 16:06.520 --> 16:12.800 Uh, and also another ben- benefit here was there was multiple lo- losses of service because this is such a small network. 16:12.800 --> 16:20.520 We sent a variety of file sizes if we're dealing with a very large, like, say, 100 megabyte file, uh, uh, 5 megabits per second. 16:20.520 --> 16:31.020 That's still gonna take a little while and so we experienced some losses of service but the, uh, micropatching version of the script was able to just restart from, from where they left off. 16:31.060 --> 16:45.500 Uh, now, the, if we're talking smaller than a megabyte, then it was, uh, not as, not as fast in terms of pure transfer time but there's some other benefits that I don't, I wanna get into here in terms of future work. 16:45.600 --> 16:53.180 So, uh, the, uh, at, at the base level, right, ultimately reduced downtime is, is one goal here. 16:53.180 --> 17:11.980 The other time is cyber security being able to, uh, in terms, being able to secure these, uh, updates to make sure that not just, uh, modification but you're also protecting insertion and deletion and you're reducing, uh, your, uh, repair time by, uh, 17:11.980 --> 17:17.320 having these, um, uh, this micropatching service. 17:17.580 --> 17:24.840 Uh, so we, this is the first time that we're aware of, of a micropatching deployment being deployed to an asset on this ISS. 17:24.840 --> 17:35.780 Uh, we see this as a good starting point going forward to look at, uh, deploying micropatching on other space assets or to maybe even something like space and space communications as well. 17:35.820 --> 17:46.920 Um, we're starting to look at ways of, uh, upgrading this, right, and, and making it, uh, something that we can deploy on other systems as well to help, uh, keep these, uh, over there updating secure. 17:49.240 --> 18:01.460 So, I went through that, uh, way faster than I thought I would, but, uh, I can, we can have a, uh, Q&A session here if there's any questions, uh, from the audience about the presentation here. 18:01.860 --> 18:02.120 Thank you. 18:02.120 --> 18:04.820 I was just gonna ask if it's source available or is it just enclosed? 18:04.960 --> 18:08.780 Uh, oh, so, yeah, so this is, uh, Swery owned, owned code, uh, yes. 18:08.860 --> 18:18.940 Oh, are you, uh, do you have plans to make it, like, the source available as sort of open source of project or are you just gonna be, like, what's the, what's the deployment model if it, if you want to have, like, operators use it? 18:18.940 --> 18:21.660 Is it gonna be, like, licensable, like commercial license? 18:21.960 --> 18:36.540 So, the way we plan to take this and integrate it into project going forward is we want to work with, uh, you know, whether that be commercial or government, uh, to, uh, implement these onto their systems because every system's gonna be a little different and we want to work with them to make sure we can, 18:36.540 --> 18:41.360 uh, customize this to fit with their solutions, uh, so, so that, so, yeah. 18:41.360 --> 18:42.600 No more questions from the audience? 18:42.600 --> 18:43.260 Okay. 18:43.260 --> 18:45.960 Well, uh, thank you guys.