Added recent references found in the meantime

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

@@ -0,0 +1,837 @@
+\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}

references/IntroToTrustedComputing_full_10-24-2012/background-intro.tex

@@ -0,0 +1,150 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[Crypto Basics]{Introduction to Trusted Computing: \\ Crypto and Security Basics}
+\author{Ariel Segall\\ ariels@alum.mit.edu}
+\date{Day 1\\ \bigskip Approved for Public Release: 12-2749. \\Distribution unlimited}
+
+\begin{document}
+
+\begin{frame}
+es
+
+\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}{The Lightning Review}
+
+Goal: quickly familiarize you with the following concepts, or refresh your memory
+
+\begin{itemize}
+\item Core security principles
+\item Nonce
+\item Cryptographic keys (symmetric and asymmetric)
+\item Hashes
+\item Common attack terms
+\end{itemize}
+
+Confused? Ask questions early and often!
+
+\end{frame}
+
+\begin{frame}{What do we mean by secure?}
+
+Three basic concepts:
+
+\begin{itemize}
+\item Confidentiality (Secrecy)
+\item Integrity
+\item Availability
+\end{itemize}
+
+Trusted computing focuses on the first two.
+
+\end{frame}
+
+\begin{frame}{Freshness and Nonces}
+\begin{itemize}
+\item We often want to be sure that data is \textit{fresh}, or recent.
+\begin{itemize}
+\item Am I actually talking to you now, or is this a recording?
+\end{itemize}
+\item Our primary tool: \textit{nonces}
+\item Nonce: \textit{freshly generated} random number
+\begin{itemize}
+\item Must be unpredictable!
+\end{itemize}
+\item Nonce generator knows any message containing their nonce was created after the nonce
+\item Allows locally verifiable confirmation that remote activity current
+\begin{itemize}
+\item Timestamps aren't verifiable! Too predictable.
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Cryptographic Keys}
+
+Two main types:
+\begin{itemize}
+\item Symmetric keys
+\item Asymmetric keys 
+\begin{itemize}
+\item aka ``public keys'', ``public-private key pairs''
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Symmetric Key Cryptography}
+
+\begin{itemize}
+\item Same key used for all operations: encryption vs. decryption, signing vs. verifying
+\item Usually very fast, good for bulk operations
+\item Big disadvantage: key distribution
+\item Not a primary topic for today
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Public Key Cryptographic (Asymmetric)}
+
+\begin{itemize}
+\item Keys come in pairs: one public, one private
+\begin{itemize}
+\item Public key is just that: no security risk from world knowing
+\item Private key must be kept secret.
+\end{itemize}
+\item Private key used for decryption, signing
+\item Public key used for encryption, verification
+\item Great for proofs of identity
+\item Slow to use; not very good for bulk operations
+\item RSA: most common public key algorithm in use now
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Hashes}
+
+\begin{itemize}
+\item Cryptographic hash: one-way function from arbitrary data to fixed length
+\item Critical hash properties:
+\begin{itemize}
+\item Easy to calculate
+\item Infeasible to reconstruct data from hash
+\item Infeasible to find collisions (different data, same  hash)
+\item Infeasible to modify data without changing hash
+\end{itemize}
+\item SHA1: hash algorithm primarily referred to in this class
+\begin{itemize}
+\item More recent algorithms exist; not widely supported in hardware yet
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Common Attack Terms}
+
+\begin{description}
+
+\item [Denial of Service (DoS)] Attack where adversary causes service
+  to be unavailable, temporarily or permanently. DoSes can also happen by accident.
+\item [Man in the Middle (MitM)] Attack where adversary fowards messages between parties, potentially modifying them, to deceive one or both parties or to reveal supposedly secret information.
+
+\end{description}
+
+\end{frame}
+
+\begin{frame}{Questions?}
+
+\end{frame}
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/course-summary.tex

@@ -0,0 +1,84 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[Course Overview]{Introduction to Trusted Computing: \\Course Overview}
+\author{Ariel Segall \\ ariels@alum.mit.edu}
+\date{Spring 2012 \\\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}{A Note for Open Security Training Users}
+
+The slides for this course were revised between the recorded session
+and now. In order to provide the best materials, the revised slides
+have been included here; however, you may notice some discrepancies
+between the recordings and the slides. I apologize; if I ever have the
+chance to rerecord the video, I will.
+
+
+\end{frame}
+
+\begin{frame}{Day 1}
+
+\begin{itemize}
+\item Quick Crypto and Security Vocabulary Review %% background-intro
+\item What Is Trusted Computing? %% what-is-trusted-computing
+\item TPM 101: A High Level Summary %% tpm101
+\item Trusted Computing Ecosystem: Beyond the TPM %% other-tc-tech
+\item Lunch!
+\item Trusted Computing in the Enterprise: Where We Are Today and Where We're Going%%enterprise-use-cases-- DOES NOT EXIST YET
+\item TPM Provisioning %% provisioning
+\item TPM Keys: Creating Them, Certifying Them, and Using Them %% tpm-keys
+
+\end{itemize}
+
+%% TODO: Consider reordering the keys/machine att/storage discussion
+\end{frame}
+\begin{frame}{Day 2}
+
+\begin{itemize}
+%\item The Roots of Trust for Measurement -> covered in other-tc-tech
+\item Using the TPM: Machine Authentication and Attestation %% auth-and-att
+\item Using the TPM: Data Protection and Storage %% data-storage
+\item Using the TPM: Other Capabilities % tpm-misc
+\item Lunch!
+%\item Beyond 1.2: Mobile Trusted Modules and TPM 2.0 -> briefly covered in other-tc-tech
+\item From Theory to Reality % programming-tpm
+\item Resources for Further Investigation % tpm-specs
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{About This Class}
+
+\begin{itemize}
+\item Ask questions early and frequently!
+\begin{itemize}
+\item Concepts build on each other
+\end{itemize}
+\item Discussion encouraged
+\begin{itemize}
+\item Section of second afternoon reserved for student questions and use cases
+\end{itemize}
+\item Schedule may vary!
+\end{itemize}
+
+\end{frame}
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/data-storage.tex

@@ -0,0 +1,383 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[Data Storage]{Using the TPM: \\ Data Protection and Storage}
+\author{Ariel Segall \\ ariels@alum.mit.edu}
+\date{Day 2\\ \bigskip Approved for Public Release: 12-2749. \\Distribution unlimited}
+%\institute{\copyright MITRE Corporation 2012}
+%\date{May 31, 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}
+\begin{itemize}
+\item The TPM's Tamper Resistance
+\item Using Storage Keys 
+\item Using Binding Keys
+\item NVRAM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Revisiting the TPM's Tamper Resistance}
+
+My most frequently asked question about TPMs:\\ 
+``I can use it to protect
+my data if the machine is stolen, right?''
+
+\begin{itemize}
+\item Reminder: TPM is \textit{tamper-resistant}, not tamper-proof
+\begin{itemize}
+\item Not up to government standards
+\item Not designed for nation-state adversaries!
+\end{itemize}
+\item Far better than software protection, but keys \textit{can} be removed
+\begin{itemize}
+\item Expensive to break: \$100,000+ for the publicized attack
+\item High failure rate: destroyed a dozen to remove keys from one
+\item \textbf{Still not sufficient for sponsor high-value data with
+  high theft risk}
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{TPM's Storage Protection Scenarios}
+
+\begin{itemize}
+\item Evil Maids
+\begin{itemize}
+\item Can't copy hard drive and pull keys out at leisure
+\item Combined with PCRs, can't reboot into evil OS and steal secrets
+\end{itemize}
+\item Software data theft
+\begin{itemize}
+\item Can't freely vacuum data and send off machine
+\item Combine TPM keys and user passwords for best security
+\item Note: At-rest protection, not during use!
+\end{itemize}
+\item Casual physical theft
+\begin{itemize}
+\item Not good enough for nation-states, plenty good against even
+  competent thieves
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{What This Means For Use}
+
+\begin{itemize}
+\item The TPM is strongest when protecting data at rest\ldots
+\item \ldots therefore, protecting data in bulk less effective than small, focused chunks
+\item Storage most effective when used in multi-part security:
+\item TPM as thing you have; authorization value as thing you know
+\item State verification one of the most powerful tools for data protection\ldots
+\item \ldots and can also cause self-inflicted DoS. Use with care.
+\end{itemize}
+
+
+\end{frame}
+
+
+\begin{frame}{What We'll Be Covering}
+\begin{itemize}
+\item The TPM's Tamper Resistance
+\item {\color{red}Using Storage Keys} 
+\item Using Binding Keys
+\item NVRAM
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Using Storage Keys}
+
+\begin{itemize}
+\item \texttt{TPM\_Seal}: Encrypt data for later decryption with \texttt{TPM\_Unseal}
+\begin{itemize}
+\item Local platform only!
+\end{itemize} 
+\item Storage keys are also used to protect TPM keys
+\begin{itemize}
+\item Every \texttt{TPM\_CreateWrapKey} operation must provide a storage key parent
+\item When migrating keys, encrypted to storage key: new parent
+\end{itemize}
+\item Note: The SRK is a storage key!
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{Key Storage Hierarchy Review}
+
+\includegraphics[width=4in]{key-storage-hierarchy}
+
+\end{frame}
+
+\begin{frame}{Sealing}
+
+\begin{itemize}
+\item When sealing data, several options:
+
+\begin{itemize}
+\item Which storage key to use
+\item Whether to require authorization data (password)
+\item Whether to provide PCR constraints for decryption
+\item Whether to provide locality constraints for decryption
+\end{itemize}
+\item Sealed data always contains unique TPM internal value
+\begin{itemize}
+\item Locked to this TPM even if the key migrates
+\end{itemize}
+\item Sealing also records the current PCR state
+\begin{itemize}
+\item Ensure that decrypted data can be trusted
+\end{itemize}
+\item Returns ``sealed blob''
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Unsealing}
+
+\begin{itemize}
+\item Use same storage key to decrypt
+\item Verifies authorization, current PCRs, current locality against blob
+\begin{itemize}
+\item Note: two authorizations may be required! One for key, one for blob
+\end{itemize}
+\item Verifies creation data to ensure real creation value matches public value
+\item Returns decrypted data
+\item Note: blob can be unsealed multiple times
+\end{itemize}
+
+\medskip
+
+Note: Once unsealed, data is in the clear!
+\begin{itemize}
+\item Use PCR values and authorization to minimize risk of loss during use
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Storage Key Summary}
+
+\begin{itemize}
+\item Utility key for protecting secret data, including keys
+\item Directly protect user data with Seal
+\begin{itemize}
+\item Optionally additionally protect with password, PCR constraints
+\item Local system only
+\end{itemize}
+\item Decrypt with Unseal
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+\begin{itemize}
+\item The TPM's Tamper Resistance
+\item Using Storage Keys 
+\item {\color{red}Using Binding Keys}
+\item NVRAM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Binding Keys}
+
+\begin{itemize}
+\item Another utility key for data protection
+\item Different paradigm than storage
+\item Anyone on any platform can Bind data
+\item Only TPM can decrypt, using \texttt{TPM\_Unbind}
+\item No fancy options-- just decryption
+\begin{itemize}
+\item PCR constraints and authorization still possible, but on key not blob
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Storage vs. Binding Key Summary}
+
+\begin{tabular}{|c|c|}
+\hline 
+\textbf{Storage} & \textbf{Binding} \\
+\hline
+Local use only & Local or remote use \\
+\hline
+\textit{Seals} user data, & \textit{Binds} user data, \\
+optional extra constraints & constraints only on key \\ 
+\hline
+Can be used as key parent & Encrypts user data only\\
+\hline
+Only authenticates local data & Usable for machine authentication \\
+\hline
+\end{tabular}
+
+
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+\begin{itemize}
+\item The TPM's Tamper Resistance
+\item Using Storage Keys 
+\item Using Binding Keys
+\item {\color{red}NVRAM}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{NVRAM Summary}
+
+\begin{itemize}
+\item Storage area inside TPM
+\item Very limited in size: only 1280 bytes required, though can be bigger
+\begin{itemize}
+\item No hard data on actual implementations
+\end{itemize}
+\item Controlled by owner; permissions can be delegated
+\item Some sections reserved for specific purposes (e.g., root credentials)
+\item Customizable constraints per region for read or write access
+\begin{itemize}
+\item PCR contents
+\item Locality
+\item Authorization data 
+\end{itemize}
+\item Limited number of writes; can be burned out
+\begin{itemize}
+\item Order of 10,000; only a  minor DoS issue for most applications
+\end{itemize}
+%\item Not going into how to allocate, store data today-- \\implementation complicated 
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Why NVRAM is Useful}
+
+\begin{itemize}
+\item Stores data that can serve as reference
+\begin{itemize}
+\item Much harder to modify than data on disk!
+\item Hashes for integrity checking
+\item Owner or trusted authority public key 
+\item Very powerful for system sanity checking!
+\end{itemize}
+\item Stores high-value data that should not be accidentally deleted
+\begin{itemize}
+\item Keys
+\item Certificates
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{NVRAM Use Case Examples}
+
+\begin{itemize}
+\item Storing user-chosen pictures for 'trusted boot'
+\begin{itemize}
+\item If correct picture retrieved, PCR values in known state
+\end{itemize}
+\item Preventing attacks which replace trusted authority
+\begin{itemize}
+\item IT-approved CA key or DNS server in read-only NVRAM
+\end{itemize}
+\item Integrity reference for software
+\begin{itemize}
+\item Put hash of file in write-limited NVRAM
+\item Current AV definitions? Most recent save file? Policy approved
+  by owner? Approved OS list for boot loader?
+\item If file is public key, can use to verify owner signature.
+\end{itemize}
+\item Resources for early boot, DRTM
+\begin{itemize}
+\item Limited space, but easy to constrain access
+\end{itemize} 
+\end{itemize}
+
+\end{frame}
+
+
+
+\begin{frame}{Using NVRAM-- Quick Summary}
+
+\begin{itemize}
+\item Establish a region of NVRAM with desired size and permissions
+\begin{itemize}
+\item \texttt{TPM\_NV\_DefineSpace}
+\item Owner only, unless permissions delegated
+\end{itemize}
+\item Separate commands for owner, non-owner access
+\begin{itemize}
+\item \texttt{TPM\_NV\_WriteValue}, \texttt{TPM\_NV\_ReadValue} for non-owner
+\item \texttt{TPM\_NV\_WriteValueAuth}, \texttt{TPM\_NV\_ReadValueAuth} for owner
+\end{itemize}
+\item \textbf{Note: Access control enforcement on NVRAM is not automatic!}
+\begin{itemize}
+\item Manufacturers need ability to write certs into NVRAM without being owner
+\item Supposed to set flag enabling access control afterwards
+\item Don't always!
+\item How to check and set flag in next section.
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+
+
+\begin{frame}{Problems with NVRAM}
+
+\begin{itemize}
+\item Space is \textit{very} limited
+\begin{itemize}
+\item For one application, not a problem; if commonly used, potentially serious
+\item Many hashes; very few certificates or keys
+\end{itemize}
+\item Limited number of writes in lifetime
+\begin{itemize}
+\item How many? Good question!
+\item Not suitable for applications with frequent updates
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{TPM Data Protection Review}
+
+\begin{itemize}
+\item TPM designed for protection of data at rest
+\item Storage keys protect data on this platform
+\begin{itemize}
+\item Many protection options
+\end{itemize}
+\item Binding keys protect data from anywhere
+\item NVRAM protects limited, high-value data
+\begin{itemize}
+\item Good for integrity verification and system checks
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Questions?}
+
+\end{frame}
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/other-tc-tech.tex

@@ -0,0 +1,337 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usepackage{color}
+\usetheme{Madrid}
+
+\title[Beyond the TPM]{Beyond the TPM: \\ Other Trusted Computing Technologies}
+\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}
+
+\begin{itemize}
+\item The Roots of Trust for Measurement (RTMs)
+\item Trusted Network Connect
+\item What else is out there (in brief)
+\end{itemize}
+
+\end{frame}
+
+
+\section{Roots of Trust for Measurement}
+\begin{frame}{Core Concept: Chain of Trust}
+
+Measurements in trusted computing are based on the idea of a
+\textit{chain of trust}.
+
+\begin{itemize}
+\item Component A measures component B; stores that measurement
+\item Component A then launches component B
+\item Verifier: ``If I trust A, then I can believe the measurement of
+  B is accurate, and use the measurement to decide if I trust B.''
+\item Chains: A measures B, B measures C, C measures D....
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Two RTMs}
+
+There are two Roots of Trust for Measurement:
+
+\begin{itemize}
+\item Static
+\begin{itemize}
+\item Part of BIOS
+\item Runs automatically as part of system boot
+\item Used to create ``boot-time'' chain of trust
+\end{itemize}
+\item Dynamic
+\begin{itemize}
+\item Part of CPU (signed code from manufacturer)
+\item Run by entering special secure CPU mode
+\item Used to create ``late-launch'' chain of trust
+\item Can be used to measure and launch anything!
+\end{itemize}
+
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Static RTM Chain of Trust}
+\includegraphics[width=4.5in]{chain-of-trust.pdf}
+\end{frame}
+
+\begin{frame}{Static RTM Tradeoffs}
+
+Pros:
+\begin{itemize}
+\item Already there, already working
+\item Free, no need to change any software
+\end{itemize}
+
+Cons:
+\begin{itemize}
+\item How much do you trust your BIOS? Your BIOS vendor?
+\item Today, measurements are \textit{extremely} variable and cryptic
+\begin{itemize}
+\item Work ongoing on standardizing, but not rolled out yet
+\end{itemize}
+\item BIOS ``bootkits'' exist.
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{DRTM: How It Works}
+
+\begin{itemize}
+\item Special command sent to processor, along with designated region of memory
+\begin{itemize}
+\item SINIT (Intel's TXT) or SKINIT (AMD's SVM)
+\end{itemize}
+\item All processing on machine shut down except for special code module
+\begin{itemize}
+\item Stored in firmware, signed by CPU manufacturer
+\item Signature verified before execution
+\end{itemize}
+\item Code module (DRTM) hashes contents of memory region, stores in TPM
+\begin{itemize}
+\item Memory region may include both data and executables
+\end{itemize}
+\item Passes control to specified location in memory
+\item Direct chain of trust from CPU root to any program user chooses
+\item Has special locality, and PCRs only it can write to
+\begin{itemize}
+\item Can also be used to constrain keys or data
+\end{itemize}
+\item Often referred to as \textit{Late Launch}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{DRTM Example: Virtualization Chain of Trust}
+
+\includegraphics[width=4.5in]{virtualization-chain-of-trust.pdf}
+
+\end{frame}
+
+\begin{frame}{DRTM Example: Flicker Chain of Trust}
+
+\includegraphics[width=4.5in]{flickr-chain-of-trust.pdf}
+
+\end{frame}
+
+\begin{frame}{DRTM Tradeoffs}
+
+Pros:
+\begin{itemize}
+\item Very flexible; measure anything you need to
+\item Trust CPU, not BIOS or boot loader
+\item Much shorter chains of trust
+\end{itemize}
+
+Cons:
+\begin{itemize}
+\item Requires non-trivial implementation
+\end{itemize}
+
+Mixed:
+\begin{itemize}
+\item Can be done repeatedly; only most recent verifiable
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{When Should You Care About RTMs?}
+
+System design or integration:
+\begin{itemize}
+\item You want your system to be remotely evaluatable via TPM.
+\end{itemize}
+
+\medskip
+
+Application:
+\begin{itemize}
+\item You want your app to be measurable.
+\begin{itemize}
+\item Unless using Flicker-style application-specific DRTM, you just
+  need to know which component should measure your app.
+\end{itemize}
+\item You are evaluating another system's trustworthiness, and thus
+  need to know which RTM they use.
+\item That's it! Otherwise, you can pretty much ignore.
+\end{itemize}
+
+\end{frame}
+
+\section{Trusted Network Connect}
+
+\begin{frame}{What We'll Be Covering}
+
+\begin{itemize}
+\item The Roots of Trust for Measurement (RTMs)
+\item {\color{red}Trusted Network Connect}
+\item What else is out there (in brief)
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Trusted Network Connect Overview}
+
+\begin{itemize}
+\item TCG's architecture for network access control (NAC)
+\item Not really a technology; a suite of protocols and architectures
+\item Probably the most supported TCG product
+\item \textbf{Does not actually require use of the TPM}
+\begin{itemize}
+\item Part of the reason adoption has been rapid
+\item Architecture flexible and abstract-- roots of trust optional!
+\item \textbf{Not all implementations of TNC can meaningfully be trusted}
+\end{itemize}
+\item Uses fairly standard NAC abstractions
+\end{itemize}
+
+Core idea: Machines seeking network access present evidence about
+their state, which is evaluated based on policy before the machine is
+admitted.
+
+\end{frame}
+
+\begin{frame}{TNC Vocabulary}
+\begin{description}
+\item[AR]\textbf{ Access Requestor}: machine seeing network access
+\item[PEP]\textbf{ Policy Enforcement Point}: Gateway, or other resource that can allow or deny access
+\item[PDP] Policy Decision Point: Machine which evaluates access requests
+\item[MAP] Metadata Access Point: Stores and provides information about ARs
+\item[MAPC] MAP Client: Clients which read or write MAP state data about ARs
+\item[PTS] Platform Trust Services: AR software interfacing between TNC and TPM.
+\end{description}
+
+Only bold roles actually required.
+
+\end{frame}
+
+\begin{frame}{TNC High-Level Visual}
+
+\includegraphics[width=4.5in]{tnc-arch.pdf}
+
+\end{frame}
+
+\begin{frame}{TNC: Where the TPM Fits In}
+\begin{center}
+\includegraphics[width=4in]{tnc-arch-with-tpm.pdf}
+\end{center}
+\end{frame}
+
+\begin{frame}{Some Words of Warning}
+
+\begin{itemize}
+\item The TNC protocol designers were not TPM experts.
+\begin{itemize}
+\item {\color{red}\textbf{It is not safe to deploy their PTS to IF-M binding in an
+  enterprise that plans to use any other attestation technologies.}}
+\item There is a \textbf{man-in-the-middle attack} if quotes are used
+  elsewhere on the network.
+\end{itemize}
+\item TNC alone does not give you real trust; it defines how components communicate
+\item You can buy TNC products today; always ask whether they use the TPM, and if so, how.
+\end{itemize}
+
+\end{frame}
+
+
+\section{What else is out there}
+
+\begin{frame}{What We'll Be Covering}
+
+\begin{itemize}
+\item The Roots of Trust for Measurement (RTMs)
+\item Trusted Network Connect
+\item {\color{red}What else is out there (in brief)}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Other Trusted Computing Technologies: Storage}
+
+\begin{itemize}
+\item High-security drives designed with trusted computing in mind
+\item Self-encrypting
+\begin{itemize}
+\item Designed for high speed encryption and decryption
+\end{itemize}
+\item Generally support user authentication
+\item Future possibilities: machine authentication or attestation
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{Other Trusted Computing Technologies: Protocols}
+
+Generally, TCG's protocols are focused on taking advantage of
+low-level technologies.
+
+\begin{itemize}
+\item Integrate TPM quotes into high-level reporting standards
+\item Certify TPM keys and trusted platforms
+\item Add TPM data to various handshakes or channel establishments
+\item \textbf{\textit{Not all TCG protocols are appropriate for enterprise use!}}
+\begin{itemize}
+\item Serious flaws have been found in at least one TCG protocol (PTS
+  Binding to IF-M)
+\item Assumed it would be the \textit{only} protocol on the network using the TPM
+\item All TCG protocols should be evaluated against enterprise needs before use
+\end{itemize}
+\end{itemize}
+
+
+
+\end{frame}
+
+\begin{frame}{Other Trusted Computing Technologies: Near Future}
+
+\begin{itemize}
+\item Mobile Trusted Module
+\begin{itemize}
+\item Streamlined TPM-like functionality for cellphones
+\item Allow providers more ability to control, verify software
+\item Support cellphone-as-wallet usecase with real security
+\end{itemize}
+\item TPM 2.0
+\begin{itemize}
+\item Next version of TPM
+\item Much like today's, but more flexible and more capable
+\item Better crypto algorithms
+\item More standards-compliant
+\end{itemize}
+\item Trusted Virtualized Platform
+\begin{itemize}
+\item Using TPMs to establish trust in virtualized workstation or cloud
+\item Virtual TPMs for identifying VMs and protecting VM data
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/programming-tpm.tex

@@ -0,0 +1,357 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[TPM Programming]{Programming for the TPM \\ and other practical topics}
+\author{Ariel Segall \\ ariels@alum.mit.edu}
+\date{Day 2 \\ \bigskip Approved for Public Release: 12-2749 \\ Distribution unlimited} 
+%\date{May 31, 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}{Why Straight Into Programming?}
+
+FAQ: ``Where can I buy commercial products with TPM feature X?''
+
+\smallskip
+
+Usual Answer: ``You can't yet''.
+
+\begin{itemize}
+\item Software vendors have generally not started integrating TPMs
+\begin{itemize}
+\item Demand not there
+\end{itemize}
+\item Only a few isolated products provide support
+\begin{itemize}
+\item Usually specialized
+\item Not always friendly to other applications
+\end{itemize}
+\item For today, expect to build your own, or convince vendor to support
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Exceptions}
+
+\begin{itemize}
+\item Most mature: trusted computing work in open source community
+\begin{itemize}
+\item Largely driven by IBM, European OpenTC initiative, grad students
+\item tpm-tools: Linux package (orphaned?) with basic command line utilities
+\item Thunderbird integration: TPM protection of key store
+\item tboot: GRUB (boot loader) version with extra TPM compatibility, features
+\item Generally aimed at individual tinkerers
+\end{itemize}
+\item Microsoft beginning TPM integration
+\begin{itemize}
+\item Prominently: Bitlocker drive encryption
+\item Automatic provisioning tools, but \textbf{do not use}
+\begin{itemize}
+\item Do not meet security recommendations
+\item Reports of incompatibility with anything but Bitlocker
+\end{itemize}
+\end{itemize}
+\item Wave Software does enterprise TPM integration
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Programming for the TPM}
+
+Two primary approaches:
+\begin{itemize}
+\item Trusted Software Stack
+\begin{itemize}
+\item ``High-level'' (C) API for TPM; back end handles some complexity
+\item TrouSerS on Linux
+\end{itemize}
+\item Driver-level coding
+\begin{itemize}
+\item Byte arrays for TPM's direct consumption, or close to it
+\item Microsoft's Trusted Base Services
+\item Flicker
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Advantages of Each Approach}
+
+TSS:
+\begin{itemize}
+\item C API allows integration at many applications' level
+\item Manages authorization sessions, keys for you
+\item Book about how to use it!
+\end{itemize}
+
+Driver-level:
+\begin{itemize}
+\item TPM spec (while complicated) relatively well-defined
+\item Very clean if comfortable working at low level
+\item For simple applications, much lower overhead
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Downsides to Each Approach}
+
+TSS:
+\begin{itemize}
+\item Spec is \textit{even more complicated} than TPM, and less well-written
+\item Multiple abstraction levels, unclear how to use
+\item High overhead for even simple applications
+\item Debugging extremely difficult
+\end{itemize}
+
+\medskip
+
+Driver-level:
+\begin{itemize}
+\item Managing nonces and authorization sessions complicated and fragile
+\item Lower-level than many applications
+\item Difficult to read and debug unless driver or kernel programmer
+\item Only documentation is TPM spec
+\item Debugging extremely difficult
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Drilling Down (Slightly)}
+
+\begin{itemize}
+\item TSS
+\item Driver-level
+\end{itemize}
+
+Note: Either of these could be a multi-day course on its own!
+
+\end{frame}
+
+\begin{frame}{The Trusted Software Stack}
+
+\begin{itemize}
+\item Spec from TCG; intended to be standard interface to TPM
+\item ``TSS'' really refers to two pieces:
+\begin{itemize}
+\item API for coding for the TSS
+\item Back-end driver which exports API, handles TPM communications
+\end{itemize}
+\item Working implementations:
+\begin{itemize}
+\item TrouSerS (Linux; buggy port to Windows 7)
+\begin{itemize}
+\item \texttt{trousers} package in most standard Linux distributions
+\end{itemize}
+\item NTRU stack (Windows XP; port to Windows 7 not yet well tested)
+\item ...neither perfect, but fairly reliable
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{What the TSS Does For You}
+
+\begin{itemize}
+\item Authorization Sessions
+\begin{itemize}
+\item Associate passwords with keys, other resources
+\item In some implementations, secure password input
+\end{itemize}
+\item Basic Key Management
+\begin{itemize}
+\item Swap keys out when TPM out of space 
+\begin{itemize}
+\item Rarely necessary feature today
+\end{itemize}
+\item In some implementations, stores created keys in internal store
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{TSS Code: Example (incomplete!)}
+
+\begin{verbatim}
+result = Tspi\_Context\_Create( \&hContext);
+
+result = Tspi\_Context\_Connect(hContext, NULL);
+
+// Get the TPM handle
+
+result=Tspi\_Context\_GetTpmObject(hContext,
+&hTPM);
+
+// Get the SRK handle
+
+result=Tspi\_Context\_LoadKeyByUUID(hContext,
+
+TSS\_PS\_TYPE\_SYSTEM, SRK\_UUID, \&hSRK);
+
+//Get the SRK policy
+
+result = Tspi\_GetPolicyObject(hSRK,
+
+TSS\_POLICY\_USAGE, \&hSRKPolicy);
+
+//Then set the SRK policy to be the well known secret
+
+result=Tspi\_Policy\_SetSecret(hSRKPolicy,
+
+TSS\_SECRET\_MODE\_SHA1, 20, wks);
+
+result=Tspi\_Context\_CreateObject(hContext,
+
+TSS\_OBJECT\_TYPE\_RSAKEY,initFlags, \&hESS\_Bind\_Key );
+
+result=Tspi\_Key\_CreateKey(hESS\_Bind\_Key,hSRK, 0);
+\end{verbatim}
+
+\end{frame}
+
+\begin{frame}{Learning to Code with the TSS}
+
+\begin{itemize}
+\item Resources exist!
+\item Dave Challener (author of much of TSS spec) wrote book:\\ \textit{A Practical Guide to Trusted Computing}
+\item Has also taught short workshops whose materials are online
+\begin{itemize}
+\item On your quick reference sheet
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{Drilling Down}
+
+\begin{itemize}
+\item TSS
+\item {\color{red}Driver-level}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Driver Level Variations}
+
+Nothing so coordinated as TSS standard!
+
+\begin{itemize}
+\item Used when in extremely minimal environments
+\begin{itemize}
+\item Flicker: running in CPU secure mode, stripped down
+\end{itemize}
+\item Windows 7 native support: TBS
+\begin{itemize}
+\item TBS is (theoretically) a direct pass-through to TPM
+\item \textbf{TBS modifies code unpredictably! Serious problem.}
+\end{itemize}
+\item Homebrew your own driver!
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Driver-Level Coding, In Brief}
+
+\begin{itemize}
+\item Assemble your data structures, based on TPM structures spec
+\item Assemble your command blob, based on TPM command spec
+\item Send to TPM
+\item Deconstruct response blob, based on TPM command spec
+\item Deconstruct relevant data structures, based on TPM structures spec
+\item Interpret and use as needed
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Driver-Level Code: Example}
+
+\begin{verbatim}
+
+int slb\_TPM\_Extend(unsigned char *buffer,
+
+               unsigned long pcrindex, unsigned char *hash)\{
+
+int res;
+    
+    ((unsigned int *)buffer)[0] = 0x0000c100;
+
+    ((unsigned int *)buffer)[1] = 0x00002200; /* length = 34 */
+
+    ((unsigned int *)buffer)[2] = 0x00001400;
+
+    *((unsigned int *) (buffer+10))=ntohl(pcrindex);
+  
+  TPM\_COPY\_TO(hash, 4, TCG\_HASH\_SIZE);
+    
+    res = slb\_tis\_transmit(buffer, 34, TCG\_BUFFER\_SIZE, 
+
+TIS\_LOCALITY\_2);
+
+    TPM\_COPY\_FROM(hash, 0, TCG\_HASH\_SIZE);
+
+    return res < 0 ? res : (int) ntohl(*((unsigned int *) 
+
+(buffer+6)));\}
+
+\end{verbatim}
+ %% Flicker sample code
+\tiny{Code copyright Jon McCune and Bernhard Kauer, released under GPL 2} 
+\end{frame}
+
+
+\begin{frame}{The Simple TPM API: A Sales Pitch}
+
+\begin{itemize}
+\item Adoption severely slowed by difficulty of use
+\item The vast majority of applications use a fraction of TPM commands
+\item No need for full range of options
+\begin{itemize}
+\item Just build in recommended choices-- advanced users can brew their own
+\end{itemize}
+\item Make conceptually atomic actions take one command
+\begin{itemize}
+\item Hide key handling; hide authorization sessions; hide intermediate steps
+\end{itemize}
+\item Use TPM at the level people understand it
+\end{itemize}
+
+Straightforward project; just needs someone to do it.
+
+\end{frame}
+
+
+\begin{frame}{TPM Programming Summary}
+
+\begin{itemize}
+\item No good choices today!
+\begin{itemize}
+\item TSS overcomplicated and high overhead
+\item Driver-level API overcomplicated, extremely low-level
+\end{itemize}
+\item Support architectures exist, but not universally
+\begin{itemize}
+\item Windows support particularly patchy
+\end{itemize}
+\item Lots of room for improvement, and vendors
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Questions?}
+
+\end{frame}
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/provisioning.tex

@@ -0,0 +1,575 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usepackage{color}
+\usepackage{dingbat}
+\usetheme{Madrid}
+
+\title[TPM Provisioning]{TPM Provisioning}
+\author{Ariel Segall \\ ariels@alum.mit.edu}
+%\institute{MITRE Corporation}
+\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}
+
+\begin{itemize}
+\item What do we mean by provisioning?
+\item Turning on the TPM
+\item The Endorsement Key: Theory vs. Reality
+\item Provisioning TPM Keys
+\item Certifying the EK (and other variations)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{What is TPM Provisioning?}
+
+In short: getting the TPM ready to use.
+
+\medskip
+
+Several components; not all required in all cases
+\begin{itemize}
+\item Turning the TPM on
+\item Making sure it has an Endorsement Key
+\item Making sure it has an Endorsement Credential
+\item Taking ownership
+\item Creating any initial keys 
+\item Certifying these keys
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Why Provisioning Matters}
+
+We can do all kinds of wonderful things by rooting trust in hardware. But:
+
+\medskip
+
+\textbf{How do we know we're actually communicating with the TPM?}
+
+\medskip
+
+Provisioning is how we establish trust in the TPM itself.
+
+\medskip
+
+\textbf{\color{red} If provisioning is not done properly, an adversary
+  can undetectably pretend to be our TPM.}
+
+\end{frame}
+
+\begin{frame}{Where Trust is Established}
+
+\begin{itemize}
+\item We prove that we are talking to the TPM using keys.
+\item All of our trust is rooted in \textbf{the association of a key with the TPM}.
+\item The TPM has capabilities for certifying new keys, given a root key.
+\item \textbf{Security is essential when provisioning and certifying the root key}.
+\item Other steps in the provisioning process, like turning on the TPM, are less sensitive.
+\begin{itemize}
+\item If we're wrong about having turned it on, just a DoS
+\item No loss of trust in the TPM
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+
+\begin{itemize}
+\item What do we mean by provisioning?
+\item {\color{red}Turning on the TPM}
+\item The Endorsement Key: Theory vs. Reality
+\item Provisioning TPM Keys
+\item Certifying the EK (and other variations)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Turning on the TPM}
+
+\begin{itemize}
+\item TPMs are turned on in the BIOS menu.
+\item Each BIOS varies in location
+\begin{itemize}
+\item Common: ``Security'', ``TPM Security'', ``Security Chip''
+\end{itemize}
+\item TPM technically has two different versions of ``on/off'':
+\begin{itemize}
+\item Activated/Deactivated
+\item Enabled/Disabled
+\end{itemize}
+\item To use the TPM, it must be both Activated and Enabled. 
+\begin{itemize}
+\item Some BIOSes group these into a single option.
+\end{itemize}
+\item A few systems require multiple reboots to turn the TPM on.
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Aside: Clearing the TPM}
+
+\begin{itemize}
+\item Some BIOSes also provide a \textbf{Clear} option for the TPM
+\item Clearing the TPM erases the Storage Root Key and owner
+\begin{itemize}
+\item This makes all keys and encrypted data useless!
+\end{itemize}
+\item Normally used before transferring machine to new owner
+\item Some BIOSes automatically turn the TPM off after clearing.
+\end{itemize}
+
+\textbf{If your BIOS offers a Clear option, adding a BIOS password reduces the risk of an accidental DoS.}
+
+\end{frame}
+
+\begin{frame}{Demo: Turning on a TPM in the BIOS}
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+
+\begin{itemize}
+\item What do we mean by provisioning?
+\item Turning on the TPM
+\item {\color{red}The Endorsement Key: Theory vs. Reality}
+\item Provisioning TPM Keys
+\item Certifying the EK (and other variations)
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Review and Expand: Endorsement Key}
+
+\begin{itemize}
+\item EK is root key for reporting
+\item TPM's unique identifier
+\item Only directly used to establish trust in TPM identities
+\begin{itemize}
+\item ..but identities certify all other keys and sign TPM reports
+\end{itemize}
+\item Source of all remote trust in TPM
+\begin{itemize}
+\item ``EK belongs to good TPM; key K in same TPM as EK; so trust K''
+\item ``K belongs to good TPM, so PCR quote is reliable''
+\item All comes back to EK!
+\end{itemize}
+\item Generally last lifetime of TPM
+\begin{itemize}
+\item Revokable EKs are in spec, but not always implemented
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Endorsement Key, According to the TCG}
+According to the TPM spec:
+\begin{itemize}
+\item The TPM manufacturer creates the TPM's EK as part of manufacturing
+\begin{itemize}
+\item Unique to each TPM and secret; process not specified
+\end{itemize}
+\item Each TPM is shipped with an \textit{Endorsement Credential (EC)} in NVRAM
+\begin{itemize}
+\item Signed by manufacturer
+\item Claim: ``I created this TPM, and this is its root key''
+\item Anyone can verify to trust TPM if they trust manufacturer
+\end{itemize}
+\item TPMs can be trusted immediately, by tracing keys back to EK
+\end{itemize}
+
+\medskip
+
+\begin{center}
+\onslide<2-> Reality is somewhat different.
+\end{center}
+\end{frame}
+
+\begin{frame}{The Endorsement Key, Today}
+
+\begin{itemize}
+\item Many TPM manufacturers do not include an EK at all.
+\begin{itemize}
+\item \onslide<2->{\textbf{EK must be created during provisioning.}}
+\end{itemize}
+\item Most TPM manufacturers that do include an EK do not include EC
+\begin{itemize}
+\item \onslide<2->{\textbf{New or not, EK must be certified during provisioning}}
+\end{itemize}
+\item If EC included, verification process unclear
+\end{itemize}
+
+\medskip
+
+\begin{center}
+For today's machines, we can't rely on the TCG process to establish EK trust.
+\end{center}
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+
+\begin{itemize}
+\item What do we mean by provisioning?
+\item Turning on the TPM
+\item The Endorsement Key: Theory vs. Reality
+\item {\color{red}Provisioning TPM Keys}
+\item Certifying the EK (and other variations)
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Provisioning Process}
+
+In brief:
+\begin{enumerate}
+\item Establish trusted environment
+\item Create EK, if necessary
+\item Record public EK for later certification
+\item Take ownership of TPM
+\item (Optional) Create additional TPM keys; save for later use
+\item (Optional) Record public half of additional keys for later certification
+\end{enumerate}
+
+
+\end{frame}
+
+\begin{frame}{Establishing a Trusted Environment (1/2)}
+
+\begin{itemize}
+\item Threat to avoid: malware or adversary masquerading as TPM
+\begin{itemize}
+\item Low risk, catastrophic damage-- all future trust undermined
+\end{itemize}
+\item Ideal: minimal, trusted, software; no network access
+\begin{itemize}
+\item Boot CD with minimal Linux, no network drivers
+\item Data transferred off via writeable CD
+\end{itemize}
+\item Enterprises sometimes require compromises
+\begin{itemize}
+\item Live CD requires technician running program on every machine:\\ high trust, high cost, hard to scale
+\item Script remotely run on windows: extremely low trust, but fast and scalable
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Establishing a Trusted Environment (2/2)}
+\textbf{Recommendation:}
+\begin{itemize}
+\item Use trusted process when machines first acquired
+\begin{itemize}
+\item IT department installing software anyway
+\item Low additional overhead, trained personnel
+\end{itemize}
+\item Use lower-security process for most machines in field
+\begin{itemize}
+\item Average machine has lifespan of only a few years
+\item Threat often not a big enough concern to warrant cost
+\end{itemize}
+\item Use high-security on-site process for critical machines
+\begin{itemize}
+\item Limited set; reduced scaling problems
+\item Maintain maximal trust where it matters most
+\end{itemize}
+\item \textbf{Certify with different keys, so low-trust machines can be phased out easily over time}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Provisioning Process}
+
+In brief:
+\begin{enumerate}
+\item Establish trusted environment $\checkmark$
+\item Create EK, if necessary
+\item Record public EK for later certification
+\item Take ownership of TPM
+\item (Optional) Create additional TPM keys; save for later use
+\item (Optional) Record public half of additional keys for later certification
+\end{enumerate}
+
+
+\end{frame}
+
+\begin{frame}{Creating the Endorsement Key}
+
+  \begin{itemize}
+  \item \texttt{TPM\_CreateEndorsementKeyPair}
+    \begin{itemize}
+    \item Some platforms provide more user-friendly tools
+      \begin{itemize}
+      \item \texttt{tpm\_createek} command line tool in linux tpm-tools package
+      \end{itemize}
+    \item Creates EK permanent for life of TPM
+    \item \textbf{Usually used}
+    \end{itemize}
+  \item \texttt{TPM\_CreateRevocableEK}
+    \begin{itemize}
+    \item Optional command; some TPMs may not support it
+    \item No convenient preexisting utilities
+    \item Creates EK which can be revoked using authorization set at creation
+    \item Tradeoffs: more control over TPM history, but opens DoS avenue
+    \end{itemize}
+  \item Either command will produce an error if an EK already exists.
+  \end{itemize}
+  
+\end{frame}
+
+\begin{frame}{The Provisioning Process}
+
+In brief:
+\begin{enumerate}
+\item Establish trusted environment $\checkmark$
+\item Create EK, if necessary $\checkmark$
+\item Record public EK for later certification
+\item Take ownership of TPM
+\item (Optional) Create additional TPM keys; save for later use
+\item (Optional) Record public half of additional keys for later certification
+\end{enumerate}
+
+
+\end{frame}
+
+\begin{frame}{Retrieving the Public EK}
+
+\begin{itemize}
+\item \texttt{TPM\_ReadPubek}
+\begin{itemize}
+\item Retrieves public portion of Endorsement key
+\begin{itemize}
+\item No way to retrieve private portion!
+\end{itemize}
+\item Must be executed before ownership is taken!
+\begin{itemize}
+\item The public EK can be read later, but much more complicated
+\end{itemize}
+\end{itemize}
+\item Public EK must be saved for transfer to CA
+\item \textbf{Recommend human write down key fingerprint for verification}
+\begin{itemize}
+\item Or other out-of-band mechanism to make sure saved key is the one certified
+\end{itemize}
+\item Note: Public EK is (as name suggests) not secret: we only care
+  about integrity
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Provisioning Process}
+
+In brief:
+\begin{enumerate}
+\item Establish trusted environment $\checkmark$
+\item Create EK, if necessary $\checkmark$
+\item Record public EK for later certification $\checkmark$
+\item Take ownership of TPM
+\item (Optional) Create additional TPM keys; save for later use
+\item (Optional) Record public half of additional keys for later certification
+\end{enumerate}
+
+
+\end{frame}
+
+\begin{frame}{Taking Ownership (1/2)}
+
+When taking ownership, two authorization values (passwords) are set:
+
+\begin{itemize}
+\item An owner authorization value 
+\begin{itemize}
+\item Used to change TPM configuration, create identities
+\item Less security critical than, e.g., root password
+\item Enterprises may wish to use standard values to simplify management
+\item Owner privileges can be individually delegated if access needed
+\end{itemize}
+\item A SRK authorization value
+\begin{itemize}
+\item Called for whenever the SRK is used\ldots which is often!
+\item Unless you're doing something unusual, \textit{every time you load another TPM key}.
+\item \textbf{Strongly recommend using the well-known secret}
+\begin{itemize}
+\item Effectively, no password.
+\end{itemize}
+\item If you want to protect data with a password, create another key later.
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Taking Ownership (2/2)}
+
+\begin{itemize}
+\item \texttt{TPM\_TakeOwnership}
+\item Linux utility tpm\_takeownership exists in tpm-tools package
+\item Windows 7 has a utility that will enable the TPM and take ownership, but:
+\begin{itemize}
+\item \textbf{There are reports that taking ownership with the Windows utility will result in a TPM unable to be used by anything except Bitlocker.}
+\end{itemize}
+\item Taking ownership creates the SRK and set the owner authorization.
+\item Owner remains until TPM is cleared, although auth can be changed.
+
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{The Provisioning Process}
+
+In brief:
+\begin{enumerate}
+\item Establish trusted environment $\checkmark$
+\item Create EK, if necessary $\checkmark$
+\item Record public EK for later certification $\checkmark$
+\item Take ownership of TPM $\checkmark$
+\item (Optional) Create additional TPM keys; save for later use
+\item (Optional) Record public half of additional keys for later certification
+\end{enumerate}
+
+
+\end{frame}
+
+\begin{frame}{Creating Additional TPM Keys}
+
+How of key creation later. For now: Why?
+
+\begin{itemize}
+\item Creating keys during provisioning can be practical
+\begin{itemize}
+\item Identity keys require owner approval; easiest now if owner is IT
+\item Can create and put in standard locations for apps
+\item Can make sure all users have standard utility set
+\end{itemize}
+\item Can shortcut key certification
+\begin{itemize}
+\item \textit{Not recommended long-term approach!} Not scalable.
+\item Key certification complicated-- more on that later
+\item Already doing direct certification of EK; can certify other keys
+  as well with no decrease in trust
+\item \textit{In this case}, public halves of keys should be recorded
+for certification
+\item As with the EK, a fingerprint or other verification mechanism recommended.
+\end{itemize}
+\item No keys other than EK, SRK required!
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{The Provisioning Process}
+
+In brief:
+\begin{enumerate}
+\item Establish trusted environment $\checkmark$
+\item Create EK, if necessary $\checkmark$
+\item Record public EK for later certification $\checkmark$
+\item Take ownership of TPM $\checkmark$
+\item (Optional) Create additional TPM keys; save for later use $\checkmark$
+\item (Optional) Record public half of additional keys for later certification $\checkmark$
+\end{enumerate}
+
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+
+\begin{itemize}
+\item What do we mean by provisioning?
+\item Turning on the TPM
+\item The Endorsement Key: Theory vs. Reality
+\item Provisioning TPM Keys
+\item {\color{red} Certifying the EK (and other variations)}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Certifying the EK}
+
+We currently have:
+\begin{itemize}
+\item A TPM with an uncertified EK
+\item A public EK with verification mechanism
+\end{itemize}
+
+We want to create an Endorsement Credential:
+\begin{itemize}
+\item Certificate claiming EK is Endorsement Key of legit TPM
+\item Signed by enterprise CA
+\item Containing relevant info about TPM
+\begin{itemize}
+\item e.g., machine identifier, TPM manufacturer, version\ldots
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Challenges of EK Certification}
+
+\begin{itemize}
+\item Most commercial CAs expect x.509 certificate signing requests
+\begin{itemize}
+\item Self-signed request
+\item EK not capable of signing request! (Nor are most other TPM keys.)\
+\item Need to update CA to accept request based on good process
+\begin{itemize}
+\item No actual security loss- self-signing adds nothing to trust
+\end{itemize}
+\end{itemize}
+\item Certification, like provisioning, needs to guarantee association
+\begin{itemize}
+\item Is the public EK being certified the same was created?
+\item If sent over network, rewritable media: verify integrity
+\end{itemize}
+\end{itemize}
+
+Otherwise, certification is pretty standard.
+
+\end{frame}
+
+\begin{frame}{Certifying Non-EK Keys}
+
+\begin{itemize}
+\item Can establish trust in other provisioned keys in same way as EK
+\item Same challenges apply!
+\item Certificates should clearly establish key type
+\begin{itemize}
+\item Should not be possible to mistake for EK!
+\end{itemize}
+\item If multiple certification mechanisms used (more on this soon), distinguish provisioning-certified keys from cryptographically certified keys
+\begin{itemize}
+\item Just good practice! Allows better revocation if needed.
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Provisioning Review}
+
+\begin{itemize}
+\item Process to establish initial trust in TPM
+\item Performed in trusted environment for security
+\item Create and certify Endorsement Key
+\item Take ownership, creating SRK
+\item Optionally create other TPM keys
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Questions?}
+
+\end{frame}
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/quick-reference.tex

@@ -0,0 +1,178 @@
+\documentclass{article}
+
+\title{TPM Quick Reference}
+\author{Ariel Segall}
+
+
+	\addtolength{\oddsidemargin}{-.875in}
+	\addtolength{\evensidemargin}{-.875in}
+	\addtolength{\textwidth}{1.75in}
+
+	\addtolength{\topmargin}{-.875in}
+	\addtolength{\textheight}{1.75in}
+
+\begin{document}
+\maketitle
+\begin{center}
+Approved for Public Release: 12-2749. Distribution unlimited \\ Licensed Creative Commons ``Share Alike'' http://creativecommons.org/licenses/by-sa/3.0
+\end{center}
+%% TODO: pretty formatting
+%\begin{center}
+%\LARGE{TPM Quick Reference}
+
+%\medskip
+
+%\Large{Ariel Segall}
+%\end{center}
+
+\section{Cryptographic Terms}
+
+\begin{description}
+\item[Nonce] A freshly generated random value used to prove recency
+\item [Symmetric Key] A key used for cryptographic algorithms based on shared secrets. Good for cases where speed matters, but both parties must possess the secret. \textit{The TPM does not provide symmetric encryption functionality.}
+\item [Asymmetric Key] A key (technically, a key \textbf{pair}) used for cryptographic algorithms where only one party possesses a secret. Excellent security properties, but relatively slow. Also known as ``public key pair'', since the algorithms are often referred to as ``public key cryptography''. In TPM contexts, these are almost always RSA keys.
+\item[Public Key] The half of an asymmetric key pair that can be freely provided to other people. Used for encryption and verification of signatures.
+\item[Private Key] The half of an asymmetric key pair that must be kept secret. Used for decryption and signing.
+\item[CA (Certificate Authority)] Trusted entity which issues certificates for keys. Usually run by an enterprise.
+\item [Hash] A function that turns arbitrary data into a short, constant-length chunk of output data (also known as a hash). The critical features of hashes are that they are \textbf{one-way} (it is computationally infeasible to calculate the original data from the hash) and \textbf{collision resistant} (it is extremely difficult to find two pieces of source data that hash to the same result).
+\item [Denial of Service (DoS)] A general term for an attack or system failure which causes a particular service to be unavailable. Impossible to completely prevent; do not imply a loss of future security.
+\item [Man in the Middle] An attack where an adversary forwards messages between two honest parties resulting in false security assumptions; usually, the adversary can masquerade as one of the parties. 
+\end{description}
+
+\section{Trusted Computing Terms}
+
+%% TODO: alphebetize
+
+\begin{description}
+
+
+\item [AIK (Identity Key, Attestation Identity Key)] A key which can be used to sign reports from the TPM, including quotes and CertifyKey certificates. A TPM can have many identities; only the TPM owner and owner-approved parties can create identities.
+\item [AR] Access Requestor: TNC term for client machine seeking network access
+\item [Attestation] The act of providing verifiable evidence (usually
+  about a machine or its software state) to a remote party. In
+  \textit{mutual attestation}, two or more parties provide evidence to
+  each other. Attestation is usually the first step in more complex
+  transactions, used to establish trust.
+\item [Attester] The participant providing evidence during an
+  attestation.
+\item [Bind] An operation which encrypts data using a TPM binding key. Bound data does not have PCR constraints, although binding keys can for similar effect. Bound data can be created locally or remotely.
+\item [DRTM (Dynamic Root of Trust for Measurement)] A RTM that is part of the CPU or its firmware; called dynamic because, unlike a BIOS, it measures and launches whatever is provided to it, and can be run more than once per boot.
+\item [EK (Endorsement Key)] The key that acts as the RTR for the TPM. An asymmetric key used only to certify AIKs.
+\item [Extend] The only operation which adds data to a PCR. The current value is hashed with the additional data; the result is the new value of the PCR.
+\item [Late Launch] A term used to describe systems which use the DRTM to avoid trusting the BIOS, boot loader, and other standard early system components. The ``late launch'' here refers to the launch of trusted software, such as an OS or hypervisor, via the DRTM.
+\item [Migratable] Migratable keys can be ``migrated'' off of a given TPM by encrypting them with another key, usually (but not always) a key belonging to a different TPM.
+\item [Non-Migratable] Non-migratable keys will always be locked to a given TPM, and will only exist in the clear within that TPM's internal memory.
+\item [NVRAM] Non-Volatile RAM (memory); the TPM's long-term internal storage. Very limited in size.
+
+\item [PCR (Platform Configuration Register)] A 20-byte register (region of memory) inside the TPM that always starts each boot at a known value, and which can be \textit{extended} and in some cases \textit{reset}. Used to store system measurements, among other things.
+\item [PDP] Policy Decision Point: TNC term for a machine which evaluates a network access request and decides whether or not to grant it, ideally based on attestation evidence.
+\item [PEP] Policy Enforcement Point: TNC term for gateway machine allowing or denying network access
+\item [Quote] A signed report of PCR contents in a special TPM format, using a nonce for freshness.
+\item [Reset] The operation which returns a PCR to a known value. Most PCRs are only reset when the system boots; some can be reset by software or hardware operations.
+\item [Root of Trust] A component that is assumed to be correct, and which can be used to establish trust in other components.
+
+\item [RTM (Root of Trust for Measurement)] The component which takes the first measurements of the system; see DRTM, SRTM.
+\item [RTR (Root of Trust for Reporting)] In the TPM context, the EK: the key which is responsible for providing the lowest-level identification of the platform. The EK is not directly used for system reporting, but ``reports'' on the identity keys, which are.
+\item [RTS (Root of Trust for Storage)] In the TPM context, the SRK: the key which is responsible for the security (encryption) of other keys or data, including other storage keys. 
+\item [Seal] An operation which encrypts data using a TPM storage key. Sealed data can have PCR constraints on when it can be opened, and records the PCR state when it was created. Only decryptable on the same machine it was encrypted on.
+\item [SRK (Storage Root Key)] The key that acts as the RTS for the TPM, created when ownership is taken. An asymmetric key used only to encrypt other keys or data.
+\item [SRTM (Static Root of Trust for Measurement)] A RTM that is part of the standard system boot process; static because what it measures never changes, and it always executes at the same stage of boot. The SRTM is a subset of the BIOS.
+\item [TBS (Trusted Base Services)] Windows 7's native interface for programming the TPM. Driver level; programmer must actually feed in byte strings according to TPM spec. \textbf{Not generally usable today}-- modifies commands in unpredictable ways.
+\item [TNC (Trusted Network Connect)] TCG architecture for network access control that supports attestation and trusted computing.
+\item [TPM (Trusted Platform Module)] Hardware chip soldered to the motherboard on most modern computers, providing a RTR and RTS as well as cryptographic functioanlity and storage.
+\item [TPM Key] Shorthand for an asymmetric key created by a TPM and
+  permanently bound to that TPM (non-migratable); its private half
+  will never exist in the clear outside the TPM.
+\item [TSS (Trusted Software Stack)] TCG-defined interface for
+  developers to use when writing software that uses the
+  TPM. C-level. Fairly solid implementations exist on Linux
+  (TrouSerS) and Windows XP (NTRU TSS). Windows 7 has unreliable ports, and may have hard-to-find commercial implementations from NTRU and/or Wave Systems.
+
+\item [Verifier (Appraiser)] The participant evaluating evidence during an attestation
+
+
+\end{description}
+
+\section{Where to Find More Information}
+
+Sadly, there are not yet any good, centralized resources for newcomers
+to trusted computing to use. 
+
+\paragraph{http://www.trustedcomputinggroup.org}
+The Trusted Computing Group is the largest organization in this field,
+and their website has by far the most information on trusted computing
+topics, including TPMs, TNC, and a wide variety of other
+technologies. However, the website has a very diverse audience and
+years' worth of content; many of the documents are aimed more at
+marketing than at technical information delivery. The ``Developer''
+sections are usually most helpful for implementers or people seeking
+technical details, and include specifications and some talks and
+whitepapers about how to use the relevant technologies. 
+
+%% Removed due to non-MITRE audience.
+%NOTE: MITRE is a consulting member of the TCG, which provides access
+%to workgroups and specifications still in progress.
+
+It's also worth noting that many TCG specifications are multi-part,
+because they're long; you will usually need all of the parts to make
+complete sense out of what's going on.
+
+\paragraph{Andrew Martin's Ten-Page Introduction to Trusted Computing}
+
+Andrew Martin is a professor at Oxford who's been doing trusted
+computing research for years. In response to the lack of introductory
+material in the field, he put together a ten-page introduction to
+trusted computing.
+
+www.cs.ox.ac.uk/files/1873/RR-08-11.PDF
+
+
+\paragraph{Books}
+
+David Grawrock's \textit{Dynamics of a Trusted Platform} is an
+extremely detailed book on the design and implementation of Intel's
+Trusted Execution Technology (TXT). It covers the goals and history of
+trusted computing, and does a very deep dive into the roots of trust
+for measurement as well as how the TPM interacts with the platform and
+CPU. Primarily useful for those planning on using the RTM, but can be
+useful for anyone wanting a low-level perspective on trusted
+computing.
+
+
+\subsection{Roots of Trust for Measurement}
+
+\paragraph{Flicker}
+
+Flicker is a project out of CMU which uses the RTM to perform limited,
+high-trust operations with TPM verification. Open source, with
+downloadable demonstration code and instructions for both Intel and
+AMD platforms.
+
+https://sparrow.ece.cmu.edu/group/flicker.html
+
+\subsection{Programming for the TPM}
+
+
+Dave Challener's \textit{Practical Guide to Trusted Computing} is the
+primary reference manual for anyone interested in programming for the
+TPM using the Trusted Software Stack. Contains demonstration code for
+a number of basic applications, and an introduction to the concepts
+and abstractions the TSS uses. Not perfect (some of the code is buggy,
+and attestation is not a use case that is covered at all) but better
+than anything else we have.
+
+Dave also taught a short session on TSS programming for the Trusted
+Infrastructure Workshop, whose slides and handout are publicly available:
+
+http://www.cylab.cmu.edu/tiw/slides/challener-TPM.pdf
+
+http://www.cylab.cmu.edu/tiw/slides/challener-handout.pdf
+
+Unfortunately, there are no guides to programming the TPM directly or
+via TBS. Some Flicker code uses this approach, and you can refer to
+that, but the best manual you'll have for this process is the TPM
+specification itself.
+
+
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/tpm-keys.tex

@@ -0,0 +1,444 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[TPM Keys]{TPM Keys\\ Creating, Certifying, and Using Them}
+\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}
+\begin{itemize}
+\item Creating TPM Keys
+\item Certifying TPM Keys
+\item Using TPM Keys
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Creating TPM Keys}
+
+First question: What kind of key do you need?
+
+\medskip
+
+Key creation is split into two:\footnote{Not \textit{quite} true,
+  but certifiable migratable keys are beyond the scope of this class.}:
+\begin{itemize}
+
+\item Identity key creation
+\item Everything else
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Quick Review: Types of TPM Keys}
+
+\begin{itemize}
+\item Identity (AIK): sign data from the TPM, such as quotes or certificates
+\begin{itemize}
+\item A TPM can have many identities!
+\end{itemize}
+\item Signing: sign user data
+\item Storage: encrypt data, including other keys
+\item Binding: decrypt data (usually from remote platforms)
+\item Legacy: signing or encryption
+\begin{itemize}
+\item Lower security for backwards compatibility; not recommended
+\item Only usable in some commands
+\item Not creatable in FIPS mode
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Quick Review: Types of TPM Keys}
+
+\begin{itemize}
+\item Identity (AIK): sign data from the TPM, such as quotes or certificates
+\begin{itemize}
+\item A TPM can have many identities!
+\end{itemize}
+\item {\color{red}Signing}: sign user data
+\item {\color{red}Storage}: encrypt data, including other keys
+\item {\color{red}Binding}: decrypt data (usually from remote platforms)
+\item {\color{red}Legacy}: signing or encryption
+\begin{itemize}
+\item Lower security for backwards compatibility; not recommended
+\item Only usable in some commands
+\item Not creatable in FIPS mode
+\end{itemize}
+\end{itemize}
+
+\begin{center}{\color{red}{Wrap keys!}}\end{center}
+\end{frame}
+
+\begin{frame}{Creating Wrap Keys}
+
+\begin{itemize}
+\item \texttt{TPM\_CreateWrapKey}
+\item Offers many choices
+\begin{itemize}
+\item Key type: Any except identity
+\item Key size: 512-2048 bits
+\item Authorization values to use, if any (key password)
+\item PCR and/or locality constraints, if any
+\item Migratable (can be exported) or non-migratable (this TPM only)
+\item Some key-specific options
+\begin{itemize}
+\item e.g., Signing keys have three signature scheme options
+\end{itemize}
+\end{itemize}
+\item Must provide a \textit{parent} key, already loaded into TPM
+\begin{itemize}
+\item Storage key that will be used to encrypt private portion
+\item SRK is a storage key!
+\end{itemize}
+\item Outputs a key blob, which user responsible for storing
+\end{itemize}
+\end{frame}
+
+
+\begin{frame}{Creating Identity Keys}
+
+\begin{itemize}
+\item \texttt{TPM\_MakeIdentity}
+\item TPM owner must authorize command!
+\item Only choices:
+\begin{itemize}
+\item Authorization values to use (key password)
+\item PCR and/or locality constraints, if any
+\item Privacy CA to create signing request for
+\begin{itemize}
+\item Privacy CAs in the next section
+\end{itemize}
+\end{itemize}
+\item All identity keys are created to meet minimum security requirements
+\begin{itemize}
+\item Non-migratable
+\item 2048 bits 
+\item SRK parent
+\end{itemize}
+\item Outputs key blob and certificate signing request
+\begin{itemize}
+\item Note: key blob same format as CreateWrapKey output!
+\item CSR is not x.509 standard; custom AIK certification protocol
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Key Storage Hierarchy Illustration}
+\includegraphics[width=4in]{key-storage-hierarchy}
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+\begin{itemize}
+\item Creating TPM Keys
+\item {\color{red}Certifying TPM Keys}
+\item Using TPM Keys
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Certifying TPM Keys}
+
+A very complex subject!
+
+\begin{itemize}
+\item TCG has well-designed, high-security, verifiable protocols
+\item Completely non-standard!
+\item Not supported by today's commercial CAs
+\item TPM keys \textit{cannot} participate in standard certification protocols
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Discussing Certification}
+
+\begin{itemize}
+\item Explore TCG's certification design
+\item Enterprise PKI and commercial CA expectations
+\item Compromises and recommendations
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{TCG Certification Vision}
+
+\begin{itemize}
+\item TPM EK certified by manufacturer
+\item Identity keys tied to EK with pseudonymizing PCA protocol
+\item Identity keys certify other TPM keys using CertifyKey certificates
+\item Strong cryptographic bindings at each step!
+\item TPM key heirarchies can be verified without CA interaction per-key 
+\end{itemize}
+
+\end{frame}
+
+
+
+\begin{frame}{PCA Protocol}
+\begin{center}
+\includegraphics[width=3.5in]{pca-protocol.pdf}
+\end{center}
+
+\vspace{-.25in}
+
+\begin{itemize}
+\item PCA: Privacy Certificate Authority
+\item Issues certificate for \textit{any} AIK if EK legitimate
+\begin{itemize}
+\item EK will only decrypt cert if AIK actually in TPM
+\item \texttt{ActivateIdentity} command decrypts certs
+\end{itemize}
+\item Only PCA (trusted party) can associate EK and AIK
+\begin{itemize}
+\item PCA cannot prove association unless sees cert
+\item Recipients cannot associate different AIKs from same TPM
+\end{itemize}
+\item Strong cryptographic binding between EK and AIK; pseudonymity
+
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{CertifyKey}
+
+\begin{itemize}
+\item \texttt{TPM\_CertifyKey} command: issue cert for TPM key
+\item Non-migratable keys only!
+\item Claim: ``This is a genuine TPM key with the following properties''
+\item Certificate includes:
+\begin{itemize}
+\item Key type
+\item Key length
+\item PCR and locality constraints
+\item \ldots i.e., anything a remote party would need to know to trust!
+\end{itemize}
+\item Signed by AIK
+\begin{itemize}
+\item Can be signed by signing or legacy key, but not trustworthy
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Key Certification Hierarchy Illustration}
+\includegraphics[width=4in]{tcg-cert-hierarchy}
+\end{frame}
+
+\begin{frame}{Discussing Certification}
+
+\begin{itemize}
+\item Explore TCG's certification design
+\item {\color{red}Enterprise PKI and commercial CA expectations}
+\item Compromises and recommendations
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{What Enterprises Generally Expect}
+
+\begin{itemize}
+\item x.509!
+\begin{itemize}
+\item Certificate Signing Requests are self-signed
+\item Certificates are public; CAs often publish them directly
+\end{itemize}
+\item World divided into CAs, which certify all keys; and other entities, which may not certify anything
+\item Standard protocols, supported by commercial CAs
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Where Problems Arise}
+
+\begin{itemize}
+\item Most TPM keys are incapable of creating a self-signed CSR
+\begin{itemize}
+\item Breaks x.509 request protocols
+\end{itemize}
+\item CA-published certificates would break PCA protocol entirely
+\begin{itemize}
+\item Security relies on the secrecy of the certificate until TPM decrypts
+\item A simple CSR format module isn't sufficient to fix
+\item PCA protocol only way to reliably certify AIKs post-provisioning!
+\end{itemize}
+\item TPM CertifyKey certificates break the model
+\begin{itemize}
+\item AIKs are CAs, but only for this TPM
+\item Completely non-standard format to boot: apps won't recognize
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Discussing Certification}
+
+\begin{itemize}
+\item Explore TCG's certification design
+\item Enterprise PKI and commercial CA expectations
+\item {\color{red}Compromises and recommendations}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Solving Certification: Temporary Patch}
+
+\begin{itemize}
+\item Keys of any type can be certified during provisioning
+\begin{itemize}
+\item Modular CA update: non-self-signed CSRs
+\item Some CAs support variations already
+\end{itemize}
+\item Must be implemented regardless, for certifying EKs!
+\item Equally trustworthy, if done at same time in same environment
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Solving Certification: Longer Term}
+
+\begin{itemize}
+\item Add extensions to commercial CAs to support PCA protocol
+\begin{itemize}
+\item Or separate CA operating in non-standard mode
+\end{itemize}
+\item Add CA extension that treats CertifyKey certs as special CSRs
+\begin{itemize}
+\item Issue x.509 certs based on verified CertifyKey certs
+\item Include CertifyKey info or even full cert
+\item Aware apps can utilize; legacy apps can ignore
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{What We'll Be Covering}
+\begin{itemize}
+\item Creating TPM Keys
+\item Certifying TPM Keys
+\item {\color{red}Using TPM Keys}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Using TPM Keys}
+
+\begin{itemize}
+\item We will \textit{not} be covering what to use each key for yet.
+\begin{itemize}
+\item Specialized per key; we'll cover in detail tomorrow
+\end{itemize}
+\item This section just covers common techniques for using any TPM key
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Quick Review: Key Storage}
+
+\begin{itemize}
+\item The EK is stored in the TPM permanently
+\begin{itemize}
+\item Never used directly
+\end{itemize}
+\item The SRK is stored in the TPM permanently
+\begin{itemize}
+\item Predefined location in key storage
+\end{itemize}
+\item Other keys (identity, wrap) are stored in partially-encrypted blobs on disk
+\begin{itemize}
+\item ``Disk'' is generalization-- anywhere outside the TPM will work
+\item For some apps, might not even be local to machine!
+\end{itemize}
+\begin{itemize}
+
+\end{itemize}
+
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Loading Keys (1/2)}
+
+In order for a key to be used, it must first be loaded into the TPM.
+
+\begin{itemize}
+\item Loading decrypts the private half and places it in volatile storage
+\item User receives a \textit{key handle} pointing to the key's location
+\item Handle can be provided for any future commands using the key
+\item \textit{Handles are volatile}.
+\begin{itemize}
+\item Keys may be removed from storage on reboot
+\item Keys cycled out if key storage filled
+\end{itemize}
+\item Most TPM services do behind-the-scenes key and handle management, but keys must still be explicitly loaded to use
+\begin{itemize}
+\item As a result, handle manipulation is a potential attack
+\item Recommend not reusing authorization values for high-value keys
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\begin{frame}{Loading Keys (2/2)}
+
+\begin{itemize}
+\item \texttt{TPM\_LoadKey2}\footnote{LoadKey deprecated}
+\item Two arguments: the key (blob) to be loaded, and the parent
+\begin{itemize}
+\item Parent is handle of an already loaded key (often SRK)
+\item Used to decrypt private half
+\end{itemize}
+\item TPM performs integrity and sanity checks, then loads key and returns handle
+\item Important note: This counts as using the \textbf{parent}, not the key being loaded
+\begin{itemize}
+\item Constraints on keys, like PCR values, are checked on use
+\item A key can be loaded if constraints are violated; just can't do anything
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Using Keys}
+
+\begin{itemize}
+\item Once a key is loaded, the handle may be provided to other TPM commands
+\item Many TPM commands will only accept certain kinds of keys
+\begin{itemize}
+\item Cannot sign with a storage key, or use signing key as parent
+\end{itemize}
+\item Every time a key is used:
+\begin{itemize}
+\item Any PCR constraints must be met
+\item Any locality constraints must be met 
+\item Any authorization data must be provided
+\end{itemize}
+\end{itemize}
+
+For the rest of the class, when we say ``Use a X key'', we mean ``Have
+an X key, load it, and provide it to the relevant command''.
+
+\end{frame}
+
+\begin{frame}{Questions?}
+\end{frame}
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/tpm-misc.tex

@@ -0,0 +1,348 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[Other TPM Features]{Using the TPM:\\ Other TPM Features}
+\author{Ariel Segall \\ ariels@alum.mit.edu}
+%\institute{\copyright MITRE Corporation 2012}
+\date{Day 2\\ \bigskip Approved for Public Release: 12-2749. \\Distribution unlimited}
+%\date{May 31, 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}{The Smorgasbord}
+
+The TPM has a number of minor features worth discussing
+\begin{itemize}
+\item Not significant enough for 101
+\item Too small for own talks
+\end{itemize}
+
+We'll briefly touch on several, so you'll be familiar with the concepts
+
+\end{frame}
+
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item Key Migration
+\item Monotonic Counters
+\item Tick Counters
+\item Random Number Generation
+\item OwnerEvict Keys
+\item Clearing the TPM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{TPM Flags}
+
+\begin{itemize}
+\item The TPM has a number of internal settings: ``flags'' 
+\item Values (mostly) changeable by owner or set by TPM
+\item Most are not very relevant to enterprise, e.g.:
+\begin{itemize}
+\item Ownership: determines whether an owner exists
+\item ReadPubEK: determines if EK pubkey can be read; for privacy
+\end{itemize}
+\item Some are potentially very important:
+\begin{itemize}
+\item \textbf{FIPS: Many TPM commands will require minimum good security practices}
+\item \textbf{nvLocked: Enables or disables all authorization checks on NVRAM}
+\end{itemize}
+\item Others are useful in unusal corner cases, e.g:
+\begin{itemize}
+\item CEKPUsed: Indicates if EK created by mfr process or TPM command
+\item disableOwnerClear: Determines whether owner can clear TPM
+\end{itemize}
+\item Full list in TPM Structures spec
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Getting and Setting TPM Flags}
+
+\begin{itemize}
+\item \texttt{TPM\_GetCapability}: Retrieves current value of a TPM
+  flag or other internal information, such as number of key slots
+  available, size of NVRAM, etc.
+\item \texttt{TPM\_SetCapability}: Owner-authorized command to change
+  flag values.
+\item Full list of capabilities and subcapabilities (i.e., indexes to flags and other information) in Structures spec, under \texttt{TPM\_CAPABILITY\_AREA}.
+\begin{itemize}
+\item What does that mean? We'll cover that this afternoon.
+\end{itemize}
+\item Note: When programming using TSS, there are actually more
+  commands that can be used to retrieve and set flags. We won't cover
+  those today.
+\end{itemize}
+
+\begin{center}
+\textbf{Some flags, including FIPS mode, are permanently set by the manufacturer.}
+\end{center}
+
+\end{frame}
+
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item {\color{red}Key Migration}
+\item Monotonic Counters
+\item Tick Counters
+\item Random Number Generation
+\item OwnerEvict Keys
+\item Clearing the TPM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Key Migration}
+
+\begin{itemize}
+\item In TPM keys talk, mentioned that keys could be migratable
+\item All other talks: use non-migratable keys!
+\item Key migration is a criticial feature for enterprise
+\begin{itemize}
+\item Backup
+\item System replacement
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Migration in a Nutshell}
+
+\begin{itemize}
+\item Create migratable key K on TPM A
+\item Create migration blob, reencrypting K to key on TPM B
+\begin{itemize}
+\item Requires authorization of owner, or delegated auth
+\item Note: B doesn't actually have to be a TPM, though designed to be
+\end{itemize}
+\item B decrypts blob; K now available to B.
+\end{itemize}
+
+Note: K still usable on A! This is backup approach.
+\end{frame}
+
+\begin{frame}{Migration: Starting State}
+\includegraphics[width=4in]{migration-illustration-1}
+\end{frame}
+
+\begin{frame}{Migration: Creating Migration Blob}
+\includegraphics[width=4in]{migration-illustration-2}
+\end{frame}
+
+\begin{frame}{Migration: Transferring Migration Blob}
+\includegraphics[width=4in]{migration-illustration-3}
+\end{frame}
+
+\begin{frame}{Migration: Decrypting Migration Blob}
+\includegraphics[width=4in]{migration-illustration-4}
+\end{frame}
+
+\begin{frame}{Certified Migration Keys (CMKs)}
+
+\begin{itemize}
+\item Normal migratable keys cannot be certified: could be migrated to non-TPM
+\item CMKs always migrate to migration authority, which verifies final destination
+\item Owner approves migration authorities for system
+\item Can be certified; cert includes authority info
+\item More complex than normal migration, but more assurance
+\end{itemize}
+
+
+\end{frame}
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item Key Migration
+\item {\color{red}Monotonic Counters}
+\item Tick Counters
+\item Random Number Generation
+\item OwnerEvict Keys
+\item Clearing the TPM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Monotonic Counters}
+
+\begin{itemize}
+\item TPMs provide monotonic counters
+\item Guaranteed to always increase over time
+\begin{itemize}
+\item When deliberately incremented-- not clocks
+\end{itemize} 
+\item Good for internal freshness checking!
+\begin{itemize}
+\item Counter values cannot be signed for external verification
+\item Can use to invalidate old saved data: include value, increment counter
+\end{itemize}
+\item Unlike NVRAM, burnout due to too many updates extremely unlikely
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item Key Migration
+\item Monotonic Counters
+\item {\color{red}Tick Counters}
+\item Random Number Generation
+\item OwnerEvict Keys
+\item Clearing the TPM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Tick Counters}
+
+\begin{itemize}
+\item TPM has no internal clock
+\item Closest equivalent: tick counters
+\item Count from start of last tick session
+\begin{itemize}
+\item Usually last startup, but not guaranteed
+\end{itemize}
+\item Combines counter with tick session nonce, allowing comparisons
+\begin{itemize}
+\item TPM will sign tick stamps-- use Identity!
+\item Approximate clock per boot
+\end{itemize}
+\item Surprisingly accurate!
+\begin{itemize}
+\item Intended primarily for short-term, relative comparisons
+\item Usable for timing-based attestation
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item Key Migration
+\item Monotonic Counters
+\item Tick Counters
+\item {\color{red}Random Number Generation}
+\item OwnerEvict Keys
+\item Clearing the TPM
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Random Number Generation}
+
+\begin{itemize}
+\item TPM can act as random number generator
+\begin{itemize}
+\item Frequent question: how good?
+\item Answer: Don't know, manufacturer dependent
+\item Hardware entropy recommended, not required
+\end{itemize}
+\item Bytes retrievable with \texttt{TPM\_GetRandom} command
+\item Entropy can be added from outside with \texttt{TPM\_StirRandom} command
+\begin{itemize}
+\item RNG used to create TPM keys
+\item Allows high-quality entropy to be imported for better key generation
+\end{itemize}
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item Key Migration
+\item Monotonic Counters
+\item Tick Counters
+\item Random Number Generation
+\item {\color{red} OwnerEvict Keys}
+\item Clearing the TPM
+\end{itemize}
+
+\end{frame}
+\begin{frame}{OwnerEvict Keys}
+ 
+\begin{itemize}
+\item We've previously said that loaded keys are unloaded on reboot,
+  or when the TPM runs out of key storage space.
+\item There is an exception: OwnerEvict Keys
+\begin{itemize}
+\item Currently loaded key; owner sets OwnerEvict flag on it.
+\item Key must not have any parent PCR constraints. (Constraints on key itself fine.)
+\item Key will never be unloaded until flag is changed by owner.
+\end{itemize}
+\item Very useful; no need to track key on disk or load!
+\item \textit{Very} limited; some TPMs have as few as 3 key slots.
+\item Use \texttt{TPM\_KeyControlOwner} command to set.
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Topics We'll Cover}
+
+\begin{itemize}
+\item TPM Flags
+\item Key Migration
+\item Monotonic Counters
+\item Tick Counters
+\item Random Number Generation
+\item OwnerEvict Keys
+\item {\color{red}Clearing the TPM}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Clearing the TPM}
+
+\begin{itemize}
+\item What does an enterprise do with TPM when disposing of machine?
+\item \textit{Clear} the TPM
+\item Two approaches:
+\begin{itemize}
+\item Through BIOS (ForceClear must be enabled; can be disabled temporarily)
+\item \texttt{TPM\_OwnerClear} command (must be enabled; once
+  disabled, stays until TPM cleared)
+\end{itemize}
+\item Erases all non-permanent data from TPM
+\begin{itemize}
+\item Owner erased, along with SRK
+\item Key storage cleared (in FIPS mode, overwritten with 0)
+\item Flags returned to default value
+\item Non-manufacturer NVRAM deallocated
+\item etc
+\end{itemize}
+\item Some things remain: EK, monotonic counter
+\begin{itemize}
+\item Also PCRs-- cannot clear TPM to fake boot state
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Questions?}
+
+\end{frame}
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/tpm-specs.tex

@@ -0,0 +1,106 @@
+\documentclass{beamer}
+\usepackage{graphicx}
+\usetheme{Madrid}
+
+\title[TPM Specifications]{Using the TPM Specifications}
+\author{Ariel Segall \\ ariels@alum.mit.edu}
+%\institute{\copyright MITRE Corporation 2012}
+\date{Day 2\\ \bigskip Approved for Public Release: 12-2749. \\Distribution unlimited}
+%\date{June 7-8, 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 are the Specifications?}
+
+\begin{itemize}
+\item TPM Main Part 1: Design Principles
+\item TPM Main Part 2: Structures
+\item TPM Main Part 3: Commands
+\end{itemize}
+
+\medskip
+
+Also potentially useful:
+\begin{itemize}
+\item PC Client TPM Specification
+\begin{itemize}
+\item Defines requirements for real-world TPM chips
+\item Which commands must be supported, what PCRs and localities mean, minimum sizes\ldots
+\end{itemize}
+\item TCG Softare Stack (TSS) Specification 
+\begin{itemize}
+\item If programming with the TSS
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Part 1: Design Principles}
+
+\begin{itemize}
+\item High-level context, such as architecture and goals
+\item Charts of how various commands and structures relate to each other
+\item Look here for:
+\begin{itemize}
+\item High-level overviews
+\item Architectural requirements (e.g., which components must be present)
+\item Manufacturing requirements (e.g., how good RNG must be)
+\item Behavioral requirements (e.g., dictionary attack prevention, when PCRs are checked)
+\end{itemize}
+\item Rarely contains comprehensive detail.
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Part 2: Structures}
+
+\begin{itemize}
+\item Data structure definitions, both internal to the TPM and passed to the TPM.
+\item Usually used in conjunction with Commands spec.
+\item \textbf{More important than it sounds.}
+\begin{itemize}
+\item Often, TPM commands will call for one meaningful argument that
+  is a structure
+\item That structure may contain many pieces of critical information
+\item \textbf{You cannot understand TPM commands without looking up all of the
+  data structures involved!}
+\item (Note: Many of them are multi-layered.)
+\end{itemize}
+
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Part 3: Commands}
+
+\begin{itemize}
+\item API definition for TPM
+\item The most useful spec for people designing TPM applications
+\begin{itemize}
+\item But keep in mind, you'll need Structures handy.
+\end{itemize}
+\item Generally well-grouped by command purpose; always read the
+  informative comments!
+\item Most commands have common overhead for authorization sessions
+\end{itemize}
+
+\end{frame}
+
+\begin{frame}{Example}
+
+\end{frame}
+
+\end{document}

references/IntroToTrustedComputing_full_10-24-2012/tpm101.tex

@@ -0,0 +1,945 @@
+\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}

references/IntroToTrustedComputing_full_10-24-2012/what-is-trusted-computing.tex

@@ -0,0 +1,172 @@
+\documentclass{beamer}
+\usetheme{Madrid}
+\usepackage{graphicx}
+%\setbeamertemplate{footline}[frame number]
+
+\title[What is Trusted Computing?]{What is Trusted Computing?}
+\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 is Trust?}
+
+According to the Trusted Computing Group\footnote{We'll get to them shortly}:
+
+\begin{center}
+\textit{A trusted component is one which is predictable.}
+\end{center}
+
+\begin{itemize}
+\item Trusted is not the same as good!
+\begin{itemize}
+\item But it gives us a foundation to build on
+\end{itemize}
+\item Two broad reasons to trust:
+\begin{itemize}
+\item Reliable evidence \onslide<2->{\textit{Attestation}}
+\item Out-of-band assumptions/No choice! \onslide<2->{\textit{Root of Trust}}
+\end{itemize}
+\end{itemize}
+
+\end{frame}
+
+
+\begin{frame}{What is Trusted Computing?}
+
+\begin{itemize}
+\item Not a precise term
+\item Generally, refers to systems that use hardware to provide security support to software
+\begin{itemize}
+\item Today: Trusted Platform Modules (TPMs); processors with secure modes (TXT,SVM) 
+\item Future: Mobile Trusted Modules (MTMs)
+\end{itemize}
+\item Also covers infrastructure relying on above
+\begin{itemize}
+\item Software applications
+\item Network Access Control (NAC)
+\item Secure storage devices
+\item etc...
+\end{itemize}
+
+\end{itemize}
+
+\medskip
+
+%\begin{center}
+ Goal: build trust in entire system for some purpose
+%\end{center}
+\end{frame}
+
+\begin{frame}{The Grand Trusted Computing Vision}
+
+\begin{itemize}
+\item Before logging into a computer, I know it's good.
+\item Machines that aren't up-to-date are routed to a DMZ to perform
+  updates before connecting to the network.
+\item Servers can confirm exactly which machines they're talking to
+  and whether they're running good software before providing sensitive
+  data.
+\item All of my data, including secret keys, are protected by
+  hardware and cannot be stolen over the network.
+\end{itemize}
+
+We're not there yet, but we're moving in the right direction.
+\end{frame}
+
+
+\begin{frame}{A High-Level Workstation View}
+
+\includegraphics[width=4in]{trusted-basics}
+
+\end{frame}
+
+
+\begin{frame}{Trusted NAC From 50,000 Feet}
+
+\includegraphics[width=4in]{tnc-highlevel}
+
+%aka ``Trusted Network Connect''
+\end{frame}
+
+
+\begin{frame}{The Trusted Computing Group (TCG)}
+
+\begin{itemize}
+\item Industry (mostly) consortium
+\item Defining standards for trusted computing
+\item Layered vision: starting from hardware, moving up to applications
+\item Workgroups focused on particular subsets of the problem; e.g:
+\begin{itemize}
+\item Technological: TPM, Mobile Solutions
+\item Interoperability: Infrastructure, Trusted Network Connect
+\item Use cases: Server, Trusted Multi-Tenant Infrastructure
+\end{itemize}
+\item www.trustedcomputinggroup.org
+\item Formerly the Trusted Computing Platform Alliance (TCPA)
+\end{itemize}
+
+Most technologies in this area are defined by or with the TCG.
+
+\end{frame}
+
+\begin{frame}{Why the TCG Matters}
+
+Sometimes we trust because we have no choice!
+\begin{itemize}
+\item TCG standards help define which components we must trust
+\item Standards can be evaluated to determine if we \emph{should} trust
+\item TCG has compliance programs
+\begin{itemize}
+\item Not government C&A, but better than nothing
+\end{itemize}
+\item Give us a foundation on which to build
+\end{itemize}
+
+Unfortunately, not very good at communicating with users.
+
+\end{frame}
+
+\begin{frame}{Trusted Computing Topics in This Class}
+
+\begin{itemize}
+\item Trusted Platform Modules
+\begin{itemize}
+\item The foundation most of the rest is built on
+\item Most of the technical meat of this class
+\end{itemize}
+\item Roots of Trust for Measurement
+\begin{itemize}
+\item With the TPM, what allow us to verify machine state
+\item Two kinds: static (BIOS) and dynamic (CPU)
+\end{itemize}
+\item Trusted Network Connect
+\begin{itemize}
+\item NAC protocol with trusted computing support
+\end{itemize}
+\item Not covered in detail:
+\begin{itemize}
+\item Storage: Too specialized
+\item Most infrastructure protocols: Too many!
+\end{itemize}
+\end{itemize}
+
+
+\end{frame}
+
+\end{document}