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