« UK ICO COVID-19 コンタクト・トレーシング:アプリ開発におけるデータ保護の期待 | Main | Norway コンタクト・トレーシング・アプリ(smittestopp / Infection stop) »

2020.05.05

UK NHS COVID-19 appのテストバージョンのリリースとNCSCによる技術情報の公表。。。

こんにちは、丸山満彦です。

UKのNHSXが開発したCOVID-19 appの実証テストがワイト島 (Isle of Wight ) で始まりますね。。。それに合わせて、NCSCによるCOVID-19 appに関する技術情報が公表されていますね。

NCSC

・2020.05.04 (News) NCSC provides security expertise on NHS COVID-19 contact tracing app

・2020.05.04 (Report) High level privacy and security design for NHS COVID-19 contact tracing app

 ・2020.05.03 [PDF] High level privacy and security design for NHS COVID-19 Contact Tracing App (Version 0.1)

 ・[PDF] NHS COVID-19 app infographic (Decentralised vs Centralised)

・2020.05.04 (blog) The security behind the NHS contact tracing app by Ian Levy

・2020.05.04 (Information) NHS COVID-19: the new contact-tracing app from the NHS

----

(参考)

BBC News
・2020.05.04 Coronavirus: UK contact-tracing app is ready for Isle of Wight downloads b

Data Guidance
・2020.05.05 UK: NCSC publishes papers relating to its support to the NHS Coronavirus contact-tracing app

 まるちゃんの情報セキュリティ気まぐれ日記

・2020.05.05 UK ICO COVID-19 コンタクト・トレーシング:アプリ開発におけるデータ保護の期待

・2020.05.02 英国 NHSX(国民保健サービス・デジタル)はドイツ等と異なりApple-Google APIを使用せず集中管理方式の連絡先追跡システムにする?

・2020.04.27 少なくとも7カ国の政府を含むPEPP-PTの支援者は、プライバシー保護の「中央管理手法」をあきらめていない

2020.04.26 英国 NHSX(国民保健サービス・デジタル)が間も無くコンタクト・トレーシング・アプリをリリースするようですね。。。 

2020.04.17 COVID-19感染対策用のアプリケーションは位置情報を追跡する必要はない。。。 

2020.04.17 EU - データ保護に関連したCOVID-19パンデミック対策を支援するアプリケーションのガイダンス 

・2020.04.15 UK Information commissioner's officeがパンデミック時の規制に関する文書を公表しましたね。。。 

・2020.04.15 UKがCOVID-19の追跡アプリを独自に開発?

 

注目すべきは、High level privacy and security design for NHS COVID-19 Contact Tracing App (Version 0.1)

です。

目次は、

Contents
Disclaimer – versioning and documentation
About this paper
Introduction to the NHSx app
How the NHSx app works
App operation
Security and Privacy criteria
System architecture overview
App lifecycle
Reidentification risk
High level privacy and security criteria
Centralised vs Decentralised

-----

Security and privacy criteria

 We enforce the following high priority security and privacy requirements:

1) Minimise collection of personal data (ideally, no personal data should be collected).

2) Active user consent is required for any action involving collected data.

3) It should not be possible to track users of the app over time, through the Bluetooth transmissions.

4) It should not be possible for an external observer to associate any Bluetooth transmission with any device-specific information, over and above what they can infer through proximity (e.g. I can see that this ephemeral Bluetooth LE transmission value is linked to Alice’s device because I can see that Alice is the only person close to me).

5) It should not be possible to submit spoofed data on behalf of another user.

6) It should not be possible for the recipient of a notification to determine which of the people they have been in contact with has asserted symptoms.

7) The system must be tolerant to the actions of malicious users: a. Single user seeking to gain from a false self-diagnosis b. Malicious user seeking to cause mass notification in a given area (e.g. trying to shut down a hospital) c. Nation state actor seeking to cause panic through mass notification across the country

8) A malicious user must not be able to replay a notification of proximity from the service to another user.

These are not the only security and privacy promises we make, but seem to be the most important to explain early in the app’s development.

System architecture overview

The following actors and components exist in the system.

1) Users of the app

In our model, users have consented to have their proximity to other users recorded and we expect them to donate their data when they become symptomatic. Users may be malicious.

2) Devices on which the app is installed

3) The registration service

The registration service is used to register a particular installation of the app and to exchange installation-specific and global parameters. The registration service will provide a random, unique and anonymous InstallationID (a persistent pseudonym) and the registration process agrees a symmetric key between the device and the registration service. These are stored together in a database. The registration service also provides other system parameters, such as the server public key.

4) The data collection service When a user chooses to donate their proximity data to the system, they provide the data collection service with their event log, which contains anonymous pseudonyms that they have collected over Bluetooth LE. For each pseudonym, the data collection service can recover the underlying random and anonymous InstallationID.

5) The risk modelling service Given the proximity information (based on normalised Bluetooth LE received signal strength indicators), the risk modelling service can score each encounter in terms of risk of transmission of the virus, since not every proximity event will be equally hazardous. The risk model will be updated as epidemiological and clinical data becomes available.

6) The notification service Once proximity events have been scored as sufficiently risky, notifications will be generated for each relevant installation, based on the InstallationID. Notification queues will be modelled to ensure they do not have particular undesirable characteristics and then sent for delivery by the notification transport. In our instantiation, the notification transport is Google’s FireBase service, which operates across our target ecosystems.

7) The expert clinicians The clinicians are responsible for ensuring:

  • The risk scoring of contacts is based on an evolving view of the best transmission models available.
  • That the notification cascades make sense in the context of the virus transmission characteristics, enabling malicious events to be detected.
  • The efficacy of any restrictions on the population from the data provided by the system are understood.
  • The aggregate status of users is fed into health system resource planning (from the locality voluntarily provided by users).

In the NHS app, the infrastructure on which the various back end services operate is run in commercial public cloud, with the NHS in control of the code, deployment, operation and administration of the various infrastructure and services (either directly or through contracts).

In our model, the infrastructure provider and the healthcare service can be assumed to be the same entity.

 

|

« UK ICO COVID-19 コンタクト・トレーシング:アプリ開発におけるデータ保護の期待 | Main | Norway コンタクト・トレーシング・アプリ(smittestopp / Infection stop) »

Comments

Post a comment



(Not displayed with comment.)




« UK ICO COVID-19 コンタクト・トレーシング:アプリ開発におけるデータ保護の期待 | Main | Norway コンタクト・トレーシング・アプリ(smittestopp / Infection stop) »