How can we improve passive CoinJoin e.g. from the Background?

[DanGould]

Unlike other systems iOS limits background processes' resources and execution time opportunistically. The only way to get a task as heavy as Signing a CoinJoin to happen at a scheduled time is with an external push notification, which increases the attack surface on users' privacy via timing data revealed to the push server.

Right now the only way to CoinJoin is to foreground the chaincase app on schedule. That's helped out with a notification. What else can be done here?

Oh, and background task fire at a minimum of 15 minutes from when they're scheduled.

affects: 10
importance: 10
difficulty: 9

[DanGould]

we could ping ALL devices which enroll for silent push notifications when a round is about to happen up to 2x per hour. Upon receipt, Chaincase can check from the background if it has queued for the round and if so start to tor process and complete signing in <3 minutes. But unfortunately the OS may choose to delay posting the notification as low-priority and not check. In that case, it's possible to simply wait for the next round.

This has the trade off of exposing user ip addresses to Chaincase server, but not in a way that coordinates an ip with a queued output.

Still, it is worth considering the danger that it may be possible, over a long enough time period to conduct a timing attack or a partition attack (similar to this WabiSabi issue) by selectively serving these push notification to devices the coordinator believes wants to CoinJoin, and then correlating outputs their ip depending which outputs continue the process and which don't. Because some users may CoinJoin from desktop Wasabi or move their Chaincase app to the foreground, there may be sufficient randomness to thwart such attacks practically. There is more research to be done here as to the actual trade off and dangers vs improved user experience and improving users' ability for successful CoinJoin

cc: @nothingmuch

[DanGould]

0.6 Update: A Proven Concept

At this point a number of successful CoinJoins have been triggered by silent push notifications while my iPhone was in my pocket. They succeed with modest consistency.

IP addresses are never leaked to the Chaincase server ✅

Contrary to my prior comment, device id's are generated on device, sent to Chaincase over a unique Tor identity. Each push notification request for that particular id is sent to apple as a trigger, along with all of the other enrolled device tokens. Apple can already figure out the IP of the device and that it using Chaincase via TestFlight. So users are NOT giving out any new information. Chaincase does not get user IPs.

In Practice 📲🔀

Connection Confirmation, Output Registration, and Signing ZeroLink phases have been reduced to 7sec. ZeroLink research estimates suggest a rough minimum of 1 minute to coordinate every phase, in total this is approximately the same magnitude.

15sec prior to the end of input registration, the Coordinator requests silent pushes keyed cj for all known devices. A device receiving a push with cj key begins background CoinJoin processing only if there are Coins queued on that device. It starts Tor and the Synchronizer. It takes approximately 10sec from receipt to start tor & successfully register an Alice input. The Synchronizer polling frequency is reduced to 1sec. This allows the protocol's following phases to complete a CoinJoin. The app sleep 1sec before the hard 30sec limit placed on silent push-triggered background processing to safely stop the synchronizer and Tor.

Hurdles

Reduced Connection Confirmation means the default Synchronizer polling is more frequent than necessary.

For the proof of concept the frequency is increased on push receipt (1sec) and 5sec otherwise. Perhaps it should be increased only during the time period necessary i.e. from 15sec before the phase 'til after signing. 5sec otherwise.

side note: polling more frequently during initial Input Registration may improve user experience; that way a particular input registration requires less waiting to get updated in UI.

Polling has inconsistent results in short phases.

Due to reduced phase timeouts, a request is more likely to run out of time. Instead of polling requests to change phase and then respond, perhaps clients are better off to predict at the start of each phase. For example, if one device fails output registration because of the short time to process it then the round is kaput and we get an undesired utxo ban. Timing vulnerabilities need to be explored in more depth.

❓ Outside experience would be of tremendous value to help with this problem

Silent notifications are low priority.

A push delivered too distant from the brief Input Registration window that overlaps with the 30sec background processing limit will fail to CoinJoin. Perhaps this can be addressed by resuming if and only if the push is received within range of Input Registration.

Push no more often than once every 15min per device. In testing, As long as the app has recent use on the device notifications spaced 15min or more trigger background processing consistently. However, offline mobile devices will receive and handle these when the come back online.

No automatic "Remix" yet

Wasabi throttles CoinJoin outputs to register only 60sec after broadcasting the same CoinJoin. The warning message logged says this is to prevent registration of a spent output. ❓ The reason for the delay is not clear to me. Without this delay, there should be enough time to enroll for remix which can be triggered again in the background. Users do get a "CoinJoin completed" notification on success, so if they click that and open the app there should be enough time for the new CoinJoin output to re-register since it will still be in queue.

tagging: @Kukks

[MaxHillebrand]

