masterthesis/references/IntroToTrustedComputing_full_10-24-2012/auth-and-att.tex

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

\title[Authentication and Attestation]{Using the TPM:\\Machine Authentication and Attestation}
\author{Ariel Segall \\ ariels@alum.mit.edu}
\date{Day 2 \\ \bigskip Approved for Public Release: 12-2749. \\Distribution unlimited}

\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 Cover}

\begin{itemize}
\item Review and deep dive: PCRs and Locality
\item Attestation
\item Machine authentication
\end{itemize}


\end{frame}



%% Quick review of PCRs

\begin{frame}{PCR Review}

\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 Addressed by number: PCR-0, PCR-1, etc.
\item Used primarily to store system measurements
%\item Highly constrained behavior
\item Reset to known value on every boot
\item Can never be freely overwritten; use special extend, reset operations
\item Easy to check; computationally infeasible to forge
\end{itemize}

\end{frame}

\begin{frame}{Digging a Little Deeper: PCR Extend}

The only way to \textit{add} data to a PCR is with \texttt{TPM\_Extend}

\begin{itemize}
\item Current value of a PCR is X. (Say, 0x0000....0000.)
\item We extend the PCR with some data Y.
\begin{itemize}
\item Y must be 160 bit (20 byte) value
\item 20 bytes = SHA1 hash, allowing longer data
\end{itemize}
\item TPM calculates hash(Y,X)=Z; changes value in PCR to Z.
\item We can update further:
\begin{itemize}
\item Extend with A: value is hash(A,Z)=hash(A, hash(Y,X))
\item Extend with B: PCR value is hash(B, hash(A,Z))
\item ...etc.
\end{itemize}
\item Verifiers who know the values extended into the PCRs can easily verify
\begin{itemize}
\item Perform the same hash chain themselves
\end{itemize}
\item Computationally infeasible to forge (must break SHA-1)
\begin{itemize}
\item Given PCR state N and desired state M, adversary would need to find X such that hash(X,N)=M; violates one-way assumption
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Digging a Little Deeper: PCR Reset}

Some (but not all) PCRs are \textit{resettable}. \\

\smallskip

This means they can be reset to a known state by executing the \texttt{TPM\_PCR\_Reset} command.

\begin{itemize}
\item Whether a given PCR is resettable or not is defined in platform spec
\begin{itemize}
\item All PC client TPMs have the same settings
\item Server or virtual TPMs could differ; specs do not exist yet
\end{itemize}
\item Reset requires appropriate permissions
\begin{itemize}
\item Usually based on \textit{locality}, which we'll discuss next
\end{itemize}
\item Sets PCR value back to default, erasing all data currently present
\begin{itemize}
\item Either 0x000...000 or 0xFFF...FFF, depending on PCR \& machine state
\end{itemize}
\end{itemize}

\end{frame}

%% Locality: actually define, explain; idea vs reality

\begin{frame}{Locality}

What is locality?

\begin{itemize}
\item Primitive caller-based access control for TPM
\item Based on CPU state, flags on memory pages
\begin{itemize}
\item If you're familiar with OS rings, similar concept
\end{itemize}
\item PCRs provide state check; locality says ``who sent this
  command?''
\begin{itemize}
\item Even if my OS is in approved state, random apps shouldn't be
  able to use OS' keys
\end{itemize}
\item Used to regulate access to PCRs
\item Locality checked whenever PCR state checked
\item Not utilized much today outside DRTM
\end{itemize}


\end{frame}

\begin{frame}{Locality in Theory}
\begin{center}
\begin{tabular}{| c | c |}
\hline
Locality & Meaning \\
\hline
4 & Trusted Hardware/DRTM\\
3 & Auxiliary Components/DRTM\\
2 & Trusted OS \\
1 & Trusted Applications \\
0 & Static RTM/Legacy \\
\hline

\end{tabular}
\end{center}
\end{frame}

\begin{frame}{Locality in Practice}
\begin{center}
\begin{tabular}{| c | c |}
\hline
Locality & Meaning \\
\hline
4 & Trusted Hardware/DRTM\\
3 & Software launched by DRTM\\
2 & Controlled by OS/TPM Driver \\
1 & Controlled by OS/TPM Driver \\
0 & SRTM; Default \\
\hline

\end{tabular}
\end{center}
\end{frame}

%% PCR chart. Note resettable/not, and locality permission set

\begin{frame}{PCR Usage}

\includegraphics[width=4.5in]{pcr-table}

