Continuous Tamper-proof Logging using TPM2.0

Continuous Tamper-proof Logging using TPM2.0 Arunesh Sinha1, Limin Jia1, Paul England2, Jacob R. Lorch2 1Carnegie Mellon University, 2Microsoft Research, Redmond

Motivation • Butler Lampson says • Auditing: Post-hoc inspection and punishment • Tamper-Proof logs form the basis of auditing Today computer security depends on access control, and it's been a failure. Real world security, by contrast, is mainly retroactive: the reason burglars don't break into my house is that they are afraid of going to jail, and the financial system is secure mainly because almost any transaction can be undone.

Common Scenario • A laptop used by an employee • IT wishes to enforce certain policies • Network policy, no copying sensitive data to USB device • Perfect real time prevention is difficult • Real time prevention could have significant overhead • Auditing: Prevention through deterrence • Of course, logs must not be tampered

Desiderata • Detect tampering • Work in offline setting • Processing log entries without contacting central server • Continuity across power cycles • Performance • Good throughput • Should not consume lot of resources

Talk Outline • Adversary Model • Secure Logger • Protocol A • Protocol B • Formal Verification • Implementation • Related Work

Adversary Model Adversary Model Time T • Detect tampering of log entries consumed before T • Auditor is an external trusted entity Adversary not root Adversary in control

Secure Logger: Protocol A Solution: Protocol A • Initial shared secret S between auditor and logger S H(S | “…”) K1 Log 1 HMAC(K1, Log 1) H(K1 | “…”) K2 HMAC(K2, Log 2) Log 2 H(K2 | “…”) K3 Log 3 HMAC(K3, Log 3)

Secure Logger: Protocol A Saving keys at shutdown • TPM2.0 provides a NV monotonic counter • Data can be sealed to the counter value Logger starts Unseal blob Seal key to and write blob Increment Counter Increment Counter Shutdown Startup Time Counter Value

Secure Logger: Protocol A Verification: Protocol A Verifier Logger RAM K4 Nonce Nonce HMAC(K4, Nonce) HMAC(K4, Nonce) S Disk K1 Log 1 Log 1 HMAC(K1, Log 1) HMAC(K1, Log 1) K2 HMAC(K2, Log 2) HMAC(K2, Log 2) Log 2 Log 2 Log 3 Log 3 HMAC(K3, Log 3) HMAC(K3, Log 3) K3 K4

Secure Logger: Protocol A Informal Argument for Security Time T • Attacker cannot learn keys used before T (old key) • Before T, keys present only in • Process memory of logger • Sealed blobs on disk • After T, old keys cannot be recovered Adversary not root Adversary in control

Secure Logger: Protocol A Tampering Requires Old Keys Time T • Tampering: Modification, deletion or truncation Adversary not root Adversary in control Disk RAM K4 Log 1 Log 1 HMAC(K1, Log 1) HMAC(K1, Log 1) Nonce HMAC(K2, Log 2) HMAC(K2, Log 2) Log 2 Log 2 Log 3 Log 3 HMAC(K3, Log 3) HMAC(K3, Log 3) 11

Secure Logger: Protocol B Additional considerations • Ability to delete verified logs • Verify logs in parts • Performance-security tradeoff • Handling power failure

Secure Logger: Protocol B Protocol B • Partition the log into logical epochs of N entries H(S | “…”) H(K1 | “…”) H(K2 | “…”) Pre-compute the next epoch key K2 S K1 K3 H(K1 | “.…”) K11 Store the epoch keys sealed to monotonic counter H(K11 | “.…”) K12

Secure Logger: Protocol B Issues addressed in Protocol B • Ability to delete verified logs • Verify logs in parts • Verifier can verify the epochs independently • Performance-security tradeoff • Write blocks of log entries

Secure Logger: Protocol B Power failure • Log entries still in volatile memory will be lost • Advantage over Protocol A • On Startup, logging can proceed from next epoch • A power failure does not stall logging • Malicious power failure leads to attack Adversary in control Written to disk Power Failure

