10/03/05 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...

10/03/05 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking

1

Johan Muskens Michel Chaudron

[email protected] [email protected]

Trust4All- Completing the Trilogy -

2001 2003 2005 2007


2

Outline

• Background– Robocop– Space4U– Trust4All

• Motivation Trust4All• Initial Ideas


3

– Define an open, component-based framework for the middle-ware layer in high-volume consumer devices (robustness/reliability, upgrading/extension, and trading)

non – proprietaryextendable

Goal


4

Problem Domain


5

Scope

External World

May be connected

Robocop Device

Single Device

Middleware

Applications

. . .App 2App 1 App N

. . .RC 2RC 1

Robocop Runtime Environment

OS, Network & Drivers

Device Hardware

OS + HW = Platform

Middleware

Robocop scope in red Robocop Runtime Environment

RC 2RC 1 . . .


6

•

Highlights

Robocop Component

Resource Model

Simulation Model

Documentation

Executable Component

Functional Model

Source Code

… Service 1

• Infrastructure• Runtime Environment• IDL compiler

• Download• Resource Management• Predictable assembly based on models


7

– Extend and validate the Architecture• Fault Management• Power Management• Terminal Management

Goal


8

– Fault management

– Power management

– (Remote) Integrity Management– Support for Real Time Components– Visualization

Highlights


9

– Invent techniques for the middleware for ensuring the proper working of systems whose software is dynamically extended and upgraded using components provided by a number of different parties.

Goal


10

Outline




11

What we have / What we want

• We have:

• We want:

Robust & ReliableOperation of closed

system

Secure communication

Robust & Reliable & Secure / Safe

Operation of open system

Secure communication


12

Example Scenario A

White components are provided by OCE and provide the core functionality of the device

Red component are provided by third party and provide custom functionality for a specific user / client.

Goal:

Core functionality of the copier must operate robust, reliable, (and secure) even though not all the software on the device is trusted.


13

Example Scenario B

Secure connection to corporate databaseusing VPN

White components are provided by Nokia and provide the core functionality of the device

Blue and Red Components are provided by a third party and they are used to setup a VPN connection for a specific network infrastructure

Goal:

• Establish a certain level of trust in the VPN connection• Keep robust and reliable operation of the core phone functionality


14

Scenario C

HOME X HOME Y

Setting:- In home situation.- Multiple devices providing services- Service discovery

Goal:Secure access to the services

Is this solved by existing technologies?

Yes and No


15

Scenario D

Situation:- We have video surveillance camera- Media Renderer device capable of playing several media-formats -The device becomes out-dated due to out-dated decoder- Hardware is sufficient- New decoder components are provided by a third party

Goal:-Upgrade the device (extend life-time) by allowing the third party components without jeopardizing

- Robustness- Reliability- Security


16

Abstract from these examples

• Common theme– Establish confidence in reliable, robust and

secure operation of a (dynamically changing system) system build out of components provided by multiple different parties.


17

Outline




18

Trust Model is Based on Different Aspects


19

Trust Model (Metrics / Mechanisms / ...)Trust

Robustness

Structure

- integrity rules

Behavior

- integrity rules

- real time properties

Reliability

Structure

- duplication

- inter-failure times

- know bugs

Behavior

- error correcting protocols

- tests passed

- checking pre and post

condition

Security

Structure

- Confidentiality

Behavior

- Authentication

- Encryption

Trust

Robustness

Structure

- integrity rules

Behavior

- integrity rules

- real time properties

Reliability

Structure

- duplication

- inter-failure times

- know bugs

Behavior

- error correcting protocols

- tests passed

- checking pre and post

condition

Security

Structure

- Confidentiality

Behavior

- Authentication

- Encryption


20

Maintain Integrity of a Software Configuration

Open system

ArbitraryFeature addition

TrustedOpen system

TrustedFeature addition

Failed system Trusted system

Open system

ArbitraryFeature addition

TrustedOpen system

TrustedFeature addition

Failed system Trusted system


21

Dynamically composed softwareusing components of multiple

different parties

Models describing the currentsoftware configuration of adevice.

Based on these models:

• Diagnosis and Repair • Detect mismatch in styles• Support for extra functional properties• Support for security• Visualize

•Evolution•Design flaws

Composition of:-Robustness-Reliability-Security

Model Based Diagnosis


22

Expected Emphasis for Integrity Maintenance

Model based diagnosis

Testing

Run-timeDesign time

TU/e


23

Reasoning about Real Time Aspects• In Space4U we worked on prediction

• In Trust4All– Use Prediction for Acceptation

– Suggestions for Improvement of Real Time behavior

– Enforcement

– Predictable assembly of other properties, using the same scheme (Reliability).


24

Reasoning about Security

?Driver ? .... ?


25

Reasoning about Security

• Observation– Composition of a number of secure Services can

result in an insecure system.

• Initial Ideas– Services come equipped with

• Suitable configuration patterns• Robustness, Reliability, and Security needs• Assessment schemes

– Map required Trust profile on available components

• Check for sufficient support by Service implementations


26

Visualization

• Visualization can aid in assessment of quality properties.

– Metric View

• Visualization can aid in detection of Trust problems

– Based on structure

All trusted

Mixed


27

Follow the Adventures .....

• http://www.win.tue.nl/san/projects/trust4all/


28

I Expect

Hard work ....

and a lot of fun !

10/03/05 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...

Documents

Transcript of 10/03/05 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...