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

1

Johan Muskens Michel Chaudron

J.Muskens@tue.nl M.R.V.Chaudron@tue.nl

Trust4All- Completing the Trilogy -

2001 2003 2005 2007

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

2

Outline

• Background– Robocop– Space4U– Trust4All

• Motivation Trust4All• Initial Ideas

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

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

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

4

Problem Domain

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

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

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

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

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

7

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

Goal

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

8

– Fault management

– Power management

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

Highlights

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

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/03/05 Johan Muskens (email: j.muskens@tue.nl http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking

10

Outline

• Background– Robocop– Space4U– Trust4All

• Motivation Trust4All• Initial Ideas

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

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

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

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.

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

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

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

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

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

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

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

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.

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

17

Outline

• Background– Robocop– Space4U– Trust4All

• Motivation Trust4All• Initial Ideas

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

18

Trust Model is Based on Different Aspects

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

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

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

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

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

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

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

22

Expected Emphasis for Integrity Maintenance

Model based diagnosis

Testing

Run-timeDesign time

TU/e

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

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

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

24

Reasoning about Security

?Driver ? .... ?

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

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

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

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

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

27

Follow the Adventures .....

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

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

28

I Expect

Hard work ....

and a lot of fun !