Very interesting - well done!

I understand how no additional IP info is leaked.

But is the client side generated device ID the same across time? Or is a new one generated frequently?

If not, is there a clustering of rounds a certain device ID was participating in? Or is this still in the anonset of all users?

[DanGould]

@MaxHillebrand Device *tokens are generated on some conditions like restore from back up, install of the app. They're unique to the device + app pair. The official docs explain.

We push notifications to every single device as to provide the anonset of all users. Because all users receive the identical notification payload there is no clustering of rounds to device tokens. It's even possible for someone to CoinJoin by keeping the app open, so the list of device tokens is not a complete list of potential CoinJoin peers. While this POC and probable first rollout does not yet employ the TLS notary @nothingmuch suggested, which would let users audit that we actually made requests to push to all devices, we should in time. Such a notary would bolster the protocol from potential timing attacks.

I can imagine a timing attack that requires Chaincase collude with Apple over many remixed rounds to link a device to a TXO, however such an attack would interrupt service for other honest participants and thus be costly to Chaincase to do in addition to ruining the reputation of the software provider.

It would be less costly for Chaincase to link a device token to a particular device, but without colluding with Apple that does not identify anything more than that token about a physical device or IP address. A targeted attack carried out over a substantial period of time could cluster TXOs. Perhaps the notary is worthwhile to defend against such weaknesses

[nothingmuch]

I only went one more level deep in the silent push notification docs, but couldn't find info about IP addresses, is that because of underlying HTTP redirects or something?

OK so there's an opaque (encrypted?) device token that only APN can decode, but it's a long lived per device identifier and it can't be refreshed from the API, only the OS decides. Apples says it's important not to use this device token for identification which I'll take to mean that it's possible to do that.

Perhaps a model that can work is that clients can opt in for maybe a whole week's worth of silent notifications, and then assuming the provider tokens are not replayable and use asymmetric crypto (i think it's possible with both certificates and JWT, for sure with certificates if you just expose the ephemeral key of the TLS connection after but I don't know what other information is given) the server could use TLS notary to make the transcript less repudiable, and this could be opentimestamped and latest block hash could also be included in the payload somewhere to constrain time.

Since device tokens are per device-app pair, it may be safe to then publish an audit log of all push notifications sent, and to not allow any opt out mechanism except through apple's error codes, i.e. so long as the transcript shows successful notification posts, the same device ID has to be notified during the next notification round and so on, until the subscription expires.

By making subscriptions coarse grained and not providing an opt out operation but only expiry the set of notified users is larger, thereby providing better privacy, and by publishing the transcripts with the APN api anyone can verify that the coordinator claims to have notified them at some point in time, and with TLS notary, that a 3rd party witnessed them doing that. Without such a 3rd party the claim is useless, because apple or the device may unilaterally drop notifications, giving the coordinator plausible deniability.

[DanGould]

Apple suggests to POST the user device token every time the app starts up so the back end has the most recent token, since it can change if a user restores from back up or re-installs. I've also been suggested to delete device tokens whenever APNs tells me a notification couldn't be delivered since that user must have shut notifications off / uninstalled etc. I'm curious if there might be an issue to correlate device tokens with coinjoin participation with this arch and if so how to mitigate.

[nothingmuch]

from a privacy PoV i think the right intuition is that if you have a large enough set of notified clients so that the server can't really tell which of them are acting on that information. both aspects sound like they potentially degrade that (whether you delete or not is immaterial given apple reveals the information about lack of delivery) but don't seem to fundamentally change anything.

[DanGould]

Another way to improve Chaincase CoinJoin ahead of push notifications may be to show who queued / registered historically, since the connection isn't stable. Though it could be gamed, it could give people more confidence to queue and help promote network effects to accelerate

[DanGould]

@armins88 let's see if we can extend the backend status to include the number of users who have queued in this coinjoin period (regardless of whether they DQd or not)

One requirement of this is to remain compatible with Wasabi client. So, the back end should maintain a count of how many have queued and supply it to chaincase clients, but it should not break compatibility with the Wasabi front end. I think this is possible because it only adds a piece of data.

[DanGould]

bluewallet allows their users to serve their own notifications but I think, following the model Signal succeeds with this is excess complication

[purpleninja21]

[DanGould]

Background payment status sync could be done with background fetch on iOS with the filters. We should look at their implementation

[DanGould]

On Android we can do push notifications without Google Services by using https://github.com/microg/GmsCore/wiki from MicroG

[DanGould]

One interesting thing about push notification registration is we get a rough count of active users. Every time the app is open users who have notifications enabled should push us a unique token. We could also display something extrapolated from this this back to users along with those registered to CoinJoin