The Trusted Execution Module Commodity General-Purpose Trusted Computing

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 2008 Royal Holloway, University of London Egham, Surrey, UK, Sept 10, 2008

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 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 2

Why? • Allow 3 rd 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 smartcard secret keys crypto engine VM applets TEM unique EK RAM crypto engine NVRAM VM SECpack RAM NVRAM command CLA INS params user-supplied Limited set of pre-installed commands: hdr public code private code H(…) unencrypted CARDIS 2008 get. Balance deposit withdraw migrate • • clips from Music. Co song decrypt migrate “A” song decrypt migrate “B” … • • SECpacks from Bank 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) user-supplied Unlimited set of third-party generated SECpacks CLA INS 10 1 get. Balance 10 2 deposit 10 3 withdraw • • encrypted params 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 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 4

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 CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 5

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) CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 6

Example: A Bank Account as Closures • Example in Ruby: Unoptimized Closure CARDIS 2008 Optimized Closure Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 7

Using a TEM SECpacks from Bank balance | 9174393637 deposit | 9174393637 withdraw| 9174393637 number| 9174393637 SECPack • • 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 CARDIS 2008 withdraw| 9174393637 x=100 TEM unique EK RAM crypto engine NVRAM VM Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 8

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 code: balance += x CARDIS 2008 Balance addr. = 0 x 383… 3 fae [Encrypted(…)] Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) x=100 slide 9

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 STC 06 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 CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 10

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 CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 11

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? CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 12

The Replay Attack Problem 1. 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 CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 13

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, get. Balance 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 Bob’s TEM cert (includes Bob’s TEM’s PK) 0 xac. . fe = 50 create spend get. Balance purchase request nonce • Does not have to be Alice’s master key; can be a child key certified by the master CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 14 Sign. PKA’ ( 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 CARDIS 2008 Bob’s TEM cert (includes Bob’s TEM’s PK) 0 xac. . fe = 50 create spend get. Balance migrate create spend Charlie’s TEM cert (includes Charlie’s TEM’s PK) Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) get. Balance slide 15

Implementation • Proof-of-Concept implemented using Java. Card – Victor Costan’s Master’s thesis, code available on Ruby. Forge – TEM “virtual machine” implemented as a Java. Card applet • stack-based machine model (not to be confused with Java. VM) – 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 JCOP 41 72 K and Philips 21 18 K cards – Bulk of the time is spent doing the asymmetric decryption / encryption CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 16

Discussion • Security Assumptions – Security depends on the security of each TEM’s publicprivate 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 CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 17

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 Java. Card – So it’s usable already now • But, it’s not limited to Java. Card – 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/ CARDIS 2008 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) slide 18