Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil <eric@voskuil.org>]

[-- Attachment #1: Type: text/plain, Size: 10269 bytes --]

On 02/10/2015 09:16 AM, MⒶrtin HⒶboⓋštiak wrote:
> 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 question.
>>
>> e
>>
>> On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote:
>>> 2015-02-06 2:29 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>>>> On 02/05/2015 04:36 PM, Martin Habovštiak 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 of
>>>> public keys is a distinction without a difference. The problem remains
>>>> 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 that
>>>> 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 some
>>>> 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 issue)
>>> - 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 does
>>>> of course shrink the attack surface and increase the attacker's cost.
>>>>
>>>> e
>>>>
>>>>> Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil
>>>> <eric@voskuil.org> napísal:
>>>>
>>>>>> On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
>>>>>>> That's exactly what I though when seeing the RedPhone code, but after
>>>>>>> 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 analysis
>>>>>> 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 you
>>>>>> are
>>>>>> willing to indulge me.
>>>>>
>>>>>>> Shortly, how it works:
>>>>>>> The initiator of the connection sends commit message containing the
>>>>>>> hash of his temporary public ECDH part, second party sends back their
>>>>>>> public ECDH part and then initiator sends his public ECDH part in
>>>>>>> open. All three messages are hashed together and the first two bytes
>>>>>>> are used to select two words from a shared dictionary which are
>>>>>>> displayed on the screen of both the initiator and the second party.
>>>>>
>>>>>>> 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 right
>>>>>>> public parts 1:65536. There is no way to brute-force it, since that
>>>>>>> would be noticed immediately. If instead of two words based on the
>>>>>>> first two bytes, four words from BIP39 wordlist were chosen, it would
>>>>>>> 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 buyer
>>>>>>> confirms transaction after verifying that words match.
>>>>>
>>>>>> So the assumption is that there exists a secure (as in proximity-based)
>>>>>> communication channel?
>>>>>
>>>>>> e
>>>>>
>>>>>>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric@voskuil.org>:
>>>>>>>> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋš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 other
>>>>>>>>>> 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 do.
>>>>>>>>>
>>>>>>>>> What about using encryption with forward secrecy? Merchant would
>>>>>>>>> generate signed request containing public ECDH part, buyer would
>>>>>> 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 hard
>>>>>> to
>>>>>>>>> spoof thanks to commit protocol - see RedPhone)?
>>>>>>>>
>>>>>>>> Hi Martin,
>>>>>>>>
>>>>>>>> The problem is that you need to verify the ownership of the public
>>>>>> key.
>>>>>>>> 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). But the problem is then establishing that
>>>>>> secret
>>>>>>>> over a public channel.
>>>>>>>>
>>>>>>>> You can bootstrap a private session over the untrusted network using
>>>>>> a
>>>>>>>> trusted public key (PKI/WoT). But the presumption is that you are
>>>>>>>> already doing this over the web (using TLS). That process is subject
>>>>>> 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
>>>>>>>>
>>>>>
>>>>>
>>>>
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]