masterthesis/references/IntroToTrustedComputing_full_10-24-2012/tpm101.tex

\documentclass{beamer}
\usepackage{graphicx}
\usepackage{color}
\usetheme{Madrid}

\title[TPM 101]{Introduction to Trusted Computing: TPM 101}
\author{Ariel Segall \\ ariels@alum.mit.edu}
%\institute{\copyright MITRE Corporation 2012}
\date{Day 1\\ \bigskip Approved for Public Release: 12-2749. \\Distribution unlimited}
%\date{May 30, 2012}

\begin{document}

\begin{frame}
\maketitle
\end{frame}


\begin{frame}{License}

All materials are licensed under a Creative Commons ``Share Alike'' license.
\begin{itemize}
\item http://creativecommons.org/licenses/by-sa/3.0
\end{itemize}
\includegraphics[width=4in]{creativecommons.png}
\end{frame}

\begin{frame}{What We'll Be Covering}
 
In this section:
\begin{itemize}
\item What is a TPM? What does it do?
\item What's it good for?
\item Some TPM myths (and the truths behind them)
\item Why enterprises should care about TPMs
\end{itemize}

All at a high level-- deep dive this afternoon.
\end{frame}

\begin{frame}{What is a TPM?}

\begin{itemize}
\item Trusted Platform Module
\item Inexpensive ($<$\$1, usually) chip on almost all motherboards today
\begin{itemize}
\item Not in Macs
\item Only some servers have them-- ask.
\end{itemize}
\item Hardware basis for platform trust
\begin{itemize}
\item In secrets
\item In platform state
\begin{itemize}
\item Combined with a \textit{Root of Trust for Measurement}\footnote{We'll get to these in a little while}
\end{itemize}
\item In platform identity
\end{itemize}
%\item Provides hardware protection for secrets
%\item (Very) limited cryptographic coprocessor
\item Current version is 1.2
\begin{itemize}
\item Unless otherwise specified, we'll always refer to 1.2 TPMs
\item Previous version 1.1; next, 2.0.
\end{itemize}
\end{itemize}

\end{frame}

%% What is a TPM?

%% Pretty picture of internals

\begin{frame}{What's In a TPM?}

\includegraphics[width=4in]{tpm-drawing}

\end{frame}

\begin{frame}{What TPMs Provide}

\begin{itemize}
\item A \textit{Root of Trust for Reporting}
\item A \textit{Root of Trust for Storage}
\item Limited internal storage
\begin{itemize}
\item \textit{Platform Configuration Registers}
\item Key storage
\item Data storage
\end{itemize}
\item Random number generation
\item Highly constrained cryptographic functions
\begin{itemize}
\item Feature, not bug (mostly)
\end{itemize}
\end{itemize}


\end{frame}

 \begin{frame}{Roots of Trust}

We keep hitting this phrase: \textit{Root of Trust}. What does it mean?

\begin{itemize}
\item The thing you base all other trust on
\item Trusted inherently: no way to verify it directly
\begin{itemize}
\item This is why standards are useful!
\item Out-of-band verification is your only option
\item Trust the chip because the manufacturer says it meets spec
\item Keep in mind the supply chain!
\begin{itemize}
\item There are not currently any trusted foundries producing TPMs.
\end{itemize}
\end{itemize}
\item No such thing as \textit{generic} trust. Trust always has an associated verb!
\begin{itemize}
\item I trust my electrician to repair wires, not update my bank account
\item I trust a TPM to protect my data, not to verify my antivirus
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{The Root of Trust for Reporting}

Core question: ``Is this system in a good state?''

\medskip

Breaks down into two parts:
\begin{itemize}
\item What looked at the system state? \textit{Root of Trust for Measurement}
\item What told us the results? \textit{Root of Trust for Reporting}
\end{itemize}

\medskip

\begin{center}
The TPM is a Root of Trust for Reporting (RTR); \\it is
\textit{\textbf{not}} a Root of Trust for Measurement (RTM).
\end{center}
\end{frame}

\begin{frame}{The Root of Trust for Storage}

Core question: ``Are my secrets kept secret?''

\medskip

\begin{itemize}
\item The TPM is a Root of Trust for Storage (RTS)
\item Does \textit{\textbf{not}} store \textit{all} secrets directly
\item Stores one secret used to protect other secrets that may be outside
\item Hence, \textit{Root} of Trust.
\end{itemize}

\end{frame}


\begin{frame}{What TPMs Provide}

\begin{itemize}
\item A \textit{Root of Trust for Reporting}
\item A \textit{Root of Trust for Storage}
\item Limited internal storage
\begin{itemize}
\item {\color{red}\textit{Platform Configuration Registers}}
\item Key storage
\item Data storage
\end{itemize}
\item Random number generation
\item Highly constrained cryptographic functions
\begin{itemize}
\item Feature, not bug (mostly)
\end{itemize}
\end{itemize}


\end{frame}



\begin{frame}{Platform Configuration Registers}

The TPM has three kinds of internal storage. The one we'll talk about most are Platform Configuration Registers, or \textit{PCRs}.

\begin{itemize}
\item Series of 20-byte registers (length of a SHA-1 hash)
\item Most modern TPMs have 24; older ones have 16
\item Used to store system measurements
\begin{itemize}
\item Although they can be more flexible than that!
\end{itemize}
\item Highly constrained behavior
\begin{itemize}
\item Always reset to a known value at boot
\item Only store data using an \textit{Extend} operation
\item \textbf{Extend: hash new data with current contents}
\item Permissions based on \textit{locality}; similar to OS rings
\begin{itemize}
\item Can never be freely overwritten
\item Verifier can determine every value extended in
\item Easy to check; computationally infeasible to forge
\end{itemize}
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{The Roots of Trust for Measurement}

Core question the TPM can't meet: ``What is the state of the system?''

\begin{itemize}
\item TPM has no visibility outside itself!
\item RTM must be capable of inspecting system.
\item Two current RTM options:
\begin{itemize}
\item BIOS (technically, BIOS boot block)
\begin{itemize}
\item Also known as the \textit{Static Root of Trust for Measurement} or SRTM
\end{itemize}
\item Special CPU code operating in trusted mode
\begin{itemize}
\item \textit{Dynamic Root of Trust for Measurement}, or DRTM
\item Intel: Trusted Execution Technology (TXT)
\item AMD: Secure Virtual Machine (SVM)
\end{itemize}
\end{itemize}
\item Place initial measurements into PCRs before handing off control
\end{itemize}


\end{frame}

\begin{frame}{Reporting PCR Measurements}
\begin{center}
\includegraphics[width=4in]{pcr-illustration}
\end{center}
We have system measurements in our PCRs; how do we use them?

\begin{itemize}
\item Can be read directly, but not trustworthy!
\begin{itemize}
\item If unsigned, just report from software about software
\end{itemize}
\item Instead, request a \textbf{Quote}:
\begin{itemize}
\item Signed report from TPM 
\item Contains hash of current PCR values
\item Uses nonce (created by requestor) to prove freshness
\end{itemize}
\item Quotes can be provided to other parties for PCR verification
\begin{itemize}
\item Trustworthy, remote state reporting!
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Other Uses of PCRs}

We can also use the TPM's PCRs in other ways.

\medskip

\begin{itemize}
\item Encrypted data can be \textit{sealed} or \textit{bound} to a set
  of PCR values
\begin{itemize}
\item Decryptable only when current values match target
\end{itemize}
\item Keys can be constrained to a set of PCR values
\begin{itemize}
\item Key only usable when values match
\end{itemize}
\item Non-measurement data can be stored in PCRs
\begin{itemize}
\item We'll get to use cases for this later.
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{What TPMs Provide}

\begin{itemize}
\item A \textit{Root of Trust for Reporting}
\item A \textit{Root of Trust for Storage}
\item Limited internal storage
\begin{itemize}
\item \textit{Platform Configuration Registers}
\item {\color{red}Key storage}
\item {\color{red}Data storage}
\end{itemize}
\item Random number generation
\item Highly constrained cryptographic functions
\begin{itemize}
\item Feature, not bug (mostly)
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{TPM Root Keys}

There are only two keys that never leave the TPM:

\medskip

\begin{itemize}
\item \textbf{Endorsement Key (EK)}: The key that the TPM uses in its role as Root of Trust for Reporting. 
\begin{itemize}
\item Only used directly to certify Identity Keys (AIKs), which we'll get to soon.
\item Critical: trust in all keys in the system come down to trust in EK
\end{itemize}
\item \textbf{Storage Root Key (SRK)}: The key that the TPM uses in its role as Root of Trust for Storage.
\begin{itemize}
\item Used to protect other keys and data via encryption
\item Can protect other storage keys: heirarchy of protection
\end{itemize}
\end{itemize}

All other keys created by the TPM have their private halves encrypted
by the SRK (or another storage key), and are stored outside the TPM.

\end{frame}


\begin{frame}{Non-Root Keys (1/2)}

All TPM keys are RSA keys, but have specialized roles:
\begin{itemize}
\item Encryption/Decryption: Storage, Binding
\item Signing/Reporting: Identity, Signing
\begin{itemize}
\item Identity keys better known as \textit{Attestation Identity Keys}, or \textit{AIKs}
\end{itemize}
\item Legacy keys can be used for either, but are not created by the TPM
\begin{itemize}
\item TPMs can import keys; less secure, but sometimes useful
\end{itemize}
\end{itemize}

\medskip

We'll cover the details of when to use which later today.

\end{frame}

\begin{frame}{Non-Root Keys (2/2)}


\begin{itemize}
\item Keys are stored in ``blobs''\footnote{Yes, that's the technical
  term} on disk (outside TPM)
\item Private key encrypted; integrity protection on other data
\item Only decryptable by TPM that created it, unless explicitly created otherwise
\begin{itemize}
\item Local-only keys are \textit{non-migratable}
\item Keys that can be exported off of the machine are \textit{migratable}
\end{itemize}
\item Loaded back into the TPM for use
\item Remain in the TPM while space allows, or until reboot
\begin{itemize}
\item TPMs have limited amount of internal space for keys!
\item Owner\footnote{We'll get to owners shortly} can set a particular
  key to remain in the TPM
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Data Storage}

\begin{itemize}
\item TPMs have a limited amount of non-volatile storage (\textit{NVRAM})
\begin{itemize}
\item Non-volatile because (unlike most TPM data) remains between boots
\end{itemize}
\item Access can be controlled (read and write separately)
\begin{itemize}
\item Owner
\item PCR values
\item Authorization value (password)
\end{itemize}
\item Part of NVRAM set aside for certificate storage
\begin{itemize}
\item Manufacturer may supply credentials for TPM
\begin{itemize}
\item ...but they probably didn't.
\end{itemize}
\end{itemize}
\end{itemize}


\end{frame}


%% What TPMs are capable of at a high level
%% RTR, RTS

%% Reporting: what does that mean?

%% Reporting: How does it work?

%% Storage: what does that mean?

%% Storage: how does it work?



%% Two categories of keys: those that are *never* in the clear outside the TPM, and those that can be moved around.

%% Other features at a high level?

\begin{frame}{What They Provide}

\begin{itemize}
\item A \textit{Root of Trust for Reporting}
\item A \textit{Root of Trust for Storage}
\item Limited internal storage
\begin{itemize}
\item \textit{Platform Configuration Registers}
\item Key storage
\item Data storage
\end{itemize}
\item {\color{red}Random number generation}
\item {\color{red}Highly constrained cryptographic functions}
\begin{itemize}
\item Feature, not bug (mostly)
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{Random Number Generator}

\begin{itemize}
\item TPMs required to have internal random number generator
\item Spec strongly encourages but does not require hardware entropy source
\begin{itemize}
\item Quality of entropy not defined in spec!
\item Suitable for most day-to-day purposes, but may not meet high security requirements
\item Externally generated entropy can be added into the TPM RNG 
\end{itemize}
\item RNG used to generate all TPM keys and nonces
\item Can also provide random bits directly to user on request 
\end{itemize}

\end{frame}

\begin{frame}{Cryptographic Functions}

The TPM provides several specialized cryptographic functions:
\begin{itemize}
\item Encryption/Decryption
\begin{itemize}
\item Seal/Unseal: Encrypt/decrypt data for local TPM
\item Unbind: Decrypt data from anywhere (no TPM required to encrypt)
\end{itemize}
\item Sign
\begin{itemize}
\item Constrained data formats: SHA-1, DER, custom TPM structure
\item NOTE: attack exists on custom TPM structure; do not use.
\end{itemize}
\item Key certification
\begin{itemize}
\item TPM can certify any key it creates
\item Custom format; includes all key properties
\end{itemize}
\item SHA-1 hash generation
\end{itemize}

\medskip

Why so specialized? Two reasons:
\begin{itemize}
\item Prevent attacks resulting from key misuse
\item Make it possible to verify constraints
\end{itemize}

\end{frame}

\begin{frame}{Other TPM Functions}

\begin{itemize}
\item Monotonic Counter
\begin{itemize}
\item Always increases; good for rollback prevention
\end{itemize}
\item Tick Counter
\begin{itemize}
\item Not quite a clock, but useful for timing
\end{itemize}
\item Direct Anonymous Attestation (DAA)
\begin{itemize}
\item Zero-knowledge proof of identity
\item Extremely complicated!
\item Added to address privacy concerns
\end{itemize}
\end{itemize}

\medskip

These will not be covered in detail in this class.

\end{frame}



%%% TODO: OWNERSHIP!!!!

\begin{frame}{TPM Functionality: Quick Review}

\begin{itemize}
\item A \textit{Root of Trust for Reporting}
\item A \textit{Root of Trust for Storage}
\item Limited internal storage
\begin{itemize}
\item \textit{Platform Configuration Registers}
\item Key storage
\item Data storage
\end{itemize}
\item Random number generation
\item Highly constrained cryptographic functions
\begin{itemize}
\item State reporting
\item Data protection
\item Cryptographic utilities (e.g., signing)
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{Ownership: Whose TPM Is It Anyway?}

%Who can use a TPM? Who can configure it?

%\medskip

\begin{itemize}
\item The TPM has a single \textit{owner}. 
\begin{itemize}
\item Usually the machine owner (IT dept in corporate setting)
\end{itemize}
\item Someone must take ownership for the TPM to be used!
\item Anyone with physical presence can take ownership
\item SRK is created when ownership is taken; if replaced, old key erased
\item Owner has admin privileges; e.g. can change TPM configuration settings
\item Owner has exclusive right to create TPM identities
\begin{itemize}
\item Users can freely create other keys unless SRK requires authorization
\end{itemize}
\item Owner does \textbf{NOT} automatically get access to resources
\begin{itemize}
\item TPM ownership is not like root or administrator access in OS
\end{itemize}
\end{itemize}


\end{frame}


\begin{frame}{What We'll Be Covering}
 
In this section:
\begin{itemize}
\item What is a TPM? What does it do?
\item {\color{red} What's it good for?}
\item Some TPM myths (and the truths behind them)
\item Why enterprises should care about TPMs
\end{itemize}

All at a high level-- deep dive this afternoon.
\end{frame}

%% What's it good for at a high level

\begin{frame}{What's it good for?}

The TPM's big benefits:

\begin{itemize}
\item Machine Authentication
\item Attestation
\item Data Protection
\end{itemize}

\end{frame}

 \begin{frame}{Machine Authentication}

\begin{itemize}
\item We can use TPM keys to reliably identify a machine!
\begin{itemize}
\item TPM soldered to motherboard
\item Keys cryptographically bound to a particular TPM
\end{itemize}
\item Signing-based authentication
\begin{itemize}
\item This data passed through machine X
\item (Note: Can't prove origination with just a signature)
\end{itemize}
\item Decryption-based authentication
\begin{itemize}
\item Only machine X can read this data
\end{itemize}
\item One of the simplest TPM applications
\end{itemize}


\end{frame}

\begin{frame}{Attestation}

\begin{center}
\textit{\textbf{Attestation}: the presentation of verifiable evidence about machine state to a remote party} 
\end{center}

\begin{itemize}
\item Quotes are all about attestation!
\begin{itemize}
\item Signed report of current PCR contents
\item Many PCR constraints (e.g. keys) can be used for attestation also
\end{itemize}
\item Remote verifier can check boot state of machine
\item Potentially very powerful!
\begin{itemize}
\item Is this machine running the right image?
\item Is the software trustworthy?
\end{itemize}
\item Easier said than done:
\begin{itemize}
\item Interpreting PCR values is \textbf{hard}
\item Work to regularize them is ongoing
\item Values are very fragile and hard to predict!
\end{itemize}
\end{itemize}



\end{frame}

\begin{frame}{Data Protection}

\begin{itemize}
\item TPM is \textbf{not} suitable for bulk data encryption
\begin{itemize}
\item Too slow! Public key encryption only, cheap processor
\item No fast symmetric ciphers due to export regulations
\end{itemize}
\item Use to encrypt small, high-value data; for example:
\begin{itemize}
\item Software-held private keys (e.g. user identities)
\item Symmetric keys usable for bulk encryption
\item Password stores
\end{itemize}
\item Can be used for hard drive encryption if supported
\begin{itemize}
\item TPM-sealed symmetric key encrypts drive
\item Bitlocker option!
\end{itemize}
\item Provide hardware protection, tamper resistance to sensitive data
\end{itemize}
\end{frame}

\begin{frame}{What We'll Be Covering}
 
In this section:
\begin{itemize}\item What is a TPM? What does it do?
\item What's it good for?
\item {\color{red} Some TPM myths (and the truths behind them)}
\item Why enterprises should care about TPMs
\end{itemize}

All at a high level-- deep dive this afternoon.
\end{frame}

%% Debunking TPM Myths

 \begin{frame}{TPM Myths}

There are many common \textbf{misconceptions} about the TPM.

\begin{itemize}
\item Some are misunderstandings based on early marketing materials
%\item Some are misinformation spread by certain privacy activists
\item Most are the result of simplified summaries of a very complicated topic
\end{itemize}

We'll debunk a few of the most common, and talk about the truths
behind the myths.

\end{frame}

\begin{frame}{Myth: The TPM Controls Boot}

\textbf{It can stop your machine from booting if bad software is running.}

\begin{itemize}
\item  The TPM has no control over the rest of your machine; it's a purely passive device.
\item Nor does it have any awareness of what's happening on the system
  beyond what measurement software tells it.
\item The TPM \textit{can}, in \textbf{highly controlled situations}, limit
  data access to only good software; but this is fragile.
\item High-security, predictable systems designed with this in mind
  can use the TPM to limit bad boots.
\begin{itemize}
\item Bitlocker
\item TPM-enabled device encryption
\end{itemize}
\item Note: Does \emph{not} stop machine from booting; just protects
  data.
\end{itemize}


\end{frame}

\begin{frame}{Myth: The TPM is Tamper-Proof}

\begin{itemize}
\item TPMs are tamper-\textit{resistant}\ldots for consumer products.
\item Tremendously good for their cost!
\begin{itemize}
\item Cost $<$ \$1
\item Breaking cost researcher $>$\$100,000; destroyed several in the process
\end{itemize}
\item \textbf{Not} designed with government tamper-resistance standards in mind.
\end{itemize}

\end{frame}

\begin{frame}{Myth: The TPM Works for Disney/Microsoft/etc.}

\begin{itemize}
\item Grew out of early TPM publicity
\begin{itemize} 
\item Originally pitched for digital rights management
\item Not actually the best use
\end{itemize}
\item TPM belongs to the machine owner!
\begin{itemize}
\item In enterprise setting, usually IT department
\item Owner can turn on/off
\item Owner can control identities TPM uses
\end{itemize}
\item This myth is one reason TPM has so many privacy features.
\end{itemize}

\end{frame}


\begin{frame}{Myth: You Can Delegate All Crypto To The TPM}

\begin{itemize}
\item Many people want the TPM to be a general cryptographic coprocessor, but:
\item It's highly constrained
\begin{itemize}
\item Generally a good thing-- prevents many attacks
\item Can't be dropped in for every application
\end{itemize}
\item It's \textit{very} slow
\begin{itemize}
\item Priority is cost, not performance
\item High-speed applications like packet signing: right out
\end{itemize}
\end{itemize}


\end{frame}




\begin{frame}{What We'll Be Covering}
 
In this section:
\begin{itemize}
\item What is a TPM? What does it do?
\item What's it good for?
\item Some TPM myths (and the truths behind them)
\item {\color{red} Why enterprises should care about TPMs}
\end{itemize}

All at a high level-- deep dive this afternoon.
\end{frame}

%% Handy TPM properties for the enterprise
%% inc. ``ubiquitous'' ``cheap'' ``tremendously good return on investment wrt tamper-resistance''

%% TODO: nod to storage and reporting function

\begin{frame}{Why Should Enterprises Care?}

\begin{itemize}
\item TPMs are everywhere
\begin{itemize}
\item Already in almost all enterprise machines
\end{itemize}
\item No additional cost to acquire
\begin{itemize}
\item Although integration isn't free-- we'll talk about that more 
\end{itemize}
\item Very good return on investment for security
\begin{itemize}
\item Software trust $\rightarrow$ hardware
\item Some tamper resistance better than nothing!
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Reminder: The TPM's Benefits}

Earlier, we talked about the TPM's big benefits:

\begin{itemize}
\item Machine Authentication
\item Attestation
\item Data Protection
\end{itemize}

Each of these are directly applicable to enterprises.

\end{frame}


\begin{frame}{Enterprise Machine Authentication}

Enterprises often want to know the identity of machines on their network.

\begin{itemize}
\item Network Access Control: should a machine be allowed to connect?
\item Audit trails: Which machine did this data come from?
\item Authorization: Is this request coming from an expected machine?
\begin{itemize}
\item Particularly useful for sensitive data
\end{itemize}
\item Smartcard replacement: machine instead of user ID
\end{itemize}

\end{frame}

\begin{frame}{Enterprise Attestation}

Today's enterprise security approach in a nutshell:\\
ask the software if the software should be trusted


\begin{itemize}
\item TPM-rooted attestation gives us noticably more assurance
\item Software cannot fake ``good'' measurement or use old one
\item RTMs below the level a rootkit can interfere with
\begin{itemize}
\item We'll talk about the details and other threats shortly
\end{itemize}
\item Machine authentication use cases + state
\begin{itemize}
\item Not just which machine, but what software
\end{itemize}
\item Particularly valuable when combined with sw reporting tools
\begin{itemize}
\item Check if antivirus is good before believing its report
\end{itemize}
\end{itemize}

Note: Full promise of these capabilities not yet available

\end{frame}

\begin{frame}{Enterprise Data Protection}

\begin{itemize}
\item Generally, TPM not providing \textit{new} capability
\item Better assurance over existing solutions
\item TPMs more tamper-resistant than most smartcards
\item TPMs far more tamper-resistant than software encryption solutions
\item Hardware-tied keys mean adversary cannot steal
\begin{itemize}
\item Noticable improvement over purely software keys and certs
\item Note: adversary with machine access can use, but difficulty raised
\end{itemize}
\end{itemize}
\end{frame}


\begin{frame}{Review: What We Covered}
 
\begin{itemize}
\item What is a TPM? What does it do?
\item What's it good for?
\item Some TPM myths (and the truths behind them)
\item Why enterprises should care about TPMs
\end{itemize}

\end{frame}

\begin{frame}{Review: TPM Functionality}

\begin{itemize}
\item A \textit{Root of Trust for Reporting}
\item A \textit{Root of Trust for Storage}
\item Limited internal storage
\begin{itemize}
\item \textit{Platform Configuration Registers}
\item Key storage
\item Data storage
\end{itemize}
\item Random number generation
\item Highly constrained cryptographic functions
\begin{itemize}
\item State reporting
\item Data protection
\item Cryptographic utilities (e.g., signing)
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{Review: The TPM's Benefits}

\begin{itemize}
\item Machine Authentication
\item Attestation
\item Data Protection
\end{itemize}

\end{frame}

\begin{frame}{Questions?}

Next up: Other key trusted computing technologies

\end{frame}


\end{document}