Utah Contact Tracing

In recent news Utah is in some hot water for spending 2.7 million dollars on a technological response to the Covid Pandemic. It’s seen as a failed waste of money that would have been better spent on actual people. That it’s not getting used makes that an easier attack, but even if it was a raving success it could be that the money would have helped more elsewhere. I also do not really know what the demographics of people who can and cannot use technology are. I’m only going to discuss the technical aspects of this project and why it should have failed.

First let’s talk about what the best world scenario of a product like this would be. Everyone goes about their day with their cell phone on them and a system tracks their location like it always does, but now that information is kept in a new database. If anyone got infected with Corona (or any other disease really) this system could travel backward in time in this person’s history and register any other person who was within the danger zone in time and space, track who they then ended up in proximity of and so on. Truthfully you wouldn’t get very far before the complexity of this problem space greatly exceeded even the largest systems ability to track in any reasonable time, but you can apply heuristics to this space to perhaps only follow the most likely lines first.

Given this information the CDC could come out and test people. Perhaps get to them before they spread it further and maybe even before they show signs and have a good chance of beating it quickly with help (I don’t know if this is true of Corona or not). This would be the most valuable when we’re closer to the beginning of a pandemic. As soon as it showed up in a territory you could map out everyone that was possibly exposed and quarantine before it spreads.

Doesn’t that sound great?

It really does until you think about the privacy issues associated with this level of tracking. To not only know where someone has been but everywhere they’ve ever been is a pretty big deal. It’s a given that this power would be abused. No matter what controls you put in place in this system it’s only a permission slip away for someone to gain access. We know for a fact that governments both friendly and unfriendly are tearing past these walls meant to protect the data in a database from unreasonable access. Furthermore, we know that even today when everything is web something or other and we have billions and billions of dollars sunk into the problem that hackers occasionally get to anything but the most protected, state level secrets–and probably that too. Imagine a criminal gaining access to the previous locations of a multitude of people, analyze their habbits, sort out anyone that might have some dirty little harmless but unpopular secret. The power to blackmail or worse becomes off the chart if you have this data.

So is there a way to salvage this situation? I think so. I think that this direction of thinking is still a common one and people are rightfully concerned about who is going to have this data. It’s important to realize that once data leaves your system it leaves your control and you can never get it back. However, there are two ways I can see in which this system could have been designed and surely wasn’t that would all but eliminate these concerns. Both of these ideas take advantage of an anonymizer called ‘Tor’ but I’m sure there are other methods.

Let’s first look at a method that uses a central database (with all the HA cloud stuff assumed). Everyone has with them a system that occasionally attaches to a web service and tells it an onion address, a location, and a time. This onion address is to a service running on that device, or another contact for the owner, that listens for messages. It is not required that the same onion address be used every time, so to further obfuscate things we can create an array of these services and send different addresses at different times. When the system tracks a threat it notifies the appropriate onion addresses with a signed message about that threat and how to proceed.

There’s a possibly better way: eliminate the central database. It starts similarly, with everyone having a mobile device with an onion service running on it. Instead of sending a message to a centralized web service, these individual systems broadcast their address. A ready made protocol for this could be mDNS: broadcast to the local area network your name. When two systems run into each other each registers the address and a timestamp; location isn’t needed. When the CDC finds a patient with a contageous disease, that user’s system can iterate its “visitors” and tell them of the possible threat. This then spiders outward to users on a geometric progressin of processing power; exactly what is needed to solve a problem space that’s a geometric progression.

In addition to having an array of onion services would could perhaps find a way for these systems to occasionally swap onion addresses. This may not work to well though because it introduces an opportunity for an attacker to drop such traded addresses and not forward messages meant for the user of a different time.

This system is much harder to attack. Tricking someone into giving you access to a system only gets you into their data and not the data of everyone else. Furthermore, this eliminates the tactic of just grabbing all the data you can and looking for things to exploit. To harm a user you have to at least target them directly.

It’s the best of all worlds, and though I’m sure there are holes to fill, but this would provide a full, searchable database to automatically locate and notify people of any time/location threats they may be subject to without introducing too many avenues for the exploitation of data.

We are working on a system that would provide the tools to create such a thing in an environment of users ready and set up to join such a network. The device could be built for as little as $20 with consumer grade components bought over the counter or it could come in the form of a cell phone running the same service. If these ideas interest you then please watch our project’s documentation as we refine our ideas and begin to implement them.