Secure Component Composition for Personal Ubiquitous Computing

Project Summary——————

21st April 2006

——————

David Llewellyn-Jones, Madjid Merabti, Qi Shi, Bob Askwith——————

School of Computing and Mathematical StatisticsLiverpool John Moores University

James Parsons BuildingByrom Street, Liverpool, L3 3AF, UK

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

A Ubiquitous Computing World

• Ubiquitous Computing presents a vision of computing environments in which– Networking is wireless and pervasive

– Devices are mobile and plentiful

– Data flows unimpeded giving users access to their content from anywhere

Disappearing Hardware

• There is a misconception that this means ‘embedded’ devices, or devices that can’t be seen

• Devices that blend into the background– The most profound technologies are those that disappear. They weave

themselves into the fabric of everyday life until they are indistinguishable from it”.

– “Consider writing...Today this technology is ubiquitous in industrialized countries...The constant background presence of these products of "literacy technology" does not require active attention, but the information to be conveyed is ready for use at a glance. It is difficult to imagine modern life otherwise”.

Working Seamlessly

• When users become so familiar with devices that they do not realise they are using them

• Ubiquitous Computing– Pick up any device anywhere and have access to information

• Requires device use to be seamless

Security Environment

• Characteristics that affect security– Wirelessly networked environment– Fluid data flow, fluid code movement– Heterogeneous environment– Low power and low resource devices– General users – not computer experts– Restricted user interfaces– Frequently changing environment

• The consequences for security– No physical security for networks– Malicious code can move around the network– Cannot make assumptions about consistent device interactions– Heavy duty security techniques may not be possible– Cannot expect users to administer devices effectively, if at all– Configuring security may be difficult or impossible– Security properties are constantly changing

Existing Security Issues

• Malicious code moving around the network– Viruses/worms

– Mobile code consuming resources

– Can cause denial of service even for protected/immune machines

• Hackers exploiting vulnerabilities– Accessing private information

– Buffer overrun vulnerabilities

– Taking control of devices

• Badly written code/protocols– WMF vulnerability

– WEP security

– TCP/IP

– Cleartext authentication (e.g. POP3, rlogin, telnet)

Proposed Security Solutions

• Security in individual devices– Firewalls that use battery levels to detect intrusion

– Mobile agent firewalls/IDSs

• Distributed security– Distributed firewalls

– Distributed Operating Systems

• Secure execution of code– Virtual machines: Java applets

– Proof Carrying Code

• etc.

Component Interactions

• The way components are composed affects properties

Component Interactions

• Changing the order changes the effect

Security Composition Examples

• Adding a component to improve security

Security Composition Examples

• Adding a component to reduce security

Security Composition Examples

• Ordering of components is also important

The Challenge

• Can we use secure component composition techniques to overcome the lack of boundaries in a Ubiquitous Computing world?

• The plan– Analyse a group of interacting components

– Could be devices, services, software components etc.

– Test against known security properties

Secure Component Composition Results

• Existing results tend to be very theoretical• Non-interference

– Focardi and Gorrieri, 1997– Relates to information flow through a system

– Three systems or components C1, C2 and C3. Want to ensure no data sent from C1 to C2 can be established by C3. Non-interference says this is satisfied if C3’s view of C2 is not affected in any way by C1’s behaviour.

• Non-deducibility on outputs– Mantel, 2002– Each possible low observation must be compatible with each possible high input

sequence

• Composable Assurance– Shi and Zhang, 1998

– A component Ci is said to be composably assured iff for any pair (LDi, HDi) є DPi, HDi ≠ ø

• Generalised non-interference, forward correctability, separability, non-inference, etc.

Composable Assurance

• Shi and Zhang recognised that connectivity was important– “...separability of these composable properties is usually achieved by

assuming the worst scenarios of interaction between components...this problem can be avoided by appropriate consideration of connectivity between components.”

• To test for security composition results we therefore need– Properties of individual components

– Connectivity between components

Making This Practical

• Using an extensible engine• Plug-in scripts that can

– test for problems

– find resolutions

• A general framework needs to– consider properties of individual components

– consider the component interaction

Script Example

1. <sandbox id="s2" config="c1">Read access control check</sandbox> 2. <property id="idAuth">Level component is authorised to</property> 3. <configuration id="c1" init="1"> 4. <component id="c2"> 5. <input format=""/> 6. <input id="in1" init="0" format="*"/> 7. <process config="check" action="check=@n"/> 8. <process id="auth1" init="1" action="@a[@n][0][idAuth]"/> 9. <process cond="result &lt; auth1" action="c1=0"/>10. <output format="*" cond="c1==1"/>11. <component>12. <process config="check" action="check=@n"/>13. <process id="auth2" init="1" action="@a[@n][0][idAuth]"/>14. <process cond="result &lt; auth2" action="c1=0"/>15. <input id="in2" init="0" format="*"/>16. <output format="*" config="c2" follow="fresh" cond="c1==1"/>17. <output format="" cond="c1==1"/>18. </component>19. </component>20. </configuration>

Buffer Overruns

• Buffer overrun vulnerabilities occur when– When too much data is placed in a buffer too small to accommodate it

– No bounds checking is done

• Whatever’s beyond the buffer becomes corrupted• Especially dangerous if it’s code beyond the buffer

Buffer Overruns

• A number solutions to buffer overrun problem exist– Use a memory-safe language with bounds checking (Java)

– Compile using a safe library (strsafe.lib)

– Code analysis

– Controlled attack (S-tool)

– Source code analysis (STOBO, LCLint extensions)

– Dynamic run-time checking (StackGuard)

• Largely a result of the use of C/C++• Remains a considerable problem

– At least 25% of CERT advisories

Buffer Overruns

• How can we improve the situation?• Input and output correlation

• A sends data to B• Suppose B is vulnerable, has buffer size n bytes and A

sends m bytes to B– If (m > n) then a buffer overrun may occur

– If (m ≤ n) then there’s no problem

• Want a method for showing that max bytes A will ever send is less than buffer size of B– The vulnerability ‘disappears in the wash’ during composition

Timing Results

• 600 MHz Intel X-Scale80321 Processor

Access Control

• Consider services S1,…, S6 with dependencies reading files

• Conclude– S6 must have rights to access file A

– S5 must have rights to access file B

– S3 and S4 must have rights to access both A and B

– The read access rights of S1 and S2 do not matter

Timing Results

• 600 MHz Intel X-Scale80321 Processor

• A nice consequence– Turning exponential time

checks into linear time

Future Work

• Using sensors to determine interactions dynamically• Combining into a Networked Appliance scenario• Finding solutions as well as just detecting problem

– E.g. Introduction of throughput limiter in buffer overrun case

– Adding access gateway in access control case

• In the future, expect your computer to come up with a list of problems when you start accessing a particular network

• Better yet, let it just resolve the issue without you even realising it

The End

Thank you for listening

More info at

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