A Security Framework for Executables in a Ubiquitous Computing Environment

1. 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 Sciences Liverpool John Moores University James Parsons Building Byrom Street Liverpool L3 3AF {D.Llewellyn-Jones, M.Merabti, Q.Shi, R.Askwith}@livjm.ac.uk http://www.cms.livjm.ac.uk/PUCsec/

2. 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

3. 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

4. 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

5. 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

6. 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

7. Stage 1: Component analysis • The following techniques have been discussed • Certification • Proof Carrying Code • Direct Code Analysis

8. 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

9. 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

10. 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

11. 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 1 ADD *2 *0 3 ;---------------------------------- ; End of program .End Post condition (ind(M, 0) < 50) 600MHz Intel XScale 80321 ARM compatible processor

12. Stage 2: Component composition • Having established the properties of individual components we must establish the properties of the composed application

13. 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).

14. 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>

15. 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

16. 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

17. 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

18. 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

19. 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 Statistics Liverpool John Moores University James Parsons Building Byrom Street Liverpool L3 3AF {D.Llewellyn-Jones, M.Merabti, Q.Shi, R.Askwith}@livjm.ac.uk http://www.cms.livjm.ac.uk/PUCsec/