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

2015-06-02 Thread 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

2015-06-02 Thread 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


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

2015-03-25 Thread 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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-03-02 Thread 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:bitcoin-address?bts:mac-address

NFC-BT
bitcoin:[bitcoin-address]?bts:mac-address/public-key

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:bitcoin-address?bts:mac-address
bitcoin:[bitcoin-address]?bts:mac-address/public-key

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] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Eric Voskuil
 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:mac/key

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/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:mac/key

 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

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

2015-02-25 Thread Eric Voskuil
 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
 need a certificate signed by CA? If so, why? 
 This was not a serious proposal, it was to point out what would become
 necessary if the payer could not be identified by proximity.

 In the case where a public key is reused, any payer can contact the BT
 terminal and obtain the payment request. If the merchant can't rely on
 proximity (i.e. can't trust the integrity of the NFC connection) then he
 would have to fall back on some other means of identifying the payer. A
 mutual verbal/visual confirmation could work, but the point of of NFC+BT
 is elimination of that hassle.

 Yes, it sounds a bit wild, but I have seen on this list a serious
 proposal to have people broadcast their photo, having the merchant
 select them and push to them the payment request. Of course anyone can
 spoof another's image, so at some point your image would need to be
 certified, and hence a CA.

 I wouldn't go there, but was just making the point.

 I don't need this for any https website I visit.
 When you go to a web site you first establish a private communication.
 The site doesn't know who you

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

2015-02-25 Thread 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

2015-02-25 Thread 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:macs=PublicKey

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 key 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 key is relative to bt or relative to the
path, which is mac. Quite clearly key is valid only in the context
of mac, not relevant to all macs.

As such one must conclude that the proper form is:

bt:mac/key

 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=macs=key

 But we should also look at the more flexible r# approach from your
 existing TBIPs, which would yield:

 bitcoin:[address]?r=bt:mac/key

 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 smart enough to
  distinguish between customers based on the public key they are
  encrypting the data with. Is this approach feasible?
 Yes, it is not necessary on the URL. But an id is useful in helping the
 BT terminal identify the session without having to try all of its
 outstanding keys until it finds one that works.

 I proposed that the resource name (session id may be a better name) be
 deterministically derived from the session key. Given the design change
 to pass an EC

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

2015-02-23 Thread 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=190641631iu=/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

2015-02-23 Thread 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 think it can be. An eavesdropper can
 place a tiny snooping device near and read the communication. If it is
 just passive, then the merchant/operator won't 

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

2015-02-23 Thread 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

2015-02-23 Thread 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:mac/key

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

2015-02-22 Thread 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
 support
 the mime type record, which is then set to
 'application/bitcoin-paymentrequest'
 and the rest of the NFC data is a complete BIP70 payment request.


 ## Implementation ##

 To structure the discussion a little bit, I 

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

2015-02-22 Thread 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 everything can happen in 
 one
 go. The disadvantage is, that you confirm the 

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

2015-02-22 Thread 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 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

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

2015-02-22 Thread 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 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

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

2015-02-22 Thread 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 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.
 
 
 The order is set so that it maintains backwards compatibility by
 providing the https request first.

Understood, it just isn't entirely clear to me that the backward compat
in this case doesn't depend on implementation choices of existing
systems

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

2015-02-10 Thread 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 e...@voskuil.org:
 On 02/05/2015 04:36 PM, Martin Habovštiak wrote:
 I believe, we are still talking about transactions of physical
 people in physical world. So yes, it's proximity based - people
 tell the words by mouth. :)

 Notice from my original comment:

 A MITM can substitute the key. If you don't have verifiable
 identity associated with the public key (PKI/WoT), you need
 a shared secret (such as a secret phrase).

 I said this could only be accomplished using a shared secret or a
 trusted public key. Exchanging a value that is derived from a pair of
 public keys is a distinction without a difference. The problem remains
 that the parties must have a secure/out-of-band channel for
 communicating this value.

 The fact that they are face-to-face establishes this channel, but that
 brings us back to the original problem, as it requires manual
 verification - as in visual/audible scanning of the two values for
 comparison. At that point the visual comparison of the address, or some
 value derived from it, is simpler.
 
 I have never been against manual verification. What I'm trying to say
 is let's just make manual verification easier and more secure.
 Comparison of address is simpler for the coder but also simpler to
 attack. It has these problems:
 - Addresses broadcasted in plaintext (privacy issue)
 - Amounts broadcasted in plaintext (privacy issue)
 - Address is long - takes lot of time to verify (user experience issue)
 - Address prefix can be brute-forced, if too short or used to make
 black hole address if longer (vandalism issue)
 
 Commit protocol can be used for both the encryption and the
 authentication while user experience is not bad and everything is
 still secure.
 

 In case of RedPhone, you read those words verbally over not-yet-
 verified channel relying on difficulty of spoofing your voice. Also
 the app remembers the public keys, so you don't need to verify
 second time.

 This is reasonable, but wouldn't help in the case of an ad-hoc
 connection between parties who don't know each other well.

 I suggest you to try RedPhone (called Signal on iPhone) yourself.
 It's free/open source, Internet-based and end-to-end encrypted. You
 may find it useful some day. Also I'm willing to help you with
 trying it after I wake up. (~8 hours: Send me private e-mail if
 you want to.)

 I appreciate the offer. I really don't trust *any* smartphone as a
 platform for secure communication/data. But encrypting on the wire does
 of course shrink the attack surface and increase the attacker's cost.

 e

 Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil
 e...@voskuil.org napísal:

 On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
 That's exactly what I though when seeing the RedPhone code, but after
 I studied the commit protocol I realized it's actually secure and
 convenient way to do it. You should do that too. :)

 I was analyzing the model as you described it to me. A formal analysis
 of the security model of a particular implementation, based on
 inference
 from source code, is a bit beyond what I signed up for. But I'm
 perfectly willing to comment on your description of the model if you
 are
 willing to indulge me.

 Shortly, how it works:
 The initiator of the connection sends commit message containing the
 hash of his temporary public ECDH part, second party sends back their
 public ECDH part and then initiator sends his public ECDH part in
 open. All three messages are hashed together and the first two bytes
 are used to select two words from a shared dictionary which are
 displayed on the screen of both the initiator and the second party.

 The parties communicate those two words and verify they match.

 How do they compare words if they haven't yet established a secure
 channel?

 If an attacker wants to do MITM, he has a chance of choosing right
 public parts 1:65536. There is no way to brute-force it, since that
 would be noticed immediately. If instead of two words based on the
 first two bytes, four words from BIP39 wordlist were chosen, it would
 provide

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

2015-02-10 Thread Eric Voskuil
On 02/10/2015 02:41 AM, Natanael wrote:
 Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak
 martin.habovst...@gmail.com 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

2015-02-10 Thread 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 e...@voskuil.org:
 Martin,

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

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

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

 But imagine someone purchasing their meds. HIPAA requires the checkout
 queue to form behind a yellow line. That speaks directly to this question.

 e

 On 02/06/2015 01:07 AM, MⒶrtin HⒶboⓋštiak wrote:
 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org:
 On 02/05/2015 04:36 PM, Martin Habovštiak wrote:
 I believe, we are still talking about transactions of physical
 people in physical world. So yes, it's proximity based - people
 tell the words by mouth. :)

 Notice from my original comment:

 A MITM can substitute the key. If you don't have verifiable
 identity associated with the public key (PKI/WoT), you need
 a shared secret (such as a secret phrase).

 I said this could only be accomplished using a shared secret or a
 trusted public key. Exchanging a value that is derived from a pair of
 public keys is a distinction without a difference. The problem remains
 that the parties must have a secure/out-of-band channel for
 communicating this value.

 The fact that they are face-to-face establishes this channel, but that
 brings us back to the original problem, as it requires manual
 verification - as in visual/audible scanning of the two values for
 comparison. At that point the visual comparison of the address, or some
 value derived from it, is simpler.

 I have never been against manual verification. What I'm trying to say
 is let's just make manual verification easier and more secure.
 Comparison of address is simpler for the coder but also simpler to
 attack. It has these problems:
 - Addresses broadcasted in plaintext (privacy issue)
 - Amounts broadcasted in plaintext (privacy issue)
 - Address is long - takes lot of time to verify (user experience issue)
 - Address prefix can be brute-forced, if too short or used to make
 black hole address if longer (vandalism issue)

 Commit protocol can be used for both the encryption and the
 authentication while user experience is not bad and everything is
 still secure.


 In case of RedPhone, you read those words verbally over not-yet-
 verified channel relying on difficulty of spoofing your voice. Also
 the app remembers the public keys, so you don't need to verify
 second time.

 This is reasonable, but wouldn't help in the case of an ad-hoc
 connection between parties who don't know each other well.

 I suggest you to try RedPhone (called Signal on iPhone) yourself.
 It's free/open source, Internet-based and end-to-end encrypted. You
 may find it useful some day. Also I'm willing to help you with
 trying it after I wake up. (~8 hours: Send me private e-mail if
 you want to.)

 I appreciate the offer. I really don't trust *any* smartphone

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

