Electrum security model concerns

I'm concerned about how the particular security model of electrum is being described; or rather— not being described. The electrum website appears to have no security discussion beyond platitudes like "Secure: Your private keys are not shared with the server. You do not have to trust the server with your money.", "No scripts: Electrum does not download any script at runtime. A compromised server cannot compromise your client."

Claims like "You do not have to trust the server with your money" are factually incorrect.

What I would expect is a proper discussion, like "Understanding the bitcoinj security model": http://code.google.com/p/bitcoinj/wiki/SecurityModel (which I don't agree with completely— as it makes some claims which are known to be false— wrt detecting double spends, but it does give a reasonable overview), and avoidance of broad claims which will result in misunderstandings that result in users engaging in riskier behaviors which they could avoid if they better understood the security of the software they're running.

> What I would expect is a proper discussion, like "Understanding the
> bitcoinj security model":
> http://code.google.com/p/bitcoinj/wiki/SecurityModel

That page was old, it stated that pending transactions aren't provided to the app which hasn't been true for a long time.

I've rewritten and extended it. You may still not like what it says ;) but it should at least be more thorough now. It also links to the ETH paper.

Re: Electrum. In fairness the electrum page is designed for end users and the bitcoinj page is designed for app developers. As far as I know, there are no bitcoinj based clients that try to explain transaction confidence to end users.

I don't think it's worth worrying about this too much right now. In future the software end users and merchants use will diverge significantly. At that time it'll be easier to tailor the documentation to each user demographic. And I think Electrum type services will go away once we do more optimizations like bloom filtering and better peer selection logic, as the speed of SPV clients will be comparable to Electrum/BCCAPI type clients but without the need for a specific server operator.

On Mon, Oct 8, 2012 at 7:52 AM, Mike Hearn <mike@plan99•net> wrote:

> I don't think it's worth worrying about this too much right now. In
> future the software end users and merchants use will diverge
> significantly.

Electrum also has a daemon for merchants. Considering the dislike of Java that exist reflexively in much of the non-java community and the greater ease of deployment and the integration of type-2 split key management, I wouldn't be surprised if it became quite popular quickly especially if the status quo of failing to disclose and discuss the security limitations of the client continues.

What I've found is that even fairly sophisticated bitcoin participants are actually unaware of the security implications— not just of thin clients architecturally but of electrum specifically. I think even you may find my findings of the latter a bit surprising.

Generally for thin clients— a lying server can make clients think they've received confirmed payments they haven't, and unless the client is constructed to be a bit less thin a lying server can lie about input values and cause think clients to spend large values to fees. Servers can also monitor clients and deanonymize them and selectively deny service to particular clients or transactions. Thin clients must trust their servers to be available, and to not perform these attacks. Users can use tools like tor to reduce the privacy attacks, but doing so inhibits having a trust relationship to protect against the other attacks. And none of these attacks leave cryptographic proof of their existence, so a victim can't convince the public of a server's treachery. Us experts know about these risks, but I don't think the general users do.

But thats not the limit of it— It seems some people believe Electrum does majority quorum between servers, complicating attacks arising from the fact that today users virtually never have a reason to trust their server operators. This isn't true— it connect to one at a time. (And sibyl attacks would make that pretty weak protection even if it did that, as someone could use a a botnet to run tens of thousands of 'servers' (really proxies)).

Beyond that the protocol between the clients and servers is unauthenticated cleartext JSON in TCP. So any network advisory with access to the network near the server has the same power to attack as the server operator... and one near the client has the same power to attack as the sum of all the server operators. A passive attacker near the client has full deanonymization power.

But I don't even know if any of these limitations matter much— The electrum client instantly displays unconfirmed transactions and allows users to spend them. The default user interface gives _no_ indication that the payment is unconfirmed. There is a "pro" mode, that shows 'processing' for unconfirmed transactions... but it looks as final as it ever will be once it gets a single confirm. Only the most cautious and well informed users would open the pro interface and right click and select details to see the count— and even then there is no guidance on what numbers are good (beyond '1'). So I suspect people can probably rob typical electrum users (including electrum running merchants) without actually using any of the above.

When a thin client is willing to provide arbitrary features like showing unconfirmed payments and simplified UI without regard to security it removes the functional advantage of running more secure software like SPV and various degrees of full node... the only motivation is security, and it's not much of a motivation when the risks aren't even disclosed.

...and I haven't even gotten into delving into what kind of attacks are possible due to deeper implementation specifics.

But I do share your view that people will migrate to stronger client models in the future— but I don't agree that it will be due to those clients improving (though they will improve), it will be because people will know that they provide better security and will choose them for that reason.

My only question is will they know this because we as a community and the authors of the thin clients provided clear explanations and appropriate caution, or will it be because they're getting robbed blind, producing a bunch of bad press for thin clients in particular and Bitcoin generally?

+gary

> Electrum also has a daemon for merchants.

Well, I suggest taking it up with Thomas directly. A thread here won't do much.

> Considering the dislike of
> Java that exist reflexively in much of the non-java community and the
> greater ease of deployment and the integration of type-2 split key
> management

I'm hoping that MultiBit Merchant will provide something similar based on bcj, ie, you don't have to actually be a Java developer to use it, it can just talk to your app via POSTs and GETs.

WRT deterministic wallets, yes, right now that's indeed a competitive advantage of Electrum. So much code to write, so little time.

> Generally for thin clients— a lying server can make clients think
> they've received confirmed payments they haven't, and unless the
> client is constructed to be a bit less thin a lying server can lie
> about input values and cause thin clients to spend large values to
> fees.

Yes indeed. This also gives [hacked] server operators a way to steal money from users without private keys, they can get clients to create some very high fee transactions and then provide them directly to a miner who promises to cut them in (or they can mine themselves, of course).

> Beyond that the protocol between the clients and servers is
> unauthenticated cleartext JSON in TCP.

I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar approach.

> that the payment is unconfirmed. There is a "pro" mode, that shows
> 'processing' for unconfirmed transactions

I think communicating transaction confidence to users is something of an open UI design problem right now. I agree that hiding it entirely seems suboptimal, but in reality explaining what the risks are for a given number confirmations is difficult. Given the lack of actually reported double-spends against unconfirmed transactions, I can understand this choice, even if I wouldn't recommend it.

> My only question is will they know this because we as a community and
> the authors of the thin clients provided clear explanations and
> appropriate caution

Well, I pushed for English-text explanations of clients on bitcoin.org rather than a feature matrix, for this kind of reason :) Unfortunately the current texts are too small to really give a detailed explanation of the security models involved. It may be worth adding one-liners that link to a page explaining different security models (full, SPV, superlight).

One thing I'm really hoping we can find and get agreement on is somebody clueful and trustworthy to work on the bitcoin.org website. Bitcoin, the project, needs a stronger voice than it currently has, partly to speak about such issues. For instance, an FAQ that isn't on the wiki would be good. And a simple "Welcome to Bitcoin" flow on the bitcoin.org website that guides people to appropriate clients, teaches them the security basics, etc, would be excellent.

Just to chime in on the MultiBit Merchant aspect. The architecture is that MBM is a Java backend, but executes as a simple command line:

java -jar mbm.jar server config.yml

As Mike expects, MBM offers a RESTful API using HAL+JSON. It provides a comprehensive set of order and invoice processing, accounting, inventory/delivery management and customer account handling facilities for use with a wide variety of online business models.

There will be a variety of front ends, one of which is an online shop. They also have the same startup command structure.

Since most folks are shy of using any technology, it is likely that MBM+<x client> will be offered as part of a SaaS type solution. This allows anyone who doesn't have the knowledge to configure it for themselves to make use of it.

MBM will use BitcoinJ and will depend on a bucket of public keys for transactions until the HD support is in place to allow generation of public keys without private keys being present. This removes the need for private keys to be present on the servers, and allows consumers of the SaaS model to provide their own transaction keys.

The code is released under MIT license so anyone, anywhere can use it to build the Bitcoin economy.

More info: https://github.com/gary-rowe/MultiBitMerchant/wiki/Introduction http://gary-rowe.com/agilestack/2012/06/06/multibit-merchant-genesis/

On 10 October 2012 12:19, Mike Hearn <mike@plan99•net> wrote:

> +gary
>
> > Electrum also has a daemon for merchants.
>
> Well, I suggest taking it up with Thomas directly. A thread here won't do
> much.
>
> > Considering the dislike of
> > Java that exist reflexively in much of the non-java community and the
> > greater ease of deployment and the integration of type-2 split key
> > management
>
> I'm hoping that MultiBit Merchant will provide something similar based
> on bcj, ie, you don't have to actually be a Java developer to use it,
> it can just talk to your app via POSTs and GETs.
>
> WRT deterministic wallets, yes, right now that's indeed a competitive
> advantage of Electrum. So much code to write, so little time.
>
> > Generally for thin clients— a lying server can make clients think
> > they've received confirmed payments they haven't, and unless the
> > client is constructed to be a bit less thin a lying server can lie
> > about input values and cause thin clients to spend large values to
> > fees.
>
> Yes indeed. This also gives [hacked] server operators a way to steal
> money from users without private keys, they can get clients to create
> some very high fee transactions and then provide them directly to a
> miner who promises to cut them in (or they can mine themselves, of
> course).
>
> > Beyond that the protocol between the clients and servers is
> > unauthenticated cleartext JSON in TCP.
>
> I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar
> approach.
>
> > that the payment is unconfirmed. There is a "pro" mode, that shows
> > 'processing' for unconfirmed transactions
>
> I think communicating transaction confidence to users is something of
> an open UI design problem right now. I agree that hiding it entirely
> seems suboptimal, but in reality explaining what the risks are for a
> given number confirmations is difficult. Given the lack of actually
> reported double-spends against unconfirmed transactions, I can
> understand this choice, even if I wouldn't recommend it.
>
> > My only question is will they know this because we as a community and
> > the authors of the thin clients provided clear explanations and
> > appropriate caution
>
> Well, I pushed for English-text explanations of clients on bitcoin.org
> rather than a feature matrix, for this kind of reason :) Unfortunately
> the current texts are too small to really give a detailed explanation
> of the security models involved. It may be worth adding one-liners
> that link to a page explaining different security models (full, SPV,
> superlight).
>
> One thing I'm really hoping we can find and get agreement on is
> somebody clueful and trustworthy to work on the bitcoin.org website.
> Bitcoin, the project, needs a stronger voice than it currently has,
> partly to speak about such issues. For instance, an FAQ that isn't on
> the wiki would be good. And a simple "Welcome to Bitcoin" flow on the
> bitcoin.org website that guides people to appropriate clients, teaches
> them the security basics, etc, would be excellent.
>

