Skip to content
This repository was archived by the owner on Apr 27, 2022. It is now read-only.

TPM reading group

Jump to bottom
Jason Hennessey edited this page Aug 4, 2017 · 9 revisions

Starting in December, 2015, the joint NEU/BU TPM reading group will be meeting every other week to discuss Trusted Platforms Modules (TPMs), their role in system security and different ways they've been used.

For additional information, please contact Jason Hennessey at BU.

Sessions include:

  1. 12/02/2015 - @ BU, room PRB365. x86 is harmful: epub, pdf
  2. 12/09/2015 @ NEU, 366 West Village H.. Establishing and Sustaining System Integrity via Root of Trust Installation: pdf
  3. 12/16/2015 @ BU, room PRB365. Virtual machine verifier (pdf) (uses NetROTI)
  4. NetROTI (pdf)
  5. Cloud Verifier/Seeding Clouds with Trust Anchors (pdf)
  6. Flicker (pdf)
  • Uses AMD SVM (similar to Intel TXT) to do Dynamic Root of Trust to run apps in isolated enclaves
  1. Bootstrapping Trust in Commodity Computers (SoK, 2010) (pdf)

Other possible papers

  • PUFs: Physically uncloneable functions. Mayank can provide some references.

Notes

Notes taken from the reading groups go here.

x86 is harmful 12/02/2015

-Mapping of use cases to technologies meeting them. ie - laptop/mobile, server-based, physical trust, etc

What components can we trust? -Supply chain issues

-Trusted vs trustworthy - On x86, the SMM/SMT have to be trusted - things that help trusthworthyness are open sourcing, publicly publishing hashes

-CPU is trustworthy (only 1 fab that can do that), however other ICs on the motherboard not necessarily trustworthy.

-Use cases HaaS: manufacturer trusted. Other users not - High-security users want to verify supply chain somewhat - Able to verify hardware when context switching between users - There's a sliding-scale of trust: always trust users -> verify everything - Two portions: verifying hardware and protecting it

Checkpointing: - One model is that there's a golden image for an application to start from. Would like to secure it so that it can be verified.

-Need to divide the trust model into things we can trust, things we can't, and things we ignore. Example: processor has to be trusted, BMC running old linux kernels might need to be removed since they can't be trusted

-BIOS/CPUs and private key - Blog posts where people have dumped the bios ROM with bad practices (hard coded keys) - BIOS code is always available by taking apart updates - BIOS vendors not necessarily experts in security

  • Is there a layer of BIOS that we can trust that hardware was actually reflashed? If so, it might be sufficient to reflash the BIOS whenever context switching between users.
    • One mechanism might be "proof of flashedness", where BIOS only has a limited space and has to prove it has the correct code if it didn't have sufficient memory to cache the malicious version.
  • Orran will be speaking with Intel on Friday. If we could send thoughts on what we'd want, that would help with the conversation.

-For HD encryption, it's difficult to authenticate a machine to the user as opposed to the user to the machine.

-PUFs: physically unclonable function. Hardware devices that can be used for authentication

Clone this wiki locally