Pages:
Author

Topic: Breaking Mixing Services (Read 1874 times)

legendary
Activity: 2968
Merit: 3684
Join the world-leading crypto sportsbook NOW!
March 21, 2019, 11:38:46 AM
#29
Hi madu, thanks again for giving us the time and patience to work out an article on your thesis and findings. It's published now as a feature here and I'm glad to see it's also mentioned on Wasabi Wallet's succinct article on centralised mixing services.

Like others, though, I'm still keen to see if your same techniques would have worked for ChipMixer. I believe it's been one of the few centralised mixers to have innovated on the techniques. Any success breaking it would prompt even more innovations (in fact, happy to provide test samples if you need!).
copper member
Activity: 11
Merit: 325
March 16, 2019, 10:12:45 AM
#28
Finally i have free time to read your thesis. My comment, thoughts & question :
1. On 1 - Introduction. You forget to mention 2 proposals (which published before date before of your thesis) which aim to improve anonymity which are BIP 151 and 156, even though it's not anonymization by modify transaction.
2. Upcoming bitcoin proposal, Schnorr MuSig could improve privacy on transaction with multiple input, you might be interested.
3. On 2.3 Privacy in Bitcoin. You should take not that :
  • Few wallet such as Electrum now randomize output order
  • Few wallet have multiple change address feature
  • Few wallet such as Samourai wallet have advance transaction generation to improve user's privacy. It's called Stonewall
4. Your attempt to de-anonymize coinmixer.se is great, especially distinguish customer/coinmixer address by "Following transaction fulfills fee indicator", "Received an uncommon value" and "Tx fee based on partitions correct"
5. Why did you use blockchain.info rather than use Bitcoin Core RPC-JSON?

More info :
1. BIP 151 : Peer-to-Peer Communication Encryption
2. BIP 156 : Dandelion - Privacy Enhancing Routing
3. Dandelion: Redesigning the Bitcoin Network for Anonymity
4. Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees
5. MuSig: Schnorr Multisig and signature aggregation
5. Samourai Wallet : Stonewall
Thanks for your feedback and remarks.
5) Bitcoin qt was my first choice, however I didnt have much time for coding and blockchain.info had some speed and filtering advantages. So I talked to my supervisor and decided to use blockchain.info api. However, if I would implement this in a more serious fashion, I definitely would only use original bitcoin data to be sure of their integrity.

chipmixer.wrong
Although I think .io is owned by ChipMixer too, .com is the official domain: Please use the correct URL in all your posts:
USE ONLY BELOW DOMAINS:
ChipMixer.com
ChipMixerwzxtzbw.onion
Thank you. Its updated.

