First Year Review

Project Overview

Trento - September 24th, 2007

Prof. Yoram Ofek

2

Computing/Networking Convergence

• Exponential growth in computing/networking

• Leads to unifying: computing/networking

• All machines are interconnected

• Ensuring that applications are TRUSTED is critical [Operating as specified]

• Avoiding manipulation of programs/protocols

• STEALING content and information

• DENIAL of service – TCP example

• FAIR on-line bidding/trading/gaming

• … … …

3

Remote Entrusting: Design Objective

• How a remote code (SW application) on a

1st untrusted machine

can be entrusted by a

• 2nd entrusting machine?”[albeit running inside an untrusted environment]

• I.e., Distribution of trust

or entrusting

4

���������

�� �����������������

���������� ����������������

�������������������

• 1st Untrusted machine emanates Secure Tags

from a code/software during execution

• 2nd Entrusting Machine is ENTRUSTING the

• 1st Untrusted machine by verifying the Secure Tags

��������������������������������������

Core of Trust

5

Informal Definition of Trust

for Remote Entrusting

•• A software is deemed authentic/trustedA software is deemed authentic/trusted

if and only if its functionality if and only if its functionality

has not been altered/tampered by an has not been altered/tampered by an

untrusted/unauthorized entityuntrusted/unauthorized entity

prior to or during executionprior to or during execution

6

Scope of Trust in RE-TRUST

Human-to-Human

Machine-to-MachineRemote Entrusting:

RemoteSW Authentication

In Run-time

• Trust necessary condition: some sort of “identity”

Signature/attestation/authentication

of SW & HW in run-time

•• { Informally: avoidance of the { Informally: avoidance of the ””manman--atat--thethe--

endend”” attack [i.e., the untrusted user] } attack [i.e., the untrusted user] }

7

Challenges of the Basic Approach1.1. Combining/interlocking of two programsCombining/interlocking of two programs

• 1. Functional code to be entrusted

• 2. Secret (code, parameters-keys) –for secure tag generator

2.2. Tamper resistance (TR) of the aboveTamper resistance (TR) of the aboveVarious methods – “lines of defense”:

• TR in SW only

• Replacement

• TR in SW/HW (e.g., TC, smart card)

8

Quality of Remote Entrusting

SW and SW/HW Methods[Frequency and RE Complexity]

Method 2: SWComponents/Parameters

Replacement

(increased frequency)

Method 1: SWTamper-resistance (TR) Quality

(increased reverse engineering (RE) complexity)

Improved Security & TrustImproved Security & Trustis Measured by IncreasedDistance from the Origin

Method 3: SW/HW [e.g., USB Smart Card]Tamper-resistance (TR) Quality

(increased reverse engineering (RE) complexity)

9

Some Current Approaches

1. Sending packetsBased on monitoring & diagnosticsreactive (after the fact)

• Firewall monitoring

• SLA (service level agreement) policing

2. Receiving packets (e.g., content)Based on adding special HW

• E.g., TC/NGSCB, “watch-dogs,” …

• Specific to each computer HW depends on configuration, architecture, …

• What to do with current systems?

10

TCG Architecture

• Trusted Platform Module (TPM)The set of functions and data that are common to all types of platform, which must be trustworthy if the Subsystem is to be trustworthy; a logical definition in terms of protected capabilities and shielded locations.

CPU

RAM

Controller

Display

Boot ROM

TPM

DevicesEmbedded

RemovableDevices

Reference PC Platform containing TCG TPM

Tamper ProofComputing Device

CPU exec boot TCG ROMTPM is not snooping –but respond to requests

11

TCG: TPM Architecture

Communications

Non−Volatile

Storage

Platform

Configuration

Register (PCR)

Attestation

Identity

Key (AIK)

Program

Code

I/O

RSA

Engine Opt−InExec

Engine

Key

GenerationSHA−1

Engine

Random

Number

Generator

Trusted Platform Module (TPM)

TPM Component Architecture

PCR stores hash of measurementvalues but is not visible outside TPMWhile “chaining” measurements

12

TCG: Transitive Trust

Application Code

OS Code

OS Loader Code

CRTM

TBB + Roots of Trust

1

3

5

2

4

6

Execution Flow

Measurement Flow

Transitive Trust applied to Boot from Static Root of Trust

Primary Objective:Application Trust

TBB - trusted buildin blockCRTM - core root of trust for measurementsNote:OS etc. updates should be known to the verifier--- open-source? --- customization?For apps "big brother" on "mother board“?Consequently - closed computing system?

- users cannot do what they want?!

13

TCG: Integrity Reporting• RTR – root of trust reporting has two functions

1. expose shielded locations for storage of integrity measurements2. attest to the authenticity of stored values based on trusted platform identities

1. RequestPlatformConfiguration( )

2. GetEventLog( )

3. GetSignedPCR( )

4. SignPCRValue( )

5. GetPlatformCredentials( )

PlatformConfiguration( )

6. ValidatePlatformCredentials( )

SignedPCR( )

ChallengerPlatform

Agent TPM Repository

Attestation Protocol and Message Exchange

Credentials: certificate that are built in the machine e.g., processor ID, TPM ID,

EK public key –endorsement key for generating attestation keys

“TrustedChecker”

Non Run-time “Secure-TagGenerator”

Attestation: provides signaturesto the challenger "like" remote entrusting

14

TC vs. RE-TRUST• Core of trust

