enabling trusted software integrity l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Enabling Trusted Software Integrity PowerPoint Presentation
Download Presentation
Enabling Trusted Software Integrity

Loading in 2 Seconds...

play fullscreen
1 / 21

Enabling Trusted Software Integrity - PowerPoint PPT Presentation


  • 156 Views
  • Uploaded on

Enabling Trusted Software Integrity. Darko Kirovski Microsoft Research Milenko Drinić Miodrag Potkonjak Computer Science Department University of California, Los Angeles. Problem Description. Buffer Overrun. Goal Explore improperly implemented I/O Divert execution to attack code

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Enabling Trusted Software Integrity' - paul


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
enabling trusted software integrity

Enabling Trusted Software Integrity

Darko Kirovski

Microsoft Research

Milenko Drinić

Miodrag Potkonjak

Computer Science Department

University of California, Los Angeles

buffer overrun
Buffer Overrun
  • Goal
    • Explore improperly implemented I/O
    • Divert execution to attack code
  • Simplest variant – Stack smashing
    • “Smashing The Stack For Fun And Profit” by Aleph One (aleph1@underground.org), Phrack 49, 1996.
  • Numerous variants explore different vulnerabilities
    • Tutorials on the Web with bug descriptions
    • setuid() – Chen, Wagner, Dean, 2002.
what can be done
What Can Be Done?
  • StackGuard – Cowan et al., 1998
    • Dummy value next to return address
  • Bounds checking for all pointers – Jones, Kelly, 1995
    • Slow in pointer-intensive software
  • Static analysis – Wagner, 2000
    • Verify all buffers – promising idea
    • Too many false alarms
    • Need to be resolved manually
intrusion prevention
Intrusion Prevention
  • Current approaches
    • Intrusion detection
  • PREVENT rather than DETECT is easier
  • Intrusion prevention system
    • Adversary must solve a computationally difficult task to run programs in high priority
  • Two types of binaries
    • Ordinary
    • Touched with a security wand
  • Run-time verification
outline
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
outline7
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
outline9
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
software installation
Software Installation
  • Installer is on-chip or on an EPROM with verified contents
  • Single process
  • I/O – memory mapped
  • Interrupts disabled
  • Used registers, memory overwritten
  • ~ BOOT on PCs

GOAL: embed constraintsw/o revealing CPUID.

outline11
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
constraint embedding techniques
Constraint Embedding Techniques
  • Entropy of program representation is high
  • Reduce entropy w/ constraints for 50+ bits with preserved performance
  • Exact entropy reduction unique for each CPUID
  • Constraint types
  • Requirements
    • High entropy
    • Functional transparency
    • Transformation invariance
    • Effective implementation
    • Low performance overhead
  • Examples
    • Instruction rescheduling
    • Register assignment
    • Basic block reordering
    • Conditional branch selection
    • Filling unused opcode fields
    • Toggling signs of operands
outline15
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
run time code verification
Run-time Code Verification
  • ARM instruction set and simulated system
  • 50 cycles
  • 20K gates
  • HW support?

Cache line

outline17
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
how to break the system
How to Break the System?
  • Cryptographically secure keyed MAC
    • Hard to extract CPUID from working-copies
    • Hard to create an I-block with CPUID constraints satisfied w/o the CPUID
  • Patch low entropy instruction blocks
    • I-block with low entropy? Example:
      • I-block = one instruction and all other NOPS
    • Hardware must detect I-blocks with low entropy
      • Count and limit domain cardinality
      • Done during domain ordering
  • Patch I-blocks from working copies
    • Difficult? Hard to evaluate w/o a lot of software
outline19
Outline
  • How the system works?
  • Software installation
  • Example of constraint embedding
  • Run-time verification
  • How to break the system?
  • Effect on performance
performance

Simulated w/ ARMulator

  • ARM instruction set
  • MediaBench suite
Performance
  • Embedded bits of entropy
  • Performance effect
    • 13-25% overhead
    • 7-17% with a cache that logs TI-hashes
summary
Summary
  • Intrusion prevention
  • On-line software verification for authenticity
  • Keyed message authentication code
    • Stored as footer
    • Stored as constraints
      • 50% decrease in code size overhead
  • Public and trusted execution mode
  • Relatively hi/lo performance overhead
    • No hardware acceleration
    • 20% - sets back Moore’s Law 4.5 months 