For everyone who is interested in Bitcoin privacy:
Recently the bitcoin.it privacy page (https://en.bitcoin.it/wiki/Privacy) has been updated by Chris Belcher (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016698.html).



legendary
Activity: 3430
Merit: 3080
March 13, 2019, 01:24:26 PM
#27
OP's thesis describe sybil attack, so IMO it's worth to mention those BIP which have few/some correlation.

You're right, I don't know how I skipped over that


I've seen some sources (including it's paper and Core's developer commentary) mention MuSig improve privacy since outsider can verify signature validity without see used public key.

Do i interpret it wrong or they're talking privacy on different aspect?

I see your point: multi-sig using Musig looks like a 1 input transaction when spending from a Musig address, regardless of how many signers are needed to pass the threshold. But the way I understand it, it's Schnorr's additive keys property that confers that quality, and not Musig per se.

Certainly, Musig is designed at least in part to prevent the attack I described in my previous post, an attack which is a consequence of using additive public keys to generate the public key for a multisig address. So it seems logical that it's Schnorr that's improving multisig privacy, and Musig that mitigates the risks of using Schnorr signing for a multisig address.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
March 13, 2019, 12:39:59 PM
#26
Finally i have free time to read your thesis. My comment, thoughts & question :
1. On 1 - Introduction. You forget to mention 2 proposals (which published before date before of your thesis) which aim to improve anonymity which are BIP 151 and 156, even though it's not anonymization by modify transaction.
Remember that these are confined to the network layer of Bitcoin:

1. With BIP156, your IP address will no longer be tied to your personal transactions from the perspective of connected Bitcoin nodes.
2. With BIP151, all relayed transaction data will be encrypted from the perspective of someone analysing internet traffic (but connected Bitcoin nodes will still see the transactions unencrypted).


Neither of those BIPs will change the ability to analyse transactions on the blockchain

OP's thesis describe sybil attack, so IMO it's worth to mention those BIP which have few/some correlation.

2. Upcoming bitcoin proposal, Schnorr MuSig could improve privacy on transaction with multiple input, you might be interested.
No, Musig Schnorr makes using multiple inputs less expensive. This only incentivises coinjoins, it does not make them any more private.

edit: Musig is for threshold based multisig that is safe to use with signature aggregation (without Musig, the last person adding their sig to an n of n aggregated public key could cheat by throwing out all the previous keys and replacing them with 1 key that belongs to them, and pretend that all the previous people's keys are aggregated together into it, so they can steal everyone's money). And so Musig doesn't have anything to do with privacy or anonymity on the blockchain either

I've seen some sources (including it's paper and Core's developer commentary) mention MuSig improve privacy since outsider can verify signature validity without see used public key.

Do i interpret it wrong or they're talking privacy on different aspect?
legendary
Activity: 3318
Merit: 4606
diamond-handed zealot
March 13, 2019, 09:56:25 AM
#25
Yeah, I always suspected that these mixing services wouldn't stand up to a concerted traffic analysis.

Top notch work, I bet some folks are sweating a bit right now...these tracks never fade.
member
Activity: 103
Merit: 327
March 13, 2019, 07:30:05 AM
#24
Thank you for the reply Felix! I added your thesis to my article on Traditional Bitcoin mixers: https://medium.com/@nopara73/traditional-bitcoin-mixers-6a092e59d8c2

I've been long theoretizing this happening, but I never found a concrete example of anyone doing this.
legendary
Activity: 3430
Merit: 3080
March 13, 2019, 04:58:27 AM
#23
Finally i have free time to read your thesis. My comment, thoughts & question :
1. On 1 - Introduction. You forget to mention 2 proposals (which published before date before of your thesis) which aim to improve anonymity which are BIP 151 and 156, even though it's not anonymization by modify transaction.

Remember that these are confined to the network layer of Bitcoin:

1. With BIP156, your IP address will no longer be tied to your personal transactions from the perspective of connected Bitcoin nodes.
2. With BIP151, all relayed transaction data will be encrypted from the perspective of someone analysing internet traffic (but connected Bitcoin nodes will still see the transactions unencrypted).


Neither of those BIPs will change the ability to analyse transactions on the blockchain


2. Upcoming bitcoin proposal, Schnorr MuSig could improve privacy on transaction with multiple input, you might be interested.

No, Musig Schnorr makes using multiple inputs less expensive. This only incentivises coinjoins, it does not make them any more private.

edit: Musig is for threshold based multisig that is safe to use with signature aggregation (without Musig, the last person adding their sig to an n of n aggregated public key could cheat by throwing out all the previous keys and replacing them with 1 key that belongs to them, and pretend that all the previous people's keys are aggregated together into it, so they can steal everyone's money). And so Musig doesn't have anything to do with privacy or anonymity on the blockchain either
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
March 13, 2019, 04:03:28 AM
#22
chipmixer.wrong
Although I think .io is owned by ChipMixer too, .com is the official domain: Please use the correct URL in all your posts:
USE ONLY BELOW DOMAINS:
ChipMixer.com
ChipMixerwzxtzbw.onion
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
March 13, 2019, 12:41:13 AM
#21

3. On 2.3 Privacy in Bitcoin. You should take not that :
  • Few wallet such as Electrum now randomize output order
  • Few wallet have multiple change address feature
  • Few wallet such as Samourai wallet have advance transaction generation to improve user's privacy. It's called Stonewall

None of these have any impact on privacy if users of Bitcoin are not using these features. When he wrote his paper, transaction fees were >$20, and using multiple change addresses would be very expensive for a business that processes many transactions. The same is true if a business generates transaction inputs in not the most efficient way.

Above all, the most effective way to maximize privacy when using Bitcoin is to abstain from address reuse, and to only conduct business with those who abstain from address reuse. This would be very effective in making "mixers" obsolete, and unnecessary in most cases.
legendary
Activity: 2870
Merit: 7490
Crypto Swap Exchange
March 13, 2019, 12:22:28 AM
#20
Finally i have free time to read your thesis. My comment, thoughts & question :
1. On 1 - Introduction. You forget to mention 2 proposals (which published before date before of your thesis) which aim to improve anonymity which are BIP 151 and 156, even though it's not anonymization by modify transaction.
2. Upcoming bitcoin proposal, Schnorr MuSig could improve privacy on transaction with multiple input, you might be interested.
3. On 2.3 Privacy in Bitcoin. You should take not that :
  • Few wallet such as Electrum now randomize output order
  • Few wallet have multiple change address feature
  • Few wallet such as Samourai wallet have advance transaction generation to improve user's privacy. It's called Stonewall
4. Your attempt to de-anonymize coinmixer.se is great, especially distinguish customer/coinmixer address by "Following transaction fulfills fee indicator", "Received an uncommon value" and "Tx fee based on partitions correct"
5. Why did you use blockchain.info rather than use Bitcoin Core RPC-JSON?

More info :
1. BIP 151 : Peer-to-Peer Communication Encryption
2. BIP 156 : Dandelion - Privacy Enhancing Routing
3. Dandelion: Redesigning the Bitcoin Network for Anonymity
4. Dandelion++: Lightweight Cryptocurrency Networking with Formal Anonymity Guarantees
5. MuSig: Schnorr Multisig and signature aggregation
5. Samourai Wallet : Stonewall
copper member
Activity: 1652
Merit: 1901
Amazon Prime Member #7
March 12, 2019, 04:58:44 PM
#19
It looks like a major problem with coinmixer.se is their transactions all had multiple unique variables. If a mixing service were to use multiple node/wallet implementations to create and sign transactions, and use randomized values for the variables you found to always be constant with coinmixer.se transactions, it might be more difficult to determine their "network", or would have a less degree of certainty as to which transactions are part of their network.

An attacker using their service is ultimately a massive, unavoidable data leak. Your 20 "test transactions" during that week, accounted for more than 1% of their weekly transactions.

When bitmixer closed, they made a very interesting comment:
When we started this service I was convinced that any Bitcoin user has a natural right to privacy. I was totally wrong. Now I grasped that Bitcoin is transparent non-anonymous system by design.
This appears to imply they believe similar research was done successfully on their mixing service, and did not want to give their customers a false sense of securityprivacy.
copper member
Activity: 11
Merit: 325
March 12, 2019, 09:25:42 AM
#18
It is terribly chatty for me. I'd like to check if my quick glance takeaways are correct:

1. First you identify a traditional mixing service's transactions.
2. Then you mess around with the possible timeframes for the mixes.
3. Finally you do a subset-sum analysis. (Amount based analysis of mixing inputs and outputs.)

Thus you get most of the links between incoming and outgoing transactions, except those that happen to be equal within the appropriate mixing window.

Is this a fair way to describe what you did?

Yes, you could define it like that. But generally speaking there are only two big steps:
1) Identify mixing service transactions within blockchain data
2) Find an algorithm to connect input transactions to output transactions