• TC: local

• RE-TRUST: remote

• Run-time

• TC: no

• RE-TRUST: yes

• Scope of entrusting

• TC: bottom - up

• RE-TRUST: selected applications

• Trust authority

• TC: external (TPM is based on public-key)

• “Big-brother” on the motherboard!?

• RE-TRUST: none / mutual agreement

15

Trusted Tag

Checker (TC)

Untrusted Computing

Environment

TrustedFlow

Generator (TG)

Handheld/Wireless Device

Trusted Tag

Checker (TC)

TrustedFlow

Generator (TG)

Untrusted Computing

Environment

Handheld/Wireless Device Network Interface

������������ �������������������

���������

���������

��������

��������

16

TG

TG

TG

TG

TGTG

TGTG

TC

TC TC

TC

Entrusting

Entrusting Entrusting

Entrusting

TC

“Castle”

“HARDENED”with SpecialHardware/Software(e.g., TCPA)

�������������!������ �������������������

���������

��������� ���������

17

Selected Scientific and Technical Challenges

1. SW-based – Tamper-resistance quality

• Combining two programs: original together with tag generator into “secure SW module”.

• Protecting the secure SW so it is hard to separate by increased program cohesiveness.

• Hiding the semantic of the secure SW module by means of obfuscation, for example.

• Measuring the complexity of reverse engineering of the secure SW module.

2. SW-based – Dynamic replacement

• Replacement of SW component in run-time is different from the current operating system (OS) paradigm.

• Replacement of SW component while resisting tampering by the OS is a new challenge.

• Analyzing trade-off between dynamic replacement frequency and tamper-resistance quality.

3. HW/SW-based – Tamper-resistance and encryption quality

• Tamper-resistant co-design of applications with software and hardware components.

• Analyzing trade-off between hardware and software.

• The security of communication between the secure SW module and the HW component.

18

Work Plan Organization

WP1: Overall Architecture

WP2: SW-basedTR Method 1 & 2

WP3: HW/SW-basedTR Method 3

WP4: Security/Trust Analysis

Optional (analysis dependent):- Proof-of-concepts (PoC) – WP2/WP3 - Standardization – WP1 - Solution definitions / technology transfer – WP1

Analysis

Analysis Analysis

Analysis

Analysis

19

Work-planning and timetable – Gantt0 3 6 9 12 15 18 21 24 27 30 33 36

WP0 - Management and Coordination

T0.1 Management activities

T0.2 Risk management activitiesT0.3 Scientific/industrial advisory board activities

WP1 - Architectural Framework

T1.1 – Trust requirements, generic applications

T1.2 – SW-based initial architectural framework

T1.3 – HW/SW-based initial architectural framework

T1.4 – SW-based reference architecture designT1.5 – HW/SW-based reference architecture design

WP2- SW-based Tamper Resistance

T2.1 – Trust model

T2.2 – Secure interlocking and authenticity checking

T2.3 – Dynamic replacement

T2.4 – Increased reverse engineering complexity

T2.5 – Design of entrusting protocol T2.6 – Proof of concept

WP3 - HW/SW-based Tamper Resistance

T3.1 – Trust model

T3.2 – Hardware/Software co-obfuscation

T3.3 – Encrypted code execution

T3.4 – Observable cryptography T3.5 – Scalability and performance

WP4 - Trust and Security Analysis

T4.1 – Trust analysis of SW-based method

T4.2 – Trust analysis of HW/SW-based method

T4.3 – Reverse engineering complexity

T4.4 – Comparative analysis with trusted computingT4.5 – Remote entrusting and Internet secure protocols

WP5 - Dissemination

T5.1 – Project oriented dissemination activities T5.2 – Scientific oriented dissemination activities

20

Initial architecture

WP1-Phase 1

DesignWP2/WP3

Analysis &Evaluation

WP4

Reference architecture

WP1-Phase 2

T1.2

SW-based

initial arch

T4.1- T43

Analysis of

SW-based method

and reverse

engineering

complexity

Task

Logicaldependency

T1.3

HW/SW-based

initial arch

Task1.4

SW-based

reference arch

Task1.5

HW/SW-based

reference arch

T4.2

Analysis of

HW/SW-based

method

T2.2- T2.3

Interlocking,

authenticity,

replacement

T2.4

Resistance to

reverse

engineering

T3.2

HW/SW

co-obfuscation

T3.3 – T3.4

Encrypted

code execution,

observable

cryptography

21

Work Package List

310TOTAL

536118P1

Dissemination,

Exploitation,

Standardization

WP 5

836175P1Trust and Security

AnalysisWP 4

536172P4HW/SW-based Tamper

Resistance MethodWP 3

736195P2SW-based Tamper

Resistance MethodsWP 2

536136P1Architectural

FrameworkWP1

636114P1Management and

CoordinationWP0

Delivera

ble

No.

End

month

Start

month

Person-

months

Lead

contractorWorkpackage titleNo.

22

Scientific/Industry Advisory Board

• Internationally renown experts in both academia and industry:

• Christian Collberg (University of Arizona)

• Amir Herzberg (Bar Ilan University, Israel)

• Willem Jonker (Philips Research)

• David Naccache (University Paris II)

• Bart Preneel (Katholieke Universiteit Leuven)

• Paolo Prinetto (Politecnico di Torino)

• Paul Van Oorschot (Carleton University, Canada)

• Moti Yung (Columbia University, USA)