Medium and High Assurance Solutions for

Developing Distributed Real-Time Systems

September 12, 2007

•Acknowledgments to collaborators:Rance DeLong (LW), John Rushby (SRI), AFRL, LM Aero, Raytheon, NSA and other members of the MILS community

2

Presenters for Today…

Joe Wlad, director of product marketing at LynuxWorks, has more than 23 years of safety-critical systems design, development, test and evaluation experience at companies such as Intermetrics, Inc., McDonnell-Douglas Aircraft Company and United Airlines. Formerly a senior product and project manager at Wind River Systems, Wlad is a FAA DER for Systems and Equipment and Software and has co-authored three patents on Global Positioning System integrity functions.

Jan Van Bruaene, senior applications engineer at RTI, has over ten years experience in software engineering with expertise in designing distributed systems, middleware, network protocols and I/O devices. Prior to RTI, Jan was a staff engineer with Sun Microsystems, where heworked with Independent Software Vendors, making their software run on Solaris systems. Jan also worked at VLSI Technology in the network products group on networking ASICs and embedded systems. Jan holds a Master's degree in Electronic Engineering from KIHK, Geel, Belgium.

3

What you will learn today

This talk will provide an overview of two technologies that address medium and high assurance software requirements– RTI has implemented a secure communications with its Data

Distribution Service (DDS) compliant middleware, addressing medium assurance requirements

– LynuxWorks' LynxSecure Separation Kernel is a Multiple Independent Levels of Security/Safety (MILS)-compliant real-time operating system. MILS ensures that tasks running at different security levels are safe from cross-level information leakage

Also addressed are:– Common Criteria, Medium and High Assurance overview– MILS architecture: MILS supports isolation between software

running at differing security levels on a single processor

4

Agenda

Common Criteria Review– Contrast Medium and High Assurance

Secure Data Communication– RTI Data Distribution Service and RTI Secure Transport

Introduction to High Assurance and MILS

5

Common Criteria (CC) OverviewA “common language and structure for expressing IT security requirements in a manner that allows those requirements to be used to evaluate … products”*Multiple criteria**:– Metric for documenting design, implementation, and maintenance– Methodology for installing and testing a product against a

documented design and guidance– Metalanguage and methodology to create comparable security for

IT products and systems– Method to compare security functionality and assurance between

commercial products of like technologiesAssurance based on:– Development environment– Developer actions– Presentation of evidence– Independent evaluation

* Ben Calloni, LM/Aero ** Robert Williamson, SAIC

6

Evaluation Assurance Level

The Common Criteria define Evaluation Assurance Levels (EALs) from 1 to 7.– Untested No assurance– EAL 1-4 Risk Management – EAL 5-7 Risk Avoidance

EAL 1-4 are the Basis for Mutual Recognition in the international community EAL 5-7 have not been agreed upon internationallyEAL 5-7 require a Reference Monitor (RM) that is Always Invoked, Non-Bypassable, Tamper Proof, and Evaluatable. RM is implemented with respect to an Information Flow and Data Isolation PolicyOnly one operating system evaluation and validation above EAL4 has been completed under the Common Criteria in the United States, XTS-400 at EAL5

7

Common Criteria Evaluation Assurance Levels (EALs)

EALEAL 1EAL 2EAL 3EAL 4EAL 5EAL 6EAL 7

NameFunctionally TestedStructurally TestedMethodically Tested & CheckedMethodically Designed, Tested & ReviewedSemiformally Designed & TestedSemiformally Verified Design & TestedFormally Verified Design & Tested

8

System Modes and Assurance Levels

Common Criteria Security AccreditationEAL 3 System HighEAL 4 System High w/ Type Separation

(SECRET NOFORN / SECRET NATO)

EAL 5 - (RM) * 1 Level Separation (TS/S;S/C;C/U)EAL 6 - (RM) * 2 Level Separation (TS/S/C;S/C/U)EAL 7 - (RM) * 3 Level Separation (TS/S/C/U)* - RM: Reference Monitor

Medium Assurance EAL 1-4

High Assurance EAL 5-7

Securing Data Communication Using

RTI Data Distribution Serviceand DTLS

Jan Van BruaeneSenior Applications Engineer

10

Topics

Introduction to RTI Data Distribution Service– Standards– DDS key concepts– Network and transport

RTI Secure Transport– Overview DTLS– RTI Secure Transport details– Use case: Secure WAN

11

Standards Compliance:Data Distribution Service for Real-Time Systems

Object Management Group (OMG)Broadly adopted:– DISA: DISR mandated for publish-

subscribe data distribution– Navy: Open Architecture, FORCEnet– Air Force, Navy and DISA: NESI

(SPAWAR)– Army: FCS / SOSCOE– Coflight air traffic control system for

southern EuropeRTI is world’s leading supplier of DDS software and services– >80% market share– Standard based on RTI’s Data

Distribution Service middleware, available since 1996

Real-time publish-subscribe

wire protocol

RTI DataDistribution Service

DDS API

Standards-based API for application developers

Open protocol for interoperability

12

Key concepts of RTI Data Distribution Service

1. Anonymous Publish-Subscribe

2. Data Centric Interfaces

3. Real-Time Quality of Service Control

13

Publish-Subscribe InterfacesWell-Suited to Data Distribution

Decouples publishers and subscribers – “Anonymous”• Location: reduce dependencies• Redundancy: multiple readers & writers• Time: data when you want it• Platform: Connect any set of systems

Automatic discovery

Subscriber

SubscriberPublisher

PublisherTopicTemp

14

Data-Centric Interfaces

Publisher

Subscriber

Subscriber

Subscriber

Collisionavoidanceapplication

Radar TrackAirlineFlight #Latitude

LongitudeAltitude

All samples

Airline operations center

Airline=“Virgin Air”

Within my latitude, longitude and altitude range

Database, real-time log

Visualization toolse.g., RTI Analyzer, RTI Scope andSL Enterprise RTView

Web services, XML, JMS,

Complex Event Processing

Messages addressed by topic and keyStandard message definition language and binary marshallingContent-aware message delivery

15

Real-Time Quality of Service Control

Quality of Service (QoS) determined per-entityQoS Contract: Request - OfferedPublishing and subscribing applications can be notified when messages lost or deadlines missedHigh availability via automatic failover

Subscriber

Subscriber

Subscriber

Collisionavoidanceapplication

Radar TrackPublisher

Reliable; 1 Hz;

get history

Best effort; 0.2 HZ;get history

Airline operations center

Best effort; 0.01 Hz;no history

Database, real-time log

• Publish reliably• 10 Hz• Keep 10 minute history

(6000 samples)

Reliable; all new data;

get historyBackup

Publisher

16

Network and Transport

True peer-to-peer communication doesn’t require a shared “daemon” processes, brokers or serversStandard Wire Protocol (RTPS) handles discovery and marshalling of dataBest effort and reliable messaging– Supports slow and unreliable links– Reliability protocol tunable to balance latency and overhead

Choice of transport: Pluggable transports architecture. – UDPv4 and UDPv6 (unicast and multicast)– Shared memory– Secure Transport

17

Datagram Transport Layer Security

Protocol capable of securing datagram transport– Suited for “delay-sensitive” applications– RFC 4347 ; Selected by IETF as a standard for

secure VOIPBased upon TLS, can work on datagram-based transports, including UDP– Keeps application interfaces similar to TLS– Functionally equivalent to TLS in other respects– Includes provisions to handle

loss of data re-ordering of datadata larger than datagram size

Performance impact of cryptographic algorithms

18

DTLS Illustrated

ServerClientClient Hello

Cookie exchange protects against DoS attacks

cookie HelloVerifyRequestClient Hello Verifies message and

Extract client ClipherSuite and Compression algorithm

Server HelloCertificate; ServerKeyExchangeServerHelloDone

Handshake

Generate Premaster SecretDecrypt using server private keyCertificate; ClientKeyExchangeIndicate Cipher Suite to be usedChangeCipherSpec

Finished Decrypt and verify message content integrity with Cipher Suite and keys

ChangeCipherSpecFinished

Application DataApplication Data

Client HelloReauthentication

19

RTI Secure Transport

Built on top of OpenSSL 0.9.8– OpenSSL is de facto standard open source TLS/SSL– Modified to support DTLS – Well tested - cryptographic algorithms are easy to

get wrong, resulting in security flaws– Validation for FIPS 140-2: Security Requirements for

Cryptographic ModulesU.S. federal agencies must use FIPS-compliant products to secure networks carrying unclassified but sensitive data. Software products using OpenSSL will also be validated

Can be used to secure unicast discovery data and/or user data

20

RTI Secure Transport

DTLS is semantically client-server. With minor extensions, can be used for peer-to-peer communication.– Each writer is a DTLS client– Each reader is a DTLS server– Reliable communication: both client and server

Initial_peers specify who to contact during discovery using which transportTransport Properties to configure e.g.– Cipher list in OpenSSL format– Certificate info (X.509)– Reauthentication (time / MB of data based)

21

Example: Securing WAN communication

ServerApplication 1

RegisterConnect to APP 2

Register

APP2 public address APP 1 public address

Connect

DTLS handshaking

RTPS discovery

RTPS user traffic

Application 2

RTI

DTLS

RTPS Discovery TrafficRTPS User Traffic

NAT

STUN

Application 1

RTI

DTLS

STUN

Application 1

TLS handshaking Encrypted RTPS

STUN trafficTLS traffic

STUN traffic

NAT

RTI WAN Rendezvous Server

MILS approach to High Assurance and

LynxSecure Separation Kernel

Open.Reliable.Safe.Secure. Joe Wlad, Marketing Director

23

The Challenge

How can the USAF, other DoD services and agencies affordably certify and field MLS solutions

on their systems and platforms?

Courtesy of AFRL

24

High Assurance Security Issues

Connected Systems– Information Protection is not guaranteed

Medical and Financial applications, e.g., cell phones now used for banking

– SSL, IPSec are used at the network layer for encryption

– Security at the embedded foundation has not been adequately addressed

Mobile Code– Active-X, Java Applets, etc.– Embedded software not designed to quarantine

malicious device drivers

25

Security Issue Examples

• Helicopter maintenance data classified as “Secret”Current Solution: Pilots manually downgrade information or maintenance personnel need secret clearance

Tanker aircraft needs required data links to fly in civil airspace and military data linksCurrent Solutions: Some have no access to civil data links; some have roll-on access to military data links – systems are separate

26

Current measures used to handle multilevel data

Physical Separation by Level and Community of Interest– Multiple servers in data centers– Multiple networks connecting the same

endpoints– Multiple workstations on a single desk– Information sharing via the Sneaker Net

requiring significant human intervention

27

Classified S/W

Unclassified Software

RTOS

GREEN uP

RTOS

Yellow Interface

ASIC/uP

RED uP

Hardware Separation to meet Security Requirements

Today’s designs require multiple RTOS’ and microprocessorsCostly special evaluations for each design

28

Approaches to Secure Architectures

Separate Systems(Unevaluated)

Security Kernel-based(Unevaluatable)

Separation Kernel-based(Modularly Evaluatable)

UntrustedApps

TrustedApps

MonolithicSecurity Kernel

UntrustedApps

Separation Kernel

ModularTrusted Middleware

ModularTrusted Services

Untrusted OSand Applications

Untrusted OSand Applications

Untrusted OSand Applications

Untrusted OSand Applications

Untrusted OSand Applications

MonolithicTCB Extensions

29

Security Kernel / TCB Approach

Privileged ModeDevice drivers

AuditingFile systems

Information Flow

Data isolation

MAC

(BLP)

DA

C

Security Kernel

Monolithic Applications

UserMode

TCBExtensions

Courtesy of Ben Calloni

30

A proposed solution

Rushby’s 1981 seminal paper proposed the Separation Kernel making these observations:– Complications result when a security kernel is used to impose a

single system-wide security policy– Applications requiring guaranteed security often perform simple

functions– Distributed systems achieve security while avoiding difficulties

arising from the security kernel approach– A conceptually distributed system may be supported on a single

processor by a separation kernel– A separation kernel can be verified w/ high-assurance– Could decouple SK verification from other components

Unfortunately, until the last decade, <10,000 partition switches per second would completely use up a processor

31

Separation Kernel

Interest in the Separation Kernel (SK) concept has been renewed by advancements in processor performance:– 60,000 partition switches per second still leaves 95+% of a processor– Needed for safety- and security-critical apps & critical infrastructure

The SK is the foundation for the MILS architecture and must meet the highest standards in:– FAA DO-178B Level A Safety Technology (technically conservative)– Common Criteria EAL 7-ish Security Technology (technically progressive)

SK’s security policy is data isolation and information flow control– SK is Small: ~ 4K SLOC– SK is small enough to analyze, always invoked and tamper-proof

All other OS and Middleware services and applications reside in user mode– Leverage SK guarantees to enable “application” layers to

enforce, manage & control their own policies– Implement reference monitors for higher level policies that are

simple enough to analyze, non-bypassable and tamper-proof

32

SK Security Policies

Data Isolation– Information in a partition is accessible only by that partition

unless it is explicitly shared according to the information flow policy

– The confidentiality of local unshared data is protected– The integrity of local unshared data is protected– Subverted or faulty partitions cannot affect data in another

partition except according to authorized information flowsInformation Flow Control– Information flows only through provided channels– Information originates only from an authorized source– Information is delivered only to an intended destination– Source and destination are mutually authenticated– No unauthorized information flows are permitted

33

MILS Architecture Approach

ApplicationsMLS App(Main Program)

MLS RequiresCertifiable

Applications

CertifiableApplicationsOn CertifiableInfrastructure

MILS MiddlewareDevice drivers

Auditing

File systems

MAC policyDAC policy

Networking

Privileged Mode

Certifiable

UserMode

Separation KernelInformation FlowData Isolation

Courtesy of Ben Calloni

34

MILS “Three Layer” Architecture

Separation Kernel– Trusted to guarantee time and space separation