The method of solving each steps is based on the implementation of the mixing service.
In case of coinmixer.se the first step could be solved by analyzing transaction data and the second step could be solved by analyzing the transaction flow and transaction data.
In case of bitmixer.io both steps could be solved by analyzing transaction data - no transaction flow is needed here.

I'm curious if this methods would work with CoinJoin transactions, particularly with those wallets were there aren't many users (I guess that means all).
There is a lot of interest in this topic. I will definitely also look into decentralized mixing protocol implementations. However, I will focus in my next work on chipmixer.com and some privacy enhancing coins (dash, monero, zcash) as this seems a very challenging and interesting task.

What kind of attacks did you exactly make? I'm keen to know them and understand all of them in a much better way if you could elaborate it well. Also, how can you consider the mentioned mixer services to be centralized?

You may find it stupid but I wish to ask one more question here, that when you're able to attack these services (don't know exactly the type of attack, but still a query in my mind), weren't you able to fetch transactions done by XMR and Dash users? It'd be a threat to these alts if you or any dev will be able to fetch the real transactions among the mixed ones as well as I believe you already are a fear to all of us who use these services because if this is actually true, what's the meaning for anyone to use a mixer?
Mixing Services work like black boxes. You put your coins in, some "magic" happens and you receive anonymized coins. Since Bitcoin is purely transparent and you are able to to analyze each transaction in blockchain space you have enough data to identify and deanomyize transactions regarding the mixing service. You just have to filter all blockchain data which is not interesting for you and analyze the rest.

These services are purely centralized, since you send your coins to a centralized party. If the mixing service wants to steal your coins - they definitely are able to do this. Just remember: whenever you lose the control over your coins and some party is able to steal your coins - it is a centralized service.
In decentralized mixing/tumbling no centralized party is able to steal your coins.

I did not look into the specific implementation of dash, monero, zcash. General speaking the difference between mentioned cryptos and bitcoin is, that bitcoin is not meant to provide privacy while the main focus of monero and zcash is privacy. They are built in a way to provide privacy, while in bitcoin some services try to implement algorithms to provide privacy on a cryptocurrency which is not meant to guarantee privacy.
sr. member
Activity: 699
Merit: 274
Crypto Currency Exchange, IPTV, AWS
March 11, 2019, 08:18:22 AM
#17
very interesting findings dear Felix. You did an excellent job!

Just like someone said, raising awareness about security flaws that have been made is a very good thing for the community.

Technologies are getting better daily, making out of it a wheel were Tom & Jerry are gaming...

I will give a try to your thesis. Thanks a lot for sharing it with us!

legendary
Activity: 3052
Merit: 1273
March 08, 2019, 11:56:18 AM
#16
What kind of attacks did you exactly make? I'm keen to know them and understand all of them in a much better way if you could elaborate it well. Also, how can you consider the mentioned mixer services to be centralized?

You may find it stupid but I wish to ask one more question here, that when you're able to attack these services (don't know exactly the type of attack, but still a query in my mind), weren't you able to fetch transactions done by XMR and Dash users? It'd be a threat to these alts if you or any dev will be able to fetch the real transactions among the mixed ones as well as I believe you already are a fear to all of us who use these services because if this is actually true, what's the meaning for anyone to use a mixer?
legendary
Activity: 2968
Merit: 3684
Join the world-leading crypto sportsbook NOW!
March 08, 2019, 10:41:06 AM
#15
Good job, I do think you've got a bright future with one of them blockchain analytics firms or at least as an independent consultant, you know compliance in fintech and crypto is coming up big time, particularly with the currently problematic area of identifying the UBO (ultimate beneficial owner) with crypto transactions as part of AML/KYC compliance.

I'm curious if this methods would work with CoinJoin transactions, particularly with those wallets were there aren't many users (I guess that means all).

On the note of traditional mixers, Mixing has been due an overhaul for a while now! I may say this with some bias, but ChipMixer's really been the only service to have innovated on the standard model of tumbling, and I suppose it's always a matter of time before a new method is cracked.

Also, I've sent you a DM, hoping to be able to get a bit more coverage of this elsewhere. Hopeful for a response.
member
Activity: 103
Merit: 327
March 08, 2019, 10:24:35 AM
#14
It is terribly chatty for me. I'd like to check if my quick glance takeaways are correct:

1. First you identify a traditional mixing service's transactions.
2. Then you mess around with the possible timeframes for the mixes.
3. Finally you do a subset-sum analysis. (Amount based analysis of mixing inputs and outputs.)

Thus you get most of the links between incoming and outgoing transactions, except those that happen to be equal within the appropriate mixing window.

Is this a fair way to describe what you did?
full member
Activity: 658
Merit: 117
March 07, 2019, 03:12:23 PM
#13
Quote
If there is interest in this topic, I can publish further information (source-codes, examples, ..) on this topic and attacks.


I'm definitely interested, sent you a pm.
full member
Activity: 630
Merit: 172
March 07, 2019, 12:36:19 PM
#12
This is why anyone serious about privacy just uses privacy coins.  Why go through all the hassle of mixing when its not even full proof.  Serious sellers on the darknet only accept privacy coins.
copper member
Activity: 11
Merit: 325
March 07, 2019, 11:45:58 AM
#11
Thanks for all of your feedback!

Interesting reading material... I've quickly browsed trough your attack on coinmixer.se, and my first reaction was that you were able to attack them because they did not include any variation in the creation of their output transactions. I mean, if a mixer only creates output transactions with version = 2, sequence = 294967294, locktime > 0 and the fee is within a very small range, it should become pretty easy to identify those transactions (and you did).

Don't get me wrong, what you did was a very nice thing... I personally wouldn't have the patience to analyse a mixer's method like you did, and i personally feel that you discovered a huge security flaw in coinmixer.se's mode of operation... However, i can hardly imagine it being impossible to fix these issues...
They basically had to generate more "random" output transactions, making sure there isn't a clear pattern in them... If they'd do this, it looks to me like an attack on their service would have been much harder.

That being said: i quickly browsed trough your thesis, so i haven't read your exact conclusions (yet), but i really think you did a great job... Raising awareness about security flaws that have been made even by the biggest mixing services is a good thing for the community Smiley

