The Trusted Execution Module: Commodity General-Purpose Trusted Computing Victor Costan, Luis F. G. Sarmenta, Marten van Dijk, and Srini Devadas Massachusetts

The Trusted Execution Module:Commodity General-Purpose Trusted Computing

Victor Costan, Luis F. G. Sarmenta, Marten van Dijk, and Srini Devadas

Massachusetts Institute of Technology

Presented at CARDIS 2008Royal Holloway, University of London

Egham, Surrey, UK,Sept 10, 2008

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

The TEM: a new secure device model

• A new way to program secure applications:

Feed (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 TEM’s 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

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

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!

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


The TEM vs. conventional smartcard model

• 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

TEM

crypto engineRAM

NVRAMVM

smartcard

crypto enginesecret keys RAM

NVRAMVM

app-lets

CLA INS params hdr public code params

command

Limited set ofpre-installed commands:

CLA INS10 1 getBalance10 2 deposit10 3 withdraw

SECpack

Unlimited set of third-party generated SECpacks

getBalancedepositwithdrawmigrate

SECpacks from Bank

decrypt

clips from MusicCo

migratesong “A”

decrypt migratesong “B” …

unique EK

unencrypted encrypted user-supplieduser-supplied

private code H(…)



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 -> 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



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)



Example: A Bank Account as Closures

• Example in Ruby:

Unoptimized Closure Optimized Closure



Using a TEM

• Compile closures into code + data

• Encrypt sensitive parts of closures using TEM’s EKPublic

• Give set of “SECPacks” to user

• User can use them later without being online

balance | 9174393637

SECpacks from Bank

TEM

crypto engineRAM

NVRAMVM

unique EK

x=100

SECPack

deposit | 9174393637

withdraw| 9174393637

number| 9174393637

withdraw| 9174393637



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 parametersBalance addr. = 0x383…3fae

code:balance += x x=100

x=100code: balance += x [Encrypted(…)]



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



Read vs. Write Access Control

• Easy … just don’t 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



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?



The Replay Attack Problem1. 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

2. 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 doesn’t work either because the new number

will be different from the old one that the SECPacks expect



Usage Flow

• Alice verifies Bob’s TEM’s 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 Alice’s master key; can be a child key certified by the master

Bob’s TEM cert(includes Bob’s

TEM’s PK)

spend

getBalance

create

0xac..fe = 50

purchaserequest

nonceSignPKA’ ( nonce | amount )



Migration

• 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 (Charlie’s)

– Invalidates persistent state on source TEM (Bob’s)

– re-encrypts other related SECPack to new TEM’s

• 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

Bob’s TEM cert(includes Bob’s

TEM’s PK)

spend

getBalance

create

0xac..fe = 50

Charlie’s TEM cert(includes Charlie’s

TEM’s PK)

spend

getBalance

migrate

create



Implementation

• Proof-of-Concept implemented using JavaCard

– Victor Costan’s Master’s 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



Discussion

• Security Assumptions– Security depends on the security of each TEM’s 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



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 it’s usable already now

• But, it’s not limited to JavaCard– Can be implemented by itself– Core is simple easier to make it secure

• For more details, see Victor Costan’s Master’s Thesis at MIT, and http://tem.rubyforge.org/

• For other papers from our group: http://projects.csail.mit.edu/tc/


http://tem.rubyforge.org/



http://projects.csail.mit.edu/tc/



Documents

The Trusted Execution Module: Commodity General-Purpose Trusted Computing Victor Costan, Luis F. G. Sarmenta, Marten van Dijk, and Srini Devadas Massachusetts