A Security Framework for Executables in a Ubiquitous Computing Environment

Globecom 2004——————

1st December 2004

——————

Dr. David Llewellyn-Jones, Prof. Madjid Merabti, Dr. Qi Shi, Dr. Bob Askwith

——————

School of Computing and Mathematical SciencesLiverpool John Moores University

James Parsons BuildingByrom Street

Liverpool L3 3AF

{D.Llewellyn-Jones, M.Merabti, Q.Shi, R.Askwith}@livjm.ac.ukhttp://www.cms.livjm.ac.uk/PUCsec/

Ubiquitous computing security

• Ubiquitous computing properties– Computers form an integral part of the environment– Devices are networked– Data flow is highly fluid– Code is also likely to move between devices

• Security in such an environment is paramount

Focus on executables

• Current security paradigm relies on a ‘safe area’– Perimeter model prevents incoming threats– Only certain programs can be used– Safe area is administered by trained professionals

• This model no longer applies in a Ubicomp environment– There is no perimeter– Users cannot be expected to have the same expertise as administrators

• Nonetheless, users will demand a safe environment– Adoption of Ubicomp technology is dependent on overcoming these

problems

• We focus on safe code execution as the bedrock of all other security requirements

Existing security solutions

• A number of solutions exist to facilitate safe code execution– Sandboxing– Certification– Proof Carrying Code– Direct Code Analysis

• Each has benefits and drawbacks• To achieve a universal and automated solution a hybrid

approach is required

Hybrid solution

• In this presentation we will present our prototype hybrid solution

• Our aim has been to produce an automated system• Properties of code are tested against a security policy

– code conforming to the policy can be executed without restriction– where possible, sandbox techniques can be used to force code conformance– otherwise the code is prevented from execution

• In order to achieve this, we aim to utilise all four of the described methods, in conjunction with component composition

• Component composition establishes the properties of a composed application based on the properties of the constituent components

Hybrid solution

• We propose a 3 stage solution– Stage 1: Component analysis– Stage 2: Component composition– Stage 3: Dynamic sandboxed execution

• The implementation will be considered in detail

Stage 1: Component analysis

• The following techniques have been discussed– Certification– Proof Carrying Code– Direct Code Analysis

Extended executables

• Encodes additional data with the executable• Allows all of the techniques to be used in a transparent way

• Plain ‘vanilla’ code must also be useable

extended executable = code | header, block

block = code | {block [, X-properties [, X-proof]]}KX | block, X-properties, X-proof

code = the “vanilla” executable code

header = description of the structure of the data

X-properties = description of the properties established of the code by actor X

X-proof = PCC style property proof of the properties established by actor X

Direct Code Analysis

• When plain code is received we require a method of establishing its properties

• We employ Direct Code Analysis for this task– Based on method developed by Floyd and Hoare

• Code is converted into logic based on pre and post conditions

• Reasoning establishes whether these conditions hold or not

• Combines PCC process into a single task

DCA benefits and drawbacks

• Benefits– Based on an a priori process– Fully automated process– Any property representable in propositional logic can be tested

• Drawbacks– Resource intensive– Exponential complexity– Only properties representable in propositional logic can be tested

DCA Experimental results

• Analysis of linear code is efficient

• Branching code is more complex– depends on branch direction– depends on internal loop length

• Success establishing buffer overruns• Implemented as an automated process

;----------------------------------; Initialise

MOV *0 0;----------------------------------; Main loop

ADD *0 *0 1ADD *2 *0 3

;----------------------------------; End of program.End

Post condition(ind(M, 0) < 50)

600MHz Intel XScale 80321 ARM compatible processor

Stage 2: Component composition

• Having established the properties of individual components we must establish the properties of the composed application

Component composition

• Individual components make up the complete application• Components may be composed across a network• We know the properties of each component; must establish

the properties of the composed application– Non-trivial process– Many theoretical results exist

– Aim to implement a practical solution

• Why not just analyse the entire application?

Definition: An interface E of a component is said to satisfy non-interference iff for any trace t TE there exists a trace t´ TE such that t´HIE = and t´(LIE LOE) = t(LIE LOE).

Component composition

• Implementation– Based on an extensible, scriptable

technique– Analyse the properties of individual

components combined with the component topology

– Use PROLOG-like XML

<compose><sandbox id="s1" config="c1">A sandbox method</sandbox><property id="Any">Defined to be any property</property> <property id="id1">A particular property</property> <property id="id2">A particular property</property> <configuration id="c1"> <component> <input format="id1" config="c1" cycle="disallow"/> <output format="Any Any" config="c1" cycle="disallow"/> </component> <component> <input format="id2" config="c1" cycle="disallow"/> </component> </configuration></compose>

Component composition experimental results

• So far our engine has been found to be flexible enough to cope with all the theoretical composition results tested from the literature

• These include– Hierarchical results such as Composable Assurance– Restrictive results such as Non-Interference– Practical buffer overrun results

• Analysis time depends on complexity of system being analysed

• In general, scripting ensures that the time required is negligible

Example: buffer overruns

• Simple component topology

• Component B suffers a buffer overrun vulnerability if more than 64 non-terminated bytes are sent on channel 0

• May establish A sends no more than 64 bytes– Component composition indicates no buffer overrun vulnerability exists for

the composed application

• May establish A potentially sends more than 64 bytes– Component composition indicate a buffer overrun vulnerability

exists under certain circumstances

Summary

• Have developed a framework for ensuring executable security appropriate for a Ubiquitous Computing environment

• Our framework utilises– Sandboxing– Certification– Proof Carrying Code– Direct Code Analysis– Component composition

• Current prototype utilises– Direct Code Analysis– Component composition

• Fully automated framework

Future work

• Investigate dynamic sandboxing techniques• Combine all of the methods into a fully automated

framework– Design using a simple agent-based component composition model

• Build sensible security policies around the system• Introduce distributed analysis

A Security Framework for Executables in a Ubiquitous Computing Environment

Globecom 2004——————

1st December 2004

——————

Dr. David Llewellyn-Jones, Prof. Madjid Merabti, Dr. Qi Shi, Dr. Bob Askwith

——————

School of Computing and Mathematical StatisticsLiverpool John Moores University

James Parsons BuildingByrom Street

Liverpool L3 3AF

{D.Llewellyn-Jones, M.Merabti, Q.Shi, R.Askwith}@livjm.ac.ukhttp://www.cms.livjm.ac.uk/PUCsec/