Quick Analysis: NHSX Contact Tracing App

When the NHSX contact tracing app was made available in the app stores last Thursday we decided to take a quick look at its operation and how the code has been put together. We used the Android version and the excellent MobSF tools to do our reversing analysis. On Friday the full source code of the app was also published on github. 

As has been widely publicised, the only information needed for signup is the UK postcode area. A postcode area corresponds to thousands of different households. Once this information is provided and Bluetooth is enabled the app enters its standard operating mode. It runs as a background task so a small notification is always shown as it is running and it’s restarted automatically if the phone is rebooted.

The app uses FIrebase so during the startup a registration is made, for example (obtained using mitmproxy):

A signup endpoint is provided on api.svc-covid19.nhs.uk/api/devices that is supplied with the postcode information as well as activation information and a push token. The app signs up to Google cloud messaging, which allows notifications to be pushed by the server to the app at a later point. This is the mechanism by which a user of the app will be notified if they have been exposed to somebody with Covid-19 who was also using the app.

Firebase endpoints are not certificate pinned, but all communications with api.svc-covid19.nhs.uk have a pin provided in the network security configuration which further protects the app from any Man-in-the-Middle (MitM) exposure of data flowing to these endpoints.

It isn’t quite the case that the only personalised information collected is the postcode area. The phone device model and version number is also collected. This is presumably used in the modelling of the Bluetooth signal strength from the device to provide a better estimate of proximity. There is a wide variation between devices, so knowing the model is quite important as was shown by the excellent work done on this by the TraceTogether team in Singapore. Of course this means that, if you have a particularly unusual brand of Android device, then the number which are present within a given postcode district may be quite small, slightly elevating the risk of your data being linked with your real identity if anyone has access to the backend database. Ultimately, this all comes down to the safeguards that need to be in place to protect this data.

One of the innovative aspects of the NHSX app design is that it has a better approach to solving the “iOS background” issue, as described in this technical deep-dive. The app has an identity as well as a keep alive Bluetooth GATT Characteristic provided on the service UUID.

The app can act both as a Bluetooth peripheral device, advertising to other devices around it and also as a Bluetooth “central” to connect to other devices for sending/receiving data, specifically the payloads from other apps that are recorded as a contact events.

Due to privacy concerns, iOS quite aggressively ensures apps are not able to advertise for an extended period in background mode. iOS uses a custom overflow Bluetooth format to advertise services in background that is normally only used by the iPhone OS. The NHSX app has reverse engineered this to allow a background iOS to be woken up. There still remains a problem if all co-located iOS devices are in the background for too long, since they will then need a foreground iOS or Android device to wake them up. This might not be a major issue in practice though. It is however a little clunky compared to the updates coming from the Apple/Google approach which should allow reliable background operation.

If you wish to report symptoms then you are driven through a couple of screens double checking that these (coughing, high temperature) are definitely consistent with Covid-19, and you are asked to provide a date for the onset of these. You can then submit a report which will be processed by the backend systems. Somewhat controversially, the NHSX system does not presently seem to require a positive Covid-19 test in order to make this submission, which may open it up to abuse and undermine its efficacy. A testing step could be added without needing to change the app, so the intent is probably to keep this aspect flexible. We will explore this and other security issues in a future blog.

The submission is made to another API endpoint that includes the stream of contact events that the app has recorded, as discussed in NCSC technical paper published last week. There are no particular surprises in the data recorded by the app. The contact events can be decrypted by the backend to reveal other app instances that the user has been in contact with, to allow push notifications to be sent to those apps where the level of exposure is considered to have put them at risk.

Some effort has gone into protecting against the submission of manipulated reports, both by the pinning and also because the reports are signed with an HMAC that uses the private key associated with the app instance.

Of course these protections cannot prevent a determined attacker from being able to craft a script or modified app that is able to both register and obtain a private key and to submit a valid report. The efficacy of such an attack (other than wasting backend resources) is related to whether the contact events are from real users that might receive a notification. This is harder to achieve, but we will also explore the risks around this in a future article.

NHSX documents describe the structure of the backend systems. This must take the contact events from different reports and use various models to determine the risk of exposure before sending out appropriate notification events to the impacted users. The source code for the backend has not been made available. 

One of the arguments made in favour of the centralised approach is that it allows the data models to be more easily tweaked and more advanced data analysis techniques to be applied. This may be true, but it does come with the enormous downside risk of the privacy concerns around centralisation. In the Apple/Google APIs an exposure configuration allows various parameters to be tweaked even though the matching is being done privately on individual devices. It might also be acceptable for users to provide anonymized information about their exposure for some central tracking, in the same way we do already with app performance and crashes. The key point is that this must be opt-in and shouldn’t prevent full use of the app without it.

First impressions of the NHSX app are positive from a design and security perspective. However, as discussed in our previous blog the decision to only rotate the Bluetooth Value on a daily basis creates unnecessary privacy risks. Moreover, the justification of this in terms of providing information about daily contacts doesn’t even appear to be implemented in the current app. Much remains unclear about the operation of the backend systems and whether the UK is backing the wrong approach by opting for a centralised system.