The Trusted Execution Module: Commodity General-Purpose Trusted Computing

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

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

3. Why? slide 3 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) • 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

4. 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 smartcard TEM RAM app-lets secret keys unique EK RAM crypto engine crypto engine NVRAM NVRAM VM VM SECpack command hdr public code params CLA INS private code H(…) params user-supplied unencrypted encrypted 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 slide 4 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) 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 -> 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) 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) 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) Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) CARDIS 2008

8. Using a TEM TEM unique EK RAM SECpacks from Bank crypto engine NVRAM VM balance | 9174393637 deposit | 9174393637 withdraw| 9174393637 number| 9174393637 SECPack x=100 withdraw| 9174393637 • 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 slide 8 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) 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. = 0x383…3fae code:balance += x x=100 x=100 [Encrypted(…)] code: balance += x slide 9 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) 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) Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) CARDIS 2008

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

14. 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) 0xac..fe = 50 create spend getBalance SignPKA’ ( nonce | amount ) nonce purchaserequest slide 14 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) CARDIS 2008

15. 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) 0xac..fe = 50 create spend getBalance migrate create spend Charlie’s TEM cert (includes Charlie’s TEM’s PK) getBalance slide 15 Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) Trusted Execution Module (Costan, Sarmenta, van Dijk, and Devadas, MIT) CARDIS 2008

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

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