{\tiny Chart TCG copyright 2005, from PC Client TPM Specification Version 1.2}
\end{frame}

\begin{frame}{PCR Usage Rules of Thumb}


\begin{itemize}
\item Static RTM boot process: 0-7
\begin{itemize}
\item Only subset contains real content today
\end{itemize}
\item DRTM launch and code: 17-20
\item Need a non-resettable PCR? Use 8-15
\begin{itemize}
\item Set aside for OS, but rarely used
\item Linux trusted boot loader uses 8,9, 12-14
\end{itemize}
\item Need a resettable PCR? Use 16 or 23
\end{itemize}
\end{frame}

%% Why do we care? Because PCRs are a flexible tool. Some non-standard examples; mention that we'll go into signing with pcrs in more detail shortly.


\begin{frame}{The Fragility of PCR Values}

\begin{itemize}
\item PCR contents are all hash chains
\begin{itemize}
\item Most values extended into PCRs are also hashes
%\item People rarely want to record only 20 bytes of data
\end{itemize}
\item \textit{Any} change in value will change the hash unpredictably!
\begin{itemize}
\item Did it update the date, or add a rootkit? We can't tell!
\end{itemize}
\item Extremely difficult to predict
\begin{itemize}
\item Holy grail of measurement: golden values reflecting good/bad state
\item Real-world systems generally more chaotic
\end{itemize}
\item Improving predictability, reliability area of active work
\begin{itemize}
\item Research: property-based attestation
\item Industry: standardized measurement techniques and targets
\end{itemize}
\item Still useful!
\begin{itemize}
\item ``Are you the same as you were yesterday?''
\item ``Are you running our 'gold disk'?''
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{What We'll Cover}

\begin{itemize}
\item Review and deep dive: PCRs and Locality
\item {\color{red}Attestation}
\item Machine authentication
\end{itemize}


\end{frame}

\begin{frame}{What Is Attestation, Again?}

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

\begin{itemize}
\item In TPM context, evidence generally means PCRs
\begin{itemize}
\item Can be augmented; we'll talk more about that
\end{itemize}
\item Verifier (also called \textit{appraiser}) can inspect PCRs, verify chain of trust
\begin{itemize}
\item Trust in high-level components based on good low-level measurements
\end{itemize}
\item Primary tool is \textit{Quote}: signed report of current PCR values
\item Any cryptographically verifiable evidence of PCR state counts
\end{itemize}

\end{frame}

\begin{frame}{Quotes}

\begin{center}
\includegraphics[width=3.5in]{quote}
\end{center}

\begin{itemize}
\item Data structured to distinguish from other TPM data
\begin{itemize}
\item Slightly abstracted here for simplicity
\end{itemize}
\item Nonce for freshness, provided by requestor
\item Hash of current PCR values
\begin{itemize}
\item Selection of any subset as desired 
\item Full record of PCR contents should be provided for verification
\end{itemize}
\item Should be signed using an AIK
\begin{itemize}
\item \textbf{Insecure to sign with signing or legacy keys}
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Using a Quote}

\begin{center}
\includegraphics[width=4in]{quote-protocol}
\end{center}

\begin{itemize}
\item Many variations, but all follow fundamental structure
\item Attester decides:
\begin{itemize}
\item Willing to provide this appraiser with that state info?
\end{itemize}
\item Appraiser decides:
\begin{itemize}
\item Is quote valid, and from legitimate TPM?
\item Is nonce the same one I provided? If fresh, proves quote current.
\item Are PCRs in state I approve of?
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Including User Data In Attestation}

\begin{itemize}
\item Sometimes, we want more than just boot-time system data
\begin{itemize}
\item Add runtime measurements from applications (e.g. config checker)
\item Associate application data with good state (e.g. financial programs)
\item Tie external data to machine, now (e.g. user smartcard)
\end{itemize}
\item Several approaches; simplest is to incorporate into quote
\begin{itemize}
\item We'll cover the others next
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{How NOT to Include User Data}

\begin{center}
\includegraphics[width=4in]{quote-nonce-red}
\end{center}


Common approach: replace nonce with user data, or hash(nonce, data)

\begin{center}
\textbf{\color{red} Do not do this!}
\end{center}

\begin{itemize}
\item Nonces are intended for freshness only
\item Adding meaning enables a man-in-the-middle attack!
\end{itemize}

\end{frame}

\begin{frame}{The Nonce-Data Attack}

\begin{center}
\includegraphics[width=4in]{nonce-attack}
\end{center}

