 I'm Darren Cofer. I'm a researcher at Collins Aerospace. My talk today is called Steal This Drone and provides an overview of the High Assurance Cyber Military Systems Program. So you may recognize the talk title as a take on Abby Hoffman's book called Steal This Book, published in 1971. Hoffman was a 60s year counter-cultural activist and a member of the Chicago Seven. The book was intended as a guide for how to fight against the establishment and included advice on organizing protests, building bombs, setting up pirate radio stations, things like that. Just as all of life has moved online in the intervening 50 years, there's a sense in which cyber threats and cyber terrorists, whether individuals, groups or nation states, are the modern day equivalent of the methods and audience of this book. So around 2010, people started becoming aware that cyber vulnerabilities are not isolated to traditional information processing platforms and infrastructure, but are also present in embedded systems, cars, airplanes, printers, including safety critical systems. So DARPA at that time organized the Hackens program, High Assurance Cyber Military Systems, with the goal of using formal methods to build systems that are resilient against cyber attack, because they can be proven not to have typical security vulnerabilities. Collins led one of the teams on the Hackens program with our partners at Galois, the SEL4 development team, Boeing, and the University of Minnesota. So as a quick review, formal methods are a way of providing complete exploration of a design using mathematical analysis. Includes the use of formal methods, discrete math and computer checked proofs techniques such as automated, they're improving model checking. And the use of formal methods is motivated by the idea that just as in other engineering disciplines, doing appropriate mathematical analysis can contribute to establishing the correctness and robustness of the design. So it's really trying to make software engineering an actual engineering discipline, and can be applied to both safety and cybersecurity. And we can think of this as, you know, the equivalent of doing geometric proofs, like the Tagarian theorem, where we want to know things not about just individual triangles, or in this case, individual programs or combinations of variables, but a proof that something works for all inputs to the system. One example of this that's relevant for me, living in the Minneapolis area is the, you may remember the collapse of the Mississippi River bridge some years ago. There was a case where the structural design that was designed by hand back in those days, of course, and there was an error that eventually over time led to the collapse of the bridge. So the analogy here is that formal methods is the software as the finite element analysis that we use today for ensuring that mechanical structures are sound and will serve their purpose. The approach we've used in that we used in the Hackams program, which I mentioned wrapped up in around 2017 is architecture driven assurance. So we start with a model of the system architecture and analyze it to ensure that it is correct that does what we want it to do it meets its requirements. This includes having a model using a language like ADL, the architecture analysis and design language. That can capture the properties, the structure behavior interactions of components. And then we use formal analysis using a senior key contracts to make sure that the components of the system interact to satisfy the system requirements. Next we need to make sure that components themselves are correct. That is that they satisfy their their contracts. And the contracts themselves are consistent and realizable and we may use languages and tools like ivory tower language developed in the Hackams program simulink design verifier in the light. Next we want to show that the system does what the model says. That is that there are no other information flows in the system. This includes properties like memory isolation and safety. And one way of doing that is to use the SEL for formally verified secure kernel, which was a key part of the work that we did in this program. Finally, once we're happy that the architecture components and the posting operating system are correct. We automatically build the system implementation from the component and architecture models with proof of equivalence. And SEL for this was developed by researchers. Now at usw and Sydney, and the, and the SEL for foundation SEL for is the first formally verified high performance microkernel. The binary code has been approved to correctly implement the behavior of the system described in its abstract specification. And importantly, to do nothing else, there's no extra behaviors in the system and you the formal proof gives us confidence in that so this allows us to build systems that have security properties of integrity and confidentiality. The SEL for is open source, and it's now supported by the SEL for foundation for ongoing development. And it allows us to implement a whole host of bugs that can lead to serious security issues. Ivory tower is a domain specific language that was developed by our partners at Galois. Ivory tower is embedded in a high level language Haskell and it, the idea is to provide a language that prevents users from making common errors that might be found in C so they program in this very compact DSL and then generate safe C from that and it's a very efficient way to generate a lot of code from a relatively small specification and also automatically generates properties and tests that can be checked arithmetic checks for that overflows and checks on interface values and types. So one of the demonstrations demonstration platforms that we talked about and we have here at the aerospace village is the smack them copter research vehicle as you can see it's a small quadcopter and we've used this to demonstrate the effectiveness of the formal methods tools that we are using for software development and proof of correctness. Here's a peek inside of the quadcopter starts out as the iris plus airframe has a traditional RC controller radio that we use a safety radio. It comes with the pick sock flight control computer inside. We've added to that mission computer based on the TK one som computer and those communicate over a can bus. There's also a little downward looking camera on the on the vehicle. And then it has a couple of other radios for communicating with its ground station control and telemetry go over a encrypted 3d our radio data link, and then video from the camera as stream down on just a standard Wi Fi link. To demonstrate the effectiveness of some of the technologies that we've been building also implemented a bunch of different cyber attacks to to try to break the system behavior or attempt to cause it to do something that the operators don't want it to do so. The idea here is that we exploit this relatively unprotected Wi Fi link that's just being used to provide video from the camera as a way of gaining access to the vehicle and connecting to the to the mission computer software. Here's a view of the demo that we did. At the end of the hackens program you can see on the left group of good guys who are the operators of the vehicle. Mission area, representing some models small buildings that they're attending to do surveillance of, and then bad guys on the right who are trying to hack into the vehicle and actually be able to compromise it and physically capture the vehicle. There's a diagram of what's going on in this attack so this is showing you what the before version of the system before we made our modifications to the to the software. It's just here it's running an unverified kernel that has a memory vulnerability in it. And what that does is it allows the attackers to SSH into the Linux VM that's being hosted on the kernel. It's running the camera software so they can just go in that that Wi Fi link and break that and get access to the Linux VM and then exploit the memory error to find and change the encryption keys that are being used for the for the telemetry link. Having done that they can prevent the legitimate ground station from being able to control the vehicle and and operate it and even receive the video telemetry from it, and bring up their own ground station using the keys that they've written into the vehicle now and take control of the vehicle and physically capture. So they haven't broken the encryption at all that just use this deficiency in the in the vehicle to be able to find and overwrite encryption keys themselves. So then after we reengineered the vehicle, relying to a large extent on the seal for secure kernel. Now that attack fails when the attackers try to gain access to any memory outside of the Linux VM. They're unsuccessful. And in fact they can do anything they like they can crash the camera software crash the VM itself, and the vehicle is able to continue flying without any impact on its on the control from the from the legitimate ground section. In fact, the VM itself can be remotely restarted to regain control of the camera. So that's the after version that shows that the vehicle being hardened against those kinds of cyber attacks. Okay, but you may say that's just a toy what about a real helicopter. Good question. Maybe something like this this is Boeing's unmanned little bird helicopter that we use as our second platform you can see upfront where there might normally be some room for passengers as a bunch of computers that have been better used to allow this vehicle to fly autonomously. So this was our. We would take our next step was to take all the technologies that we demonstrated on the quadcopter and apply them to the to the little bird. So here's a look at what the baseline architecture of the system looks like you can see that sort of equivalent to the quadcopter and that on the left you see there's a flight control computer. On the right, a mission computer that's interacting with the ground station and managing requests, possibly from different ground stations and those communicate initially over 53. There's a data bus there's also on board camera that's controlled through the through the ground station and also can be used for certain guidance missions for the for the vehicle flight control software is just monolithic written and see that 20,000 lines of code and mission software is C plus plus. And it's about 87,000 lines of code. It's really quite amazing that we were able to do this on this program because all we wanted to do was rebuild the software in this helicopter, using these new formal methods tools. And oh by the way, then we want to do some cyber attacks on it while it's flying. And because of the confidence that we had in their results. Everyone on the team was was willing to go along with us and we actually had some nice in flight demonstrations of the vehicle being resistant to cyber attacks. So here's what the final you will be architecture looks like as you can see we've done a lot of similar things we've got a cell for running on the mission computer added a verified file system for a cell for the authentication functions ground station interoperability enforcement some other functions are implemented in the ivory tower language. The camera software and the data recorder functions are now hosted in guest Linux VMs running on SEL for the internal communication system has been simplified by control computer software has been refactored and it's now running. The BX works our toss. Some of the flight control computer by control computer components are now implemented in ivory tower. We did an analysis of the you will be a BL model that was used to construct the system. And finally did some flight demos to show that it works and it was resistant to release some some number of cyber attacks. This shows you what the baseline vehicle looked like. Originally everything on the mission computer was running on Linux all in one address space, we're able to demonstrate a kind of a sample attack in which an infected USP maintenance device is connected to the B port on the helicopter to to download the data from the data logging process. From there the exploit goes and it modifies the camera control software and during that during an actual flying mission, the camera to be disabled and that prevents the vehicle from performing its mission and essentially continually stows a camera and so it can't perform the camera based guidance on the hardened version. Again, we've got SEL for running on the mission computer and the separation that it provides between all of the software running natively on SEL for and in these two VMs running Linux as a guest but the camera software and the data logging process. So as the attackers now to only be able to affect the data logging process, no longer can it access the camera or any other software running on the vehicle so we're able to complete our mission without interference lost the data logging process but all of the safety critical and mission critical functions are unaffected. We have nice videos from the final demo of the system that are available on our website that I show there both of the quadcopter flying and the ULB flight demo also be showing those on a loop down in the aerospace village. So our next step then was to move to how do we do this more efficiently and that brings us to the current DARPA Cybershirt Systems Engineering Program and Collins is leading a team here with the SEL 14 University of Kansas at ventium in Kansas State. The idea behind the program is that cyber security requirements are largely addressed today through processes aimed at risk mitigation and pen testing performed late in development and this awesome also results often in expensive rework so the goal of case is to develop design analysis and verification tools that allow system engineers to design in cyber resiliency and manage trade offs like they would do with other non functional properties when designing complex embedded computing systems. So you can think of this is how do we provide tools to automate much of the work that we did by hand in the hackams program. So the tool suite that we've developed for this program is called briefcase. And what it is is an integrated model based system engineering tool suite based again on ADL. The idea is to help users to be able to transform their system design models to satisfy cyber resiliency requirements and provide as much automation as possible and doing that. We generate new high assurance components from formal specifications. We verify the system design using formal methods and generate and document the evidence produced and compliance with requirements by means of an assurance case that's being built up in the in the background by the tool. And then finally we generate this all the software integration code directly from verified architecture models targeting multiple operating systems and kernels including SEL four. We've chosen ADL for our architecture language here because it's sufficiently rigorous and that provides the semantics that we need to support analysis it's at the right level of abstraction. Being targeted at distributed real time embedded systems and supports construction you can actually generate code from an ADL model and deal satay open source. The ADL tool environment supports addition of new capabilities like that we developed in the case program. So here's a quick use case that more or less corresponds to some of the things that we did in hack them as a cyber retrofit where we're trying to deal with some legacy code we're not always in effect almost never starting from scratch when designing systems. So the process that the tool helps you can help you go through in this case is virtualizing the legacy system, hosting it on SEL four, extracting hardening specific critical components, possibly filtering the inputs to make sure that no malformed inputs are sent into the the legacy software to try to cause harm and then monitoring the outlets to make sure that everything is performing correctly and intervening if necessary. So you see at the bottom left here very simple ADL model of the gravy after applying the tools and transforms from the case, the briefcase tools. We've inserted a bunch of new components, most of this is done automatically under user guidance, and we're automatically collecting verification evidence in the in the background. We have also some demos of the briefcase briefcase tools in action on our website the first video kind of walks through the use of the briefcase tool environment, addressing multiple cyber resiliency requirements for a UAB mission computing system. And then there's another demo sort of showing the same before and after effects of hardening the system using the tools here's a, here's an attack that worked on the baseline system and now you can see it's defeated on the hardening system. So we're like in hackens we're moving in the final phase of the program to a real military system or applying these tools to the Collins come in the avionics architecture system or cast which is employed and a number of military vehicles including the army CH 47 that's helicopter. And that work is ongoing right now. We have a hacking activity set up in aerospace village that you can take advantage of to get some hands on experience with some of the stuff that we did in the hackens program. We've got that quadcopter. Just like I showed in the demo system earlier. We'll have the ability for you to log in to the Linux VM which is hosted on a CL for with root access running on the quadcopter mission computer. And just as I described the encryption keys for the, the telemetry links are stored in a separate CL for component. So if you're having logged in, you're in the, you have access to the VM. The goal is to see, you know, if you can, can you see, read or write these, these keys, first of all, we'll have some pre stage attacks or you can bring your own attacks to run on the Linux software and absorb the effects on the quadcopter operation, determine whether you know crashing the camera software or crashing the entire Linux VM will impact that the telemetry is not supposed to. And then finally, the main goal is to see if you can bypass the CL for separation to read or write the encryption keys or possibly do worse. Somehow affect the operation of the vehicle like we showed in the demonstration. Sadly, we're not flying quadcopter this is all a bench demo, but so it's a it's a it's a real system and cleaning to see operation. So wrapping up in the DARPA hackings and case programs we developed a suite of model based system engineering tools for cyber resiliency, these tools use formal methods to automatically transform architecture models. Improve that the system is correct with respect to cybersecurity safety and functional requirements system implementation can be automatically generated from verified models. Targeting Linux or the formally verified SEO for secure kernel. And importantly, we've applied the tools to real systems real aircraft to show that they're both practical and effective. There's the links again to the code papers videos on the website for both the hackings in the case project. Thank you for listening today.