COVIDSafe Part 3: network capture, analysis & OSI layers 1–8

So after clocking off yesterday evening with work I decided to do what I do every night (this week), go for another brief exploration through COVIDSafe.

I wanted to revisit my failed attempts at intercepting the traffic and, courtesy of a brief post from Geoff Huntley, I’d identified the errors of my ways and got the app flowing through Burp Suite & Wireshark. I’ll happily provide the pcaps & internal DB after I leave the Nexus 5 idling till later this evening with my own phone in close proximity.

Observations

Illustrated a little further along I’ve provided a rough overview of traffic flows to device-api.prod.lp.aws.covidsafe.gov.au and a relative to a “hypothetical” backend that may exist, however what I’ve seen in the 6 hours of capture I have looked at are:

1. 5 parameters are sent for enrolment via a POST request. The device ID sent might during enrolment be a superfluous however I cannot qualify this. At the very least, I do not believe it can be correlated with the IMEI or MAC address… will probably dive into this over the weekend.
2. You can falsify all data except your phone number as part of enrolment(yes, even the device ID if you are that paranoid, although I wouldn’t be certain of the effect this would have, once again have not qualified its role).
3. The device is only making a single request to /prod/getTempID once every hour after the device. It is not uploading traffic
4. The JWT used to update has not been renewed and I’m guessing it remains static throughout the apps lifetime.
5. It looks like an upload of records needs to be approved by a doctor or medical practitioner once an infection is confirmed, and cannot be uploaded without at least a 6 digit pin. Whilst I have not attempted to brute force this, I dare say both the pin and phone number are required for the upload to occur.

So how does this look & understanding how a HSM might be employed?

I wanted to at least map out traffic flows between the mobile device and the API as illustrated below. I’ve highlighted in green what I’ve qualified so far through normal interaction, and in yellow what “probably” happens without having been qualified (would like to revisit when details come out):

It is likely that a HSM is in use to facilitate the symmetric encryption of database content and tempID/MSG with the private key stored within the HSM. Whilst I cannot qualify the statement, I hypothesise that values could undergo additional layer of encryption based on timeframes, so as to facilitate anonymity when moving around. It is also likely the following business rules exist:

1. Data is only encrypted one way within the app, and can only be decrypted in a seperate database once a case has been identified.
2. Data can only be decrypted based on a specific flow IE after a case of COVID19 has been formally verified and only against the data that has been uploaded.
3. decrypted data, including a phone number and alias is then used to accelerate contact with possible contacts.

Once again, I dare say they’re a bit more complexity especially around key management, logging and the actual CI/CD setup but its been a good exercise to think through, analyse what is known and deduct what could be or at least an exercise of thinking through how I’d do it.

Layer 8 errors

So after looking at ones and zeros, building out a rough, partially qualified diagram, there is a little too much happening at the “thought leadership” end that is quite frankly frustrating and lacks any detailed consideration. To call a few of these out:

1. Stop “parroting” for code: I keep hearing the experts call for code of the backend environment that I don’t think will be as productive as more of a walkthrough of architecture that can at least allow us to identify and understand the implementation. I believe We’re better off asking for validated design documentation or questioning based on what hands on analysis has deducted to date by the research community and key considerations that can be generated based on what we know. Realistically, we should have asked for design verification over privacy impact assessments.
2. Don’t tell “vulnerable” people not to install the app: A statement that frustrated the hell out of me during a panel discussion recently involved an “expert” advising that vulnerable people dealing with domestic abuse or stalkers should not install the app. This only reinforces conditions of fear that they’re being tracked, which is fantastic if your intent is to enslave human beings to cybersecurity mysticism. Additional recommendations of constantly factory resetting phones are equally counterproductive as the recorded data wont be maintained and thus undermines the intent of the app. Worst still, it’s vulnerable parts of the community or those that are distrustful of the government that we need to reassure and, should they be infected because we’ve elected not to track and control the spread, we will prolong the disease. If they are genuinely vulnerable, further marginalising such communities by denying healthcare information is on par with anti-vaxxers.
3. The Americans aren’t coming to spy on you: Yes, AWS is owned by the United States, however the act of acquiring and decrypting this data is of little value even if it were possible. Additionally, there are plenty more effective mechanisms out there for surveillance including angry twitter messages or interactions and ideological leanings that can be gleaned from more accessible sources than a bluetooth app.
4. So why didn’t we go with Australian hosting: there are a few simple answers to this: development teams (such as the companies used) already have breadth & depth of experience in AWS, effective DDOS services through CloudFront for up to 10-20 million requests an hour that cannot be sustained by a local provider (we might have had availability issues in the past that we’ve learned from), ease of rolling out code quickly and easily into AWS instead of new & unfamiliar environments, well developed and readily integrated HSMs [that realistically should address the overseas interference concerns]. AWS presents a low risk, low cost and will fundamentally lead to an outcome that saves lives.

Whilst I think a healthy skepticism is part and parcel of democracy, there is an ongoing misinformation or confirmation bias towards the sky is falling, the government is failing or zombies are coming. I think theres been a-lot of effort in the tech community to really understand whats happening with COVIDSafe and I have to give a shout out to Geoffrey Huntley @GeoffreyHuntley , Matthew Robbins @matthewrdev and Gabor Szathmari @gszathmari for their efforts to date.