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

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.
Auditing: Post-hoc inspection and punishment
Tamper-Proof logs form the basis of auditing


2
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
Desiderata
Detect tampering
Work in offline setting




Processing log entries without contacting central server
Continuity across power cycles
Performance



4
Good throughput
Should not consume lot of resources
Talk Outline
Adversary Model
Secure Logger




Protocol A
Protocol B
Formal Verification
Implementation
Related Work



5
Adversary Model
Adversary Model
Time T
Adversary not root
Adversary in control

Detect tampering of log entries consumed before T

Auditor is an external trusted entity
6
Secure Logger: Protocol A
Solution: Protocol A
Initial shared secret S between auditor and logger

S
H(S | “…”)
Log 1
Log 2
HMAC(K1, Log 1)
K1
HMAC(K2, Log 2)
K2
H(K1 | “…”)
H(K2 | “…”)
Log 3
7
HMAC(K3, Log 3)
K3
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
Seal key to 𝑥 + 1
and write blob
Shutdown
Startup
Unseal
blob
Increment
Counter
Increment
Counter
Time
𝑥
8
𝑥
𝑥+1
𝑥+2
Counter
Value
Secure Logger: Protocol A
Verification: Protocol A
Verifier
Logger
RAM
K4
Nonce
HMAC(K4, Nonce)
Disk
S
K1
Log 1
HMAC(K1, Log 1)
Log 2
HMAC(K2, Log 2)
K2
Log 3
HMAC(K3, Log 3)
K3
K4
9
Secure Logger: Protocol A
Informal Argument for Security

Attacker cannot learn keys used before T (old key)
Time T
Adversary not root

Before T, keys present only in



Adversary in control
Process memory of logger
Sealed blobs on disk
After T, old keys cannot be recovered
10
Secure Logger: Protocol A
Tampering Requires Old Keys

Tampering: Modification, deletion or truncation
Time T
Adversary not root
RAM
Adversary in control
K4
Nonce
11
Disk
Log 1
HMAC(K1, Log 1)
Log 2
HMAC(K2, Log 2)
Log 3
HMAC(K3, Log 3)
Talk Outline


Adversary Model
Secure Logger





Protocol A
Protocol B
Formal Verification
Implementation
Related Work
12
Secure Logger: Protocol B
Additional considerations




Ability to delete verified logs
Verify logs in parts
Performance-security tradeoff
Handling power failure
13
Secure Logger: Protocol B
Protocol B

Partition the log into logical epochs of N entries
H(S | “…”)
S
H(K1 | “…”)
K2
K1
H(K1 | “.…”)
K11
H(K11 | “.…”)
K12
14
H(K2 | “…”)
K3
Pre-compute
the next epoch key
Store the epoch
keys sealed to
monotonic counter
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

15
Write blocks of log entries
Secure Logger: Protocol B
Power failure

Log entries still in volatile memory will be lost
Written to disk
Adversary in
control
Power
Failure

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
16
Secure Logger:
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

17
Using resetCount and restartCount in 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
NV memory TPM

EOL marker never written to disk normally
EOL marker written to disk only on power failure

Adversary cannot generate valid EOL

18
Talk Outline


Adversary Model
Secure Logger





Protocol A
Protocol B
Formal Verification
Implementation
Related Work
19
Formal Verification
Model


Threads (programs) are run by principals: 𝑇


Message queue Q


Reduction:
20
Formal Verification
Language and Logic



Extension of an earlier framework (Garg et al.)
Timed logic: 𝜓 @ 𝑢
Judgment's about program expressions
After expression 𝑒 evaluates
holds
holds throughout evaluation of 𝑒 (invariant)

First order logic judgment
21
Formal Verification
Main Verification Result
Last log written
before min(𝑢𝑎 , 𝑢𝑟 )
Log entry 𝑘’ written
𝑢𝑤
𝑢𝑙
𝑢𝑎
Logs received
and verified
𝑢𝑟
The log entry 𝒌’ recv. by verifier is same as what was written at time 𝒖𝒘
22
Formal Verification
Formal Verification: Main Finding
Logger
starts
Seal key to 𝑥 + 1
and write blob
Shutdown
Startup
Unseal
blob
Increment
Counter
Increment
Counter
Time
Blob
not
read
𝑥
23
𝑥+1
𝑥+2
Counter
Value
Talk Outline


Adversary Model
Secure Logger





Protocol A
Protocol B
Formal Verification
Implementation
Related Work
24
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
25
Related Work
Related Work

Key chain approach


Efficient data structures for storing logs



Kelsey and Schenier – no continuity across power cycle
Crossby et al. 2009
Snodgrass et al. 2004
Formal methods



26
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 tamperproof 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
27
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


28
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
Calls with
keys
Network TPM
29
Hard
Disk
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


30
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
LogX
LogX

Treat this file as the log that needs to be tamper detectable
For verification


31
K1
K2
K3
Store in another file the mapping of key index to log number


LogY
LogY
LogX
Send the mapping file, and other information for verification
Send the requested log
Handling Power Failure
Handling power failure

Occasional checkpointing



When to checkpoint?


Extend hash of key into NVPCR occasionally
Indicate in the log also (for the verifier)
At least, whenever the log is written to disk (to be consistent with
NVPCR)
When should the log be written to disk?




32
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.
33