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

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