From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id A10151381F4 for ; Tue, 14 Aug 2012 20:01:47 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7978B21C0A7; Tue, 14 Aug 2012 20:01:35 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3DC1421C0A7 for ; Tue, 14 Aug 2012 20:01:35 +0000 (UTC) Received: from hornbill.gentoo.org (hornbill.gentoo.org [94.100.119.163]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 68BF41B4042 for ; Tue, 14 Aug 2012 20:01:34 +0000 (UTC) Received: from localhost.localdomain (localhost [127.0.0.1]) by hornbill.gentoo.org (Postfix) with ESMTP id 251BAE5440 for ; Tue, 14 Aug 2012 20:01:33 +0000 (UTC) From: "Sven Vermeulen" To: gentoo-commits@lists.gentoo.org Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=UTF-8 Reply-To: gentoo-dev@lists.gentoo.org, "Sven Vermeulen" Message-ID: <1344974482.f15f7783b17394b0ae51a51f111295bac3464221.SwifT@gentoo> Subject: [gentoo-commits] proj/hardened-docs:master commit in: html/integrity/ X-VCS-Repository: proj/hardened-docs X-VCS-Files: html/integrity/concepts.html X-VCS-Directories: html/integrity/ X-VCS-Committer: SwifT X-VCS-Committer-Name: Sven Vermeulen X-VCS-Revision: f15f7783b17394b0ae51a51f111295bac3464221 X-VCS-Branch: master Date: Tue, 14 Aug 2012 20:01:33 +0000 (UTC) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-commits@lists.gentoo.org X-Archives-Salt: 851c32c0-8cb0-406f-b79f-06d52baa5585 X-Archives-Hash: 6516bac3ba5c6d77eadec44bf712b85b commit: f15f7783b17394b0ae51a51f111295bac3464221 Author: Sven Vermeulen siphos be> AuthorDate: Tue Aug 14 20:01:22 2012 +0000 Commit: Sven Vermeulen siphos be> CommitDate: Tue Aug 14 20:01:22 2012 +0000 URL: http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-docs.git;a=commit;h=f15f7783 Update preview for concepts --- 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.

6. An implementation: the Trusted Computing Group functionality

Trusted Platform Module

+

+Years ago, a non-profit organization called the Trusted Computing Group 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. +

+

+One of its deliverables is the Trusted Platform Module, abbreviated to +TPM, to help achieve these goals. But what are these goals exactly (especially +in light of our integrity project)? +

+
    +
  • + 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 +
  • +
  • + 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 +
  • +
+

+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. +

+

+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): +

+
    +
  • + Asymmetric crypto engine, supporting the generation of asymmetric keys (RSA + with a keylength of 2048 bits) and standard operations with those keys +
  • +
  • + A random noise generator +
  • +
  • + A SHA-1 hashing engine +
  • +
  • + Protected (and encrypted) memory for user data and key storage +
  • +
  • + Specific registers (called PCRs) to which a system can "add" data to +
  • +
+

Platform Configuration Registers, Reporting and Storage

+

+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. +

+

+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. +

+

+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. +

+

+The TPM chip has (at least) 24 PCR registers available. These registers will +contain the extended values for +

+
    +
  • + BIOS, ROM and memory block data (PCR 0-4) +
  • +
  • + OS loaders (PCR 5-7) +
  • +
  • + Operating System-provided data (PCR 8-15) +
  • +
  • + Debugging data (PCR 16) +
  • +
  • + Localities and Trusted Operating System data (PCR 17-22) +
  • +
  • + Application-specific data (PCR 23) +
  • +
+

+The idea of using PCRs is to first measure the data a component is about +to execute (or transfer control to), then extend the appropriate PCR, +then log this event in a measurement log and finally transfer +control to the measured component. This provides a trust "chain". +

+

Trusting the TPM

+

+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 +Endorsement Key, 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. +

+

+A second key, called the Storage Root Key, 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 Storage Keys and Signature +Keys). +

+

+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). +