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 • Team: • KUL (WP leader) • • Team: Team: - - - Bart PRENEEL Bart PRENEEL Bart PRENEEL - - - Jan CAPPAERT Jan CAPPAERT Jan CAPPAERT - - - Sebastian FAUST Sebastian FAUST Sebastian FAUST - - - Thomas HERLEA Thomas HERLEA Thomas HERLEA - - - Dries SCHELLEKENS Dries SCHELLEKENS Dries SCHELLEKENS - - - Brecht WYSEUR Brecht WYSEUR Brecht WYSEUR
Participants • KUL (WP leader) • GEM • Team: • • Team: Team: • • • Jean- -Daniel AUSSEL Daniel AUSSEL Jean Jean-Daniel AUSSEL • • • Jerome D’ ’ANNOVILLE ANNOVILLE Jerome D Jerome D’ANNOVILLE
Participants • KUL (WP leader) • GEM • UNITN - Team: - - Team: Team: - - - Paolo TONELLA Paolo TONELLA Paolo TONELLA - - - Mariano CECCATO Mariano CECCATO Mariano CECCATO - - - Jasvir NAGRA Jasvir NAGRA Jasvir NAGRA - - - Milla DALLA PREDA DALLA PREDA Milla Milla DALLA PREDA - - - Amitabh SAXENA Amitabh SAXENA Amitabh SAXENA
Participants • KUL (WP leader) • GEM • UNITN • POLITO • Team: • • Team: Team: • • • Stefano DI CARLO Stefano DI CARLO Stefano DI CARLO • • • Alberto SCIONTI Alberto SCIONTI Alberto SCIONTI
Participants • KUL (WP leader) • GEM • UNITN • POLITO • SPIIRAS • Team: • • Team: Team: • • • Igor KOTENKO Igor KOTENKO Igor KOTENKO • • • Vasily DESNITSKY Vasily DESNITSKY Vasily DESNITSKY
Tasks D3.1 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
Tasks T3.1 T3.1 ... ... M1 M1 M2 M2 M3 M3 M4 M4 M5 M5 M6 M6 M7 M7 M8 M8 M9 M9 M10 M11 M12 M13 M14 M15 M16 M10 M11 M12 M13 M14 M15 M16 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 Trust model Untrusted platform (U) Trusted platform (T) HW HW OS OS TAG P TAG P TV’ TAG seq. TAG seq. TAG seq. TAG seq. Validation Validation M Monitor replacement M Monitor replacement M o o n n i i t t o o r r r r e e p p l l a a c c Monitor e e Monitor m m e e n n t t MF’ Factory Factory Trusted hardware (H) P’ M’
Tasks T3.2 T3.2 ... ... M1 M1 M2 M2 M3 M3 M4 M4 M5 M5 M6 M6 M7 M7 M8 M8 M9 M9 M10 M11 M12 M13 M14 M15 M16 M10 M11 M12 M13 M14 M15 M16 T3.1 T3.1 T3.3 T3.3 T3.4 T3.4
T3.2 T3.2 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 Hardware/Software Co-Obfuscation 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 Confidentiality Integrity
T3.2 T3.2 T3.2 Hardware/Software Co-Obfuscation TPM Assisted Remote Software Entrusting (KUL) Trusted computing approach: remote attestation Option Memory Hardware ROMs OS Network OS Application CRTM BIOS loader root of trust in integrity measurement New OS trusted component Component TPM measuring root of trust reporting in integrity storing values reporting logging methods
T3.2 T3.2 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 Trusted platform Trusted platform Untrusted platform Untrusted platform c := cksum(n,M) c := cksum(n,M) n M M M M c h := hash(c,P) h h := hash(c,P) P P P P t 2 – t 1 < � � t expected � �
T3.2 T3.2 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 Hardware/Software Co-Obfuscation T3.2 T3.2 TPM Assisted Remote Software Entrusting (KUL) Enhanced solution: TPM tick stamping Trusted platform Untrusted platform Trusted platform Untrusted platform c := cksum(TS 1 ,M) c := cksum(TS 1 ,M) n TS 1 TS 1 := Sign TPM (n||t 1 ) M M M M TPM TPM TS 2 := Sign TPM (c||t 2 ) TS 2 h := hash(TS 2 ,P) h := hash(TS 2 ,P) h P P P P t 2 – t 1 < � t expected
T3.2 Hardware/Software Co-Obfuscation T3.2 T3.2 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 of 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) ������� Program P Un-trusted host Trusted host Card Reader Virtual secure channel
T3.2 T3.2 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
Tasks T3.3 T3.3 ... ... M1 M1 M2 M2 M3 M3 M4 M4 M5 M5 M6 M6 M7 M7 M8 M8 M9 M9 M10 M11 M12 M13 M14 M15 M16 M10 M11 M12 M13 M14 M15 M16 T3.1 T3.1 T3.2 T3.2 T3.4 T3.4
T3.3 T3.3 Encrypted Code Execution Goal “Go beyond obfuscation, to provably secure code execution” Model “An attacker can monitor all memory accesses” Computing with Computing with Encrypted Data Encrypted Functions
T3.3 T3.3 T3.3 Encrypted Code Execution Computing with Encrypted Data (GEM - KUL) Trusted Platform Untrusted Platform Trusted Hardware E(x i ) • E E(x 1 ),E(x 2 ),...,E(x n ) x 1 ,x 2 ,...,x n • F G F(x 1 ,x 2 ,...,x n ) ? D G(E(x 1 ),E(x 2 ),...,E(x n ))
T3.3 T3.3 T3.3 Encrypted Code Execution Computing with Encrypted Functions (GEM - KUL) Trusted Platform Untrusted Platform Trusted Hardware x 1 ,x 2 ,...,x n E(F) F E E(F) F(x 1 ,x 2 ,...,x n ) ? D E(F)(x 1 ,x 2 ,...,x n )
T3.3 T3.3 T3.3 – Encrypted Code Execution White-Box Crypto against Side- Channel Attacks (GEM - KUL) Cryptographic implementation secure in Smartcard white-box model CPU Cache Secure in a grey-box Memory model (existing AND future (!) attacks)
Tasks T3.4 T3.4 ... ... M1 M1 M2 M2 M3 M3 M4 M4 M5 M5 M6 M6 M7 M7 M8 M8 M9 M9 M10 M11 M12 M13 M14 M15 M16 M10 M11 M12 M13 M14 M15 M16 T3.1 T3.1 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
Recommend
More recommend
