diff options
| author | Mike Hearn <mike@plan99.net> | 2014-03-20 19:31:27 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-20 18:31:34 +0000 |
| commit | 950ebcb696ea4a987d981a436e877ed5446bf699 (patch) | |
| tree | d8cd67da641be8550fc3185893825e17d6667898 | |
| parent | a24c463492bae482359fc6668aa87be13bb41e45 (diff) | |
| download | pi-bitcoindev-950ebcb696ea4a987d981a436e877ed5446bf699.tar.gz pi-bitcoindev-950ebcb696ea4a987d981a436e877ed5446bf699.zip | |
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
| -rw-r--r-- | 38/d5e515586565141fb2c919ca3e5088d98b6c57 | 230 |
1 files changed, 230 insertions, 0 deletions
diff --git a/38/d5e515586565141fb2c919ca3e5088d98b6c57 b/38/d5e515586565141fb2c919ca3e5088d98b6c57 new file mode 100644 index 000000000..433ff4cb8 --- /dev/null +++ b/38/d5e515586565141fb2c919ca3e5088d98b6c57 @@ -0,0 +1,230 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1WQhkc-0000KR-8P + for bitcoin-development@lists.sourceforge.net; + Thu, 20 Mar 2014 18:31:34 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.181 as permitted sender) + client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f181.google.com; +Received: from mail-ob0-f181.google.com ([209.85.214.181]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WQhkb-0001gx-1V + for bitcoin-development@lists.sourceforge.net; + Thu, 20 Mar 2014 18:31:34 +0000 +Received: by mail-ob0-f181.google.com with SMTP id wp4so1342115obc.40 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 20 Mar 2014 11:31:27 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.182.81.197 with SMTP id c5mr8621399oby.40.1395340287711; + Thu, 20 Mar 2014 11:31:27 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.71.231 with HTTP; Thu, 20 Mar 2014 11:31:27 -0700 (PDT) +In-Reply-To: <CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com> +References: <lc5hmg$1jh$1@ger.gmane.org> <leuunm$tjk$1@ger.gmane.org> + <CANEZrP3nQfvDArKTRgje0Cus4G2JD_zpxSjA3fXfxM2TNAP80Q@mail.gmail.com> + <CALDj+BafD+6KTNcYDBEu5gNPzYozSkiC-JCxrY-PzXL2DYBRsw@mail.gmail.com> + <CAJHLa0N4J_Z907+D0ENSNKfNAW2N=7Jf4JzSCO=SU558GtGTzA@mail.gmail.com> + <lge7nk$3mf$2@ger.gmane.org> + <CANEZrP0J849oDvMWjf8LWi0xj44Q8DaUwDip5_smVBMNgeQ3mw@mail.gmail.com> + <CALDj+BZJ0rSKuDHdbL7ANN0Vtaa3-KGYgusqMDzzB-CUxjMz7g@mail.gmail.com> +Date: Thu, 20 Mar 2014 19:31:27 +0100 +X-Google-Sender-Auth: JEWfULLXo3JoMG0v8VVG99nFEdE +Message-ID: <CANEZrP3szn=oQS+ZuqSzjUoSAjtkyPxPWJFaU1vDW43dRNVeNQ@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Alex Kotenko <alexykot@gmail.com> +Content-Type: multipart/alternative; boundary=047d7b2e4d5830beaf04f50dfa6e +X-Spam-Score: -0.5 (/) +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 + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 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: 1WQhkb-0001gx-1V +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>, + Andreas Schildbach <andreas@schildbach.de> +Subject: Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments +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: Thu, 20 Mar 2014 18:31:34 -0000 + +--047d7b2e4d5830beaf04f50dfa6e +Content-Type: text/plain; charset=UTF-8 + +With Java, in theory, you can use SSLSocketFactory.createSocket(btsocket, +address, 1234, true) to wrap a bluetooth socket in SSL. However I have not +tried it. + +For now, just prototype and build your product without the security. We can +find someone to experiment with this, if you don't want to . + +Bluetooth needs encryption and MACs as well as signing to be secure, +because there could be radio MITM. Yes, this overlaps somewhat with the PKI +signing in BIP70, but not entirely - you might want to serve unsigned +payment requests, but still have confidentiality and authenticity for a +local face to face transaction. The signing and encryption does different +things. + + +On Thu, Mar 20, 2014 at 7:20 PM, Alex Kotenko <alexykot@gmail.com> wrote: + +> Hmm, is there any other way to do it? Can we provide a signed payment +> request and verify the sign on receiving side and this way protect from +> bluetooth MitM attack? Quick googling showed that SSL over bluetooth isn't +> a very well developed area, and my own skills are not enough to quickly +> implement a reliable secure solution here. +> +> +> 2014-03-20 10:36 GMT+00:00 Mike Hearn <mike@plan99.net>: +> +>> Encoding entire payment requests into qrcodes is definitely not the way +>> to go. They can already be large when signed and we're just at the start of +>> adding features. +>> +>> Finishing off and standardising the bluetooth support is the way to go +>> (r=bt:mac). Andreas' app already has some support for this I believe, so +>> Alex you could prototype with that, but we need to: +>> +>> 1) Add an encryption/auth layer on top, because it runs over RFCOMM +>> sockets. The authentication would require proof of owning the Bitcoin key +>> that's in the address part of the URI (which is needed for backwards compat +>> anyway). +>> +>> 2) Write a BIP for it and make sure it's interoperable +>> +>> For the auth layer we could either use SSL and then just ignore the +>> server certificate and require signing of the session public key with the +>> Bitcoin key, which should be easy to code up but is rather heavy on the +>> air, or roll a custom lightweight thing where we just do a basic ECDH, with +>> the servers key being the same as the address key. But rolling such +>> protocols is subtle and I guess it'd need to be reviewed by people familiar +>> with such things. +>> +>> This feels like a good opportunity to grow the community - perhaps we can +>> find a volunteer in the forums who enjoys crypto. +>> +>> +>> ------------------------------------------------------------------------------ +>> Learn Graph Databases - Download FREE O'Reilly Book +>> "Graph Databases" is the definitive new guide to graph databases and their +>> applications. Written by three acclaimed leaders in the field, +>> this first edition is now available. Download your free book today! +>> http://p.sf.net/sfu/13534_NeoTech +>> _______________________________________________ +>> Bitcoin-development mailing list +>> Bitcoin-development@lists.sourceforge.net +>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +>> +>> +> + +--047d7b2e4d5830beaf04f50dfa6e +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">With Java, in theory, you can use SSLSocketFactory.createS= +ocket(btsocket, address, 1234, true) to wrap a bluetooth socket in SSL. How= +ever I have not tried it.<div><br></div><div>For now, just prototype and bu= +ild your product without the security. We can find someone to experiment wi= +th this, if you don't want to .</div> +<div><br></div><div>Bluetooth needs encryption and MACs as well as signing = +to be secure, because there could be radio MITM. Yes, this overlaps somewha= +t with the PKI signing in BIP70, but not entirely - you might want to serve= + unsigned payment requests, but still have confidentiality and authenticity= + for a local face to face transaction. The signing and encryption does diff= +erent things.</div> +</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,= + Mar 20, 2014 at 7:20 PM, Alex Kotenko <span dir=3D"ltr"><<a href=3D"mai= +lto:alexykot@gmail.com" target=3D"_blank">alexykot@gmail.com</a>></span>= + wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default= +" style=3D"font-family:courier new,monospace;color:#003300">Hmm, is there a= +ny other way to do it? Can we provide a signed payment request and verify t= +he sign on receiving side and this way protect from bluetooth MitM attack? = +Quick googling showed that SSL over bluetooth isn't a very well develop= +ed area, and my own skills are not enough to quickly implement a reliable s= +ecure solution here.</div> + + +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><= +div class=3D"gmail_extra"><div class=3D"gmail_quote">2014-03-20 10:36 GMT+0= +0:00 Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@plan99.net" ta= +rget=3D"_blank">mike@plan99.net</a>></span>:<br> + + +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><div= + class=3D"gmail_extra">Encoding entire payment requests into qrcodes is def= +initely not the way to go. They can already be large when signed and we'= +;re just at the start of adding features.</div> + + +<div class=3D"gmail_extra"> +<br></div><div class=3D"gmail_extra">Finishing off and standardising the bl= +uetooth support is the way to go (r=3Dbt:mac). Andreas' app already has= + some support for this I believe, so Alex you could prototype with that, bu= +t we need to:</div> + + + +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1) Add an e= +ncryption/auth layer on top, because it runs over RFCOMM sockets. The authe= +ntication would require proof of owning the Bitcoin key that's in the a= +ddress part of the URI (which is needed for backwards compat anyway).</div> + + + +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">2) Write a = +BIP for it and make sure it's interoperable</div><div class=3D"gmail_ex= +tra"><br></div><div class=3D"gmail_extra">For the auth layer we could eithe= +r use SSL and then just ignore the server certificate and require signing o= +f the session public key with the Bitcoin key, which should be easy to code= + up but is rather heavy on the air, or roll a custom lightweight thing wher= +e we just do a basic ECDH, with the servers key being the same as the addre= +ss key. But rolling such protocols is subtle and I guess it'd need to b= +e reviewed by people familiar with such things.</div> + + + +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This feels = +like a good opportunity to grow the community - perhaps we can find a volun= +teer in the forums who enjoys crypto.</div></div> +<br></div></div><div class=3D"">-------------------------------------------= +-----------------------------------<br> +Learn Graph Databases - Download FREE O'Reilly Book<br> +"Graph Databases" is the definitive new guide to graph databases = +and their<br> +applications. Written by three acclaimed leaders in the field,<br> +this first edition is now available. Download your free book today!<br> +<a href=3D"http://p.sf.net/sfu/13534_NeoTech" target=3D"_blank">http://p.sf= +.net/sfu/13534_NeoTech</a><br>_____________________________________________= +__<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +<br></div></blockquote></div><br></div></div> +</blockquote></div><br></div> + +--047d7b2e4d5830beaf04f50dfa6e-- + + |