Re: [Bitcoin-development] Proposal to address Bitcoin malware

[Eric Voskuil]

In sending the first-signed transaction to another for second signature, how 
does the first signer authenticate to the second without compromising the  
independence of the two factors?

Sent from my iPhone

> On Feb 2, 2015, at 10:40 AM, Brian Erdelyi  wrote:
> 
> Another concept...
> 
> It should be possible to use multisig wallets to protect against malware.  
> For example, a user could generate a wallet with 3 keys and require a 
> transaction that has been signed by 2 of those keys.  One key is placed in 
> cold storage and anther sent to a third-party.
> 
> It is now possible to generate and sign transactions on the users computer 
> and send this signed transaction to the third-party for the second signature. 
>  This now permits the use of out of band transaction verification techniques 
> before the third party signs the transaction and sends to the blockchain.
> 
> If the third-party is malicious or becomes compromised they would not have 
> the ability to complete transactions as they only have one private key.  If 
> the third-party disappeared, the user could use the key in cold storage to 
> sign transactions and send funds to a new wallet.
> 
> Thoughts?
> --
> 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

Re: [Bitcoin-development] Proposal to address Bitcoin malware

[Eric Voskuil]

Confusing or not, the reliance on multiple signatures as offering greater 
security than single relies on the independence of multiple secrets. If the 
secrets cannot be shown to retain independence in the envisioned threat 
scenario (e.g. a user's compromised operating system) then the benefit reduces 
to making the exploit more difficult to write, which, once written, reduces to 
no benefit. Yet the user still suffers the reduced utility arising from greater 
complexity, while being led to believe in a false promise.


> On Feb 2, 2015, at 11:35 AM, Brian Erdelyi  wrote:
> 
> 
>> Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your 
>> phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly. 
>> 
>> It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on desktop 
>> and Android on mobile.
>> 
>> It could be adapted to use BitGo as a third party key holder with SMS 
>> authenticator relatively easily, I think. We did the bulk of all the needed 
>> work last year as part of the bitcoinj multisig work. Then you'd have a 
>> server involved, but not a web app.
> 
> I really like the concept of Bitcoin Authenticator and think it’s exactly 
> what I was describing (without a third-party).
> 
> I think it’s a bit confusing when they describe Bitcoin Authenticator as 2FA. 
>  I think it may be more accurate to describe it as out of band transaction 
> verification/signing or dual transaction signing.  Regardless, it’s very 
> exciting to see others are thinking about this too.
> 
> Brian Erdelyi
> --
> 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

Re: [Bitcoin-development] Proposal to address Bitcoin malware

[Eric Voskuil]

On Feb 2, 2015, at 11:53 AM, Mike Hearn  wrote:
>> In sending the first-signed transaction to another for second signature, how 
>> does the first signer authenticate to the second without compromising the  
>> independence of the two factors?
> 
> Not sure what you mean. The idea is the second factor displays the 
> transaction and the user confirms it matches what they input to the first 
> factor. Ideally, using BIP70, but I don't know if BA actually uses that 
> currently.
> 
> It's the same model as the TREZOR, except with a desktop app instead of 
> myTREZOR and a phone instead of a dedicated hardware device. 

Sorry for the slow reply, traveling.

My comments were made in reference to this proposal:

> On Feb 2, 2015, at 10:40 AM, Brian Erdelyi  wrote:
> 
> Another concept...
> 
> It should be possible to use multisig wallets to protect against malware.  
> For example, a user could generate a wallet with 3 keys and require a 
> transaction that has been signed by 2 of those keys.  One key is placed in 
> cold storage and anther sent to a third-party.
> 
> It is now possible to generate and sign transactions on the users computer 
> and send this signed transaction to the third-party for the second signature. 
>  This now permits the use of out of band transaction verification techniques 
> before the third party signs the transaction and sends to the blockchain.
> 
> If the third-party is malicious or becomes compromised they would not have 
> the ability to complete transactions as they only have one private key.  If 
> the third-party disappeared, the user could use the key in cold storage to 
> sign transactions and send funds to a new wallet.
> 
> Thoughts?

In the multisig scenario the presumption is of a user platform compromised by 
malware. It envisions a user signing a 2 of 3 output with a first signature. 
The precondition that the platform is compromised implies that this process 
results in a loss of integrity of the private key, and as such if it were not 
for the second signature requirement, the malware would be able to spend the 
output. This may be extended to all of the keys in the wallet.

The scenario envisions sending the signed transaction to an another ("third") 
party. The objective is for the third party to provide the second signature, 
thereby spending the output as intended by the user, who is not necessarily the 
first signer. The send must be authenticated to the user. Otherwise the third 
party would have to sign anything it received, obviously rendering the second 
signature pointless. This implies that the compromised platform must transmit a 
secret, or proof of a secret, to the third party.

The problem is that the two secrets are not independent if the first platform 
is compromised. So of course the malware has the ability to sign, impersonate 
the user and send to the third party. So the third party *must* send the 
transaction to an *independent* platform for verification by the user, and 
obtain consent before adding the second signature. The user, upon receiving the 
transaction details, must be able to verify, on the independent platform, that 
the details match those of the transaction that user presumably signed. Even 
for simple transactions this must include amount, address and fees.

The central assumptions are that, while the second user platform may be 
compromised, the attack against the second platform is not coordinated with 
that of the first, nor is the third party in collusion with the first platform.

Upon these assumptions rests the actual security benefit (increased difficulty 
of the coordinated attack). The strength of these assumptions is an interesting 
question, since it is hard to quantify. But without independence the entire 
security model is destroyed and there is thus no protection whatsoever against 
malware.

So for example a web-based or other third-party-provisioned implementation of 
the first platform breaks the anti-collusion assumption. Also, weak comsec 
allows an attack against the second platform to be carried out against its 
network. So for example a simple SMS-based confirmation could be executed by 
the first platform alone and thereby also break the the anti-collusion 
assumption. This is why I asked how independence is maintained.

The assumption of a hardware wallet scenario is that the device itself is not 
compromised. So the scenario is not the same. If the user signs with a hardware 
wallet, nothing can collude with that process, with one caveat.

While a hardware wallet is not subject to onboard malware, it is not 
inconceivable that its keys could be extracted through probing or other direct 
attack against the hardware. It's nevertheless an assumption of hardware 
wallets that these attacks require loss of the hardware. Physical possession 
constitutes compromise. So the collusion model with a hardware wallet does 
exist, it just requires device possession. Depending on the implementation the 
extraction ma

Re: [Bitcoin-development] Proposal to address Bitcoin malware

[Eric Voskuil]

One clarification below.

e

On 02/02/2015 02:54 PM, Eric Voskuil wrote:
> On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote:
>>
>> In sending the first-signed transaction to another for second
>> signature, how does the first signer authenticate to the second
>> without compromising the  independence of the two factors?
>>
>> Not sure what you mean. The idea is the second factor displays the
>> transaction and the user confirms it matches what they input to the
>> first factor. Ideally, using BIP70, but I don't know if BA actually
>> uses that currently.
>>
>> It's the same model as the TREZOR, except with a desktop app instead
>> of myTREZOR and a phone instead of a dedicated hardware device. 
> 
> Sorry for the slow reply, traveling.
> 
> My comments were made in reference to this proposal:
> 
>>> On Feb 2, 2015, at 10:40 AM, Brian Erdelyi >> <mailto:brian.erde...@gmail.com>> wrote:
>>>
>>> Another concept...
>>>
>>> It should be possible to use multisig wallets to protect against
>>> malware.  For example, a user could generate a wallet with 3 keys and
>>> require a transaction that has been signed by 2 of those keys.  One
>>> key is placed in cold storage and anther sent to a third-party.
>>>
>>> It is now possible to generate and sign transactions on the users
>>> computer and send this signed transaction to the third-party for the
>>> second signature.  This now permits the use of out of band transaction
>>> verification techniques before the third party signs the transaction
>>> and sends to the blockchain.
>>>
>>> If the third-party is malicious or becomes compromised they would not
>>> have the ability to complete transactions as they only have one
>>> private key.  If the third-party disappeared, the user could use the
>>> key in cold storage to sign transactions and send funds to a new wallet.
>>>
>>> Thoughts?

My comments below start out with the presumption of user platform
compromise, but the same analysis holds for the case where the user
platform is clean but a web wallet is compromised. Obviously the idea is
that either or both may be compromised, but integrity is retained as
long as both are not compromised and in collusion.

> In the multisig scenario the presumption is of a user platform
> compromised by malware. It envisions a user signing a 2 of 3 output with
> a first signature. The precondition that the platform is compromised
> implies that this process results in a loss of integrity of the private
> key, and as such if it were not for the second signature requirement,
> the malware would be able to spend the output. This may be extended to
> all of the keys in the wallet.
> 
> The scenario envisions sending the signed transaction to an another
> ("third") party. The objective is for the third party to provide the
> second signature, thereby spending the output as intended by the user,
> who is not necessarily the first signer. The send must be authenticated
> to the user. Otherwise the third party would have to sign anything it
> received, obviously rendering the second signature pointless. This
> implies that the compromised platform must transmit a secret, or proof
> of a secret, to the third party.
> 
> The problem is that the two secrets are not independent if the first
> platform is compromised. So of course the malware has the ability to
> sign, impersonate the user and send to the third party. So the third
> party *must* send the transaction to an *independent* platform for
> verification by the user, and obtain consent before adding the second
> signature. The user, upon receiving the transaction details, must be
> able to verify, on the independent platform, that the details match
> those of the transaction that user presumably signed. Even for simple
> transactions this must include amount, address and fees.
> 
> The central assumptions are that, while the second user platform may be
> compromised, the attack against the second platform is not coordinated
> with that of the first, nor is the third party in collusion with the
> first platform.
> 
> Upon these assumptions rests the actual security benefit (increased
> difficulty of the coordinated attack). The strength of these assumptions
> is an interesting question, since it is hard to quantify. But without
> independence the entire security model is destroyed and there is thus no
> protection whatsoever against malware.
> 
> So for example a web-based or other third-party-provisioned
> implementation of the first platform breaks the anti-collusion
> assumption. Also, weak comsec allows

Re: [Bitcoin-development] Proposal to address Bitcoin malware

[Eric Voskuil]

On 02/02/2015 11:58 AM, Brian Erdelyi wrote:>
>>Confusing or not, the reliance on multiple signatures as offering
>>greater security than single relies on the independence of multiple
>secrets. If the secrets cannot be shown to retain independence in the
>>envisioned threat scenario (e.g. a user's compromised operating
>>system) then the benefit reduces to making the exploit more difficult
>>to write, which, once written, reduces to no benefit. Yet the user
>>still suffers the reduced utility arising from greater complexity,
>>while being led to believe in a false promise.
>
>Just trying to make sure I understand what you’re saying.  Are you
>eluding to that if two of the three private keys get compromised there
>is no gain in security?  Although the likelihood of this occurring is
>lower, it is possible.

No, that's not it. Sorry for not being clear. Independence of control is
the central issue in the analysis of a multiple factor system. If an
attack compromises one factor there must be no way for that attack to
reduce the difficulty of obtaining the other factors.

Some factors (secrets), like a fingerprint, aren't very secret at all.
But getting someone's fingerprint doesn't also help the attacker get a
PIN. That factor must be attacked independently. But if the PIN is
encrypted with the fingerprint in a public store, then the PIN is not
independent of the fingerprint and there is really only one secret.

If multiple factors are coincident (located within the same security
perimeter) they are compromized coincidentally. Coincidence has the same
effect as dependence. Consider a credit card with a "security code"
printed on the back. A successful attack on the leather wallet yields
both secrets.

Individual environments can be compromised with some difficulty (e.g.
desktop malware, fingerprint lift, dictionary attack, brute force PIN,
etc.). For the sake of simplicity, let that chance of successful
independent attack on any factor be 1 in 2 and the resulting probability
of successful concurrent attack on any n factors be 1 in 2^n. If m
factors are dependent/coincident on others the relation becomes 1 in
2^(n-m).

Any multi-factor web wallet that handles the user's keys in the browser
and authenticates the user in the browser to authorize service signing
is effectively single factor. One attack may be launched by an insider,
or externally, against the web app, executing in the browser, gaining
coincident access to two secrets. Browser/desktop malware can accomplish
the same. The difficulty is 1 in 2 vs. the expected 1 in 4.

>As more malware targets bitcoins I think the utility is evident.
>Given how final Bitcoin transactions are, I think it’s worth trying to
>find methods to help verify those transactions (if a user deems it to
>be high-risk enough) before the transaction is completed.  The balance
>is trying to devise something that users do not find too burdensome.

I'm not questioning the motive, I agree it's worth trying. But trying is
not succeeding. Increasing user (and/or system) complexity without
increasing integrity or privacy is a poor trade, and worse if the user
is misled.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Subject: Re: Proposal to address Bitcoin malware

[Eric Voskuil]

On 02/03/2015 04:04 AM, Will wrote:
> An idea for the bitcoin malware proposal below, the idea is at the bottom…
> ...
> The trick we need to look at is how to use the bitcoin network as a
> delivery mechanism to bypass the need for the trusted third party in the
> example above. 

Using the Bitcoin network would be a convenience, certainly not a
requirement. Any public store (or other channel accessible to all
signers) would do.

> Instead of the second factor routing through a 3rd party
> to the intended recipient, we have another option - one that doesn’t
> require core development either.

Absolutely, there is no need for a trusted third party in the case of
MFA unless that party has independent judgement in the decision to sign.
For example, if the third party is the trustee of a fund from which a
beneficiary wants to withdraw.

If you are just routing a decision back to yourself a third party makes
no sense. Oddly most of the services in operation today are doing just
that. You will end up authenticating to the third party from a platform
you control, which means that the platform must be trusted as much as
the third party. Why not just trust the platform and no third party? It
doesn't reduce the number of factors but it certainly reduces the attack
surface.

> 1) Sender > signs signature 1 via desktop > bitcoin network 2/3 P2SH
> 2) Mobile app also used by sender receives req. from bitcoin network to
> sign signature - not through the site in 1 (similar to the 2nd channel
> between the website and security company above)
> 3) Sender > signs signature 2 via mobile app (or any separate
> device operating on a different network - heck could be radio) > 2/3
> signatures, transaction authorized

There's no need for the devices to be on independent networks. You can
safely remove that constraint. The partially-signed transaction can be
encrypted to the other signatories (for privacy) or it can be sent in
the clear. And ultimately all platforms in the scheme are connected to
the Internet, even if it's via sneakernet.

The important requirement is that the signing platforms are independent
and that the signers inspect the transactions on those platforms. This
preserves the benefit of MFA, which is that the signing platforms must
be compromised independently.

> ...
> If there was a way to perform 2/3 multisig without requiring a second
> band, performing the function safely by somehow knowing if the service
> is performed from a compromised device through some sort of
> on-blockchain anti-malware check by validating the signature of the
> signing application by comparing it to a signature recorded when the
> multisig address was funded,  that would be a really neat breakthrough.
>  Food for thought, but I can’t see how that could be executed in a way
> where signatures couldn’t be spoofed from a compromised device.  If
> someone cracks that problem, it’s a really big advance for information
> security.

Once you've done this you are talking about two independent signing
platforms. Plug two trustworthy signing devices into a PC and you've
done it. This is because the host environment (the PC in this case) is
not trusted in the first place. Two untrusted environments are no better
than one. It's only if the environments are trusted that they must be
independent.

But therein lies the problem. The physical proximity of two trusted
hardware devices exposes them to a single attack in the case of physical
theft or loss. So to guard against that threat the devices must be
independently stored. This presents a problem when it comes to usage.

This is the central problem of MFA. It's not possible to control
multiple factors while not exposing them to compromise. This is true
whether we are talking about multiple physical devices or a remote
service, since in the remote case the secret must still be accessible to
the person in control.

In the case of truly independent decisions MFA is strongest. But short
of that there's no reason for a remote third party. One can probably
accept the risk of securing multiple devices with the home, etc - and
needs to do this even if using a third party. On the other hand, walking
around with all necessary factors, or keeping them in the same safe, is
tantamount to having just one factor.

e

> On 02/02/2015 02:54 PM, Eric Voskuil wrote: 
>> On Feb 2, 2015, at 11:53 AM
> <http://airmail.calendar/2015-02-02%2011:53:00%20MST>, Mike Hearn wrote: 
>>> 
>>> In sending the first-signed transaction to another for second 
>>> signature, how does the first signer authenticate to the second 
>>> without compromising the independence of the two factors? 
>>> 
>>> Not sure what you mean. The idea is the second factor displays the 
>>> transaction and the user confirms it matches what t

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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




signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

Yes, a stellar device for mass surveillance coupled with transaction tainting.

e


> On Feb 5, 2015, at 1:19 PM, Brian Hoffman  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  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
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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  <mailto:p...@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 > <mailto:e...@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 > <mailto:m...@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.

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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



signature.asc
Description: Ope

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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 :
>> 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
>>



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Eric Voskuil]

Hi Andy,

This is good stuff. I've spent quite a bit of time on this question, but
set aside most of it earlier in the year in order to make some progress
in other areas. I did review what I found available at the time
pertaining to the Schildbach implementation and these questions.
Skimming the links now I'm encouraged, but I see several things that I'd
like to discuss at greater length than is appropriate here.

The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT. For payment
purposes the lower bandwidth isn't much of a hit.

e

On 02/05/2015 03:38 PM, Andy Schroder wrote:
> Hello,
> 
> With the recent discussion started today regarding another bluetooth
> communication proposal created by Airbitz, I'd like to bring people's
> attention back to this proposal that saw little discussion last fall. I
> guess I'm not sure why two proposals are being created. Is their some
> advantage of using bluetooth low energy over standard bluetooth (I'm not
> well versed in bluetooth low energy)? This NFC coupled approach seems to
> avoid a lot of issues with identifying the correct payee. You can see
> this proposed scheme demonstrated in action in a POS application in the
> video link below which demonstrates it with my fuel pump and Andreas
> Schildbach's wallet.
> 
> There was a small discussion that occurred after my original
> announcement below. If you are new to this e-mail list, you can find an
> archive of those few replies here:
> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
> 
> Since this original announcement, a few improvements have been made to
> the proposal:
> 
>  1. Improved documentation and explanation of the use cases in
> Schildbach's wallet's wiki
>  1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
>  2. Issue with the payment_url field has resolved by changing to a
> repeated field and requiring the wallet to search for the protocol
> they want to use, rather than expecting it to be a certain element
> number in the list.
>  1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
> 
> 
> Although there are some interesting use cases of Airbitz's proposal's
> work flow, tapping an NFC radio with a 5 mm range requires much less
> brain power and time than picking the correct name on the app's screen.
> The manual name picking is going to be especially crazy in a very
> congested location. The payer isn't ever going to want to have to try
> and figure out what register or payment terminal they are at for most
> applications I would ever use.
> 
> I'd like to see something happen with this technology. I've also noticed
> that micropayment channels have little formality to being established
> practically and it would be awesome if they could be managed over
> bluetooth as well. Maybe more improvements to the payment protocol can
> simultaneously result (and also extended to bluetooth) that embrace the
> establishment of micropayment channels.
> 
> 
> 
> Andy Schroder
> 
> On 10/17/2014 03:58 PM, Andy Schroder wrote:
>> Hello,
>>
>> I'd like to introduce two proposed BIPs. They are primarily focused on
>> implementing the payment protocol using bluetooth connections. I've
>> been working on automated point of sale devices and bluetooth
>> communication is critical in my mind due to the potential lack of
>> internet access at many points of sale, either due to lack of cellular
>> internet coverage, lack of payee providing wireless internet, and/or
>> due to financial constraints of the payer prohibiting them from
>> maintaining a cellular internet service plan. These BIPs are largely
>> modeled after the current functionality of Andreas Schildbach's
>> android Bitcoin Wallet's bluetooth capability. I've discussed the
>> communication scheme with him in depth and believe these proposals to
>> clearly and accurately represent the communication scheme.
>>
>> There is also an additional &h= parameter added to the bitcoin: URI
>> scheme which applies to both bluetooth and http payment protocol
>> requests which allows for a hash of the payment request to be
>> included. This hash was proposed by Andreas as an amendment to BIP72,
>> but others preferred not to amend BIP72 since it has already been put
>> into place. The current version of Schildbach's bitcoin wallet already
>> supports the "h parameter".
>>
>> I'd appreciate feedback from everyone, particularly wallet developers
>> as widespread bluetooth support among wallets is very important to me.
>> I'm also very new to this mailing list as well as the BIP writing
>> process, so I'd appreciate your understanding if my conventions are
>> not standard. I am currently using the naming conventions "TBIP", so
>> that I can propose /temporary/ BIP numbers, and cross reference
>> between the two. Obviously these will

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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  <mailto:e...@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
> 



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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
 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 :
>>>> 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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Eric Voskuil]

Agree, range is not an issue. The trade-off is in battery vs. total
time, which would be influenced primarily by the battery sensitivity of
the platform. I'll send you a note to follow up.

e

On 02/05/2015 05:40 PM, Andy Schroder wrote:
> Hello,
> 
> I personally would prefer as low of range as possible for this bluetooth
> application considering the connection is not yet encrypted (mentioned
> below), and even if it were, it seems like it is always going to be
> better in case there is some vulnerability. From my testing with a
> bluetooth radio inside my metal cabinet, the range is ~5 meters, which
> is more than enough.
> 
> However, the connection is actually a bit slow when the whole
> certificate chain is included (~3-4s). You can sort of see this in my
> video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is
> actually spent verifying the signature, and I'm not sure how much of it
> is doing the fetching (I haven't done any detailed timings using "adb
> logcat" and looking at the log entries), but I do know it is a little
> slower than an HTTPS payment request fetch over wifi (~2-3s). The reason
> I know most of the time is the signature verification is because an
> HTTPS payment request fetch over wifi and verification using breadwallet
> on apple is much faster (<1s) than HTTPS payment request on bitcoin
> wallet on android (apparently apple has a significantly more optimized
> signature verification algorithm). Bottom line is that there may be ~1s
> time transferring the data with this current bluetooth connection. Not
> sure how slow it will be with the BLE connection. Time is everything in
> a point of sale application.
> 
> So, I guess what I am saying is it seems like the lower speed and range
> gain with bluetooth low energy are not a benefit in my opinion. I'm not
> sure that the latency gain will be a benefit either unless the speed
> issues I am noticing with regular bluetooth are actually a latency issue
> with just getting the connection established, or actually transmitting
> the payment request data. How much power is going to be used for just a
> few second payment? It's not like the bluetooth connection is maintained
> for a long time like it may be in other non bitcoin use cases.
> 
> 
> Where is a more appropriate place to discuss the other issues you have
> at length?



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

[Eric Voskuil]

On 02/06/2015 12:40 AM, Andreas Schildbach wrote:
> On 02/06/2015 01:36 AM, Eric Voskuil wrote:
> 
>> The main advantage of BLE over BT is that it uses much less power, with
>> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
>> be even greater and connection latency lower than BT. For payment
>> purposes the lower bandwidth isn't much of a hit.
> 
> I'm all for extending the BT: scheme to Bluetooth LE. If you have
> ideas how this can be done please let us know. I haven't had a chance to
> play around with LE because none of my devices support it.
> 
> I suspect the way how Bluetooth LE transfers files (like payment
> requests) is opening a plain old Bluetooth socket. If this is true, I'm
> afraid Bluetooth LE would not add anything for sending the BIP70
> messages back and forth. Note signed payment requests can easily be 4 kB
> in size, so speed *does* matter.

Hi Andreas,

I haven't expressed any preference for BLE, just answering questions
that were raised about it. The main thing that BLE brings to the table
is increased battery life, but with larger transfers that benefit is
reduced.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Standardizing automatic pre-negotiation of transaction terms with BIP70? (Emulating Amazon one-click purchase at all merchants)

[Eric Voskuil]

On 02/10/2015 02:41 AM, Natanael wrote:
> Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak"
> mailto:martin.habovst...@gmail.com>>:
>>
>> Why would anyone want to do anything about payment before choosing
>> what he wants to buy and for what price? I've never used Amazon but
>> isn't filling a form with shipping information enough?
> 
> That's not what this is about.
> 
> BIP70 isn't just payment, it is about communication the terms of the sale.

Hi Natanael,

BIP70 exists for seller non-repudiation (i.e. a cryptographically signed
receipt for payment) and establishing strong seller identity in a
face-to-face or other non-web scenario (since TLS doesn't help).
Anything else is incidental.

> Let's say you're visiting an international webshop. But they don't ship
> to your country. Wouldn't you want to know that before your start
> filling the cart? With this, your wallet / browser extension could tell
> you right away that you can't shop there. No time wasted!
> 
> That's just one requirement of many where you would benefit from being
> told right away if it is acceptable for both parties or not.

There's quite a bit that can be done with wallets and web sites, but
personally I'd freak out if my wallet prompted me because I visited a
web site.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

Martin,

I like your idea for the commit protocol in that it resolves the
vandalous address substitution attack. However, I don't see a way to
prevent privacy loss without adverse impact to the scenario.

Anyone could perform the handshake and thereby obtain the payment
request. Therefore to prevent inadvertent disclosure the customer must
visually confirm the "phrase" and then verbally tell the merchant to
proceed by sending the payment request.

One might argue that it's sufficient to preserve the integrity of the
transaction while suffering the privacy loss, especially given that a
hijacked handshake should never result in a completed transaction -
unless of course the hijacker pays.

But imagine someone purchasing their meds. HIPAA requires the checkout
queue to form behind a yellow line. That speaks directly to this 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 :
>> 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
>>  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:
>>

Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

[Eric Voskuil]

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 :
>> 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 :
>>>> 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

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

Hi Jan,

This is really nice work.

WRT the Schroder and Schildbach proposal, the generalization of the "r"
and "payment_url" parameters makes sense, with only the potential
backward compat issue on payment_url.

> TBIP75 furthermore proposes to include an additional 'h' parameter
> which would be a hash of the BIP70 payment request, preventing a MITM
> attack on the Bluetooth channel even if the BIP70 payment request
> isn't signed. This would have also been my suggestion, although I
> know that Mike Hearn has raised concerns about this approach. One
> being, that one needs to finalize the BIP70 payment request at the
> time the QR code and NFC URI is generated.
> ...
> 3) Are there other comments regarding 'h' parameter as per TBIP75?

Yes, this design is problematic from a privacy standpoint. Anyone within
the rather significant range of the Bluetooth terminal is able to
capture payment requests and correlate them to people. In other words it
can be used to automate tainting.

The problem is easily resolved by recognizing that, in the envisioned
face-to-face trade, proximity is the source of trust. Even in the above
proposal the "h" parameter is trusted because it was obtained by
proximity to the NFC terminal. The presumption is that this proximity
produces a private channel.

As such the "tap" should transfer a session key used for symmetric block
cipher over the Bluetooth channel. This also resolves the issue of
needing to formulate the payment request before the NFC.

As an aside, in other scenarios, such as an automated dispenser, this
presumption does not hold. The merchant is not present to guard against
device tampering. Those scenarios can be secured using BIP70, but cannot
guarantee privacy.

The other differences I have with the proposal pertain to efficiency,
not privacy or integrity of the transaction:

The proposed resource name is redundant with any unique identifier for
the session. For example, the "h" parameter is sufficient. But with the
establishment of a session key both as I propose above, the parties can
derive a sufficiently unique public resource name from a hash of the
key. An additional advantage is that the resource name can be
fixed-length, simplifying the encoding/decoding.

The MAC address (and resource name) should be encoded using base58. This
is shorter than base16, is often shorter than base64, better
standardized and does not require URI encoding, and is generally
available to implementers.

There is no need for the establishment of two Bluetooth services.

I would change the payment_url recommendation so that the list order
represents a recommended ordering provided by the terminal for the wallet.

I wrote up my thoughts on these considerations last year and recently
revised it by adding a section at the end to incorporate the "r" and
"payment_url" generalizations from Andreas and Andy.

https://github.com/evoskuil/bips/tree/master/docs

e


On 02/22/2015 11:08 AM, Jan Vornberger wrote:
> Hi everyone,
> 
> I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, 
> which
> displays QR codes, but also provides payment requests via NFC. It can 
> optionally
> receive the sender's transaction via Bluetooth, so if the sender wallet
> supports it, the sender can be completely offline. Only the terminal needs an
> internet connection.
> 
> Typical scenario envisioned: Customer taps their smartphone (or maybe 
> smartwatch
> in the future) on the NFC pad, confirms the transaction on their phone
> (or smartwatch) and the transaction completes via Bluetooth and/or the phone's
> internet connection.
> 
> You can see a prototype in action here:
> 
>   https://www.youtube.com/watch?v=P7vKHMoapr8
> 
> The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
> works as shown today. However, some parts - especially the Bluetooth stuff - 
> are
> custom extensions of Schildbach's wallet which are not yet standard.
> 
> I'm writing this post to document my experience implementing NFC and offline
> payments and hope to move the discussion forward around standardizing some of
> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
> follows along the same lines, so his proposed TBIP74 [3] and TBIP75 [4] are
> relevant here as well.
> 
> 
> ## NFC vs Bluetooth vs NFC+Bluetooth ##
> 
> Before I get into the implementation details, a few words for why I decided to
> go with the combination of NFC and Bluetooth:
> 
> Doing everything via NFC is an interesting option to keep things simple, but 
> the
> issue is, that one usually can't maintain the connection while the user 
> confirms
> the transaction (as they take the device back to press a button or maybe 
> enter a
> PIN). So there are three options:
> 
> 1. Do a "double tap": User taps, takes the device back, confirms, then taps
> again to transmit the transaction. (I think Google Wallet does something like
> this.)
> 
> 2. Confirm beforehand: User confirms, then taps and everythin

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

One correction inline below.

e

On 02/22/2015 02:39 PM, Eric Voskuil wrote:
> Hi Jan,
> 
> This is really nice work.
> 
> WRT the Schroder and Schildbach proposal, the generalization of the "r"
> and "payment_url" parameters makes sense, with only the potential
> backward compat issue on payment_url.
> 
>> TBIP75 furthermore proposes to include an additional 'h' parameter
>> which would be a hash of the BIP70 payment request, preventing a MITM
>> attack on the Bluetooth channel even if the BIP70 payment request
>> isn't signed. This would have also been my suggestion, although I
>> know that Mike Hearn has raised concerns about this approach. One
>> being, that one needs to finalize the BIP70 payment request at the
>> time the QR code and NFC URI is generated.
>> ...
>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
> 
> Yes, this design is problematic from a privacy standpoint. Anyone within
> the rather significant range of the Bluetooth terminal is able to
> capture payment requests and correlate them to people. In other words it
> can be used to automate tainting.
> 
> The problem is easily resolved by recognizing that, in the envisioned
> face-to-face trade, proximity is the source of trust. Even in the above
> proposal the "h" parameter is trusted because it was obtained by
> proximity to the NFC terminal. The presumption is that this proximity
> produces a private channel.
> 
> As such the "tap" should transfer a session key used for symmetric block
> cipher over the Bluetooth channel. This also resolves the issue of
> needing to formulate the payment request before the NFC.
> 
> As an aside, in other scenarios, such as an automated dispenser, this
> presumption does not hold. The merchant is not present to guard against
> device tampering. Those scenarios can be secured using BIP70, but cannot
> guarantee privacy.
> 
> The other differences I have with the proposal pertain to efficiency,
> not privacy or integrity of the transaction:
> 
> The proposed resource name is redundant with any unique identifier for
> the session. For example, the "h" parameter is sufficient. But with the
> establishment of a session key both as I propose above, the parties can
> derive a sufficiently unique public resource name from a hash of the
> key. An additional advantage is that the resource name can be
> fixed-length, simplifying the encoding/decoding.
> 
> The MAC address (and resource name) should be encoded using base58. This

The MAC address (and session key) should be encoded using base58. This

> is shorter than base16, is often shorter than base64, better
> standardized and does not require URI encoding, and is generally
> available to implementers.
> 
> There is no need for the establishment of two Bluetooth services.
> 
> I would change the payment_url recommendation so that the list order
> represents a recommended ordering provided by the terminal for the wallet.
> 
> I wrote up my thoughts on these considerations last year and recently
> revised it by adding a section at the end to incorporate the "r" and
> "payment_url" generalizations from Andreas and Andy.
> 
> https://github.com/evoskuil/bips/tree/master/docs
> 
> e
> 
> 
> On 02/22/2015 11:08 AM, Jan Vornberger wrote:
>> Hi everyone,
>>
>> I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, 
>> which
>> displays QR codes, but also provides payment requests via NFC. It can 
>> optionally
>> receive the sender's transaction via Bluetooth, so if the sender wallet
>> supports it, the sender can be completely offline. Only the terminal needs an
>> internet connection.
>>
>> Typical scenario envisioned: Customer taps their smartphone (or maybe 
>> smartwatch
>> in the future) on the NFC pad, confirms the transaction on their phone
>> (or smartwatch) and the transaction completes via Bluetooth and/or the 
>> phone's
>> internet connection.
>>
>> You can see a prototype in action here:
>>
>>   https://www.youtube.com/watch?v=P7vKHMoapr8
>>
>> The above demo uses a release version of Schildbach's Bitcoin Wallet, so it
>> works as shown today. However, some parts - especially the Bluetooth stuff - 
>> are
>> custom extensions of Schildbach's wallet which are not yet standard.
>>
>> I'm writing this post to document my experience implementing NFC and offline
>> payments and hope to move the discussion forward around standardizing some of
>> this stuff. Andy Schroder's work around his Bitcoin

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/22/2015 02:37 PM, Andy Schroder wrote:
> I'd like to see some discussion too about securing the bluetooth
> connection. Right now it is possible for an eavesdropper to monitor the
> data transferred. 

Yes, this should be a prerequisite issue to all others.

> I'd personally like to see if wrapping the current
> connection with SSL works or if we can run https over a bluetooth
> socket. 

There is no reason to add this significant complexity. The purpose of
SSL/TLS is to establish privacy over a *public* channel. But to do so
requires verification by the user of the merchant's public certificate.
Once we rely on the channel being *private*, the entire SSL process is
unnecessary.

Presumably we would not want to require PKI for privacy, since that's a
bit of a contradiction. But if one wants to do this NFC is not required,
since the private session can be established over the public (Bluetooth)
network.

> There was some criticism of this, but I don't think it has been
> tested to know if it is really a problem or not. If we just run https
> over bluetooth, then a lot of my concerns about the message header
> inconsistencies will go away and the connection will also be secure. We
> don't have to reinvent anything.
> 
> 
> 
> Andy Schroder
> 
> On 02/22/2015 02:08 PM, Jan Vornberger wrote:
>> Hi everyone,
>>
>> I am working on a Bitcoin point of sale terminal based on a Raspberry
>> Pi, which
>> displays QR codes, but also provides payment requests via NFC. It can
>> optionally
>> receive the sender's transaction via Bluetooth, so if the sender wallet
>> supports it, the sender can be completely offline. Only the terminal
>> needs an
>> internet connection.
>>
>> Typical scenario envisioned: Customer taps their smartphone (or maybe
>> smartwatch
>> in the future) on the NFC pad, confirms the transaction on their phone
>> (or smartwatch) and the transaction completes via Bluetooth and/or the
>> phone's
>> internet connection.
>>
>> You can see a prototype in action here:
>>
>>https://www.youtube.com/watch?v=P7vKHMoapr8
>>
>> The above demo uses a release version of Schildbach's Bitcoin Wallet,
>> so it
>> works as shown today. However, some parts - especially the Bluetooth
>> stuff - are
>> custom extensions of Schildbach's wallet which are not yet standard.
>>
>> I'm writing this post to document my experience implementing NFC and
>> offline
>> payments and hope to move the discussion forward around standardizing
>> some of
>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser [1,2]
>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75
>> [4] are
>> relevant here as well.
>>
>>
>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>
>> Before I get into the implementation details, a few words for why I
>> decided to
>> go with the combination of NFC and Bluetooth:
>>
>> Doing everything via NFC is an interesting option to keep things
>> simple, but the
>> issue is, that one usually can't maintain the connection while the
>> user confirms
>> the transaction (as they take the device back to press a button or
>> maybe enter a
>> PIN). So there are three options:
>>
>> 1. Do a "double tap": User taps, takes the device back, confirms, then
>> taps
>> again to transmit the transaction. (I think Google Wallet does
>> something like
>> this.)
>>
>> 2. Confirm beforehand: User confirms, then taps and everything can
>> happen in one
>> go. The disadvantage is, that you confirm the transaction before you
>> have seen
>> the details. (I believe Google Wallet can also work this way.)
>>
>> 3. Tap the phone, then establish a Bluetooth connection which allows
>> you to do
>> all necessary communication even if the user takes the device back.
>>
>> I feel that option 3 is the nicest UX, so that is what I am focusing
>> on right
>> now, but there are pros and cons to all options. One disadvantage of
>> option 3 in
>> practice is, that many users - in my experience - have Bluetooth
>> turned off, so
>> it can result in additional UI dialogs popping up, asking the user to
>> turn on
>> Bluetooth.
>>
>> Regarding doing everything via Bluetooth or maybe BLE: I have been
>> following the
>> work that Airbitz has done around that, but personally I prefer the NFC
>> interaction of "I touch what I want to pay" rather than "a payment
>> request comes
>> to me through the air and I figure out whether it is meant for me/is
>> legitimate".
>>
>>
>> ## NFC data formats ##
>>
>> A bit of background for those who are not that familiar with NFC: Most
>> Bitcoin
>> wallets with NFC support make use of NDEF (NFC Data Exchange Format)
>> as far as I
>> am aware (with CoinBlesk being an exception, which uses host-based card
>> emulation, if I understand it correctly). NDEF defines a number of
>> record types,
>> among them 'URI' and 'Mime Type'.
>>
>> A common way of using NFC with Bitcoin is to create a URI record that
>> contains a
>> Bitcoin URI. Beyond that Schildbach's wallet (and maybe others?) also
>> su

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/22/2015 03:32 PM, Andy Schroder wrote:
> On 02/22/2015 06:06 PM, Eric Voskuil wrote:
>> On 02/22/2015 02:37 PM, Andy Schroder wrote:
>>> I'd like to see some discussion too about securing the bluetooth
>>> connection. Right now it is possible for an eavesdropper to monitor the
>>> data transferred.
>> Yes, this should be a prerequisite issue to all others.
>>
>>> I'd personally like to see if wrapping the current
>>> connection with SSL works or if we can run https over a bluetooth
>>> socket.
>> There is no reason to add this significant complexity. The purpose of
>> SSL/TLS is to establish privacy over a *public* channel. But to do so
>> requires verification by the user of the merchant's public certificate.
>> Once we rely on the channel being *private*, the entire SSL process is
>> unnecessary.
> 
> 
> I guess we need to decide whether we want to consider NFC communication
> private or not. I don't know that I think it can be.

If the NFC communication is not private then there is no reason to use it.

> An eavesdropper can
> place a tiny snooping device near and read the communication. If it is
> just passive, then the merchant/operator won't realize it's there.

See my comments on an unmonitored terminal.

> So, I
> don't know if I like your idea (mentioned in your other reply) of
> putting the session key in the URL is a good idea?

My point is that you are not solving that problem by creating a more
complex system. Either you establish trust via proximity or you don't.
If you don't, it's a public network. If you do, then keep it simple.

There's nothing holy about a session key in this scenario. It's not
derived from long-lived keys and is itself used only once. There is
nothing wrong with the URL carrying the secret. If you want to secure
this channel without manual intervention, there is ultimately no other
option.

>> Presumably we would not want to require PKI for privacy, since that's a
>> bit of a contradiction. But if one wants to do this NFC is not required,
>> since the private session can be established over the public (Bluetooth)
>> network.
>>
>>> There was some criticism of this, but I don't think it has been
>>> tested to know if it is really a problem or not. If we just run https
>>> over bluetooth, then a lot of my concerns about the message header
>>> inconsistencies will go away and the connection will also be secure. We
>>> don't have to reinvent anything.
>>>
>>>
>>>
>>> Andy Schroder
>>>
>>> On 02/22/2015 02:08 PM, Jan Vornberger wrote:
>>>> Hi everyone,
>>>>
>>>> I am working on a Bitcoin point of sale terminal based on a Raspberry
>>>> Pi, which
>>>> displays QR codes, but also provides payment requests via NFC. It can
>>>> optionally
>>>> receive the sender's transaction via Bluetooth, so if the sender wallet
>>>> supports it, the sender can be completely offline. Only the terminal
>>>> needs an
>>>> internet connection.
>>>>
>>>> Typical scenario envisioned: Customer taps their smartphone (or maybe
>>>> smartwatch
>>>> in the future) on the NFC pad, confirms the transaction on their phone
>>>> (or smartwatch) and the transaction completes via Bluetooth and/or the
>>>> phone's
>>>> internet connection.
>>>>
>>>> You can see a prototype in action here:
>>>>
>>>> https://www.youtube.com/watch?v=P7vKHMoapr8
>>>>
>>>> The above demo uses a release version of Schildbach's Bitcoin Wallet,
>>>> so it
>>>> works as shown today. However, some parts - especially the Bluetooth
>>>> stuff - are
>>>> custom extensions of Schildbach's wallet which are not yet standard.
>>>>
>>>> I'm writing this post to document my experience implementing NFC and
>>>> offline
>>>> payments and hope to move the discussion forward around standardizing
>>>> some of
>>>> this stuff. Andy Schroder's work around his Bitcoin Fluid Dispenser
>>>> [1,2]
>>>> follows along the same lines, so his proposed TBIP74 [3] and TBIP75
>>>> [4] are
>>>> relevant here as well.
>>>>
>>>>
>>>> ## NFC vs Bluetooth vs NFC+Bluetooth ##
>>>>
>>>> Before I get into the implementation details, a few words for why I
>>>> decided to
>>>> go 

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/22/2015 03:35 PM, Andy Schroder wrote:
>> On 02/22/2015 02:39 PM, Eric Voskuil wrote:
>>> Hi Jan,
>>>
>>> This is really nice work.
>>>
>>> WRT the Schroder and Schildbach proposal, the generalization of the "r"
>>> and "payment_url" parameters makes sense, with only the potential
>>> backward compat issue on payment_url.
>>>
>>>> TBIP75 furthermore proposes to include an additional 'h' parameter
>>>> which would be a hash of the BIP70 payment request, preventing a MITM
>>>> attack on the Bluetooth channel even if the BIP70 payment request
>>>> isn't signed. This would have also been my suggestion, although I
>>>> know that Mike Hearn has raised concerns about this approach. One
>>>> being, that one needs to finalize the BIP70 payment request at the
>>>> time the QR code and NFC URI is generated.
>>>> ...
>>>> 3) Are there other comments regarding 'h' parameter as per TBIP75?
>>> Yes, this design is problematic from a privacy standpoint. Anyone within
>>> the rather significant range of the Bluetooth terminal is able to
>>> capture payment requests and correlate them to people. In other words it
>>> can be used to automate tainting.
>>>
>>> The problem is easily resolved by recognizing that, in the envisioned
>>> face-to-face trade, proximity is the source of trust. Even in the above
>>> proposal the "h" parameter is trusted because it was obtained by
>>> proximity to the NFC terminal. The presumption is that this proximity
>>> produces a private channel.
>>>
>>> As such the "tap" should transfer a session key used for symmetric block
>>> cipher over the Bluetooth channel. This also resolves the issue of
>>> needing to formulate the payment request before the NFC.
>>>
>>> As an aside, in other scenarios, such as an automated dispenser, this
>>> presumption does not hold. The merchant is not present to guard against
>>> device tampering. Those scenarios can be secured using BIP70, but cannot
>>> guarantee privacy.
>>>
>>> The other differences I have with the proposal pertain to efficiency,
>>> not privacy or integrity of the transaction:
>>>
>>> The proposed resource name is redundant with any unique identifier for
>>> the session. For example, the "h" parameter is sufficient. But with the
>>> establishment of a session key both as I propose above, the parties can
>>> derive a sufficiently unique public resource name from a hash of the
>>> key. An additional advantage is that the resource name can be
>>> fixed-length, simplifying the encoding/decoding.
>>>
>>> The MAC address (and resource name) should be encoded using base58. This
>> The MAC address (and session key) should be encoded using base58. This
> 
> 
> As I mentioned in my other e-mail, I don't know that we can consider
> this NFC a private channel, so I don't think a session key should be
> transmitted over it.

I don't think there is another option. The point of the NFC terminal is
to establish trust based on proximity.

I don't agree that it's insufficiently private. It's no less private
than if the customer pulled out an R2-D2 interface arm and plugged into
the merchant's terminal. The terminal connection can still be compromised.

IOW the merchant trusts that the person who just tapped on the NFC
terminal is the one who he/she is going to hand the product to, and both
parties trust that because of this handshake, no non-proximate
interlopers can monitor the content of the transaction. In the absence
of BIP70 (quite real in some scenarios) the payer also relies on
proximity to establish the identity of the receiver.

Otherwise, without proximity establishment, an *independent* secure
channel is required (see the Airbitz/RedPhone discussion). You end up
with an infinite regression problem. RedPhone terminates this regression
by relying on each party's ability to recognize the other's voice, and
in the difficulty of spoofing a voice. PKI deals with it by trusting
root CAs on presumed-trusted platforms (and a troublesome revocation
process). WoT establishes this by unspecified means (e.g. Peter Todd has
produced a nice video of him reading out his PGP key fingerprint).

If interlopers are so close to the NFC terminal that they can join the
session, they have effectively compromised an endpoint, so the privacy
problem becomes moot. Both endpoints must secure their devices to
achieve privacy in any design.

>>> is shorter than bas

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/22/2015 11:36 PM, Andy Schroder wrote:
> I agree that NFC is the best we have as far as a trust anchor that you
> are paying the right person. The thing I am worried about is the privacy
> loss that could happen if there is someone passively monitoring the
> connection. 

We have the same objective. Privacy loss is my primary concern with the
existing proposal.

> So, in response to some of your comments below and also in
> response to some of Eric Voskuil's comments in another recent e-mail:
> 
> Consider some cases:
> 
> If NFC is assumed private, then sending the session key over the NFC
> connection gives the payer and the payee assumed confidence that that a
> private bluetooth connection can be created.
> 
> If the NFC actually isn't private, then by sending the session key over
> it means the bluetooth connection is not private. An eavesdropper can
> listen to all communication and possibly modify the communication, but
> the payer and payee won't necessarily know if eavesdropping occurs
> unless communication is also modified (which could be difficult to do
> for a really low range communication).

I realize you are postulating a situation where an interloper monitors
but doesn't substitute the NFC communication. But clearly if you can do
one you have the potential to do the other, so if one is going to rely
on the assumption that the NFC tap can be monitored one must also accept
that it can be modified. Once one accepts this premise there is no point
in using NFC.

> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> unmodified but actually monitored by an eavesdropper) and use that
> public key received via NFC to encrypt a session key and send it back
> via bluetooth, to then initiate an encrypted bluetooth connection using
> that session key for the remaining communication, then the payee still
> receives payment as expected and the payer sends the payment they
> expected, and the eavesdropper doesn't see anything.

You can send a public cert over a public channel but before it can be
used it must be validated and verified to belong to the party that you
intend to communicate with privately. Otherwise the interloper can
substitute a public cert and subvert the payment process.

The reduces to the system requiring PKI just to establish private
communication. One might argue that BIP-70 already contemplates PKI.
However the above approach is significantly different in that it would
*require* all NFC/BT communication to use PKI just to be private.

Furthermore, to establish a private channel between *both* intended
parities, public certs must be exchanged in both directions. Otherwise,
if the customer isn't validated by the merchant, a distant interloper
can trivially use the merchant's public cert to obtain the payment
request from the Bluetooth terminal. This is the privacy breach that we
are trying to prevent in the first place.

Any requirement for PKI, in either direction, itself creates privacy
problems. But a requirement for customer certificates really gets hairy.

The PKI requirement can be dropped by instead exchanging self-generated
public keys, in the RedPhone model. However that requires out-of-band
secure communication of a common derived value by the parties. This
could be as simple as a number on each screen that one or both of the
parties compares. But this requires no private communication, and
therefore NFC is entirely unnecessary. This is in fact what I would
recommend for the BT-only scenario.