On Wed, Oct 10, 2012 at 7:19 AM, Mike Hearn <mike@plan99•net> wrote:

> +gary
>
>> Electrum also has a daemon for merchants.
>
> Well, I suggest taking it up with Thomas directly. A thread here won't do much.

I tried in IRC and got no response. These messages are copying the only contact email address I could find.

> I thought it used SSL. Maybe I'm thinking of BCCAPI which is a similar approach.

Yes, so do a lot of people. It doesn't.

> I think communicating transaction confidence to users is something of
> an open UI design problem right now. I agree that hiding it entirely
> seems suboptimal, but in reality explaining what the risks are for a

There is a middle ground: You can not hide it without explaining it. AFAICT we don't see ~any questions about the reference client waiting for six confirmations before saying confirmed.

> given number confirmations is difficult. Given the lack of actually
> reported double-spends against unconfirmed transactions, I can
> understand this choice, even if I wouldn't recommend it.

There have been a great many circulated on the network. People don't report all losses— e.g. we've never seen a report from those who've burned hundreds of bitcoins in fees on transactions.

> of the security models involved. It may be worth adding one-liners
> that link to a page explaining different security models (full, SPV,
> superlight).

Perhaps.

> One thing I'm really hoping we can find and get agreement on is
> somebody clueful and trustworthy to work on the bitcoin.org website.

I think this is very hard because this matter is rapidly politicized. There are some in the community who will instantly allege misconduct when there is a mis-agreement.

Basically: No one sane should want the job, and anyone who wants should on no account be allowed to have it.

At this point I think we also will get better results communicating among technical people in order to get the development focus adjusted in a way that mitigates those risks that can be mitigated and those cautions that can be offered offered.

After all, if the Electrum project is _unwilling_ to disclose the limitations of their implementation and security model on their own site, even after having them pointed out then someone updating Bitcoin.org to include them will be politically contentious. I want to make sure that we've followed all reasonable avenues before going that route— first I attempted informally on IRC, now I've brought the discussion here... instead of, e.g. starting the process to remove it from the bitcoin.org clients page.

> Bitcoin, the project, needs a stronger voice than it currently has,
> partly to speak about such issues. For instance, an FAQ that isn't on

I agree, thats why I started this thread.

> I tried in IRC and got no response. These messages are copying the
> only contact email address I could find.

Forum private message may work better.

> I think this is very hard because this matter is rapidly politicized.
> There are some in the community who will instantly allege misconduct
> when there is a mis-agreement.

Yeah, but that's only an issue if it ends up being an intractable disagreement between the people who are reviewing changes to the core site. The clients page itself was contentious but we still arrived at something reasonably professional looking and moved on.

> discussion here... instead of, e.g. starting the process to remove it
> from the bitcoin.org clients page.

I don't think it should be removed. At most the description should be updated to point to a discussion of the tradeoffs of that class of apps (same for BitcoinSpinner).

On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:

> I'm concerned about how the particular security model of electrum is
> being described; or rather— not being described.

Just to close the loop on this: I finally got in touch with Thomas on IRC and walked over the security issues I brought up here, plus a number of other ones.

He took the concerns seriously and rapidly redesigned big swaths of electrum to eliminate the issues structurally. Electrum no longer a classical thin client it is now a slightly watered down simplified-payment-validation node with generally the same security properties as other SPV nodes. Its network behavior leaves it somewhat more vulnerable to isolation and compromise by a high hash power attacker, because it does not (yet) make an effort to make sure it's really on the longest chain. It is also more vulnerable to transaction hiding (a DOS attack) for similar reasons. But this is still a massive improvement. The UI was also changed and the confirmation status of payments is no longer hidden.

There are still things to improve— both in the client and the security communication to users. But I wanted to leave a note that it's come a long way and that I now feel confident that any remaining issues will be resolved.

Great to hear that.

BTW have you checked the code? I took a quick look and didn't see things I was expecting to see. In particular I couldn't find any code that manages wallet state in the presence of re-orgs. It appears to check that transactions appeared in the block chain, but if there's a chain switch it's not clear to me the wallet will be in the right state.

I saw a message from Thomas on his thread saying something like "can't spend coins bug happens when there's a re-org and the server gives you the wrong histories, to fix it reset your wallet and switch to a new server" .... which to me rather implies there's no re-org handling at all.

If Electrum does end up doing all SPV work correctly, how is it different to MultiBit? Just the deterministic wallet seeding?

On Fri, Nov 16, 2012 at 4:59 PM, Mike Hearn <mike@plan99•net> wrote:

> Great to hear that.