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