First year review WP3 overview Trento - September 24th, 2007 Goal - - PowerPoint PPT Presentation

First year review WP3 overview

Trento - September 24th, 2007

Goal

Investigate the combination of hardware- and software based software protection techniques in order to implement the remote entrusting principle

Participants

• KUL (WP leader)
• Team:
• Bart PRENEEL
• Jan CAPPAERT
• Sebastian FAUST
• Thomas HERLEA
• Dries SCHELLEKENS
• Brecht WYSEUR
• Team:

Team:

• Bart PRENEEL

Bart PRENEEL

• Jan CAPPAERT

Jan CAPPAERT

• Sebastian FAUST

Sebastian FAUST

• Thomas HERLEA

Thomas HERLEA

• Dries SCHELLEKENS

Dries SCHELLEKENS

• Brecht WYSEUR

Brecht WYSEUR

Participants

• KUL (WP leader)
• GEM
• Team:
• Jean-Daniel AUSSEL
• Jerome D’ANNOVILLE
• Team:

Team:

• Jean

Jean-

• Daniel AUSSEL

Daniel AUSSEL

• Jerome D

Jerome D’ ’ANNOVILLE ANNOVILLE

Participants

• KUL (WP leader)
• GEM
• UNITN
• Team:
• Paolo TONELLA
• Mariano CECCATO
• Jasvir NAGRA
• Milla DALLA PREDA
• Amitabh SAXENA
• Team:

Team:

• Paolo TONELLA

Paolo TONELLA

• Mariano CECCATO

Mariano CECCATO

• Jasvir NAGRA

Jasvir NAGRA

• Milla

Milla DALLA PREDA DALLA PREDA

• Amitabh SAXENA

Amitabh SAXENA

Participants

• KUL (WP leader)
• GEM
• UNITN
• POLITO
• Team:
• Stefano DI CARLO
• Alberto SCIONTI
• Team:

Team:

• Stefano DI CARLO

Stefano DI CARLO

• Alberto SCIONTI

Alberto SCIONTI

Participants

• KUL (WP leader)
• GEM
• UNITN
• POLITO
• SPIIRAS
• Team:
• Igor KOTENKO
• Vasily DESNITSKY
• Team:

Team:

• Igor KOTENKO

Igor KOTENKO

• Vasily

Vasily DESNITSKY DESNITSKY

Tasks

M0 M3 M6 M9 M12 M15 M18 M21 M24 M27 M30 M33 M36

T3.1 T3.1 T3.2 T3.2 T3.3 T3.3 T3.4 T3.4 T3.5 T3.5

D3.1

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16

Tasks

... ...

T3.2 T3.2 T3.3 T3.3 T3.4 T3.4 T3.1 T3.1

Trust model

Definition of the trust model for hardware/software-based remote entrusting The output of this task is the deliverable D3.1:

• Trust model for the combined

hardware/software-based approach

T3.1 T3.1

Trusted hardware (H)

Trust model

Untrusted platform (U)

HW HW OS OS P P

M

Trusted platform (T)

TAG seq. TAG seq. TAG seq. TAG seq. M

• n

i t

• r

r e p l a c e m e n t M

• n

i t

• r

r e p l a c e m e n t Monitor replacement Monitor replacement

T3.1 T3.1

P’

M’

TV’ MF’

TAG TAG Validation Validation Monitor Monitor Factory Factory

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16

T3.1 T3.1

Tasks

... ...

T3.2 T3.2 T3.3 T3.3 T3.4 T3.4

Hardware/Software Co-Obfuscation

Use of light-weight hardware to ensure software confidentiality and software integrity

• TPM, Smart card, …

Advantages

• Controlled latency
• Delegated verification
• Identification
• Users (Smartcard)
• Machine (TPM)

T3.2 T3.2

Software confidentiality

• Software splitting
• Code decryption in hardware
• Hide control flow information

Data confidentiality

• Applied to original program and/or monitor
• Must be combined with other techniques

Software integrity

Hardware/Software Co-Obfuscation

T3.2 T3.2

Confidentiality Integrity

T3.2 Hardware/Software Co-Obfuscation

TPM Assisted Remote Software Entrusting (KUL)

Trusted computing approach: remote attestation

T3.2 T3.2

CRTM BIOS OS loader OS Application Option ROMs TPM Hardware Network New OS Component root of trust in integrity measurement root of trust in integrity reporting measuring reporting storing values logging methods Memory trusted component

T3.2 Hardware/Software Co-Obfuscation

TPM Assisted Remote Software Entrusting (KUL)

Existing techniques for remote software entrusting:

• Timed execution of checksum function
• Examples: Pioneer and TEAS

T3.2 T3.2

n c h

Untrusted platform Untrusted platform Trusted platform Trusted platform P P M M

t2 – t1 <

• texpected

P P M M

c := cksum(n,M) h := hash(c,P) c := cksum(n,M) h := hash(c,P)

T3.2 Hardware/Software Co-Obfuscation

TPM Assisted Remote Software Entrusting (KUL)

Disadvantages of timing based attestation techniques

• Constraints on verification function implementation
• predictable execution time (interrupts, supervisor

mode)

• time-optimal
• Known hardware configuration hardware

replacement attack

• Network delays need to be incorporated proxy

attacks Minimal trade-off: assist software attestation with TPM features.

T3.2 T3.2

T3.2 Hardware/Software Co-Obfuscation

TPM Assisted Remote Software Entrusting (KUL)

Enhanced solution: TPM tick stamping

T3.2 T3.2

n

Untrusted platform Untrusted platform Trusted platform Trusted platform P P M M

t2 – t1 < texpected

P P M M

c := cksum(TS1,M) h := hash(TS2,P) c := cksum(TS1,M) h := hash(TS2,P) h TS1 := SignTPM(n||t1) TS2 := SignTPM(c||t2) TS1 TS2

TPM TPM

T3.2 Hardware/Software Co-Obfuscation

TPM Assisted Remote Software Entrusting (KUL)

Extensions: assistance for trusted OS loader

• Include HW specifications (CPUID) in Tag
• Simulate verification function at boot-time

Publication

• Dries Schellekens, and Brecht Wyseur, and Bart Preneel, “Remote

Attestation on Legacy Operating Systems with Trusted Platform Modules” – accepted for REM’07

T3.2 T3.2

T3.2 Hardware/Software Co-Obfuscation

Hardware assisted invariants Monitoring (POLITO - KUL)

Extension of software-based solution Software-based invariants monitoring (WP2):

• A program invariant is a property that is

true at a particular program execution point

• Invariant monitoring aims at detecting

attacks to the state of a program P by continuously checking dynamically inferred invariants

T3.2 T3.2

T3.2 Hardware/Software Co-Obfuscation

Hardware assisted invariants Monitoring (POLITO - KUL)

Assist invariants monitoring with a Smart card

• Reduce network load
• Hide which variables are traced (trace

more, and filter in the Smartcard) Delegate parts of invariants verification to the Trusted Hardware

• Dynamically replace verification

algorithm

• Deployment of a challenge-response

system

T3.2 T3.2

T3.2 Hardware/Software Co-Obfuscation

Distributed Trust Verification

(UNITN - GEM)

Barrier Slicing (WP2):

• Protecting the state of P by moving parts
• f its code from U to T
• Trade-off
• Performance (network overhead)
• Security

T3.2 T3.2

T3.2 Hardware/Software Co-Obfuscation

Distributed Trust Verification

(UNITN - GEM)

T3.2 T3.2

Un-trusted host Trusted host Program P

• Card Reader

Virtual secure channel

T3.2 Hardware/Software Co-Obfuscation

On-card Trust Verification

(GEM)

T3.2 T3.2

T3.2 Hardware/Software Co-Obfuscation

Distributed Trust Verification

(UNITN - GEM)

Improvements

• Automatic support for the identification of

the secure and un-secure variables;

• Perform simulations on bigger test-cases

to gather improved measurements

• Implementation
• On a Smart card simulator (done)
• On a real Smart card

T3.2 T3.2

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16

T3.1 T3.1

Tasks

... ...

T3.2 T3.2 T3.3 T3.3 T3.4 T3.4

Encrypted Code Execution

