Download - 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
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.
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
4
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
5
Talk Outline Adversary Model Secure Logger
Protocol A Protocol B
Formal Verification Implementation Related Work
6
Adversary Model
Detect tampering of log entries consumed before T
Auditor is an external trusted entity
Time TAdversary in controlAdversary not root
Adversary Model
7
Solution: Protocol A Initial shared secret S between auditor and
logger
S
K1
K2
K3
H(S | “…”)
H(K1 | “…”)
H(K2 | “…”)
Log 1
Log 2
Log 3
HMAC(K1, Log 1)
HMAC(K2, Log 2)
HMAC(K3, Log 3)
Secure Logger: Protocol A
8
Saving keys at shutdown TPM2.0 provides a NV monotonic counter Data can be sealed to the counter value
Secure Logger: Protocol A
Shutdown
Seal key to and write blob
Time
CounterValue
StartupIncrementCounter
IncrementCounter
Unsealblob
𝑥 𝑥+1 𝑥+2
Loggerstarts
𝑥
9
Verification: Protocol ASecure Logger: Protocol A
Log 1Log 2Log 3
HMAC(K1, Log 1)HMAC(K2, Log 2)HMAC(K3, Log 3)
K4
Disk
RAMLogger Verifier
NonceHMAC(K4, Nonce)
Log 1Log 2Log 3
HMAC(K1, Log 1)HMAC(K2, Log 2)HMAC(K3, Log 3)
S
K1
K2
K3
K4
HMAC(K4, Nonce)
Nonce
10
Informal Argument for Security 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 TAdversary in controlAdversary not root
11
Tampering Requires Old Keys
11
Log 1Log 2Log 3
HMAC(K1, Log 1)HMAC(K2, Log 2)HMAC(K3, Log 3)
K4DiskRAM
Log 1Log 2Log 3
HMAC(K1, Log 1)HMAC(K2, Log 2)HMAC(K3, Log 3)
Nonce
Time TAdversary 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
13
Additional considerations Ability to delete verified logs Verify logs in parts Performance-security tradeoff Handling power failure
Secure Logger: Protocol B
14
Protocol B Partition the log into logical epochs of N
entries
S K1 K2 K3
H(S | “…”) H(K1 | “…”) H(K2 | “…”)
K11
K12
H(K11 | “.…”)
H(K1 | “.…”)Pre-compute
the next epoch key
Store the epoch keys sealed to
monotonic counter
Secure Logger: Protocol B
15
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
16
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
Secure Logger: Protocol B
Written to diskAdversary in
controlPowerFailure
17
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 resetCount and restartCount in TPM
Secure LoggerSecure Logger: Protocol B
18
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
Secure Logger: Protocol B
NV memory TPM
19
Talk Outline Adversary Model Secure Logger
Protocol A Protocol B
Formal Verification Implementation Related Work
20
Model Threads (programs) are run by principals:
Message queue Q
Reduction:
Formal Verification
21
Language and LogicFormal Verification
After expression evaluates holds holds throughout evaluation of (invariant)
Extension of an earlier framework (Garg et al.) Timed logic: Judgment's about program expressions
First order logic judgment
22
Main Verification ResultFormal Verification
𝑢𝑎 𝑢𝑟𝑢𝑙𝑢𝑤
Logs receivedand verified
Last log writtenbefore
Log entry written
The log entry recv. by verifier is same as what was written at time
23
Formal Verification: Main FindingFormal Verification
Shutdown
Seal key to and write blob
Time
CounterValue
StartupIncrementCounter
IncrementCounter
Unsealblob
𝑥 𝑥+1 𝑥+2
Loggerstarts
Blobnot read
24
Talk Outline Adversary Model Secure Logger
Protocol A Protocol B
Formal Verification Implementation Related Work
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
26
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
Related Work
27
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
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
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 withkeys
ETW
HardDisk
Implementation
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
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
LogYK1
K2K3
LogX LogYLogX
LogX
LogX
Multiple Logs
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
33
Handling power failure contd. Fix – TPM manufacturers can provide a
fast/failure resistant NV memory. Cache with a capacitor.
Handling Power Failure