Thanks for the feedback.
Yes, you are correct, it was pretty easy to identify coinmixer.se's network. However, it was the biggest mixing services at the time and it should be seen an example of how to break these services.
The general problem of these mixing algorithms is, that they use generic transactions. Even if every transaction of a centralized mixing service is completely randomized you will be able to differentiate (with a great possibility) generic randomized transactions sent by a mixing service from genuine user transactions.
However, identifying a network does not necessarily imply that transactions of this network can be deanonymized (but in a regulated future you might get some problems trying to use these coins).

Generally speaking, the algorithms of coinmixing services are evolving. While the first generation of mixing services could easily be broken through simple taint analysis (bitcoin fog, blockchain.info mixing service), the next generation of mixing implementation needed some more work to be broken (bitmixer.io - timing attack, coinmixer. se transaction analysis) and with the newest mixing algorithms (chipmixer.com) you might already need heuristic methods.

An important research, but why don't you spend more time on attacking Chipmixer or other mixing services (of course, ideally the biggest ones). I'm curios as how far will you be able to attack reputable mixer services and if you did succesfully hack it up, maybe we need to rework how mixing services is built.
Yes, when I started my research bitmixer.io and after that coinmixer.se were the biggest mixing services. However, I realized that chipmixer.com has a better approach of mixing but was not used that much. Right after my thesis, I began with other bitcoin projects, so I didn't look further into my approaches to attack chipmixer.com. But I see, many people are interested in chipmixer.com. As soon as I got time I will again look into it. I think I already have a little python script.

In general, I would recommend using privacy driven cryptocurrencies if you want to have privacy in your transactions. But if you really want to use Bitcoin, than chipmixer.com might be the best solution for now. But remember, bitmixer.io and coinmixer.io were the best solutions in their times. Today you are able to identify and deanonymize nearly all transactions which have been made through these services. If someone used these services to anonymize their criminal activities they might still get caught.

If this is true, then you can help law enforcement to trace coins that was used in crime.  Wink

Did you find any criminal activities and terrorism funding that was presumably done with these Mixer services? Did the 3 letter agencies approach you, like they did with Gavin in the early days, to help them track some of the criminal activities that were done with these services?

Glad to hear that some Mixer services are more secure than others, because we need financial privacy.  Wink
Yes, it would be very interesting to check if/how many criminals use these kind of services. I remember, my professor also asked me this question. But I have worked on other projects right after my thesis, so I didnt follow up on this.
Actually I did not publish my thesis till now, because I woked on other cryptocurrency related projects. This is the first place I publish it.

Thanks for sharing. I take a quick look and while you list lots of attack scenario, you forget to mention de-anonymization attack through Tor exit or VPN which leak information such as DNS request (or you intentionally left it as it's complex enough to make separate research)

You might want move this thread to Development & Technical Discussion as you'll get more people who interested or can give better feedback.

P.S. will add comment after i done read the paper or/and try python code
Thank you!
Yes, I completly forgot network attacks. I remeber, that I thought about it - dont know why I didnt add it.

Thanks for posting, this is very interesting.

Is your conclusion that the specific services have been poorly designed and their implementations are faulty or is an unbreakable mixing service impossible/hard to make?
My conclusion is, that breaking mixing services can be compared to cracking/reverse engineer software. While some years ago it was pretty easy to crack software, in today's world it got way harder. However, in both cases, attackers will always be able to break it.
legendary
Activity: 3584
Merit: 5243
https://merel.mobi => buy facemasks with BTC/LTC
March 07, 2019, 04:07:14 AM
#10
Interesting reading material... I've quickly browsed trough your attack on coinmixer.se, and my first reaction was that you were able to attack them because they did not include any variation in the creation of their output transactions. I mean, if a mixer only creates output transactions with version = 2, sequence = 294967294, locktime > 0 and the fee is within a very small range, it should become pretty easy to identify those transactions (and you did).

Don't get me wrong, what you did was a very nice thing... I personally wouldn't have the patience to analyse a mixer's method like you did, and i personally feel that you discovered a huge security flaw in coinmixer.se's mode of operation... However, i can hardly imagine it being impossible to fix these issues...
They basically had to generate more "random" output transactions, making sure there isn't a clear pattern in them... If they'd do this, it looks to me like an attack on their service would have been much harder.

That being said: i quickly browsed trough your thesis, so i haven't read your exact conclusions (yet), but i really think you did a great job... Raising awareness about security flaws that have been made even by the biggest mixing services is a good thing for the community Smiley
Pages:
Jump to: