Message-ID: <54DA4657.5080604@voskuil.org>
Date: Tue, 10 Feb 2015 09:56:39 -0800
From: Eric Voskuil <eric@voskuil.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: =?UTF-8?B?TeKStnJ0aW4gSOKStmJv4pOLxaF0aWFr?= <martin.habovstiak@gmail.com>
References: <CABdy8DKS4arkkCLGC=66SUJm5Ugib1EWP7B6MkQRX1k-yd3WBw@mail.gmail.com>	<54D3D636.1030308@voskuil.org>	<CANEZrP3ekWQWeV=Yw_E=n0grORBLHaXLUh3w0EFQdz=HsjWvZw@mail.gmail.com>	<279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com>	<CANEZrP3VAWajxE=mNxb6sLSQbhaQHD=2TgRKvYrEax2PAzCi2A@mail.gmail.com>	<6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org>	<CABdy8DLRGyy5dvmVb_B3vao7Qwz-zdAC3-+2nJkg9rSsU6FLbw@mail.gmail.com>	<C28CD881-DAB8-4EDB-B239-7D45A825EAF0@voskuil.org>	<54D3FB4A.9010105@voskuil.org>	<CALkkCJammCvVd6_1SYRvnxsMVj_x1AvS1VsSa6_76d0NWMDs=Q@mail.gmail.com>	<54D400F0.9090406@voskuil.org>	<CALkkCJYLfEXxvKjOMCNtK3zhCOmO24JD3w73VwORoqX9xF_p7w@mail.gmail.com>	<54D4093F.5000707@voskuil.org>	<C6292B5F-B48D-4BCE-909E-DD59261E8E95@gmail.com>	<54D418DF.1000704@voskuil.org>	<CALkkCJb_FZ6w9fWKGRcbfr4RRA5g5da-A3EEbZqHPOUjCNWoew@mail.gmail.com>	<54DA381E.7050407@voskuil.org>
	<CALkkCJZB9RTAXiT_V8FtP+L6OOhgryBRDE21by-bpWOVes+jmA@mail.gmail.com>
In-Reply-To: <CALkkCJZB9RTAXiT_V8FtP+L6OOhgryBRDE21by-bpWOVes+jmA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="RGrGG8P0CveT7Hg7Si5l6LPjxHkTUs2b4"
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Paul Puey <paul@airbitz.co>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE)
 transfer of Payment URI
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--RGrGG8P0CveT7Hg7Si5l6LPjxHkTUs2b4
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/10/2015 09:16 AM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak wr=
ote:
> I'm not sure if I was clear enough. Handshake should be used to
> establish authenticated AND encrypted communication using ECDH (or
> just DH, but I think it's easier to use ECDH, since required functions
> are already used in Bitcoin protocol), like RedPhone does. BTW
> knowledge of verification string is useless to the attacker.

Yes, I think this was clear from your description.

> Yes, the customer must verify it verbally and the merchant shouldn't
> send the transaction before verification. Other possibility is that in
> case of differing verification strings new address is generated, so
> attacker doesn't know the address. But in this case, amount is leaked
> and there is quite high probability it can be found in the Blockchain.

Yes, for each handshake the payment request would need to contain a
different address, mitigating some of the privacy loss.

> Anyway, I don't believe the transaction can be made securely without
> such interaction except with white-listing public keys, so I see no
> reason why interaction should be problematic.

It can be done securely and privately by transfer of a shared secret
through a private channel.

> We don't have such strict regulations but I agree that security is
> important. Currently I think that verbal verification and manual
> confirmation is the best way to achieve high security and reasonable
> user-friendliness.

I think for a broadcast model (e.g. Bluetooth only) that is the only
want to ensure integrity and privacy. A narrow cast can use proximity to
establish trust.

> 2015-02-10 17:55 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>> Martin,
>>
>> I like your idea for the commit protocol in that it resolves the
>> vandalous address substitution attack. However, I don't see a way to
>> prevent privacy loss without adverse impact to the scenario.
>>
>> Anyone could perform the handshake and thereby obtain the payment
>> request. Therefore to prevent inadvertent disclosure the customer must=

>> visually confirm the "phrase" and then verbally tell the merchant to
>> proceed by sending the payment request.
>>
>> One might argue that it's sufficient to preserve the integrity of the
>> transaction while suffering the privacy loss, especially given that a
>> hijacked handshake should never result in a completed transaction -
>> unless of course the hijacker pays.
>>
>> But imagine someone purchasing their meds. HIPAA requires the checkout=

>> queue to form behind a yellow line. That speaks directly to this quest=
ion.
>>
>> e
>>
>> On 02/06/2015 01:07 AM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1tiak=
 wrote:
>>> 2015-02-06 2:29 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>>>> On 02/05/2015 04:36 PM, Martin Habov=C5=A1tiak wrote:
>>>>> I believe, we are still talking about transactions of physical
>>>>> people in physical world. So yes, it's proximity based - people
>>>>> tell the words by mouth. :)
>>>>
>>>> Notice from my original comment:
>>>>
>>>>>>>> A MITM can substitute the key. If you don't have verifiable
>>>>>>>> identity associated with the public key (PKI/WoT), you need
>>>>>>>> a shared secret (such as a secret phrase).
>>>>
>>>> I said this could only be accomplished using a shared secret or a
>>>> trusted public key. Exchanging a value that is derived from a pair o=
f
>>>> public keys is a distinction without a difference. The problem remai=
ns
>>>> that the parties must have a secure/out-of-band channel for
>>>> communicating this value.
>>>>
>>>> The fact that they are face-to-face establishes this channel, but th=
at
>>>> brings us back to the original problem, as it requires manual
>>>> verification - as in visual/audible scanning of the two values for
>>>> comparison. At that point the visual comparison of the address, or s=
ome
>>>> value derived from it, is simpler.
>>>
>>> I have never been against manual verification. What I'm trying to say=

>>> is let's just make manual verification easier and more secure.
>>> Comparison of address is simpler for the coder but also simpler to
>>> attack. It has these problems:
>>> - Addresses broadcasted in plaintext (privacy issue)
>>> - Amounts broadcasted in plaintext (privacy issue)
>>> - Address is long - takes lot of time to verify (user experience issu=
e)
>>> - Address prefix can be brute-forced, if too short or used to make
>>> "black hole" address if longer (vandalism issue)
>>>
>>> Commit protocol can be used for both the encryption and the
>>> authentication while user experience is not bad and everything is
>>> still secure.
>>>
>>>>
>>>>> In case of RedPhone, you read those words verbally over not-yet-
>>>>> verified channel relying on difficulty of spoofing your voice. Also=

>>>>> the app remembers the public keys, so you don't need to verify
>>>>> second time.
>>>>
>>>> This is reasonable, but wouldn't help in the case of an ad-hoc
>>>> connection between parties who don't know each other well.
>>>>
>>>>> I suggest you to try RedPhone (called Signal on iPhone) yourself.
>>>>> It's free/open source, Internet-based and end-to-end encrypted. You=

>>>>> may find it useful some day. Also I'm willing to help you with
>>>>> trying it after I wake up. (~8 hours: Send me private e-mail if
>>>>> you want to.)
>>>>
>>>> I appreciate the offer. I really don't trust *any* smartphone as a
>>>> platform for secure communication/data. But encrypting on the wire d=
oes
>>>> of course shrink the attack surface and increase the attacker's cost=
=2E
>>>>
>>>> e
>>>>
>>>>> D=C5=88a 6. febru=C3=A1ra 2015 1:22:23 CET pou=C5=BE=C3=ADvate=C4=BE=
 Eric Voskuil
>>>> <eric@voskuil.org> nap=C3=ADsal:
>>>>
>>>>>> On 02/05/2015 04:04 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1=
tiak wrote:
>>>>>>> That's exactly what I though when seeing the RedPhone code, but a=
fter
>>>>>>> I studied the commit protocol I realized it's actually secure and=

>>>>>>> convenient way to do it. You should do that too. :)
>>>>>
>>>>>> I was analyzing the model as you described it to me. A formal anal=
ysis
>>>>>> of the security model of a particular implementation, based on
>>>>>> inference
>>>>> >from source code, is a bit beyond what I signed up for. But I'm
>>>>>> perfectly willing to comment on your description of the model if y=
ou
>>>>>> are
>>>>>> willing to indulge me.
>>>>>
>>>>>>> Shortly, how it works:
>>>>>>> The initiator of the connection sends commit message containing t=
he
>>>>>>> hash of his temporary public ECDH part, second party sends back t=
heir
>>>>>>> public ECDH part and then initiator sends his public ECDH part in=

>>>>>>> open. All three messages are hashed together and the first two by=
tes
>>>>>>> are used to select two words from a shared dictionary which are
>>>>>>> displayed on the screen of both the initiator and the second part=
y.
>>>>>
>>>>>>> The parties communicate those two words and verify they match.
>>>>>
>>>>>> How do they compare words if they haven't yet established a secure=

>>>>>> channel?
>>>>>
>>>>>>> If an attacker wants to do MITM, he has a chance of choosing righ=
t
>>>>>>> public parts 1:65536. There is no way to brute-force it, since th=
at
>>>>>>> would be noticed immediately. If instead of two words based on th=
e
>>>>>>> first two bytes, four words from BIP39 wordlist were chosen, it w=
ould
>>>>>>> provide entropy of 44 bits which I believe should be enough even =
for
>>>>>>> paranoid people.
>>>>>>>
>>>>>>> How this would work in Bitcoin payment scenario: user's phone
>>>>>>> broadcasts his name, merchant inputs amount and selects the name =
from
>>>>>>> the list, commit message is sent (and then the remaining two
>>>>>>> messages), merchant spells four words he sees on the screen and b=
uyer
>>>>>>> confirms transaction after verifying that words match.
>>>>>
>>>>>> So the assumption is that there exists a secure (as in proximity-b=
ased)
>>>>>> communication channel?
>>>>>
>>>>>> e
>>>>>
>>>>>>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>>>>>>>> On 02/05/2015 03:36 PM, M=E2=92=B6rtin H=E2=92=B6bo=E2=93=8B=C5=A1=
tiak wrote:
>>>>>>>>>> A BIP-70 signed payment request in the initial broadcast can
>>>>>> resolve the
>>>>>>>>>> integrity issues, but because of the public nature of the
>>>>>> broadcast
>>>>>>>>>> coupled with strong public identity, the privacy compromise is=

>>>>>> much
>>>>>>>>>> worse. Now transactions are cryptographically tainted.
>>>>>>>>>>
>>>>>>>>>> This is also the problem with BIP-70 over the web. TLS and oth=
er
>>>>>>>>>> security precautions aside, an interloper on the communication=
,
>>>>>> desktop,
>>>>>>>>>> datacenter, etc., can capture payment requests and strongly
>>>>>> correlate
>>>>>>>>>> transactions to identities in an automated manner. The payment=

>>>>>> request
>>>>>>>>>> must be kept private between the parties, and that's hard to d=
o.
>>>>>>>>>
>>>>>>>>> What about using encryption with forward secrecy? Merchant woul=
d
>>>>>>>>> generate signed request containing public ECDH part, buyer woul=
d
>>>>>> send
>>>>>>>>> back transaction encrypted with ECDH and his public ECDH part. =
If
>>>>>>>>> receiving address/amount is meant to be private, use commit
>>>>>> protocol
>>>>>>>>> (see ZRTP/RedPhone) and short authentication phrase (which is h=
ard
>>>>>> to
>>>>>>>>> spoof thanks to commit protocol - see RedPhone)?
>>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> The problem is that you need to verify the ownership of the publ=
ic
>>>>>> key.
>>>>>>>> A MITM can substitute the key. If you don't have verifiable iden=
tity
>>>>>>>> associated with the public key (PKI/WoT), you need a shared secr=
et
>>>>>> (such
>>>>>>>> as a secret phrase). But the problem is then establishing that
>>>>>> secret
>>>>>>>> over a public channel.
>>>>>>>>
>>>>>>>> You can bootstrap a private session over the untrusted network u=
sing
>>>>>> a
>>>>>>>> trusted public key (PKI/WoT). But the presumption is that you ar=
e
>>>>>>>> already doing this over the web (using TLS). That process is sub=
ject
>>>>>> to
>>>>>>>> attack at the CA. WoT is not subject to a CA attack, because it'=
s
>>>>>>>> decentralized. But it's also not sufficiently deployed for some
>>>>>> scenarios.
>>>>>>>>
>>>>>>>> e
>>>>>>>>
>>>>>
>>>>>
>>>>
>>


--RGrGG8P0CveT7Hg7Si5l6LPjxHkTUs2b4
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU2kZXAAoJEDzYwH8LXOFOvL4H/1kp+HYi2Dsys7PIRwxuPC3I
/T/VQ9Em2z6VOtCqXhQKqVcn7C3vVaHnbAuHuUOYa5SiAXEa7M43N/tptb01uJpR
fW3ONzl/GPPvIMsi7W6HYEpkYehBDbozxFgmGoapJdNjkhrtz4cv9Ei/4Oil0M44
+8/HwkRzmOecqTG5eTM7S86tP3fEcw45TfI0Q68w6yHd2vk/2Qx2nQ+5CcrbLQJ1
bZFh/95vsp0Ehq0ePhMPHkGrq6HVFqmpTRsSTR8974h/4XjYVeEVWvHkvfJpPrmv
kWnxoiUxCKNK/bULdPeyUdbj/951KzcBdBLJtrHpCUyFXBfxm9W8R1jmlX8940w=
=mNoy
-----END PGP SIGNATURE-----

--RGrGG8P0CveT7Hg7Si5l6LPjxHkTUs2b4--