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 ) 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 ; 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: References: Date: Thu, 20 Mar 2014 19:31:27 +0100 X-Google-Sender-Auth: JEWfULLXo3JoMG0v8VVG99nFEdE Message-ID: From: Mike Hearn To: Alex Kotenko 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 , Andreas Schildbach 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 : > >> 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
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.

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 .

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.


On Thu,= Mar 20, 2014 at 7:20 PM, Alex Kotenko <alexykot@gmail.com>= wrote:
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 class=3D"gmail_extra">
2014-03-20 10:36 GMT+0= 0:00 Mike Hearn <mike@plan99.net>:
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.

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:

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).

2) Write a = BIP for it and make sure it's interoperable

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.

This feels = like a good opportunity to grow the community - perhaps we can find a volun= teer 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-de= velopment



--047d7b2e4d5830beaf04f50dfa6e--