The value added by NFC is that proximity can be used to establish trust.
If that does not meet one's threshold for privacy then the parties need
to establish this trust through some presumably more private channel
(such as visual or voice confirmation).

Note that payment integrity can be reasonably ensured by relying on PKI
as established by BIP-70 (which also offers the seller non-repudiation
benefit). So this question is strictly about privacy.

> If we send a public key of the payee over the NFC connection (in place
> of a session key) and the NFC connection is assumed trusted (and is
> actually modified by an eavesdropper) and use that public key received
> via NFC to encrypt a session key and send it back via bluetooth, to then
> initiate an encrypted bluetooth connection using that session key for
> the remaining communication, then the payee receives no payment and the
> attack is quickly identified because the customer receives no product
> for their payment and they notify the payee, and hopefully the problem
> remedied and no further customers are affected. 

In this case the attacker hijacks the subsequent BT connection, sends a
payment request and gets paid. The only thing to prevent it would be
BIP-70/PKI, as mentioned above.

In a more complex attack the interloper can sit in the middle of all
communications between payer and receiver. Since the payer is not
validated by the 

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/23/2015 01:49 AM, Andreas Schildbach wrote:
> I think at this point I'd like to bring back my original suggestion of
> using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
> transmit some secret that could be eavesdropped, 

Hi Andreas,

DHKE will not improve the situation. Either we use a simple method to
transfer a session key or a complex method.

> but at least the session could not be decrypted from recordings.

DHKE doesn't offer greater forward secrecy than private transfer of a
session key, in fact it's lesser.

> Anyway, establishing a "mostly secure" session is clearly an improvement
> to no protection at all. If we can't find a solution to the dilemma of
> how to exchange the secret, I suggest going ahead with what we have and
> make the best from it.

I don't see that there is a dilemma. The current proposal has a
significant privacy problem that can be easily resolved, and the
resolution actually makes the implementation simpler.

e

> On 02/23/2015 08:36 AM, Andy Schroder wrote:
>> I agree that NFC is the best we have as far as a trust anchor that you
>> are paying the right person. The thing I am worried about is the privacy
>> loss that could happen if there is someone passively monitoring the
>> connection. So, in response to some of your comments below and also in
>> response to some of Eric Voskuil's comments in another recent e-mail:
>>
>> Consider some cases:
>>
>> If NFC is assumed private, then sending the session key over the NFC
>> connection gives the payer and the payee assumed confidence that that a
>> private bluetooth connection can be created.
>>
>> If the NFC actually isn't private, then by sending the session key over
>> it means the bluetooth connection is not private. An eavesdropper can
>> listen to all communication and possibly modify the communication, but
>> the payer and payee won't necessarily know if eavesdropping occurs
>> unless communication is also modified (which could be difficult to do
>> for a really low range communication).
>>
>> If we send a public key of the payee over the NFC connection (in place
>> of a session key) and the NFC connection is assumed trusted (and is
>> unmodified but actually monitored by an eavesdropper) and use that
>> public key received via NFC to encrypt a session key and send it back
>> via bluetooth, to then initiate an encrypted bluetooth connection using
>> that session key for the remaining communication, then the payee still
>> receives payment as expected and the payer sends the payment they
>> expected, and the eavesdropper doesn't see anything.
>>
>> If we send a public key of the payee over the NFC connection (in place
>> of a session key) and the NFC connection is assumed trusted (and is
>> actually modified by an eavesdropper) and use that public key received
>> via NFC to encrypt a session key and send it back via bluetooth, to then
>> initiate an encrypted bluetooth connection using that session key for
>> the remaining communication, then the payee receives no payment and the
>> attack is quickly identified because the customer receives no product
>> for their payment and they notify the payee, and hopefully the problem
>> remedied and no further customers are affected. The privacy loss will be
>> significantly reduced and the motive for such attacks will be reduced.
>> It's possible a really sophisticated modification could be done where
>> the attacker encrypts and decrypts the communication and then relays to
>> each party (without them knowing or any glitches detected), but I guess
>> I'm not sure how easy that would be on such a close proximity device?
>>
>> Erick Voskuil mentioned this same problem would even occur if you had a
>> hardwired connection to the payment terminal and those wires were
>> compromised. I guess I still think what I am saying would be better in
>> that case. There is also more obvious physical tampering required to
>> mess with wires.
>>
>> I'm not sure if there is any trust anchor required of the payer by the
>> payee, is there? Eric also mentioned a need for this. Why does the payer
>> care who they are as long as they get a payment received? Just to avoid
>> a sophisticated modification" that I mention above? I can see how this
>> could be the case for a longer range communication (like over the
>> internet), but I'm not convinced it will be easy on really short ranges?
>> It's almost like the attacker would be better off to just replace the
>> entire POS internals than mess with an attack like that, in which case
>> everything we could do locally (other than the payment request signing
>> using PKI), is useless.
>>
>> I'm not a cryptography expert so I apologize if there is something
>> rudimentary that I am missing here.
>>
>> Andy Schroder
>>
>> On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
>>> On 02/23/2015 12:32 AM, Andy Schroder wrote:
 I guess we need to decide whether we want to consider NFC communication
 private or not. I don't know that I thi

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

Mike,

Before addressing other issues I could use some clarification on your
intent.

In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):

> doing ECDH over secp256k1 to derive a session key means we can reuse
> the address that was put in the URI already for pre-BIP70 wallets

In another statement you refer to derivation of a session key from a
public key (passed via  BT):

> The public key can then be provided in full in the clear over the
> Bluetooth connection and the session key derived.

I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?

e

On 02/23/2015 02:58 AM, Mike Hearn wrote:
> DHKE will not improve the situation. Either we use a simple method to
> transfer a session key or a complex method.
> 
> You're right that just sending the session key is simpler. I originally
> suggested doing ECDHE to set up an encrypted channel for the following
> reasons:
> 
>  1. URIs are put in QR codes more often than NFC tags. QR codes have
> limited space. The more stuff you pack into them, the slower and
> flakier the scanning process becomes.
> 
> For normal wallets, doing ECDH over secp256k1 to derive a session
> key means we can reuse the address that was put in the URI already
> for pre-BIP70 wallets, thus we don't have to expand the URI at all
> except perhaps to flag that crypted Bluetooth connections are
> supported. Win!
> 
>  2. If the wallet is a watching wallet, this won't work and in that case
> you would need to put a separate key into the URI. However, this key
> is ephemeral and does not need to be very strong. So we can generate
> a regular secp256k1 key and then put say 5-8 prefix bytes into the
> URI as a new parameter. The public key can then be provided in full
> in the clear over the Bluetooth connection and the session key
> derived. If we put the session key into the URI in full, then we
> could not use this trick. Win!
> 
>  3. It's quite common in low tech scenarios like little coffee shops to
> just print a QR code and put it in the menu, or sticky tape it to
> the back wall of the shop.
> 
> In these cases, it's possible that the device is actually hanging
> around in the shop somewhere but having the QR code somewhere larger
> and more accessible than the shop devices screen is highly
> convenient. However it means the data is entirely static.
> 
> Putting/reusing an identity key from the URI means the session keys
> are always unique and known only to both devices, even though the
> bootstrap data is public.
> 
>  4. Doing ECDHE to derive the keys means we can derive a MAC key as well
> as an AES key. Otherwise you have the issue of exchanging both,
> which again uses up valuable bootstrap space.
> 
> So for a small increase in session setup complexity we potentially avoid
> troubling problems down the line where people the same functionality
> from NFC and QR code based bootstrap, but we can't provide it.
> 
> These discussions keep coming up. I think the next step is for someone
> to upgrade Andreas' wallet to support encrypted connections and the
> TBIPs, to see what happens.
> 
> Re: the h= parameter. I only objected to requiring this when the payment
> request is also signed. It adds complexity, uses space, and the
> rationale was "the PKI can't be trusted" even though it's been used to
> protect credit card payments for 20 years without any issues. In the
> case of unsigned payment requests, sure ... but with a proper
> implementation of an encrypted Bluetooth channel it'd be unnecessary as
> the channel establishment process would guarantee authenticity anyway.
> 
> But don't let me hold you guys back! I'd rather see something that works
> than an endless debate about the perfect arrangement of hashes and URI
> parameters :)
> 



signature.asc
Description: OpenPGP digital signature
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/23/2015 03:11 PM, Mike Hearn wrote:
>> I don't see how you propose to treat the bitcoin address as a
>> secp256k1 public key, or do you mean something else?
>
> Sorry, I skipped a step. I shouldn't make assumptions about what's
> obvious.

No problem, we don't all have the same context. I may have missed prior
discussion.

> The server would provide the public key and the client would
> convert it to address form then match against the URI it has scanned.
> If it didn't match, stop at that point.

Does this not also require the BT publication of the script for a P2SH
address?

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

Andy, adding to my previous post below:

On 02/23/2015 01:40 AM, Eric Voskuil wrote:
> On 02/22/2015 11:36 PM, Andy Schroder wrote:
...
>> It's possible a really sophisticated modification could be done where
>> the attacker encrypts and decrypts the communication and then relays to
>> each party (without them knowing or any glitches detected), but I guess
>> I'm not sure how easy that would be on such a close proximity device?
> 
> If the NFC tap is sufficiently private, privacy is easy to achieve for
> the subsequent communication. If it is not, privacy can be completely
> compromised. The question is only how much more difficult is the attack.
> 
> With the public cert tap, the level of difficulty is much lower for
> capturing selected payment requests. The interloper no longer needs to
> invade the space of the NFC terminal and can instead impersonate the
> payer from a safe distance. Nobody gets paid, but privacy is compromised.

This problem in the preceding paragraph can be resolved by sending a
unique public key on each NFC tap. In that case an attacker would need
to monitor the NFC communication.

The talk of wrapping the connection in SSL led me to believe you were
talking about a static public certificate. However that's not a
necessary assumption here and may not be what you intended.

> The level of difficulty in the case where the interloper wants to taint
> transactions may appear lower, but it is not:
> 
> With the session key tap the interloper must compromise the NFC location
> and then monitor the BT traffic. Monitoring BT traffic without being
> party to the connection is presumably not rocket surgery, but not
> standard BT design either.
> 
> With the public cert tap the interloper must also compromise the NFC
> location and communicate over BT. Therefore the hardware and physical
> attack requirements are similar. The only added difficulty is that the
> attack on the NFC terminal attack is active (modifying the MAC address
> directing the payer to the BT service).

I believe your central claim was that the difference in the two
bootstrapping approaches (public key vs. session key) is that by using a
unique public key per tap, the attack requires an active vs. passive
attack on the NFC terminal. I just wanted to make clear here that I
agree with that assessment.

The symmetric key approach is based on the idea that these attacks are
comparable in difficulty and otherwise identical in privacy loss.

However, the difference in implementation amounts to about +23
additional encoded characters for the BT/LE URL, assuming use of the
secp256k1 curve for DHE. This is really not a material issue in the case
of the NFC tap. The entire URI+URL could be as small as:

bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP

In comparison to a symmetric key:

bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbXg8E

It also does not change the protocol design or complexity at all - it
would just swap out an AES key for a secp256k1 public key.

bitcoin:[address]?bt:/

If that gets us aligned I'm all for it.

> However impersonating the payer is just a matter of software - no more
> difficult than the session key attack. In fact it may be much easier to
> implement, as the attack can use supported BT features because the
> attacker has directed the payer to connect to him and is connecting to
> the receiver as if he was a payer.
> 
> But it gets worse for the public cert tap, since a more sophisticated
> attacker can set himself up in the same position without subverting the
> NFC terminal at all. By broadcasting a more powerful BT service on the
> same advertised MAC address, the attacker can capture traffic and relay
> it to the intended service.

I'm retracting the last paragraph, since the interloper, without
invading the NFC connection (by substituting the public cert), could not
read the relayed traffic. It was getting late :/

> So in sum, reliance on a public cert makes the communication less
> private under the same physical set of constraints. The difference
> results from the receiver allowing non-proximate payers to impersonate
> proximate payers from a distance by generating their own session keys
> and submitting them over BT.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

is discussion. I do think sending a unique public key over NFC has to
> be better than a unique session key. It adds one more step, but seems to
> help. 

It doesn't actually add another step to the protocol, just some
different but simple code on each end. The only downside is that it
extends the NFC URL about 23 characters.

> If we do this, can we then safely get rid of the h= parameter?

Absolutely, and I believe Mike ack'd this on a previous post today.

> That should make Mike Hearn happy, and also may alleviate the base64url
> debate?

Others may not be aware of the encoding squabble (not sure if it
qualifies as debate). In the proposed URL, it affects the mac address
and the key:

bitcoin:[address]?bt:/

base58:
bitcoin:?r=bt:12rAs9mM/234KF8hPkXq5pa6pT1wnJC3hVH7W6yB2Wtw24ztzGtBc4

base64url:
bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh

I prefer base58 because it's available to all bitcoin libraries, nearly
as compact as base64 (+1 byte in our example) and better standardized.
Some embedded device people might care about having to incorporate
base64 as well as base58.

It's also better looking (no - or _ characters) and more consistent in
the proposed URL (all three values would be base58, as opposed to one
base58 and two base64url). There may be some idea that base58 is just
for bitcoin addresses (not true) or designed for humans... that's sort
of the point, but it's also good for URLs.

e

> On 02/23/2015 09:55 PM, Eric Voskuil wrote:
>> Andy, adding to my previous post below:
>>
>> On 02/23/2015 01:40 AM, Eric Voskuil wrote:
>>> On 02/22/2015 11:36 PM, Andy Schroder wrote:
>> ...
>>>> It's possible a really sophisticated modification could be done where
>>>> the attacker encrypts and decrypts the communication and then relays to
>>>> each party (without them knowing or any glitches detected), but I guess
>>>> I'm not sure how easy that would be on such a close proximity device?
>>> If the NFC tap is sufficiently private, privacy is easy to achieve for
>>> the subsequent communication. If it is not, privacy can be completely
>>> compromised. The question is only how much more difficult is the attack.
>>>
>>> With the public cert tap, the level of difficulty is much lower for
>>> capturing selected payment requests. The interloper no longer needs to
>>> invade the space of the NFC terminal and can instead impersonate the
>>> payer from a safe distance. Nobody gets paid, but privacy is
>>> compromised.
>> This problem in the preceding paragraph can be resolved by sending a
>> unique public key on each NFC tap. In that case an attacker would need
>> to monitor the NFC communication.
>>
>> The talk of wrapping the connection in SSL led me to believe you were
>> talking about a static public certificate. However that's not a
>> necessary assumption here and may not be what you intended.
>>
>>> The level of difficulty in the case where the interloper wants to taint
>>> transactions may appear lower, but it is not:
>>>
>>> With the session key tap the interloper must compromise the NFC location
>>> and then monitor the BT traffic. Monitoring BT traffic without being
>>> party to the connection is presumably not rocket surgery, but not
>>> standard BT design either.
>>>
>>> With the public cert tap the interloper must also compromise the NFC
>>> location and communicate over BT. Therefore the hardware and physical
>>> attack requirements are similar. The only added difficulty is that the
>>> attack on the NFC terminal attack is active (modifying the MAC address
>>> directing the payer to the BT service).
>> I believe your central claim was that the difference in the two
>> bootstrapping approaches (public key vs. session key) is that by using a
>> unique public key per tap, the attack requires an active vs. passive
>> attack on the NFC terminal. I just wanted to make clear here that I
>> agree with that assessment.
>>
>> The symmetric key approach is based on the idea that these attacks are
>> comparable in difficulty and otherwise identical in privacy loss.
>>
>> However, the difference in implementation amounts to about +23
>> additional encoded characters for the BT/LE URL, assuming use of the
>> secp256k1 curve for DHE. This is really not a material issue in the case
>> of the NFC tap. The entire URI+URL could be as small as:
>>
>> bitcoin:?r=bt:12rAs9mM/79bq48xJaMgqR9YNxnWhqHHM1JB52nxn6VFXBHTP2zrP
>>
>> In comparison to a symmetric key:
>>
>> bitcoin:?r=bt:12rAs9mM/12drXXUifSrRnXLGbX

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

ter name) be
deterministically derived from the session key. Given the design change
to pass an EC public key it would need to be derived from that key (not
from the session key because the receiver would not have a copy before
decrypting the first BT message). So any function on the public key that
reduces it to a smaller length, fixed width should be fine. Hashing it
first may be better as is prevents disclosure of any bits of the public
key, which should be treated as a secret during the session.

>   * When you said a new public key for each tap, do you see that as
> every single tap, or do you consider multiple taps from the same
> customer the same tap?

Yes, since there would be no other way to distinguish between customers
in some scenarios and this is the safest approach. We certainly won't
run out of numbers, and unused sessions can be discarded based on any
number of criteria, including discarding all but the most recent. That
may may be sufficient for your vending machines given there's little if
any call for parallelism.

e

> On 02/24/2015 06:28 AM, Eric Voskuil wrote:
>> On 02/23/2015 09:53 PM, Andy Schroder wrote:
>>> I was saying provide a public key via NFC (or a public key fingerprint
>>> and then send the full public key over bluetooth). Instead of providing
>>> a new public key on each tap, why can't the payee just stop accepting
>>> connections from new parties on that "resource" after a session key has
>>> been received from the first person?
>> Because the presumption was that there was not an additional secret in
>> the URI. If the public key is reused then anyone can spoof a payer and
>> obtain payment requests.
>>
>> Adding a secret to the URI can resolve this, as long as it is encrypted
>> with the public key before being transmitted back to BT. Otherwise the
>> secret can be intercepted and replayed to the terminal, encrypted with
>> the well-known public key.
>>
>> So if you want to treat the "resource" as a secret this would work.
>> However the resource was designed as a public session identifier,
>> leading the byte stream. This changes it to private session identifier,
>> which loses some utility.
>>
>> Also, reuse of the public key introduces a forward secrecy problem and
>> the potential for persistent seller impersonation in the case of
>> undiscovered key compromise.
>>
>> But there's really no benefit to reusing the key. An ephemeral key
>> resolves these issues and can also seed the public resource name.
>>
>>> If the person decides to have there
>>> friend or family pay for them instead and cancel the payment, they could
>>> just hit cancel on the POS or something (on my fuel pump I have a switch
>>> that needs to be turned, the purpose of this is to avoid wasting too
>>> many addresses)
>> Don't you have someone stop by the pump once a week and empty out the
>> addresses? :)
>>
>>> and/or do another NFC tap (if you're providing QR codes
>>> you'd still need a button of some kind though so it knows to refresh
>>> it), or the POS can just provide a completely new payment request to any
>>> new connections on that same "resource" which use a different session key.
>>>
>>> I feel like the authentication of the payer to the payee in any future
>>> connections after they receive the session key from them (which was
>>> encrypted with the payees public key), comes from the fact that they are
>>> sending responses back that are encrypted using the session key they
>>> gave to the payee. The way I am seeing it is that the NFC tap or QR code
>>> scan is acting in addition to the visual name check on the signature
>>> verification in the wallet.
>> With a secure channel that identifies the parties by proximity, the
>> reason for the payment request signature is for the payer to obtain a
>> non-repudiation guarantee. But it also serves as a defense-in-depth
>> solution to a compromise of the channel (though does not offer a benefit
>> in the case of seller terminal/cert compromise).
>>
>>> If the certificate used isn't signed by a CA
>>> (self signed), it may be fine as long as you heard about it via NFC or
>>> QR code. I don't think it will require PKI and should still work
>>> wallet-to-wallet.
>> In that case the cert provides no benefit. A self-signed cert can be
>> repudiated and if the channel is compromised anyone can sign the payment
>> request.
>>
>>> It sounds like you are saying I'm proposing the customer is going to
>&g

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/24/2015 02:50 PM, Andy Schroder wrote:
> We can change "resource" to "Session ID" if you want.
> 
> I think the URL scheme should be:
> 
> bitcoin:[address]?r=bt:&s=

This is a question of proper URL semantics, as applied to the "bt" scheme.

From rfc3986 [Uniform Resource Identifier (URI): Generic Syntax]:

"The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any)."

...

"The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a resource
within the scope of the URI's scheme and naming authority (if any). The
query component is indicated by the first question mark ("?") character
and terminated by a number sign ("#") character or by the end of the URI."

https://tools.ietf.org/html/rfc3986#section-3.3

The question therefore is whether  is (1) relative to the path
(hierarchical) or (2) independent of the path and instead relative to
the scheme and naming authority.

The "bt" scheme does not include a naming authority, and as such the
question is simply whether  is relative to "bt" or relative to the
path, which is . Quite clearly  is valid only in the context
of , not relevant to all s.

As such one must conclude that the proper form is:

bt:/

> But when connecting to the mac, the client indicates the SessionID in
> the header, and as you say, SessionID is derived in some way from
> PublicKey.

Yes.

> This is a slightly different format than both of your suggestions below,
> but seems to make more sense based on what you said in your entire
> message. The other thing is it can be used with more protocols without
> taking up more space in the URL.
> 
> However, by loosing the h= parameter, I think we are now loosing some
> benefit it brought to https based connections if the customer doesn't
> want to use bluetooth. Right?

I don't believe that the BIP-70 protocol over https has any need for the
parameter. It was only useful because the NFC/BT session wasn't secured.
So I don't think anything is lost.

> Also, you talk about a new public key (and session ID) for each tap. I
> guess I'm wondering about this though. If the public key is compromised
> on the first tap, isn't their payment request already compromised?

Yes, but that is not the problem that non-reuse is designed to resolve.

Reuse of the public key creates a forward secrecy problem. If 1000
sessions are recorded, and later the private key associated with the
reused public key is compromized, all of the sessions are retroactively
compromised.

Another problem is persistent impersonation. If the one associated
private key is compromised, and nobody knows it, the attacker can not
only monitor all transactions but can selectively steal payments (if
they aren't signed and verified). This is BTW also a good reason to not
use HD generation of these session keys.

Another problem is that any payer can use the well-known public key to
obtain payment requests.

Another problem is that without a unique public key there is no unique
session id, so that would need to be added explicitly on the URI.

> Since we are securing everything, can we change the message header
> format from what Schildbach's bitcoin wallet implements to something
> more consistent?

Could you spell this out, I'm not familiar with the implementation, just
the proposals.

> Maybe we can create a new UUID for this secure service
> so Schildbach's bitcoin wallet can still maintain backwards compatibility.

That may be necessary depending on the implementation of existing
terminals, but I'm not familiar enough to speculate.

e

> On 02/24/2015 05:14 PM, Eric Voskuil wrote:
>>>* Add a "s=" parameter that uses a unique public key for each
>>> session.
>>>  This public key identifies the payee to the payer and payer to the
>>>  payee.
>> This would be the simple model, which just tacks on another parameter to
>> the bitcoin URL:
>>
>> bitcoin:[address]?bt=&s=
>>
>> But we should also look at the more flexible "r#" approach from your
>> existing TBIPs, which would yield:
>>
>> bitcoin:[address]?r=bt:/
>>
>> and incorporate the "payment_url" list.
>>
>>>* Use a base58 encoding to save space and reduce the character set
>>>  slightly.
>> :)
>>
>>>* Get rid of the resource? If a terminal is accepting payment from
>>>  multiple customers simultaneously, it should be

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

The list appears dead, this is a test.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

[Eric Voskuil]

On 02/26/2015 04:30 AM, Andreas Schildbach wrote:
> On 02/24/2015 11:41 AM, Mike Hearn wrote:
>> On 02/23/2015 04:10 PM, Eric Voskuil wrote:
>>> Does this not also require the BT publication of the script for a P2SH
>>> address?
>>
>> You mean if the URI you're serving is like this?
>>
>>bitcoin:3aBcD?bt=
>>
>> Yes it would. I guess then, the server would indicate both the script,
>> and the key within that script that it wanted to use. A bit more complex
>> but would still work to save URI space.
> 
> What if the script doesn't use any key at all?
> 
> Somehow this "re-using" the fallback address idea feels less and less
> appealing to me. I think we should add our own parameter and let go of
> fallback addresses as soon as possible. If will waste space during the
> transition period, but after that it should make no difference any more.

Agree. The amount of bitcoin URI space in question isn't a material
issue when it comes to NFC. The more significant considerations here are
the additional BT round trip to establish a session, greater complexity,
and the potential lack of a correlating address (as you point out above).

On the other hand I think the approach has merit in a scenario where the
bitcoin URI is read from a QR code and BT is available (IOW no NFC).
Generalizing it to the NFC-based bitcoin URI is the problem.

A much cleaner generalization is to rationalize the two approaches
*after* the bitcoin URI has been read (from either NFC or QR). In the QR
scenario the wallet can obtain a verifiable public key from the BT
terminal (subject to some limitations as discussed above). In the NFC
scenario the public key is just passed in the URI. The scenarios come
together at the point where they both have the public key (and the mac
address).

This of course implies that the the BT URL scheme, in order to be used
in both places, would have to allow the public key to be optional. But
in an NFC tap it would be present and in a QR scan it would not.

QR-BT
bitcoin:?bts:

NFC-BT
bitcoin:[bitcoin-address]?bts:/

As you say, this prevents the NFC scenario from perpetuating the
fallback address as a requirement, which eventually shortens the bitcoin
URI.

Making the public key a requirement when used with NFC would simplify
wallet development for NFC only wallets. But if a wallet supported both
NFC and QR scanning it wouldn't make much difference. So it's not
unreasonable to think of it like this:

QR-BT/NFC-BT
bitcoin:?bts:
bitcoin:[bitcoin-address]?bts:/

This provides greater generality, but it creates a situation where
NFC-only wallets need to support the more complex approach, and where
use in QR codes would have scanning issues. So I think it's better to
specify limits on each as in the first example.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

[Eric Voskuil]

On 02/14/2015 05:13 AM, Peter Todd wrote:
> So stop wasting your time. Help get the consensus critical code out of
> Bitcoin Core and into a stand-alone libconsensus library...

done

https://github.com/libbitcoin/libbitcoin-consensus

> ...
> Then ... when the next time we decide to soft-fork Bitcoin the
> process isn't some secretive IRC discussion by a half-dozen "core
> developers" - and one guy who finds the term hilarious - but a full on
> DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,
> complete with twinkle fingers.

You seriously made me laugh out loud with this one Peter.

e



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

[Eric Voskuil]

On 06/01/2015 08:55 AM, Mike Hearn wrote:
>> Decentralization is the core of Bitcoin's security model and thus
that's what gives Bitcoin its value.
> No. Usage is what gives Bitcoin value.

Nonsense.

Visa, Dollar, Euro, Yuan, Peso have usage.

The value in Bitcoin is *despite* it's far lesser usage.

Yes, the price is a function of demand, but demand is a function of
utility. Despite orders of magnitude less usage than state currencies,
Bitcoin has utility. This premium *only* exists due to its lack of
centralized control. I would not work full time, or at all, on Bitcoin
if it was not for decentralization; nor would I hold any of it. I doubt
anyone would show an interest in Bitcoin if it was not decentralized. If
it centralized even you would be forced to find something else to do,
because Bitcoin "usage" would drop to zero.

> It's kind of maddening that I have to point this out. Decentralisation
is a means to an end.

No, it was/is the primary objective. Paypal had already been done. If
anything is maddening it's that you of all people can't see this. When
people talk about the core innovation of Bitcoin, it's a conversation
about Byzantine Generals, not wicked growth hacking.

> in April 2009 and it was perfectly decentralised [...] every wallet
was a full node and every computer was capable of mining. So if you
believe what you just wrote [...] Bitcoin's value has gone down every
day since

An obvious non sequitur. By way of example, if 10 of 10 participants are
capable of mining it is not more decentralized than if 1,000 in 100,000
are doing so. 1,000 *people* in control vs. 10 is two orders of
magnitude more decentralized. The *percentage* of the community that
mines is totally irrelevant, it's the absolute number of (independent)
people that matters.

I'm not making a statement on block size, just trying to help ensure
that ill-considered ideas, like this inversion of the core value
proposition, stay on the margins.

e






signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

[Eric Voskuil]

On 06/02/2015 04:03 AM, Mike Hearn wrote:
>
>  1,000 *people* in control vs. 10 is two orders of
>
> magnitude more decentralized. 
>
>
> Yet Bitcoin has got worse by all these metrics: there was a time
> before mining pools when there were ~thousands of people mining with
> their local CPUs and GPUs. Now the number of full nodes that matter
> for block selection number in the dozens, and all the other miners
> just follow their blocks blindly.

A mining pool is not a person, a full node is not a miner, and
cooperation is not control.

http://bravenewcoin.com/news/number-of-bitcoin-miners-far-higher-than-popular-estimates/

The entire Bitcoin ecosystem cooperates, that is what consensus means.
Establishing proof of that cooperation is the purpose of Bitcoin.

Decentralization is about keeping control out of the hands of the state
(any entity that would substitute violence for consensus). Nobody has
the power to compel the cooperation of individual miners in a pool. When
state power is applied to a pool operator the miners (people) retain
their vote.

e



signature.asc
Description: OpenPGP digital signature
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development