[Bitcoin-development] Electrum security model concerns

[Bitcoin-development] Electrum security model concerns

[Gregory Maxwell]

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.

Re: [Bitcoin-development] Electrum security model concerns

[Mike Hearn]

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

Re: [Bitcoin-development] Electrum security model concerns

[Gregory Maxwell]

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?

Re: [Bitcoin-development] Electrum security model concerns

[Mike Hearn]

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

Re: [Bitcoin-development] Electrum security model concerns

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5667 bytes --]

Re: [Bitcoin-development] Electrum security model concerns

[Gregory Maxwell]

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.

Re: [Bitcoin-development] Electrum security model concerns

[Mike Hearn]

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

Re: [Bitcoin-development] Electrum security model concerns

[Gregory Maxwell]

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.

Re: [Bitcoin-development] Electrum security model concerns

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

Great to hear that.

[-- Attachment #2: Type: text/html, Size: 20 bytes --]

Re: [Bitcoin-development] Electrum security model concerns

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1218 bytes --]