ISOLATING UNTRUSTED SOFTWARE ON SECURE SYSTEMS HYPERVISOR CASE STUDY

Transcription

1 ISOLATING UNTRUSTED SOFTWARE ON SECURE SYSTEMS HYPERVISOR CASE STUDY Dr. Gregg Wildes DornerWorks Embedded Systems Engineering for Security and Safety-Critical Systems Where Hardware and Software Meet

2 Overview & Context Embedded Electronics Engineering Motivation for Trusted/Untrusted Software Security and Safety Hypervisor 2

3 Motivation Connected World We Live in a Material World We Live in a Connected World 3

4 Motivation IoT Things We Live in a Connected World DornerWorks focuses on the Things in IoT. Embedded devices are increasingly inter-connected. 4

5 Is a Vehicle IoT? Vehicle Vulnerabilities 5

6 Security or Safety? DARPA Automotive Security Project, This fact, that a car is not a simple machine of glass and steel but a hackable network of computers. Charlie Miller (left) and Chris Valasek behind their Prius dismantled dashboard. 6

7 Safety or Security? The vulnerabilities that we found were the kind that existed on PCs in the early to mid-1990s, when computers were first getting on the Internet, Professor Stefan Savage, UCSD. 7

8 Motivation Federated vs. Integrated Historically, aircraft had many independent systems running specific applications flight management, navigation, controls... 8

9 Motivation Federated vs. Integrated With modern computing, previously independent systems are now integrated into a few computing platforms. Reduced SWaP (Size, Weight and Power) 9

10 Motivation Federated vs. Integrated As microprocessors become more powerful, previously independent systems are now integrated on to one computing platform. Isolated vs. Connected In the past, embedded devices were generally isolated from broader networks. Today, embedded devices are increasingly inter-connected. 10

11 Safety or Security? 11

12 Problem Need a Secure AND Safe embedded platform solution, without compromising Performance Security concerns in safety-critical systems are now paramount; and Aerospace & Defense, Medical, and Automotive markets are all demanding solutions. our open-source, open-architecture hypervisor provides safety, security, and performance on an embedded platform. 12

13 Hypervisors & Virtualization What is virtualization? 10/28/2015 DornerWorks Proprietary - do not disclose

14 Architecture 14

15 Simultaneous Benefits Security Multiple Independent Levels of Security (MILS) Common Criteria (CC) Evaluation Assurance Level (EAL) up to 7 Add security features Safety Trusted Platform Modules (TPM) Secure kernel objects Firmware module signing and verification Certification artifacts and models DO-178C Certification with Design Assurance Level A, ARINC 653 Partitioning IEC Sufficient Independence Performance New performance features: Multicore processors, Interrupt I/O 15

16 Evolution - DornerWorks IR&D DornerWorks evaluated hypervisor options: Open source vs. proprietary hypervisor solutions DornerWorks enabled security and safety certification of systems. Some say secure or safe, we set out to prove it. 16

17 Evolution - Navy SBIR Isolation Techniques for Untrusted Software Evaluated security and performance for the ARINC 653 CPU scheduler Established the feasibility of formal modeling for security Mock certification reviews for safety conducted by FAA DER consultant using Stage Of Involvement (SOI) audits White hat hacker testing 17

18 Evolution - DARPA SBIR Space Hypervisor Development of payload hypervisor mission event scheduler. Conducted on-sight DARPA demonstration in February 2015, Program manager extremely impressed with maturity of product at this stage of the development High altitude balloon flights planned 18

19 TARDEC: Hypervisor Evaluation Cross Domain Solutions with Xen hypervisor Performing trade study on hypervisors Results will define embedded Xen future development: Cross Domain Solutions (CDS) for Secure communications Real time performance optimization for embedded military vehicles Supports multiple guest OS: Linux, Android, Windows, and others 19

20 Xen Hypervisor Cross Domain Solution Multiple levels of security on single integrated hardware platform 20

21 Evolution Xilinx Collaboration Business critical support for Xen hypervisor Like Red Hat for Linux Related technical expertise: Xilinx Premier Design Partner - FPGA Embedded Electronics Software & Hardware design 21

22 Security vs. Safety Analysis Safety Properties System does good things Shall Requirements Can be Tested Well suited for DO-178B PolicyStatement Current Schedule TaskList Security Properties Doesn t do bad things Shall Not Requirements Very difficult to test Well suited for Formal Analysis FreeBufferList Mathematically rigorous verification techniques Task[1] Task[2] Configuration Kernel Heap Hypervisor Security Evaluation Driven by Common Criteria / MILS/ SKPP High-Robustness Requirements Judicious use of scalable formal analysis techniques (Rockwell s DFL) Designed to minimize life-cycle cost Focused on high-value security concerns 22

23 Safety and Security Certification DO-178C, Level A Safety EAL 5* Security EAL = Evaluation Assurance Level EAL 6+ requires Formal Methods Analysis Does not flow in the other direction * Merging Safety and Assurance: The Process of Dual Certification for Software, Carol Taylor, Jim Alves-Foss, and Bob Rinker, University of Idaho Center for Secure and Dependable Systems. 23

24 Safety Design Assurance Levels Level A is the most critical failure level and a software failure here would result in a catastrophic failure condition for an aircraft. Level B would cause or contribute to hazardous/severe major failure condition for an aircraft. Level C would cause or contribute to major failure condition for an aircraft. Level D would cause or contribute to minor failure condition for an aircraft. Level E would have no effect on an aircraft. 24

25 Security Design Assurance Levels EAL7: Formally Verified Design and Tested EAL6: Semi-formally Verified Design and Tested EAL5: Semi-formally Designed and Tested EAL4: Methodically Designed, Tested, and Reviewed EAL3: Methodically Tested and Checked EAL2: Structurally Tested EAL1: Functionally Tested 25

26 Architecture 26

27 Hypervisor Demo 27

28 Summary & Take-aways Embedded IoT = Things Motivation Connected Devices Creates Vulnerabilities Security and Safety Hypervisor Separation to Manage/Optimize 28

29 Questions? Thank you! Dr. Gregg Wildes DornerWorks Embedded Systems Engineering for Security and Safety-Critical Systems 29