From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLF3M-0006mE-OO for bitcoin-development@lists.sourceforge.net; Tue, 10 Feb 2015 17:56:52 +0000 X-ACL-Warn: Received: from mail-pd0-f180.google.com ([209.85.192.180]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YLF2u-0006jZ-Gn for bitcoin-development@lists.sourceforge.net; Tue, 10 Feb 2015 17:56:52 +0000 Received: by pdev10 with SMTP id v10so23217864pde.7 for ; Tue, 10 Feb 2015 09:56:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=UjUDKz2wt8sCl9yAQVoPJmGNRYIWN1BZF1EhG/8YLMs=; b=VNPaPhxAB54lbggNvlRpc9dzwF8mgpZOx+dk8RAvfXzABJyiNLdTYs/Sicf4g+XZ3u L9TWdPfN+WQviEbqx9tmCOXU9uJpXXJEfdaOxzINaPwLLWMl0FL3zhQNKqUYhXbP+F3P AqmgP4l7eNHIR6F0rXMckHHc59aD/R1M2YLFPwxHal5ogawpobhWz5ZTU6BqGsYlyuSx S1wo31dv77gLPAyQn6sSztKpRI0MOJIBapk19H/UV2azYz2Z65q3eW4mKEZ2v095vrob eclfkS3fovRT/Ma2aq1MF/WDWCyM5S27nN9E1PBVln+UKM1gFh98hRP6F08o5g1M2Mjg Ag6g== X-Gm-Message-State: ALoCoQm1exduu4yaMytmWx3bQqYWk4xnPDUb4peVvHZY0ORcCDrpRv2rghqwvUueqty/izKy8WaJ X-Received: by 10.66.120.236 with SMTP id lf12mr40511945pab.67.1423590978654; Tue, 10 Feb 2015 09:56:18 -0800 (PST) Received: from [10.0.1.3] (c-50-135-46-157.hsd1.wa.comcast.net. [50.135.46.157]) by mx.google.com with ESMTPSA id bc1sm20129623pad.12.2015.02.10.09.56.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Feb 2015 09:56:17 -0800 (PST) Message-ID: <54DA4657.5080604@voskuil.org> Date: Tue, 10 Feb 2015 09:56:39 -0800 From: Eric Voskuil 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?= References: <54D3D636.1030308@voskuil.org> <279489A5-1E46-48A2-8F58-1A25821D4D96@gmail.com> <6AEDF3C4-DEE0-4E31-83D0-4FD92B125452@voskuil.org> <54D3FB4A.9010105@voskuil.org> <54D400F0.9090406@voskuil.org> <54D4093F.5000707@voskuil.org> <54D418DF.1000704@voskuil.org> <54DA381E.7050407@voskuil.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RGrGG8P0CveT7Hg7Si5l6LPjxHkTUs2b4" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1YLF2u-0006jZ-Gn Cc: Bitcoin Dev , Paul Puey Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2015 17:56:52 -0000 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 : >> 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 : >>>> 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 >>>> 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 : >>>>>>>> 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--