Secure Logger Secure Logger: Protocol B Suggested Hardware Feature • Fast memory interface for NV memory of TPM • Assured write to TPM’s NV memory on power failure • Already exists: the ability to determine if power failed • Using resetCountand restartCountin TPM

Secure Logger: Protocol B Improvement to Protocol B • Buffer in NV memory of TPM instead of RAM • Maintain an end of log (EOL) marker in buffer • HMAC of known string with current key • EOL marker never written to disk normally • EOL marker written to disk only on power failure • Adversary cannot generate valid EOL NV memory TPM

Formal Verification Model • Threads (programs) are run by principals: • Message queue Q • Reduction:

Formal Verification Language and Logic • Extension of an earlier framework (Garg et al.) • Timed logic: • Judgment's about program expressions • First order logic judgment After expression evaluates holds holds throughout evaluation of (invariant)

Formal Verification Main Verification Result Last log written before Logs received and verified Log entry written The log entry recv. by verifier is same as what was written at time

Formal Verification Formal Verification: Main Finding Logger starts Unseal blob Seal key to and write blob Increment Counter Increment Counter Shutdown Startup Time Blob not read Counter Value

Implementation Prototype Implementation • Logger as a windows service • Used TPM simulator developed by MSR • Used C# TPM library developed by MSR • Could process 100,000 log entries in 5.13 secs • 512 byte block size, disk time 2.5 secs • Each log entry on average 140 bytes

Related Work Related Work • Key chain approach • Kelsey and Schenier – no continuity across power cycle • Efficient data structures for storing logs • Crossby et al. 2009 • Snodgrass et al. 2004 • Formal methods • Bellare et al. 1997 – Forward integrity, no language/logic • Ma et al. 2007 – cryptographic style security of hash chain, no language/logic • Crossby et al. 2009 – model log integrity requiring online commitment

Conclusion • A scheme addressing practical problems of tamper-proof audits • Works across power cycles, in offline setting • Support truncation of logs • Support verification of arbitrary subset of the logs • Software-based hashing for performance • Handles power failures • Leveraged novel TPM 2.0 features • Formally verified tamper-proof property • Implemented a prototype

Alternate Approach Hash Chain of logs • A simple hash chain of log • Will work with the initial secret (with hashchain in memory and protected like the keys) • Keys approach vs. Hashchain approach • Keys approaches allows for parallel verification • Keys approach can also yield keys that can encrypt log entries

Implementation Implementation issues • TPM library is in C# • The solution requires secure erasing of memory • Not possible with “moving” GC in high level languages ETW C# TPM Library Unmanaged DLL Hard Disk Calls with keys Network TPM

Vulnerabilities Known Issues • How to know when the adversary turns malicious? • Implicit assumption that this event is logged • Usual suspects: loading applications, logons, etc. • Time of generation to time of consumption • ETW logging happens asynchronously • Adversary can take over the system before his malicious presence is recorded

Multiple Logs Multiple logs • Do not want to use multiple counters • Each log should be verifiable independently • Start with a central controller producing keys • As log entries arrive assign a key to them • Store in another file the mapping of key index to log number • Treat this file as the log that needs to be tamper detectable • For verification • Send the mapping file, and other information for verification • Send the requested log LogY LogX LogX LogX LogY LogX K1 K2 K3

Handling Power Failure Handling power failure • Occasional checkpointing • Extend hash of key into NVPCR occasionally • Indicate in the log also (for the verifier) • When to checkpoint? • At least, whenever the log is written to disk (to be consistent with NVPCR) • When should the log be written to disk? • Flush when memory buffer is full/ every 50 log entries • At shutdown • On verification • Important security events?

Handling Power Failure Handling power failure contd. • Fix – TPM manufacturers can provide a fast/failure resistant NV memory. Cache with a capacitor.

Continuous Tamper-proof Logging using TPM2.0