Separate memory spaces (partitions)Partitioning of processor time

– Secure transfer of control between partitions– Small and structured for verification

“MILS Middleware”– Most of the traditional operating system functionality

Device drivers, file systems, networking, access control mechanisms, web services, etc.

– Partitioning Communications SystemExtends the policies of Separation Kernel to other processing nodesSecure end-to-end inter-partition message flowFacilitates traditional middleware

– Secure application componentsApplications

– May enforce application-specific security policies and functions– e.g., firewalls, crypto services, guards, system management

35

Multi-layer Architecture for Multilevel Security

Separation Kernel: Isolation & Information Flow Control Policy,Partitions, Subjects, Exported Resources, Communication, Synchronization

Extended Security Attributes &Reference Validation Mechanisms

MLS Filesystem:Dirs, Polyinstantiation

MLS Networking:Labels, Crypto, Routing

MLS Console:Windows, Trusted Path

Other MLSServices

MLS Server

MLS Resources: Subjects, Objects, Namespaces,Label Interpretation, Device Allocation

MLS Desktop

PCS

CORBA

Audit

MLSDBMS

MLSWebserver

MLS GenericGuard/Regrader DDS

CryptoPrimitives

UntrustedGuest

OperatingSystem(s)

UntrustedApps

VirtualDevices

Ident’n, Authent’n,Authoriz’n, Acct’g

Interrupts,Exceptions Minimal High-Assurance APIs: POSIX, ARINC Devices

Hardware: Instruction Set Architecture, MMU, VM Support, Privileged Operations

36

Multi-layer Policy Enforcement

UntrustedApplications

MLS Apps/Subsystems

MLS Policy: SS, *-property,MCS, Regrader, Guard, Pump, …“Application”

MLS entitiesand attributes

MLS entities: Subject/ObjectIdentities, Labeling, PCS

“Supporting”

SeparationKernel

SK Policy: Partitions, Subj/Res,Isolation, Data Flow, Privileges

“Prevailing*”

Hardware“Foundation” HW Policy: Sup/User Modes,User/Privileged Instructions

* SK configuration minus flows between a trusted subsystem and its clients

37

LynxSecure ArchitecturePartition 0 Partition NPartition 2Partition 1

Hardware

LynxSecure Separation Kernel (EAL7)

User Mode

Supervisor Mode

Minimal Run-time

Open Standards API

Middleware

LynxOS-SE

Open Standards API

Windows* Linux

Open Standards API

POSIX

POSIXApp

APEX

ARINC653App

API

WinApp

GLIBC

LinuxApp

Middleware

App

App

App

App

Windows API

TrustedNetwork

Stack

TrustedFile

System

TrustedBSP&

Drivers

*Future Support

38

LynxSecure Usage Model

Hardware

LynxSecure Separation Kernel (EAL7)

User Mode

Supervisor Mode

Linux (PVM) Linux (UVM) Linux (UVM)

XServer NFSServer

XclientMpegplayer

NFSclient

XclientMpegplayer

NFSclient

Inter Partition TCP/IP

Partition 0 Partition 2Partition 1

39

LynxSecure Provides Migration & ScalabilityStand-Alone

X86 Processor

Microsoft WindowsTM

Windows Applications

Processor

Blue Cat Linux

Linux Applications

Processor

Minimal Runtime

1-Partition MILS App

Processor

LynxOS / LynxOS-178

LynxOS / Linux Apps

Applications Unchanged

LynxSecure SK

LynxSecure Separation Kernel

LynxOS / LynxOS-178

LynxOS / Linux Apps

Blue Cat Linux

Linux Applications

Minimal Runtime

MILS Application

Processor(s) (SMP and/or multi-node scalability with PCS)

x86 VM

Microsoft WindowsTM

Windows Applications

40

LynxSecure SK Enhanced Features

Symmetric MP and multi-core supportParavirtualizedinterfaceMinimal Runtime interfaceMultiple address spaces / subjects per partitionFull virtualization to run unmodified OSs

Zero-copy high-performance bulk interpartition commTrusted services extensionsTrusted object managersFine-grained privilegesVirtual networking among guest OSs

Partition and subject-resource policy abstractionPartition families with delegationDynamic configurationHigh-assurance integrated development environment

41

Summary

RTI Secure Transport provides secure communication between DDS-based applicationsMILS is a cost-effective solution to challenging security and safety problems in defense, government, critical infrastructures, and commerceLynxSecure is an advanced SKPP-conformant separation kernel providing enhanced features and taking advantage of Intel’s cutting edge hardware technologies while providing the foundation for a rich universe of applications

42

Thank you!

Q&AFor more information– info@rti.com– www.rti.com– info@lnxw.com– www.lynuxworks.com– www.omg.org