secure mathematically-assured composition of control ...€¦ · © copyright 2013 rockwell...
TRANSCRIPT
© 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)
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
Outline
• UAS requirements
• AADL model
• Compositional verification
• Trusted build
2
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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) */
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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:
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
Examining Correctness of Communications
16
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
What is Trusted Build?
• All type and interface declarations
• All communication paths between processes and their type
• [Future] Scheduling information AADL Model
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
Simulation Environment
Pentium workstation
FC
C
seL4
VSM
Linux part.
Gro
und
stat
ion
Simulation Environment
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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
© Copyright 2013 Rockwell Collins, Inc. All rights reserved.
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))