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
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
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 <jeremy@taplink.co>) id 1WK3mf-00032f-K1
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 10:38:13 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1WK3me-0003si-Em for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 10:38:13 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co
; Sun, 2 Mar 2014 02:38:26 -0800
Content-Type: multipart/alternative; boundary=----------hsfupyWtnaTWPUmT1EHYyk
To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>, "Mike Hearn"
<mike@plan99.net>
References: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
Date: Sun, 02 Mar 2014 02:38:04 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xb3btqp7yldrnw@laptop-air>
In-Reply-To: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
X-Spam-Score: -0.6 (/)
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 SPF_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WK3me-0003si-Em
Subject: Re: [Bitcoin-development] BIP70 extension to allow for identity
delegation
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: Sun, 02 Mar 2014 10:38:13 -0000
------------hsfupyWtnaTWPUmT1EHYyk
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn <mike@plan99.net> wrote:
> 3) Whilst these payment processors currently verify merchants so the
> security risk is low, in future a lighter-weight model or competing
> sites that >allow open signups would give a weak security situation: a
> hacker who compromised your computer could sign up for some popular
> payment >processor under a false identity (or no identity), and wait
> until you use your hacked computer to make a payment to someone else
> using the same >payment processor. They could then do an identity swap
> of the real payment request for one of their own, and your Trezor would
> still look the same. >Avoiding this is a major motivation for the entire
> system!
Let me restate that, it's a huge problem...
Alice's system is compromised,
Mallory intercepts a payment request being sent to Alice from payment
processor X on behaf of merchant X.
Mallory regenerates a spoof payment request which pays to M, from the same
payment processor
Alice can't tell Mallory's spoofed PR apart from Merchant X's and thinks
she's paying Merchant X
It might be a bit challenging for M to generate the new PR on-the-fly
without being noticed, but that's not a security guarantee.
Perhaps the UI just isn't expressive enough currently to expose this
situation in any way, let alone reliably alert the user to the issue,
because there's no way for the payment processor to get authenticated
fields other than memo into the UI.
Today the only solution is for the payment processor to strictly control
the 'memo' field so Mallory wouldn't be able to make his own PR that
looked exactly like merchant Y's. But maybe it's too subtle to make
payment processors embed that kind of information.
So is the main goal is to provide a structured way to embed this
information in the PR and expect that user interfaces will display them to
end users? If that's the case, I don't think we need an entirely secondary
certificate, or cross signing from a secondary ECDSA key.
A poor solution: If the UI included some sort of certificate viewer, even
just tied to the OS certificate viewer, and made the cert available for
inspection, at least the merchant would have a chance to put some fields
in there which a very advanced user might actually find. But this was
discussed a while ago and I think the primary problem is the difficulty in
getting a CA to let you embed any additional fields in your certificate in
the first place, plus you don't want to generate a new cert for each
merchant.
A somewhat better option: Some additional fields defined in an extension
which are reliably shown in the UI. We could try to define specific
fields, like 'DelegateCN' which would possibly override the primary CN...
As an aside, I think you can never allow actually overriding the CN
displayed in the UI directly, the most you can do is add another field in
the UI to show this string. First I need to know it's from Payment
Processor X, and then maybe we can let the payment processor make some
additional claim, like yes you are paying irs.gov. You can't give the
impression that Payment Processor X is not actually man-in-the-middle.
Maybe the simplest would be a single field expected to contain a delimited
key/value string (of course JSON) which could be shown as additional lines
of labeled text in the UI. I don't want to give the "merchant" too much
dynamic control over what the user's screen will display, but making it
somewhat dynamic might add some future proofing.
I think any additional extension fields should be hashed using the hash
function specified in pki_type and signed by X509Certificates.certifcate
private key. No extended_certs required -- I'm thinking something like;
message PaymentRequest {
// new field
optional bytes extended_properties = 6;
optional bytes extended_properties_sig = 7;
}
Thanks,
Jeremy
------------hsfupyWtnaTWPUmT1EHYyk
Content-Type: multipart/related; boundary=----------hsfupyWtnaTWPU83yrMnql
------------hsfupyWtnaTWPU83yrMnql
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1393756684854.97450a665d6b425a@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body>On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn <mike@plan99.net=
> wrote:<br><br><blockquote style=3D"margin: 0 0 0.80ex; border-left:=
#0000FF 2px solid; padding-left: 1ex">3) Whilst these payment processor=
s currently verify merchants so the security risk is low, in future a li=
ghter-weight model or competing sites that allow open signups would give=
a weak security situation: a hacker who compromised your computer could=
sign up for some popular payment processor under a false identity (or n=
o identity), and wait until you use your hacked computer to make a payme=
nt to someone else using the same payment processor. They could then do =
an identity swap of the real payment request for one of their own, and y=
our Trezor would still look the same. Avoiding this is a major motivatio=
n for the entire system!</blockquote><div><br></div><div>Let me restate =
that, it's a huge problem...</div><div><br></div><div>Alice's system is =
compromised,</div><div>Mallory intercepts a payment request being sent t=
o Alice from payment processor X on behaf of merchant X.</div><div>Mallo=
ry regenerates a spoof payment request which pays to M, from the same pa=
yment processor</div><div>Alice can't tell Mallory's spoofed PR apart fr=
om Merchant X's and thinks she's paying Merchant X</div><div><br></div><=
div>It might be a bit challenging for M to generate the new PR on-the-fl=
y without being noticed, but that's not a security guarantee.</div><div>=
<br></div><div>Perhaps the UI just isn't expressive enough currently to =
expose this situation in any way, let alone reliably alert the user to t=
he issue, because there's no way for the payment processor to get authen=
ticated fields other than memo into the UI.</div><div><br></div><div>
<div>Today the only solution is for the payment processor to strictly co=
ntrol the 'memo' field so Mallory wouldn't be able to make his own PR th=
at looked exactly like merchant Y's. But maybe it's too subtle to make p=
ayment processors embed that kind of information.</div><div><br></div><d=
iv>So is the main goal is to provide a structured way to embed this info=
rmation in the PR and expect that user interfaces will display them to e=
nd users? If that's the case, I don't think we need an entirely secondar=
y certificate, or cross signing from a secondary ECDSA key.</div></div><=
div><br></div><div>
<div>A poor solution: If the UI included some sort of certificate viewer=
, even just tied to the OS certificate viewer, and made the cert availab=
le for inspection, at least the merchant would have a chance to put some=
fields in there which a very advanced user might actually find. But thi=
s was discussed a while ago and I think the primary problem is the diffi=
culty in getting a CA to let you embed any additional fields in your cer=
tificate in the first place, plus you don't want to generate a new cert =
for each merchant.</div></div><div>
<div>A somewhat better option: Some additional fields defined in an exte=
nsion which are reliably shown in the UI. We could try to define specifi=
c fields, like 'DelegateCN' which would possibly override the primary CN=
... As an aside, I think you can never allow actually overriding the CN =
displayed in the UI directly, the most you can do is add another field i=
n the UI to show this string. First I need to know it's from Payment Pro=
cessor X, and then maybe we can let the payment processor make some addi=
tional claim, like yes you are paying irs.gov. You can't give the impres=
sion that Payment Processor X is not actually man-in-the-middle.</div><d=
iv><br></div><div>Maybe the simplest would be a single field expected to=
contain a delimited key/value string (of course JSON) which could be sh=
own as additional lines of labeled text in the UI. I don't want to give =
the "merchant" too much dynamic control over what the user's screen will=
display, but making it somewhat dynamic might add some future proofing.=
</div><div><br></div></div><div>I think any additional extension f=
ields should be hashed using the hash function specified in pki_type and=
signed by X509Certificates.certifcate private key. No extended_certs re=
quired -- I'm thinking something like;</div><div><br></div><div>message =
PaymentRequest {<br> // new field<br> optional bytes extended_prope=
rties =3D 6;</div><div> optional bytes extended_properties_sig =3D =
7; <br>}</div><div><br></div><div><br></div><div>Thanks,</div><div>=
Jeremy</div></body></html>
------------hsfupyWtnaTWPU83yrMnql--
------------hsfupyWtnaTWPUmT1EHYyk--
|
