The Trusted Execution Module: Commodity General-Purpose Trusted Computing

1
The Trusted Execution ModuleCommodity
General-Purpose Trusted Computing

• Victor Costan, Luis F. G. Sarmenta, Marten van
  Dijk, and Srini Devadas
• Massachusetts Institute of Technology
• Presented at CARDIS 2008
• Royal Holloway, University of London
• Egham, Surrey, UK,
• Sept 10, 2008

2
The TEM a new secure device model

• A new way to program secure applicationsFeed
  (partially)-encrypted code/data packets as inputs
  to a Trusted Execution Module (TEM)
• Allows secure and private execution of code
  and/or data
• protected from TEMs potentially malicious host
  machine
• Allows any third party to write apps for it
• even untrusted ones
• Supports persistent state, optionally stored
  outside the TEM
• Secure against replay and tampering by
  non-related apps
• Enables new ways of using secure devices
• Arbitrary third party secure distributed apps
  without online TTPs

slide 2
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
3
Why?

• Allow 3rd parties to write secure apps using TEMs
  on users machines without needing to go through
  Trusted Third Party (TTP) for installation
• Analogy Think of revolutionary difference
  between sandboxed browser-based apps (Java,
  Flash, etc.) vs. traditional apps that need
  complex installation
• Create a new market for secure apps
• Enables independent development and rapid and
  easy deployment
• Allow private groups to create their own in-house
  secure apps without going through a TTP
• e.g., school club can create their own secure
  virtual e-tickets or e-tokens
• e.g., small company can create secure apps for
  their employees
• Create new possible applications
• e.g., user-programmed mobile agents running on
  servers with TEMs
• e.g., secure/private outsourced computations on
  servers with TEMs
• Current smartcards (used conventionally) cannot
  do this!

slide 3
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
4
The TEM vs. conventional smartcard model
TEM
smartcard
RAM
app-lets
secret keys
unique EK
RAM
crypto engine
crypto engine
NVRAM
NVRAM
VM
VM
command
SECpack
CLA
INS
hdr public code
params
private code H()
params
unencrypted
encrypted
user-supplied
user-supplied
Limited set ofpre-installed commands CLA
INS 10 1 getBalance 10 2
deposit 10 3 withdraw
Unlimited set of third-party generated SECpacks
SECpacks from Bank
clips from MusicCo
song A
getBalance
decrypt
migrate
deposit
song B
withdraw
decrypt
migrate

migrate

• Commands typically pre-installed
• Only trusted parties are allowed to install
  commands (usually)
• Limited functionality
• Installed apps are not migratable to other
  smartcards (without online trusted party)

• TEM accepts secure closures
• Even untrusted parties can write closures for the
  TEM (without affecting other parties)
• Arbitrary functionality
• Supports count-limited operations and offline
  migratable clips

slide 4
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
5
TEM vs. conventional smartcards

• TEM uses public-key encryption, not symmetric
  encryption
• This is important because otherwise, we cannot
  allow arbitrary third parties to write
  applications for the TEM
• This is inspired by the TPM model
• Minimum just one keypair -gt Endorsement Key
  (EK), used for decryption
• Or, can use more complex TPM techniques
• Storage keys and Identity keys, Key hierarchies,
  Direct Anonymous Attestation, etc.
• Unlike a TPM
• TPM is limited to a few functions (decryption,
  signing, etc.)
• TEM can execute arbitrary functions given in
  encrypted code and data packets (aka SECPacks)
• Unlike a (conventional) smartcard
• A difference in possible distribution methods
• Different style of programming
• Again Think of revolutionary difference between
  browser-based apps (Java, Flash, AJAX, etc.) vs.
  traditional apps that needed complex installation

slide 5
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
6
Secure Closures (SECs)

• Closure a fragment of code representing a
  function with some of its variables already bound
  to a particular value
• Example in Java (draft JSR)

slide 6
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
7
Example A Bank Account as Closures

• Example in Ruby

Unoptimized Closure
Optimized Closure
slide 7
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
8
Using a TEM
SECpacks from Bank
balance 9174393637
deposit 9174393637
withdraw 9174393637
number 9174393637
SECPack
x100
withdraw 9174393637

• Compile closures into code data
• Encrypt sensitive parts of closures using TEMs
  EKPublic
• Give set of SECPacks to user
• User can use them later without being online

slide 8
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
9
SECPack and TEM Input Structure

• Inspired by TPM wrapped key data structures
• Three parts
• Private code and data that need to be kept
  secret from host
• Shared code and data that can be viewed by host,
  but not changed
• Open code and data that can be viewed and
  changed by host i.e., host-provided parameters

Balance addr. 0x3833fae
codebalance x
x100
x100
Encrypted()
code balance x
slide 9
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
10
Persistent State

• TEM supports read and write of special
  persistent variables
• can be stored in internal NVRAM
• or externally using a hash-tree scheme see our
  ACM STC06 paper
• Each persistent variable has a long (e.g,
  160-bit) address
• Address is kept in private part of SEC
• Issuer of SECPacks generates this secret address
• Related SECPacks (e.g., deposit and withdraw) use
  the same address
• Other SECPacks do not know the address and cannot
  access the data
• Long address is essentially also its access key

slide 10
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
11
Read vs. Write Access Control

• Easy just dont give the user any code that
  writes the variable
• People who get read/write access get two SECPacks
• People who get read-only access only get the read
  SECPack
• This is like capability-based access control,
  where SECPacks act as capability tokens

slide 11
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
12
The Replay Attack Problem

• Running withdraw twice is not a problem
• Second execution will read updated value of
  balance
• For externally stored data, root hash inside TEM
  protects freshness
• The problem what if we replay the creation of
  the bank account?
• Since the TEM is out-in-the-field, the original
  point of creation of the bank account on the
  target TEM happened at some point in response to
  a host feeding its TEM a creation SECPack issued
  by the Bank
• What if the host ran that SECPack again?

slide 12
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
13
The Replay Attack Problem

• Simple Solution Never allow creation twice
• If an address is already used, it cannot be
  recreated or used for anything else
• Problem irreversibly growing physical memory
  requirement
• We could add a remove method, but then this
  will allow replay attacks
• More complex solution (allows the re-use of
  physical space)
• First, the TEM is given a creation SECPack that
  causes the TEM to generate a new number and
  associate it with the newly created address
• This number is given to the Issuer, who then
  codes the rest of the SECPacks so that they work
  only if the number associated with new address is
  still the same
• remove of address is done by deleting the
  number associated with it.
• Thus, existing SECPacks will not work anymore..
• Running the creation SECPack again doesnt work
  either because the new number will be different
  from the old one that the SECPacks expect

slide 13
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
14
Usage Flow
Bobs TEM cert (includes Bobs TEMs PK)

• Alice verifies Bobs TEMs certificate
• Alice generates and sends Bob a CREATE SECPack
• Bob executes it on his TEM and returns result to
  Alice
• associates physical space with new variable
• this includes the new number
• Alice generates the rest of the SECPacks
• e.g., spend, getBalance
• Bob can now use SECPacks without interaction with
  Alice
• e.g., spend can be implemented as a signature
  operation using a key certified to be associated
  with Alice
• Does not have to be Alices master key can be a
  child key certified by the master

0xac..fe 50
create
spend
getBalance
SignPKA ( nonce amount )
purchaserequest
nonce
slide 14
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
15
Migration
Bobs TEM cert (includes Bobs TEMs PK)

• Migratable tokens are useful
• cash-like usability
• more like the real-world (tickets, books, etc.)
• We can implement these using migratable SECpacks
• migrate SECpack
• verifies certificate of target TEM (Charlies)
• Invalidates persistent state on source TEM
  (Bobs)
• re-encrypts other related SECPack to new TEMs
• This is done with special TEM operations and/or
  special privileged SECPacks given by TEM
  manufacturer to TEM owner
• enables the operations above, while preventing
  attackers from using the same mechanism to
  decrypt SECpacks arbitrarily

0xac..fe 50
create
spend
getBalance
migrate
create
spend
Charlies TEM cert (includes Charlies TEMs PK)
getBalance
slide 15
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
16
Implementation

• Proof-of-Concept implemented using JavaCard
• Victor Costans Masters thesis, code available
  on RubyForge
• TEM virtual machine implemented as a JavaCard
  applet
• stack-based machine model (not to be confused
  with JavaVM)
• Support code in Ruby
• Use Ruby program running on a PC to communicate
  with Card
• Use Ruby to write assembly language code, to go
  into SECPacks
• Performance
• Tested on NXP JCOP41 72K and Philips 21 18K cards
• Bulk of the time is spent doing the asymmetric
  decryption / encryption

slide 16
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
17
Discussion

• Security Assumptions
• Security depends on the security of each TEMs
  public-private key pair
• If that gets compromised, then SECpacks sent to
  that TEM will be compromised
• Issuers should design their apps accordingly
• e.g., do not use the same keys on all TEMs
• Future Work
• Look into more applications taking advantage of
  the TEMs ability to do arbitrary computation

slide 17
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008
18
Conclusion

• We present a new device mode that enables a new
  way of thinking about and designing
  trusted-hardware-based secure applications
• We have prototyped it using JavaCard
• So its usable already now
• But, its not limited to JavaCard
• Can be implemented by itself
• Core is simple ? easier to make it secure
• For more details, see Victor Costans Masters
  Thesis at MIT, and http//tem.rubyforge.org/
• For other papers from our group
  http//projects.csail.mit.edu/tc/

slide 18
Trusted Execution Module (Costan, Sarmenta, van
Dijk, and Devadas, MIT)
CARDIS 2008