Improved Computer Implementation of Anonymous Proximity Tracing

Abstract

a) providing a plurality of wirelessly capable participating devices 2, each having a non-interactive key exchange protocol interface including a private key generator and non-interactive key exchange protocol parameters; b) periodically using the private key generator at each of the participating devices to obtain a respective current private key, and calculating a respective current public key at each of the participating devices based on the respective current private key and the non-interactive key exchange protocol parameters, and each of the participating devices periodically wirelessly broadcasting its current public key; c) upon a first participating device detecting a respective current public key broadcast by a second participating device, at each of the first and second participating devices: i. calculating a current shared secret defined by the non-interactive key exchange protocol parameters and the respective current private keys of the first and second participating devices; and ii. calculating a current shared secret using a pseudo-random function parameterized with the current shared secret and applied to bucket values. and (iii) calculating a sort value determined by applying a total order function using two inputs known to both the first and second participating devices, and storing the first token in a first encounter token list of the first participating device and a second encounter token list of the second participating device based on the sort value, or storing the first token in a second encounter token list of the first participating device and a second encounter token list of the second participating device based on the sort value; and (d) selectively uploading, by a given participating device, at least a portion of either the first encounter token list or the second encounter token list to a proximity management server upon detection of an upload condition by the given participating device.

Description

[Technical field]

[0001] The present invention relates to the field of proximity tracing, and more particularly to a computer-implemented method for anonymous proximity tracing. [Background technology]

[0002] With the proliferation of mobile devices and the development of low energy protocols, proximity tracking has become one of the prominent development areas. With the emergence of beacons, many technological use cases have arisen from the retail and logistics industries, etc. The outbreak of the COVID19 pandemic has only reinforced this trend.

[0003] The biggest challenge with all proximity tracking applications is balancing the quality of the information with the essential need to guarantee privacy to prevent misuse. This has led to the development of two main approaches:

[0004] One is usually called "centralized" while the other is usually called "decentralized". The distinction is based on the presence or absence of a server. Although a first reflex might be that "serverless (or near-serverless)" is considered more secure in terms of privacy, highly counterintuitively, these solutions are actually more dangerous since they replicate all data for all users across the entire user population, and they are data-hungry, indeed hugely so, since they require sending large amounts of irrelevant data to most users.

[0005] For this reason, the applicant considered "centralized" approaches in which a server ultimately collects some information from users. As a first approach, the applicant proposed an anonymous proximity tracking method named "ROBERT" (ROBust and privacypresERving proximity Tracing) in Non-Patent Document 1, a paper published on April 18, 2020, accessible at https: / / github.com / ROBERT-proximity-tracing / documents.

[0006] ROBERT1.0 relied on the assignment of temporary identities to users by a centralized server, the storage of these temporary identities by other users when their devices were in close proximity to the device of the user possessing this temporary identity, and the uploading of a list of "met in proximity temporary identifications" by users when they were diagnosed with COVID 19. In this way, the centralized server does not store any personal data about users, and users can recognize that they have been in close proximity to a COVID 19 positive person by checking whether one of their temporary identities is listed on the centralized server.

[0007] Although this approach is interesting, there is room for improvement, especially to reduce the role of the server in the protocol and make it as "serverless (or nearly serverless)" as possible. [Prior art documents] [Non-patent literature]

[0008] [Non-Patent Document 1] “ROBERT: ROBust and privacypresERving proximity Tracing”, published on April 18, 2020 Summary of the Invention

[0009] The present invention aims to improve the situation. To this end, the Applicant presents a computer-implemented method for anonymous proximity tracking, comprising: a) providing a plurality of wireless communication enabled participating devices, each having a non-interactive key exchange protocol interface including a private key generator and non-interactive key exchange protocol parameters; b) periodically using the private key generator at each of the participating devices to obtain a respective current private key, and calculating a respective current public key at each of the participating devices based on the respective current private key and the non-interactive key exchange protocol parameters, and each of the participating devices periodically wirelessly broadcasting its respective current public key; c) upon detection by the first participating device of the respective current public keys broadcast by the second participating device, at each of the first participating device and the second participating device: i. calculating a current shared secret defined by the non-interactive key exchange protocol parameters and the respective current private keys of the first participating device and the second participating device; ii. calculating a first token using a pseudo-random function parameterized with the current shared secret and applied to a first value associated with the first participating device, and calculating a second token using the pseudo-random function parameterized with the current shared secret and applied to a second value associated with the second participating device; iii. calculating a sorting value by applying a total ordering function using two inputs known to both the first participating device and the second participating device, and storing the first token in a first encounter token list of the first participating device and a second encounter token list of the second participating device based on the sorting value, and storing the second token in the second encounter token list of the first participating device and the first encounter token list of the second participating device, or storing the first token in the second encounter token list of the first participating device and the first encounter token list of the second participating device, and storing the second token in the first encounter token list of the first participating device and the second encounter token list of the second participating device; d) selectively uploading, by a given participating device, at least a portion of one of the first encounter token list or the second encounter token list to a proximity management server upon detection of an upload condition by the given participating device; The present invention proposes a method comprising the steps of:

[0010] The method is advantageous because the Proximity Server is used only as the final repository of the results of the proximity interaction. Furthermore, due to the nature of the token, the Proximity Server is completely anonymous (blind) to the user and the user's device; only the two devices involved in the generation of the token can participate in it without knowing each other. No irrelevant data is spread to the user, and the user only stores anonymized data that reflects only their proximity encounter. Finally, since public keys are generated locally within each device, the resulting protocol ("ROBERT v2") can be considered "serverless (or nearly serverless)" and even decentralized.

[0011] In various embodiments, the method may provide one or more of the following features. the total ordering function calculates the sort value by comparing values ​​derived from the respective current public keys of the first participating device and the second participating device; Step d) includes uploading tokens from the first encounter token list; The method comprises: e) periodically transmitting at least one token from the second encountered token list to a reporting server for each of the participating devices, and when the reporting server detects that another participating device has uploaded a token from the first token encounter list of the other participating device that is identical to the at least one token from the second encountered token list, the reporting server transmits a message to the participating device that issued the second encountered token list to the reporting server indicating the detection of the upload of the identical token; The method comprises: f) for each participating device, periodically sending at least one token from the second encounter token list to the reporting server, and calculating a risk score based on a comparison of the at least one token from the second encounter token list with the tokens uploaded by other participating devices from the first encounter token list; The non-interactive key exchange protocol is based on Curve25519, another elliptic curve, the Elliptic-curve Diffie-Hellman protocol, or the Diffie-Hellman key exchange; Metadata regarding the colocation of the first participating device and the second participating device is stored along with the first token and the second token in one of the first encounter token list and the second encounter token list.

