The MILS Partitioning Communication System + RT CORBA = Secure Communications for SBC Systems Kevin Buesing Objective Interface Systems Field Applications Engineer kevin.buesing@ois.com Jeff Chilton Objective Interface Systems Senior Product Engineer jeff.chilton@ois.com This presentation represents joint research between the Air Force, Army, Navy, NSA, Boeing, Lockheed Martin, Objective Interface, Green Hills, Lynux Works, Wind River, GD, Rockwell Collins, MITRE, U of Idaho
Foundational Threats Privilege Mode Processing Buffer Overflow? Network Data Wild Creatures of the Net, Worms, Virus,... 9/16/2004 SBC 2004 2
Foundational Threats (That MILS Protects Against) Privilege Mode Processing Paradigm Shift Network Data Under MILS Network Data and Privilege Mode Processing is Separated 9/16/2004 SBC 2004 3
9/16/2004 SBC 2004 4
MILS Overview 9/16/2004 SBC 2004 5
The Whole Point of MILS Really simple: Dramatically increase the scrutiny of security critical code Dramatically reduce the amount of security critical code 9/16/2004 SBC 2004 6
What does MILS do? Executive Overview MILS Architecture Objectives Enable the Application Layer Entities to Enforce, Manage, and Control Application Level Security Policies in such a manner that the Application Level Security Policies are Reference Non-bypassable Monitor Evaluatable Concept Always-Invoked Tamper-proof MILS = Multiple Independent Levels of Security/Safety 9/16/2004 SBC 2004 7
MILS Architecture Objectives How does MILS achieve its objectives? Enforce an Information Flow, Data Isolation, Periods Processing, and Damage Limitation Security Policy between multiple address spaces: First, in a Microprocessor Centric Manner, i.e., MILS RTOS Kernel, Second, in a Network Centric Manner, i.e., MILS Middleware, in such a manner that the layered Security Policies are N E A T 9/16/2004 SBC 2004 8
Orange Book vs. MILS Architecture CSCI (Main Program) Monolithic Applications User Mode Middleware Damage Limitation Network I/O Partitioning Monolithic Kernel File systems Mathematical Verification/ Evaluation Periods Processing Kernel Auditing Information Flow DAC Data isolation MAC Device drivers Privilege Mode 9/16/2004 SBC 2004 9
Executive Overview MILS Three Layer Architecture Three distinct layers (John Rushby, PhD) Partitioning Kernel Trusted to guarantee separation of time and space Separate process spaces (partitions) Time partitioning Secure transfer of control between partitions Really small: 4K lines of code 1. Middleware Secure application component creation Secure end-to-end inter-object message flow Most of the traditional operating system functionality Device drivers, file systems, etc. Partitioning Communications System Extends the policies of Partitioning Kernel to communication Facilitates traditional middleware Real-time CORBA, DDS, web services, etc. 2. Applications Can enforce application-specific security functions e.g., firewalls, crypto services, guards 9/16/2004 SBC 2004 10
Layer Responsibilities Partitioning Kernel Functionality Time and Space Partitioning Data Isolation Inter-partition Communication Periods Processing Minimum Interrupt Servicing Semaphores Timers Instrumentation MILS Middleware Functionality RTOS Services Device Drivers CORBA File System Partitioned Communication System Inter-node communication And nothing else! 9/16/2004 SBC 2004 11
Executive Overview MILS Architecture High Assurance Application (User Mode) Partitions MILS - Multiple Independent Levels of Security MSL - Multi Single Level S TS S,TS MLS - Multi Level Secure SL - Single Level (SL) (SL) (MLS) Keyboard Device Driver (MSL) File Sys Device Driver (MSL) Network Interface Unit (MSL) PCS (MSL) RT CORBA Run Time Libraries RT CORBA Run Time Libraries RT CORBA Run Time Libraries RTOS Micro Kernel (MILS Partitioning Kernel) Supervisor Mode MMU, Inter-Partition Communications Interrupts Processor 9/16/2004 SBC 2004 12 45
Partitioning Kernel: Just a Start Partitioning Kernel provides Secure foundation for secure middleware Secure Middleware provides Most of traditional O/S capabilities File system Device drivers (not in the kernel, not special privileges) Etc. Secure intersystem communication (PCS) Secure foundation for building secure applications Secure Applications can Be built! Be trusted to enforce application-level security policies!!! 9/16/2004 SBC 2004 13
Distributed Security 9/16/2004 SBC 2004 14
Distributed Security Requirements Rely upon partitioning kernel to enforce middleware security policies on a given node Information Flow Data Isolation Periods Processing Damage Limitation Application-specific security requirements must not creep down into the middleware (or kernel) ensure the system remains supportable and evaluatable Optimal inter-partition communication Minimizing added latency (first byte) Minimizing bandwidth reduction (per byte) Fault tolerance Security infrastructure must have no single point of failure Security infrastructure must support fault tolerant applications 9/16/2004 SBC 2004 15
Distributed Object Communication Partition Local same address space, same machine Machine Local different address space, same machine Remote different address space, on a different machine Shared Memory Multicast Rapid IO TCP/IP 1394 ATM RACEway VME 9/16/2004 SBC 2004 16
Partitioned Communication System 9/16/2004 SBC 2004 17
Partitioned Communication System Partitioned Communication System Part of MILS Middleware Responsible for all communication between MILS nodes Purpose Extend MILS partitioning kernel protection to multiple nodes Similar philosophy to MILS Partitioning Kernel Minimalist: only what is needed to enforce end-to-end versions of policies End-to-end Information Flow End-to-end Data Isolation End-to-end Periods Processing End-to-end Damage Limitation Designed for EAL level 7 evaluation 9/16/2004 SBC 2004 18
PCS Objective Just like MILS Partitioning Kernel: Enable the Application Layer Entities to Enforce, Manage, and Control Application Level Security Policies in such a manner that the Application Level Security Policies are Non-Bypassable, Evaluatable, Always-Invoked, and Tamper-proof. An architecture that allows the Security Kernel and PCS to share the RESPONSIBILITY of Security with the Application. Extended: To all inter-partition communication within a group of MILS nodes (enclave) 9/16/2004 SBC 2004 19
PCS Requirements Strong Identity Nodes within enclave Separation of Levels/Communities of Interest Need cryptographic separation Secure Configuration of all Nodes in Enclave Federated information Distributed (compared) vs. Centralized (signed) Secure Loading: signed partition images Suppression of Covert Channels Bandwidth provisioning & partitioning Network resources: bandwidth, hardware resources, buffers 9/16/2004 SBC 2004 20
PCS Provides End-to-End: Information Flow Data Isolation Periods Processing Damage Limitation Executive Overview MILS Network Security Policy Example Policy Enforcement Independent of Node Boundaries RS E1 E2 BV CPU & Network Registers Switches, DMA, Red Network E3 Black Network RPM BPM D1 RV D2 BS System D3 9/16/2004 SBC 2004 21
MILS Replaces Physical Separation MILS architecture allows computer security measures to achieve the assurance levels as physically isolated systems All O/S code not necessary for performing Partitioning Kernel functions moved out of privileged mode O/S service code moved to middleware layer e.g. device drivers, file system, POSIX Prevents software and network attacks from elevating a partition privilege to an unauthorized level 9/16/2004 SBC 2004 22
Best Security/Safety is Physical (Air Gap) Processor R1 Processor R2 Processor Rn Intranet (Proprietary, Sensitive, Critical) App App App Internet (Public, Untrusted) App App App Processor B1 Processor B2 Processor Bn 9/16/2004 SBC 2004 23
Legacy Approach to Bridging the Air Gap (Good, Expensive, Physical Solutions Exist) Processor R1 Processor R2 Processor Rn Red App App App (classified, Sensitive, Critical) Very high assurance Off-the-shelf solution SNS One- Way Gate Write- Down Guard Office environment only Extra hardware Black (unclassified, Public, Untrusted) App Processor B1 App Processor B2 App Processor Bn 9/16/2004 SBC 2004 24
Air Gap Solution to SDR Separate Hardware Modem Crypto Engine Red Processor Channel A (Top Secret) Modem Crypto Engine Red Processor Channel B (Secret) Modem Crypto Engine Red Processor Channel C (Confidential) Modem Crypto Engine Red Processor Channel D (Unclassified) This Is Current Stovepipe Technology That Is Expensive And Inflexible 9/16/2004 SBC 2004 25
A Simple Application of MILS to SDR Separate Processor Resources Modem Crypto Engine Red Processor Channel A (Top Secret) Modem Crypto Engine Red Processor Channel B (Secret) Modem Crypto Engine Red Processor Channel C (Confidential) Modem Crypto Engine Red Processor Channel D (Unclassified) AND AND Need MILS Solution Here! Need MILS Solution Here! Need MILS Non Real-Time Operating Environment Solution Here! 9/16/2004 SBC 2004 26
Introduction MLS/MSLS Multi-Level Secure/Safe (MLS): Processes data of differing classifications/sensitivities securely/safely down graders data fusion guards firewalls data bases Multi-Single Level Secure/Safe (MSLS): Separates data of differing classifications/sensitivities securely/safely simultaneously communications platforms infrastructures 9/16/2004 SBC 2004 27
MILS Can Handle MLS A Partitioning Kernel is ignorant of traditional Multi-Level Security (MLS) Requirement for military and intelligence systems However, MILS is quite capable of supporting MLS systems MILS can be used to construct MLS systems because of Strong separation guarantees Certification process 9/16/2004 SBC 2004 28
Applying MILS to Software Defined Radio 9/16/2004 SBC 2004 29
Example JTRS Joint Tactical Radio System Family of software programmable radios Design around Software Communications Architecture JTRS provides reliable multichannel voice, data, imagery, and video communications Eliminates communications problems of "stovepipe" legacy systems JTRS is: Modular, enabling additional capabilities and features to be added to JTR sets Scaleable, enabling additional capacity (bandwidth and channels) to be added to JTR sets Backwards-compatible, communicates with legacy radios Allowing dynamic intra-network and inter-network routing for data transport that is transparent to the radio operator 9/16/2004 SBC 2004 30
MILS Roadmap MILS Crypto Engine & Emb OE Modem BLACK MLS Crypto Apps TS Channel Modem Modem Modem MILS Crypto Engine RED MILS Middleware MILS RTOS Microprocessor S Channel C Channel U Channel 9/16/2004 SBC 2004 31
Designing an MLS Component MLS Middleware Component Classified network (Red), labeled messages Ex: Cryptographic downgrader, such as JTRS or trusted network interface unit Unclassified Network (Black) 9/16/2004 SBC 2004 32
Designing an MLS Component Encryption Engine(s) (MLS) Classified network (Red), labeled messages Red Network Interface Unit (MLS) Decryption Engine(s) (MLS) Blk Network Interface Unit Unclassified Network (Black) 9/16/2004 SBC 2004 33
Designing an MLS Component MLS E1 Certified Downgrader RS E2 BV E3 Red NIU (MLS) Blk NIU Classified network (Red), labeled messages RV D1 D2 BS Unclassified Network (Black) D3 Single Level Components (MSL) 9/16/2004 SBC 2004 34
Designing an MLS Component E1 Certified Downgraders RS E2 E3 BV Red NIU Blk NIU (MLS) Classified network Certification Requirements: (Red), labeled D1 Incoming messages will be encrypted with the messages specified algorithm RV and D2key BS Output is strongly encrypted D3 Each device downgrades from one specific level to unclassified Unclassified Network (Black) 9/16/2004 SBC 2004 35
Designing an MLS Component MLS E1 RS E2 E3 BV Classified network (Red), labeled messages Red NIU (MLS) Blk NIU Certification D1 Requirements: Unclassified Network RV Messages D2 from BS either side will maintain (Black) labels and contents D3 Periods processing (transaction based) unit 9/16/2004 SBC 2004 36
Designing an MLS Component MLS E1 RS E2 E3 BV Classified network (Red), labeled messages Red NIU (MLS) Blk NIU Certification Requirements: Messages from NIU will be routed to D1 Unclassified appropriate encryption unit Network RV D2 BS Periods processing (transaction based) (Black) unit D3 9/16/2004 SBC 2004 37
Designing an MLS Component MLS Classified network (Red), labeled messages E1 Certification Requirements: RS E2 BV Messages from decryption units will be labeled correctly before E3 sending to NIU Periods processing (transaction based) unit Red NIU Blk NIU (MLS) RV D1 D2 D3 BS Unclassified Network (Black) 9/16/2004 SBC 2004 38
Designing an MLS Component Black Communication Links Certification Requirements???: Tamperproof, Non bypassable, Evaluatable E1 RS E2 E3 BV Red NIU (MLS) Blk NIU Classified network (Red), labeled messages RV D1 D2 BS Unclassified Network (Black) Red Communication Links D3 Certification Requirements: Tamperproof, Non bypassable, Evaluatable 9/16/2004 SBC 2004 39
The MILS Architecture Approach Describe the system in terms of communicating components Designate the clearance of each component and label as MLS or MSL Determine the flow between components with respect to policy Install boundary firewalls that manage information up-flow and down-flow these are MLS components 9/16/2004 SBC 2004 40
The MILS Architecture Approach For each MLS device, determine its type Downgrader will take data from one security level and send data at a lower level Transaction processor will process data one message at a time; stateless, may filter data or perform operation on single message Collator will combine data from many inputs Verification of each device may involve additional MILS componentization 9/16/2004 SBC 2004 41
Implementation Hierarchical Approach Lowest level is separation kernel enforces isolation, information flow, periods process, damage limitation on a single processor Next level is middleware, to coordinate end-to-end separation Need to create trusted components. Verification of the components utilizes architectural support of lower layer Next Level is application specific 9/16/2004 SBC 2004 42
Acronyms MILS Multiple Independent Levels of Security/Safety MSLS Multiple Single Level Security/Safety MLS Multi-Level Secure/Safe PCS Partition Communication System CORBA Common Object Request Broker Architecture NEAT Non-bypassable, Evaluatable, Always-invoked,Tamper-proof NIU Network Interface Unit ORB Object Request Broker O/S Operating System CC Common Criteria EAL Evaluation Assurance Level ARINC 653 Safety Community Standard for Time and Space Partitioning DMA Direct Management Access MMU Memory Management Unit 9/16/2004 SBC 2004 43
Partners MILS Hardware Based Partitioning Kernel AAMP7 Rockwell Collins MILS Software Based Partitioning Kernel Integrity-178 LynxOS-178 VxWorks AE Secure Green Hills Software LynuxWorks Wind River MILS Middleware PCS and ORBexpress MILS TestBed MILS TestBed Objective Interface Systems, Inc. University of Idaho Naval Post Graduate School 9/16/2004 SBC 2004 44