Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security risks with re-use of onion address #2005

Closed
qubenix opened this issue Nov 30, 2018 · 4 comments
Closed

Security risks with re-use of onion address #2005

qubenix opened this issue Nov 30, 2018 · 4 comments

Comments

@qubenix
Copy link

qubenix commented Nov 30, 2018

Some discussion here: http://bisq.community/t/why-re-use-onion-address/6670.

It's better for user privacy and security if onion addresses are not re-used (aka 'ephemeral'), and if Bisq does not know or store the private key for the onion address. This can be achieved with DiscardPK flag, and makes sense if Bisq is using the system's Tor or the bundled Tor.

In either situation the privkey is stored in ~/.local/share and readable to any other software run by the same user. This would solve that security issue when using the system's Tor, when using bundled Tor you should think about encryption for the privkey as mentioned in the forum post.

Creating a new onion address on each run is also better for user privacy against adversaries on the network, and probably for other reasons I'm not aware of. It is mentioned in the Tor friendly applications best practices doc to keep onion services ephemeral.

It was mentioned in the forum that the onion address is used as an identifier for reputation. This is concerning since the privkey is so easily readable. Compromise of the privkey could allow an attacker to mimic the onion address of the victim. I'm not sure what the complete implications are there with regards to Bisq and the reputation system.

It may make sense to come up with another identifier. For instance, lnd (I only use this example because it's another system I'm familiar with where the identifier is critical for use) is using a specific path from the wallets seed to derive the identity_pubkey.

@aejontargaryen
Copy link
Contributor

Very logical idea. Just riffing here, since onion address is also being used for reputation...if it were to be created anew each trade, it could work if another less detailed system could be used to only represent successful/unsuccessful trades. eg +5/-2 , +9/-0
Would require some work i'm sure, but you sound like you have a really great grasp on the area of expertise. I think its awesome.

@freimair
Copy link
Contributor

About the reputation: I think the onion address of the hidden service has been chosen because it is readily available and no further thought has been put on this. There is, however, a non-written plan to eventually use the private_key itself for identifying the user and her reputation (@ManfredKarrer) in order to support other networks as well (#1397). However, switching to the private_key makes no difference here as the onion-address is derived from the private_key.

In general, a reputation of some sort does require a unique identifier, there is no way around. And the reputation (to my knowledge) gives the Bisq users a tool to judge whether the trading partner is going to fulfill her part in a fast and correct way (very similar to, for example, PGPs trust network).

If a user wants to stay completely anonymous and therefore, no reputation data is available, she may have difficulties finding trading partners. Hence, if the user wants to stay anonymous, she has to accept that other people may not trust her.

Aside from that: Given, the private_key is stored somehow encrypted (AES, RSA, ...):

  • which key should be used to encrypt?
  • And more importantly, how can we store or derive such a key that an attacker, who has access to ~/.local/share, cannot reproduce the key?
  • and yes, there is passwords. However, to keep the private_key protected, we cannot allow "remember password" as we then would have to store the password on disk. Hence, the password has to be entered everytime from scratch. So if a user is concerned about her home directory getting attacked, he would have to accept this inconvenience (and probably store the password in a textfile on her desktop).

technical feasability

considering #1056 and its preparation work (#2009 ff.), we already have a solid base for the onion address being changed everytime Bisq is run. One hidden service per trade, however, remains a challenge...

all in all

  • we could add a switch to start Bisq in "use fresh onion-address"-mode.
    • via command line parameter: Make it a shortcut and you are set.
    • settings
  • we could add a password with all its trappy nature
  • so we can let the user decide, whether she wants privacy or convenience

@ManfredKarrer
Copy link
Contributor

@qubenix

If someone can read your data directory you are already in a pretty bad situation. Basic security assumptions in Bisq is that your system is not compomised on that level.

Your onion address cannot change if you have open offers, trades or disputes. For the reputation though we could and probably should use a seperate key pair to be more flexible and make it possible to renew the onion address without losing the reputation. But as @freimair mentioned reputation requires some sort of identity and that is usually in conflict with privacy. So you will not get both in a perfect way. But letting users choose what is more importent for them should be the way to go.

Consider also that the main focus of Bisq it on the Fiat exchange side and here the bank details reveal your real life identity so some extent to the other peer anyway. With that in mind trying to get perfect privacy on the network side does not give you much as an undercover agent could easily just do a trade with your and find out your identiy. For altcoins though there is more headroom for a high level of privacy. But also here you should consider the Bitcoin-blockchain (and - if not a cryptonote coin - the altcoin-blockchain) as the weak element where it is very easy to lose privay and for most users who are not very skilled and knwoledgeable very hard to get good privay (e.g. coin merge, block explorer lookup, bloom filters,...).

Atm we have many other high prio tasks to complete (new trade protocol, DAO, P2P network stability,...), so no dev resources to get into those rather sophisticated features. If you are a developer you are welcome to join and work on it.

@ManfredKarrer
Copy link
Contributor

That topis is handled here #1056 as well. So I will close that as duplicate, but feel free to continue discussion on the othere issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants