Topic: Is this security solution a good idea? Is it new? (Read 1563 times)

It's because it's essential to the goal of the project to allow the users to control their account actions (including withdrawing) without allowing the user to directly control the bitcoins they've deposited. This means the system needs two private keys for each account: one to authorize non-withdraw account actions, which the user must own; and another to authorize withdraws, which the user must not own.

It's similar to how a traditional bank must lock up the actual cash deposited, but allow users other means of controlling the funds. The setup allows the bank to offer services that cash alone is incapable of (like instant transfers to other users or debit card services), while still allowing the user to get the actual cash back at any time through an internal withdrawal process. It's true that the bank now technically has two points of vulnerability (identity theft and physical bank robberies), and I know that the bank's extra security is a part of the metaphor that doesn't apply to my project. However, even if the bank had security comparable a potential customer just handling the cash directly, the extra services offered by the bank may make it useful to certain customers.

Not that this doesn't achieve some level of security, but it's kind of backwards.  If this is secure, it's because the user properly secures their private key for signing commands, plus a little bit extra "confusion" factor induced by the obscurity of the setup.  But if you're going to secure that command-signing key well, why not just leave out server B entirely, and just secure the Bitcoin private key to use to sign transactions directly, instead of signing-comands-to-tell-some-other-system-to-sign-transactions?

If you're concerned about anonymity, you could still maintain server A and B and let server B find & broadcast the signed transaction for you from the hidden service.  But there's no reason to have server B keeping the private data.  In fact, what you posted here would be theoretically less secure, because if either the command-signing key or the hidden service Bitcoin private key is compromised, the coins are gone.  That means you have two distinct, single points of failure, which has the security of the weakest one.  You might as well limit to a single point of failure and secure that one point correctly.

Well, this gets into the design goal of the project, so I'll try to give you a summary. As I said earlier, someone's working on a better writeup of it (might be done within the week?), and we'll post it here when it's done.

The only reason server B will create a Bitcoin transaction is to accomodate a user's "withdraw" command. All other operations don't actually involve sending the coins anywhere, and are be done entirely on server A. The project is centered around using this setup to offer of the some perks of a server-based system (instant, cheap payment to another user, possibly with sub-satoshi denominations) while preserving many of the perks of Bitcoin (transparent, developer-friendly, open-source, verifiable), and adding memo functionality. The particular combination of characteristics found in this system lead to extremely intriguing development possibilities.

I just noticed an error in my original post, and now Wolf0 and cp1's responses make way more sense.

I said "Server B actually has the private keys to the users' accounts", but that's terribly misleading. The users are the only ones that have the private keys needed to sign commands and authorize actions on server A. What server B (and no one else) has, is the private key(s) that actually own any bitcoins that any user has deposited. So in order for a user to direct their Bitcoins, they send a command signed with their private key to server A, which is eventually scanned by server B. Server B then verifies that the command is legitimately signed by the user, signs a Bitcoin transaction using the keys that actually own the coins, and sends that signed transaction back to server A to broadcast.

Well, there are a few characteristics of the project that may mitigate this (although I am certainly not a Tor/security expert):

First, server B will be contacting server A and no one else (but maybe this is just as easy to snoop?).
Second, server B can query server A at random intervals, and can realistically wait anywhere from 10 minutes to an hour between queries.
Third, because the server is designed to be used by other programs, there will be a whole class of queries (some through Tor) that query server A in an "automated", or "regular" way. Knowing nothing else about server B, how would you begin to narrow down this large pool of candidates, each of which has their own interest in retaining privacy?
Fourth, it will be trivial to actually move server B as often as you want, or change server B's connection habits, since server A never needs to know where server B actually is or when it will act.


If an attacker can attain a user's private key, that's a failure of the user to remain secure, not a failure of the server. Neither server ever asks for the user's private key, so the only security risk here is the one inherent in any cryptography at all: how to protect your private key, when you (should) know very well that no one should have to ask for it.

By the way, thank you all for this discussion. It's putting me miles ahead of where I would be if I was stuck with searches and individual research.

Of course it is clear that you can't guarantee full anonymity under all circumstances (and Tor makes it usually pretty clear that it is "use at your own risk"), but it seems to me the protection (at least if done right) must be rather good.  I'm pretty sure that a lot of law enforcement agencies around the world would be happy to find out where Silkroad is operated, for instance.  (Or certain other sites hosted as hidden services.)  The fact that they haven't seems to me a clear indication that it isn't so easy.

Or do I miss something which makes Silkroad different?  (Apart from DPR obviously knowing what he's doing.)

If A doesn't know how to contact B, then yes, B can remain hidden.

You should bare in mind that Tor hidden services and just that i.e. hidden and not anonymous.

If you know what your doing (technically) and combine this knowledge with other factors, such as historical / real-time data, it is possible to work out exactly which IP (or Tor server) a hidden service is being operated from. Its not very easy, but it is possible to do it, hence hidden and not anonymous. Tor client users have better anonynimity than the hidden service operator in fact.

In less than 20 boot straps of Tor, using a highly edited config. it is fairly easy to determine (currently), with more than 90% accuracy, say which country a Tor hidden service is being run from, for example.

The rest of the work is done just by using a simple process of elimiination. That's all that is required.

Aside from that your described concept seems fairly sound.

As I'm currently imagining it, server A actually doesn't ever need to initiate communication with server B. I'm not sure about the specifics of how Tor operates, but wouldn't this mean that an attacker couldn't find server B, even if server A is compromised?

Each server needs to know how to reach the other.  Using tor, you can restrict what each side knows and harden that part, but you can't eliminate it entirely.

For example, if A and B only know each other by tor hidden service keys, then if an attacker gets into A, he will learn how to send messages to B, but he won't learn how to port scan, or whatever else he'd like.

Like Mike, I was thinking about a trust relationship between A and B.  If you don't need that, then yes, tor is excellent.

Running any sort of bitcoin service is like sticking a big sign on your server that says "Free money here!".  Even if you don't actually keep your wallet on that server, you will get more attention.  If you aren't sure of your security, or don't want the hassle, or both, then tor is a huge advantage in that you then really only need to harden one TCP port, while the rest of your server can fade into the billions of other random boxes on the internet.

In that case it sounds like an appropriate setup, yes.

How do the users sign the commands to send to server A if they don't have their own private key?

Well, this is all a proposed security setup for the Minisats project, which has a (very dry) summary here: https://bitcointalksearch.org/topic/introducing-minisats-a-transparent-bitcoin-nanopayment-processor-and-more-237042 (someone's working on a better writeup of it, which we plan to post here on the forum when it's done in a few days). It's a long read, so I'll try to summarize the relevant parts here:

The first reason that comes to mind is that the server is designed to be used by other programs, and (as far as I know) to require a developer to use Tor would significantly shrink the amount of people that could use it, and defeat much of the "ease-of-use" appeal of the project. Also, most commands sent by users will not involve Bitcoin transactions directly, and for these commands it's essential that there is as little lag as possible. There may be other reasons that aren't occurring to me, since I haven't actually directly considered your question before.

Basically, the front-end must be as easy as possible to find and access, but the portion that actually verifies and authorizes Bitcoin transactions must be as difficult to find as possible. Thus you have two servers: A transparent, fast, public server A, and a hidden server B.

Ah, sorry, I missed that your proposed backend doesn't actually accept commands from the frontend but rather, end users directly.

It leads me to wonder what the purpose of the server A is? Why doesn't the user just send the commands directly to server B via a Tor hidden service?

Would you mind explaining this a bit more? How would an attacker find the origin of a message sent from server B?


In my specific case, server B would be scanning server A for commands signed by specific users with their address. No matter how much an attacker compromised server A, they couldn't actually fake a signed command, and server B would verify the legitimacy of signed commands before doing anything.


What exactly makes this expensive--is it the risk analysis specifically? In my case, the risk analysis is as simple as checking to make sure the command is legitimately signed by the user before performing the action.

It's been discussed before, yes. Having a separate server perform risk analysis on commands from an untrusted frontend is one of those things that's obviously a good idea, but the actual costs of doing so are high enough that I never heard of anyone actually doing it. Once you have such an architecture, putting the backend behind a Tor hidden service is a simple way to improve security if you can tolerate the latency.

But that's not the biggest threat. The biggest threat is server A being compromised, and telling server B send coins to attacker's address.

I'm planning to run some services over TOR like this.

Keep in mind that neither server is really hidden from the other.

I'm curious about what you guys think about the following security setup:

Server A is publicly hosted at some domain name or ip address, and this server takes signed commands from Bitcoin users to perform various actions. Server B actually has the private keys that own any bitcoins the users have deposited, and nothing--not even server A--knows where server B is. When a user wants to perform an action that requires a Bitcoin transaction, server A posts this command publicly somewhere. Server B regularly checks for these commands, connecting through a Tor-like service to obscure where the query came from. When it sees that a Bitcoin transaction is required, it signs the transaction and sends the signed transaction to server A (again through a Tor-like service), and server A then broadcasts the transaction.

This basically allows a server to remain completely unfindable, since the only network actions it performs are outgoing and through Tor. If a server is unfindable, then the private keys can't be snatched.

Has this idea already been discussed? Am I missing an important detail that makes this less airtight than it seems?

[Edited to clarify some confusing wording]