diff options
| -rw-r--r-- | html/integrity/concepts.html | 137 |
1 files changed, 136 insertions, 1 deletions
diff --git a/html/integrity/concepts.html b/html/integrity/concepts.html index 22b50d9..84cf15d 100644 --- a/html/integrity/concepts.html +++ b/html/integrity/concepts.html @@ -414,6 +414,141 @@ it took before. <p class="chaphead"><a name="doc_chap6"></a><span class="chapnum">6. </span>An implementation: the Trusted Computing Group functionality</p> <p class="secthead"><a name="doc_chap6_sect1">Trusted Platform Module</a></p> +<p> +Years ago, a non-profit organization called the <a href="http://www.trustedcomputinggroup.org">Trusted Computing Group</a> was +formed to work on and promote open standards for hardware-enabled trusted +computing and security technologies, including hardware blocks and software +interfaces across multiple platforms. +</p> +<p> +One of its deliverables is the <span class="emphasis">Trusted Platform Module</span>, abbreviated to +TPM, to help achieve these goals. But what are these goals exactly (especially +in light of our integrity project)? +</p> +<ul> + <li> + Support hardware-assisted record (measuring) of what software is (or was) + running on the system since it booted in a way that modifications to this + record (or the presentation of a different, fake record) can be easily + detected + </li> + <li> + Support the secure reporting to a third party of this state (measurement) so + that the third party can attest that the system is indeed in a sane state + </li> +</ul> +<p> +The idea of providing a hardware-assisted method is to prevent software-based +attacks or malpractices that would circumvent security measures. By running some +basic (but important) functions in a protected, tamper-resistant hardware module +(the TPM) even rooted devices cannot work around some of the measures taken to +"trust" a system. +</p> +<p> +The TPM chip itself does not influence the execution of a system. It is, in +fact, a simple request/reply service and needs to be called by software +functions. However, it provides a few services that make it a good candidate to +set up a trusted platform (next to its hardware-based protection measures to +prevent tampering of the TPM hardware itself): +</p> +<ul> + <li> + Asymmetric crypto engine, supporting the generation of asymmetric keys (RSA + with a keylength of 2048 bits) and standard operations with those keys + </li> + <li> + A random noise generator + </li> + <li> + A SHA-1 hashing engine + </li> + <li> + Protected (and encrypted) memory for user data and key storage + </li> + <li> + Specific registers (called PCRs) to which a system can "add" data to + </li> +</ul> +<p class="secthead"><a name="doc_chap6_sect2">Platform Configuration Registers, Reporting and Storage</a></p> +<p> +PCR registers are made available to support securely recording the state of +(specific parts of) the system. Unlike processor registers that software can +reset as needed, PCR registers can only be "extended": the previous value in the +register is taken together with the new provided value, hashed and +stored again. This has the advantage that a value stores both the knowledge of +the data presented to it as well as its order (providing values AAA and BBB +gives a different end result than providing values BBB and AAA), and that the +PCR can be extended an unlimited number of times. +</p> +<p> +A system that wants to securely "record" each command executed can take the hash +of each command (before it executes it), send that to the PCR, record the event +and then execute the command. The system (kernel or program) is responsible for +recording the values sent to the PCR, but at the end, the value inside +the PCR has to be the same as the one calculated from the record. If it differs, +then the list is incorrect and the "secure" state of the system cannot be proven. +</p> +<p> +To support secure reporting of this value to a "third party" (be it a local +software agent or a remote service) the TPM supports secure reporting of the PCR +values: an RSA signature is made on the PCR value as well as on a random +number (often called the "nonce") given by the third party (proving there is no +man-in-the-middle or replay attack). Because the private key of this signature +is securely stored on the TPM this signature cannot be forged. +</p> +<p> +The TPM chip has (at least) 24 PCR registers available. These registers will +contain the extended values for +</p> +<ul> + <li> + BIOS, ROM and memory block data (PCR 0-4) + </li> + <li> + OS loaders (PCR 5-7) + </li> + <li> + Operating System-provided data (PCR 8-15) + </li> + <li> + Debugging data (PCR 16) + </li> + <li> + Localities and Trusted Operating System data (PCR 17-22) + </li> + <li> + Application-specific data (PCR 23) + </li> +</ul> +<p> +The idea of using PCRs is to first <span class="emphasis">measure</span> the data a component is about +to execute (or transfer control to), then <span class="emphasis">extend</span> the appropriate PCR, +then <span class="emphasis">log</span> this event in a measurement log and finally <span class="emphasis">transfer +control</span> to the measured component. This provides a trust "chain". +</p> +<p class="secthead"><a name="doc_chap6_sect3">Trusting the TPM</a></p> +<p> +In order to trust the TPM, the TCG basis its model on asymmetric keys. Each TPM chip +has a 2048-bit private RSA key securely stored in the chip. This key, called the +<span class="emphasis">Endorsement Key</span>, is typically generated by the TPM manufacturer during +the creation of the TPM chip, and is backed by an Endorsement Key certificate +issued by the TPM manufacturer. This EK certificate guarantees that the EK is in +fact an Endorsement Key for a given TPM (similar to how an SSL certificate is +"signed" by a Root CA). The private key cannot leave the TPM chip. +</p> +<p> +A second key, called the <span class="emphasis">Storage Root Key</span>, is generated by the TPM chip +when someone takes "ownership" of the TPM. Although the key cannot leave the TPM +chip, it can be removed (when someone else takes ownership). This key is used to +encrypt data and other keys (user <span class="emphasis">Storage Keys</span> and <span class="emphasis">Signature +Keys</span>). +</p> +<p> +The other keys (storage and signature keys) can leave the TPM chip, but always +in an encrypted state that only the TPM can decrypt. That way, the system can +generate specific user storage keys securely and extract them, storing them on +non-protected storage and reload them when needed in a secure manner). +</p> <br><p class="copyright"> The contents of this document, unless otherwise expressly stated, are licensed under the <a href="http://creativecommons.org/licenses/by-sa/3.0">CC-BY-SA-3.0</a> license. The <a href="http://www.gentoo.org/main/en/name-logo.xml"> Gentoo Name and Logo Usage Guidelines </a> apply. @@ -436,7 +571,7 @@ it took before. </td> <td width="1%" bgcolor="#dddaec" valign="top"><table border="0" cellspacing="4px" cellpadding="4px"> <tr><td class="topsep" align="center"><p class="altmenu"><a title="View a printer-friendly version" class="altlink" href="swift?style=printable">Print</a></p></td></tr> -<tr><td class="topsep" align="center"><p class="alttext">Page updated July 30, 2012</p></td></tr> +<tr><td class="topsep" align="center"><p class="alttext">Page updated August 14, 2012</p></td></tr> <tr><td class="topsep" align="left"><p class="alttext"><b>Summary: </b> Integrity validation is a wide field in which many technologies play a role. This guide aims to offer a high-level view on what integrity validation is all |