\begin{itemize}
\item B can't distinguish random nonce from one with user data
\item A assumes B has signed something that B has never seen
\item \textbf{This is the flaw in TNC's PTS-to-IF-M protocol.}
\item Only occurs if multiple quote protocols on same network, but:
\begin{itemize}
\item Other quote applications are powerful, and should not be eliminated
\item Other people may break your protocol accidentally!
\item Do you really have that much control over your network?
\end{itemize}
%\item \textbf{It is a bad idea to have your protocol assume no others.}
\end{itemize}

\end{frame}

\begin{frame}{How to Safely Include User Data}
\begin{center}
\includegraphics[width=3.5in]{quote-pcr-red}
\end{center}

\begin{itemize}
\item Extend data into an otherwise unused PCR
\begin{itemize}
\item Unlike quote, extend not generally network-accessible!
\item Adversary would need platform access to forge
\end{itemize}
\item Remotely verifiable, without changing overall meaning
\item Note: Often wise to include freshness within data as well
\begin{itemize}
\item Is this anti-virus report from today? Or yesterday?
\end{itemize}
\item These can be used as long-term signatures!
\begin{itemize}
\item ``At the time this was signed, these were the PCR values''
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{Selecting the Right PCRs for Data}
%% TODO: REVISIT THIS, AWKWARD! TABLE?
Broadly, two kinds of PCRs:
\begin{itemize}
\item Resettable
\begin{itemize}
\item Can be reset to known values
\item Generally, reset before each use
\item \textbf{Resettable PCRs are good default for data}
\end{itemize}
\item Non-resettable
\begin{itemize}
\item Reset only on system boot
\item Note: Time since last boot not easy to determine!
\end{itemize}
\end{itemize}

\medskip

\begin{center}
\begin{tabular}{|c|c|}
\hline
Resettable & Non-Resettable\\
\hline
No history & History since boot\\
Low verifier overhead & Usable for offline updates\\
Good for one-offs & Good for audit logs\\
\hline
\end{tabular}
\end{center}

\end{frame}


%% Attestation beyond quotes: certifykey + pcr locks, sealing and binding
%% \item \textbf{Locking data or keys to PCR values should be used with care}

\begin{frame}{Beyond Quotes: Other Forms of Attestation}

\begin{itemize}
\item Two primary categories:

\begin{itemize}
\item PCR constraints on keys
\item PCR constraints on data
\end{itemize}

\item Both of these share a common requirement:
\begin{itemize}
\item ``Good'' PCR values must be known in advance
\end{itemize}
\item Side note: whenever PCRs constrained, locality can be also
\begin{itemize}
\item Very useful for certain DRTM applications, such as Flicker
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Attestation with PCR-Constrained Keys}

Previously discussed:
\begin{itemize}
\item Any TPM key can have PCR constraints associated with it
\item Keys can only be used when PCRs match constraints
\item CertifyKey allows remote party to verify constraints
\end{itemize}

Put together:
\begin{itemize}
\item Create a key with PCR constraints X.
\item Certify the key with your choice of AIK.
\item Now, whenever key used, remote party knows PCRs contain X.
\end{itemize}
\end{frame}

\begin{frame}{PCR-Constrained Key Use Cases}

\begin{itemize}
\item ``When this data was signed, X was true''
\begin{itemize}
\item Good for any case where X implies properties of data; e.g:
\item Certifying correct handling of sensitive data
\item Performing hard-to-verify or security-sensitive operations
\end{itemize}
\item ``When this data was encrypted, X was true''
\begin{itemize}
\item Good for tracking possession over multiple boots
\item Good for evaluating data sources
\item Note: not for encrypting to remote platforms! (Seal, not bind)
\end{itemize}
\item ``When this data is decrypted, X will be true''
\begin{itemize}
\item Good for ensuring state on receipt
\item Covered in more detail on next slide
\end{itemize}
\end{itemize}


\end{frame}

\begin{frame}{Attestation with PCR-Constrained Data}

\begin{itemize}
\item Sealing (local) allows PCR constraints on encrypted data
\begin{itemize}
\item Can also Bind (remote), but constraints on key, not data
\end{itemize}
\item Useful for data protection!
\begin{itemize}
\item Know both target machine and target state at time of receipt
\item No simultaneous communication required-- can create at any time
\item ``You can only receive this data if you're in an acceptable state''
\end{itemize}
\item If PCRs predictable, can encrypt to future state
\begin{itemize}
\item Remote: ``If you update, you'll gain access''
\item Local: Normal operation can encrypt to secure-mode code 
\item Local: Secure-mode app A can encrypt to secure-mode app B
\end{itemize}
\item Can be used to make data only accessible during windows of time
\begin{itemize}
\item e.g., disk decryption key sealed to non-resettable PCRs containing
  default values; filled in as machine boots
\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Why no NVRAM attestation?}


NVRAM can be constrained to PCR values; why can't it be used to attest?

\begin{itemize}
\item Evidence must be \textit{remotely verifiable}.
\item Owner sets NVRAM constraints; no way to directly verify! 
\begin{itemize}
\item Keys can be certified with CertifyKey
\item Sealed or Bound data can be directly inspected
\item Owner would need to issue certificate; not a standard process
\end{itemize}
\item Proof of access: read data from NVRAM
\begin{itemize}
\item Unless asymmetric key pair, verification requires knowledge of secret
\item If key pair, just use key constraints!
\item If not, certifying association between secret and state leaks info
\end{itemize}
\item Generally, can only attest meaningfully to owner
\begin{itemize}
\item Small enough use case to not worry about
\end{itemize}
\end{itemize}

PCR constrained NVRAM very useful! But not for remote attestation.

\end{frame}

\begin{frame}{Attestation Summary}

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

\begin{itemize}
\item Any verifiable report of PCR contents can be used for attestation
\item Quote is primary attestation tool
\begin{itemize}
\item Signed report of current PCR state
\item Can be used to also sign user data via extended PCRs
\item Generally, use resettable PCR for signing data
\item \textbf{Never} use quote nonce to sign data!
\end{itemize}
\item PCR constrained keys or data can be used for specialized applications
\end{itemize}


\end{frame}


