Secure Component Composition for Personal Ubiquitous Computing Project Overview and Potential Techniques —————— 16 th May 2003 —————— David Llewellyn-Jones Bob Askwith Qi Shi Madjid Merabti

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 Networked Many appliances networked together. Non-uniform Appliances may vary greatly in terms of power, user interface and intended use. Mobile Devices will be mobile. Code may be mobile in the form of mobile agents. Componentised Software services built from multiple smaller components.

Aims of the project – challenges Maintain security Total security will not be achievable, but the framework should provide a reasonable and adaptable level. Maintain usability The security protection should be transparent to the user. Incorporate extendibility The 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: Certificates checked Code analysis Initial properties establishes Composition analysis secure wrapper execution C 1. C 2. C 3 C1C1 C2C2 C3C3 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 ModellingSpecificationVerification

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 SpecificationVerification

Kripke diagrams A simple example: inta = 2; a += 5; Modelling SpecificationVerification S1S1 S2S2 S1S1 S2S2 a = 2 a = 7

Kripke diagrams Unravelling loops: inta = 2; boolkey = false; do { a = 7; key = (getchar () == ‘c’); } while !key; a = 0; S1S1 S 2 / S 3 S4S4 a = 7 key = true a = 7 key = false a = 2 key = false a = 0 key = true S2S2 S3S3 S4S4 S1S1 Modelling SpecificationVerification

Kripke diagrams Unravelling loops S2S2 S3S3 S4S4 S1S1 Modelling SpecificationVerification

Kripke diagrams Unravelling loops S2S2 S3S3 S4S4 S1S1 Modelling SpecificationVerification S4S4 S3S3 S4S4 S2S2 S3S3 S4S4 S3S3 S2S2 S3S3 S4S4 S1S1 S2S2

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? ModellingSpecification Verification

Checking infinite traces ModellingSpecification 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 ModellingSpecification 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 C 2 needs to satisfy the requirement. C1C1 C2C2 OUT IN OUT

Current techniques More specific Model checking/verification Component composition Flow control/analysis Wrappers/white-box techniques