From: Eric Voskuil <eric@voskuil•org>
To: "MⒶrtin HⒶboⓋštiak" <martin.habovstiak@gmail•com>
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
Date: Tue, 10 Feb 2015 09:56:39 -0800 [thread overview]
Message-ID: <54DA4657.5080604@voskuil.org> (raw)
In-Reply-To: <CALkkCJZB9RTAXiT_V8FtP+L6OOhgryBRDE21by-bpWOVes+jmA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2015-02-10 17:56 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 20:06 Paul Puey
2015-02-05 20:28 ` Mike Hearn
2015-02-05 20:37 ` Paul Puey
2015-02-05 20:43 ` Mike Hearn
2015-02-05 20:44 ` Eric Voskuil
2015-02-05 20:50 ` Mike Hearn
2015-02-05 20:59 ` Eric Voskuil
2015-02-05 21:19 ` Brian Hoffman
2015-02-05 21:23 ` Eric Voskuil
2015-02-05 21:36 ` Mike Hearn
2015-02-05 21:46 ` Eric Voskuil
2015-02-05 22:07 ` Paul Puey
2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
2015-02-05 23:22 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:02 ` William Swanson
2015-02-05 23:34 ` Roy Badami
2015-02-05 23:59 ` Eric Voskuil
2015-02-06 8:59 ` Roy Badami
2015-02-06 9:13 ` Eric Voskuil
2015-02-06 0:58 ` Paul Puey
2015-02-05 23:22 ` Eric Voskuil
2015-02-05 23:36 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:46 ` Eric Voskuil
2015-02-06 0:04 ` MⒶrtin HⒶboⓋštiak
2015-02-06 0:22 ` Eric Voskuil
2015-02-06 0:36 ` Martin Habovštiak
2015-02-06 1:29 ` Eric Voskuil
2015-02-06 9:07 ` MⒶrtin HⒶboⓋštiak
2015-02-10 16:55 ` Eric Voskuil
2015-02-10 17:16 ` MⒶrtin HⒶboⓋštiak
2015-02-10 17:56 ` Eric Voskuil [this message]
2015-02-06 0:49 ` Paul Puey
2015-02-06 0:50 ` Martin Habovštiak
2015-02-06 1:05 ` Eric Voskuil
2015-02-06 2:09 ` Paul Puey
2015-02-05 22:02 ` Paul Puey
2015-02-05 22:01 ` Paul Puey
2015-02-05 22:05 ` Eric Voskuil
2015-02-05 22:08 ` Paul Puey
-- strict thread matches above, loose matches on Subject: below --
2015-02-05 8:01 Paul Puey
2015-02-05 13:46 ` Andreas Schildbach
2015-02-05 13:57 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54DA4657.5080604@voskuil.org \
--to=eric@voskuil$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=martin.habovstiak@gmail$(echo .)com \
--cc=paul@airbitz$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox