Secure Component Composition for Personal Ubiquitous Computing

Project Overview and Potential Techniques

——————

16th May 2003

——————

David Llewellyn-JonesBob Askwith

Qi ShiMadjid Merabti

http://www.cms.livjm.ac.uk/PUCsec/

Aims of the project

Concerning security in a given setting

• Privacy/confidentiality

• Integrity and authentication

• Access control

• Non-repudiation

• QoS – not tackled

Aims of the project – the setting

• NetworkedMany appliances networked together.

• Non-uniformAppliances may vary greatly in terms of power, user interface and intended use.

• MobileDevices will be mobile. Code may be mobile in the form of mobile agents.

• ComponentisedSoftware services built from multiple smaller components.

Aims of the project – challenges

• Maintain securityTotal security will not be achievable, but the framework should provide a reasonable and adaptable level.

• Maintain usabilityThe security protection should be transparent to the user.

• Incorporate extendibilityThe framework must be extensible

Network setting

Internet

Current techniques

General

• Certification

• Secure protocols

• Cryptography etc..

All well developed techniques with real-world implementations

Current techniques

More specific

• Model checking/verification

• Component composition

• Flow control/analysis

• Wrappers/white-box techniques

Using the techniques – a framework

The framework for applying these techniques might involve a process along the following lines:

Certificateschecked

Codeanalysis Initial

propertiesestablishes

Compositionanalysis

securewrapper

execution

C1. C2. C3

C1

C2

C3

Dynamic re-evaluation

Full certificates

Model checking/verification

An automated method for checking that a program satisfies its specification.

Most often used in safety critical systems.

Requires a lot of computing power even when checking relatively small programs: time consuming and expensive.

Applies to finite state systems.

Has the potential to allow automated verification of security properties without requiring any user intervention.

Model checking – process overview

Three stages to model checking:

• Modelling

• Specification

• Verification

Modelling Specification Verification

Modelling

Converts a program in to a form suitable for analysis by a model checker.

Program execution viewed as a series of states: memory snapshots.

The program design dictates flow from one state to another.

Information about states and flow are encoded in to a Kripke diagram.

Modelling Specification Verification

Kripke diagrams

A simple example:

int a = 2;

a += 5;

Modelling Specification Verification

S1

S2

S1

S2

a = 2

a = 7

Kripke diagrams

Unravelling loops:

int a = 2;

bool key = false;

do

{

a = 7;

key = (getchar () == ‘c’);

} while !key;

a = 0;

S1

S2 / S3

S4

a = 7key = true

a = 7key = false

a = 2key = false

a = 0key = true

S2 S3

S4

S1

Modelling Specification Verification

Kripke diagrams

Unravelling loops

S2 S3

S4

S1

Modelling Specification Verification

Kripke diagrams

Unravelling loops

S2 S3

S4

S1

Modelling Specification Verification

S4S3

S4

S2

S3

S4

S3S2

S3

S4

S1

S2

Specification

Which properties must be satisfied by the program?

In our case security properties

Modelling Specification Verification

Example CTL* formula

“If a file gets set as Private it will not have Send applied to it at a later date”

A specification consists of a collection of such formulae

Verification

This part involves the ‘serious’ computation.

Tests every sequence of potential states (called a trace) against the specification.

Because of looping, some traces will be of infinite length, so how can we check these?

Modelling Specification Verification

Checking infinite traces

Modelling Specification Verification

Although some traces will have potentially infinite length, there are only finitely many possible states. So an infinite trace must take the form:

For example:

Problems with verification

Modelling Specification Verification

•Only applies to finite state systems

•For CTL*, time needed for model checking is

Although this is linear in the size of the model, this makes it potentially exponential in the number of variables

Component Composition

Component composition can be considered in many ways.

In our case, it will be the connection of inputs/outputs of one component to the inputs/outputs of further components.

Not all properties are preserved across this process of composition.

Component Composition

Example of property not preserved by composition:

“In a single session the component will access either files, or the network, but not both.”

In general properties will be• strict• technical• mathematically formulated

Composition properties

BSD – Backward Strict Deletion

BSI – Backward Strict Insertion

Resolving timing difficulties

When combining components, it is essential to consider the security aspects. However, it can also be beneficial.

Model checking an entire program will take time exponential to the number of states. However, when split in to components, this can be improved substantially.

Composition results

“Under given circumstances” the following hold

There are practical problems with this• Composed property is as weak as the weakest component• Can only use components satisfying strict security properties

Components with mixed properties

Weaker components can have their security properties improved by the strength of the stronger ones.

Example:

If all data must satisfy some property, such as being signed, then in this configuration only C2 needs to satisfy the requirement.

C1 C2

OUT

OUT

IN IN OUT

Current techniques

More specific

• Model checking/verification

• Component composition

• Flow control/analysis

• Wrappers/white-box techniques