diff options
| -rw-r--r-- | xml/integrity/concepts.xml | 165 |
1 files changed, 163 insertions, 2 deletions
diff --git a/xml/integrity/concepts.xml b/xml/integrity/concepts.xml index c8859f9..c9f6313 100644 --- a/xml/integrity/concepts.xml +++ b/xml/integrity/concepts.xml @@ -20,8 +20,8 @@ more secure environment to work in. <!-- See http://creativecommons.org/licenses/by-sa/3.0 --> <license version="3.0" /> -<version>1</version> -<date>2012-07-30</date> +<version>2</version> +<date>2012-08-14</date> <chapter> <title>It is about trust</title> @@ -517,6 +517,167 @@ it took before. <title>Trusted Platform Module</title> <body> +<p> +Years ago, a non-profit organization called the <uri +link="http://www.trustedcomputinggroup.org">Trusted Computing Group</uri> 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 <e>Trusted Platform Module</e>, 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> + +</body> +</section> +<section> +<title>Platform Configuration Registers, Reporting and Storage</title> +<body> + +<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 <e>measure</e> the data a component is about +to execute (or transfer control to), then <e>extend</e> the appropriate PCR, +then <e>log</e> this event in a measurement log and finally <e>transfer +control</e> to the measured component. This provides a trust "chain". +</p> + +</body> +</section> +<section> +<title>Trusting the TPM</title> +<body> + +<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 +<e>Endorsement Key</e>, 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 <e>Storage Root Key</e>, 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 <e>Storage Keys</e> and <e>Signature +Keys</e>). +</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> + </body> </section> </chapter> |