ISOLATING UNTRUSTED SOFTWARE
ON SECURE SYSTEMS –
HYPERVISOR CASE STUDY
Dr. Gregg Wildes
DornerWorks
www.DornerWorks.com
Embedded Systems Engineering
Embedded Electronics Engineering
Motivation for Trusted/Untrusted Software
Security and Safety
Hypervisor
Motivation – Connected World
We Live in a Material World
We Live in a Connected World
Motivation – IoT “Things”
We Live in a Connected World
Is a Vehicle IoT?
DARPA Automotive Security Project, “This fact, that a car is not a simple machine of glass and steel but a hackable network of computers.”
“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.
Motivation
Federated vs. Integrated
Historically, aircraft had many independent systems running
Motivation
Federated vs. Integrated
With modern computing, previously independent systems are
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.
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.
Hypervisors & Virtualization
What is
Simultaneous Benefits
Security Multiple Independent Levels of Security (MILS)
Common Criteria (CC) Evaluation Assurance Level (EAL) up to 7 Add security features
Trusted Platform Modules (TPM) Secure kernel objects
Firmware module “signing and verification”
Safety
Certification artifacts and models
DO-178C Certification with Design Assurance Level A, ARINC 653 Partitioning IEC 61508 Sufficient Independence
Performance
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.
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
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
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
Xen Hypervisor Cross Domain Solution
Evolution – Xilinx Collaboration
Business critical support for Xen hypervisor
“Like Red Hat for Linux”
www.Xen.world
Related technical expertise:
Xilinx Premier Design Partner - FPGA
Security vs. Safety Analysis
Safety Properties
System does good things Shall Requirements
Can be Tested
Well suited for DO-178B
Security Properties
Doesn’t do bad things Shall Not Requirements
Very difficult to test
Well suited for Formal Analysis
Mathematically rigorous verification techniques
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
Current Schedule PolicyStatement TaskList FreeBufferList Task[2] Configuration Kernel Heap Task[1] Current Schedule PolicyStatement TaskList FreeBufferList Task[2] Configuration Kernel Heap Task[1]
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.
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.
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
Embedded IoT = “Things”
Motivation – Connected Devices
Creates Vulnerabilities
Security and Safety
Hypervisor – Separation to Manage/Optimize
www.Xen.world
Questions?
Thank you!
Dr. Gregg Wildes
DornerWorks
www.DornerWorks.com www.Xen.worldEmbedded Systems Engineering
