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

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