Paper Title: AEGIS: Architecture for Tamper-Evident and Tamper-Resistant Processing

Announcement:

  • Final Project: team up; get feedback; start early; either existing project or new one is fine.

Problem:

  • Privacy (<> Resistance in this paper):
    • Data can not be readable without explicit permission.
    • Even when everything is correct, if someone can see or observe, then privacy violated
  • Integrity (<>Tamper evident in this paper):
    • Data can not be manipulated without permission and also without evidence.
    • In paper, any physical or software tampering that can alter the behavior of a program is detected or prevented.
    • Informally, it means what I am doing is correct.

Goal:

  • To allow private execution with integrity
    • with lower overhead
    • minimal TCB (Trusted Computing Base) processing non-trusted software
      • TCB can be implemented using Secure Kernel (SK) and Trusted Processor or,
      • It can be implemented completely in the hardware (Untrusted OS).

Attack model:

  • Every security paper is targeting at a specific attack model, meaning this is “secure” in such context.
  • In this paper,
    • Any accesses to all components such as memory except the chip itself
    • Any software can be modified
    • Application of interest is bug free
  • In reality,
    • (Essentially) Digital attacks: Only data bus really considered
      • Not such attacks at power, timing. Even bug free, we can manipulate by changing voltage.
    • NOTE: They did mention assumption of no digital side channel but this is not a fucus. Side channel attack is an interesting topic. If we may have some time, we can look into this later.

Users:

  • High paranoia
  • When you don’t trust software that is sharing system with whom you don’t trust
  • DRM (Digital Rights Management)
  • Verifiable result and not exposing secret when you don’t trust …
  • (Prevent) hacking

What they do:

  • Integrity: Hash tree (or Merkle tree)
    • Digital signature: mathematical scheme for demonstrating the authenticity of a digital message or documents. It can be computed as smaller than data containing result.
    • Hash requirement: few collision and non-reversible (difficult to be computed and found)
    • To reduce performance overhead upon user requirement of low overhead,
      • Cached hash tree
      • Instead of checking the entire path from the chunk to the root of the tree, the processor checks the path from the chunk to the first hash it finds in the cache, using hierarchy.
    • Does this always work? How can they convince?
      • Probability for collision is low enough.
      • Not reversible by encryption.
  • Privacy: Encryption (One time pad)
    • How encrypt data moving on and off?
      • We can encrypt before data sent and decrypt data received. Direct block encryption scheme will work but suffer from performance degradation.
    • How encrypt and decrypt quick?
      • In class discussion: pipelining / speculation / prefetch / lookup table were suggested
      • Proposed solution: to decouple the AES computation from the corresponding data access using one-time-pad encryption [*] and time stamps.
  • Instructor Note: overlap between reliability (by accident) and security (by malicious). Dependable computing (converged term)
  • Scriber note[*]: There are several versions of this paper. One liked at the course web page does not include One-Time-Pad Encryption which discussed in class, while another version[1] add more about it.

[1] http://csg.csail.mit.edu/pubs/memos/Memo-461/memo-461.pdf

Evaluation:

  • Architecture-wise: simulator based on SimpleScalar with considering different cache size
    • cache block size can be important because it can affect the size of hash tree structure.
    • used SPEC benchmarks to evaluate their implementation.
  • Security-wise:
    • Not much. Summarized in Table I
    • We trust cryptography and specific parameters that they have chosen.
  • Instructor comment: evaluation was minimum but it works for him.

Users and other users:

  • Users: Those who need privacy and integrity and also who willing to pay for them.
  • Minimum impact on other users because we can turn off what they add such as integrity check logic, encryption logic, a few registers, isolation bits in cache and TLB although other users pay a bit more hardware.

Take away lesson:

  • Even for general architecture research, integrity check is very powerful for example to check reliability or error related topics.

Why choose this paper?

  • This is the first paper that came up with a secure architecture and memory encryption.
  • Interesting and nice even without formal verification and proof involved but convincing as well.