Topic: "wallet" handling code should be a separate process. (Read 2081 times)

Agreed, we need to think of something like this.

This is what I tried to make clear in my bitcoin safe box thread ( https://www.bitcoin.org/smf/index.php?topic=1826.0 ) as well.

I would be scared shitless to have more than the equivalent $1000 available connected to the internet using a P2P daemon 24/7 It's like a 'hack me' bounty.

After all, that is the solution, that will allow correct usage of bitcoin in a multi-user environment.

UNIX systems, Windows terminal servers, thin clients, public hosting, ... ?

Right now, you need to patch bitcoin to bind to a different port and then
you still be required to store your own copy of blockchain and generate your
own traffic flow, identical among other users.

From a user's point of view it might look pretty trustworthy if funds-altering operations could be managed from an isolated system. Many people look sceptical towards the electronic money (especially in the countries where these technologies are new or uncommon). It would be a big COMPETATIVE ADVANTAGE of Bitcoin over other Internet banking systems if it could offer an ability to handle sensitive data (wallet's private keys) on a separate machine (say, isolated linux netbook, that has no network whatsoever). In this scenario transactions' requests and approved (signed) transactions are transferred to/from the isolated system via USB-flashdrive (which are about $5). It would be much easier to believe in the reliability of such isolated system than in reliablility of a wirewall (which many people are puzzled to build and maintain).
Hackers may be unhappy with this solution: it's impossible to hack a network if there is no network.
Of cause, it makes sence only when funds are high: one may not care about $10, but few are indifferent about $1000 and more. Thus Bitcoin could win in the high-end market.

I think it is WAY too early to nail all that down; bugs in that code caused changes just a few months ago.

Just write the code, and when core bitcoin changes, be prepared to change your code.  For the specific case we're talking about, you don't need to know all the possible ways scriptSig satisfies scriptPubKey-- you just need to reverse engineer how the standard send-to-bitcoin-address works so you can sign your own send-to-bitcoin-address transactions.

I agree completely.

In order to enable interoperability we need to have a sufficiently detailed specification of the scripting language, how mathematically scriptSig satisfies scriptPubKey and some commitment from Satoshi that he will "play nicely" with such efforts.

It would be annoying to have to reverse engineer everything and to fix it when the standard client changes the implementation. See Samba/Microsoft.

ByteCoin

The behind-the-firewall nodes will need the following from an on-the-network bitcoind:

1. They need to be able to ask it "tell me about any transactions to these bitcoin addresses..."
2. They need to be able to send it a signed transaction and ask "Please broadcast this for me."

Item 1 is implemented in my monitorreceived patch ( https://github.com/gavinandresen/bitcoin-git/tree/monitorreceived ).

Item 2 would be cool.  Anybody want to design and develop an "accept transaction" patch?

All the other functionality needed (like generating public/private keys, generating and signing transactions) could be, and should be, in my opinion, be done as a project separate from bitcoin.  Making the code small and self-contained and as secure as possible would be the goal; it could be re-used to create a type of lightweight client that ran on cell phones in addition to running behind corporate firewalls.

If you're a small company, just take the above example and pretend you're just a branch office.
Also, most multinationals don't write their own finance software so they won't "do it themselves".

ByteCoin

Anyone with those kinds of resources are going to want to do it themselves anyway.

If you're a multinational using Bitcoin for substantial payment and capital purposes you might have an architecture as follows:

You have several branch offices overseas and dedicated secure lines and failover satellite links running between each of these and your head office . Each branch office runs a Bitcoin node that accepts and relays transactions across the network and maintains a block chain. As these computers accept arbitrary data from arbitrary peers they are hard to secure they therefore have no ability to generate new transactions and certainly no wallet. They purely act as the company's connection to the bitcoin network. They are geographically and topologically separated to mitigate network fragmentation and to shorten the maximum propagation distance for any of company's transactions.

The branch offices also have a secure intranet that runs transaction generating software. This can show balances, make payments and everything a company branch wants to do with money. There are probably many terminals capable of creating new transactions. Each terminal signs any bitcoin transaction it wants to make and sends it to the gatekeeper nodes described below. They get their information from their internet-facing bitcoin node and possibly from the company's other bitcoin nodes over the secure lines.

Each branch might have a separate secure computer holding some private keys but only with relatively small balances suitable for branch operation. The public key holding computer would only accept suitably signed bitcoin messages. Access to this secure computer would be through a secure gatekeeper computer which would perform various sanity checks on the messages but would have no ability to sign them so, if compromised it would not be able to create bitcoin transactions.

Large transactions and most of the capital would be held at the head office secure computers. If the branch terminals wanted to generate a large transaction that the branch holdings can't satisfy then the signed transaction is sent to the secure gatekeeper node at head office.

If an internet-facing bitcoin node is compromised then the harm is small as there's no ability to generate transactions and no wallet.

If an attaker cracks the secure intranet or gets access to a terminal they can attempt to make transactions. Hopefully the gatekeeper sanity checking would minimise losses.

If the gatekeeper node is compromised then transaction approvals grind to a halt but as it can't generate signed transactions there are no further losses.

When I say "sign", "signs","signed" and "signature" above I just mean normal PKC not bitcoin signatures.

ByteCoin

But again:  if that clear interface includes a command to "send XYZ bitcoins to some address", then how is the separation making you more secure?

You must appreciate however that serious security flaws continue to be found and can be inferred to continue to exist in a wide variety of carefully written and carefully reviewed applications. 


Absolutely. I therefore think it's important to separate the transaction generating code from anything network-facing. My post was more of a display of the design techniques required to implement a secure system rather than a do-this-and-everything-is-fixed-forever solution.


Agreed. However, splitting the functionality across processes that communicate using a clear interface would allow wallet handling code to run on secure back-end machines without direct internet connections.

ByteCoin

First: I've reviewed Bitcoin's networking code looking specifically for possible buffer overflow vulnerabilities, and found none.  It is possible I missed something; please help review the code and let me or Satoshi know if you find anything suspicious.

Second: I don't think splitting the wallet handling code into a separate process will improve security at all.  If there is code that can send the nicely-compartmentalized wallet handling code a command "Send XYZ bitcoins to address 1ABC...", and that code has a buffer overflow vulnerability in it, then you are just as vulnerable as today.

If your PC has been compromised, then you are in trouble; anything you do on your machine may be intercepted by a bad guy.  Log into your bank account website-- the bad guy might hijack your session and transfer money out.  Start up bitcoin-- the bad guy might inject keyboard and mouse events to send coins out.

Even if Bitcoin implemented multi-factor authentication before allowing wallet access ("scan your fingerprint and enter your password to send coins"), if your PC is compromised a bad guy could arrange to modify the bitcoin address that you say you want to send coins to, so you think you're authenticating a payment to Wally's Discount Center but you really authenticate payment to Doctor Evil's Empire.

There is already, rpc method 'backupwallet'.

+ 1.

Also, there should be an easy way to make backup of the wallet, without having to shut down the client. Perhaps having wallet manager in separate process would simultaneously make that easier.


BTW,
Make a poll about this please.

Buffer overflow attacks against the current client could allow an unauthenticated remote attacker to steal your bitcoins.

I raised this topic in https://bitcointalksearch.org/topic/m.20574

The principal flaw of the current client in this respect is that it's a large monolithic process that accepts arbitrary data from arbitrary network connections and performs complex processing on them while having full access to small valuable private keys.
An attacker who could patch the client could ensure untraceable access to all future private keys (with some caveats).

The way to secure this application is by restricting the operations we allow to be performed on the private keys and by simplifying the code accessing the private keys.

The only operations that ever need to be performed on the list of private keys are "read key" and "add new random key". A malicious process that can read an arbitrary private key can spend the coins associated with that key. A malicious process that can add a new random key can only waste storage space. As an aside, a malicious process that can add an arbitrary private key can spend the coins assigned to that key in future, so we must forbid this. To help the enforcement of these rules, the file holding the keys could be opened with only read and append permissions.

The private key handling process would accept only two commands. "Sign message" would take a message and a public key and return the signature. "Add new key" would return the new public key.

A separate process could control access to the "sign message" interface of the public key handling process. This could perhaps check that the value of the messages signed was under a certain limit before requiring user confirmation. It could check that the rate of spending was not over a certain limit or that the total sent for that day was not excessive.

The private key handling process should not attempt to parse and check the messages it signs as it makes the code vastly larger and more difficult to prove secure.

ByteCoin