Secure Mathematically-Assured Composition of Control ...€¦ · © Copyright 2013 Rockwell Collins, Inc. All rights reserved. AADL model 8 /* The STM32F405 has 1024Kb of FLASH beginning

© Copyright 2013 Rockwell Collins, Inc. All rights reserved.

Secure Mathematically-Assured Composition of Control Models (SMACCM)

High-Assurance Cyber Military Systems

DARPA I20

PI meeting: 5-7 February 2013

Technical Area 4 – Research Integration

Darren Cofer (presented by Mike Whalen)


Outline

• UAS requirements

• AADL model

• Compositional verification

• Trusted build

2


Architecture-Driven Proofs

3


Requirements & challenge problems

• Challenge problem = “unit of demonstration”

• Purposes:

– Unrestricted version of a technical challenge derived from a restricted vehicle for use by university researchers (this is the definition from the HACMS BAA)

– Tangible technical challenge that demonstrates research results in an observable, measurable way

– Decomposition of a high-level requirement into simpler technical challenges or architecture-specific elements that are necessary to prove the higher level requirement

• It is this last purpose that challenge problems will suggest a number of behavioral requirements for the UAS

• Each challenge problem can be thought of as one or more requirements that must be satisfied

4


Requirements related to data flow • Only data from authorized senders shall be delivered to receivers.

• Data delivered from authorized senders shall be correct (that is, unmodified).

• Only commands from an authorized sender shall be executed by the vehicle.

• Alt: Data sent by authorized sender shall appear correctly (unmodified) in vehicle

memory, and only in intended location.

– Note that this formulation of the requirement relies on an assumption of no DoS attack, while the previous one does not.

• Received data shall be correctly validated according to the interface protocol.

5

Comm

Comm

Wireless network

Comm

good

credentials

bad

credentials

trusted

command

command Attacker

User Actuator

Control Laws

Validate command

Ground Station

Attacker

Vehicle


Requirements related to vehicle state

• The vehicle shall always reach its “secure” operational state after startup without accepting

input from unauthorized users (or possibly from any user at all).

• Maintenance (software modification) shall only be performed by authorized users at

appropriate times.

• Designated regions of the vehicle memory shall not be modified at any time.

• The only means to update the software components and configuration parameters shall be

through the maintenance port.

• A specified set of sensor inputs signifying “on ground” shall all agree before the

maintenance port is enabled.

• The maintenance port shall be disabled during system startup.

6

Modes

Boot

Operational

Maintenance

Secure


FM Workbench

7

A

B

C Assumption: Input < 20 Guarantee: Output < 2*Input

Assumption: Input < 20 Guarantee: Output < Input + 15

Assumption: none Guarantee: Output = Input1 + Input2

Assumption: Input < 10 Guarantee: Output < 50

Lute

Architecture Models

Trusted Build

Compositional Analysis

OSATE AGREE

Trans


AADL model

8

/* The STM32F405 has 1024Kb of FLASH beginning at address 0x0800:0000 and * 192Kb of SRAM. SRAM is split up into three blocks: * * 1) 112Kb of SRAM beginning at address 0x2000:0000 * 2) 16Kb of SRAM beginning at address 0x2001:c000 * 3) 64Kb of TCM SRAM beginning at address 0x1000:0000 * * When booting from FLASH, FLASH memory is aliased to address 0x0000:0000 * where the code expects to begin execution by jumping to the entry point in * the 0x0800:0000 address range. * * HWF4: In the original linker script, the first 0x4000 of flash was * reserved for the bootloader. For now, we'll place the application * at the start of flash until we start using a boot loader again. */ MEMORY { /* flash (rx) : ORIGIN = 0x08004000, LENGTH = 1008K */ flash (rx) : ORIGIN = 0x08000000, LENGTH = 1024K sram (rwx) : ORIGIN = 0x20000000, LENGTH = 128K ccsram (rwx) : ORIGIN = 0x10000000, LENGTH = 64K } /* Top of the user mode stack. */ _estack = 0x20020000; /* top of 128KiB of SRAM */ /* Error in the linker if heap and stack don't fit. */ _min_heap_size = 0; _min_stack_size = 0x400; OUTPUT_ARCH(arm) ENTRY(Reset_Handler) /* * Ensure that abort() is present in the final object. The exception handling * code pulled in by libgcc.a requires it (and that code cannot be easily avoided). */ /* EXTERN(abort) */

/* The STM32F405 has 1024Kb of FLASH beginning at address 0x0800:0000 and * 192Kb of SRAM. SRAM is split up into three blocks: * * 1) 112Kb of SRAM beginning at address 0x2000:0000 * 2) 16Kb of SRAM beginning at address 0x2001:c000 * 3) 64Kb of TCM SRAM beginning at address 0x1000:0000 * * When booting from FLASH, FLASH memory is aliased to address 0x0000:0000 * where the code expects to begin execution by jumping to the entry point in * the 0x0800:0000 address range. * * HWF4: In the original linker script, the first 0x4000 of flash was * reserved for the bootloader. For now, we'll place the application * at the start of flash until we start using a boot loader again. */ MEMORY { /* flash (rx) : ORIGIN = 0x08004000, LENGTH = 1008K */ flash (rx) : ORIGIN = 0x08000000, LENGTH = 1024K sram (rwx) : ORIGIN = 0x20000000, LENGTH = 128K ccsram (rwx) : ORIGIN = 0x10000000, LENGTH = 64K } /* Top of the user mode stack. */ _estack = 0x20020000; /* top of 128KiB of SRAM */ /* Error in the linker if heap and stack don't fit. */ _min_heap_size = 0; _min_stack_size = 0x400; OUTPUT_ARCH(arm) ENTRY(Reset_Handler) /* * Ensure that abort() is present in the final object. The exception handling * code pulled in by libgcc.a requires it (and that code cannot be easily avoided). */ /* EXTERN(abort) */


AADL model

9


AADL model

10


Compositional verification

• Components annotated with verified properties

– Assumptions and guarantees

• Reason about system properties based on component properties and relationships in architecture model

11

Example (to prove) AS AA

AS PA AB

AS PA PB AC

AS PA PB PC PS

Contract compliance:

G(H(A) P) A

B

C Assumption: Input < 20 Guarantee: Output < 2*Input

Assumption: Input < 20 Guarantee: Output < Input + 15

Assumption: none Guarantee: Output = Input1 + Input2

Assumption: Input < 10 Guarantee: Output < 50


Correctness of Software Connections

Are the documented software connections sound and complete?

1. Use static analysis to extract connection information from software

2. Use Lute analysis tool to confirm that AADL model matches the software


Static Analysis of Software Connections

static void sensors_share(const struct sensors_result *capt) {

...

memcpy(&sensors_shared_state, capt, sizeof(struct sensors_result));

...

}

From the control flow graph of each thread, we can extract buffer usage information

thread Sensors

...

properties

Source_Text => ("src/sensors.cpp");

Initialize_Entrypoint_Source_Text => "sensors_init";

Compute_Entrypoint_Source_Text => "sensors_task";

Static_Analysis::Writes_to_buffers => ("sensors_shared_state");

end Sensors;

Software connections are realized through shared data buffers


Lute Analysis of AADL Connection

Writes_To(t) := Property_With_Default(t, "Static_Analysis::Writes_to_buffers");

Reads_From(t) := Property_With_Default(t, "Static_Analysis::Reads_from_buffers");

Exists_Shared_Buffer(t1, t2) := Overlap(Writes_To(t1), Reads_From(t2));

theorem Software_Connections_Realizable

foreach c in Software_Connections do

check Exists_Shared_Buffer(Owner(Source(c)), Owner(Destination(c))),

"Connection", c, "is not realizable via a shared buffer";

end;

theorem Shared_Buffers_Documented_As_Connections

foreach t1 in Thread_Set do

foreach t2 in Thread_Set do

when Exists_Shared_Buffer(t1, t2) do

check Exists_Connection(t1, t2),

"Thread", t1, "can communicate to thread", t2,

"via a shared buffered, but this connection is not documented in the model";

end;

We define a notion of communication via a shared buffer

The AADL connections are sound if they can be realized via a shared buffer

The AADL connections are complete if every shared buffer corresponds to an AADL connection


Tool Example

The existing model connections are correct:

If we change sensors to write to motorsoutput_shared_state buffer instead, then this error is detected:


Examining Correctness of Communications

16


Why Trusted Build?


Why Trusted Build?

• Ensure fidelity between models and system image

– Proofs are over architectural models

• Information flow between processes and threads

• Well-formedness of architecture: scheduling, memory limits and safety, etc.

– Trusted build generates system image from architectural model

• Prevents stupid errors

– Mismatches on unit types between modules [Mars Polar Lander]

