continuous tamper proof logging using tpm2 0
Download
Skip this Video
Download Presentation
Continuous Tamper-proof Logging using TPM2.0

Loading in 2 Seconds...

play fullscreen
1 / 33

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


  • 76 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Continuous Tamper-proof Logging using TPM2.0' - maia


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 ModelAdversary 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 ASolution: 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 ASaving 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 AVerification: 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 AInformal 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 ATampering 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 BAdditional considerations
  • Ability to delete verified logs
  • Verify logs in parts
  • Performance-security tradeoff
  • Handling power failure
protocol b
Secure Logger: Protocol BProtocol 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 BIssues 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 BPower 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 BImprovement 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 VerificationModel
  • Threads (programs) are run by principals:
  • Message queue Q
  • Reduction:
language and logic
Formal VerificationLanguage 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 VerificationMain 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 VerificationFormal 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
ImplementationPrototype 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 WorkRelated 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 ApproachHash 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
ImplementationImplementation 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
VulnerabilitiesKnown 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 LogsMultiple 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 FailureHandling 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 FailureHandling power failure contd.
  • Fix – TPM manufacturers can provide a fast/failure resistant NV memory. Cache with a capacitor.
ad