1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
|
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 <mh.in.england@gmail.com>)
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 <multiple recipients>; 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: <CAEvNM8=yQn8sE4Lrf5+xedfm4RomBkBVhVWOdFFXxPEk7wZYDw@mail.gmail.com>
<CAAS2fgS=5ju1BFFDkjoRW65qdtojm3rYBHZcSMtUmHhyaTxMhA@mail.gmail.com>
<CANEZrP2+jOTHsEv+qXpqLKJS3UATB_so2ZwQdL+AyJTd2zti4A@mail.gmail.com>
<7B0891A4-7163-43AE-85EC-8BA7ADC28A2A@grabhive.com>
Date: Tue, 30 Jul 2013 14:12:51 +0200
X-Google-Sender-Auth: Vj4C5FGRo-idaYbvDe2lu6iB400
Message-ID: <CANEZrP0OYzz8p6zT_y7JGZyofZ=wTZ=6umCLu0AJy8KH6E0R5A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
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-development@lists.sourceforge.net>,
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <w@grabhive.com> 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
<div dir=3D"ltr">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.<div>
<br></div><div>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.<br>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div><br></div><div>*note: actual tamper resi=
stance of real-world TPM chips is not something that seems to have been stu=
died much</div></div></div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">
On Tue, Jul 30, 2013 at 1:27 PM, Wendell <span dir=3D"ltr"><<a href=3D"m=
ailto:w@grabhive.com" target=3D"_blank">w@grabhive.com</a>></span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
Can you explain this process for those of us not too familiar with TPM chip=
s?<br>
<br>
-wendell<br>
<br>
<a href=3D"http://grabhive.com" target=3D"_blank">grabhive.com</a> | <a hre=
f=3D"http://twitter.com/grabhive" target=3D"_blank">twitter.com/grabhive</a=
> | gpg: 6C0C9411<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote:<br>
<br>
> 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.<br>
</div></div></blockquote></div><br></div>
--047d7b339fbf27d8c004e2b987c5--
|
