Securely Using Untrusted Terminals and Compromised Machines with Human-Verifiable Code Execution

1
Securely Using Untrusted Terminals and
Compromised Machines with Human-Verifiable Code
Execution

• Jason Franklin, Mark Luk, Arvind Seshadri, Adrian
  Perrig

2
How can we trust our devices?

• How do I securely use a device I dont trust?
• Terminal in an Internet café or conference
• What about compromised devices?
• My PDA, home/work/car computer

3
Human-Verifiable Code Execution (HVCE)

• How can I know what is executing on my PDA?
• Example encrypted data stored on PDA, how can I
  be assured that no malware steals password?
• Goal human-verifiable code execution to prevent
  malware from undetectably interfering with
  application

4
Human-Verifiable Code Execution

• Problem Statement
• Provide a human verifier with a guarantee that a
  target executable has been invoked for execution
  in an untampered environment, such that no other
  code can interfere with its execution
• Guarantee must be obtained without direct
  assistance of another computational device and be
  verifiable by a human

5
Past Human-Verifiable Code Execution

• We had human-verifiable code execution in the
  past!
• On punchcard-based mainframes, programmer could
  hear when his program was executing!
• Or, in modern times, my machine acts strangeI
  quickly type
• gt ps auwx
• Can we achieve secure human-verifiable code
  execution on todays platforms?

6
Outline

• Vision
• Untrusted Terminal Problem
• Binary and Generalized
• Hardware-based HVCE
• Software-based HVCE
• Building verifiable applications
• User study
• Ongoing Work
• Conclusion

7
Binary Untrusted Terminal Problem
Untrusted Terminals
Trusted Terminals
8
Generalized Untrusted Terminal Problem

• Levels of trust exist beyond completely trusted
  and untrusted

9
Current Approaches
10
Outline

• Vision
• Untrusted Terminal Problem
• Binary and Generalized
• Hardware-based HVCE
• Software-based HVCE
• Building verifiable applications
• User study
• Ongoing Work
• Conclusion

11
Hardware-Based HVCE

• Based on AMDs Pacifica and Intels LT
• Next generation platforms for secure
  virtualization
• Include hardware Trusted Platform Module (TPM)
• New instructions skinit (AMD) and senter (Intel)
• Provide guarantee of externally-verifiable code
  execution
• Guarantee not useful to human verifier
• Require modifications to allow human verifier

12
TCG Trusted Platform Module (TPM)
13
Basic TPM Functionality

• TPM contains 16 program configuration registers
  (PCRs) to store integrity measurements
• Operations on PCRs
• TPM_Extend(N, S) PCRN SHA-1(PCRN S)
• TPM_Read(N) Return contents of PCRN
• TPM contains private key to sign attestations and
  manufacturer certificate
• Tamper resistant storage for private key K-1AIK
• Manufacturer certificate, for example KAIK
  K-1IBM

14
Externally-Verifiable Code Execution

• On call to skinit(target_exe_p)
• CPU transfers executable image to TPM over LPC
  bus
• TPM hashes executable image and stores in PCR
• CPU sets up untampered execution environment
• Disables interrupts
• Sets up memory protections to disable DMA writes
  to memory locations containing target executable
• CPU jumps to target executable and executes

Remote platform
Verifier
15
Externally-Verifiable Code Execution

• Verifier sends 160 bit nonce to remote platform
• Remote platform returns signed hash of target
  executable and nonce
• Verifier uses remote platforms public
  attestation identity key to check signature and
  verifies that correct executable has been invoked

16
Enabling a Human Verifier
Verifier
Remote platform
Untrusted Terminal
Sign (H (target_exe, nonce), AIK_priv)
H(target_exe)

• Human needs list of challenge response pairs
• Generating pairs requires access to AIK_priv
• Only available to TPM
• Cant trust software on device to generate pairs
• Solution Add verify button and utilize existing
  secure I/O functionality
• Verify button directly invokes skinit on fixed
  memory location containing executable and
  arguments
• Human verifies hash of target executable
  displayed in trusted area of screen
• Eliminates need for challenge response pairs
• Requires further modifications to next generation
  hardware

17
Outline

• Vision
• Untrusted Terminal Problem
• Binary and Generalized
• Hardware-based HVCE
• Software-based HVCE
• Building verifiable applications
• User study
• Ongoing Work
• Conclusion

18
Software-Based Approach

• Extend current software-based attestation
  primitives
• Establish trusted input and output paths for
  human verifier
• Advantages of software technique
• Works on legacy devices
• Software-based solutions can be fixed if
  vulnerability discovered
• TPMs require hardware changes to fix
  vulnerabilities (SHA-1)
• Avoids privacy concerns with remote attestation
• Disadvantages
• Difficult to reason about security

19
Software-based Attestation Overview

• External, trusted verifier knows expected memory
  content of device
• Verifier sends challenge to untrusted device
• Assumption attacker has full control over
  devices memory before check
• Device returns memory checksum, assures verifier
  of memory correctness

Remote Platform
External Verifier
Device memory
Expected device memory content
20
Verifiable Code Execution with Pioneer

• First step to address untampered code execution
  on untrusted legacy hosts
• Implemented on Intel Pentium IV
• Approach
• Verify code integrity through software-based
  attestation
• Set up untampered code execution environment
• Execute code

21
Assumptions and Attacker Model

• Assumptions on verifier
• Knows hardware configuration of remote device
• Assumptions on device (untrusted host)
• Hardware and firmware is trustworthy
• Can only communicate with verifier no proxy
  attacks
• Attacker controls devices software and OS before
  verification

22
Design of Pioneer Function
Root of Trust
Checksum Code
Hash Function
Verification Function

• Compute checksum
• Set up untampered
• execution environment

Measure Integrity
Invoke
Target Code
23
The Pioneer Protocol
Remote Platform
Verifier

• Successful verification if t2 t1 lt
  expected time cksum exp. cksum

Checksum Code
Hash Function
Target Code
24
Checksum Requirements

• Optimal implementation code cannot be optimized
• Denali project _at_ HP labs provides proof of
  optimal implementation of short pieces of code
• GNU superopt
• Open challenge to prove optimality of checksum
  function
• No algebraic optimizations
• Checksum has to be computed in entirety
• Given a memory change, checksum cannot be
  adjusted without recomputation

25
Desired Security Property

• Verifiers check is successful if and only if
• Verification function is unmodified
• Untampered execution environment is established
• Intuition Checksum is incorrect or checksum
  computation slows down if attacker
• Modifies verification function and forges correct
  checksum, or
• Fakes creation of untampered code execution
  environment

26
Challenges on Modern CPUs

• Execution time non-determinism
• Out-of-order execution
• Cache and virtual memory
• Dynamic CPU clock speed scaling
• DMA-based attacks from malicious peripherals
• Interrupt-based attacks
• Non-maskable interrupts
• Attacks using exceptions
• Virtualization-based attacks

27
Results Runtime Difference
28
Results Runtime Difference
29
Results Runtime Difference
30
Results Runtime Difference
31
Results Runtime Difference
32
Results Runtime Difference
.3ms
33
Enabling a Human Verifier

• Humans have limited powers of perception and
  computation
• Challenges
• Cant create secure random nonces
• Cant compute correct checksum
• Cant accurately time checksum computation
  (.3ms?)

34
Enabling a Human Verifier

• Provide user access to list of challenge response
  pairs and detection threshold
• Similar to two factor authentication in European
  online banking systems
• Increase time of checksum computation
• Human measures checksum time using stopwatch

35
Challenge-Response Pair Generation and Management

• Pairs must be unpredictable and secret
• Threats to generation process include
• Pair creator could be malicious
• Legitimate challenge-response pair leaked
• Only require one pair to bootstrap creation of
  list
• Issue challenge to device
• Check response
• Generate additional pairs in untampered execution
  environment
• Recommend maintain a list of challenge-response
  pairs

36
Challenge-Response Pair Generation and Management

• Manufacturer could generate initial pairs and
  include with device
• Use isolated machine with tamper-evident hardware
  and specialized software
• Does not require additional trusted entities
• Already trust manufacturer
• Could provide out-of-band method to acquire
  additional pairs
• Phone, mail, or SMS

37
Increasing Computation Time

• Adversary overhead on x86 is around 2
• Running checksum longer isnt reasonable or
  usable
• Even with a 10min checksum we only see 12sec
  overhead
• 2 of 10mins 12sec adversary overhead
• Solution required a simpler architecture
• Redesigned Pioneer for Intel XScale-PXA255
  processor
• 16 general purpose registers, 2 processor status
  registers, seven processor modes
• Simple architecture reduces number of possible
  attacks and increases adversary overhead
• Fastest known attack on XScale implementation
  (memory copy attack) has overhead of close to 40
  

38
Implementation