Goal “Go beyond obfuscation, to provably secure code execution” Model “An attacker can monitor all memory accesses”

T3.3 T3.3

Computing with Encrypted Data Computing with Encrypted Functions

Untrusted Platform Trusted Platform Trusted Hardware

T3.3 Encrypted Code Execution

Computing with Encrypted Data (GEM - KUL)

T3.3 T3.3

F(x1,x2,...,xn) ?

• x1,x2,...,xn
• F

E(x1),E(x2),...,E(xn) G(E(x1),E(x2),...,E(xn))

E(xi)

E D G

Untrusted Platform Trusted Platform Trusted Hardware

T3.3 Encrypted Code Execution

Computing with Encrypted Functions (GEM - KUL)

T3.3 T3.3

F(x1,x2,...,xn) ?

x1,x2,...,xn E(F)(x1,x2,...,xn)

E(F)

E D

E(F)

F

T3.3 – Encrypted Code Execution

White-Box Crypto against Side- Channel Attacks (GEM - KUL)

T3.3 T3.3

Smartcard

Cache Memory CPU

Cryptographic implementation secure in white-box model Secure in a grey-box model (existing AND future (!) attacks)

M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16

T3.1 T3.1

Tasks

... ...

T3.2 T3.2 T3.3 T3.3 T3.4 T3.4

Observable Cryptography

(KUL)

Goal

• Define exactly what information

about the program execution leaks to an attacker

• Develop provable secure techniques

accordingly

T3.4 T3.4

T3.4 Observable Cryptography

Gap in Provable Security

Traditional provable security

• Cryptographic Algorithms are modeled as black-boxes
• Adversary may have access to inputs and outputs
• Inner workings during computation are not revealed

Gap to real-world implementations

• Practical attacks on provable secure systems exist
• Not due failure in the proof, but by taking a step outside

the model

• Physical devices do not behave as black boxes
• Side-channel attacks provide the adversary with a

partial view on the inner workings of implementations

T3.4 T3.4

T3.4 Observable Cryptography

Gap in Provable Security

Approach in provable security

• Develop adversary model
• Define what is understood under the security of the algorithm
• Prove that no adversary can exist under reasonable assumptions

Proof by contradiction

• Given A’ against the algorithm, build A against assumption
• A uses A’ A has to simulate a “real-looking” environment for A’

T3.4 T3.4

A’

C M

A

A’

C M

N p,q

T3.4 Observable Cryptography

Ishai/Sahai/Wagner, Crypto 2003

Can we guarantee secrecy if an adversary can access a bounded number of wires in a circuit? Model:

• Computation on Boolean circuits with n gates
• Adversary A can adaptively probe t wires in a circuit
• t-privacy: whatever A can do, can be done without the side-channel

no additional information is obtained Results

• Transformation T, transforming C into a perfect t-private circuit C’ with

O(nt2) gates.

• T transforming C into a statistical t-private circuit C’ with O(nt) gates

(but big constants)

• Efficient construction for a computational t-private PRG circuit

T3.4 T3.4

T3.4 Observable Cryptography

State-of-the-Art

Micali/Reyzin, TCC 2004: Can we build from PO OWF, a PO PRNG, signature scheme, etc. that is secure against all observing adversaries?

• Observation: unpredictability indistinguishability
• Physically observable OWF (durable) PO unpredictable

Chari et al., Crypto 1999: How many power samples are needed such that the adversary can distinguish a correct key guess from a false one with non-negligible probability?

• Adversary A obtains N power samples through a side channel, and

has to distinguish two state distributions (to reduce the key space)

• Result: A general countermeasure to protect against DPA attacks:

each bit of computation is split into k independent shares. The success probability of A decreases exponentially in k

T3.4 T3.4

Future activities

• Development of new techniques for

hardware/software co-obfuscation, and improvements of software-only techniques enhanced with light-weight hardware (T3.2)

• Implementation of techniques on the Trusted

Platform (Smart card) (T3.2)

• Study and improvement of Encrypted Code

Execution Techniques (T3.3)

• Theoretical study of Observable Cryptography for

the development of models for RE-TRUST (T3.4)

WP3 WP3