Smittestopp Summarized

Summarizing the expert group report on the Norwegian COVID-19 app

The expert group appointed by the Norwegian Ministry of Health and Care Services to ascertain whether security and privacy is responsibly taken care of in the Norwegian COVID-19 contact tracing app "Smittestopp" has now published its final public report.

Being a member of this group, I thought I would very briefly and informally summarize our findings in English here, as the report is only available in Norwegian.

Though this is obviously a condensed representation of the contents of our report, I have tried to retain overall structure and the meaning of our original statements. Some details are undoubtedly still lost. I do this of my own personal initiative; This translation and summarization is not approved by any other party, including other members of the group.

This means that this is not an official translation.

Background and Involved parties

In March of this year, it was revealed that the Norwegian Institute of Public Health (Folkehelseinstituttet, FHI) – a government agency under the Ministry of Health and Care Services (Helse- og omsorgsdepartementet, HOD) – were developing a digital contact tracing app. Simula was chosen as a supplier, producing parts of the soution. FHI would also produce parts of the solution, as well as Norsk Helsenett (NHN) – which is a government owned company that develops and delivers national IT-infrastructure to the health sector.

Our work

On April 4th, the Norwegian Ministry of Health and Care Services appointed a group of experts based on recommendations from the organization IKT Norge. None of the participants are connected to the Norwegian Institute of Public Health, the Ministry of Health and Care Services, or Simula in any way.

We were tasked with evaluating all involved components in the Norwegian solution for contact tracing in the context of COVID-19. This includes mobile apps, a backend (encompassing many components, including analysis- and reporting-code) and connected services running in the cloud, integrations and new solutions at NHN and FHI, and plans for software that would create aggregated datasets after 30 days, for use in research and analysis.

From the 5th of April, we had direct access to source code (working repos), documentation, and representatives from all involved parties.

The Ministry og Health and Care Services published our mandate (Norwegian) on the 8th of April.

We delivered a temporary public report (Norwegian) on the 9th. Because of the short timeline and what parts of the overall system work had started on at this point, the temporary report only dealt with the mobile apps themselves, as well as some of the backend code. Additionally, we only commented on the security-aspects, and not the privacy implications – as we did not feel we could properly evaluate the privacy of the entire solution without more insight into the complete system and more time.

The Norwegian solution

The Norwegian COVID-19 contact tracing solution has two purposes:

  • Contact tracing
  • Evaluating government actions that aim to lower infection rate (e.g. public movement patterns), as well as further research and analysis (e.g. input to SEIR-models)

The solution consists of the following components:

Smartphone app ("Smittestopp")

Users enter their date of birth to confirm they are older than 16 years old, and register with their phone-number in order to use the application. The app collect locations (GPS) and contact (BLE + metadata relevant for estimating distance) with other devices running the app continuously. Once an hour, the app attempts to send all collected user data (contacts via Bluetooth Low Energy, locations via GPS) to a central server, and deletes local data upon completion.

The code also includes workarounds for BLE-use on iOS in the background, as this is presently subject to certain limitations on the platform.

Users can temporarily disable tracking (BLE and/or GPS), or request data deletion (in the cloud) from their app. The app also independently uploads heartbeats once registered, which is used to determine whether a given user is still active (still has the app on their phone), and delete their uploaded data if they are not. This heartbeat also includes whether the user has enabled or disabled GLE and GPS, respectively.

User interactions in the app fires analytics events to AppCenter.

Cloud solution

An Azure-hosted central datastore. Contains all user data from the last 30 days, including locations, IDs met and timestamps of BLE event, and associated metadata. Here, contact events are calculated in various ways, including crossing GPS-trajectories, and BLE-signals within 2m over 15 min., based on RSSI and more. Two graphs are produced:

  • A graph based on location data only, and
  • A graph based on Bluetooth-data, augmented with location data.

Also included here are services that produces reports for government health services for each person that has been in contact with an "index" (confirmed infected) patient. This includes points of interests (POIs), risk scores, number of contacts, as well as details of each contact between the two, such as the contact event dispayed in a map, risk scores, POIs, and more.

Within 30 days, and after using making aggregated datasets for further research and analysis, the cloud solution will delete data on an individual level (personally identifiable information), in accordance with regulation.

Security events, diagnostic data, etc. are also fed to a Security Operations Center (SOC) from here.

Web applications from FHI & NHN

NHN has produced an access auditing solution, where users can log in securely on an existing Norwegian healthcare information website, using a high security government standard login solution, and associate themselves with the phone number used to register the app on their smartphone. They will then be able to see who has accessed their data, when, and for what purpose.

In addition, FHI has produced a web application for use in "hunting" for contacts. These "infection hunters" will, given an index patient (person with confirmed infection), review contacts between the index patient and other persons for possible notification. Here, they will use the reports mentioned earlier.

Aggregated data

There is an expressed need for aggregated data in order to evaluate, for instance, the effect of government actions on social distance, rate of infection, analyze public movement, and to obtain data to use as input to SEIR-models.

Protocols to produce five different aggregated datasets (with different variants), and a k-anonymity of (usually) 5-10 has been proposed.

The code that would perform this task was not finished during our work. Thus, we worked mostly with documentation and conversations with relevant parties in this part of the review.

Data Use and Results

Purpose and context

The more limitations one puts on collection and storage of data, the less of a risk is posed to users' privacy. We point out that contact could be traced via BLE alone, and note that GPS typically has a precision of 3-10m and yields the best results outdoors. We also comment on the state of Bluetooth APIs and their limitations (on iOS in particular), which at this point in time is the main argument in favor of augmenting this data with GPS, and correlating data from several users. We note that background use of BLE-APIs on iOS will change in an upcoming OS update, as part of Apple and Google's collaboration on a standardized contact tracing API.

To evaluate how government actions affect movement in the population, one would ostensibly need location data in some form – though it would likely suffice with "courser" data than GPS on an individual level (as is used in contact tracing). In the Norwegian solution, GPS-data from all participants is used in combination with BLE, the latter of which is used to count contacts between people on different categories (POIs) of places. One could imagine a differentially private approach, where apps would aggregate data on the device, add artificial noise with certain statistical properties and so on.

In a pure resesarch-perspective, more data would be better – though the opposite is true in a pure privacy-perspective.

The app is voluntary to use in Norway, though the basis for processing is a regulation (authorized by the "Diseases Act") – not consent. Outside of this, the (the Norwegian implementation of) GDPR applies as otherwise. The regulation which is the basis for processing puts in place certain limitations for use and sharing of health-related data and location data. As BLE is neither, we fear that the current regulation allows sharing of BLE-data with, for instance, law enforcement.



The app starts communicating analytics data as soon as it is opened– including app version, telecom provider, locale, device model and manufacturer, screen resolution, OS type and version, timezone, and a unique identifier. This is not mentioned in the app's privacy policy, and user's are unable to control (i.e. opt out of) this.

The app uses a static identifier in BLE-contact communications. This was also reported in our previous, limited report. Simula plans to implement a new approach, where exchanged IDs and timestamps are encrypted on users' devices with a public key, and decrypted using a private key in the cloud.


The only form of anything resembling session validation in the cloud solution is using an eternal connection string. This means that one Man-In-The-Middle'ed connection equals eternal session hijacking (in combination).

The functionality used to bind phone number to the cloud device ID is implemented using a so-called "preview feature", which the supplier (Microsoft) says one should not use to process personal data or any other data that is subject to heightened compliance requirements.

Access solution

Requesting deletion of data in the cloud (via a user device) will also effectively delete any audit logs for the user data. This should be decoupled and done directly in its own solution.

Users can not see their own Bluetooth-contacts in the access auditing solution.

Logs of FHI's data access cannot be seen by users at the time of writing.

Notification solution