• Sharp Zaurus PDA SL-6000
• Intel XScale CPU
• Linux kernel 2.4.19
• Implemented as kernel module
• Checksum loop is assembly, remainder is C
• Using 80-bit challenges and responses

39
Security Analysis

• Probabilistic guessing attacks
• Device attempts to gain pre-computation advantage
  by guessing remaining characters of challenge as
  it is input
• Exploits fact that humans may slowly input
  challenge
• Countermeasure Use realistic bounds on
  attackers overhead
• Challenge-response pair secrecy, integrity, and
  freshness
• Various threats including malicious printers and
  eavesdropping
• Social engineering attacks
• Malicious program ask user to press return after
  entering challenge
• Malicious program beeps early to signal
  completion
• Denial of Challenge Attack
• Malicious software consistently crashes the
  device after observing challenges

40
Outline

• Vision
• Untrusted Terminal Problem
• Binary and Generalized
• Hardware-based HVCE
• Software-based HVCE
• Building verifiable applications
• User study
• Ongoing Work
• Conclusion

41
Secure Digital Signature Application

• Scenario User wants to sign a message using a
  private key encrypted under a password
• Steps to sign message with PGP application
• Start signature application and enter password
• Application decrypts private key using password
• Application uses decrypted private key to sign
  message
• Application erases decrypted key in memory and
  exits
• Avenues of attack include
• Malware can steal password used to decrypt
  private key
• Malware can capture decrypted private key in
  memory
• Malware can perform a message substitution attack
  and sign a different message

42
Secure Digital Signature Application

• Developed verifiable digital signature using
  software-based HVCE
• Implemented as a kernel module
• User loads kernel module and issues challenge
• User checks response and execution time
• Digital signature application executes in an
  untampered execution environment
• Untampered execution environment provides
  guarantee that malware did not steal password or
  private key through eavesdropping or memory
  monitoring

43
Digital Signature Application User Study

• 12 users with various levels of experience with
  PDAs
• 7 male and 5 female
• 5 between 18-22, 5 between 23-30, and 2 older
  than 31
• Implementation Linux kernel of Sharp Zaurus PDA
• Provided list of challenge-response pairs
• asjmxk 20fa667fdf059980 30.2s
• tpaskon ace665f453199a0b 30.2s
• Provided four test scripts to user
• 2 used correct verification function
• 1 maliciously computed correct checksum with a
  delay
• 1 maliciously returned incorrect checksum on time
• Told users to accept if checksum if correct and
  running time lt 42s
• Results
• False Positives
  0/24
• False Negative (delayed execution)
  0/12
• False Negative (incorrect checksum)
  1/12

44
Verification of Voting Machines

• Challenge verify correctness of software on
  voting machine
• Incident wrong software was executing on voting
  machine on election day
• Approach leverage human-verifiable code
  execution protocol to ensure correctness of
  software on voting machine

45
Verification of Voting Machines

• County generates challenge-response pairs
• Generated by isolated computer
• Can be validated by public after election
• Challenge-response pair lists sent to poll
  workers
• Poll workers periodically tests voting machine SW
• Type challenge into voting machine
• Measure computation time
• Verify response
• Provides stronger guarantees than random auditing
  of machines

46
Ongoing Work

• Improving usability of software-based technique
• Developing techniques to check a thin
  security-visor which then enforces policy on
  programs
• Increases TCB
• Increase the number of verifiable applications
• Beginning standardization with NIST

47
Conclusions

• Described design of hardware and software-based
  systems for human-verifiable code execution
• Software-based human-verifiable code execution
  feasible on simple architectures
• HVCE can provide trusted path for input and
  output
• Strong guarantees even to a human verifier
• HVCE enables development of verifiable
  applications
• Described a sample verifiable application to
  securely sign messages on a untrusted terminal
• Software-based HVCE can be used today to enable
  verification of voting machine software integrity
  without hardware changes

48
Related Work

• Hardware-based untampered execution
• Cerium µkernel running inside caches of a
  tamper-resistant CPU Chen et al.
• XOM Mutually untrusting applications execute on
  (possibly) malicious OS Lie et al.
• Mondrix Fine-grained memory protection for Linux
  using the Mondriaan system Witchel et al.
• HW-based attestation
• Load-time attestation using TCG specs Sailer et
  al.
• Terra Use trusted VMM for attestation Garfinkel
  et al.
• Copilot Use add-in PCI card for attestation
  Petroni et al.
• Software-based attestation
• Genuinity Uses CPU architecture features to
  distinguish between execution on actual hardware
  and a simulator Kennell et al.
• Software tamperproofing