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: • • Team: Team: - - - Yoram OFEK Yoram OFEK Yoram OFEK - - - Bruno CRISPO Bruno CRISPO Bruno CRISPO - - - Amitabh SAXENA Amitabh SAXENA Amitabh SAXENA - - - Jasvir NAGRA Jasvir NAGRA Jasvir NAGRA - - - Paolo TONELLA Paolo TONELLA Paolo TONELLA
Participants • UNITN (WP leader) • KUL • Team: • • Team: Team: - - - Bart Preneel Bart Preneel Bart Preneel - - - Brecht WYSEUR Brecht WYSEUR Brecht WYSEUR
Participants • UNITN (WP leader) • KUL • GEM • Team: • • Team: Team: - - - Jean- -Daniel AUSSEL Daniel AUSSEL Jean Jean-Daniel AUSSEL - - - Jerome D’ Jerome D ’ANNOVILLE ANNOVILLE Jerome D’ANNOVILLE
Participants • UNITN (WP leader) • KUL • GEM • POLITO • Team: • • Team: Team: - Mario BALDI - - Mario BALDI Mario BALDI - Stefano DI CARLO - - Stefano DI CARLO Stefano DI CARLO - Paolo FALCARIN - - Paolo FALCARIN Paolo FALCARIN
Participants • UNITN (WP leader) • KUL • GEM • POLITO • SPIIRAS • Team: • • Team: Team: - - - Igor KOTENKO Igor KOTENKO Igor KOTENKO - - - Vasily DESNITSKY DESNITSKY Vasily Vasily DESNITSKY - - - Victor VORONTSOV Victor VORONTSOV Victor VORONTSOV - - - Vitaly BOGDANOV BOGDANOV Vitaly Vitaly BOGDANOV
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
WP4 Tasks M16 ... M1 M2 M3 M4 M5 M6 M7 M8 M9 M10 M11 M12 M13 M14 M15 T4.1 T4.1 T4.2 T4.2 T4.3 T4.3 T4.4 T4.4 T4.5 T4.5 9
WP4 Tasks M17 M18 M19 M20 M21 M22 M23 M24 M25 M26 M27 M28 M29 M30 M31 M32 ... T4.1 T4.1 T4.2 T4.2 T4.3 T4.3 T4.4 T4.4 T4.5 T4.5 10
T4.1 T4.1 Task 4.1 • Goal: Trust and Security Analysis of the various SW-based methods • Deliverable: D-4.1 • Delivery Date: M24 11
Trust Model Untrusted platform Untrusted platform Trusted platform Trusted platform HW HW OS OS P TAG TAG P TAG seq. TAG seq. TAG seq. TAG seq. Validation Validation M M M Monitor replacement 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 factory factory 12
T4.1 T4.1 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 13
T4.1 T4.1 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) 14
T4.1 T4.1 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 15
T4.1 T4.1 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 16
T4.1 T4.1 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 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 of 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 18
T4.1 T4.1 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 19
T4.1 T4.1 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 20
T4.1 T4.1 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 obfuscator for the virtual machine • Feasibility (UNITN, KUL) 21
T4.3 T4.3 Task 4.3 • Goal: To analyze the complexity (difficulty) of reverse engineering programs after some obfuscating transformations are applied to it • Responsible: UNITN • Deliverable: D-4.3 • Delivery Date: M24 22
T4.3 T4.3 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 23
T4.3 T4.3 Reverse Engineering (Analysis) • Research required to understand the efficacy of proposed techniques • Theorectical Evaluation • Empirical Evaluation (UNITN/POLITO) 24
T4.3 T4.3 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 25
T4.5 T4.5 Task 4.5 • Goal: Analysis of interaction of RE-TRUST with security protocols • Deliverable: D-4.5 • Delivery date: M30 26
T4.5 T4.5 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 27
Recommend
More recommend
