* [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
@ 2015-02-05 8:01 Paul Puey
2015-02-05 13:46 ` Andreas Schildbach
0 siblings, 1 reply; 43+ messages in thread
From: Paul Puey @ 2015-02-05 8:01 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 7059 bytes --]
Airbitz has developed and implemented a method for communicating a bitcoin
URI across Bluetooth (BLE) or any other P2P, mid range, wireless, broadcast
medium. The currently documented implementation is available in our iOS and
Android mobile wallet (updated Android version with BLE coming in about 1
week). We would like to have the BIP pulled into Github for review and
discussion. Here is the current BIP:
BIP: TBD
Title: P2P Wireless URI transfer
Authors: Thomas Baker <tom’at’airbitz.co>, Paul Puey <paul’at’airbitz.co>
Contributors: Joey Krug <joeykrug’at’gmail.com>
Status: proposal
Type: Standards Track
Created: 2015-01-12
Table of Contents
-
Abstract
-
Motivation
-
Specification
-
Compatibility
-
Examples
-
References
Abstract
This is a protocol for peer-to-peer wireless transfer of a URI request
using an open broadcast or advertisement channel such as Bluetooth,
Bluetooth Low Energy, or WiFi Direct.
Motivation
There are disadvantages for a merchant (requester) and customer (sender) to
exchange a URI request using QR codes that can be eliminated by using
wireless broadcast or advertisements.
Current QR code scan method to transfer a request URI from merchant
(Requester) to customer (Sender) is cumbersome. A usual scenario is a
merchant with a POS terminal for order entry and a separate tablet for
transacting payments with bitcoin, and a customer with a smartphone. After
the order is entered, the merchant enters payment request information into
the tablet, generates the QR code representing the URI, and presents this
to the customer. The customer prepares to scan the QR code with their
smartphone by maneuvering the camera to the tablet. The tablet screen must
be relatively clean, point at the customer, and held steady. The smartphone
camera lens must be clean, point at the tablet screen, come into range, and
held steady to focus and wait for a QR scan. Environmental conditions such
as bright outdoor sunlight, indoor spot lights, or significant distance
between QR code and camera can create difficult and cumbersome experiences
for users.
Using a wireless local broadcast allows the merchant to just enter the
payment and wait. The tablet and smartphone are not maneuvered to align in
any way. The customer observes broadcast listings, selects the appropriate
one from possible simultaneous broadcasts from other POS stations nearby,
examines the URI request details such as amount, and decides whether to
send funds, initiating a bitcoin network transfer. The merchant and
customer then receive the transaction confirmations and are done with the
sale. Merchant and customer devices are kept private and secured in their
own possession.
The URI and other broadcast identification (Joe’s Grill #1) only contain
public information. However, a copycat broadcaster acting as MITM might
duplicate the broadcast simultaneously as the merchant, attempting to lure
the customer to send funds to the copycat. That attack is mitigated with
this broadcast method because of the partial address in the broadcast.
Specification
Requester generates a bitcoin URI request of variable length, and a limited
descriptive identifier string. Requester then broadcasts the URI’s partial
public address (<paddress>) plus identifier (<id>) over a publicly visible
wireless channel.
Sender scans for broadcasts on their device, examines and selects the
desired request by the identifier and partial address. This connects a data
channel to Requester.
Requester sends full URI back over the data channel.
Sender device ensures <paddress> is part of the full URI public address and
checks the full address integrity. Checking the broadcast and full URI
integrity prevents a copycat device within range from copying the partial
address and fooling the customer into sending funds to the copycat instead.
Below is a description of the protocol through Bluetooth Smart (Low Energy).
Requestor Sender - Bitcoin transaction roles
Peripheral Central - Bluetooth GAP definitions
Mode Mode
1 |------------->| - Requestor Advertises partial bitcoin: URI +
Name
| ... |
2 |<-------------| - Subscribe then send sender's Name, requesting
a response
3 |------------->| - ACK
4 |<-------------| - request Read Characteristic from peripheral
5 |------------->| - Sender receives full bitcoin: URI
1.
Peripheral advertises over a service UUID a BLE extended advertisement
with a Scan Response containing the partial address of a bitcoin URI and a
Name, any plain text. The entire response is limited to 26 characters. The
first 10 make up the first 10 characters of the bitcoin URI public address
where to send bitcoin, and must be present. The remaining characters are
any plain text such as “The Habit 1” or “Starbucks-Reg 1”, more human
readable information. The partial address serves as a check against a
nearby attacker who may try to lure a Sender into sending payment to a
separate wallet by advertising a similar Scan Response but cannot replicate
a public address with the same leading 10 characters and different trailing
characters.
2.
When the Central scans the advertisement, it may display the Scan
Response in a human readable listing using the two pieces of information.
If Central chooses this advertisement to receive the full request, it then
subscribes to the service and writes the characteristic (a second UUID)
with it’s own name, or a blank if not sending a name, to the Peripheral.
3.
Peripheral gets a characteristic write request of the Central’s name,
and acknowledges the receipt by sending a server response.
4.
Central receives a characteristic write (from the response) and
immediately requests the entire bitcoin URI by issuing a read request on
that characteristic.
5.
Peripheral receives the read request and sends the entire bitcoin URI
over that characteristic up to 512 bytes.
This ends the proposed specification as the bitcoin URI transfer is
complete. The Sender would then normally confirm the request and decide
whether to initiate the fund transfer.
Compatibility
There are no prior BIPs covering this.
Examples
Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.
References
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
[-- Attachment #2: Type: text/html, Size: 22612 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 8:01 [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI Paul Puey
@ 2015-02-05 13:46 ` Andreas Schildbach
2015-02-05 13:57 ` Mike Hearn
0 siblings, 1 reply; 43+ messages in thread
From: Andreas Schildbach @ 2015-02-05 13:46 UTC (permalink / raw)
To: bitcoin-development
Thanks Paul, for writing up your protocol!
First thoughts:
For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
publish BIP70 payment requests instead. URIs mainly stick around because
of QR codes limited capacity. BIP70 would partly address the "copycat"
problem by signing payment requests.
In your Motivation section, I miss some words about NFC. NFC already
addresses all of the usability issues mentioned and is supported by
mobile wallets since 2011. That doesn't mean your method doesn't make
sense in some situations, but I think it should be explained why to
prefer broadcasting payment requests over picking them up via near field
radio.
On 02/05/2015 09:01 AM, Paul Puey wrote:
> Airbitz has developed and implemented a method for communicating a
> bitcoin URI across Bluetooth (BLE) or any other P2P, mid range,
> wireless, broadcast medium. The currently documented implementation is
> available in our iOS and Android mobile wallet (updated Android version
> with BLE coming in about 1 week). We would like to have the BIP pulled
> into Github for review and discussion. Here is the current BIP:
>
>
> BIP: TBD
>
> Title: P2P Wireless URI transfer
>
> Authors: Thomas Baker <tom’at’airbitz.co <http://airbitz.co>>, Paul Puey
> <paul’at’airbitz.co <http://airbitz.co>>
>
> Contributors: Joey Krug <joeykrug’at’gmail.com <http://gmail.com>>
>
> Status: proposal
>
> Type: Standards Track
>
> Created: 2015-01-12
>
>
> Table of Contents
>
> *
>
> Abstract
>
> *
>
> Motivation
>
> *
>
> Specification
>
> *
>
> Compatibility
>
> *
>
> Examples
>
> *
>
> References
>
>
> Abstract
>
> This is a protocol for peer-to-peer wireless transfer of a URI request
> using an open broadcast or advertisement channel such as Bluetooth,
> Bluetooth Low Energy, or WiFi Direct.
>
>
> Motivation
>
> There are disadvantages for a merchant (requester) and customer (sender)
> to exchange a URI request using QR codes that can be eliminated by using
> wireless broadcast or advertisements.
>
> Current QR code scan method to transfer a request URI from merchant
> (Requester) to customer (Sender) is cumbersome. A usual scenario is a
> merchant with a POS terminal for order entry and a separate tablet for
> transacting payments with bitcoin, and a customer with a smartphone.
> After the order is entered, the merchant enters payment request
> information into the tablet, generates the QR code representing the URI,
> and presents this to the customer. The customer prepares to scan the QR
> code with their smartphone by maneuvering the camera to the tablet. The
> tablet screen must be relatively clean, point at the customer, and held
> steady. The smartphone camera lens must be clean, point at the tablet
> screen, come into range, and held steady to focus and wait for a QR
> scan. Environmental conditions such as bright outdoor sunlight, indoor
> spot lights, or significant distance between QR code and camera can
> create difficult and cumbersome experiences for users.
>
> Using a wireless local broadcast allows the merchant to just enter the
> payment and wait. The tablet and smartphone are not maneuvered to align
> in any way. The customer observes broadcast listings, selects the
> appropriate one from possible simultaneous broadcasts from other POS
> stations nearby, examines the URI request details such as amount, and
> decides whether to send funds, initiating a bitcoin network transfer.
> The merchant and customer then receive the transaction confirmations and
> are done with the sale. Merchant and customer devices are kept private
> and secured in their own possession.
>
> The URI and other broadcast identification (Joe’s Grill #1) only contain
> public information. However, a copycat broadcaster acting as MITM might
> duplicate the broadcast simultaneously as the merchant, attempting to
> lure the customer to send funds to the copycat. That attack is mitigated
> with this broadcast method because of the partial address in the broadcast.
>
>
> Specification
>
> Requester generates a bitcoin URI request of variable length, and a
> limited descriptive identifier string. Requester then broadcasts the
> URI’s partial public address (<paddress>) plus identifier (<id>) over a
> publicly visible wireless channel.
>
> Sender scans for broadcasts on their device, examines and selects the
> desired request by the identifier and partial address. This connects a
> data channel to Requester.
>
> Requester sends full URI back over the data channel.
>
> Sender device ensures <paddress> is part of the full URI public address
> and checks the full address integrity. Checking the broadcast and full
> URI integrity prevents a copycat device within range from copying the
> partial address and fooling the customer into sending funds to the
> copycat instead.
>
> Below is a description of the protocol through Bluetooth Smart (Low Energy).
>
> Requestor Sender - Bitcoin transaction roles
>
> Peripheral Central - Bluetooth GAP definitions
>
> Mode Mode
>
> 1 |------------->| - Requestor Advertises partial bitcoin: URI +
> Name
>
> | ... |
>
> 2 |<-------------| - Subscribe then send sender's Name,
> requesting a response
>
> 3 |------------->| - ACK
>
> 4 |<-------------| - request Read Characteristic from peripheral
>
> 5 |------------->| - Sender receives full bitcoin: URI
>
>
> 1.
>
> Peripheral advertises over a service UUID a BLE extended
> advertisement with a Scan Response containing the partial address of
> a bitcoin URI and a Name, any plain text. The entire response is
> limited to 26 characters. The first 10 make up the first 10
> characters of the bitcoin URI public address where to send bitcoin,
> and must be present. The remaining characters are any plain text
> such as “The Habit 1” or “Starbucks-Reg 1”, more human readable
> information. The partial address serves as a check against a nearby
> attacker who may try to lure a Sender into sending payment to a
> separate wallet by advertising a similar Scan Response but cannot
> replicate a public address with the same leading 10 characters and
> different trailing characters.
>
> 2.
>
> When the Central scans the advertisement, it may display the Scan
> Response in a human readable listing using the two pieces of
> information. If Central chooses this advertisement to receive the
> full request, it then subscribes to the service and writes the
> characteristic (a second UUID) with it’s own name, or a blank if not
> sending a name, to the Peripheral.
>
> 3.
>
> Peripheral gets a characteristic write request of the Central’s
> name, and acknowledges the receipt by sending a server response.
>
> 4.
>
> Central receives a characteristic write (from the response) and
> immediately requests the entire bitcoin URI by issuing a read
> request on that characteristic.
>
> 5.
>
> Peripheral receives the read request and sends the entire bitcoin
> URI over that characteristic up to 512 bytes.
>
> This ends the proposed specification as the bitcoin URI transfer is
> complete. The Sender would then normally confirm the request and decide
> whether to initiate the fund transfer.
>
>
> Compatibility
>
> There are no prior BIPs covering this.
>
>
> Examples
>
> Airbitz iOS Bluetooth Low Energy to Bluetooth Low Energy request transfer.
>
>
> References
>
>
>
>
>
> logo
> *Paul Puey* CEO / Co-Founder, Airbitz Inc
> +1-619-850-8624 | http://airbitz.co <http://airbitz.co/> | San Diego
> <http://facebook.com/airbitz> <http://twitter.com/airbitz> <https://plus.google.com/118173667510609425617> <https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey> <https://angel.co/paul-puey>
>
> *DOWNLOAD THE AIRBITZ WALLET:*
>
> <https://play.google.com/store/apps/details?id=com.airbitz><https://itunes.apple.com/us/app/airbitz/id843536046>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 13:46 ` Andreas Schildbach
@ 2015-02-05 13:57 ` Mike Hearn
0 siblings, 0 replies; 43+ messages in thread
From: Mike Hearn @ 2015-02-05 13:57 UTC (permalink / raw)
To: Andreas Schildbach; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead.
>
Agreed - it's not clear to me at all that this partial address scheme is
actually secure. The assumption appears to be that the MITM must match the
address prefix generated by the genuine merchant. But if they can do a
wireless MITM they can just substitute their own address prefix/partial
address, no?
To avoid MITM attacks the sender must know who they are sending money to,
and that means they must see a human understandable name that's
cryptographically bound to the right public key. Displaying partial
addresses to the user is not going to solve this unless users manually
compare key prefixes across the screens.... which is even less convenient
than a QR code.
I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
>
This is probably an artifact of Apple's restrictions on iOS. Only the
iPhone 6 has NFC hardware and Apple don't expose it via any public API. It
can however support Bluetooth LE.
Apple isn't a big deal in Germany because iPhone only achieved about 17%
market share during the quarter when the iPhone 6 launched. Normally it's
closer to 10-13%. Most other markets are similar.
However in the USA, UK, Australia and Japan iOS is still a big deal and NFC
is going to be seen as a non-universal solution there. At least, until
Apple catches up and provides an NFC API.
It's certainly not a problem to have a working radio based broadcast
system, though the theoretician in me wonders what happens when lots of
people are trying to pay simultaneously for something that has equal cost
..... e.g. buying movie tickets at a counter. NFC and QR codes prevent any
kind of "oops I paid for someone elses stuff" confusion.
In practice of course Bitcoin payments are not normally popular enough for
this to be a problem outside of Bitcoin community events.
[-- Attachment #2: Type: text/html, Size: 2528 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-10 17:16 ` MⒶrtin HⒶboⓋštiak
@ 2015-02-10 17:56 ` Eric Voskuil
0 siblings, 0 replies; 43+ messages in thread
From: Eric Voskuil @ 2015-02-10 17:56 UTC (permalink / raw)
To: MⒶrtin HⒶboⓋštiak; +Cc: Bitcoin Dev, Paul Puey
[-- 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-10 16:55 ` Eric Voskuil
@ 2015-02-10 17:16 ` MⒶrtin HⒶboⓋštiak
2015-02-10 17:56 ` Eric Voskuil
0 siblings, 1 reply; 43+ messages in thread
From: MⒶrtin HⒶboⓋštiak @ 2015-02-10 17:16 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
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, 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.
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.
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.
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
>>>>>>>
>>>>
>>>>
>>>
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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
0 siblings, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-10 16:55 UTC (permalink / raw)
To: MⒶrtin HⒶboⓋštiak; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 8185 bytes --]
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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-06 8:59 ` Roy Badami
@ 2015-02-06 9:13 ` Eric Voskuil
0 siblings, 0 replies; 43+ messages in thread
From: Eric Voskuil @ 2015-02-06 9:13 UTC (permalink / raw)
To: Roy Badami; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
On 02/06/2015 12:59 AM, Roy Badami wrote:
>> In this case there is no need for P2P communication, just pay to an
>> address you already have for the other party. If you want to avoid
>> address reuse, use stealth addressing.
>>
>> But yes, if you don't have a stealth address for the other party you can
>> certainly communicate in private as peers where you trust that you share
>> a public key. The core issue here is really bootstrapping of that trust
>> in an ad hoc manner.
>
> Something interactive might still be nicer, though, to avoid the risk
> of paying to an address that the payee no longer has the private key
> for. "Nooo!! Don't pay to that address. I lost my old phone so I
> generated a new wallet."
Certainly, which brings us back to proximity.
Which reminds me - it's important to keep in mind the scenario that
arises when there is no person present to represent the receiver. Such
as a vending machine purchase.
Proximity in these cases is insufficient, as the receiver is not able to
prevent application of a fraudulent NFC device or replacement of a
static QR code. In these cases BIP-70 becomes essential.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-06 1:29 ` Eric Voskuil
@ 2015-02-06 9:07 ` MⒶrtin HⒶboⓋštiak
2015-02-10 16:55 ` Eric Voskuil
0 siblings, 1 reply; 43+ messages in thread
From: MⒶrtin HⒶboⓋštiak @ 2015-02-06 9:07 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
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
>>>>>
>>
>>
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 23:59 ` Eric Voskuil
@ 2015-02-06 8:59 ` Roy Badami
2015-02-06 9:13 ` Eric Voskuil
0 siblings, 1 reply; 43+ messages in thread
From: Roy Badami @ 2015-02-06 8:59 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
> In this case there is no need for P2P communication, just pay to an
> address you already have for the other party. If you want to avoid
> address reuse, use stealth addressing.
>
> But yes, if you don't have a stealth address for the other party you can
> certainly communicate in private as peers where you trust that you share
> a public key. The core issue here is really bootstrapping of that trust
> in an ad hoc manner.
Something interactive might still be nicer, though, to avoid the risk
of paying to an address that the payee no longer has the private key
for. "Nooo!! Don't pay to that address. I lost my old phone so I
generated a new wallet."
roy
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-06 1:05 ` Eric Voskuil
@ 2015-02-06 2:09 ` Paul Puey
0 siblings, 0 replies; 43+ messages in thread
From: Paul Puey @ 2015-02-06 2:09 UTC (permalink / raw)
To: Eric Voskuil; +Cc: William Swanson, Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3553 bytes --]
Thanks for all the feedback Eric. You know we value all that you have to say. That's what this forum is for. We're looking for great ideas to harden this protocol and we're not closed to better ideas and we'll improve it as suggestions come up.
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.8624 | http://airbitz.co | San Diego
On Feb 5, 2015, at 5:05 PM, Eric Voskuil <eric@voskuil•org> wrote:
> On 02/05/2015 04:49 PM, Paul Puey wrote:
> The trust can be considered bootstrapped by visual verification of the
> address prefix.
Another (unspendable) address can trivially match the prefix. Imagine
someone walking around in a mall with a phone in the pocket with a
malicious app, just disrupting business by causing money to be burned.
Manual verification doesn't fix this attack.
> If we are really concerned about someone jamming a Bluetooth signal
> in a coffeeshop then the UI can encourage verification of the prefix.
I don't think it would be great to constrain a standard implementation
to low cost purchases or the need for manual verification, but again
manual prefix verification isn't actually a solution.
> Much like how regular Bluetooth requires 'pairing' via entering a 4-6
> digit code.
An appeal to the security of BT bootstrapping isn't exactly flattering.
You know I love Airbitz, and I know you guys are extremely privacy
conscious. I personally would have no problem using this feature under
certain circumstances. My question is only whether it would be wise to
standardize on the proposal as-is.
e
> On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric@voskuil•org
> <mailto:eric@voskuil•org>> wrote:
>
> 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: Type: text/html, Size: 10371 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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
0 siblings, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-06 1:29 UTC (permalink / raw)
To: Martin Habovštiak; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 6187 bytes --]
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.
> 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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
1 sibling, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-06 1:05 UTC (permalink / raw)
To: Paul Puey, William Swanson; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]
On 02/05/2015 04:49 PM, Paul Puey wrote:
> The trust can be considered bootstrapped by visual verification of the
> address prefix.
Another (unspendable) address can trivially match the prefix. Imagine
someone walking around in a mall with a phone in the pocket with a
malicious app, just disrupting business by causing money to be burned.
Manual verification doesn't fix this attack.
> If we are really concerned about someone jamming a Bluetooth signal
> in a coffeeshop then the UI can encourage verification of the prefix.
I don't think it would be great to constrain a standard implementation
to low cost purchases or the need for manual verification, but again
manual prefix verification isn't actually a solution.
> Much like how regular Bluetooth requires 'pairing' via entering a 4-6
> digit code.
An appeal to the security of BT bootstrapping isn't exactly flattering.
You know I love Airbitz, and I know you guys are extremely privacy
conscious. I personally would have no problem using this feature under
certain circumstances. My question is only whether it would be wise to
standardize on the proposal as-is.
e
> On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric@voskuil•org
> <mailto:eric@voskuil•org>> wrote:
>
> 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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 23:34 ` Roy Badami
2015-02-05 23:59 ` Eric Voskuil
@ 2015-02-06 0:58 ` Paul Puey
1 sibling, 0 replies; 43+ messages in thread
From: Paul Puey @ 2015-02-06 0:58 UTC (permalink / raw)
To: Roy Badami; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4662 bytes --]
Although consumer to merchant is a use case for BLE I would argue that NFC has a higher chance of providing a better user experience in most cases since, at least on Android, a user can tap their phone without even having a wallet running. The URI handler will launch the wallet for them. However a dedicated, user facing, screen can give certainty that the user is connecting to the correct recipient.
1. Because it can show an address prefix
2. It can display the users nickname/handle upon connecting which is only sent to the merchant upon a point to point connection. Not a broadcast.
The Airbitz wallet already does this on the recipient side. A popup shows the most recent person connecting to the recipient.
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.8624 | http://airbitz.co | San Diego
On Feb 5, 2015, at 3:34 PM, Roy Badami <roy@gnomon•org.uk> wrote:
For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying. You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.
As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there". It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it). OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.
Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.
roy
> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the
>> original. You then only see one.
>
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>
> -William
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 10836 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-06 0:49 ` Paul Puey
@ 2015-02-06 0:50 ` Martin Habovštiak
2015-02-06 1:05 ` Eric Voskuil
1 sibling, 0 replies; 43+ messages in thread
From: Martin Habovštiak @ 2015-02-06 0:50 UTC (permalink / raw)
To: Paul Puey, Eric Voskuil, William Swanson; +Cc: Bitcoin Dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Commit protocol provides both better user experience and better security.
Dňa 6. februára 2015 1:49:12 CET používateľ Paul Puey <paul@airbitz•co> napísal:
>The trust can be considered bootstrapped by visual verification of the
>address prefix. If we are really concerned about someone jamming a
>Bluetooth signal in a coffeeshop then the UI can encourage verification
>of the prefix. Much like how regular Bluetooth requires 'pairing' via
>entering a 4-6 digit code.
>
>
>
>Paul Puey CEO / Co-Founder, Airbitz Inc
>619.850.8624 | http://airbitz.co | San Diego
>
>
>
>
>On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric@voskuil•org> wrote:
>
>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
- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iI8EAREKADcFAlTUD/AwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUPwgA/0eVlJYeA3fYmVb1zVA8j1l/
kjOhc9CIDYL9ifk8N0t/AP4mC4CwmZoNXqr24le5WdYeBeyHMiDMtJrRfwQkN1LG
dQ==
=pY76
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 23:46 ` Eric Voskuil
2015-02-06 0:04 ` MⒶrtin HⒶboⓋštiak
@ 2015-02-06 0:49 ` Paul Puey
2015-02-06 0:50 ` Martin Habovštiak
2015-02-06 1:05 ` Eric Voskuil
1 sibling, 2 replies; 43+ messages in thread
From: Paul Puey @ 2015-02-06 0:49 UTC (permalink / raw)
To: Eric Voskuil, William Swanson; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2296 bytes --]
The trust can be considered bootstrapped by visual verification of the address prefix. If we are really concerned about someone jamming a Bluetooth signal in a coffeeshop then the UI can encourage verification of the prefix. Much like how regular Bluetooth requires 'pairing' via entering a 4-6 digit code.
Paul Puey CEO / Co-Founder, Airbitz Inc
619.850.8624 | http://airbitz.co | San Diego
On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric@voskuil•org> wrote:
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: Type: text/html, Size: 6985 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-06 0:22 ` Eric Voskuil
@ 2015-02-06 0:36 ` Martin Habovštiak
2015-02-06 1:29 ` Eric Voskuil
0 siblings, 1 reply; 43+ messages in thread
From: Martin Habovštiak @ 2015-02-06 0:36 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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. :)
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.
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.)
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
>>>
- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8
uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa
zQ==
=J4w/
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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
0 siblings, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-06 0:22 UTC (permalink / raw)
To: MⒶrtin HⒶboⓋštiak; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 3940 bytes --]
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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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:49 ` Paul Puey
1 sibling, 1 reply; 43+ messages in thread
From: MⒶrtin HⒶboⓋštiak @ 2015-02-06 0:04 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
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. :)
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.
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.
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
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 23:34 ` Roy Badami
@ 2015-02-05 23:59 ` Eric Voskuil
2015-02-06 8:59 ` Roy Badami
2015-02-06 0:58 ` Paul Puey
1 sibling, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 23:59 UTC (permalink / raw)
To: Roy Badami, William Swanson; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]
On 02/05/2015 03:34 PM, Roy Badami wrote:
> For peer-to-peer payments, how common do we think that the payment is
> of an ad hoc nature rather than to a known contact?
>
> If I want to pay my friends/colleagues/etc over a restaurant table
> there's no reason why I couldn't already have their public keys in my
> contact list - then it would be pretty straightforward to have a
> watertight mechanism where I would know who I was paying. You could
> probably even relatively securely bootstrap a key exchange over SMS,
> relying only on the contacts already having each other in their
> phonebooks.
In this case there is no need for P2P communication, just pay to an
address you already have for the other party. If you want to avoid
address reuse, use stealth addressing.
But yes, if you don't have a stealth address for the other party you can
certainly communicate in private as peers where you trust that you share
a public key. The core issue here is really bootstrapping of that trust
in an ad hoc manner.
> As for comsumer-to-merchant transactions where the merchant is a
> bricks and mortar merchant, IMHO it absolutely has to be "pay that
> terminal over there". It's the trust model we all currently use -
> whether paying cash or card - and it's the only trust model that works
> IMHO (and customers and businesses alike are well aware of the risks
> of a fraudster standing behind the counter pretending to be an
> employee accepting payment - and by and large are pretty good at
> mitigating it). OTOH as we've discussed here before there are many
> use cases where the custoemr doesn't actually know or care about the
> name of the shop or bar they walked into but is pretty damn sure that
> they need to make payment to the person over there behind the counter.
Yes, proximity is practically the universal solution to the problem of
the payer identifying the correct seller in any face-to-face scenario.
> Granted, there are cases taht dont' fall into either of the above -
> but they're the cases that are (a) harder to figure out how to
> authenticate and consequently (b) the use cases that are going to be
> most subject to attempted fraud.
When identification is required (show me some id before I pay you) it
equates to the BIP-70 scenario in the bitcoin model. This is also
required in order guard against repudiation (give me a signed receipt).
> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric@voskuil•org> wrote:
>>> A MITM can receive the initial broadcast and then spoof it by jamming the
>>> original. You then only see one.
>>
>> You are right, of course. There is no way to make Bluetooth 100%
>> secure, since it is an over-the-air technology. You could try securing
>> it using a CA or other identity server, but now you've excluded ad-hoc
>> person-to-person payments. Plus, you need an active internet
>> connection to reach the CA.
>>
>> You can try using proximity as a substitute for identity, like
>> requiring NFC to kick-start the connection, but at that point you
>> might as well use QR codes.
>>
>> This BIP is not trying to provide absolute bullet-proof security,
>> since that's impossible given the physical limitations of the
>> Bluetooth technology. Instead, it's trying to provide the
>> best-possible security given those constraints. In exchange for this,
>> we get greatly enhanced usability in common scenarios.
>>
>> There are plenty of usable, real-world technologies with big security
>> holes. Anybody with lock-picking experience will tell you this, but
>> nobody is welding their front door shut. The ability to go in and out
>> is worth the security risk.
>>
>> Bluetooth payments add a whole new dimension to real-world Bitcoin
>> usability. Do we shut that down because it can't be made perfect, or
>> do we do the best we can and move forward?
>>
>> -William
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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:49 ` Paul Puey
0 siblings, 2 replies; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 23:46 UTC (permalink / raw)
To: MⒶrtin HⒶboⓋštiak; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]
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 --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 23:22 ` Eric Voskuil
@ 2015-02-05 23:36 ` MⒶrtin HⒶboⓋštiak
2015-02-05 23:46 ` Eric Voskuil
0 siblings, 1 reply; 43+ messages in thread
From: MⒶrtin HⒶboⓋštiak @ 2015-02-05 23:36 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
> 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)?
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 23:02 ` William Swanson
@ 2015-02-05 23:34 ` Roy Badami
2015-02-05 23:59 ` Eric Voskuil
2015-02-06 0:58 ` Paul Puey
0 siblings, 2 replies; 43+ messages in thread
From: Roy Badami @ 2015-02-05 23:34 UTC (permalink / raw)
To: William Swanson; +Cc: Bitcoin Dev, Paul Puey
For peer-to-peer payments, how common do we think that the payment is
of an ad hoc nature rather than to a known contact?
If I want to pay my friends/colleagues/etc over a restaurant table
there's no reason why I couldn't already have their public keys in my
contact list - then it would be pretty straightforward to have a
watertight mechanism where I would know who I was paying. You could
probably even relatively securely bootstrap a key exchange over SMS,
relying only on the contacts already having each other in their
phonebooks.
As for comsumer-to-merchant transactions where the merchant is a
bricks and mortar merchant, IMHO it absolutely has to be "pay that
terminal over there". It's the trust model we all currently use -
whether paying cash or card - and it's the only trust model that works
IMHO (and customers and businesses alike are well aware of the risks
of a fraudster standing behind the counter pretending to be an
employee accepting payment - and by and large are pretty good at
mitigating it). OTOH as we've discussed here before there are many
use cases where the custoemr doesn't actually know or care about the
name of the shop or bar they walked into but is pretty damn sure that
they need to make payment to the person over there behind the counter.
Granted, there are cases taht dont' fall into either of the above -
but they're the cases that are (a) harder to figure out how to
authenticate and consequently (b) the use cases that are going to be
most subject to attempted fraud.
roy
On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric@voskuil•org> wrote:
> > A MITM can receive the initial broadcast and then spoof it by jamming the
> > original. You then only see one.
>
> You are right, of course. There is no way to make Bluetooth 100%
> secure, since it is an over-the-air technology. You could try securing
> it using a CA or other identity server, but now you've excluded ad-hoc
> person-to-person payments. Plus, you need an active internet
> connection to reach the CA.
>
> You can try using proximity as a substitute for identity, like
> requiring NFC to kick-start the connection, but at that point you
> might as well use QR codes.
>
> This BIP is not trying to provide absolute bullet-proof security,
> since that's impossible given the physical limitations of the
> Bluetooth technology. Instead, it's trying to provide the
> best-possible security given those constraints. In exchange for this,
> we get greatly enhanced usability in common scenarios.
>
> There are plenty of usable, real-world technologies with big security
> holes. Anybody with lock-picking experience will tell you this, but
> nobody is welding their front door shut. The ability to go in and out
> is worth the security risk.
>
> Bluetooth payments add a whole new dimension to real-world Bitcoin
> usability. Do we shut that down because it can't be made perfect, or
> do we do the best we can and move forward?
>
> -William
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
2015-02-05 23:02 ` William Swanson
@ 2015-02-05 23:22 ` Eric Voskuil
2015-02-05 23:36 ` MⒶrtin HⒶboⓋštiak
2 siblings, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 23:22 UTC (permalink / raw)
To: Paul Puey; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5423 bytes --]
On 02/05/2015 02:08 PM, Paul Puey wrote:
> Although not perfect, and it may require visual/verbal verification,
> I don't see what the trust issue is.
I agree that with manual verification between the parties the worst
problem becomes DOS, which is certainly not catastrophic.
But the objective is to the extent possible improve upon the cumbersome
process of QR code, NFC signal, or textual address scanning. Given that
there would be no way to know you are under attack, with the exception
of manual confirmation, it would seem unwise to ever rely on the
automation. If the automation cannot be relied upon, it may actually
make matters worse. People would either take their chances by relying on
it or go through a more complex process.
In terms of the difficulty of an attack, it's important to recognize
that all attacks (DOS, privacy, integrity) in this scenario can be
fully-automated and executed over the air by a black box at some distance:
* DOS is possible by rebroadcasting a similar request.
* Privacy is compromised by monitoring for payment requests and
correlating them to location and potentially images of parties.
* Integrity is compromised by either:
(1) Rebroadcasting a similar transaction with a bogus address but with
the same leading characters; can't be spent but you lose your money.
(2) Rebroadcasting with a valid address that doesn't match the leading
characters, in the expectation that the user doesn't check manually.
Regarding possible mitigation via BIP-70:
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.
So the initial broadcast needs privacy, but then of course it cannot be
a broadcast - it need to be a narrow cast. That brings us back to
proximity-based establishment.
I think that you could get away with this for a while, simply because of
the narrow fields we are working in presently. But in a bitcoin world it
would be very problematic. For this reason I wouldn't want to encourage
standardization on this approach.
e
On 02/05/2015 02:10 PM, Eric Voskuil wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming
> the original. You then only see one.
>
> e
>
> On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz•co
> <mailto:paul@airbitz•co>> wrote:
>
>> So if you picked up the BLE broadcast request. All you know is that
>> *someone* within 100m is requesting bitcoin at a certain address. Not
>> necessarily who. The *name* is both optional, and possibly just a
>> *handle* of the user. If I'm sitting 5 ft away from someone at dinner
>> and wanted to pay them via BLE, I might see "Monkey Dude" on my list
>> and simply ask him "is that you?" If so, I send it. If there are two
>> "Monkey Dude's" Then I have to bother with the address prefix, but not
>> otherwise.
>>
>> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil•org
>> <mailto:eric@voskuil•org>> wrote:
>>
>> BLE has an advertised range of over 100m.
>>
>> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>>
>> In the case of mass surveillance that range could most likely be
>> extended dramatically by the reviewer. I've seen WiFi ranges of
>> over a mile with a strong (not FCC approved) receiver.
>>
>> WiFi hotspots don't have strong identity or a guaranteed position,
>> so they can't be trusted for location.
>>
>> e
>>
>> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99•net
>> <mailto:mike@plan99•net>> wrote:
>>
>>> This sounds horrible. You could basically monitor anyone with
>>> a wallet in a highly populated area and track them super
>>> easily by doing facial recognition.
>>>
>>>
>>> We're talking about BLE, still? The radio tech that runs in the
>>> so called "junk bands" because propagation is so poor?
>>>
>>> My watch loses its connection to my phone if I just put it down
>>> and walk around my apartment. I'm all for reasonable paranoia,
>>> but Bluetooth isn't going to be enabling mass surveillance any
>>> time soon. It barely goes through air, let alone walls.
>>>
>>> Anyway, whatever. I'm just bouncing around ideas for faster user
>>> interfaces. You could always switch it off or set it to be
>>> triggered by the presence of particular wifi hotspots, if you
>>> don't mind an initial bit of setup.
>>>
>>> Back on topic - the debate is interesting, but I think to get
>>> this to the stage of being a BIP we'd need at least another
>>> wallet to implement it? Then I guess a BIP would be useful
>>> regardless of the design issues. The prefix matching still feels
>>> flaky to me but it's hard to know if you could really swipe
>>> payments out of the air in practice, without actually trying it.
>>>
>>>
>>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 22:49 ` Roy Badami
@ 2015-02-05 23:22 ` MⒶrtin HⒶboⓋštiak
0 siblings, 0 replies; 43+ messages in thread
From: MⒶrtin HⒶboⓋštiak @ 2015-02-05 23:22 UTC (permalink / raw)
To: Roy Badami; +Cc: Bitcoin Dev, Paul Puey
I would like to shortly express my opinion:
- Having BT as an alternative is good idea but it must be secure enough
- Signed BIP70 should be enough. I see only two issues regarding BIP70
(but they apply also to TCP/IP, not just BT): key revocations and MITM
attacks by governments.
- Broadcasting faces is very bad idea IMHO.
- Comparing addresses seems complicated but if hash was displayed as a
unique, picture hard to be mistake or long phrase, it could be more
convenient.
- Maybe storing public key (I do NOT mean bitcoin address!) of
merchant after successful transaction is good compromise?
Another idea: I noticed it's extremely easy to compare two strings if
they are the same size (in terms of millimeters, not number of
characters). If the hash of signing key was printed on a sign near the
POS in specified size (90% of smallest available screen?) and phone
would scale correctly, just putting the phone near the sign would be
enough to instantly spot whether the hashes are same.
Maybe instead of hex/base58 hash encoding use colored barcode. But I'm
not sure if it would improve things.
2015-02-05 23:49 GMT+01:00 Roy Badami <roy@gnomon•org.uk>:
> Personally I like the simplicity of tapping two phones together to
> make payment - it should be quicker and easier than scanning QR codes
> and it's a trust model that's hard to misunderstand.
>
> Is NFC good enough for that? I fear even with NFC it is possible to
> produce a device with longer range than one would expect. What
> happened to the idea of tapping two devices together and then
> comparing the timing of the tap (as detected by the phones'
> accelerometers) to make spoofing a transaction harder? I remember
> hearing about that years ago - is that still a thing?
>
> roy
>
> On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
>>
>> e
>>
>> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz•co> wrote:
>> >
>> > So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
>> >
>> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> >> BLE has an advertised range of over 100m.
>> >>
>> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>> >>
>> >> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
>> >>
>> >> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
>> >>
>> >> e
>> >>
>> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99•net> wrote:
>> >>
>> >>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
>> >>>
>> >>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
>> >>>
>> >>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
>> >>>
>> >>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
>> >>>
>> >>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
>> >
>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
@ 2015-02-05 23:02 ` William Swanson
2015-02-05 23:34 ` Roy Badami
2015-02-05 23:22 ` Eric Voskuil
2 siblings, 1 reply; 43+ messages in thread
From: William Swanson @ 2015-02-05 23:02 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil <eric@voskuil•org> wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming the
> original. You then only see one.
You are right, of course. There is no way to make Bluetooth 100%
secure, since it is an over-the-air technology. You could try securing
it using a CA or other identity server, but now you've excluded ad-hoc
person-to-person payments. Plus, you need an active internet
connection to reach the CA.
You can try using proximity as a substitute for identity, like
requiring NFC to kick-start the connection, but at that point you
might as well use QR codes.
This BIP is not trying to provide absolute bullet-proof security,
since that's impossible given the physical limitations of the
Bluetooth technology. Instead, it's trying to provide the
best-possible security given those constraints. In exchange for this,
we get greatly enhanced usability in common scenarios.
There are plenty of usable, real-world technologies with big security
holes. Anybody with lock-picking experience will tell you this, but
nobody is welding their front door shut. The ability to go in and out
is worth the security risk.
Bluetooth payments add a whole new dimension to real-world Bitcoin
usability. Do we shut that down because it can't be made perfect, or
do we do the best we can and move forward?
-William
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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:22 ` Eric Voskuil
2 siblings, 1 reply; 43+ messages in thread
From: Roy Badami @ 2015-02-05 22:49 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
Personally I like the simplicity of tapping two phones together to
make payment - it should be quicker and easier than scanning QR codes
and it's a trust model that's hard to misunderstand.
Is NFC good enough for that? I fear even with NFC it is possible to
produce a device with longer range than one would expect. What
happened to the idea of tapping two devices together and then
comparing the timing of the tap (as detected by the phones'
accelerometers) to make spoofing a transaction harder? I remember
hearing about that years ago - is that still a thing?
roy
On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
> A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
>
> e
>
> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz•co> wrote:
> >
> > So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
> >
> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil•org> wrote:
> >> BLE has an advertised range of over 100m.
> >>
> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
> >>
> >> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
> >>
> >> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
> >>
> >> e
> >>
> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99•net> wrote:
> >>
> >>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
> >>>
> >>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
> >>>
> >>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
> >>>
> >>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
> >>>
> >>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
> >
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 22:07 ` Paul Puey
@ 2015-02-05 22:10 ` Eric Voskuil
2015-02-05 22:49 ` Roy Badami
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 22:10 UTC (permalink / raw)
To: Paul Puey; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]
A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
e
> On Feb 5, 2015, at 2:07 PM, Paul Puey <paul@airbitz•co> wrote:
>
> So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
>
>> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil•org> wrote:
>> BLE has an advertised range of over 100m.
>>
>> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>>
>> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
>>
>> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
>>
>> e
>>
>> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99•net> wrote:
>>
>>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
>>>
>>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
>>>
>>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
>>>
>>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
>>>
>>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
>
[-- Attachment #2: Type: text/html, Size: 3805 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 22:05 ` Eric Voskuil
@ 2015-02-05 22:08 ` Paul Puey
0 siblings, 0 replies; 43+ messages in thread
From: Paul Puey @ 2015-02-05 22:08 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]
Although not perfect, and it may require visual/verbal verification, I
don't see what the trust issue is.
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 2:05 PM, Eric Voskuil <eric@voskuil•org> wrote:
> Hi Paul,
>
> The issue is in the establishment of trust. Anyone can broadcast the
> initial information.
>
> e
>
> On Feb 5, 2015, at 2:01 PM, Paul Puey <paul@airbitz•co> wrote:
>
> The broadcast is ONLY done when the wallet is in Receive mode. Same as
> when the QR code is visible. The use of the *Name* section is specifically
> so that a recipient can broadcast their name/handle. Not so the recipient
> would broadcast the name of the Sender.
>
> On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn <mike@plan99•net> wrote:
>
>> I'm imagining myself walking around broadcasting my photo and MAC
>>> address while hucksters push payment requests to me for approval
>>
>>
>> I hate to break it to you, but you broadcast a photo of your face every
>> time you walk outside ;)
>>
>> Bluetooth MAC addresses are random, they aren't useful identifiers. If
>> someone can see you, a face is a far more uniquely identifying thing than a
>> MAC.
>>
>> "Payment spam" might be a problem. I can imagine a wallet requiring that
>> such requests are signed and then spammers can be blacklisted in the usual
>> fashion so they can't push things to your phone anymore. Anyway, a hurdle
>> that can be jumped if/when it becomes an issue.
>>
>
>
[-- Attachment #2: Type: text/html, Size: 6160 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 21:46 ` Eric Voskuil
@ 2015-02-05 22:07 ` Paul Puey
2015-02-05 22:10 ` Eric Voskuil
0 siblings, 1 reply; 43+ messages in thread
From: Paul Puey @ 2015-02-05 22:07 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2690 bytes --]
So if you picked up the BLE broadcast request. All you know is that
*someone* within 100m is requesting bitcoin at a certain address. Not
necessarily who. The *name* is both optional, and possibly just a *handle*
of the user. If I'm sitting 5 ft away from someone at dinner and wanted to
pay them via BLE, I might see "Monkey Dude" on my list and simply ask him
"is that you?" If so, I send it. If there are two "Monkey Dude's" Then I
have to bother with the address prefix, but not otherwise.
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric@voskuil•org> wrote:
> BLE has an advertised range of over 100m.
>
> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>
> In the case of mass surveillance that range could most likely be extended
> dramatically by the reviewer. I've seen WiFi ranges of over a mile with a
> strong (not FCC approved) receiver.
>
> WiFi hotspots don't have strong identity or a guaranteed position, so they
> can't be trusted for location.
>
> e
>
> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99•net> wrote:
>
> This sounds horrible. You could basically monitor anyone with a wallet in
>> a highly populated area and track them super easily by doing facial
>> recognition.
>>
>
> We're talking about BLE, still? The radio tech that runs in the so called
> "junk bands" because propagation is so poor?
>
> My watch loses its connection to my phone if I just put it down and walk
> around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't
> going to be enabling mass surveillance any time soon. It barely goes
> through air, let alone walls.
>
> Anyway, whatever. I'm just bouncing around ideas for faster user
> interfaces. You could always switch it off or set it to be triggered by the
> presence of particular wifi hotspots, if you don't mind an initial bit of
> setup.
>
> Back on topic - the debate is interesting, but I think to get this to the
> stage of being a BIP we'd need at least another wallet to implement it?
> Then I guess a BIP would be useful regardless of the design issues. The
> prefix matching still feels flaky to me but it's hard to know if you could
> really swipe payments out of the air in practice, without actually trying
> it.
>
>
>
[-- Attachment #2: Type: text/html, Size: 7208 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 22:01 ` Paul Puey
@ 2015-02-05 22:05 ` Eric Voskuil
2015-02-05 22:08 ` Paul Puey
0 siblings, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 22:05 UTC (permalink / raw)
To: Paul Puey; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]
Hi Paul,
The issue is in the establishment of trust. Anyone can broadcast the initial information.
e
> On Feb 5, 2015, at 2:01 PM, Paul Puey <paul@airbitz•co> wrote:
>
> The broadcast is ONLY done when the wallet is in Receive mode. Same as when the QR code is visible. The use of the *Name* section is specifically so that a recipient can broadcast their name/handle. Not so the recipient would broadcast the name of the Sender.
>
> On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn <mike@plan99•net> wrote:
>>> I'm imagining myself walking around broadcasting my photo and MAC
>>> address while hucksters push payment requests to me for approval
>>
>> I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;)
>>
>> Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC.
>>
>> "Payment spam" might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue.
>
[-- Attachment #2: Type: text/html, Size: 1973 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 21:19 ` Brian Hoffman
2015-02-05 21:23 ` Eric Voskuil
2015-02-05 21:36 ` Mike Hearn
@ 2015-02-05 22:02 ` Paul Puey
2 siblings, 0 replies; 43+ messages in thread
From: Paul Puey @ 2015-02-05 22:02 UTC (permalink / raw)
To: Brian Hoffman; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]
The implementation on Airbitz does not encourage or even let a user
broadcast a photo. Just an address prefix and "name/handle". And it's only
broadcast during the Receive request. Not generally while the app is
running although that's up to the implementation.
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 1:19 PM, Brian Hoffman <brianchoffman@gmail•com>
wrote:
> This sounds horrible. You could basically monitor anyone with a wallet in
> a highly populated area and track them super easily by doing facial
> recognition. Yes you could photograph people but it's way more burdensome.
> Sorry to go off topic a little.
>
>
> On Feb 5, 2015, at 3:50 PM, Mike Hearn <mike@plan99•net> wrote:
>
> I'm imagining myself walking around broadcasting my photo and MAC
>> address while hucksters push payment requests to me for approval
>
>
> I hate to break it to you, but you broadcast a photo of your face every
> time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If
> someone can see you, a face is a far more uniquely identifying thing than a
> MAC.
>
> "Payment spam" might be a problem. I can imagine a wallet requiring that
> such requests are signed and then spammers can be blacklisted in the usual
> fashion so they can't push things to your phone anymore. Anyway, a hurdle
> that can be jumped if/when it becomes an issue.
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 7001 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 20:50 ` Mike Hearn
2015-02-05 20:59 ` Eric Voskuil
2015-02-05 21:19 ` Brian Hoffman
@ 2015-02-05 22:01 ` Paul Puey
2015-02-05 22:05 ` Eric Voskuil
2 siblings, 1 reply; 43+ messages in thread
From: Paul Puey @ 2015-02-05 22:01 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
The broadcast is ONLY done when the wallet is in Receive mode. Same as when
the QR code is visible. The use of the *Name* section is specifically so
that a recipient can broadcast their name/handle. Not so the recipient
would broadcast the name of the Sender.
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn <mike@plan99•net> wrote:
> I'm imagining myself walking around broadcasting my photo and MAC
>> address while hucksters push payment requests to me for approval
>
>
> I hate to break it to you, but you broadcast a photo of your face every
> time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If
> someone can see you, a face is a far more uniquely identifying thing than a
> MAC.
>
> "Payment spam" might be a problem. I can imagine a wallet requiring that
> such requests are signed and then spammers can be blacklisted in the usual
> fashion so they can't push things to your phone anymore. Anyway, a hurdle
> that can be jumped if/when it becomes an issue.
>
[-- Attachment #2: Type: text/html, Size: 5338 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 21:36 ` Mike Hearn
@ 2015-02-05 21:46 ` Eric Voskuil
2015-02-05 22:07 ` Paul Puey
0 siblings, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 21:46 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]
BLE has an advertised range of over 100m.
http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
e
On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike@plan99•net> wrote:
>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
>
> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
>
> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
>
> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
>
> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
>
>
[-- Attachment #2: Type: text/html, Size: 2587 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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:02 ` Paul Puey
2 siblings, 1 reply; 43+ messages in thread
From: Mike Hearn @ 2015-02-05 21:36 UTC (permalink / raw)
To: Brian Hoffman; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1127 bytes --]
>
> This sounds horrible. You could basically monitor anyone with a wallet in
> a highly populated area and track them super easily by doing facial
> recognition.
>
We're talking about BLE, still? The radio tech that runs in the so called
"junk bands" because propagation is so poor?
My watch loses its connection to my phone if I just put it down and walk
around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't
going to be enabling mass surveillance any time soon. It barely goes
through air, let alone walls.
Anyway, whatever. I'm just bouncing around ideas for faster user
interfaces. You could always switch it off or set it to be triggered by the
presence of particular wifi hotspots, if you don't mind an initial bit of
setup.
Back on topic - the debate is interesting, but I think to get this to the
stage of being a BIP we'd need at least another wallet to implement it?
Then I guess a BIP would be useful regardless of the design issues. The
prefix matching still feels flaky to me but it's hard to know if you could
really swipe payments out of the air in practice, without actually trying
it.
[-- Attachment #2: Type: text/html, Size: 1513 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 21:19 ` Brian Hoffman
@ 2015-02-05 21:23 ` Eric Voskuil
2015-02-05 21:36 ` Mike Hearn
2015-02-05 22:02 ` Paul Puey
2 siblings, 0 replies; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 21:23 UTC (permalink / raw)
To: Brian Hoffman; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
Yes, a stellar device for mass surveillance coupled with transaction tainting.
e
> On Feb 5, 2015, at 1:19 PM, Brian Hoffman <brianchoffman@gmail•com> wrote:
>
> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little.
>
>
> On Feb 5, 2015, at 3:50 PM, Mike Hearn <mike@plan99•net> wrote:
>
>>> I'm imagining myself walking around broadcasting my photo and MAC
>>> address while hucksters push payment requests to me for approval
>>
>> I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;)
>>
>> Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC.
>>
>> "Payment spam" might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue.
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 2968 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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
` (2 more replies)
2015-02-05 22:01 ` Paul Puey
2 siblings, 3 replies; 43+ messages in thread
From: Brian Hoffman @ 2015-02-05 21:19 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1660 bytes --]
This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition. Yes you could photograph people but it's way more burdensome. Sorry to go off topic a little.
On Feb 5, 2015, at 3:50 PM, Mike Hearn <mike@plan99•net> wrote:
>> I'm imagining myself walking around broadcasting my photo and MAC
>> address while hucksters push payment requests to me for approval
>
> I hate to break it to you, but you broadcast a photo of your face every time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If someone can see you, a face is a far more uniquely identifying thing than a MAC.
>
> "Payment spam" might be a problem. I can imagine a wallet requiring that such requests are signed and then spammers can be blacklisted in the usual fashion so they can't push things to your phone anymore. Anyway, a hurdle that can be jumped if/when it becomes an issue.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 2581 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 20:50 ` Mike Hearn
@ 2015-02-05 20:59 ` Eric Voskuil
2015-02-05 21:19 ` Brian Hoffman
2015-02-05 22:01 ` Paul Puey
2 siblings, 0 replies; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 20:59 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]
On 02/05/2015 12:50 PM, Mike Hearn wrote:
> I'm imagining myself walking around broadcasting my photo and MAC
> address while hucksters push payment requests to me for approval
>
> I hate to break it to you, but you broadcast a photo of your face every
> time you walk outside ;)
>
> Bluetooth MAC addresses are random, they aren't useful identifiers. If
> someone can see you, a face is a far more uniquely identifying thing
> than a MAC.
Interesting take on privacy. But the market will of course decide.
Would the merchant be broadcasting payment requests in the clear, or
would they be encrypted with a public key of the spender?
> "Payment spam" might be a problem. I can imagine a wallet requiring that
> such requests are signed and then spammers can be blacklisted in the
> usual fashion so they can't push things to your phone anymore. Anyway, a
> hurdle that can be jumped if/when it becomes an issue.
Not sure I'd shoot for a system that's guaranteed to require PKI with
blacklisting and spam filtering.
e
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 20:44 ` Eric Voskuil
@ 2015-02-05 20:50 ` Mike Hearn
2015-02-05 20:59 ` Eric Voskuil
` (2 more replies)
0 siblings, 3 replies; 43+ messages in thread
From: Mike Hearn @ 2015-02-05 20:50 UTC (permalink / raw)
To: Eric Voskuil; +Cc: Bitcoin Dev, Paul Puey
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
>
> I'm imagining myself walking around broadcasting my photo and MAC
> address while hucksters push payment requests to me for approval
I hate to break it to you, but you broadcast a photo of your face every
time you walk outside ;)
Bluetooth MAC addresses are random, they aren't useful identifiers. If
someone can see you, a face is a far more uniquely identifying thing than a
MAC.
"Payment spam" might be a problem. I can imagine a wallet requiring that
such requests are signed and then spammers can be blacklisted in the usual
fashion so they can't push things to your phone anymore. Anyway, a hurdle
that can be jumped if/when it becomes an issue.
[-- Attachment #2: Type: text/html, Size: 951 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 20:28 ` Mike Hearn
2015-02-05 20:37 ` Paul Puey
@ 2015-02-05 20:44 ` Eric Voskuil
2015-02-05 20:50 ` Mike Hearn
1 sibling, 1 reply; 43+ messages in thread
From: Eric Voskuil @ 2015-02-05 20:44 UTC (permalink / raw)
To: Mike Hearn, Paul Puey; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3591 bytes --]
On 02/05/2015 12:28 PM, Mike Hearn wrote:
> The donation to live performer example is good - there's no issue of
> accidentally paying for someone else in this context as there's only one
> recipient, but many senders.
I'm not sure you could assume this, even if the payer only received one
broadcast. And if the payer receives multiple, it constitutes a DOS on
the scenario, potentially unintentional.
> The issue of confused payments remains in other situations though.
Agree, the problem of the payer strongly identifying the receiver
requires either proximity (NFC or QR code scan from the known-good
source) or PKI/WoT. The problem can't be resolved through a broadcast.
> For the coffee shop use case, it'd be nicer (I think) if we aim for a
> Square-style UI where the device broadcasts a (link to) a photo of the
> user combined with a bluetooth MAC. Then the merchant tablet can show
> faces of people in the shop, and can push a payment request to the users
> device. That device can then buzz the user, show a confirmation screen,
> put something on their smart watch etc or just auto-authorise the
> payment because the BIP70 signature is from a trusted merchant. User
> never even needs to touch their phone at all.
I'm imagining myself walking around broadcasting my photo and MAC
address while hucksters push payment requests to me for approval, while
recording my photo and correlating it to my address. It will pretty
quickly turn in to a scenario where I need to touch something before
this is turned on.
> On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul@airbitz•co
> <mailto:paul@airbitz•co>> wrote:
>
> The BIP70 protocol would preclude individuals from utilizing the P2P
> transfer spec. It would also require that a Sender have internet
> connectivity to get the payment protocol info. BLE could enable
> payment w/o internet by first transferring the URI to from Recipient
> to Sender. Then in the future, we could sign a Tx and send it over
> BLE back to the recipient (who would still need internet to verify
> the Tx). This is an important use case for areas with poor 3G/4G
> connectivity as I've experience myself.
>
> Also, due to Android issues, NFC is incredibly clunky. The URI
> Sender is required to tap the screen *while* the two phones are in
> contact. We support NFC the same way Bitcoin Wallet does, but unless
> the payment recipient has a custom Android device (which a merchant
> might) then the usage model is worse than scanning a QR code. BLE
> also allows people to pay at a distance such as for a donation to a
> live performer. We'll look at adding this to the Motivation section.
>
> From: Andreas Schildbach <andreas@sc•..> - 2015-02-05 13:47:04
>
> Thanks Paul, for writing up your protocol!
>
> First thoughts:
>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead. URIs mainly stick around because
> of QR codes limited capacity. BIP70 would partly address the "copycat"
> problem by signing payment requests.
>
> In your Motivation section, I miss some words about NFC. NFC already
> addresses all of the usability issues mentioned and is supported by
> mobile wallets since 2011. That doesn't mean your method doesn't make
> sense in some situations, but I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
2015-02-05 20:37 ` Paul Puey
@ 2015-02-05 20:43 ` Mike Hearn
0 siblings, 0 replies; 43+ messages in thread
From: Mike Hearn @ 2015-02-05 20:43 UTC (permalink / raw)
To: Paul Puey; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]
>
> Even if a user could get the BIP70 URL in the URI, they would still need
> internet to access the URL.
>
The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address
where you can download the request from. BIP70 does not depend on internet
access or HTTP, plus, you don't have to sign them.
The name field might work but requires the merchant to set it, e.g. by
asking the payer what their name is, then typing it in, then the payer has
to wait for it to show up. By this point it's probably faster to have
scanned a QR code.
Re: security. I'll repeat what I wrote up-thread in case you didn't see it:
it's not clear to me at all that this partial address scheme is actually
> secure. The assumption appears to be that the MITM must match the address
> prefix generated by the genuine merchant. But if they can do a wireless
> MITM they can just substitute their own address prefix/partial address, no?
>
> To avoid MITM attacks the sender must know who they are sending money to,
> and that means they must see a human understandable name that's
> cryptographically bound to the right public key. Displaying partial
> addresses to the user is not going to solve this unless users manually
> compare key prefixes across the screens.... which is even less convenient
> than a QR code.
>
[-- Attachment #2: Type: text/html, Size: 2113 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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
1 sibling, 1 reply; 43+ messages in thread
From: Paul Puey @ 2015-02-05 20:37 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5701 bytes --]
Thanks for CC'ing me Mike. Having trouble receiving maillist list posts.
Even if a user could get the BIP70 URL in the URI, they would still need
internet to access the URL. This BLE spec doesn't preclude BIP70, but can
work with it while still allowing individuals without a certificate to
broadcast a request.
The issue of confused payments becomes less so if the Recipient broadcasts
a name along with the 10 digit public addr prefix. Only if there is a name
conflict will the user have to be concerned with the prefix. The name can
be something like
Mikes Coffee #1 and it can have a "Register #1" at the counter. A customer
facing screen can also show the 10 digit prefix.
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
On Thu, Feb 5, 2015 at 12:28 PM, Mike Hearn <mike@plan99•net> wrote:
> BIP70 requests can be sent over bluetooth as well, as can transactions.
> Bitcoin Wallet can already send money even when offline by doing this. It's
> transparent to the user. I mean original Bluetooth in this context - BLE
> has incredibly tight data constraints and isn't really meant for data
> transfer.
>
> Yes Android Beam has a pretty stupid UI. You can actually tap the devices,
> take them away and then press, but that's not obvious at all. There have
> been new APIs added in recent releases that give more control over this, so
> it's possible we can revisit things and make the UI better these days.
>
> The donation to live performer example is good - there's no issue of
> accidentally paying for someone else in this context as there's only one
> recipient, but many senders.
>
> The issue of confused payments remains in other situations though.
>
> For the coffee shop use case, it'd be nicer (I think) if we aim for a
> Square-style UI where the device broadcasts a (link to) a photo of the user
> combined with a bluetooth MAC. Then the merchant tablet can show faces of
> people in the shop, and can push a payment request to the users device.
> That device can then buzz the user, show a confirmation screen, put
> something on their smart watch etc or just auto-authorise the payment
> because the BIP70 signature is from a trusted merchant. User never even
> needs to touch their phone at all.
>
> On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul@airbitz•co> wrote:
>
>> The BIP70 protocol would preclude individuals from utilizing the P2P
>> transfer spec. It would also require that a Sender have internet
>> connectivity to get the payment protocol info. BLE could enable payment w/o
>> internet by first transferring the URI to from Recipient to Sender. Then in
>> the future, we could sign a Tx and send it over BLE back to the recipient
>> (who would still need internet to verify the Tx). This is an important use
>> case for areas with poor 3G/4G connectivity as I've experience myself.
>>
>> Also, due to Android issues, NFC is incredibly clunky. The URI Sender is
>> required to tap the screen *while* the two phones are in contact. We
>> support NFC the same way Bitcoin Wallet does, but unless the payment
>> recipient has a custom Android device (which a merchant might) then the
>> usage model is worse than scanning a QR code. BLE also allows people to pay
>> at a distance such as for a donation to a live performer. We'll look at
>> adding this to the Motivation section.
>>
>> [image: logo]
>> *Paul Puey* CEO / Co-Founder, Airbitz Inc
>> +1-619-850-8624 | http://airbitz.co | San Diego
>> <http://facebook.com/airbitz> <http://twitter.com/airbitz>
>> <https://plus.google.com/118173667510609425617>
>> <https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
>> <https://angel.co/paul-puey>
>> *DOWNLOAD THE AIRBITZ WALLET:*
>> <https://play.google.com/store/apps/details?id=com.airbitz>
>> <https://itunes.apple.com/us/app/airbitz/id843536046>
>>
>>
>> From: Andreas Schildbach <andreas@sc•..> - 2015-02-05 13:47:04
>>
>> Thanks Paul, for writing up your protocol!
>>
>> First thoughts:
>>
>> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
>> publish BIP70 payment requests instead. URIs mainly stick around because
>> of QR codes limited capacity. BIP70 would partly address the "copycat"
>> problem by signing payment requests.
>>
>> In your Motivation section, I miss some words about NFC. NFC already
>> addresses all of the usability issues mentioned and is supported by
>> mobile wallets since 2011. That doesn't mean your method doesn't make
>> sense in some situations, but I think it should be explained why to
>> prefer broadcasting payment requests over picking them up via near field
>> radio.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 14942 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
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:44 ` Eric Voskuil
0 siblings, 2 replies; 43+ messages in thread
From: Mike Hearn @ 2015-02-05 20:28 UTC (permalink / raw)
To: Paul Puey; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4366 bytes --]
BIP70 requests can be sent over bluetooth as well, as can transactions.
Bitcoin Wallet can already send money even when offline by doing this. It's
transparent to the user. I mean original Bluetooth in this context - BLE
has incredibly tight data constraints and isn't really meant for data
transfer.
Yes Android Beam has a pretty stupid UI. You can actually tap the devices,
take them away and then press, but that's not obvious at all. There have
been new APIs added in recent releases that give more control over this, so
it's possible we can revisit things and make the UI better these days.
The donation to live performer example is good - there's no issue of
accidentally paying for someone else in this context as there's only one
recipient, but many senders.
The issue of confused payments remains in other situations though.
For the coffee shop use case, it'd be nicer (I think) if we aim for a
Square-style UI where the device broadcasts a (link to) a photo of the user
combined with a bluetooth MAC. Then the merchant tablet can show faces of
people in the shop, and can push a payment request to the users device.
That device can then buzz the user, show a confirmation screen, put
something on their smart watch etc or just auto-authorise the payment
because the BIP70 signature is from a trusted merchant. User never even
needs to touch their phone at all.
On Thu, Feb 5, 2015 at 9:06 PM, Paul Puey <paul@airbitz•co> wrote:
> The BIP70 protocol would preclude individuals from utilizing the P2P
> transfer spec. It would also require that a Sender have internet
> connectivity to get the payment protocol info. BLE could enable payment w/o
> internet by first transferring the URI to from Recipient to Sender. Then in
> the future, we could sign a Tx and send it over BLE back to the recipient
> (who would still need internet to verify the Tx). This is an important use
> case for areas with poor 3G/4G connectivity as I've experience myself.
>
> Also, due to Android issues, NFC is incredibly clunky. The URI Sender is
> required to tap the screen *while* the two phones are in contact. We
> support NFC the same way Bitcoin Wallet does, but unless the payment
> recipient has a custom Android device (which a merchant might) then the
> usage model is worse than scanning a QR code. BLE also allows people to pay
> at a distance such as for a donation to a live performer. We'll look at
> adding this to the Motivation section.
>
> [image: logo]
> *Paul Puey* CEO / Co-Founder, Airbitz Inc
> +1-619-850-8624 | http://airbitz.co | San Diego
> <http://facebook.com/airbitz> <http://twitter.com/airbitz>
> <https://plus.google.com/118173667510609425617>
> <https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
> <https://angel.co/paul-puey>
> *DOWNLOAD THE AIRBITZ WALLET:*
> <https://play.google.com/store/apps/details?id=com.airbitz>
> <https://itunes.apple.com/us/app/airbitz/id843536046>
>
>
> From: Andreas Schildbach <andreas@sc•..> - 2015-02-05 13:47:04
>
> Thanks Paul, for writing up your protocol!
>
> First thoughts:
>
> For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
> publish BIP70 payment requests instead. URIs mainly stick around because
> of QR codes limited capacity. BIP70 would partly address the "copycat"
> problem by signing payment requests.
>
> In your Motivation section, I miss some words about NFC. NFC already
> addresses all of the usability issues mentioned and is supported by
> mobile wallets since 2011. That doesn't mean your method doesn't make
> sense in some situations, but I think it should be explained why to
> prefer broadcasting payment requests over picking them up via near field
> radio.
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 10306 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI
@ 2015-02-05 20:06 Paul Puey
2015-02-05 20:28 ` Mike Hearn
0 siblings, 1 reply; 43+ messages in thread
From: Paul Puey @ 2015-02-05 20:06 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]
The BIP70 protocol would preclude individuals from utilizing the P2P
transfer spec. It would also require that a Sender have internet
connectivity to get the payment protocol info. BLE could enable payment w/o
internet by first transferring the URI to from Recipient to Sender. Then in
the future, we could sign a Tx and send it over BLE back to the recipient
(who would still need internet to verify the Tx). This is an important use
case for areas with poor 3G/4G connectivity as I've experience myself.
Also, due to Android issues, NFC is incredibly clunky. The URI Sender is
required to tap the screen *while* the two phones are in contact. We
support NFC the same way Bitcoin Wallet does, but unless the payment
recipient has a custom Android device (which a merchant might) then the
usage model is worse than scanning a QR code. BLE also allows people to pay
at a distance such as for a donation to a live performer. We'll look at
adding this to the Motivation section.
[image: logo]
*Paul Puey* CEO / Co-Founder, Airbitz Inc
+1-619-850-8624 | http://airbitz.co | San Diego
<http://facebook.com/airbitz> <http://twitter.com/airbitz>
<https://plus.google.com/118173667510609425617>
<https://go.airbitz.co/comments/feed/> <http://linkedin.com/in/paulpuey>
<https://angel.co/paul-puey>
*DOWNLOAD THE AIRBITZ WALLET:*
<https://play.google.com/store/apps/details?id=com.airbitz>
<https://itunes.apple.com/us/app/airbitz/id843536046>
From: Andreas Schildbach <andreas@sc•..> - 2015-02-05 13:47:04
Thanks Paul, for writing up your protocol!
First thoughts:
For a BIP standard, I think we should skip "bitcoin:" URIs entirely and
publish BIP70 payment requests instead. URIs mainly stick around because
of QR codes limited capacity. BIP70 would partly address the "copycat"
problem by signing payment requests.
In your Motivation section, I miss some words about NFC. NFC already
addresses all of the usability issues mentioned and is supported by
mobile wallets since 2011. That doesn't mean your method doesn't make
sense in some situations, but I think it should be explained why to
prefer broadcasting payment requests over picking them up via near field
radio.
[-- Attachment #2: Type: text/html, Size: 7383 bytes --]
^ permalink raw reply [flat|nested] 43+ messages in thread
end of thread, other threads:[~2015-02-10 17:59 UTC | newest]
Thread overview: 43+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-05 8:01 [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI Paul Puey
2015-02-05 13:46 ` Andreas Schildbach
2015-02-05 13:57 ` Mike Hearn
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox