summaryrefslogtreecommitdiff
path: root/15/d8c46f51ab73d3f96312b6c346b94b3f529c4c
blob: 11fa19ace99dec2316277fa94d2405d4bdf9039e (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <natanael.l@gmail.com>) id 1YPp5C-00006i-1k
	for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 09:13:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.171 as permitted sender)
	client-ip=74.125.82.171; envelope-from=natanael.l@gmail.com;
	helo=mail-we0-f171.google.com; 
Received: from mail-we0-f171.google.com ([74.125.82.171])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YPp5A-0000u6-M2
	for bitcoin-development@lists.sourceforge.net;
	Mon, 23 Feb 2015 09:13:42 +0000
Received: by wesw62 with SMTP id w62so16569456wes.12
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 23 Feb 2015 01:13:34 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.194.91.199 with SMTP id cg7mr19533687wjb.114.1424682814658; 
	Mon, 23 Feb 2015 01:13:34 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Mon, 23 Feb 2015 01:13:34 -0800 (PST)
Received: by 10.194.28.170 with HTTP; Mon, 23 Feb 2015 01:13:34 -0800 (PST)
In-Reply-To: <54EAD884.8000205@AndySchroder.com>
References: <20150222190839.GA18527@odo.localdomain>
	<54EA5A1C.2020701@AndySchroder.com> <54EA60D9.8000001@voskuil.org>
	<54EA66F5.2000302@AndySchroder.com> <mcdu6b$j11$1@ger.gmane.org>
	<54EAD884.8000205@AndySchroder.com>
Date: Mon, 23 Feb 2015 10:13:34 +0100
Message-ID: <CAAt2M19zerAMCtbfSjv=kmBy_GoW16mp8Bd-wrhCs9_Vj3b1-g@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Andy Schroder <info@andyschroder.com>
Content-Type: multipart/alternative; boundary=047d7bf0d86215de4a050fbdd11b
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(natanael.l[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1YPp5A-0000u6-M2
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Bitcoin at POS using BIP70,
 NFC and offline payments - implementer feedback
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: Mon, 23 Feb 2015 09:13:42 -0000

--047d7bf0d86215de4a050fbdd11b
Content-Type: text/plain; charset=UTF-8

Den 23 feb 2015 08:38 skrev "Andy Schroder" <info@andyschroder.com>:
>
> I agree that NFC is the best we have as far as a trust anchor that you
are paying the right person. The thing I am worried about is the privacy
loss that could happen if there is someone passively monitoring the
connection. So, in response to some of your comments below and also in
response to some of Eric Voskuil's comments in another recent e-mail:

From the sources I can find NFC don't provide full privacy, but some
modulations are MITM resistant to varying degrees, some aren't at all, and
they are all susceptible to denial of service via jammers.

If the merchant system monitors the signal strength and similar metrics, a
MITM that alters data (or attempts to) should be detectable, allowing it to
shut down the connection.

Using NFC for key exchange to establish an encrypted link should IMHO be
secure enough.

http://resources.infosecinstitute.com/near-field-communication-nfc-technology-vulnerabilities-and-principal-attack-schema/

--047d7bf0d86215de4a050fbdd11b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
Den 23 feb 2015 08:38 skrev &quot;Andy Schroder&quot; &lt;<a href=3D"mailto=
:info@andyschroder.com">info@andyschroder.com</a>&gt;:<br>
&gt;<br>
&gt; I agree that NFC is the best we have as far as a trust anchor that you=
 are paying the right person. The thing I am worried about is the privacy l=
oss that could happen if there is someone passively monitoring the connecti=
on. So, in response to some of your comments below and also in response to =
some of Eric Voskuil&#39;s comments in another recent e-mail:</p>
<p dir=3D"ltr">From the sources I can find NFC don&#39;t provide full priva=
cy, but some modulations are MITM resistant to varying degrees, some aren&#=
39;t at all, and they are all susceptible to denial of service via jammers.=
 </p>
<p dir=3D"ltr">If the merchant system monitors the signal strength and simi=
lar metrics, a MITM that alters data (or attempts to) should be detectable,=
 allowing it to shut down the connection. </p>
<p dir=3D"ltr">Using NFC for key exchange to establish an encrypted link sh=
ould IMHO be secure enough. </p>
<p dir=3D"ltr"><a href=3D"http://resources.infosecinstitute.com/near-field-=
communication-nfc-technology-vulnerabilities-and-principal-attack-schema/">=
http://resources.infosecinstitute.com/near-field-communication-nfc-technolo=
gy-vulnerabilities-and-principal-attack-schema/</a><br>
</p>

--047d7bf0d86215de4a050fbdd11b--