The code that finds and analyzes instances of contact is of very low quality. In some cases it is hard to read, and is so complicated and complex that it can not be called easily maintainable. There are also weaknesses both in implementation and in method (such as dropping data, performing smoothing).

As a consequence of attempting to translate signal strength (RSSI, txPower) to distance (BLE), there might also be inconsistent classifications.

SMS, which is used for notifying users, is not a secure communications channel, and these are easily spoofable.


The government thinks they need 60% of the population (minimum) to get good results in contact tracing, and that research/analysis might need only 10% of the population. As users cannot choose what data to share for what purpose, we believe there is a risk of lowered user uptake.

We understand why one might start out with a centralized approach: Attempting to compensate for data quality by combining data from users, adjusting the contact tracing algorithms, and having an easily understandable and familiar basis will reduce risk and time to market. However, this does not mean one cannot work towards decentralization over time. By being more selective in what data to collect, and separating data collection for contact tracing from other purposes, one can reduce the risk to user privacy. In addition, a centralized data store of this kind will yield much larger negative consequences in the event of misuse, leaks or errors. It will also be a high value target for APTs, which are already targeting actors and systems involved in COVID-19 response.

Location data (on some level) is needed to evaluate movement patterns in the public, and enables use of category of location and mode of transport as factors in contact evaluation. While it can be used to remediate lowered quality of BLE-data, it is also more privacy-invasive.

Updated APIs from platform providers (Apple & Google) will lead to better data quality via BLE. Using these APIs requires no use of location services, and forbids a centralized storage approach, and would thus demand some rework of the app. This would have to lead to a lowered ambition when it comes to data collection, or implementing an app that only does contact tracing.

We discuss the currently propsed solution for data aggregation, which involves random sampling, k-anonymity and access-control, and compare the qualities of this approach with differential privacy, which we think would yield both better privacy and better data in this case.

Also discussed is contact tracing vs. attempting to predict infection directly, e.g. using time spent in POIs, close contacts etc. as inputs.

The group points out that open source code would make it posible for the public to verify, and possibly improve the solution. Open source code might lead to better security in a longer perspective, but in the short run it could enable bad actors to identify and exploit a vulnerability before anyone else can identify it, patch it, and release a fix.

We discuss the fact that contact tracing via smartphones is a new, unsolved problem – and that, since the solution is based on technology that is not designed for this purpose (BLE, GPS), it is uncertain whether the problem can be solved in practice. We acknowledge that time is obviously a pressing concern in this project. Then we discuss the extent to which non-functional requirements such as security and privacy are considered at present, in light of what development phase the solution is in. It is claimed that the app is being tested in a select few municipalities, even though people all over the country are able to download the application and upload data in practice. We mention the importance of goals and hypotheses in the context of constantly reevaluating during development.


We find that neither security nor privacy is responsibly taken care of in the system as of May 18th 2020.

In the case of security, rectifying the use of a static identifier might have bettered security-aspects so much as lead us to another conclusion – but privacy concerns demands more, and larger alterations.


The group's recommendations include:

  • Clarifying the regulation which serves as basis for processing (changing "anonymized" to "deidentified"), to enable data aggregation in practice.
  • Split purposes, and allow users to choose how their data is used (split into several apps, or implement opt-in functionality). This might both protect users' interests and lead to more users.
  • Remove all data that is not needed (e.g. delete location data older than 15-16 days, delete location data without crossing trajectories at regular intervals) to increase data minimization.
  • Implement differential privacy in data aggregation processes, to reduce risk to privacy and increase accuracy of the resulting dataset.
  • Consider rewriting to a more distributed solution, post stabilized contact tracing criteria, as this could be both less invasive and lead to an increase in users.
  • Implement local differential privacy before uploading user data, to further decrease privacy impact.
  • Make as much source code as possible available as open source, to give the public real insight into how their data is used.
  • Regularly evaluate the solution, purpose and effect, to ensure that the solution is still suitable, and the problem is still relevant.

The original Norwegian report can be found here (PDF).

Newer post
Defining Privacy
Older post
Don't be Evil