2015-02-06 Thread 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:mac 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

2015-02-06 Thread 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] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI

2015-02-05 Thread 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 p...@airbitz.co
 mailto:p...@airbitz.co wrote:
 
 The BIP70 protocol would preclude individuals from utilizing the P2P
 transfer spec. It would also require that a Sender have internet
 connectivity to get the payment protocol info. BLE could enable
 payment w/o internet by first transferring the URI to from Recipient
 to Sender. Then in the future, we could sign a Tx and send it over
 BLE back to the recipient (who would still need internet to verify
 the Tx). This is an important use case for areas with poor 3G/4G
 connectivity as I've experience myself.
 
 Also, due to Android issues, NFC is incredibly clunky. The URI
 Sender is required to tap the screen *while* the two phones are in
 contact. We support NFC the same way Bitcoin Wallet does, but unless
 the payment recipient has a custom Android device (which a merchant
 might) then the usage model is worse than scanning a QR code. BLE
 also allows people to pay at a distance such as for a donation to a
 live performer. We'll look at adding this to the Motivation section.
 
 From: Andreas Schildbach andreas@sc... - 2015-02-05 13:47:04
 
 Thanks Paul, for writing up your protocol!
 
 First thoughts:
 
 For a BIP standard, I think we should skip bitcoin: URIs entirely and
 publish BIP70 payment requests instead. URIs mainly stick around because
 of QR codes limited capacity. BIP70 would partly address the copycat
 problem by signing payment requests.
 
 In your Motivation section, I miss some words about NFC. NFC already
 addresses all of the usability issues mentioned and is supported by
 mobile wallets since 2011. That doesn't mean your method doesn't make
 sense in some situations, but I think it should be explained why to
 prefer broadcasting payment requests over picking them up via near field
 radio.




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

2015-02-05 Thread Eric Voskuil
Yes, a stellar device for mass surveillance coupled with transaction tainting.

e


 On Feb 5, 2015, at 1:19 PM, Brian Hoffman brianchoff...@gmail.com wrote:
 
 This sounds horrible. You could basically monitor anyone with a wallet in a 
 highly populated area and track them super easily by doing facial 
 recognition. Yes you could photograph people but it's way more burdensome. 
 Sorry to go off topic a little.
 
 
 On Feb 5, 2015, at 3:50 PM, Mike Hearn m...@plan99.net wrote:
 
 I'm imagining myself walking around broadcasting my photo and MAC
 address while hucksters push payment requests to me for approval
 
 I hate to break it to you, but you broadcast a photo of your face every time 
 you walk outside ;)
 
 Bluetooth MAC addresses are random, they aren't useful identifiers. If 
 someone can see you, a face is a far more uniquely identifying thing than a 
 MAC.
 
 Payment spam might be a problem. I can imagine a wallet requiring that 
 such requests are signed and then spammers can be blacklisted in the usual 
 fashion so they can't push things to your phone anymore. Anyway, a hurdle 
 that can be jumped if/when it becomes an issue.
 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
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

2015-02-05 Thread 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

2015-02-05 Thread 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 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.
 
 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

2015-02-05 Thread 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 p...@airbitz.co wrote:
 
 The broadcast is ONLY done when the wallet is in Receive mode. Same as when 
 the QR code is visible. The use of the *Name* section is specifically so that 
 a recipient can broadcast their name/handle. Not so the recipient would 
 broadcast the name of the Sender.
 
 On Thu, Feb 5, 2015 at 12:50 PM, Mike Hearn m...@plan99.net wrote:
 I'm imagining myself walking around broadcasting my photo and MAC
 address while hucksters push payment requests to me for approval
 
 I hate to break it to you, but you broadcast a photo of your face every time 
 you walk outside ;)
 
 Bluetooth MAC addresses are random, they aren't useful identifiers. If 
 someone can see you, a face is a far more uniquely identifying thing than a 
 MAC.
 
 Payment spam might be a problem. I can imagine a wallet requiring that 
 such requests are signed and then spammers can be blacklisted in the usual 
 fashion so they can't push things to your phone anymore. Anyway, a hurdle 
 that can be jumped if/when it becomes an issue.
 
--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-02-05 Thread 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 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 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 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.
 
 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

2015-02-05 Thread 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 p...@airbitz.co
 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 e...@voskuil.org
 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 m...@plan99.net
 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.

 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

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

2015-02-05 Thread 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

2015-02-05 Thread 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 e...@voskuil.org wrote:
 A MITM can receive the initial broadcast and then spoof it by jamming the
 original. You then only see one.

 You are right, of course. There is no way to make Bluetooth 100%
 secure, since it is an over-the-air technology. You could try securing
 it using a CA or other identity server, but now you've excluded ad-hoc
 person-to-person payments. Plus, you need an active internet
 connection to reach the CA.

 You can try using proximity as a substitute for identity, like
 requiring NFC to kick-start the connection, but at that point you
 might as well use QR codes.

 This BIP is not trying to provide absolute bullet-proof security,
 since that's impossible given the physical limitations of the
 Bluetooth technology. Instead, it's trying to provide the
 best-possible security given those constraints. In exchange for this,
 we get greatly enhanced usability in common scenarios.

 There are plenty of usable, real-world technologies with big security
 holes. Anybody with lock-picking experience will tell you this, but
 nobody is welding their front door shut. The ability to go in and out
 is worth the security risk.

 Bluetooth payments add a whole new dimension to real-world Bitcoin
 usability. Do we shut that down because it can't be made perfect, or
 do we do the best we can and move forward?

 -William

 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




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

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

2015-02-05 Thread 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 e...@voskuil.org:
 On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
 A BIP-70 signed payment request in the initial broadcast can resolve the
 integrity issues, but because of the public nature of the broadcast
 coupled with strong public identity, the privacy compromise is much
 worse. Now transactions are cryptographically tainted.

 This is also the problem with BIP-70 over the web. TLS and other
 security precautions aside, an interloper on the communication, desktop,
 datacenter, etc., can capture payment requests and strongly correlate
 transactions to identities in an automated manner. The payment request
 must be kept private between the parties, and that's hard to do.

 What about using encryption with forward secrecy? Merchant would
 generate signed request containing public ECDH part, buyer would send
 back transaction encrypted with ECDH and his public ECDH part. If
 receiving address/amount is meant to be private, use commit protocol
 (see ZRTP/RedPhone) and short authentication phrase (which is hard to
 spoof thanks to commit protocol - see RedPhone)?

 Hi Martin,

 The problem is that you need to verify the ownership of the public key.
 A MITM can substitute the key. If you don't have verifiable identity
 associated with the public key (PKI/WoT), you need a shared secret (such
 as a secret phrase). But the problem is then establishing that secret
 over a public channel.

 You can bootstrap a private session over the untrusted network using a
 trusted public key (PKI/WoT). But the presumption is that you are
 already doing this over the web (using TLS). That process is subject to
 attack at the CA. WoT is not subject to a CA attack, because it's
 decentralized. But it's also not sufficiently deployed for some scenarios.

 e




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

2015-02-05 Thread 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 change if the BIPs are formally
 adopted. You can find a copy of these proposed BIPs at the following
 links:

   

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

2015-02-05 Thread 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 e...@voskuil.org
 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

2015-02-05 Thread 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
e...@voskuil.org napísal:

 On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
 That's exactly what I though when seeing the RedPhone code, but after
 I studied the commit protocol I realized it's actually secure and
 convenient way to do it. You should do that too. :)
 
 I was analyzing the model as you described it to me. A formal analysis
 of the security model of a particular implementation, based on
 inference
from source code, is a bit beyond what I signed up for. But I'm
 perfectly willing to comment on your description of the model if you
 are
 willing to indulge me.
 
 Shortly, how it works:
 The initiator of the connection sends commit message containing the
 hash of his temporary public ECDH part, second party sends back their
 public ECDH part and then initiator sends his public ECDH part in
 open. All three messages are hashed together and the first two bytes
 are used to select two words from a shared dictionary which are
 displayed on the screen of both the initiator and the second party.
 
 The parties communicate those two words and verify they match.
 
 How do they compare words if they haven't yet established a secure
 channel?
 
 If an attacker wants to do MITM, he has a chance of choosing right
 public parts 1:65536. There is no way to brute-force it, since that
 would be noticed immediately. If instead of two words based on the
 first two bytes, four words from BIP39 wordlist were chosen, it would
 provide entropy of 44 bits which I believe should be enough even for
 paranoid people.

 How this would work in Bitcoin payment scenario: user's phone
 broadcasts his name, merchant inputs amount and selects the name from
 the list, commit message is sent (and then the remaining two
 messages), merchant spells four words he sees on the screen and buyer
 confirms transaction after verifying that words match.
 
 So the assumption is that there exists a secure (as in proximity-based)
 communication channel?
 
 e
 
 2015-02-06 0:46 GMT+01:00 Eric Voskuil e...@voskuil.org:
 On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
 A BIP-70 signed payment request in the initial broadcast can
 resolve the
 integrity issues, but because of the public nature of the
 broadcast
 coupled with strong public identity, the privacy compromise is
 much
 worse. Now transactions are cryptographically tainted.

 This is also the problem with BIP-70 over the web. TLS and other
 security precautions aside, an interloper on the communication,
 desktop,
 datacenter, etc., can capture payment requests and strongly
 correlate
 transactions to identities in an automated manner. The payment
 request
 must be kept private between the parties, and that's hard to do.

 What about using encryption with forward secrecy? Merchant would
 generate signed request containing public ECDH part, buyer would
 send
 back transaction encrypted with ECDH and his public ECDH part. If
 receiving address/amount is meant to be private, use commit
 protocol
 (see ZRTP/RedPhone) and short authentication phrase (which is hard
 to
 spoof thanks to commit protocol - see RedPhone)?

 Hi

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

2015-02-05 Thread 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] Subject: Re: Proposal to address Bitcoin malware

2015-02-03 Thread 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 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

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

2015-02-02 Thread Eric Voskuil
On Feb 2, 2015, at 11:53 AM, Mike Hearn m...@plan99.net 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 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?

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 

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

2015-02-02 Thread 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 brian.erde...@gmail.com
 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 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

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

2015-02-02 Thread 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] Proposal to address Bitcoin malware

2015-02-02 Thread 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 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?
 --
 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

2015-02-02 Thread 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 brian.erde...@gmail.com 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