\begin{frame}{What We'll Cover}

\begin{itemize}
\item Review and deep dive: PCRs and Locality
\item Attestation
\item {\color{red}Machine authentication}
\end{itemize}


\end{frame}

\begin{frame}{What is Machine Authentication?}

\begin{itemize}
\item Remotely verifiable proof of machine identity
\item Useful in many enterprise contexts
\item Strict subset of attestation!
\begin{itemize}
\item Attestation: ``What is the state of machine X?''
\item Authentication: ``Is this machine X?''
\end{itemize} 
\item Most TPM keys can be used for machine authentication.
\begin{itemize}
\item TPM soldered to motherboard
\item Keys crytographically bound to TPM
\item All key activity must happen on that machine!
\end{itemize}
\end{itemize}

\end{frame}


\begin{frame}{Types of Machine Authentication}

Two primary types:
\begin{itemize}
\item Signing-based
\item Decryption-based
\end{itemize}

\end{frame}

\begin{frame}{Signing-Based Machine Authentication}

\begin{itemize}
\item The most intuitive form of machine authentication
\item ``Machine X signed Y''
\item Easy to use to derive trust in Y
\item We'll focus on non-attestation signatures
\begin{itemize}
\item Remember, attestation will get you auth for free!
\item But involves overhead you often don't want.
\end{itemize}
\end{itemize}

\medskip
Choosing the right key for authentication is not as easy as it sounds!
\begin{itemize}
\item Signing keys
\item Identity keys
\end{itemize}
\end{frame}
 
\begin{frame}{Signing Key Choices}
\begin{itemize}
\item Signing keys come in several varieties!
\item Choice of key properties can make or break security.
\begin{itemize}
\item Key length: 512-2048 bits; should be 2048
\item Migratability: \textbf{must be non-migratable for authentication}
\item Signature scheme: SHA1, DER, INFO
\begin{itemize}
\item Note: all RSA keys; scheme determines what kind of data can be signed
{\onslide<2>

\item {\color{red}\textbf{Security critical!}}}
\end{itemize}

\end{itemize}
\end{itemize}

\end{frame}

\begin{frame}{Signature Schemes}

\begin{description}
\item[SHA1] Signs only 20-byte chunks of data. (SHA-1 hash length!) Will sign user data or TPM data, but \textbf{should never be trusted to sign TPM data, as forgery is trivial.}
\item[DER] Signs DER-formatted data. Will only sign user data. Should ensure that nothing these sign appear to be TPM data.
\item[INFO] Signs data in custom TPM wrapper format. Designed to be a more flexible alternative to identity keys. \textbf{\color{red} Vulnerable to SHA-1 collision attack. Do not use.}
\end{description}



\end{frame}

\begin{frame}{Using Signing Keys for Machine Authentication}

\begin{itemize}
\item \texttt{TPM\_Sign} command
\item Sign arbitrary user-provided data in key-appropriate format
\item SHA1 or DER signatures can often be dropped into existing protocols
\begin{itemize}
\item Use TPM key instead of software key; get machine auth for free
\item Note: slow! Do not use for high-frequency operations
\end{itemize}
\item Associate any data with machine
\end{itemize}

\end{frame}

\begin{frame}{Using Identity Keys for Machine Authentication}

\begin{itemize}
\item Identity keys intended for TPM authentication
\item \textbf{Identity keys are the only secure choice for TPM data}
\begin{itemize}
\item Quotes, CertifyKey certs, audit logs
\item All imply machine auth
\end{itemize}
\item As with signing keys, associate all signed data with machine
\item To sign only user data:
\begin{itemize}
\item Extend user data into PCRs; perform quote of only those PCRs
\item Note: high overhead for a simple signature!
\end{itemize}
\item Best used for attestation or TPM-specific functions, however:
\item It is not possible to misconfigure an identity key, making them easier to verify!
\end{itemize}


\end{frame}

\begin{frame}{Verification is Critical}

\begin{center}
\textbf{Trust requires a target: trust for what?}
\end{center}

\begin{itemize}
\item When evaluating TPM signatures, it is critical to ask:
\begin{itemize}
\item Is this data making any claims about TPM state or keys?
\item If so, is this key one I should trust for that purpose?
\item \textbf{Never trust a signing key without considering both key and data.}
\end{itemize}
\item This is also the core question when evaluating attestation target!
\end{itemize}

\end{frame}

\begin{frame}{Types of Machine Authentication}

Two primary types:
\begin{itemize}
\item Signing-based
\item {\color{red}Decryption-based}
\end{itemize}

\end{frame}

\begin{frame}{Decryption-Based Machine Authentication}

\begin{itemize}
\item We prove identity by demonstrating secret possession
\item Decrypting data proves possession of private key
\item Remote party can prove identity by creating encrypted challenge
\begin{itemize}
\item If challenge is decrypted and used, proves possession
\end{itemize}
\item We use binding keys for this
\begin{itemize}
\item Storage keys for local data only!
\end{itemize}
\end{itemize}
\end{frame}

\begin{frame}{Authenticated Data Delivery}

\begin{itemize}
\item Simplest form of decryption-based authentication
\item Take data intended for target; \textit{Bind} with target binding key
\begin{itemize}
\item Note: \texttt{TPM\_Unbind} is a TPM operation; Bind is not
\item For practical purposes, large data usually encrypted with symmetric key; symmetric key is bound
\end{itemize}
\item Encrypted data can now be made public; only target can make use of
\item Note: Can also perform attestation by binding to PCR-constrained key
\end{itemize}

\end{frame}

\begin{frame}{Decryption-Based Authentication Protocols}

\begin{itemize}
\item Many protocols encrypt a secret to prove identity!
\begin{itemize}
\item Nonces, keys, session ID
\end{itemize}
\item Powerful approach: Use TPM key to establish shared session key
\begin{itemize}
\item Public key operations expensive
\item Use to set up shared secret symmetric key
\end{itemize}
\item Simplest possible protocol: bind session key, send to authentication target
\item Usually, however, want \textit{mutual authentication}: both
  parties identified
\end{itemize}

\end{frame}

\begin{frame}{A Sample Decryption-Based Attestation Protocol}
\begin{center}
\includegraphics[width=4in]{decryption-protocol}
\end{center}

\begin{itemize}
\item A knows only B will know K1
\item B knows only A will know K2
\item Secure channel can be built with combined key
\end{itemize}

\end{frame}

\begin{frame}{Machine Authentication Summary}

\begin{itemize}
\item Machine authentication provides proof of machine identity
\item Signing or decryption based
\item Use SHA1 or DER signing keys for most user data
\item Use identity keys for TPM data or high-security applications
\item Use binding keys to guarantee data recipient identity
\end{itemize}

\end{frame}

\begin{frame}{What We've Covered}

\begin{itemize}
\item Review and deep dive: PCRs and Locality
\item Attestation
\item Machine authentication
\end{itemize}


\end{frame}

\begin{frame}{Summary}



\begin{tabular}{|c|c|c|}
\hline
\textbf{If you want\ldots} & \textbf{use key type\ldots} & \textbf{with\ldots}\\ 
\hline
Attestation & Identity & Quote \\
Signing-based Authentication & Signing & Sign \\
Decryption-based Authentication & Binding & Bind \\
\hline
\end{tabular}
\end{frame}


\begin{frame}{Questions?}


\end{frame}

\end{document}