Presentation is loading. Please wait.

Presentation is loading. Please wait.

Continuous Tamper-proof Logging using TPM2.0 Arunesh Sinha 1, Limin Jia 1, Paul England 2, Jacob R. Lorch 2 1 Carnegie Mellon University, 2 Microsoft Research,

Similar presentations


Presentation on theme: "Continuous Tamper-proof Logging using TPM2.0 Arunesh Sinha 1, Limin Jia 1, Paul England 2, Jacob R. Lorch 2 1 Carnegie Mellon University, 2 Microsoft Research,"— Presentation transcript:

1 Continuous Tamper-proof Logging using TPM2.0 Arunesh Sinha 1, Limin Jia 1, Paul England 2, Jacob R. Lorch 2 1 Carnegie Mellon University, 2 Microsoft Research, Redmond

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

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

4 Desiderata 4  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

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

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

7 Solution: Protocol A  Initial shared secret S between auditor and logger S K1K1 K2K2 K3K3 H(S | “…”) H(K 1 | “…”) H(K 2 | “…”) Log 1 Log 2 Log 3 HMAC(K 1, Log 1) HMAC(K 2, Log 2) HMAC(K 3, Log 3) 7 Secure Logger: Protocol A

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

9 Verification: Protocol A 9 Secure Logger: Protocol A Log 1 Log 2 Log 3 HMAC(K 1, Log 1) HMAC(K 2, Log 2) HMAC(K 3, Log 3) K4K4 Disk RAM Logger Verifier Nonce HMAC(K 4, Nonce) Log 1 Log 2 Log 3 HMAC(K 1, Log 1) HMAC(K 2, Log 2) HMAC(K 3, Log 3) S K1K1 K2K2 K3K3 K4K4 HMAC(K 4, Nonce) Nonce

10 Informal Argument for Security 10  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 Secure Logger: Protocol A Time T Adversary in controlAdversary not root

11 Tampering Requires Old Keys 11 Log 1 Log 2 Log 3 HMAC(K 1, Log 1) HMAC(K 2, Log 2) HMAC(K 3, Log 3) K4K4 Disk RAM Log 1 Log 2 Log 3 HMAC(K 1, Log 1) HMAC(K 2, Log 2) HMAC(K 3, Log 3) Nonce Time T Adversary in controlAdversary not root  Tampering: Modification, deletion or truncation Secure Logger: Protocol A

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

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

14 Protocol B  Partition the log into logical epochs of N entries SK1K1 K2K2 K3K3 H(S | “…”)H(K 1 | “…”)H(K 2 | “…”) K 11 K 12 H(K 11 | “.…”) H(K 1 | “.…”) Pre-compute the next epoch key Store the epoch keys sealed to monotonic counter 14 Secure Logger: Protocol B

15 Issues addressed in Protocol B 15  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

16 Power failure 16  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 Secure Logger: Protocol B Written to disk Adversary in control Power Failure

17 Suggested Hardware Feature 17  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 resetCount and restartCount in TPM Secure LoggerSecure Logger: Protocol B

18 Improvement to Protocol B 18  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 Secure Logger: Protocol B NV memory TPM

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

20 Model 20 Formal Verification

21 Language and Logic 21 Formal Verification

22 Main Verification Result 22 Formal Verification Logs received and verified

23 Formal Verification: Main Finding 23 Formal Verification Shutdown Time Counter Value Startup Increment Counter Increment Counter Unseal blob Logger starts Blob not read

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

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

26 Related Work 26  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 Related Work

27 Conclusion 27  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

28 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 Alternate Approach 28

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

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

31 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 K1 K2 K3 LogX LogY LogX Multiple Logs 31

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

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


Download ppt "Continuous Tamper-proof Logging using TPM2.0 Arunesh Sinha 1, Limin Jia 1, Paul England 2, Jacob R. Lorch 2 1 Carnegie Mellon University, 2 Microsoft Research,"

Similar presentations


Ads by Google