SABLE on TPM 2.0

1. SABLE on TPM 2.0 Scott Constable

2. What’s new in TPM 2.0? • Completely new key hierarchy Syracuse University

3. Key Hierarchy • TPM 1.2: Syracuse University

4. TPM Device Key Hierarchy Persistent Keys Transient Keys • TPM 2.0: Key Cache Manager Storage Key Storage Device Signing Key Primary Storage Key Primary Signing Key Syracuse University

5. What’s new in TPM 2.0? • Completely new key hierarchies • Everything is an “entity” Syracuse University

6. Entities • TPM 2.0 entities include: • Hierarchies • Lockout mechanism • NV indexes • PCRs • Keys • Data • Each entity can have its own • Password • Access control policy Syracuse University

7. What’s new in TPM 2.0? • Completely new key hierarchy • Everything is an “entity” • Uniform access control policies Syracuse University

8. Access Control Policies • Can be applied to any TPM entity • Four kinds, inductively defined: • Simple assertion policy: a single (atomic) authority assertion • Multi-assertion policy: a conjuction (logical AND) of policies • Compound policy: a disjunction (logical OR) of policies Syracuse University

9. Access Control Policies (Cont.) • Flexible policy: a policy that can be updated by a trusted party • When initialized, a flexible policy stores a digest of the public key that is allowed to update the policy • How to Revoke a policy? Use a monotonic counter with TPM2_PolicyNV • This would allow us to allow multiple configurations (PCR values) to unlock one disk AND revoke access to the disk from one or more configurations, all without needing to change the FDE key Syracuse University

10. Access Control Policies • TPM2_PolicyAuthValue: Requires HMAC session • TPM2_PolicyCommandCode: Only a particular command is allowed • TPM2_PolicyCounterTimer: Predicate on time • TPM2_PolicyCpHash: Only allow certain commands, parameters • TPM2_PolicyLocality: Check that command is executed from a particular locality • TPM2_PolicyNameHash: Apply the policy to certain objects • TPM2_PolicyPCR: Check that specified PCRs have specified values when the command is executed • TPM2_PolicyPassword: Require a password at command execution Syracuse University

11. Trust Protocol for SABLE on TPM 2.0 SABLE’s post-DRTM behavior comprises two distinct execution phases: • Platform attestation • FDE key generation Syracuse University

12. Trust Protocol for SABLE on TPM 2.0 • Platform attestation • User enters a password , the authdata for a storage key . • SABLE executes TPM2_Load(), where is a sealed blob of SEC secrets, encrypted by . • SABLE executes TPM2_Unseal() over an encrypt session, where is a TPM2 enhanced authorization policy that allows to be extracted in plaintext only when PCR17 and PCR19 are correct for SABLE and the boot modules, respectively, and the TPM locality is correct. • If the operation succeeds, then two datum are returned: the plaintext passphrase, and entropy bits (32 bytes) representing the unique identity of this SEC. • SABLE extends PCR19 with a special value. This effectively locks for the remainder of this boot cycle. • The passphrase is displayed to the user. Syracuse University

13. Trust Protocol for SABLE on TPM 2.0 • FDE key generation • If the user recognizes the passphrase, he/she enters a countersign, , the authdata for a signing key owned by the user. • SABLE computeswhere • is a cryptographic hash algorithm • is the standard definition of HMAC, parameterized by a hash algorithm • is a public value generated during configuration time and included in an SEC's configuration file The KDF would generate a 512-bit key (the maximum size for LUKS) by repeating the HMAC 4096 times. Syracuse University

14. Configuration • Can use tpm2-tools to create the signing key and configure the SEC blob: $ tpm2_createprimary –-hierarchy=o –-pwdp=ownerpass \ --pwdk=keypass –-halg=sha256 –-kalg=rsa $ tpm2_evictcontrol –-auth=o --pwda=ownerpass –-persistent=0x04 $ tpm2_createpolicy [...] –-policy-file=policy.out $ tpm2_getrandom 32 > SEC.txt `# create SEC identity`$ echo “This is the passphrase!” >> SEC.txt $ tpm2_create –-parent=0x04 –-halg=sha256 –-kalg=keyedhash \ –I SEC.txt -u out.pub –r out.pri \ –-policy-file=policy.out • Could write our own tool on TSS2, or use an automation script Syracuse University

15. Configuration • The configuration tool should produce a key-value configuration file, which can be passed to SABLE as a module:key-handle=0x4512sec-policy=<policy digest>pcr17=…pcr19=…etc. • Thus will not require the user to reconfigure GRUB whenever the config is updated. • Will allow for more flexible policies later on Syracuse University

16. Discussion • No TPM2 NVRAM • NVRAM provides limited storage (~8KB) • Platform owner autorization is required to define NVRAM spaces. • By not requiring NVRAM, we allow each user to create as many SECs as he/she wants, without consulting the platform owner. • We can still “lock” sealed blobs by invalidating their required authorization policy after they have been successfully unsealed. Syracuse University

17. Discussion • Security considerations: • Because is never revealed in plaintext outside the TPM or SLB/MLE, it can never be seen by any user. Hence the FDE key should be impossible to derive outside of SABLE. • If an evil maid learns the passphrase, she can convince the user to boot into a different environment. • If an evil maid learns and , she can boot into the secure environment. Syracuse University

18. Project Timeline • Phase 1: “Hello World” (target March 9) [Tianyu] • Reorganize SABLE for TPM 2.0 • Update transport-layer TPM driver • Update software crypto algorithms for TPM 2.0, e.g. SHA256 • Issue a TPM2_Startup() to the TPM with a success result • Phase 2: Get SABLE Working (target April 18) • Implement TPM2_Extend, TPM2_Load, and TPM2_Unseal, with the most basic security (password only) [Tianyu] • Get SABLE to run start-to-finish and generate the FDE key [Tianyu] • Build the configuration tool [Jonathan] • Phase 3: Added Security (target May 9) • Add HMAC MiM protections [Tianyu] • Add access control policies [Tianyu] • Add an encrypt channel to the NVRAM read [Jonathan] Syracuse University

19. Future Work • Use compound policies to enable SEC groups • Multiple configurations (e.g. PCR values) can be covered by one passphrase, one SEC identity, and one sealing key. • This could make it easier for one user to keep track of many different SECs without having to remember all of the distinct passphrases, passwords, etc. • Use flexible policies to ease the process of updating boot components • Thus we wouldn’t require a new FDE key to be generated each time the system is updated • This feature is obviously for convenience, not added security Syracuse University

20. References • “A Practical Guide to TPM 2.0” Chapters 8-14, 17 • TCG TPM 2.0 Specification • SABLE TPM 2.0 Specification • PBKDF2 Syracuse University