COVIDSafe Part 4: Deeper analysis, activities post pandemic, and a call to “hack the data”

I’ve gone a little deeper and let COVIDSafe run for a while in the following environment setup below. I wanted to validate and reassure that the data sent is limited, but also wanted to have a deeper exploration into bluetooth. Needless to say, I think this experiment validated some assumptions, identified some information gaps and has perhaps informed experiments with the App. It also got me thinking on a few more of the privacy concerns, and I’ve gone into a further tangent on these below.

An analysis of the database

The application was active for 28 hours and conducted 1060 scans between 17:45 on the 29th of April through to 19:36 on the 30th of April. These scans lead to the identification of my personal iPhone across 5 different tempIDs (stored in the database and write ahead logging file). This is surprising given I’d had the phone nearby in the 3 hours after 17:45, around 3–4 hours in the morning, again from 14:00 onwards; I would have expected at around 8-10 (unless my phone was not regularly updating as listed below). The database has an additional 4 devices which, given the RSSI, all appear to be neighbours as the phone I’ve used has not left my desk which is close to the window.

Is interesting to note that the scan period is initiated approximately every 40 seconds, and only lasts for around 8 seconds. Ideally this would be a lot more, however this would understandably impact the devices performance and battery life.

An analysis of bluetooth traffic

The bluetooth traffic log indicated that the above scans had taken place and data had been exchanged. I also noted 7 interactions where connection was disrupted, as well as 29 exchanges that were in the bluetooth log but did not appear in the database (this could be also because data was is written to the cache file that I have not reviewed yet).

An analysis of BurpSuite data

BurpSuite was used to review application data during which time, no data was uploaded. The JWT remained static and the tempIDs changed regularly. There was one curiosity though; the request to /prod/getTempId was skipped for no particular reason on 2 seperate occasions at the 24 hour period which kept the tempID for 2 hours instead of the intended 1 hour. Not a big risk, but if this remains static for a prolonged period, the individual tracking scenario discussed by other researches becomes more of a reality.

An analysis of network traffic

I used Wireshark to capture all remaining network traffic going from the phone and observed that, outside of normal behaviour and the application data reviewed, not much happened.

Sum of analysis

Some of the empirical concerns about the ineffectiveness of COVIDSafe near iPhones (or in general) appears to be valid however this could be due to any number of variables such as device use and proximity. It also doesn’t help that I had not kept a log of hours of use, activities on the phone or when I was or was not in the room… perhaps for the next time I do this experiment. My coordination of time for logs also could be improved upon between the test VM, the phone and my own time/space awareness.

A call to “hack the data”

I’m confident that theres not a great deal of evil that can be done or a violation of privacy as so many “experts” with no technological background have fretted about. However, I assess theres a way to get around these privacy fears without undermining the intended health tracking application.

There are 2 things that can be done to “hack the data”:

  1. Register with an incorrect name or pseudonym. For example, I have, for the past 10 days, been registered as Carol Baskin. I would also encourage Joe Exotic, Bubbles the Clown, and any other myriad of names that come to mind. I would also encourage names that are entertaining without being too low brow; call centres using this data to track cases could probably do with a bit of humour during what could be an uncomfortable activity.
  2. Use someone else’s mobile for the pin & point of contact. I’ve been able to register 2x phones under one number, therefore there is no need to have it associated with your individual phone number. This does mean that someone else will be taking the call for your random name should a positive test occur. My only guidance would be to ensure you have a codebook to establish pseudonym to actual name.

If this is done on a large enough scale, the accuracy of the data is ruined for anyone doing invasive activities without preventing contact tracing. If your argument for not installing stems from privacy concerns, I’d argue that you have a moral obligation to create your own obfuscated, oddly named accounts complete with incorrect phone numbers to defend the rest of us.

Sidenote: ESP32s for those without phones

So a conversation had come up in an online forum about the vulnerable, or those without a phone, to still be able to access the service. It might be possible to provision ESP32s that beacon out parameters that could be directly tied to a phone number and individual through an intermediary service. The static temp may upset the privacy minded folks whilst disregarding the value of early access to a vulnerable person whose life could be saved early on should contact occur. Additionally, I’d be curious if the tempID would remain valid for more than 21 days- logically I think the process of decrypting the encrypted data incorporates a time based salt with the private key that works backwards till a valid value is decrypted (I wouldn’t mind hearing DTAs thought on this).

I might further explore this at a later date.

Once this is over or if you’re travelling

I mentioned earlier that if the URL is no longer accessible or if the apps got nowhere to call to the tempID will remain in place until it can be renewed. As COVID dies down and the app is no longer necessary, the tempID becomes static and will facilitate individual identification. Another risk is the possibility that the domain is “black-holed” or blocked, especially in unfriendly countries which could help with individual tracking with a static tempID. therefore, delete the app once this is over or if you’re in another country.

I would also encourage the Government to set everyones tempID to a long string of zeros so that we’re all the same once the requirement to track is no longer present- that way it just means we’re all the same.

We’re here to help

Let Mercury safeguard your business while you focus on growing it.

Reach out to us for a tailored cyber security consultation that aligns with your unique business needs.