[0012] The invention also relates to a computer program comprising instructions for carrying out the method according to the invention, a data storage medium having said computer program recorded thereon, and a computer system comprising a processor coupled to a memory having recorded thereon the computer program according to the claims.

[0013] Other features and advantages of the present invention will become readily apparent in the following description of the drawings, in which: The drawings illustrate exemplary embodiments of the invention. [Brief description of the drawings]

[0014] [Figure 1] 1 is a schematic diagram of a system for implementing the method according to the invention; [Diagram 2] 1 is a general diagram of an exchange between two devices implementing the method according to the invention; [Diagram 3] FIG. 3 is a time diagram showing the data exchange following FIG. 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] The drawings and the following description are, for the most part, composed of useful and clearly defined features, and as a result, they are not only useful in understanding the invention, but can also be used to contribute to the definition of the invention when the need arises.

[0016] This specification may refer to or use copyrighted or copyrightable material. Applicant has no objection to the reproduction of these materials, subject to required legal disclosure restrictions, but this should not be construed as a waiver of any rights or license.

[0017] The new version uses the same architecture but brings major improvements. In particular, it presents the concept of a private encounter token (PET) generated with a secret cryptography. Furthermore, a temporary identifier broadcasted on the Bluetooth interface is now generated by the mobile device, giving the user more control. Finally, all data stored by the server is now encrypted with a key stored in the mobile device, protecting against data leakage at the server. All these changes dramatically improve the scheme privacy against malicious users and authorities. As in the first version of ROBERT, risk scores and notifications are still managed and controlled by the server and therefore by the health authorities, which provides high robustness, flexibility and efficiency.

[0018] 1 Introduction 1.1 Private Encounter Tokens (PETs) Different from existing proximity tracking schemes, we propose an exposure notification system based on Private Encounter Tokens (PETs) generated from Ephemeral Bluetooth Identifiers (EBIDs). EBIDs and PETs are generated and computed locally by mobile devices and are unlinkable. A PET identifies an encounter between two nodes and is secret only to these nodes (no one else can compute it). The creation of a PET is based on the Diffie-Hellman (DH) key exchange protocol.

[0019] For simplicity and ease of reading, in the following we refer to multiplicative DH notation. However, for efficiency reasons, we propose to implement it using an instance of discrete logarithm on elliptic curves (also known as Elliptic-curve Diffie-Hellman or ECDH) using Curve25519 (details on Curve25519 can be found at https: / / en.wikipedia.org / wiki / Curve25519). We assume that the devices share the same group structure (order p and generator g), which can be pre-configured in the application.

[0020] At each epoch i, Device X is g Xi Here, Xi is a secret generated by X. Using elliptic curve cryptography and the elliptic curve Curve25519, g Xi requires 32 bytes, which are transmitted in two consecutive Bluetooth packets (see section 5.3 below). Device Yi to EBID, g Yi Upon receiving this, device X will Xi*Yi , store this in a local list, and obtain the PET H(K), where H() is a cryptographic hash function such as SHA-256. This PET is a unique secret identifier for the encounter between X and Y. ·PET H(K) can only be computed by X and Y and is therefore protected from eavesdroppers. This is guaranteed by the Deterministic Diffie-Hellman (DDH) assumption. PET has the advantage over EBID that it reduces the server's ability to link collocation information coming from different individuals. Furthermore, this method mitigates "replay attacks" where a malicious individual collects EBIDs received by infected (or potentially infected) individuals and replays them in many locations, thus generating a large number of false positives.

[0021] It is worth noting that the PET token is not specific to pandemic applications and could benefit all other existing proximity tracing proposals.

[0022] 1.2 Protocol Overview All notations used in this document are summarized in Table 1 below. The proposed system is shown in Figure 1 and includes a user 2 who installs an exposure notification application (called "App") that uses ROBERT v2, and a backend server 4 (hereafter called the reporting server) under the control of a health authority. It is assumed that the server is configured with a known domain name, a certificate and is highly secured.

[0023] [Table 1]

[0024] All communication with the server is done through a proxy (to hide the user's network metadata that may be used by the server to re-identify the user). Apps interact with the system through at least the following four steps: Initialization: When a user wants to use the service, he installs an application App from an official trusted app store. The App then registers with the server 4 which generates a permanent identifier (ID). The IDTable (see Table 1) holds an entry for each registered ID. The stored information is "de-identified" and never associated with a specific user. In other words, no personal information is stored in the IDTable. Proximity discovery: After registering with the service, each device A A new unlinkable EBID each epoch A Generate This EBID A Broadcast periodically, Collect the EBID of the device encountered, Generate a PET token from the collected EBID if certain conditions are met, e.g., contact length, received signal strength, etc. · Store the generated PET tokens in one or more local lists, possibly together with additional metadata (contact length, speed, ...). Infected user declaration: When an individual is tested and diagnosed as COVID19 positive, and after explicit user consent and authentication (e.g. from a medical service), the app on the user's smartphone uploads his local list to the institution's server (hereafter the reporting server), which adds these to the global list of exposed PET tokens, EList. Exposure Status Request: The App queries the “exposure status” of its associated users by periodically probing the reporting server with its own list of PET tokens (pull mechanism). The reporting server then checks how many of the App’s tokens appear in the EList and calculates a risk score from this information (and possibly other parameters such as exposure duration and signal strength). If this score is greater than a given threshold, a bit “1” (synonymous with “at risk of exposure”) is returned to the App, otherwise a bit “0” is returned. On receipt of the message “1”, a notification can be sent to the App’s user indicating instructions to follow (e.g. to go to the hospital for a test, to call a specific phone number, to stay in a quarantine facility, etc.).

[0025] FIG. 2 shows a schematic diagram of the exchanges that take place during the proximity discovery procedure described above and is explained in more detail in Section 2.2 below.

[0026] First, device A has EBID=g A Device B broadcasts EBID g B Then, broadcast EBID g B When device A detects PET1=H(“1”|g B*A ) and PET2 = H("2" | g B*A ) and PET1 is detected by RTL A and store PET2 in ETL A Device B stores the PET1=H("1"|g A*B ) and PET2 = H("2" | g A*B ) and calculate PET2 as ETL B and store PET1 in RTL B According to various embodiments, PET1 is stored in the ETL A or RTL A (Each ETL B or RTL B ) may be based on a determination of a sort value, which will be further described below.

[0027] The ROBERT v2 protocol assumes that all smartphones and servers are loosely time-synchronized (by NTP, which stands for Network Time Protocol, or other time synchronization mechanisms such as cellular mobile phone network information or GPS time information, etc.). Time is expressed as an NTP "seconds" value, which represents the number of seconds since midnight, January 1, 1900 UTC, for era 0. Time is discretized into epochs (e.g., 15 minutes, but other values ​​are possible depending on the proximity discovery protocol and the application pursued, i.e., the meaning attached to the detected encounter). In the following, the variable "epoch_duration_sec" specifies the duration of an epoch in seconds. In the example described herein, the epoch is synchronized with the MAC address randomization period.

[0028] 1.3 Risk Scoring and Notification Considerations A particular effective risk scoring is outside the scope of this specification. In the examples described here, it is assumed that (1) the server returns a binary answer informing the user whether the user is at risk or not, and (2) the answer is based solely on the calculated risk score value. These two assumptions need to be discussed. For several reasons, it may be useful to return a probability value instead of binary information. Furthermore, adding some randomness in the query-answer mechanism can improve privacy (see Section 5.2 below).

[0029] It is further assumed that the risk assessment algorithm and its parameters should be defined and monitored by health authorities in collaboration with epidemiologists. In the case of pandemic applications, it is also paramount that authorities are able to adapt the algorithm and its parameters over time. These adjustments must take into account the evolution of the situation, in particular the number of exposed and infected persons, the available resources and the progress made by epidemiological studies to understand the virus and its spread. Indeed, a key success factor for proximity tracing applications is a smooth integration within the existing healthcare infrastructure, in particular being able to adapt the response to the local epidemiological situation and the available resources. This requires a system in which the exposure risk scores and notifications are managed by a reporting server. The same applies to other technological cases related to the retail or logistics industry.

[0030] The main driver of the approach presented here is that it allows health services to analyse the data and send alerts only to those at highest risk of being infected.

[0031] A key challenge is the subsequent management of alerts within the existing proximity tracing framework (including manual contact tracing, testing, quarantine, etc.). If the infrastructure is not large enough and equipped to handle all alerts, proximity tracing applications can be useless, anxiety-inducing (due to lack of care for individuals), and economically devastating (through the rapid but unnecessary withdrawal of essential workers). A "centralized" approach to risk assessment and notification makes it possible to avoid excessive alerts that can lead either to a panicked response from users or to a loss of interest or trust.

[0032] Another advantage of the central role of the server is that it increases the resistance of the system to attackers trying to identify infected users. In summary, digital proximity tracing tools should be deployed as an element of public health policy and should work in synergy with other existing measures under the control of public health authorities. This is an essential functional requirement of any real pandemic or health care-related exposure notification solution that seems incompatible with a truly decentralized approach. More precisely, in a decentralized approach, as an example, where the risk calculation algorithm is calculated on the user's device, the health authority does not know the number of exposed persons. This information is important both for statistical purposes alone and to be able to adjust the risk calculation algorithm in a practical manner.

[0033] 2. ROBERT v2 Protocol Description 2.1 Application Initialization Users 2 who wish to install the application on their device must download it from the official Apple or Google Play Stores. A After installing, User 2 needs to register with the backend server.

[0034] The registration phase consists of two stages: authentication token generation, where the user obtains an anonymous authentication token, and user registration, where the user anonymously registers with the server.

[0035] As will be explained below, these stages are unlinkable and provide complete anonymity to the user. 1. Authentication Token Generation: Step is used by the user to obtain an anonymous authentication token to be used during the user registration and exposure status request phase. This can be done by using blind signatures, as described in Section 5.1 below. Note that although the user reveals his / her phone number (to verify that there is only one application App per smartphone, to limit Sybil attacks), the server cannot link the user's phone number with the generated authentication token. 2. User registration: User 2 registers with authentication token AT A Once we have this, we can register it with the server. This can be done as follows: a) User 2 receives his authentication token AT A Send a registration message containing the b) The server validates the authentication token and returns a unique identifier ID A and creates an entry in that IDTable. In the example described herein, the entry table contains the following information for each registered user: -ID A ("Permanent IDentifier for A"): A randomly generated identifier (random selection process with no replacement to avoid collisions) that is unique to each registered app. -UN A ("User A Notified"): This flag indicates whether the associated user has already been notified (associated value of "True") of being at risk of exposure (associated value of "False"). A is initialized with the value "false". -SRE A (Status Request Epoch) (SRE): An integer indicating the last epoch in which User 2 sent a Status Request. -LEPM A(List of Exposed PET Metadata (LEPM)): This list reflects the user's exposure (time and frequency information) and is used to store metadata needed to calculate the risk score (e.g., duration and proximity of exposure to a person diagnosed with COVID19 positive). In this version of the protocol, each element encodes the date the user came into contact with a user diagnosed with COVID19 positive, and the duration of that encounter. The information contained in this list can be expanded to include other types of data useful for calculating the risk score, such as information about the environment (indoor or outdoor), signal strength, ... -ERS A ("Exposure Risk Score" (ERS)): The exposure risk score of the current user. c) Server: i.Encryption key EK A Generate ii.ID A , E.K. A to User 2 iii.EK A Use ID A excluding IDTable[ID A ], where it is advantageous to use an authenticated encryption scheme. iv.EK A Delete

[0036] The server also stores all received AT tokens to verify that they are used only once. Alternatively, the server can generate authentication tokens AT that are valid for only a certain number of days (e.g., by periodically changing its public / private key pair), which allows reducing the storage load on the server.

[0037] 2.2 Encounter discovery Each node A stores two tables: the exposed token list ETL A and the request token list RTLA maintain.

[0038] At each epoch of a given date, i, node A 1.A i-1 and EBID A,i-1 Delete 2.A i Randomly select EBID A,i =g Ai Calculate 3.EBID via Bluetooth A,i Broadcast periodically, 4. RTL by removing outdated elements, i.e. elements that were included before the CT date A and ETL A Advantageously, in the examples described herein, CT is the length of the infectious period (usually 14 days).

[0039] Upon each encounter with node B, node A: 1. Encounter B to EBID B,i =g Bi Collect. 2. If the encounter satisfies some predefined conditions, node A a) Duration of the encounter t A,B Calculate b) Two separate PETs are calculated. PET1 i =H(「1」|g Ai*Bi ) and PET2 i =H("2"|g Ai*Bi ) c) (bit string g Ai is the bit string g Bi If the PET1 i RTL A Then, store the tuple (PET2 i ;t AB ;day) to ETL A Store in. d) Otherwise, node A will use PET2 i RTL A and store the tuple (PET1 i ;tAB ;day) to ETL A Store in. 3.g Bi Delete

[0040] As shown above, device A encodes each encounter with device B into two PETs, PET1 and PET2, which are stored in two different lists, ETLs. A and RTL A PET1 is stored in the PET1 register as a parameter a value for device A (here, “1”) and a shared secret g Ai*Bi PET2 is generated by applying a function H() using the parameter Ai*Bi On the other hand, device B will generate exactly the same encounter token. Step c) is done by applying function H() with g to ensure that both device A and device B know how to distinguish between the generated tokens and to which token list they should be uploaded. Ai and g Bi This comparison constitutes a total ordering function, meaning that both devices can perform the same type of ordering without the need for any synchronization.

[0041] As described below, one of the lists (RTL A ) to query the reporting server about exposures, while the other (ETL A ) is uploaded to the reporting server if the user of device A is diagnosed with COVID19 positive.

[0042] These two lists are for the same encounter, and are the list ETL for device A. A Each token in the list RTL of device B BThus, if the user of device A is diagnosed with COVID19 positive, user B can create a list RTL to be notified of close encounters with people who have been diagnosed with COVID19 positive. B At the same time, the report server can be polled with a token from the list ETL A and RTL A Since the tokens in the list RTL cannot be linked together (except by device A), the reporting server must use the list RTL in the ESR_REQ request. A A polling token from the list ETL A By comparing the tokens of the list ETL with those of the list A, the anonymity of user A is prevented from being taken away. Without this protection, the reporting server could use these links to A We can then reconnect the tokens together and derive the proximity graph for the user of device A.

[0043] In general, at time t b From EBID B It is in contact with another device B which broadcasts EBID A Device A broadcasts the e New EBID, EBID A,i +1, or when device A starts using f EBID over a selected duration (this value is a parameter) B If device B stops receiving EBID, it generates a new PET token. B EBID B,i From EBID B,i+1 , or when device B moves away from device A or is temporarily behind an obstacle.

[0044] Various circumstances may lead the device to generate several PETs for a single successive close encounter, and the present invention allows control of this situation.

[0045] Figure 3 shows the various PETs that can be generated by two devices A and B taking into account the above rules and a loose time synchronization between devices A and B. This makes it possible to understand the extent to which the present invention enables anonymous proximity detection in a truly decentralized context.

[0046] In this figure, device A has a current of g at time T0. A Device A starts broadcasting the PET. Device A encounters device B at time T0+t0. At time T0+t0+t1, device A changes its EBID. As a result, device A receives the PET A,1 H(g B*A ) and stores it together with its duration t1. Similarly, at time T0+t0+t1, device B generates g A Therefore, PET B,1 H(g A*B ) and stores it together with its duration t1. Then, when device B changes its EBID at time T0+t0+t1+t2, device B stores the PET B,2 H(g A ' *B ) and stores it together with its duration t2. Similarly, at time T0+t0+t1+t2, device A generates a PET A,2 H(g B*A ') and stores it together with its duration t2, and so on until the encounter between device A and device B is completely finished at time T0+t0+t1+t2+t3+t4.

[0047] 2.3 Infected Device Declaration If User 2 is tested at a hospital or medical institution and diagnosed as COVID-19 positive, AIt is proposed to upload each element of the list to the server. For example, a possible solution is that User 2, upon being diagnosed with COVID19 positive, gets an authentication code from a hospital or medical institution. Then, User 2 can use this code to get N anonymous authentication tokens, where N is the ETL of User 2. A The tokens are the number of elements in the list (see Section 5.1 for an example). User 2 then uses these tokens to execute the ETL A Each of the elements can be uploaded to the reporting server one by one. A The specific interactions between the user 2 and the health authorities will not be described in detail here as they vary from one health system to another and do not form the core of the invention. Advantageously, this upload is done anonymously and in particular does not reveal the identity of user 2 or any of its EBIDs to the reporting server.

[0048] If preventive measures are insufficient, ETL A The upload of could potentially be used by the reporting server to build a de-identified social / proximity graph of users 2 who have tested positive for COVID19. The aggregation of many such social / proximity graphs could, under some conditions, lead to the de-anonymization of the nodes, resulting in the social graph of the user. ETL A Instead of doing a single step upload of A To "break" the link between any two elements of, the invention proposes to upload each of its elements independently and in a random order. To achieve this, different solutions can be envisaged. ETL A Each element of is sent to the server one by one, either by using Mixnet or a proxy. As a result, the uploads are spread out over a long period of time, and the reporting server cannot associate them with a specific ETL. ETL Aare uploaded to a trusted server (e.g. in a hospital or health organization), which mixes the elements from the different ETLs and proceeds to upload them to a reporting server, which can then access the exposed entries only through a specific API provided by the trusted server. The reporting server is equipped with a secure hardware module that handles the ETL uploads, and the reporting server only has access to exposed entries via specific APIs provided by the secure hardware module.

[0049] For this, the reporting server maintains a global list EList of all exposed tuples (token;day;t) coming from all users who have tested positive for COVID19. Devices periodically flush irrelevant data, thus ensuring that only relevant tokens are uploaded to the reporting server. Alternatively, the reporting server could periodically flush tokens once they are no longer relevant.

[0050] 2.4 Exposure Status Requests To check whether User 2 is “at risk”, i.e., whether User 2 has encountered an infected and / or contagious user on the most recent CT date, application App A ID A The user periodically sends "exposure status" requests (ESR_REQ) to the reporting server of the user's device. For example, these queries are sent periodically, at most every ESR_min epochs. For example, if a user is allowed to make N queries per day, ESR_min is defined as T=86400 / (N*epoch_duration_sec). The reporting server then calculates a "risk score" value. The reporting server replies with an ESR_REP message that is set to "1" when the "risk score" is greater than a threshold, indicating that the user is "at risk", and is set to "0" otherwise.

[0051] This can be done, for example, as follows: 1. Device A transmits the ID via the TLS proxy. A , E.K. A , and RTL A ESR_REQ containing some or all of the PET tokens A,i A message is sent periodically to the reporting server. 2. The reporting server uses IDTable[ID A ] and each of its elements is A Use the following to decrypt it. 3. The reporting server uses i-SRE (to limit the number of daily requests made by each user). A ) is lower than a threshold ESR_min, where i is the current epoch number. If so, the server returns ESR_REP A,i The server then returns the EK A Using IDTable[ID A ] and encrypt each element of the EK A Clear, else continue. 4. Reporting server is UN A Verify the flag. UN A If ESR_REP is set to "true", the reporting server will use the same ESR_REP A,i An application App that has already been notified that the user is at risk of exposure may return an ESR REQ to ensure that the traffic of this application is indistinguishable from the traffic of other users' applications when observing network traffic. A,i It is good practice to continue sending messages and receiving valid responses. The server then A Using IDTable[ID A ] and encrypt each element of the EK A Clear, else continue. 5.Then, the reporting server sends the RTL AThe server checks whether any of the PET tokens in appears in any tuple (token;day;t) in the EList. If so, the server removes the matching tuple from the EList and stores all (day;t) pairs in the IDTable[ID A ]LEPM A Add to list. 6. The reporting server calculates the exposure risk score for user 2 and stores it in IDTable[ID A ](Field ERS A Alternatively, the reporting server can store the RTL token generated in the last CT in the IDTable. This saves some bandwidth since a given device only needs to send a "new" token each day in its ESR_REQ queries. In addition, this improves security in devices that only store daily tokens locally. 7. At this point, two situations are possible. a) If the calculated risk score indicates that the user is at risk of exposure, the server flags A to "true" and ESR_REP set to "1" (indicating that the user is at risk of exposure). A,i The message is returned to User 2. b) If the calculated risk score does not indicate any significant risk, then ESR_REP is set to "0". A,i The message is returned to User 2. 8. After sending the response message, the reporting server A Using IDTable[ID A ] and encrypt each element of the EK A Erase. 9.ESR_REP A,i If is set to "1", User 2 can A The patient receives a notification from the health department with specific instructions (e.g., to go to a hospital to get tested, to call a specific number, or to continue isolating).

[0052] For a given user with device A, the uploaded list ETL A and required RTL A Since the PET tokens used in are different for the same encounter, the server cannot link these elements and cannot build any adjacency graph.

[0053] Furthermore, the only information leaking from the request is the number of elements, which is A One solution is to set the number of elements in the request to a fixed value T. A Number of elements in N A If is less than T, App A The request (TN A ) fake tokens. The number of elements N A If is greater than T, App A Regarding that request, RTL A Other variants use only T elements of RTL A This may include encoding the elements of into a Bloom or Cuckoo filter.

[0054] 2.5 Managing Notified Devices When a device is notified that its user is at risk, the UN A The flag is set to true in the IDTable. From now on, the reporting server processes its ESR_REQ queries as normal, but continues to reply with ESR_REP messages set to "1", regardless of the outcome of the ESR_REQ.

[0055] When set to "At Risk," notified device users have several options. -The User is tested and diagnosed as COVID-19 positive. In that case, the User must create its own ETL as described in Section 2.3. A You can upload the list. Independently, the user can provide the server with an identifier ID A The ETL may be notified through a specific protocol (not specified herein) that a person has tested positive. A This is done separately from list uploads and cannot be linked together (reporting servers must provide IDs). A (It is not possible to identify PET tokens uploaded by the public.) This information is essential for health authorities to calibrate their risk score functions. -The user is tested and tests negative for COVID-19. The user reports to the reporting server the identifier ID A The user may be notified via a specific protocol (not specified herein) that he / she has been tested and found to be negative. As a result, the UN A The flag is reset to "false." - The user decides not to take the test or not to inform the reporting server about his test. In that case, the user's "at risk" status can be reset after a certain fixed period of time (3-4 days, value to be defined).

[0056] In either case, applications that are notified as "at risk" continue to send and receive EBID and calculate PET. This is needed, for example, while the user is waiting for test results. If the user is found to be negative, the encounter continues to be recorded and an updated exposure status can be calculated without any gaps in the history as soon as the user unlocks their status in the reporting server.

[0057] Users who test positive should have the option to continue using the application as long as they are contagious. During this period, the user must periodically upload their ETL list to the server.

[0058] Of course, the above procedures may be reviewed by epidemiologists and health authorities and are therefore subject to change.

[0059] 3 Privacy Protection 3.1 Server data breach The server stores only pseudonymous data. In addition, this information is minimized and is only used to calculate the exposure risk score. Furthermore, each entry in the IDTable of device A stores the key EK A is encrypted with the key EK A is stored only on device A and provided to the reporting server together with the ESR_REQ query.

[0060] As a result, in case of a data breach of the server, all useful information is encrypted. The risks associated with the data breach are then minimal.

[0061] 3.2 Passive eavesdropping / tracking (by malicious users and institutions) Since PET tokens are unique for each encounter and are calculated locally, a passive eavesdropper only obtains the EBIDs, which change every epoch. Furthermore, if an institution deploys several Bluetooth receivers, it will be difficult to guess the exact EBID for any EBID (i.e., g Ai ) cannot be associated with any PET token. Therefore, passive tracking by the server or the user is not possible.

[0062] 3.3 Active eavesdropping / tracking (by malicious users) Active eavesdropping / tracking by users is not possible.

[0063] 3.4 Active eavesdropping / tracking (by malicious parties) The institution is active, e.g. Z If we deploy a Bluetooth device that also broadcasts its own unique EBID containing A*Z ) and H("2"|gA*Z The reporting server device can also generate the same token that the server can use to identify the target ESR REQ message and possibly track some of its location. The device's ESR_REQ query will include (the user's ID A With enough of these tracking devices, the server could potentially re-identify some users because the tracking devices are linkable (including the

[0064] 3.5 Reconstructing the Social Interaction Graph (by Malicious Authorities) When the user of device A is diagnosed with COVID-19 positive, the user’s ETL, as explained above, A All elements of are uploaded independently and anonymously. As a result, the reporting server cannot create a link between the user and the uploaded PET tokens, nor between the uploaded PET tokens themselves.

[0065] When a user of device A queries the server about its exposure status, the server appends the ID to all PET tokens included in the ESR_REQ query. A However, the PET token used in the ESR_REQ query is different from the token that would be uploaded to the reporting server if the user of device A were to undergo a diagnosis. As a result, the reporting server cannot infer any link between the exposed token in its EList and the token in the exposure request.

[0066] Furthermore, two users of respective devices A and B who have exchanged EBIDs and built associated PET tokens will do so with different tokens when making requests to the server with exposure requests, which prevents the reporting server from linking the tokens in these requests.

[0067] 3.6 Re-identification of infected devices (by malicious users) Users cannot identify infected contacts because this information is kept on the server and users only get their own exposure risk score. However, the "one-entry" attack inherent in all schemes is still possible.

[0068] In such an attack, the adversary selects User T (This can be easily achieved by turning off the Bluetooth interface, switching it on when the adversary is in the vicinity of his victim, and then switching it off again.) Once the adversary is notified that it is “at risk”, it will T Learn that a person has tested positive for COVID-19.

[0069] This attack can be mitigated by: - Requiring users to register to limit Sybil attacks. - Limit the number of requests each node can make per day, and further limit when users are notified that they are at risk. This countermeasure limits the scale of the attack. - Using the probability notification scheme as presented in Section 5.2. Sending an ESR_REP that is set to "1" only if the requesting user's number of exposed tokens is strictly greater than one. - Have the server verify that the request contains at least N tokens before providing the reply "1". However, this countermeasure does not stop an adversary from using fake tokens together with the target token.

[0070] 3.7 Replay Attacks This is not possible because the communication is assumed to be symmetric. For example, if a malicious device E Cto device A, device A calculates and stores the corresponding PET1 and PET2. However, device C does not have these values ​​in its RTL and ETL tables.

[0071] 3.8 Relay Attacks This is only possible within at most one epoch.

[0072] 3.9 False Alert Injection Attacks Poisoning is an attack in which a malicious node colludes with a diagnosed user to include the identifiers of several victims in the user's contact list. The goal of the malicious adversary is to cause false alerts in the target victim's app.

[0073] This attack requires the colluding user and the victim to interact in order to calculate their PET, and therefore such an attack is only possible via a relay attack.

[0074] 4 Stateless version of ROBERT v2 As shown above, in ROBERT v2 the reporting server stores some information about registered users. This information is minimal and stored securely. The applicant has found this feature to be a strength of the inventive scheme, as it allows to mitigate some attacks, for example by controlling the number of registered users and limiting the request frequency.

[0075] This feature also allows health authorities to calculate and update risk scores as the situation evolves, providing them with information about user exposure that can be highly valuable for optimizing risk score functions, as discussed in Section 1.3. In other technology cases, this feature allows the system to more easily adapt to evolving paradigms.

[0076] However, it is possible to transform ROBERT v2 into a state-less system, where the reporting server is simply a "matching machine" between the ETL list PET tokens uploaded by users who have tested positive for COVID19 and the RTL list tokens included in the ESR_REQ query.

[0077] The protocol can then operate as follows. - Application Initialization A user does not need to register with the server. A user only needs to obtain CT different anonymous authentication tokens per day. Each of these authentication tokens should only be valid on a specific day and can be obtained in batches during registration. For example, a user may obtain CT tokens per day (different for each day, d i , d i-1 , d i-2 ,...tokens available today, d i+1 , d i , d i-1 For each role in the token, a specific signing key is used. This is the same vein as is done in the online electronic cash scheme "a la Chaum" using blind signatures. - Encounter Discovery Similar to the ROBERT v2 protocol described above. -Infected device declaration Similar to the ROBERT v2 protocol described above. -Exposure Status Request Users query the reporting server using non-linkable ESR_REQ queries, each of which has a different RTL. A Each ESR_REQ query may, for example, contain PET tokens generated during the same day. In this case, each day d i In, the user may generate CT distinct unlinkable ESR_REQ queries (one for d iContains the generated tokens, one for d i-1 Contains the generated tokens in ..., one for d i-CT The generated token is included in the request.

[0078] The reporting server processes each of these ESR_REQ queries independently by checking whether any tokens included in the request appear in the list EList of exposed tokens, and then calculates a resulting exposure risk score for each request and sends the results back to the requesting device.

[0079] Note that with this extension, the reporting server can no longer calculate a "global" exposure risk score for the user, but only non-linkable "daily" risk scores. The device gets CT different risk scores (for days prior to the different CT days) that need to be aggregated into a global score. This also implies that every app must include an aggregation function that may need to be updated periodically.

[0080] Finally, it is also possible to completely decentralize the risk assessment by publishing the exposed PET token contained in the server's EList to all phones. The resulting scheme is then very similar to so-called "decentralized" approaches such as DP3T. However, the applicant has found this approach unsatisfactory in terms of reducing the resistance to re-identification of infected devices. Furthermore, this complete decentralization of the risk score calculation may lead to the generation of many uncontrollable notifications. This may have a dramatic impact on the population, reducing trust in the system and, as a consequence, its adoption rate (see section 1.3 above).

[0081] 5. Appendix 5.1 Authentication Token Generation Assume the server has an RSA certificate with public key (e,n) and private key (d,n).

[0082] The following is done using a TLS proxy channel: User------>phone_number------>Server The server calculates ID=H(phone_number) and checks that the ID does not exist. The server sends the code PIN to the user via SMS. The SMS is used to verify that the user owns the phone number and thus the device. Note that the PIN code can be obtained via another mechanism if the user does not have a SIM card. For example, the PIN code can be delivered by a doctor or a medical institution, for example via email. The user generates two random values ​​c and R, and e Calculate .H(R)(mod n) and send the following: User------>PIN,c e .H(R)(mod n)------>Server The server verifies the PIN and returns REP=(c e .R) d =c:H(R) d Calculate (mod n). User<------REP=cH(R) d (mod n)<------client The user calculates Sigma = REP / c = H(R) d Calculate (mod n) and obtain the authentication token (R, sigma). The server removes the phone number and the REP.

[0083] The user can then prove that he is a registered user by using his authentication token when sending the ESR_REQ or during the registration phase.

[0084] However, note that although the user reveals his / her phone number to verify,that there is only one application per smartphone to limit,Sybil attacks, the server cannot link the user’s phone number,with the generated authentication token since it is not possible to link,the token (,R,sigma,) to an arbitrary phone number.

[0085] It should be noted that a user who uninstalls an application will not be able to register a new application later. If this is a problem, a solution is to authorize a limited number of user registrations per phone number (i.e., 2 or 3).

[0086] 5.2 Probabilistic Notification As described in the paper "Analysis of DP3T" by Serge Vaudenay, Cryptology ePrint Archive, Report 2020 / 399, 2020, all proximity tracking schemes are vulnerable to "one-entry" attacks.

[0087] As explained in Section 3.6 above, in this attack, the adversary T When an adversary is notified that there is a risk, T Learn that a person has tested positive for COVID-19.

[0088] As described in Section 3.6, ROBERT v2 proposes several mitigation measures.

[0089] Applicants believe that the only way to thwart this attack is to use probabilistic notification to introduce some "deniability." In such a scheme, a server receiving an ESR_REQ message replies with: If the user's ID is not in the list of exposure IDs, then "0" (i.e., no risk); "1" if the user's ID is in the list of exposed IDs or is randomly selected by the server (the server is configured to select additional users who should receive a "0" response, with probability p receiving a "1" response).

[0090] As a result, when a user receives a "1" response, he does not know if it is due to him being exposed or if it was randomly selected by the server. Since the user can no longer query the server (due to having already received a "1" response), he cannot send additional requests to refine the attack. This attack remains possible with n colluding nodes targeting one user, but in this case, all n colluding nodes will be returned "1" and will discover the exposed status of their own victim. However, now it takes n adversaries to target one victim, reducing the scalability of the attack.

[0091] A side effect of this proposal is to introduce some false positives, i.e. some people will be notified even though they are not actually "at risk" (at least according to the risk score). The acceptability of this tradeoff lies in several factors. First, we need to recognize that proximity tracing is not perfect and there will be false positives or false negatives anyway. In this context, adding 5% or 10% more false positives is not necessarily a problem. Second, the use for which the system is used also plays a big role. i.e. if the app is used to target users who should be tested, then randomly testing 5% or 10% more users is quite acceptable, but if the app is notifying users to go into quarantine, then false positives may be more problematic.

[0092] 5.3 Bluetooth communication The identifier EBID broadcasted via Bluetooth is now larger than 16 bytes and therefore cannot be carried in advertising packets alone. The invention proposes two solutions for transmitting this larger message via Bluetooth.

[0093] 5.3.1 Scan-Response-Based Approach 256-bit identifier EBID A,i via BLE (Bluetooth Low Energy), the present invention proposes to use the scan response mechanism of BLE [8, Vol 3, Part B, sec. 4.4.2.3]. The 256-bit identifier is split into two blocks of 16 bytes, the first one is included in the advertisement data of the ADV_IND packet, whereas the second one is included in the advertisement data of the SCAN_RSP packet (see Tables 2 and 3 below).

[0094] Identifier Segmentation 256-bit identifier EBID A,i There are two blocks, ID L =LSB 16 (EBID A,i ) and IDH=MSB 16 (EBID A,i ), where MSB 16 (x) and LSB 16 (x) are functions that return the most significant 16 bytes and the least significant 16 bytes of x, respectively.

[0095] [Table 2]

[0096] [Table 3]

[0097] 5.3.2 Dedicated Services Each of these blocks constitutes data for a service. For this purpose, two dedicated services are defined: Risk Notification Service 1 (RNS1) with 16-bit UUID 0xFD01, which transmits the ID together with metadata (protocol version and Tx power). L and Risk Notification Service 2 (RNS2) carries the ID along with the 16-bit UUID 0xFD02. H Transport.

[0098] 5.3.3 Advertisement and Scan Response Payload The payload of an advertisement packet consists of the following: Flags (3 bytes) The full 16-bit UUID (4 bytes) that carries the UUID of the Risk Notification Service 1 (0xFD01) Service Data - Data for Risk Notification Service 1, i.e. ID L (16 Bytes), a 16-bit UUID (22 Bytes) carrying the protocol version (1 Byte) and Tx power (1 Byte).

[0099] The payload of the scan response consists of the following: The full 16-bit UUID (4 bytes) that carries the UUID of the Risk Notification Service 2 (0xFD02) Service Data – Risk Notification Service 2, i.e. ID H 16-bit UUID (20 bytes) carrying data for (16 bytes)

[0100] It was assumed that the EBID rotation was synchronized with the device address. Thus, the two block IDs L and ID H can be linked via their device addresses. If this is not the case, then the advertisement and scan response packets must include an additional identifier in their payload to allow reconstruction of the EBID.

[0101] 5.3.4 Advertising and Scanning As stated in the Bluetooth specification [8, Vol 3, Part B, sec. 4.4.2.3], after receiving an advertisement packet (ADV_IND PDU), the scanner can send a scan request (SCAN_REQ PDU) or request additional information about the advertiser. If the advertiser receives a SCAN RSP PDU containing its device address, it replies with a SCAN RSP PDU on the same primary advertising channel index.

[0102] Devices are configured to follow this request-response mechanism: more specifically, a device should always send a scan request in response to a new advertisement packet, and upon receiving a scan request, a device should always respond with a scan response.

[0103] 5.4 Fragmentation Methods Another solution is EBID A,i One solution is to split the metric into two blocks and send these blocks alternately in the advertisement packet.

[0104] More specifically, EBID A,i follows the methodology presented in Section 5.3.1 to find two block IDs. L and ID H These blocks are transmitted in the payload of an advertisement packet (ADV_IND PDU) as service data associated with a dedicated service (e.g., risk notification service 1 with UUID 0xFD01, as presented in Section 5.3.2). The service data in the transmitted advertisement packet is alternately divided into IDs L and ID H The value is

[0105] 6 Expansion 6.1 Two non-COVID19 related PET-based methods Although the present invention has been described primarily in the context of COVID19 exposure management, it has practical application in a wide variety of other settings.

[0106] The present invention can be applied to any situation where two devices A and B need to privately and securely prove their co-location to a third entity, without even having a dialogue.

[0107] Broadly speaking, many of the features of the embodiments described above can be interchanged. For example: Instead of -Curve25519, another elliptic curve, or ECDH, can be used, or any type of Non-Interactive Key Exchange (NIKE) protocol such as the basic Diffie-Hellman key protocol ("NIKE" in the paper "Non-Interactive Key Exchange" by Freire ESV, Hofheinz D., Kiltz E., Paterson KG (2013) In: Kurosawa K., Hanaoka G. (eds) Public-Key Cryptography - PKC 2013. PKC 2013. Lecture Notes in Computer Science, vol 7778. Springer, Berlin, Heidelberg). Instead of Bluetooth and BLE, any other wireless transmission protocol can be used, whether radio (such as WiFi), or airborne (by ultrasound), or by light modulation. The function H() described herein is a hash function. In alternative embodiments, it can be any pseudorandom function with similar results. -Different metrics and / or metadata can be used to associate PETs according to the type of encounter being monitored, the information being sought, e.g., duration, speed during the encounter, whether the encounter occurred outside or inside, instantaneous density (i.e., how many EBIDs were visible), etc. - In the above, the value of PET is g A and g B The ETL and RTL lists are assigned by comparing the values ​​of A and B. The goal here is to define an ordering between A and B based on inputs known by both A and B, without there being a need for further communication. More comprehensively, this can be done by implementing a total ordering function that, given two inputs known by A and B, outputs a sorted value that defines an ordering between A and B.

[0108] Moreover, the above relates to a particularly robust and anonymous method for application in pandemic management. However, simpler versions may be used to aid in the study of other cases. For example, instead of calculating two PETs and storing them in two lists to prevent malicious reporting server activity, only one PET may be generated. And, for example, if one of the devices is a fixed device, this device may use its interaction encounter tokens to evaluate the efficiency of various policies. For example, this fixed device may be positioned near a communication medium or near an element that is the subject of the communication medium, and may monitor the encounter tokens as a means of evaluating the efficiency of this communication medium.

[0109] It should be understood that in the above, all data items are stored on a tangible memory medium, which may be realized in any suitable manner, such as by a hard disk drive, a solid state drive, a flash memory, a memory embedded in a processor, a remote storage device accessible in the cloud, etc.

[0110] Similarly, most of the functions and operations described above are intended to be performed by computer programs executing on one or more processors, including any known means of automated computation, such as CPUs, GPUs, CPU and / or GPU grids, remote computation grids, specially configured FPGAs, specially configured ASICs, specially configured chips such as SOCs or NOCs, AI specially configured chips, etc.

[0111] Although the participating devices above are described as smartphones running applications, any mobile device with wireless capabilities can implement the method according to the invention.

[0112] More generally, the present invention proposes a computer-implemented method for anonymous proximity tracking, the method comprising: a) providing a plurality of wireless communication enabled participating devices, each having a non-interactive key exchange protocol interface including a private key generator and non-interactive key exchange protocol parameters; b) periodically using a private key generator at each of the participating devices to obtain a respective current private key, and calculating a respective current public key at each of the participating devices based on the respective current private key and the non-interactive key exchange protocol parameters, and each of the participating devices periodically wirelessly broadcasting its respective current public key; c) upon detection by the first participating device of the respective current public keys broadcast by the second participating device, at each of the first participating device and the second participating device: i. calculating a current shared secret defined by non-interactive key exchange protocol parameters and a current private key of each of the first participating device and the second participating device; ii. calculating at least one token using a pseudorandom function parameterized with said current shared secret and applied to the bucket values; d) selectively uploading at least some of said first tokens calculated by a given participating device to a reporting server upon detection of an upload condition by said given participating device; The present invention relates to a method for producing a semiconductor device comprising the steps of:

[0113] According to this method, the plurality of participating devices may further store a first encounter token list and a second encounter token list, and step c) ii includes: calculating a first token using a pseudo-random function parameterized with the current shared secret and applied to a first bucket value; and calculating a second token using the pseudo-random function parameterized with the current shared secret and applied to a second bucket value; and step c) includes: iii. calculating a sort value determined by applying a total order function with two inputs known by both the first participating device and the second participating device; and based on the sort value, adding the first encounter token list of the first participating device and the second encounter token list of the second participating device to the first encounter token list of the first participating device and the second encounter token list of the second participating device. and storing a first token in the second encounter token list of the first participating device and the second token in the first encounter token list of the second participating device, or storing the first token in the second encounter token list of the first participating device and the first encounter token list of the second participating device and storing the second token in the first encounter token list of the first participating device and the second encounter token list of the second participating device, wherein step d) may include selectively uploading, by a given participating device, at least a portion of one of the first encounter token list or the second encounter token list to a proximity management server upon detection of an upload condition by the given participating device.

Claims

1. 1. A computer-implemented method for anonymous proximity tracking, comprising: a) providing a plurality of wireless communication enabled participating devices (2), each having a non-interactive key exchange protocol interface including a private key generator and non-interactive key exchange protocol parameters; b) periodically using the private key generator at each of the participating devices to obtain a respective current private key, and calculating a respective current public key at each of the participating devices based on the respective current private key and the non-interactive key exchange protocol parameters, and each of the participating devices periodically wirelessly broadcasting its respective current public key; c) when a first participating device detects the respective current public keys broadcast by a second participating device, in each of the first participating device and the second participating device: i. calculating a current shared secret defined by the non-interactive key exchange protocol parameters and the respective current private keys of the first participating device and the second participating device; ii. calculating a first token using a pseudorandom function parameterized with the current shared secret and applied to a first value associated with the first participating device, and calculating a second token using the pseudorandom function parameterized with the current shared secret and applied to a second value associated with the second participating device; iii. calculating a sort value by applying a total order function using two inputs known to both the first participating device and the second participating device, and storing the first token in a first encounter token list of the first participating device and a second encounter token list of the second participating device based on the sort value, and storing the second token in the second encounter token list of the first participating device and the first encounter token list of the second participating device, or storing the first token in the second encounter token list of the first participating device and the first encounter token list of the second participating device, and storing the second token in the first encounter token list of the first participating device and the second encounter token list of the second participating device; d) selectively uploading, by a given participating device, at least a portion of one of the first encounter token list or the second encounter token list to a proximity management server upon detection of an upload condition by the given participating device; 16. A computer-implemented method for anonymous proximity tracking, comprising:

2. 2. The computer-implemented method of anonymous proximity tracking of claim 1 , wherein the total ordering function calculates the sort value by comparing values ​​derived from the respective current public keys of the first participating device and the second participating device.

3. 3. The computer-implemented method of anonymous proximity tracking of claim 1 or 2, wherein step d) comprises uploading a token from the first encounter token list.

4. e) for each of the participating devices, periodically transmitting at least one token from the second encountered token list to a reporting server, wherein upon detection by the reporting server that another participating device has uploaded a token from the first token encounter list of the other participating device that is identical to the at least one token from the second encountered token list, transmitting a message to the participating device that issued the second encountered token list to the reporting server indicating detection of uploading the identical token.

5. 5. The computer-implemented method of anonymous proximity tracking of claim 3 or 4, further comprising the steps of: f) for each participating device, periodically sending at least one token from the second encounter token list to a reporting server and calculating a risk score based on a comparison of the at least one token from the second encounter token list with the tokens uploaded by other participating devices from the first encounter token list.

6. The computer-implemented method of anonymous proximity tracking according to any one of claims 1 to 5, wherein the non-interactive key exchange protocol is based on Curve25519, another elliptic curve, the elliptic curve Diffie-Hellman protocol or Diffie-Hellman key exchange.

7. 7. The computer-implemented method of anonymous proximity tracking of claim 1, wherein metadata regarding the co-location of the first participating device and the second participating device is stored along with the first token and the second token in one of the first encounter token list and the second encounter token list.

8. A computer program comprising instructions for carrying out the method according to any one of claims 1 to 7.

9. A data storage medium having recorded thereon the computer program according to claim 8.

10. 9. A computer system comprising a processor coupled to a memory having stored thereon the computer program of claim 8.

Images