Pages:
Author

Topic: The Most Important Bitcoin Client Feature IMHO... (Read 3632 times)

member
Activity: 308
Merit: 10
Yep, but its arranged in a situation where both survelliance each other.

So the DLL/SO survelliances that the EXE requesting API access is correctly signed and not modified, and that not critical parts are modified, and the EXE checks that the DLL/SO is not modified.

Also both the EXE and the DLL/SO can check itself in a way too.


If its too tough to make secure, you could have 2 identical DLL/SO, that survelliance each other.

How does the dll keep me from modifying it while it isn't running?

No matter how many complicated layers you add, I am still running code on your system. I can do whatever I want to circumvent those security layers because I am responsible for enforcing them in the first place.
full member
Activity: 129
Merit: 119
Yep, but its arranged in a situation where both survelliance each other.

So the DLL/SO survelliances that the EXE requesting API access is correctly signed and not modified, and that not critical parts are modified, and the EXE checks that the DLL/SO is not modified.

Also both the EXE and the DLL/SO can check itself in a way too.


If its too tough to make secure, you could have 2 identical DLL/SO, that survelliance each other.
member
Activity: 308
Merit: 10
The DLL/SO is then locked in a way so *nobody* can update it while bitcoin is running, and the file is signed and checked by the bitcoin client prior to loading. The bitcoin client and the DLL/SO should also have a function preventing the bitcoin coin from updating the DLL/SO althogheter, even if you could completely decide which code is in the EXE/executeable.


In this way, we can have secure auto-update of the bitcoin, WITHOUT any fear that the core rules might change because of a hacker attack. To prevent stealing of coins from users, we could have the proposed signature scheme.

So in other words, the developers can send out autoupdates regarding non critical parts in the client, but nobody, not even the developers, can send out updates that change the central rules in the bitcoin.

So the part of the program I can update is responsible for the locking of the part I shouldn't be able to?
staff
Activity: 4284
Merit: 8808
I strongly disagree. (on topic to another thread: does that make me an extremist?)
Automatic updating is merely yet another attack vector. I highly doubt it could be made secure. Is there any other money handling software that automatically updates?

Other projects with similar security requirements have been struggling with this too.

http://google-opensource.blogspot.com/2009/03/thandy-secure-update-for-tor.html

It's more subtle than you might initially expect. I advise against reinventing the wheel here.
full member
Activity: 129
Merit: 119
I think it would be better to divide the client in 2 parts:

For windows: A EXE and a DLL.
For linux: A executeable and a SO.

The DLL/SO file contains the core functions for bitcoin, like chains, rules, mining, packets sending and such.  The DLL/SO is *NOT* locked in regards in which scripts that can appear in transactions, but the core functions will never allow the bitcoin client to change its inflation rules.

The DLL/SO is then locked in a way so *nobody* can update it while bitcoin is running, and the file is signed and checked by the bitcoin client prior to loading. The bitcoin client and the DLL/SO should also have a function preventing the bitcoin coin from updating the DLL/SO althogheter, even if you could completely decide which code is in the EXE/executeable.


In this way, we can have secure auto-update of the bitcoin, WITHOUT any fear that the core rules might change because of a hacker attack. To prevent stealing of coins from users, we could have the proposed signature scheme.

So in other words, the developers can send out autoupdates regarding non critical parts in the client, but nobody, not even the developers, can send out updates that change the central rules in the bitcoin.
sr. member
Activity: 322
Merit: 251
I was just asking about this today.

I think the client should be GPG signed by multiple developers, and the Bitcoin client should tell you when there is a new update, but not automatically update. It should also provide a quick changelog textbox.
legendary
Activity: 980
Merit: 1020
Google Chrome auto-updates without user knowing, and while many would argue that's a privacy breach, etc. etc. blah blah blah, no one can argue that Chrome has most up-to-date installs from all browsers. And because Bitcoin handles money, in my opinion it SHOULD auto-update in this manner, because if (when) we discover a hole in the protocol/client, it can take ages before everybody updates to new version.
Of course it could be done in way that an experienced user could turn it off, and there also could be stable and dev channels, just like Chrome does.

Right...so:

1. Outdated clients are potential attack vector.

2. Somebody mimicking Gavin is also an attack vector.
administrator
Activity: 5222
Merit: 13032
Automatic updates make things way too centralized, IMO.

Gavin should have an alert key, though, and an alert should be issued for every new version.
hero member
Activity: 607
Merit: 500
Google Chrome auto-updates without user knowing, and while many would argue that's a privacy breach, etc. etc. blah blah blah, no one can argue that Chrome has most up-to-date installs from all browsers. And because Bitcoin handles money, in my opinion it SHOULD auto-update in this manner, because if (when) we discover a hole in the protocol/client, it can take ages before everybody updates to new version.
Of course it could be done in way that an experienced user could turn it off, and there also could be stable and dev channels, just like Chrome does.
sr. member
Activity: 294
Merit: 252
Well, I am not opposed to an automatic update system as long as all of the current developers agree that there aren't any security concerns, it is optional, and the user is prompted to update.
hero member
Activity: 755
Merit: 515
I responded before I saw your post. Do you have details on the implementation you describe?
Current build instructions are at https://gist.github.com/806265.  The download/install/etc script is still a WIP, but you'd have to ask devrandom for more details on that.  Current signed copy of 0.3.21 is available on request (signatures in bitcoin-release repository of devrandom on github).
staff
Activity: 4270
Merit: 1209
I support freedom of choice
Anyway, every p2p network works better if it has every clients updated Wink
hero member
Activity: 812
Merit: 1022
No Maps for These Territories
I don't agree. The agency managing the automatic updates can instantly transform the network into whatever they want. They would be pretty much like the Fed.
sr. member
Activity: 280
Merit: 252
What if tomorrow the value of BTC jumped up to $100,000 USD/BTC and Gavin decided he now wanted to "round" every transaction down and send the remainder to his own account (like the plot from "office space").

OK, but the transaction record is public. That hack would make for some interesting reading on blockexplorer.com.


Sure, but the damage would have already been done.

One could (in theory, if (s)he were in charge of releases)...

1) Round up (or even direct the entire transaction amount) to his/her bitcoin address.
2) Sell as many bitcoins as they possibly could on any/every market within 24 hours.
3) (OPTIONAL) DDOS the bitcoin.org forums for another few days until their payments came through.

As of right now, that person could probably steal a few hundred thousand USD.

In the not too distant future, that person could feasibly steal millions of dollars, in less than a day... I regrettably imagine that there are already some people with similar plans.
member
Activity: 73
Merit: 10
What if tomorrow the value of BTC jumped up to $100,000 USD/BTC and Gavin decided he now wanted to "round" every transaction down and send the remainder to his own account (like the plot from "office space").

OK, but the transaction record is public. That hack would make for some interesting reading on blockexplorer.com.
sr. member
Activity: 280
Merit: 252
I just thought of a potential problem the open sourced bitcoin community might face...

How many people currently have to "ok" a release?

What if tomorrow the value of BTC jumped up to $100,000 USD/BTC and Gavin decided he now wanted to "round" every transaction down and send the remainder to his own account (like the plot from "office space").

No offense to Gavin, but most everybody has their price.  Undecided
sr. member
Activity: 294
Merit: 252
Automatic updating is merely yet another attack vector. I highly doubt it could be made secure. Is there any other money handling software that automatically updates?
How could you exploit a system which requires developers to sign the results with gpg?  You'd have to steal the gpg keys of multiple developers.

I responded before I saw your post. Do you have details on the implementation you describe?
staff
Activity: 4270
Merit: 1209
I support freedom of choice
hero member
Activity: 755
Merit: 515
apt-get
Have fun getting that to work while we are still on wx 2.9.  Plus the recommended package will be the downloaded which checks trust on binaries before they are distributed (instead of the bitcoin binary itself).
legendary
Activity: 1232
Merit: 1076
apt-get
Pages:
Jump to: