Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V48nR-00009w-RU; Tue, 30 Jul 2013 12:12:57 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.174 as permitted sender) client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f174.google.com; Received: from mail-ob0-f174.google.com ([209.85.214.174]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1V48nQ-0002l9-K7; Tue, 30 Jul 2013 12:12:57 +0000 Received: by mail-ob0-f174.google.com with SMTP id wd6so8564891obb.5 for ; Tue, 30 Jul 2013 05:12:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.141.36 with SMTP id rl4mr22637167oeb.43.1375186371203; Tue, 30 Jul 2013 05:12:51 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Tue, 30 Jul 2013 05:12:51 -0700 (PDT) In-Reply-To: <7B0891A4-7163-43AE-85EC-8BA7ADC28A2A@grabhive.com> References: <7B0891A4-7163-43AE-85EC-8BA7ADC28A2A@grabhive.com> Date: Tue, 30 Jul 2013 14:12:51 +0200 X-Google-Sender-Auth: Vj4C5FGRo-idaYbvDe2lu6iB400 Message-ID: From: Mike Hearn To: Wendell Content-Type: multipart/alternative; boundary=047d7b339fbf27d8c004e2b987c5 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1V48nQ-0002l9-K7 Cc: Bitcoin Dev , bitcoin-list@lists.sourceforge.net Subject: Re: [Bitcoin-development] BitMail - p2p Email 0.1. beta X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:12:58 -0000 --047d7b339fbf27d8c004e2b987c5 Content-Type: text/plain; charset=UTF-8 The TPM is a piece of secure* hardware that provides various cryptographic services to the host system. It is important to understand that it is not a crypto accelerator. It is a place to store keys and small pieces of data (like hashes, counters) where it's difficult for someone to extract them even if they have physical access. The TPM is designed to support trusted computing, a rather splendid set of extensions to the x86 architecture that let you do remote attestation, software sealing and other things. Or at least it would be splendid if it had been really finished off and pushed to completion by the designers. Unfortunately due to various political issues it exists in a quasi-finished, semi-broken state which only experts can use. Without a doubt you have never run any software in a TC environment. As part of that role, the TPM provides some permanent storage in the form of NVRAM. Because the TPM is designed to be as cheap as possible, it has a limited number of write cycles. Normally you're meant to store Intel TXT launch control policies and sealed keys there, but Pond uses it in a different way by storing keys there that it encrypts local data with. By erasing the key in the TPM chips memory area, the data on disk is effectively destroyed too. This is useful because modern "disks" are often SSD drives, or physical metal disks that use log structured file systems. Because flash memory has a limited number of write cycles per cell, internally SSDs have firmware that remap writes from logical addresses to different physical addresses, the goal is to avoid wearing down the drive and extend its useful life. Normally it doesn't matter, but if you want to delete data such that it's really really gone, it obviously poses a problem. Using TPM NVRAM solves it, albiet, at a high usability cost. *note: actual tamper resistance of real-world TPM chips is not something that seems to have been studied much On Tue, Jul 30, 2013 at 1:27 PM, Wendell wrote: > Can you explain this process for those of us not too familiar with TPM > chips? > > -wendell > > grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 > > On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote: > > > As a testament to the seriousness with which Pond takes forward > security, it can use the NVRAM in a TPM chip to reliably destroy keys for > data that an SSD device might have otherwise made un-erasable. > --047d7b339fbf27d8c004e2b987c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The TPM is a piece of secure* hardware that provides vario= us cryptographic services to the host system. It is important to understand= that it is not a crypto accelerator. It is a place to store keys and small= pieces of data (like hashes, counters) where it's difficult for someon= e to extract them even if they have physical access.

The TPM is designed to support trusted computing, a rather s= plendid set of extensions to the x86 architecture that let you do remote at= testation, software sealing and other things. Or at least it would be splen= did if it had been really finished off and pushed to completion by the desi= gners. Unfortunately due to various political issues it exists in a quasi-f= inished, semi-broken state which only experts can use. Without a doubt you = have never run any software in a TC environment.

As part of that role, the TPM provides some permanent s= torage in the form of NVRAM. Because the TPM is designed to be as cheap as = possible, it has a limited number of write cycles. Normally you're mean= t to store Intel TXT launch control policies and sealed keys there, but Pon= d uses it in a different way by storing keys there that it encrypts local d= ata with. By erasing the key in the TPM chips memory area, the data on disk= is effectively destroyed too.

This is useful because modern "disks" are oft= en SSD drives, or physical metal disks that use log structured file systems= . Because flash memory has a limited number of write cycles per cell, inter= nally SSDs have firmware that remap writes from logical addresses to differ= ent physical addresses, the goal is to avoid wearing down the drive and ext= end its useful life. Normally it doesn't matter, but if you want to del= ete data such that it's really really gone, it obviously poses a proble= m. Using TPM NVRAM solves it, albiet, at a high usability cost.



*note: actual tamper resi= stance of real-world TPM chips is not something that seems to have been stu= died much


On Tue, Jul 30, 2013 at 1:27 PM, Wendell <w@grabhive.com> wrote= :
Can you explain this process for those of us not too familiar with TPM chip= s?

-wendell

grabhive.com | twitter.com/grabhive | gpg: 6C0C9411

On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote:

> As a testament to the seriousness with which Pond takes forward securi= ty, it can use the NVRAM in a TPM chip to reliably destroy keys for data th= at an SSD device might have otherwise made un-erasable.

--047d7b339fbf27d8c004e2b987c5--