Continuous tamper proof logging using tpm2 0
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

Continuous Tamper-proof Logging using TPM2.0 PowerPoint PPT Presentation


  • 55 Views
  • Uploaded on
  • Presentation posted in: General

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. Motivation. Butler Lampson says Auditing: Post-hoc inspection and punishment

Download Presentation

Continuous Tamper-proof Logging using TPM2.0

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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

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

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

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

Talk Outline

  • Adversary Model

  • Secure Logger

    • Protocol A

    • Protocol B

  • Formal Verification

  • Implementation

  • Related Work


Adversary model

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


Solution protocol a

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)


Saving keys at shutdown

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


Verification protocol a

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


Informal argument for security

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


Tampering requires old keys

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


Talk outline1

Talk Outline

  • Adversary Model

  • Secure Logger

    • Protocol A

    • Protocol B

  • Formal Verification

  • Implementation

  • Related Work


Additional considerations

Secure Logger: Protocol B

Additional considerations

  • Ability to delete verified logs

  • Verify logs in parts

  • Performance-security tradeoff

  • Handling power failure


Protocol b

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


Issues addressed in protocol b

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


Power failure

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


Suggested hardware feature

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


Improvement to protocol b

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


Talk outline2

Talk Outline

  • Adversary Model

  • Secure Logger

    • Protocol A

    • Protocol B

  • Formal Verification

  • Implementation

  • Related Work


Model

Formal Verification

Model

  • Threads (programs) are run by principals:

  • Message queue Q

  • Reduction:


Language and logic

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)


Main v erification r esult

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 main finding

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


Talk outline3

Talk Outline

  • Adversary Model

  • Secure Logger

    • Protocol A

    • Protocol B

  • Formal Verification

  • Implementation

  • Related Work


Prototype implementation

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

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

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


Hash chain of logs

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 issues

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


Known issues

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

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

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 contd

Handling Power Failure

Handling power failure contd.

  • Fix – TPM manufacturers can provide a fast/failure resistant NV memory. Cache with a capacitor.


  • Login