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


Shutdown

Seal key to and write blob

Time

CounterValue

StartupIncrementCounter

IncrementCounter

Unsealblob

𝑥 𝑥+1 𝑥+2

Loggerstarts

𝑥

9

Verification: Protocol A


Log 1

Log 2

Log 3

HMAC(K1, Log 1)

HMAC(K2, Log 2)

HMAC(K3, Log 3)

K4

Disk

RAM

Logger Verifier

NonceHMAC(K4, Nonce)

Log 1

Log 2

Log 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



11

Tampering Requires Old Keys

11

Log 1

Log 2

Log 3

HMAC(K1, Log 1)

HMAC(K2, Log 2)

HMAC(K3, Log 3)

K4

DiskRAM

Log 1

Log 2

Log 3

HMAC(K1, Log 1)

HMAC(K2, Log 2)

HMAC(K3, Log 3)

Nonce


Tampering: Modification, deletion or truncation


12




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-computethe next epoch key

Store the epoch keys sealed to

monotonic counter


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


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


Written to diskAdversary in

control

PowerFailure

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


NV memory TPM

19




20

Model Threads (programs) are run by principals:

Message queue Q

Reduction:

Formal Verification

21

Language and Logic

Formal 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 Result

Formal 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 Finding

Formal Verification

Shutdown

Seal key to and write blob

Time

CounterValue

StartupIncrementCounter

IncrementCounter

Unsealblob

𝑥 𝑥+1 𝑥+2

Loggerstarts

Blobnot read

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

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

Continuous Tamper-proof Logging using TPM2.0

Documents

Transcript of Continuous Tamper-proof Logging using TPM2.0