– Mismatches on alignment of data, data representation, and data location


What is Trusted Build?

AADL Model


What is Trusted Build?

• All type and interface declarations

• All communication paths between processes and their type

• [Future] Scheduling information AADL Model


Translation: AADL2CAmkES

… assembly { composition { component SOFTWARE__Sensors SS; component SOFTWARE__Command_Control_Telemetry CCT; component SOFTWARE__Radio_Control RC; component SOFTWARE__Stability_Navigation SN; component SOFTWARE__Motor_Control MC; connection seL4SharedData conn_1 (from SS.sensors_out, to SN.sensors); connection seL4SharedData conn_2 (from CCT.mavlink_out, to SN.mavlink); connection seL4SharedData conn_3 (from RC.commands_out, to SN.rc_commands); connection seL4SharedData conn_4 (from SN.motor_commands, to MC.motor_commands); } }

… struct DATATYPES__Servo_Commands { // TODO: FILL IN STRUCTURE OF OPAQUE TYPE }; struct DATATYPES__Motor_Commands { // TODO: FILL IN STRUCTURE OF OPAQUE TYPE }; struct DATATYPES__Flight_Control_Commands_Impl { double f1 ; int_32 i2 ; }

IDL File

ADL File


22

Rockwell

Collins

NICTA

Galois

UIUC

Research

Vehicle

0 Phase 1 16 mo. 12 6

Monolithic SW

No RTOS

No security

Monolithic Ardupilot

Software

Virtualization Layer

FreeRTOS

PX4: ARM Cortex M4 S

tab.

DS

L

NICTA RTOS

PX4: ARM Cortex M4

NICTA RTOS

PX4: ARM Cortex M4

Oth

er D

SL

Tas

k n

libc

Sta

b. D

SL

Oth

er D

SL

Sim

plex

libc

Virtualization Layer Virtualization Layer

System requirements

NICTA RTOS

Simplex architecture for autoland Embedded DSL

Factored autopilot tasks

C program verification

Generate executable from ADL

AADL ADL translation

FM Workbench

AADL model of

HW & SW

Verification of system requirements


23

Rockwell

Collins

NICTA

Galois

Boeing

Military

Vehicle

0 Phase 1 16 mo. 12 6

Simulation Environment

VSM / FCC

Data link (STANAG cmds)

Ground station

Pentium workstation

Simulation environment runs ULB flight software,

can be run locally by Red Team, and allows use

of existing seL4 port for Pentium CPU

seL4 microkernel

System requirements

Generate executable from ADL

(seL4 only)

AADL ADL translation

FM Workbench

AADL model of

HW & SW

Verification of system requirements


Pentium workstation

FC

C

seL4

VSM

Linux part.

Gro

und

stat

ion


Pentium workstation

FC

C

seL4

VSM

Linux

Gro

und

stat

ion

ST

AN

AG

Challenge problems

Port VSM to Linux partition

Port STANAG command task to seL4


Research Objectives

• Use vehicle architecture as mechanism to integrate

– OS and infrastructure properties from NICTA

– control component properties from Galois

– to prove system safety and security properties

– about ArduCopter and ULB helicopter

• Extend analysis methods in AGREE and LUTE to

– handle additional types of properties

– combine heterogeneous evidence produced by different tools

– Expand set of supported AADL features

• AGREE now uses data modeling annex format for type descriptions

– Work with Serban Gheorghe on getting LUTE standardized

24


Research Objectives

• Expand logics (sneak peek):

– Res●lute: adding resolution to Lute (e.g. Datalog with negation

through stratification).

– Allow implications rather than equalities for definitions

– Allow quantification in expressions

25

# The component x only receives messages that pass Decrypt.

secure_comm_decrypt(x : component) : bool <=

forall (y : component) (c : connection).

connected(y, c, x) and message_channel(c) =>

secure(c) and (y = Decrypt or secure_comm_decrypt(y))

# The memory of process p is protected from alterations by other processes.

memory_protected(p : process) : bool <=

property_lookup(p, "SMACCM::OS", "SeL4") or

(property_lookup(p, "SMACCM::OS", "Breakaway-RTOS") and

bound(p, mem) and forall (q : process). bound(q, mem) and memory_safe(q))

Documents

Secure Mathematically-Assured Composition of Control ...€¦ · © Copyright 2013 Rockwell Collins, Inc. All rights reserved. AADL model 8 /* The STM32F405 has 1024Kb of FLASH beginning