SLIDE 1
First year review WP4 overview
Trento - September 24th, 2007
2
Goal of WP4
- Trust and Security Analysis of the various
First year review WP4 overview Trento - September 24th, 2007 Goal - - PowerPoint PPT Presentation
First year review WP4 overview Trento - September 24th, 2007 Goal - - PowerPoint PPT Presentation
First year review WP4 overview Trento - September 24th, 2007 Goal of WP4 Trust and Security Analysis of the various SW-based and combined HW/SW-based methods for the RE-TRUST problem 2 Participants UNITN (WP leader) Team:
SLIDE 2
SLIDE 3
Participants
- UNITN (WP leader)
- Team:
- Yoram OFEK
- Bruno CRISPO
- Amitabh SAXENA
- Jasvir NAGRA
- Paolo TONELLA
- Team:
Team:
- Yoram OFEK
Yoram OFEK
- Bruno CRISPO
Bruno CRISPO
- Amitabh SAXENA
Amitabh SAXENA
- Jasvir NAGRA
Jasvir NAGRA
- Paolo TONELLA
Paolo TONELLA
SLIDE 4
Participants
- UNITN (WP leader)
- KUL
- Team:
- Bart Preneel
- Brecht WYSEUR
- Team:
Team:
- Bart
Bart Preneel Preneel
- Brecht WYSEUR
Brecht WYSEUR
SLIDE 5
Participants
- UNITN (WP leader)
- KUL
- GEM
- Team:
- Jean-Daniel AUSSEL
- Jerome D’ANNOVILLE
- Team:
Team:
- Jean
Jean-
- Daniel AUSSEL
Daniel AUSSEL
- Jerome D
Jerome D’ ’ANNOVILLE ANNOVILLE
SLIDE 6
Participants
- UNITN (WP leader)
- KUL
- GEM
- POLITO
- Team:
- Mario BALDI
- Stefano DI CARLO
- Paolo FALCARIN
- Team:
Team:
- Mario BALDI
Mario BALDI
- Stefano DI CARLO
Stefano DI CARLO
- Paolo FALCARIN
Paolo FALCARIN
SLIDE 7
Participants
- UNITN (WP leader)
- KUL
- GEM
- POLITO
- SPIIRAS
- Team:
- Igor KOTENKO
- Vasily DESNITSKY
- Victor VORONTSOV
- Vitaly BOGDANOV
- Team:
Team:
- Igor KOTENKO
Igor KOTENKO
- Vasily
Vasily DESNITSKY DESNITSKY
- Victor VORONTSOV
Victor VORONTSOV
- Vitaly
Vitaly BOGDANOV BOGDANOV
SLIDE 8
WP4 Tasks
- 4.1: Trust and security analysis of the various SW-based methods
[POLITO] – M24
- 4.2: Trust analysis of combined HW/SW-based and HW-based
methods [POLITO] – M30
- 4.3: Analysis of reverse engineering complexity [UNITN] - M24
- 4.4: Comparative analysis of RE-TRUST with Trusted
Computing (TC) [UNITN] - M36
- 4.5: Analysis of interaction of RE-TRUST with security
protocols [SPIIRAS] - M30
SLIDE 9
9
WP4 Tasks
M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 M16 ...
T4.1 T4.1 T4.2 T4.2 T4.3 T4.3 T4.4 T4.4 T4.5 T4.5
SLIDE 10
10
WP4 Tasks
M17 M18 M19 M20 M21 M22 M23 M24 M25 M26 M27 M28 M29 M30 M31 M32 ...
T4.3 T4.3 T4.2 T4.2 T4.4 T4.4 T4.5 T4.5 T4.1 T4.1
SLIDE 11
11
Task 4.1
- Goal:
Trust and Security Analysis of the various SW-based methods
- Deliverable: D-4.1
- Delivery Date: M24
T4.1 T4.1
SLIDE 12
12
Trust Model
Untrusted platform Untrusted platform HW HW OS OS P P M M Trusted platform Trusted platform
TAG seq. TAG seq. TAG seq. TAG seq.
TAG TAG Validation Validation Monitor Monitor factory factory
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
SLIDE 13
13
Possible Attacks
- Reverse engineering and direct modification of
the code of program
- Modification of the execution environment (eg.
Emulators, debuggers)
- Dynamic change of program’s state without
modifying program
- Execute multiple copies, some modified
- Intercept/modify network messages
T4.1 T4.1
SLIDE 14
14
Proposed Solutions
(Software-based)
- Checksum Based Techniques (POLITO)
- Invariants Monitoring (POLITO)
- Assertions Based Techniques (UNITN)
- Barrier Slicing (UNITN)
- Code obfuscation (KUL, GEM)
- Dynamic replacement (POLITO)
- Obfuscated Virtual Machine (UNITN, KUL)
T4.1 T4.1
SLIDE 15
15
Checksum Approaches
(Analysis)
- Overcomes attack based on direct code modification
- Fails under Memory copy attack
- Attacker keeps a good copy of program along with
tampered one
- For checksums, uses good copy
- Possible because easy to separate execution and data
mode access of program code
- Timing information is difficult to measure across
network
T4.1 T4.1
SLIDE 16
16
Invariants Monitoring
(Analysis)
- Overcomes state modfication
- With a given level of confidence
- Fails if attacker can guess the invariant
- Attacker carries out static/dynamic anaylsis
- Guesses and maintains some subset of these
invariants
- Possible because some invariants are easy to guess
- Possible to use trusted hardware to assist invariant
monitoring
T4.1 T4.1
SLIDE 17
Assertion-based Techniques
(Analysis)
- Overcomes state-modification attacks
- More general than invariants monitoring
- Some states cannot be protected (unsafe states)
- Scales poorly in programs where state history is
important
- All relevant state must be maintained to apply the
assertion.
T4.1 T4.1
SLIDE 18
18
Barrier Slicing
(Analysis)
- Overcomes state-modification and code-modification attacks
- Attacker does not have access to vulnerable code and data
- Scales poorly because server must execute a large amount of code
- Some slices may be quite large
- Defeats one of the objectives of RE-TRUST of performing the most
- f the computation on the client
- Tradeoff between efficiency and security
- Research required to establish a theoretical model to evaluate
- Security properties of the scheme
- Amount of work performed by the server and client
T4.1 T4.1
SLIDE 19
19
Code Obfuscation
(Analysis)
- May increase the effort required by an attacker
- Metrics required to measure effort
- Empirical analysis required to evaluate techniques
- Even empirical studies provide feedback on average-
attacker effort, not best-attacker effort
- Significant problem with class attacks
- Theoretical results of limited value
- Indicate limitations on what is possible
T4.1 T4.1
SLIDE 20
20
Dynamic replacement
(Analysis)
- Early analysis indicates:
- To be effective, monitor must be replaced before
the time attacker takes to reverse-engineer it
- Metrics needed for this time measurement
- Requires a monitor factory that can manufacture
diverse monitors
- Monitor must be strongly integrated with
program to prevent separation
T4.1 T4.1
SLIDE 21
21
Obfuscated Virtual Machine
(Analysis)
- If feasible, would allow for a theorectically
sound solution to RE-TRUST
- Early research:
- Depends on the existence of a secure
- bfuscator for the virtual machine
- Feasibility (UNITN, KUL)
T4.1 T4.1
SLIDE 22
22
Task 4.3
- Goal:
To analyze the complexity (difficulty) of reverse engineering programs after some
- bfuscating transformations are applied to it
- Responsible: UNITN
- Deliverable: D-4.3
- Delivery Date: M24
T4.3 T4.3
SLIDE 23
23
Reverse Engineering
- Examples:
- Learning the algorithm
- Deducing the source
- Extracting embedded (cryptographic) key
- Removing a watermark
- Discovering some property
- Eg. “Is this code watermarked ?”
- Bypassing sections of code
- Alter behavior in other meaningful ways
T4.3 T4.3
SLIDE 24
24
Reverse Engineering
(Analysis)
- Research required to understand the efficacy
- f proposed techniques
- Theorectical Evaluation
- Empirical Evaluation (UNITN/POLITO)
T4.3 T4.3
SLIDE 25
25
Empirical Study
(underway)
- Scenarios:
Low level code only / Low + High level code
- Reverse Engineering Goals:
Extract key / watermark, bypass sections of code, alter behavior
- Obfuscation techniques used:
Renaming / Flattening / Opaque predicates / Snippets, etc
- Languages:
Java, C/C++
- Tools / training / information available to attacker:
Debuggers, de-compilers, emulators, slicers, compilers, etc Partial information of program to be reverse engineered
T4.3 T4.3
SLIDE 26
26
Task 4.5
- Goal:
Analysis of interaction of RE-TRUST with security protocols
- Deliverable: D-4.5
- Delivery date: M30
T4.5 T4.5
SLIDE 27
27
Security Protocols
- WP2 and WP3 provide the basic blocks which
constitute components in a complete system
- Insufficient to show the security of each
component
- Protocol analysis will be required to investigate
the security of the system
- An attacker may not adhere to the proposed
models
- RE-TRUST is about the man-in-the-end attack
T4.5 T4.5