ELECTRONIC SYSTEM FOR USER TRACKING, ESPECIALLY FOR COMBATTING A PANDEMIC

Description

Technical field

[0001] The invention relates to an electronic system for tracing users, in particular for tracing users in emergency scenarios such as in the fight against a pandemic, such as Covid-19, and a corresponding digital storage medium on which a computer program or an app is stored. State of the art

[0002] To limit the spread of Covid-19, the current procedure is to require individuals attending public events or restaurants to provide their personal data. The associated documentation requirements are burdensome for the respective organizers and restaurant operators, especially since data protection regulations must also be observed.

[0003] Furthermore, the existing method cannot guarantee the desired level of security for visitors' sensitive personal data, such as addresses and telephone numbers, as restaurant and cultural venue operators are not equipped to securely store sensitive data from a large number of individuals. Moreover, the very fact that visitors' address data must be disclosed to venue operators poses a security risk, as this allows the venue operator to trace users, at least within their own premises, and also reveals the identities of their guests. In contrast, the invention provides a computer-implemented method, an electronic system, and individual system components that ensure largely automated tracing while complying with data protection regulations. Technical problem and basic solutions

[0004] Against this background, there is a need for improved procedures for tracing visitors to event venues and other spatial areas, insofar as the aforementioned disadvantages can be at least partially avoided.

[0005] In contrast, the invention is based on the objective of creating an improved method and system for tracing visitors, which offers better protection of sensitive personal data.

[0006] The problems underlying the invention are each solved by the features of the independent claims. Embodiments of the invention are specified in the dependent claims. The embodiments listed below can be freely combined with one another, provided they are not mutually exclusive.

[0007] In one aspect, the invention relates to an electronic system with user devices, each assigned to a user, and with at least one server for tracing users who are temporarily located in different spatial areas (venues). User tracing is performed for a single entity. The electronic system is configured to perform the following steps: In connection with registration: storage of user data on the server, whereby the user data is encrypted with a user data key individual to the respective user (i.e. a symmetric or asymmetric public encryption key for the encryption of the user data), whereby in particular a user ID of the user in question is linked to the encrypted user data and stored on the server;and storage of the user IDs and a user-specific user data decryption key suitable for decrypting the encrypted user data in each of the user devices assigned to the user, wherein preferably the user data key and / or the user data decryption key (the user data key and the user data decryption key can be, for example, identical symmetric keys or form an asymmetric cryptographic key pair) is stored securely in the user device of the respective user and is not accessible to the server;During a user check-in at one of the venues, a trace ID is generated by the user's device. This trace ID is representative of a combination of the user's user ID and current time information. The trace ID is then stored on the server, linked to the venue ID of that venue, and stored as an access key. A message containing the user ID of the user for whom tracing is to be carried out is then received. For example, the message can be sent from an entity device and received by the server.In another example, the message can also be sent from an entity device, received by the user device, and forwarded to the server. Candidate trace IDs are generated for the user identified in the message. These candidate trace IDs are possible past trace IDs that fall within a specified past time period. The server uses these generated candidate trace IDs as search criteria to locate corresponding trace IDs stored on the server for the past period. This allows the server to determine the venue IDs of the venues where the user checked in during the past period. The server then outputs the venue IDs of the identified venues to identify the venues the user visited during the past period.

[0008] This can be advantageous because, while the server stores user data and the venue IDs linked to the trace IDs of various users during check-in events at different venues, it ensures that neither the venue operator nor the server operator can access the user data stored on the server without user authorization. This is because the decryption keys required to decrypt the user data are generated individually for each user and are securely stored on the user's device. This means that if one user's decryption key becomes known, it has no impact on the security of other users' data. The identities of users registered with the server are secure and centrally stored on the server along with their check-in records.Since the user data, in particular the encrypted identification data of the user, is encrypted according to embodiments of the invention so that the venue cannot read it (e.g. with the UserData encryption key and / or with an entity key of the entity), and since the Trace-ID is representative of a combination of the user ID of one user and a current time information (and thus does not allow any direct inference to the user ID or even the full name of the user), neither the server nor the venue can recognize which person visited the venue.

[0009] According to some embodiments, the venue encrypts the check-in data (i.e., in particular the trace ID and optionally other data) with its venue-specific key. The other data, e.g., the check-in time, can also be encrypted or appended to the encrypted trace ID as plaintext. If the venue encrypts the check-in data records with its venue key before uploading them, the server, according to embodiments of the invention, cannot even determine how many visitors a venue had at a specific time (if the timestamps are also encrypted). Only when the venue consents to such an evaluation and provides its venue-specific decryption key can the server decrypt and evaluate the encrypted trace IDs.

[0010] Embodiments of the invention can thus offer the advantage of enabling the anonymous and secure transmission and storage of contact information, allowing for the tracing of individual users, but only if the user consents to such tracing. Visitors and guests of public or private events are thereby enabled to anonymously provide their contact details to the organizer. Only in the event of an infection, with the consent of the guest and preferably also the organizer, are the local health authorities granted access to the contact details. The contact details can then be used to inform potential contacts.

[0011] For example, the system can be used to make contact tracing safer and easier for event venues, restaurants and other spatial areas (train compartments, airplanes, stadiums, concert halls, buildings, rooms, outdoor concert areas, etc.) and, in particular, to provide a secure and machine-based, and therefore efficient and scalable, tracing solution.

[0012] The anonymous and secure tracing system / procedure can be used in various application scenarios. One example is tracing infected individuals in the event of a pandemic such as Covid-19 or other contagious diseases. Another example is tracking people in the event of other types of emergencies or for investigating security incidents. For instance, the owner of a high-traffic area such as a zoo, amusement park, or train station could use the system to anonymously register visitors upon entry as part of a check-in process at the entrance. This means that the owner stores the check-in data (the venue ID linked to the user's trace ID and potentially other data) on the server without the visitor having to disclose their identity to the venue owner or operator. However, if a security incident were to occur at the venue, for example,If visitors have been injured, the venue operator can make a public appeal asking them to contact the relevant entity (e.g., the responsible authority or a competent, trustworthy organization) to cooperate, for example, as a witness (whose presence is documented by check-in and optionally also check-out events and server-side data records).

[0013] According to some implementations, user IDs are data values ​​that are created individually for each user and that do not directly and explicitly reveal the identity of the users (in particular name, contact details, and / or address as well as personal attributes such as account number, date of birth, place of birth, etc.) without knowledge of further data.

[0014] In some embodiments, the trace ID contains the user ID only in encoded or encrypted form, so that the server (and / or other actors such as the venue or other third parties) cannot identify the user ID of the associated user based on the trace ID. This can mean, for example, that in some embodiments the trace ID is generated or calculated in such a way that the user ID cannot be reconstructed from it.

[0015] According to some implementations, the trace IDs are data values ​​that do not reveal the identity of the users (in particular name, contact details, and / or address as well as personal attributes such as account number, date of birth, place of birth, etc.).

[0016] According to embodiments of the invention, the trace ID generated during check-in is calculated using a derivation function, namely as a function of the combination of the user ID to be represented and the current time information to be represented at check-in. Each candidate trace ID is calculated using the same derivation function as a function of the combination of the user ID contained in the message and one of the candidate time information for a possible check-in time in the past. The derivation function preferably includes rounding the current or candidate time information to times within predefined time intervals, wherein the time intervals are, in particular, minutes, hours, or days.For example, during check-in, the current time can be continuously recorded by the user's device, rounded down to the nearest minute after recording, and then passed to the derivation function along with the user ID. The tracing ID and the venue ID can then be linked with optional additional data, encoded as a QR code, and displayed on the user's device for check-in purposes. The user's device is configured to automatically generate a new trace ID and, if necessary, a new QR code when the time interval (e.g., a minute) has elapsed and more recent time information (current minute, rounded down) has been received. If the old QR code has not been used for check-in by then, the trace ID it contains is not stored on the server and is discarded by the user's device.

[0017] This can be advantageous because the trace ID is generated based on time, making it impossible to assign trace IDs to individual users or even group them by user. Therefore, the venue and server operators cannot create anonymous movement profiles of individual visitors based on these trace IDs, as they are derived from a constant data value (user ID) and a regularly changing time value. This increases user security against unauthorized tracking should an attacker gain access to the venue device used for check-in and / or the server.

[0018] According to embodiments of the invention, the user device is configured to generate a random value ("userTracingSecret") during registration with the server and to store it securely on the user device. The derivation function used during check-in and / or user tracking to generate candidate trace IDs calculates the trace ID as a function of (also) the random value ("userTracingSecret"). The user device is configured to obtain confirmation of the random value transmission from the user to whom it is assigned and only transmits the random value to the server (e.g., within a tracing secret transfer object) in response to this confirmation, thus enabling the server to derive the candidate trace IDs. Additionally or alternatively, the user device can be configured to transmit the random value to an entity device of the entity only in response to this confirmation (e.g.,within a tracing secret transfer object) to allow the entity to derive the candidate trace IDs.

[0019] Depending on the implementation, the application programs or apps installed on the user device, the server and / or the entity device have the necessary interfaces to exchange data directly or indirectly with each other over a network.

[0020] This can be advantageous because an attacker who guesses the user ID and possibly even learns the derivation function cannot manipulate the trace IDs stored on the server by calculating and manipulating (deleting, replacing, or supplementing with "invented" trace IDs) a user's trace IDs within a specific timeframe. The attacker would also need to infiltrate the user's device and obtain the random value ("userTracingSecret") generated and securely stored there during registration in order to calculate, identify, generate, and manipulate trace IDs for that user.

[0021] In some embodiments, the user device is configured to generate a random value, referred to below as the `userVerificationSecret`, during registration with the server and to store this value securely on the user device. During check-in with the venue, the user device is configured to use the `userVerificationSecret` to calculate a verification data value as a function of the trace ID and the encrypted ID data, and to store this value, linked to the trace ID, on the server. Depending on the embodiment, storage on the server can be direct or indirect, whereby the check-in data is first captured by a venue device, which then forwards this data to the server for storage.

[0022] According to embodiments of the invention, the entity is assigned an asymmetric cryptographic key pair consisting of a public and a private entity key. The user's device is configured to additionally encrypt the user data, which is already encrypted with the user data key, with the public entity key during registration.

[0023] Additionally or alternatively, the user's device is configured to encrypt the user data decryption key required for decrypting this encrypted user data during check-in using the public entity key along with the user's user ID, in order to generate encrypted ID data. During check-in, the user's device stores the encrypted ID data, linked to the venue ID of the specific venue, on the server. This storage can occur directly, for example, if the venue operator does not have a venue device and the user's device performs the "check-in" itself by collecting the venue's data, using it for check-in, and transmitting the check-in data, including the venue ID, to the server for storage.However, storage can also be done indirectly via the venue device, by having the venue device capture the user's check-in data, link it to the venue ID of the venue to which the venue device is assigned, and transmit it to the server for storage.

[0024] Using an entity key, such as a public encryption key belonging to an authority like the public health department, for the aforementioned purposes can be advantageous. This is because, upon gaining access to the server, the department can use its private entity key corresponding to the public entity key to decrypt the identification data stored with the trace ID, thereby obtaining the user ID and the associated user data decryption key. With this user data decryption key, the department can then decrypt the encrypted user data to determine the user's identity.

[0025] Furthermore, these features can have the advantage that the tracing data records consume less storage space on the server and the tracing data can be encoded in a graphic code such as a QR code: since the user ID and the user data decryption key are encrypted to generate the encrypted ID data, but not the complete user data, which can also be quite extensive, this data transmitted during check-in can easily be encoded in a QR code, which facilitates automatic check-in.

[0026] According to embodiments, the electronic system comprises at least one entity device associated with the entity. The entity device is configured to successively generate multiple asymmetric cryptographic key pairs assigned to the entity, invalidating the previously valid entity key pair upon generation of a new one, and each entity key pair is assigned a key version number.

[0027] At least one entity device is configured to transmit the public key of the generated and currently valid key pair to the user devices. The user devices are configured to always use only the most recently transmitted entity key to generate the multiply encrypted user data and / or the encrypted ID data.

[0028] The entity devices may be, for example, data processing devices such as desktop computers or notebooks, or other computers, especially those belonging to employees of a public authority, or data processing devices from third-party providers that are used by the entity to fulfill a task of the entity.

[0029] For example, the generation of a new entity key pair can occur daily, e.g., in response to the first launch of an entity tracing application on one of the entity's entity devices by an employee, or at a predefined time (e.g., daily at 7:00 a.m. on a predefined entity device).

[0030] For example, the version number of the entity key used can be linked to the multiply encrypted user data and / or linked to the encrypted ID data and stored on the server, so that the entity device can use the version number to identify the private entity key suitable for decryption with the same version number.

[0031] Regularly issuing new entity key pairs increases security because an attacker who obtains a private entity decryption key would not be able to decrypt the vast majority of check-in or ID data on the server, as this data is encrypted with a different (e.g., daily updated) entity key. Without knowing the key ID, the attacker would also be unaware of which check-in records could be decrypted with the obtained decryption key.

[0032] According to embodiments of the invention, the at least one entity device consists of a plurality of entity devices. The entity device that generates the current asymmetric entity key pair sends the private key of the currently generated asymmetric entity key pair in encrypted form to all other entity devices via a network, e.g., the internet and / or an intranet. Each entity device is configured to generate an emergency notification relating to one of the users and send it to the server. Additionally or alternatively, the entity device is configured to decrypt the encrypted user data and / or the encrypted identification data using one of the previously received private entity keys.

[0033] This can be advantageous because it ensures that different employees of the entity, using different entity devices, still possess the same private entity key every day for decrypting the data of users involved in an emergency (e.g., a positive test in a pandemic). This provides a tracing solution that is secure and scalable, as it establishes a decentralized IT infrastructure spanning multiple entity devices, which relies on regularly (especially daily) newly generated entity key pairs for encrypting and decrypting user data and / or ID data.

[0034] According to embodiments of the invention, the electronic system comprises several venue devices. One or more of the venue devices are assigned to each of the venues.

[0035] For example, the venue could be a restaurant with multiple entrances, each equipped with a venue device for automatic check-in and, optionally, automatic check-out of guests. Another example would be a train or train compartment, an airplane, or even a single airplane seat, with at least one venue device installed at each entrance and / or exit.

[0036] According to embodiments of the invention, the user device is configured to record its current position during check-in. For example, this can be achieved by the user device using a GPS sensor to determine its position via GPS coordinates. In this case, the user device's position is determined absolutely and explicitly. However, it is also possible for the position information regarding the user device's current position to be determined only implicitly, e.g., by receiving WLAN signals that the user device uses for WLAN-based positioning. WLAN-based positioning is a method for determining the receiver's location. The method is based on lateration and calculates the user's position using WLAN propagation patterns. Especially in densely populated areas, numerous WLAN stations transmit. These signals originate from commercial hotspots, corporate networks, or private home networks.Knowing the location of these networks (routers) allows for the calculation of one's own location. The more network signals are received, the more accurate the laterality calculation for determining one's location can be. Apple uses this method in newer mobile phone models (iPhone) based on technology from Skyhook Wireless. Free solutions include OpenWLANMap and Mozilla Location Service. As an alternative to WLAN-based location determination, the system can also be configured to receive and analyze a near-field signal from a transmitter of the venue in order to determine a venue ID encoded in the near-field signal. The venue ID used for location determination does not have to be identical to the venue ID stored on the server; it can be any data value that is uniquely assigned to a venue.Receiving a near-field signal containing a venue ID serves as implicit proof that the user device is in close proximity to the venue at check-in, as sufficient proximity is a prerequisite for receiving the venue ID via a near-field signal (e.g., Bluetooth or any other near-field communication standard, especially radio standard). The near-field signal can be emitted, for example, by a transmitter installed by the venue at the entrance.

[0037] During the check-in process, according to some implementations, the system checks whether the user device is within a maximum distance from the venue's location and only performs the check-in if the user device is within the maximum distance from the venue's location.

[0038] For example, this check can be performed by the venue or a data processing device of the venue. In this case, the venue or its data processing device has reference data (accessibly stored) that can be compared with the current position or position information of the user device to determine sufficient spatial proximity between the user device and the venue. If sufficient proximity is not determined, the check-in process is aborted.

[0039] According to an alternative embodiment, the check is performed by the server. For example, the server can receive the location information captured by the user's device during check-in, along with the venue ID, trace ID, and optionally other check-in data, and compare this information with the venue's location data, which is stored on the server and linked to that venue's ID. In another example, the location information regarding the venue's position (e.g., GPS data, venue ID for location determination, Wi-Fi name, etc.) is not stored on the server but is transmitted again with each check-in to enable the server to perform the check. If insufficient proximity is detected, the check-in process is aborted by the server.

[0040] According to embodiments of the invention, determining the current position of the user device includes acquiring GPS data from the user device using a GPS sensor on the user device. The GPS data determined by the user device is compared with position data of the venue to determine whether the user device is within the maximum distance of the venue at check-in.

[0041] According to an alternative embodiment, the detection of the user device's current position includes the detection of a WLAN identifier from a locally available WLAN network. The WLAN identifier determined by the user device serves as proof during the check-in process that the user device is within the maximum distance of the venue.

[0042] According to an alternative embodiment, the detection of the user device's current position includes the detection of a near-field signal from a near-field signal transmitter of the venue. This near-field signal encodes an identifier for the venue. The venue identifier determined by the user device via the near-field signal serves as proof during the check-in process that the user device is within the maximum distance of the venue.

[0043] This additional check regarding sufficient proximity between the user's device and the venue during check-in can be advantageous, as it ensures that users can only successfully check in to a venue if they are actually in its vicinity. For example, this prevents individuals who have obtained an image of a venue's QR code from using that image to check in from a distant location, perhaps to create an alibi or to hinder contact tracing through mass "fake check-ins." Thus, this plausibility check to verify that a user is actually at the venue during check-in increases the system's security.

[0044] According to another embodiment, the venue IDs of the venues registered with the server are stored on the server and linked to one of a variety of predefined risk levels. The risk level depends on the type of event for which tracing is being carried out and on various factors relating to the venue. In the case of a pandemic, some of the following factors can influence the risk level: the presence and quality / strength of ventilation systems (windows, air conditioning, air purifiers), the available space per guest, and the type of venue use (for concerts, sports, indoor dining, outdoor dining, etc.). This feature allows the entity, for example, toA public health department can be notified of visitors to a venue, provided they consent and willingly disclose their user ID and, optionally, the relevant time period to be traced, in varying degrees depending on the risk level of the respective venue. For this purpose, the server generates all trace IDs for a user's user ID and the predefined time intervals within that 7-day period, for example, for a user who wants to find out their risk of infection during the last 7 days. These trace IDs are used as access keys to identify, in a database, those venues with which an identical trace ID is stored. The venue ID, in turn, can be stored linked to a risk level, depending on the implementation. If, during the relevant period, information is available for one or more of the venues visited by the interested user indicating that an infected person was present, the system will issue a warning.If a person who tested positive visited the same venue at the same time, interested users can quickly determine not only whether an infection may have occurred during a visit to one or more specific venues, but can also optionally determine the risk of transmission automatically based on the venues' risk levels. This allows for an automated yet highly accurate assessment of the individual infection risk for each user who provides their user ID to the entity.

[0045] According to the implementation, the server is configured to detect when a predefined minimum number of users who have tested positive for COVID-19 and reported themselves to the responsible entity (e.g., the public health department) and provided their user ID for tracing have visited the same venue within a predefined timeframe. This could indicate a super-spreading event at that venue. This allows the public health department to contact the venue and inform them of the event, enabling them to potentially post notices urging their patrons to contact the public health department if they were at the venue during the relevant period. Instead of tracing COVID-19 infections, the system can also be used for other emergency situations and by other entities.

[0046] In one embodiment, the venue application—that is, an application program instantiated on a data processing device assigned to the venue operator—is interoperable with a user status app instantiated on the user's device and is configured to automatically receive and evaluate user-related data during check-in, provided the user has previously consented to this data collection. For example, the user status app could be an application that specifies the user's vaccination status with regard to an infectious disease such as COVID-19. This enables the venue operator to make the check-in process even more efficient and secure.

[0047] According to embodiments of the invention, the user performs the check-in with one of the venue devices, wherein one of the venue devices includes a communication interface for direct communication with the user device of a checking-in user. The user device and the one venue device are configured such that the following occurs during the check-in process: Generation of the check-in data packet by the user device, wherein the check-in data packet encodes the trace ID and preferably also the encrypted identification data; transmission of the check-in data packet from the user device to the venue device via the direct communication interface; and decoding of the received check-in data packet by the venue device in order to obtain the trace ID and preferably also the encrypted identification data of the checking-in user and to store this linked to the venue ID of the venue to which the venue device is assigned on the server;

[0048] The direct communication connection can be, for example, a near-field communication connection or an optical data transmission channel. Data transmission via the optical data transmission channel involves the capture of a graphic code, which encodes the check-in data packet and is displayed on a screen of the user's device, by an optical sensor in the venue device. The venue device decodes the data contained in the code (e.g., QR code or barcode), including, for example, the trace ID and optionally other data such as encrypted ID data, verification values, QR code version number, check-in timestamp, and / or other data, and stores this data on the server, linked to the venue ID stored in the venue device. In one embodiment, the venue device is the venue operator's smartphone, on which, for example,a Venue app from a tracing service provider is installed, which implements the Venue device-side steps of the tracing process.

[0049] The near-field communication connection can be, for example, a radio connection, an infrared connection, a Bluetooth connection, or other forms of connection in the near field of the venue device.

[0050] This implementation variant can be advantageous because suitable venue devices can greatly simplify and accelerate the check-in process, enabling seamless integration of the recorded check-in data into the tracing system without additional effort for the visitor or venue operator.

[0051] According to another embodiment, the electronic system comprises at least one carrier object with a graphical venue code for one of the venues. The venue code encodes a venue ID under which this venue is registered with the server. The user checks in to this venue, and the user device is configured such that the following occurs during the check-in process: Capturing the graphical venue code with a camera on the user's device; and decoding the venue code by the user's device to obtain the venue ID.

[0052] The user's device transmits the trace ID and preferably also the identification data of the checking-in user to the server, whereby the decoded venue ID is also linked to the trace ID and stored on the server. The venue code is preferably a QR code or barcode visible on a printed or digital display, and / or the carrier object is preferably a table stand or a door sign for a vehicle, vehicle compartment, building, or room.

[0053] This can be advantageous because the venue operator does not need to maintain or install their own venue device to provide visitors with the secure tracing method according to embodiments of the invention. For example, it is sufficient for a restaurant operator to place table tents on the tables, each tent encoded with the venue ID and optionally other data (such as table number) in the form of a QR code. A guest then only needs to scan the QR code on the table tent with their device's camera to complete the "check-in process" described above within the same device. For example, the data encoded in the venue code can be used by the user's device to "personalize" a simulated venue device with the venue's ID and, if applicable, other data, and then the check-in can be carried out using this simulated venue device.The trace ID is linked to the venue ID and, if applicable, other data from the user device and transmitted directly to the server for storage.

[0054] According to embodiments of the invention, the electronic system is configured such that a check-out time is transmitted from the user's device or from the venue device to the server when the user leaves the venue. The check-out time is assigned to the trace ID previously received for that user, so that the user's stay at the venue is stored as a combination of the check-in time and the check-out time.

[0055] According to embodiments of the invention, the electronic system is configured to: Generation of a tracing secret transfer object by the user device, wherein the tracing secret transfer object contains at least the user ID and the user data decryption key of the user to whom the user device is assigned; encryption of the tracing secret transfer object with a public key of the entity by the user device, wherein the public key is, in particular, the most recent of a series of successively generated public entity keys; for example, the entity key may be the public part of the entity key pair valid for the current day; transmission of the encrypted tracing secret transfer object over a network from the user device to the server;In response to receiving the encrypted tracing secret transfer object, the server generates a TAN and stores the TAN linked to the encrypted tracing secret transfer object, and issues the TAN to the user; the entity device assigned to the entity receives the TAN from the user; the entity device uses the TAN to receive and decrypt the user's encrypted user data in interaction with the server.

[0056] Preferably, the generation of the tracing secret transfer object by the user device is initiated exclusively by an explicit command from the user to whom the device is assigned, for example, by the user selecting the "Share identity and visit history" function on a tracing app on their device. For instance, the user could do this after receiving a positive test result for an infectious disease following a request from the public health department (e.g., via email, letter, or phone call).

[0057] This can be advantageous because, without the user's explicit authorization, the entity cannot generate candidate trace IDs and therefore cannot identify either the venues visited or the user's potential contacts at those venues. If the user to be traced transmits their tracing secrets (i.e., all data required to generate candidate trace IDs for a specific user) to the agency, for example, via a tracing secret transfer object, this enables the agency to recognize the identity of potential contacts (whose user data can be decrypted by the agency using these users' user data keys, which are part of the check-in data of the venues visited during the relevant period), but not to trace these potential contacts, as they would have to transmit their tracing secrets to the entity for this to happen.

[0058] According to embodiments of the invention, the use of the TAN includes: The entity device sends an initial user data request containing the TAN to the server; the server receives an initial user data request containing the TAN from the entity device; in response to receiving the user data request, the server sends the encrypted tracing secret transfer object, which is stored linked to the TAN, to the entity device; the entity device decrypts the tracing secret transfer object using the entity's private key, which corresponds to the entity's public key, to obtain the user ID and the user data decryption key required to decrypt the user's encrypted user data; the entity device uses the decrypted user ID to generate a second user data request containing the user ID and sends it to the server;Receipt of the user's encrypted user data from the server by the entity device in response to the second request; and decryption of the encrypted user data by the entity device using the user data decryption key contained in the tracing secret transfer object.

[0059] According to embodiments of the invention, the tracing secret transfer object additionally contains a random value ("userTracingSecret") generated during registration with the server and stored exclusively on the user's device in an access-protected manner. The server is configured to calculate the candidate trace IDs using this random value based on a multitude of time points within the past period and the user ID.

[0060] This can be advantageous because, before receiving the tracing secret transfer object (userTracingSecret), the agency cannot calculate the candidate trace IDs and therefore cannot use them as search values ​​in the server data to identify check-in records belonging to the user in question. Thus, without the explicit release and provision of the tracing secret transfer object, the agency cannot determine when and at which venues the user checked in.

[0061] In some embodiments, the tracing secret transfer object additionally contains a random value generated during user registration with the server and stored exclusively on the user's device in an access-protected manner; this value is hereinafter referred to as userVerificationSecret. The server is configured accordingly: to determine the trace IDs stored on the server that are identical to one of the candidate trace IDs; to use the userVerificationSecret contained in the tracing secret transfer object to calculate a verification data value for each of the determined trace IDs as a function of the trace ID and the encrypted identity data (408) stored with these determined trace IDs; to compare the verification data value calculated for each of the determined trace IDs with a verification data value that was stored during check-in with the determined trace ID; and to communicate a result of this comparison to the at least one entity device.

[0062] At least one entity device is configured to treat the assignment of the trace ID to the user as manipulated if the comparison results in a mismatch of the verification data values.

[0063] The creation of the userVerificationSecret during the user's registration process, the use of this userVerificationSecret to calculate a verification data value that is transmitted directly or indirectly from the user's device to the server as part of a check-in message or QR code, and the provision of the userVerificationSecret as part of the tracing secret transfer object to the authority can have the advantage that the authority is enabled to check whether a specific check-in data record was generated by the same user device (and thus the same user) that has currently also transmitted the tracing secret transfer object.Therefore, if an attacker were to intercept a trace ID during transmission and use it on the attacker's device for a check-in under a false identity, this would be detected. While the attacker's device could reuse the stolen trace ID for the fraudulent check-in, it would have a different userVerificationSecret than the legitimate device (or even no userVerificationSecret at all). If the attacker were to successfully perform a check-in using the stolen trace ID, the incorrect check-in data on the server would be assigned an incorrect verification data value (or none at all), and a comparison with the verification data value from the trace secret transfer object would reveal a mismatch.

[0064] According to embodiments of the invention, the electronic system, and in particular the server, is configured to identify those users who also visited one or more of the identified venues during the past period and during the user's stay. For this purpose, those check-in records (and their trace IDs) are identified that contain a venue ID and a check-in timestamp, indicating that the respective check-in events occurred at one of the identified venues during a period in which the user to be traced was also present at the venue.

[0065] By decrypting the ID data encrypted with the entity key in these identified check-in records, the entity obtains the decryption keys for the user data of the potential contacts, and thus access to their contact information. Optionally, the venue devices have additionally encrypted the ID data in the check-in records they generate with a key belonging to the venue device. In this case, the server must first send the identified check-in records to the venue device identified by the venue ID so that the device can decrypt the ID data. The server then provides the decrypted ID data, still encrypted with the entity key, to the entity device.

[0066] In another aspect, the invention relates to an electronic system that comprises only one or some of the components of the system described above, e.g., only the server, only the user device, only an entity device, only a venue device, or e.g., a combination of the server and a user device, a combination of the server and the venue device, a combination of the server and the entity device, or a combination of the venue device or the venue object and the user device.

[0067] In another aspect, the invention relates to a computer program, a computer program product or a digital storage medium with program instructions executable by a processor of a user device for carrying out those steps for the execution of which the electronic system is configured according to one of the embodiments of the invention described herein, which relate to the user device.

[0068] In another aspect, the invention relates to a computer program, a computer program product or a digital storage medium with program instructions executable by a processor for carrying out those steps for the execution of which the electronic system is configured according to one of the embodiments of the invention described herein, which relate to the server.

[0069] In another aspect, the invention relates to a computer program, a computer program product or a digital storage medium with program instructions executable by a processor for carrying out those steps for the execution of which the electronic system is configured according to one of the embodiments of the invention described herein, which relate to the at least one venue device.

[0070] In another aspect, the invention relates to a digital storage medium with program instructions executable by a processor for carrying out those steps for the execution of which the electronic system is configured according to one of the embodiments of the invention described herein, which relate to the at least one entity device.

[0071] In another aspect, the invention relates to a user device of a user that can be used to trace the user, who may temporarily be in different spatial areas (venues), for an entity (246), wherein the user device is configured to: Upon user registration: encryption of the user's data with a user-specific user data key; and storage of the encrypted user data linked to the user's user ID on the server; and storage of the user ID and a user-specific decryption key required to decrypt the encrypted user data (which in the symmetric case can be the user data key or in the asymmetric case a corresponding private key) on the user's device, preferably with this key being stored securely and not accessible to the server;During a user check-in at one of the venues, a trace ID is generated, the trace ID being representative of a combination of the user ID of the user and current time information, and a check-in data record containing the trace ID is transmitted to a venue device, or the check-in data record containing a venue ID of the venue is transmitted to the server to enable the storage of the trace ID with the associated data (check-in data) on the server, preferably storing the trace ID as an access key; optionally, a function for capturing a graphic code on a carrier object with a camera of the user device to initiate a check-in, for extracting a venue ID from the code, and for linking the extracted venue ID with the trace ID, wherein the check-in data record with the extracted venue ID is sent directly to the server;Optionally, functionality for creating a tracing secret transfer object in response to user interaction with the user device and for transmitting the tracing secret transfer object to the server; optionally, an interface to the server for receiving a TAN associated with the tracing secret transfer object from the server, with the user device configured to display or otherwise output the received TAN to the user.

[0072] In another aspect, the invention relates to a server that can be used to trace each of a multitude of users registered with the server, who has temporarily been in different spatial areas (venues), for an entity, wherein the server is configured to: Storing encrypted user data, encrypted with at least a user-specific encryption key and optionally also with an entity key, during the registration of each user in a database;Receiving a check-in record during the check-in of a user to a venue device from the user's device or from the venue device, wherein the check-in record includes a trace ID, a venue ID, and identification data, wherein at least the identification data is encrypted with a key of the entity, and wherein the identification data includes at least the user's user ID and a user-specific key for decrypting that user's data, and wherein the trace ID is representative of a combination of the user's user ID and current check-in time information, and storing the received check-in record in the database, preferably storing the trace ID as the access key.

[0073] According to various embodiments, the server is further configured to: Receiving a message containing the user ID of one of the users for whom tracing is to be performed; generating candidate trace IDs for the user identified in the message, wherein the candidate trace IDs are possible past trace IDs that lie within a specified past period; preferably, the message contains all data necessary for calculating the candidate trace IDs, in particular the user ID and the tracing secret, and preferably also a specification of the period for which the candidate trace IDs are to be calculated; according to an alternative embodiment, the server receives the candidate trace IDs instead from an entity device of the entity; Using the generated or received candidate trace IDs as a search criterion to find corresponding trace IDs of this user stored on the server for the past period, so that the venue IDs of those venues to which the user to be traced has checked in during the past period are determined, and outputting the venue IDs of the determined venues to identify those venues that the user to be traced has visited during the past period, by the server.

[0074] In another aspect, the invention relates to a data processing device assigned to an entity, in particular an office or authority, and referred to as the entity device. The entity device can be used to trace each of a multitude of users registered with a tracing server who have temporarily been in different spatial areas (venues) for the entity, wherein the entity device is configured to: Receipt of a message containing the user ID of one of the users for whom tracing is to be carried out; generation of candidate trace IDs for the user identified in the message, wherein the candidate trace IDs are possible past trace IDs that lie within a specified past period; preferably the message contains all data necessary for calculating the candidate trace IDs, i.e. in particular...the user ID and the tracing secret, and preferably also a specification of the period for which the candidate tracing IDs are to be calculated; sending the generated or received candidate trace IDs as part of a search query to the server, wherein the query contains the candidate trace IDs as a search criterion in order to locate corresponding trace IDs of this user stored on the server for the past period, so that the venue IDs of those venues to which the user to be traced has checked in during the past period are determined, and receiving the venue IDs of the determined venues from the server via a network to identify those venues that the user to be traced has visited during the past period.

[0075] In another aspect, the invention relates to a data processing device assigned to a venue, i.e., a spatial area where users can be located, and referred to as a venue device. The venue device can be used to enable each of a multitude of users registered with a tracing server, who may be temporarily located in different spatial areas (venues), to perform an automatic or semi-automatic check-in to the venue, wherein the visit to the venue is traceable for the entity. The venue device includes an interface for local data transmission with a user device of a user who wishes to check in to the venue and is configured to: Receipt of a check-in signal (e.g., QR code or near-field signal) from the user's device, wherein the check-in signal includes a check-in data record, the check-in data record containing at least a trace ID, check-in time information, and encrypted user identification data, the identification data being encrypted with an encryption key of the entity and including at least the user's user ID and a user-specific decryption key for that user's data; Optional: verification of the age of the time information in the check-in data record and further processing of the check-in data record only if the time information does not exceed a maximum age; supplementation of the received check-in data with the venue ID of the venue;Optional: Encrypt at least part of the received and supplemented check-in data record with a venue-specific encryption key, leaving the TraceID unencrypted; transmit the supplemented and optionally venue-key encrypted check-in data over the network to the server.

[0076] In another aspect, the invention relates to a (computer-implemented) method for tracing users who are temporarily located in different spatial areas (venues) for an entity, particularly for emergency scenarios such as a pandemic. The method comprises: Upon registration of each user: storage of the user's data on a server, wherein the user data is encrypted by a user device assigned to the user with a user data key unique to the user, wherein in particular a user ID of the user is linked to the encrypted user data and stored on the server; and storage of the user ID and a user-specific user data decryption key required to decrypt the encrypted user data in the user device, wherein preferably the user data key and / or the user data decryption key are stored securely and are not accessible to the server;During a check-in by one of the users to one of the venues, a trace ID is generated by the user's device, the trace ID being representative of a combination of the user ID of that user and current time information, and the trace ID is stored on the server linked to the venue ID of that venue, with the trace ID being stored as an access key, and a message containing the user ID of one of the users for whom tracing is to be carried out is received;Generation of candidate trace IDs for the user identified in the notification, wherein the candidate trace IDs are possible past trace IDs that fall within a specified past period; use of the generated candidate trace IDs as a search criterion by the server to find corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues to which the user to be traced checked in during the past period are determined; and output of the venue IDs of the determined venues to identify those venues that the user to be traced visited during the past period.

[0077] According to embodiments, the method includes further steps that are performed by one or more components of an electronic system for tracing users, and which have already been described with regard to these embodiments of the electronic system.

[0078] In another aspect, the invention relates to an electronic system with user devices, each assigned to a user, venue devices, and at least one server for tracing users for an entity, to which an asymmetric cryptographic key pair with a public and a private entity key is assigned, wherein the electronic system is configured to perform the following steps: Storage of user data of users upon registration on a server, wherein the user data is encrypted by the public entity key and the result of this encryption is encrypted with a respective user data key of the user in question; storage in each of the user devices of a user data key, a user secret and a user ID, wherein the user device has access to current time information via a network interface and the user device is configured to generate a trace ID that is representative of a combination of user ID, user secret and the current time information, as well as to generate a ciphertext from the user data key and the user ID, wherein the public entity key is used to generate the ciphertext, and wherein the user device has a communication interface for direct communication with a venue device.via which the trace ID and the ciphertext are transmitted to the venue device, , Capture of a user by a venue device using the user's device, wherein the venue device has an interface for direct communication with the corresponding interface of the user device and a network interface for communication with the server, wherein the venue device is configured to receive the trace ID and ciphertext from the user device for user capture and to check whether the time information of a received trace ID is sufficiently current, and if so, to transmit the trace ID to the server along with a venue ID and ciphertext assigned to the venue device, storage of a received trace ID and ciphertext along with the time information as an access key by the server, receipt of a message of the user ID and user secret from one of the users to the entity, generation of possible past trace IDs for the user in question.which lie within a predefined past period and use the generated trace IDs as a search criterion to find corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues from which the user was tracked during the past period are determined, output of the venue IDs of the determined venues to identify those venues that the user visited during the past period.

[0079] According to embodiments, the electronic system is configured such that when a user leaves the venue, the user's device transmits a check-out time to the server, assigning the check-out time to the trace ID previously received for that user, so that the user's stay at the venue is stored.

[0080] According to embodiments, the electronic system is configured to identify those users who also visited one or more of the identified venues during the past period and during a user's stay, for which purpose the trace IDs transmitted from the identified venues to the server during the past period are determined.

[0081] In another aspect, the invention relates to a digital storage medium with program instructions executable by a processor of a data processing device for carrying out those steps for the execution of the electronic system according to one of the embodiments described herein, which relate to the data processing device, wherein the data processing device is the user device, an entity device, a venue device or the server.

[0082] In another aspect, the invention relates to an electronic system with user devices, each assigned to a user, venue devices, and at least one server for tracing users for an entity, to which an asymmetric cryptographic key pair with a public and a private entity key is assigned, wherein the electronic system is configured to perform the following steps: Storage of user data of users upon registration on a server, wherein the user data is encrypted by the public entity key; storage of a user ID in each of the user devices, wherein the user device has access to current time information via a network interface and the user device is configured to generate a trace ID that is representative of a combination of user ID and the current time information; and wherein the user device has a communication interface for direct communication with a venue device, via which the trace ID is transmitted to the venue device. Capturing a user by a venue device using the user's device, wherein the venue device has an interface for direct communication with the corresponding interface of the user device and a network interface for communication with the server, wherein the venue device is configured to receive the trace ID from the user device for user capture and to check whether the time information of a received trace ID is sufficiently recent, and if so, to transmit the trace ID to the server along with a venue ID assigned to the venue device, storing a received trace ID along with the time information as an access key by the server, receiving a message of the user ID from one of the users to the entity, generating possible past trace IDs for the user in question that lie within a specified past period and using the generated trace IDs as a search criterion.to locate corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues from which the user was tracked during the past period can be determined, output the venue IDs of the determined venues to identify those venues that the user visited during the past period.

[0083] According to embodiments, the electronic system is configured such that a check-out time is transmitted from the user device of one of the users or from the venue device to the server when the user leaves the venue, whereby the check-out time is assigned to the trace ID previously received for this user, so that the period of stay at the venue is stored for the user.

[0084] According to embodiments, the electronic system is configured to identify those users who also visited one or more of the identified venues during the past period and during a user's stay, for which purpose the trace IDs transmitted from the identified venues to the server during the past period are determined.

[0085] In another aspect, the invention relates to a digital storage medium with program instructions executable by a processor of a data processing device for carrying out those steps for the execution of the electronic system according to one of the embodiments described herein, which relate to the data processing device, wherein the data processing device is the user device, an entity device, a venue device or the server.

[0086] For the purposes of this text, a "user device" is understood to be a portable data processing system, in particular a battery-powered data processing system such as a mobile phone, a notebook, a tablet computer or an integrated device that is specifically designed and / or used for the automatic check-in and tracing of visitors at a venue.

[0087] In this context, a "mobile communication device" is understood to be a portable electronic system, in particular a battery-powered telecommunications device, which has at least one processor for executing program instructions, especially for running so-called apps. A mobile communication device has a network interface for establishing communication connections via a telecommunications network, which may be configured according to a mobile communication standard.

[0088] The user device can optionally be equipped with additional communication interfaces, such as a display for visual communication with the user or for machine-to-machine communication, for example, by displaying optical patterns such as a QR code. Communication via this additional interface is direct, meaning it occurs without the need for a network. For example, the user device may also have one or more near-field communication interfaces, such as those based on the Bluetooth and / or NFC standards. Furthermore, the user device has at least one memory component in which data can be stored.

[0089] A user device is uniquely assigned to a user. This is often done, especially with mobile devices, via a SIM or eSIM.

[0090] In this context, a "venue" device refers specifically to an electronic device used by the operator of a venue—that is, a location for a public or private event, or a food service establishment such as a restaurant, club, or similar—to record the users visiting the venue. A venue can also be a means of transport or an area within it, such as an airplane, train, or train compartment. A venue device can be a monolithic or distributed data processing system, such as a mobile device or a stationary terminal, such as a PC. A venue device can also be an automated access control device, such as a turnstile or access gate. Finally, a venue device can be a third-party data processing system, for example, for ticketing purposes (automated payment, visitor management, etc.).The venue device has an interface for direct communication with the corresponding interface of the user device, as well as a network interface for communication with a server via a telecommunications network, which can be wired or wireless.

[0091] In this context, a "server" refers to a data processing system, specifically a server computer, a virtual server, or a distributed server, such as one implemented via cloud computing. The server serves to trace users, where "tracing" refers to the ability to track a user's past visits to venues and, optionally, to identify users who were present at a venue at the same time as a specific user who, for example, is infected with COVID-19. Depending on the implementation, the server may also integrate and utilize third-party computers and / or functions.

[0092] In this context, a "user" is understood to be a natural person who can act as a visitor to one or more spatial areas (venues), or a mobile, in particular autonomously or semi-autonomously driving technical system (e.g. robot, car, truck), or a physical object transported within such a mobile technical system (various goods, industrial manufactured products, spare parts, components, etc.).

[0093] The term "tracing" here refers to the tracking of contacts of a specific user over a period of time, preferably without creating or needing to create movement profiles.

[0094] This tracing is intended to take place for an "entity." An "entity" here refers to a trustworthy natural or legal person, in particular an institution that has, for example, sovereign rights to determine the whereabouts of users, such as the public health department in the case of a pandemic.

[0095] According to the invention, in various embodiments, users first register using their respective user devices. For this purpose, user data is initially collected, for example, by entering the user data into the user device or by reading the user data, for example, from the user's electronic identity card. The user data is then encrypted by the user device using the public entity key, for example, using a public key of the public health department, and the result of this encryption is encrypted with a user data key of the respective user, where the user data key is, for example, a random value with high entropy, such as a length of 16 bytes.

[0096] According to a preferred embodiment, user data can be encrypted directly using the user data key (user-specific encryption key for the user's data) generated for the user during registration. In another embodiment, encryption is performed directly using the public entity key. In a further alternative embodiment, user data is encrypted by a two-step sequential encryption process, first with the user data key and then with the public entity key, or vice versa. In yet another embodiment, the user device derives a further key from the public entity key according to a predefined procedure, which is then used to encrypt the user data. For example, the further key can be derived from the public entity key and the user data key.

[0097] The entity key can be a master key or the key of a dependent entity associated with the entity. For example, in the case of the public health department, it could be the master key of the public health department itself or a key of the public health department responsible locally.

[0098] The user data key can be provided, for example, for registration purposes by the user device's operating system. For instance, the user device might have a binary symmetric source for generating high-entropy random values.

[0099] The user data is stored on the server in a form that initially prevents the server from decrypting this user data, as this is not possible without the private entity key and / or the user data decryption key corresponding to the user data key.

[0100] In some embodiments, the user data key is a symmetric key, meaning that the user data key used to encrypt the user data and the user data decryption key used to decrypt it are identical. In an alternative embodiment, the user data key and the user data decryption key are an asymmetric cryptographic key pair, with the user data key used for encryption and the user data decryption key used for decryption. This user data key is persistently stored in non-volatile memory on the user's device. Upon registration with the server, the server generates a user ID, a unique identifier for the user in question, which the server returns to the user's device. The user ID is also persistently stored in non-volatile memory on the user's device.To record a user when visiting a venue, the following procedure is used, for example:

[0101] The user device generates a trace ID that is representative of a combination of the user ID and a current time value. This current time value is the time the user checks in at the venue, determined by the user device via the network. Preferably, this current time is rounded according to a predefined rounding procedure, for example, rounded up or down to the nearest minute.

[0102] Furthermore, the user device generates encrypted ID data by encrypting, for example, the user ID and the user data decryption key required to decrypt the user data with the public entity key. The encrypted ID data therefore contains only a user ID instead of the user data itself, and is thus so small that the encrypted ID data, along with the trace ID and optional additional data, can be transmitted quickly and efficiently to the venue device. This can be done, for example, by encoding this data in a QR code, displaying it on the user device's screen, and capturing it with a camera on the venue device. Optional additional data includes, for example, the timestamp used to derive the trace ID, as well as, if applicable, a verification data value and / or a QR code version.

[0103] The aforementioned information can also be transmitted during an automated check-out, preferably using the same trace ID as during check-in, with the currently recorded time transmitted to the venue device representing the check-out time. According to embodiments of the invention, the venue device checks, for the purpose of user registration during check-in, whether the time information on which the trace ID is based is sufficiently current. For this purpose, it also uses, for example, time information obtained via a network to synchronize with the time base used by the user device and / or as a reference value for comparison with the time information received from the user device. The time information is considered sufficiently current if, for example, it lies within a predefined tolerance range, i.e., if it is not older than a few seconds or minutes.According to one embodiment, the time information in the Trace ID is encoded in such a way that it cannot be extracted from the Trace ID by the venue device. In this case, the user device can transmit the check-in time, which was used as the basis for deriving the Trace ID, to the venue device in addition to the Trace ID. This allows the venue device to compare this additional time with a reference time (e.g., the system time of the venue device or one from a time server via the internet). If the time information on which the Trace ID is based is sufficiently current, the venue device, according to embodiments, transmits the Trace ID to the server along with a Venue ID assigned to the venue device and preferably also other data, such as, in particular, a ciphertext (i.e., the identification data encrypted with the public entity key) and, if applicable, one or more of the other data.This information is stored on the server, preferably using the trace ID as a search key. For example, a searchable index can be created in a database using the "Trace ID" column to enable efficient searching of all check-in records of users registered with the server against venues registered with the server.

[0104] Preferably, this is done for as large a number of users as possible, ideally for all users who visit a venue, in order to capture all users as comprehensively as possible.

[0105] Subsequently, it may be necessary to disclose to the entity the user(s) who visited the venue. This is the case, for example, if one of the users tests positive for COVID-19. This COVID-19-infected user reports this to the entity, in this case the public health department, and provides the entity with their user ID and user secret. Based on this information, all possible past trace IDs that could have been used to track a user by a venue device for a specified period are then generated. This generation can take place, for example, on the server or on an entity device, provided the necessary data is available.The set of these possible trace IDs, also known as "candidate trace IDs," is typically relatively limited, as not all possible times within the relevant period are considered, but only those that can actually occur due to the predefined rounding procedure. For example, to trace a user over a period of two weeks using a derivation function based on time values ​​recorded and rounded down to the minute, approximately 20,000 candidate trace IDs are calculated for a given user ID: 14 ​​days x 24 hours x 60 minutes.

[0106] These candidate trace IDs are then used as a search criterion to locate corresponding trace IDs stored on the server for the past period, thus determining the venue IDs of those venues where the user was recorded during that period. This provides the public health department with the venue IDs of the identified venues the user visited during the past period, for example, two weeks, during which they may have already been infectious. A comparison of 20,000 data points via a searchable database index can be performed very quickly and usually in real time using today's database technology.

[0107] According to one embodiment of the invention, the electronic system is configured such that, after a user check-in, a check-out time is transmitted from the user's device to the server when the user leaves the venue. This check-out time is assigned to the trace ID previously received for this user, so that the server has information about the period during which the user was at the venue. Alternatively, this information can be provided by the venue device.

[0108] According to one embodiment of the invention, this check-out is performed either manually by entering the time into the user's device or automatically by so-called geofencing. In the latter case, the check-out time, along with the associated trace ID, is automatically sent from the user's device to the server as soon as the user leaves the venue. Alternatively, this can be done by the venue device itself.

[0109] Preferably, this information is used to identify other users who were also present at the venue by limiting the search to users who not only visited the same venue but were also there for a period of time that overlaps at least with the identified user's stay. For example, the server's check-in records, which contain the users' trace IDs, can also include the venue IDs and check-in, and optionally check-out, times in plain text. This allows the identification of check-in records of users who were in a specific venue at the same time as the user to whom the emergency relates. The venue ID can be, for example, the name and / or address, an identifier, or the geographical coordinates of the venue. Further embodiments of the invention are explained in more detail below with reference to the drawings.

[0110] They show: Figure 1: A flowchart of a user tracing procedure; Figure 2: A block diagram of a distributed electronic system for user tracing; Figures 3A-3C: Various examples of user data generation and storage ("User Data Package"); Figures 4A-3C: Various examples of the content of a check-in QR code; Figures 5A-5C: Various examples of check-in data generation and storage as stored on the server; Figures 6A, 6B: Examples of venue-relevant additional data; Figure 7: A UML diagram of an example of the tracing procedure. Figure 1 shows a flowchart of a method for tracing users. According to an embodiment of the invention, the procedure is as follows: a) Registration step102: A range of user-specific data is generated for the user, some of which is stored on the server with which registration takes place. Specifically, a user ID and a user-specific encryption key (user data key), as well as optionally other data values, are generated for the user. The user data key can, for example, be a symmetric key. The user specifies their personal data (user data) to be stored encrypted on the server, such as name, address, and contact information. The user encrypts this user data using their device, i.e., an app running on it, encrypting their sensitive data with their user data key. Optionally, the user data can also be encrypted using a public entity key (preferably generated anew daily), such as a public health department key or, depending on the implementation, a key derived from one.According to another implementation variant, the user data is encrypted only with the public entity key. However, the implementation variant with user-data-key-based encryption is more secure and offers better data protection. The app on the user's device uploads this encrypted sensitive data to the server. The server assigns a user ID to the encrypted sensitive data received from the user's device and returns this user ID to the user's app. This user ID is stored by the app in the user's device's memory. b) Check-in step 104:The user device calculates a current tracing ID and transmits it to a venue device along with other check-in data, for example, by encoding this data in a QR code and scanning it. The venue device thus receives the trace ID from the user's device and, if applicable, other check-in data. Depending on the implementation, this can occur so that the trace ID from the user device contains the user ID in plain text or in an encrypted or hidden form. In the latter case, the server cannot even anonymously trace a user based on the trace ID; other methods for generating the trace ID are also possible if tracing based on the user ID is to be prevented. The venue device adds a timestamp representing the check-in time and the venue ID to the trace ID and sends this (possibly encrypted) to the server. In other implementations, a venue device is not required at the venue.The user device reads the venue ID and, if applicable, other venue-related data (e.g., via a QR code on a carrier object or via a near-field signal), performs the check-in using a module of the app representing the venue, and sends the generated check-in data, along with the venue ID, directly to the server. c) Check-out step: A check-out timestamp is sent from the venue or the user device to the server and assigned to the user ID (or a cipher copy thereof). 3. Infection / Emergency Scenario:

[0111] a) The user provides the public health department with their user ID and, if applicable, other data. This allows the department to determine, using the data stored on the server, which venues the user has visited, for example, in the last two weeks. For this purpose, an entity device of the department can, for example, send a message containing this user's user ID to the server in step 106; b) The server then generates a large number of candidate trace IDs in step 108 based on the user ID and, optionally, the other data; c) In step 110, the system queries which venues the user to be traced checked in at during a past period. For this, a search is performed using the candidate trace IDs in the server's check-in records to obtain a list of the venue IDs of the visited venues; d) In step 112, the determined venue IDs are displayed.e) Then, in optional further steps, it is queried which user IDs were at the venues at the same time as the infected user during the relevant period. f) The encrypted, sensitive data records of these users can then be decrypted with the private entity key, e.g., the public health department key, and contacted by the public health department. This can be done, for example, as follows: using the venue IDs, check-in times, and optionally available check-out times, all of which are contained in plaintext in a check-in record, all check-in records belonging to check-in processes that overlapped in time with the check-ins of the user being traced at the same venues are identified.The check-in data of the contacts (and potential infected persons) thus obtained contains, for example, encrypted identification data of the respective contacts, which is encrypted with the public entity key of the health authority and can therefore be decrypted by the authority. The decrypted identification data of the contacts, in turn, contains the user data decryption key, which the health authority can use to decrypt the user data of the contacts in order to inform them that they visited the same venue as an infected person for a certain period of time.

[0112] Figure 2 shows a block diagram of a distributed electronic system 200 for tracing users.

[0113] System 200 comprises a server 202, which is provided, for example, by an operator of a contact tracing service. The server can include a backend application 212, which may include various functionalities, such as a function for registering users 240, venues 242, and entities 246, and / or for storing, managing, and searching user and check-in data, and / or for generating candidate trace IDs. To store the data, in particular contact details of the users, venues, and entities registered with server 202, and to store check-in and / or tracing records, the backend server may include a database 214 or be operationally linked to one. The database may be, for example, a relational database or another form of structured data storage.

[0114] In some examples, the server may include an email service (218) and / or an SMS service (216), which can be used to contact users registered with the system if necessary, for example, to warn them that they were in a particular venue at the same time as an infected person. The SMS service can be used to validate phone numbers.

[0115] According to embodiments of the invention, the system further comprises several user devices 204, each assigned to a user 240. The user devices are data processing devices, in particular portable data processing devices, for example, mobile phones. The users to whom the user devices are assigned are persons who can temporarily reside in different spatial areas (venues) and thus act as (paying or non-paying) guests of the venue. An application program 214, referred to here as a guest application, can be instantiated on each of the user devices, which is interoperable with the backend application program 212 of the server 202. The application program 218 can, for example, be designed as an app and include various functions.The functions may include, for example, a function 222 for registering the user with the server 202, a function 226 for checking in the user 240 to a venue, a function 228 for self-check-in to a venue that is equipped with a carrier object with an automatically detectable venue ID instead of a venue device, and / or a functionality 224 for transmitting a tracing secret transfer object with user-related sensitive data in order to grant an entity 246 access to the user's user data.

[0116] According to embodiments of the invention, the system further comprises several entity devices 208, each assigned to an entity 246. The entity is a trusted, generally sovereign authority, for example, a government office or agency, such as a public health department. In order for the entity to use the tracing system, it must register with the server 202. During the registration process, an asymmetric cryptographic entity key pair is generated, which, according to embodiments of the invention, is regularly replaced, for example, daily, by a currently valid key pair.The public part of this key pair is provided to server 202 to enable it to distribute the entity's public encryption key to user devices 204 and / or venue devices 206. This allows these devices to use the entity's public key to encrypt specific parts of the check-in records (especially the ID records) and, optionally, the user data before the data is uploaded to the server and stored centrally in database 214. It is possible that several different entities (for example, a health authority) have registered with the server and that each entity has multiple entity devices, such as data processing devices (computers) belonging to the authority's employees.According to embodiments of the invention, multiple entities can be integrated into the system by using the same asymmetric entity key pair for encrypting and decrypting check-in data and / or user data. This can be achieved, for example, by the entity application including a function for synchronizing both the public and private parts of this asymmetric cryptographic key pair with all other entity applications of the same or a cooperating entity (or all entities that are intended to function as a single entity). Preferably, at least the private parts of the key pair are exchanged and synchronized in encrypted form, for example, by encrypting them with a public transport key of the respective receiving entity device.

[0117] According to one embodiment, the synchronization of entity keys between multiple employees and entity devices of an entity is achieved through daily key rotation: The keys are identified by a key ID (integer) that is incremented with each new key. The rotation is triggered by each employee of the public health department who logs in after the expiration of the last public entity key, which was valid for, e.g., one day. The daily public entity key is the sole property of the public health authorities and is used to secure the user's check-in data.

[0118] The rotation process involves transferring the entity's currently valid daily public key to the user's device during registration and / or check-in. This allows the user's device to use the key to encrypt ID data during check-in and, optionally, user data during registration. A daily key pair expires after 24 hours. When a daily entity key pair expires, the agency employee generates a new one for the current day. The entity application uploads the new public key to the server, and the server automatically distributes it to users' devices via the network. Additionally, participating entity devices download the respective (static) public keys of the other entity devices within the same entity.The entity device that just generated the current daily entity key pair encrypts the current private entity key (valid for the day) using the public static keys of the other entity devices. It then sends this resulting ciphertext to the respective entity device, which decrypts the ciphertext and thus also receives the daily private entity key. It is also possible for different public health departments to exchange new private entity keys daily (or at another predefined interval) using this key rotation procedure.

[0119] This process preferably takes place fully automatically in the background without active intervention from the office staff and / or individual users.

[0120] According to embodiments of the invention, the system further comprises several venue devices 206 of several different venues 242. It is possible that several venue devices 206 are attached to a single venue, for example, one device at each of several entrances to the venue. A venue application 230 can be instantiated on each venue device, which includes, for example, functionalities 232, 234 for a user check-in process to the venue and / or for registering the venue with the server 202. For example, the venue device 206 can include a camera configured to capture a QR code displayed on a screen of the user device 204, in which check-in data of a guest is encoded. The QR code is decoded by the venue application 230, and at least some of the encoded data is stored on the server 204, linked to a venue ID of the venue 242.

[0121] Optionally, the system can include one or more additional data processing devices 210 for generating static graphic codes. This can be advantageous because it allows people who are not very IT-savvy and cannot or do not want to create their own user account to use the tracing system 200. For example, an employee of a care facility can register themselves or the facility as a user with the server 202 and instruct the data processing device 210 to generate a specific quantity, for example, 50 or 100 QR codes. These pre-generated and not yet personalized QR codes can be distributed to the residents of the care facility to allow them to visit a venue (for example, a concert hall, a theater, etc.) without having to create their own account.The person who ordered the QR codes and received and printed them, for example by mail or via the internet, distributes the QR codes to the guests of the nursing home and, in the course of distribution, notes the assignment of the issued QR code to a specific person.

[0122] For example, the ordered QR codes can be assigned a serial number, and the nursing staff creates a list, either manually or electronically, that assigns each issued code to the person who received it. This list can be created on paper, for example, or it can be generated and saved using a function within an application on the 214 generator device, which might be accessed via the internet.

[0123] The individual components of the system are interconnected via network 244. This network can be, for example, the internet, and data can be transmitted via wired and / or wireless connections. For instance, data transmission between user devices 204 and server 202 can occur via a cellular connection or Wi-Fi. The transmission of check-in data from a user's device to a venue device 206 can occur, for example, via an optical data transmission channel and / or a near-field signal such as Bluetooth.

[0124] The table below shows various process steps according to an embodiment of the invention, which are carried out by different system components, as well as the respective input and output data. Steps Goal Input data Output data Venue registration (with the server) Enables private and commercial venue operators to automatically register guests and trace them retrospectively in case of emergency. Email, password, location information Venue-specific asymmetric key pair: venuePrivKey and VenuePubKey Entity registration (with the server) Allows employees of a government agency to trace visitors to venues. certificate Entity-specific asymmetric key pair: healthPrivKey health-PubKey User registration (on the server) Allows the user to automatically check in and out using the system. User data, in particular address and contact details anonymized QR code, userPrivKey, userPubKey, multiple secrets User check-in / out at a venue Transmission of anonymous contact information to the venue operator. Scanner check-in. Self-check-in via QR code on carrier object. anonymous QR code Uploaded check-in data Contact tracing (emergency / infection) Transmission of user contact data to the health department. Identification of potential contacts by the health department, optionally only after approval by the venue. TAN of the infected user, private decryption key of the health department healthPrivKey Venues visited by the infected person, contact details of possible contacts

[0125] Figures 3A-3Cshow various examples of the creation and storage of user data ("User-Data-Package", "User-Data-Dataset").

[0126] Figure 3A Figure 1 shows a user data record 300 as it is stored on server 202 according to one embodiment. The record 300 includes at least one user ID 302 in plaintext, which is linked to other user-related data stored on the server. This other data includes at least encrypted user data 306 of a person. Optionally, the user data record 300 may contain further personal data, for example, a public key 304 of an asymmetric cryptographic key pair, which was specifically issued for this user during their registration. Optionally, the user data may contain further data such as a signature 308.

[0127] In the lower part of the Figure 3AThis illustrates how different parts of the user data 300 can be generated. For example, the encrypted data 306 can be generated by encrypting the user's personal user data 314, such as the user's name, address, and / or other contact information, with a user data encryption key 310. For example, the key 310 could be a symmetric cryptographic key that was specifically generated for the user during registration and which also enables the decryption of the encrypted data 306. Preferably, the personal user data 314 is encrypted together with a user-specific verification secret 316 by the user data key 310, and / or the secret 316 is used as a parameter during encryption to generate the encrypted user data 306.

[0128] In an alternative implementation, the UserDataKey is generated as an asymmetric cryptographic key pair during user registration. In this case, only the private part used for decryption needs to be securely stored on the user's device and transmitted to the server in encrypted form as part of the ID data or check-in data during check-in.

[0129] The optional signature 308 can be generated, for example, by a private cryptographic key (signature key) 312, which was specifically generated for the user during registration, signing the encrypted user data 306 and the user data key 310 used to encrypt the user data 314. The public key 304 can be a signature verification key corresponding to key 312. This allows the authority to check whether the user data record has been subsequently manipulated after its storage and signing.

[0130] In Figure 3BA user data record 320 is shown according to a further embodiment. Data values ​​or keys of record 320 that correspond in content and / or function to one of the data values ​​or keys of record 300 are marked with the same reference numbers. The box enclosed by the frame identifies the user data record as it is stored on the server. The boxes below represent input data values ​​or keys that were used to generate corresponding elements of the user data record. The mac is a Message Authentication Code, which was generated, for example, using an HMAC-SHA256 algorithm based on the encrypted user data 306. The abbreviation "iv" represents a random value. In this case, the signature includes not only the encrypted user data 306, but also the mac and the random value iv.

[0131] In Figure 3CA user data record 330 according to a further embodiment is shown. Data values ​​or keys of the data record 330 that correspond in content and / or function to one of the data values ​​or keys of the data record 300 are marked with the same reference numbers. The box enclosed by the frame identifies the user data record as it is stored on the server. In the embodiment shown here, the encrypted user data 306 is formed by double encryption. In a first encryption step, the personal user data 314 and preferably also a user verification secret 316 are encrypted with a public entity key 332. The ciphertext generated in this step is re-encrypted in a further encryption step with the user-specific user data key 310 in order to obtain the (doubly) encrypted user data 306 and store it on the server.

[0132] According to one embodiment, the user of the app (application program) 218 ​​provides their contact information 314 to their user device during a registration process. The application generates an EC secp256r1 key pair (user public key and user private key) 312, 304, a user trace secret 410 (16 bytes entropy), a user verification secret 412 (16 bytes entropy), and a symmetric user data key 310 (16 bytes entropy).

[0133] The user data key 310 is used to encrypt the personal user data 314 in order to obtain the encrypted user data 306.

[0134] In some implementations where encryption using an entity key is also used, the application can calculate an encryption key with ECDH using the user's private key and the public master key (entity key) of the public health department. App 218 calculates an HMAC-SHA256 with the ECDH output as the data and the data key as the key. The application then encrypts the personal information and the user verification secret with this encryption key, for example, using AES-128-CBC.

[0135] Application 218 then uploads this encrypted data to server 202 and signs it with the user's private key 312 along with the user's public key. The server returns a user identifier, i.e., U-ser-ID.

[0136] The following are stored on the user device: user id (uuid) 302, user public key (ec secp256r1) 304, user private key (ec secp256r1) 312, user data key (16 bytes random data) 310, user trace secret (16 bytes random data) 410, user verification secret (16 bytes random data) 412.

[0137] Figures 4A-3C Examples 400, 420, and 430 show the content of a check-in QR code. If a user's check-in data is not transmitted to the venue device using a graphical code, but rather, for example, a near-field signal, the data is represented not as a graphical code, but as a near-field signal, such as a Bluetooth signal.

[0138] For example, the user device may contain its own clock, especially a real-time clock, and / or regularly receive the current time from a time server via the network.

[0139] When a user takes steps to check in to a venue, such as launching an app or interacting with a corresponding GUI element of the app (e.g., to generate a graphical check-in code), the user's device captures a current time value (404) and performs a derivation function on this time value (404) and the user ID (302) to obtain a trace ID (406). Preferably, this derivation incorporates a tracing secret (410), which could be, for example, a random value assigned to the user during registration and securely stored on the user's device. Preferably, the derivation function ensures that the user ID is not visible in plain text from the trace ID, and preferably, it is not apparent from the trace IDs whether they belong to the same or different users. The fact that a current time value (404) is incorporated into the trace ID (406) is symbolized by the asterisk.

[0140] Similarly, venues, each represented by one or more venue devices, can also register with the server. The data provided during registration can include, among other things: venue name, contact person's name and email address, venue address, venue coordinates, and / or check-in radius.

[0141] The data set 400 as in Figure 4AThe data shown also contains encrypted ID data 408, which is generated by encrypting the user's user ID 302 and the user-specific decryption key 310 (for example, the symmetric user data key) using the entity's public encryption key 332. The ID data 408, which contains the encrypted user ID, allows this check-in record to be assigned to a specific user, but only by a party that can decrypt the ID data 408 (i.e., the entity). Since the ID data only contains the user ID and not the complete user data 314, it is small enough to be encoded within a QR code.When the office uses its private entity key to decrypt the encrypted ID data 408, it not only learns the user ID of the user to whom this check-in record 400 belongs, but also receives the decryption key 310, which is necessary to find out the user's contact details.

[0142] Optionally, the QR code data set 400 can also contain a verification data value 414, which provides additional protection as it allows the entity to check whether the check-in data set has been manipulated.

[0143] According to one embodiment, the verification data value 414 is generated by encrypting the trace ID 406 and the encrypted identification data 408 with a user verification secret 412. The user verification secret is preferably a random number that is generated during the user's registration with the server and is securely stored on the user's device.Therefore, if an unauthorized user were to attempt to steal another user's Trace ID and use a manipulated check-in record with the stolen Trace ID, the unauthorized user would not be able to generate the verification data value 414 corresponding to that Trace ID, unless the unauthorized user also gains possession of the authorized user's device, since only there is the user verification secret 412 stored, which is necessary to derive the verification data value 414.

[0144] The user device is configured to regularly check whether the currently generated check-in data is still valid. If the trace ID derivation function always uses the current time, rounded down to the minute, as the timestamp 404 to derive the trace ID 406, a QR code or check-in record 400 is considered outdated as soon as the new minute has begun. In this case, the user device automatically discards the current check-in record 400 or the QR code 400 and generates a new, current check-in record based on the current time information 404, i.e., based on the newly started, rounded-down minute, as described above.

[0145] If the venue is not assigned a venue device, but only a carrier object on or to which the venue ID is attached in such a way that the user device can automatically detect it, the check-in record 400 can be generated by the user device without being transmitted to a venue device and without containing information about a QR code version or other technical parameters for data transmission to a venue device. Instead, such a record can then be directly enriched with the venue ID received by the user device and transmitted to the server as a complete check-in record.

[0146] In Figure 4BA check-in data record 420, or a QR code encoding it, is represented according to a further embodiment. Data values ​​or keys of data record 420 that correspond in content and / or function to one of the data values ​​or keys of data record 400 are marked with the same reference numbers. The first two lines of the data structure of Figure 4BThis shows the portion of the check-in data record 420 as it is transmitted to the venue device (in the case of check-in variants with a venue device). The boxes below represent input data values ​​or keys used to generate the corresponding elements of data record 420. Data structure 420 also contains further optional data values, such as version 402 of the algorithm used to generate the QR code ("QR code version"), the device type of the user's device, an identifier of the (daily updated) asymmetric cryptographic entity key pair, the public part of which was used to encrypt the ID data, etc. In addition to or as an alternative to the check-in time 404, which is present in plaintext, a check-out time may also be included.

[0147] In Figure 4CA check-in data record 430, or a QR code encoding it, is represented according to another embodiment. In contrast to data structures 400 and 420, in data structure 430 the user verification data value 414 is derived indirectly from the current time (via the trace ID).

[0148] Figures 5A-5C show various examples of how check-in data is generated and stored on the server.

[0149] During the check-in process, the venue device receives check-in records 400, 420, and 430 from the user's device. The data contained in the received record can be combined with other data, particularly the venue ID, to create a complete check-in record, which is then stored on the server. Thus, the server's check-in records can resemble records 400, 420, and 430, each linked to additional data, especially the venue ID of the venue on the device.

[0150] At least some of the check-in records may actually be check-out records, and may contain the check-out time 504 in addition to or as an alternative to the check-in time 404.

[0151] In some embodiments, the venue device performs further data processing steps with the check-in data 400, 420, 430 received from the user device in order to generate the finished check-in data records to be transmitted to the server based on the check-in data records received from the user device.

[0152] For example, during registration, each venue can be assigned a symmetric or asymmetric key pair, and the venue device can use the private part of the key pair (in the asymmetric case) to encrypt at least parts of each check-in record (apart from the trace ID, which must be in plaintext). Some parts of the check-in record are therefore encrypted two or even three times: for example, the ID data (408) is generated with the entity's public key (332), it can optionally be additionally encrypted with the user's user data key (310), and optionally also with the venue's public key.This can have the advantage that the entity can only trace users who have visited a venue with the venue operator's consent, since the operator must first decrypt "their" check-in records before an entity device can process them. In addition to the ID data ciphertext 408, the venue device can, for example, also encrypt the timestamp 404, the user verification data value 414, and other data with the private venue key 512 to obtain the encrypted check-in data 506, which is then uploaded to server 202.

[0153] The Figures 5B and 5C The first two lines show further alternative variants for check-in records as they are stored on the server, as well as the data values ​​and keys used to form the values ​​stored on the server below.

[0154] According to some implementations, the venue, i.e., the venue device, first checks, upon receiving check-in data, whether the timestamp 404 is of a more recent date and does not perform any further validation.

[0155] According to further examples, the encrypted check-in data 506 can be formed by the app 218 generating a signal for each check-in to transmit the trace ID, which is transmitted via direct communication, for example by displaying a QR code, whereby an ephemeral ECC key pair secp256r1 and an encryption key are preferably generated for each new QR code.

[0156] The trace ID 406 can be, for example, an HMAC-SHA256, which is derived from the user ID 302 and the current timestamp 404 (rounded down to the current minute) as (input) data and the user trace secret as the key, and is truncated to the first 16 bytes.

[0157] The encryption key is calculated using ECDH from the ephemeral private key and the public key of the public health department. The app will display a QR code with the following content (which is updated every minute with the current timestamp): QR code version (1 byte) 402, timestamp (4 bytes) 404, trace ID (16 bytes) 406, encrypted data (32 bytes) 408, (data key and user ID encrypted with AES-128-CBC and the encryption key as the key and the trace ID as the IV) ephemeral public key (33 bytes) verification tag (8 bytes) 414, (HMAC-SHA256 with trace ID and encrypted data as data and the user's verification secret as the key, truncated to the first 8 bytes).

[0158] The total payload is 94 bytes, which are concatenated and then encoded with ASCII85 as the QR code content. The ephemeral key pair can be discarded.

[0159] The venue encrypts the encrypted data received from the user's device, the ephemeral public key, and the verification tag, for example, using AES-128-CBC with the ECDH of an ephemeral key pair and the venue's public key. The venue then generates an authentication key using HMAC-SHA256 with the trace ID 406 as the data and the verification data value ("verification tag") 414 as the key. The venue will upload the check-in time, the encrypted data, and the authentication key to the server.

[0160] When the user checks out via the app (geofence or manually), the app 218, according to embodiments of the invention, sends a checkout timestamp 504 and an HMAC-SHA256 with the checkout timestamp as data and the authentication key (HMAC(data=trace id, key=verification tag) as key).

[0161] The production of the in the Figures 4 and5 The data structures shown can be implemented, for example, by having the app 218 generate a trace ID for each new QR code on the user's device. The trace ID is an HMAC-SHA256, derived from the user ID and the current timestamp (rounded down to the current minute) as data, and the user tracing secret as the key (truncated to the first 16 bytes). The user ID and the user data key are encrypted using the asymmetric encryption scheme described above for the current DailyPublicKey, with the IV in records 420 and 520 of the Figures 4B and 5B defined as the first 16 bytes of the ephemeral Public Key.

[0162] According to another example, App 218 generates a QR code with the following content (which is updated every minute with the current timestamp) (see Figures 4B and C): App Badge Data, QR code version (1 byte), device type (1 byte), key ID (2 bytes) (indicates which DailyPublicKey was used), timestamp (4 bytes), trace ID (16 bytes), encrypted data (32 bytes) (userDataKey and user ID encrypted according to the asymmetric scheme for the public entity key described above, with the first 16 bytes of the ephemeral publicKey as the IV), ephemeral public key (33 bytes), and verification tag (8 bytes) (HMAC-SHA256 with timestamp and encrypted data as data and the user's verification secret as the key, truncated to the first 8 bytes). The total payload is 95 bytes, which are simply concatenated and then encoded with ASCII85 as QR code content.

[0163] The venue device at the event location will first extract the received encrypted data from the QR code. The device will then preferably check the validity of the 404 check-in timestamp contained in the code and discard the code if the timestamp is older than a maximum age, e.g., 30 seconds.

[0164] The venue device can then create the following data set, for example, using concatenated values ​​(|| as the concatenation operator): AsymEnc_priv_Venue-Key(keyld || ePubKey || verificationTag || encData || venuePublicKey). This generates the value encCheckInData. Afterwards, the user device uploads the following data to the server: Trace ID, Venue Device ID, timestamp, encCheckInData.

[0165] The server stores, for example, at least the trace ID, the venue ID ("locationID" or "scannerID"), check-in time, the encrypted data encCheckINData, the MAC value, IV and the ephPublicKey.

[0166] In an alternative embodiment without a venue device, the venue operator provides only a physical medium, such as a table display with a QR code encoding the venue's ID. The user scans the QR code with their smartphone; the code contains a URL. This URL includes the venue ID, and scanning the URL prompts App 218 to retrieve the venue's information from Server 202, along with optional additional venue data. App 218 can register this URL as a universal URL (deeplink) and retrieve the venue ID and venuePublicKey from the server via this deeplink. In another embodiment, this data is already encoded in the QR code.The App 218 then generates all the information from the QR code as described above and processes it like the Venue device described above (re-encrypting the QR code data with venuePublicKey 512 and uploading the Trace ID, Venue ID, check-in time, encrypted data, mac, iv and the ephemeral public key to the server).

[0167] Figures 6A, 6B Examples of venue supplementary data 600 and 620 are shown. Depending on the implementation, the venue supplementary data can be stored only locally on the venue devices and / or on the server linked to the venue IDs. This supplementary data refers to data relating to the user and / or their environment during the check-in process.

[0168] For example, the additional data can include further information that the venue operator needs to automatically provide the user with certain services during their stay and / or to document and / or organize the visit in venue-related management software. For example, the additional data can include a table number and identify the table where a guest is seated. The additional data can relate to a service or ride that the visitor has selected via an app on their device and / or to data that, for example, serves to initiate an automated payment process. For example, during or after a successful check-in, the venue device can send a request to the user's device, prompting the user to enter further additional data via a graphical user interface.The user enters the data relevant to the venue (table number, booked ride, additional services or amenities, user's age, etc.). The user's device then generates a data object (for example, in JSON format) containing the entered data and sends this back to the venue device. For example, applications 218 on the user's device and 230 on the venue device can be implemented as interoperable applications of a distributed software system for the secure and privacy-compliant tracking of visitors.

[0169] Preferably, the venue's additional data (604) is stored locally and / or on the server in encrypted form (602), linked to a trace ID (406) of the check-in process in which the additional data was collected. For example, a venue-specific encryption key (512) can be used for encryption so that the server cannot access the data, or can only do so with the venue operator's consent.

[0170] Storing venue-specific data can be advantageous, as it allows for a more precise reconstruction of the visitor's location based on, for example, the table number or the chosen amusement park ride.

[0171] Additionally or alternatively, during the check-in process, the user's device can also generate supplementary user data, which is encrypted with the UserDataKey (i.e., the user-specific (public asymmetric or symmetric) encryption key of this user) and / or with the entity key. This supplementary data is also related to the check-in process and can facilitate the subsequent tracing of this user and / or their companions or contacts. For example, the 218 app can be configured to prompt the user during check-in (or beforehand) to specify which companion they will be entering the venue with and / or which other people in the venue they intend to visit.Therefore, if a visitor to a hospital arrives accompanied by children and / or visits a specific patient, this information about the children or the patient can be included as additional user data during check-in and stored on the server as part of the check-in record. This makes it easier to identify individuals who had contact with the person being traced, whether as accompanying persons, those being visited, or in any other capacity, even if these individuals have not registered with the server.

[0172] Figure 7 This shows a UML diagram of an example of the tracing procedure. The people or system components represented by the dashed lines correspond to those in Figure 2The components shown. According to the embodiments, the user tracing procedure integrates the entire process from the first contact of an infected guest with the public health department to the disclosure of contact details of potential contacts to the department. To identify the contacts, the public health department requires the TAN (transaction authentication number) of an infected person.

[0173] The examples described here with regard to a public health department and a pandemic situation also apply analogously to other types of entities and emergencies.

[0174] Figure 7This illustrates the case where a user (guest) who has visited various venues in the past receives a test result indicating that the user is or was infected with a contagious disease (e.g., Covid-19). The user, a doctor, or a laboratory reports this test result to the health authorities. In the event of an infection, the infected guests are contacted by the local health authorities. During this contact, the infected guest is asked whether they are using the tracing system according to an embodiment of the invention described herein, and they are requested to disclose their personal data and contact history for automatic contact tracing.

[0175] The infected guest in question initiates the tracing process by uploading a data transfer object (tracing secret transfer object) containing various secrets. App 218 creates the tracing secret transfer object for exchange, for example, as follows: Serialize userID, userDataKey, and userTracingSecret into a JSON object; asymmetrically encrypt the serialized JSON object with the current entity key, dailyPublicKey, valid for that day. The user's device then uploads the resulting encrypted data, and optionally also iv, mac, and ephPublicKey, to Server 202 and stores it on the server as this user's tracing secret transfer object. The server will generate a TAN, store it on the server linked to the aforementioned tracing secret transfer object, and return the TAN to the user's device. For example, the server can return the TAN to the user's device, where it will be displayed on the device's screen, and the user can then provide the TAN to the public health department by phone. Only with the TAN can the public health department use the data on the server for contact tracing.

[0176] After contacting the infected guest, the public health department employee enters the TAN (transaction authentication number) into their public health department's frontend application. The employee is logged in, for example, using the certificate generated during the registration process, which verifies the user's identity.

[0177] Reference to the entity key: For the process to begin, the health department employee needs access to all relevant DailyKeypairs of the health department. Therefore, they retrieve the encrypted, daily generated asymmetric key pair of the health department (HealthDepartmentEncryptionKeyPair), which they can decrypt using their personal private encryption key. With the locally decrypted HealthDepartmentEncryptionKeyPair, they can retrieve and read the EncryptedDailyKeypairs.

[0178] In embodiments where only a static, long-term valid asymmetric key pair is created for the entity, obtaining the entity keys can also be simpler and involve reading the private entity key. Retrieving the personal data of the infected guest:

[0179] After the registered employee receives the TAN from the user (e.g., by phone, email, or postal mail), the employee sends a tracing request to the server, including the TAN. The server identifies the tracing information transfer object associated with the TAN and makes it available for download to the employee. This transfer object is preferably encrypted with the health department's current public key and is decrypted by the employee using the corresponding private key.

[0180] The decrypted secrets of the tracing secret transfer object now available to the health department contain the Userld and the UserTracingSecret of the user to be traced, so that the department (i.e. an entity device assigned to the department) can calculate the candidate tracing IDs of this guest for, e.g., the last 14 days (20,160 candidate trace IDs). Identification of visited venues and potential contacts

[0181] The public health department sends a request to the server containing the calculated candidate tracing IDs. The server searches its check-in records in its database and identifies all venue IDs of all check-in records whose trace IDs are identical to one of the candidate trace IDs transmitted in the request. The contact details of these identified venues are then returned by the server to the department.

[0182] The public health department can then request that the venues (or their devices) grant access to all check-in records of individuals who were present at the venue at the same time as the infected users. The venues will be contacted, for example by email, to inform them about the ongoing contact tracing process and to request access to the check-in records pertaining to that venue.

[0183] With its consent, the venue will download all check-in records (or all check-in records up to a maximum age if the check-in time is included in plaintext) originating from that venue, decrypt them, and, for example, use the timestamps to check which guests might be contacts. The venue device then uploads the check-in data of the potential contacts (whose sensitive data, such as ID information, is still encrypted with the entity's DailyPublicKey) to the server, which forwards this data to the public health department. Alternatively, the venue device can send the data decrypted with the venue's private key directly to the entity device.

[0184] This detour via the venue is only necessary in implementations where the check-in records are additionally encrypted with the venue's public key, and the venue must decrypt the check-in records with the corresponding decryption key so that the entity can process them. If the check-in data is not additionally encrypted with the venue key, it is also possible for the check-in records of the potential contacts, encrypted with the entity key, to be transmitted directly from the server to the entity's device.

[0185] Once the entity device has received all check-in records of the potential contacts in the relevant period and these are no longer encrypted with the venue key, the entity device can decrypt these check-in records using the entity's corresponding DailyPrivateKeys.

[0186] Once the entity computer has obtained both user IDs and user data keys (i.e., the decryption keys required to decrypt the user data) of potential contacts through decryption, the entity device can request the encrypted user data records of these potential contacts from the server, decrypt them using the respective user-specific user data keys, and establish contact with these users. However, the agency cannot conduct contact tracing for these contacts until they provide the agency with their tracing confidentiality transfer object.

[0187] The health authority can now also verify the integrity of the check-in using the verification secrecy.

[0188] It is therefore impossible for any implementation of the electronic system to track users without their consent, as the check-in records are encrypted and the trace IDs used as search keys for these check-in records cannot be correlated without knowledge of further data, such as the tracing secret, which is generated individually for each user and securely stored on their respective devices. The tracing secret is only transmitted to the authorities in the event of an infection and only with the user's consent. Users who have only had contact with an infected user will not disclose their tracing secret and therefore cannot be traced.

[0189] The user's personal data is encrypted at all times and can only be read by individuals who possess the UserDataKey. The UserDataKey can only be obtained by the user themselves or, in encrypted form, by a venue device that has scanned the user's check-in QR code. All decryption operations are preferably performed locally by the respective system components. In some implementations, all data stored on the server and / or system components (user device, venue device, entity device, and / or server) is signed / MAC'd by the data owner (i.e., used as input to a MAC function to calculate a MAC value), preventing any employee from altering the data. Revelation section "System 2", Figures 8-12

[0190] The above disclosure relates to a procedure and system that shall be referred to here as "System 1".

[0191] In another aspect, this disclosure includes a further system ("System 2") for tracing users, particularly for combating a pandemic such as Covid-19, as well as a corresponding digital storage medium on which a computer program or app is stored. "System 2" is, for example, in the Figures 8 to 12 Illustrated embodiments, examples and explanations of the disclosure section regarding "System 1" (illustrated, for example, by means of the Figures 1-7 ) and the part of the revelation concerning "System 2" (illustrated, for example, by the Figures 8-12 These elements can be freely combined, provided they are not mutually exclusive. For the meaning of the terms "mobile device", "server", "venue", and "entity", please refer to the definitions above.

[0192] To limit the spread of Covid-19, the current procedure is to require individuals attending public events or restaurants to provide their personal data. The associated documentation requirements are burdensome for the respective organizers and restaurant operators, especially since data protection regulations must also be observed.

[0193] In contrast, according to the electronic system 2 described here, a system is provided which ensures largely automated tracing while complying with data protection regulations.

[0194] The system is implemented as follows: users first register using their mobile devices. This involves collecting user data, either by entering it directly into the device or by reading it from an electronic identity card. The user data is then encrypted by the mobile device using a public entity key (e.g., a public key from the public health department). The resulting encryption is then further encrypted with a user data key, such as a random value with high entropy, for example, 16 bytes in length. The mobile device can then be used as the user device.

[0195] The mobile device is uniquely assigned to a user. Tracing is intended to take place for an "entity".

[0196] The entity key can be a master key or the key of a dependent entity associated with the entity. For example, in the case of the public health department, it could be the master key of the public health department itself or a key of the public health department responsible locally.

[0197] The user data key can be provided, for example, for registration purposes by the mobile device's operating system. For instance, the mobile device has a binary symmetric source for generating high-entropy random values.

[0198] The user data is stored on the server in a form that initially prevents the server from decrypting this user data, since the encryption is two-stage and, in particular, is not possible without the private entity key.

[0199] The mobile device persistently stores this user data key in non-volatile memory. Furthermore, a user secret is also generated for the user by their mobile device; this can also be a random value with high entropy, for example, 16 bytes in length. Based on the registration with the server, the server generates a user ID, i.e., a unique identifier for the user in question, which the server returns to the mobile device upon registration. The user data key, the user secret, and the user ID are persistently stored in non-volatile memory on the mobile device.

[0200] To track a user's visit to a venue, the following procedure is now used: The mobile device generates a trace ID that is representative of a combination of the user ID, the user secret, and a current time. This current time is the time the user checks in at the venue, which the mobile device determines via the network. Preferably, this current time is rounded according to a predefined rounding procedure, for example, rounded up or down to the nearest minute.

[0201] Furthermore, the mobile device generates a ciphertext from the user data key and the user ID, using the public entity key to generate the ciphertext. The trace ID and the ciphertext are then transmitted from the mobile device to the venue device via direct communication, i.e., not via a network.

[0202] To register a user, the venue device checks whether the time information in the trace ID is sufficiently current. For this purpose, it also uses, for example, time information obtained via a network to synchronize with the time base used by the mobile device. The time information is considered current if, for example, it falls within a predefined tolerance range, meaning it is no older than a few seconds or minutes.

[0203] If the trace ID's timestamp is sufficiently recent, the venue device transmits the trace ID, along with a venue ID assigned to the venue device and the ciphertext, to the server. This information is then stored on the server.

[0204] Preferably, this is done for as large a number of users as possible, ideally for all users who visit a venue, in order to capture all users as comprehensively as possible.

[0205] Subsequently, it may be necessary to disclose to the entity the user(s) who visited the venue. This is the case, for example, if one of the users tests positive for Covid-19. This Covid-19-infected user reports this to the entity, in this case the health department, and provides the entity with their user ID and user secret.

[0206] Based on this information, all possible past trace IDs that could have been used to track a user by a venue device for a given period are generated. The number of these possible trace IDs is relatively limited, as not all possible times within the relevant period are considered, but only those that can actually occur due to the predefined rounding procedure.

[0207] These trace IDs are then used as a search criterion to locate corresponding trace IDs stored on the server for the past period, thus determining the venue IDs of those venues where the user was recorded during that period. This provides the public health department with the venue IDs of the identified venues the user visited during the past period, for example, two weeks, during which they may have already been infectious.

[0208] According to one embodiment of "System 2," the electronic system is configured so that a check-out time is transmitted from the mobile device of a user registered by a venue device (i.e., after check-in) to the server when the user leaves the venue. This check-out time is associated with the trace ID previously received for this user, so that the server has information about the duration of the user's stay at the venue.

[0209] Preferably, this information is used to identify other users who were also present at the venue by limiting the search to users who not only visited the same venue but also stayed there for a period that overlaps at least with the identified user's stay. According to one embodiment of "System 2," this check-out occurs either through manual entry into the mobile device or automatically via geofencing. In the latter case, the check-out time, along with its associated trace ID, is automatically sent from the mobile device to the server as soon as the user leaves the venue.

[0210] The venue ID can be, for example, the name and / or address, an identifier, or even the geographical coordinates of the venue.

[0211] In another aspect, the disclosure of "System 2" concerns a digital storage medium containing program instructions executable by a processor of a mobile device.

[0212] According to embodiments of the system, it can be used for a method of tracing users for an entity with the following steps: Storage of user data of users upon registration on a server, wherein the user data is encrypted by the public entity key and the result of this encryption is encrypted with a respective user data key of the user in question; provision of portable mobile devices, each assigned to a user, wherein a user data key, a user secret and a user ID are stored in each of the mobile devices, wherein the mobile device has access to current time information via a network interface and the mobile device is configured to generate a trace ID that is representative of a combination of user ID, user secret and the current time information, and to generate a ciphertext from the user data key and the user ID, wherein the public entity key is used to generate the ciphertext.and wherein the mobile device has a communication interface for direct communication with a venue device, via which the trace ID and the ciphertext are transmitted to the venue device, capture of one of the users by a venue device using the user's mobile device, wherein the venue device has an interface for direct communication with the corresponding interface of the mobile device, and with a network interface for communication with the server, wherein the venue device is configured to receive the trace ID and the ciphertext from the mobile device for the purpose of capturing the user and to check whether the time information of a received trace ID is sufficiently current, and if so, to transmit the trace ID with a venue ID and the ciphertext assigned to the venue device to the server, storage of a received trace ID and the ciphertext with the time information as an access key by the server,Notification of the user ID and user secret from one of the users to the entity, generation of possible past trace IDs for the user in question within a predefined past period, and use of the generated trace IDs as a search criterion to find corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues from which the user was tracked during the past period are determined, output of the venue IDs of the determined venues to identify those venues that the user visited during the past period.

[0213] According to embodiments of the method described in the context of "System 2", a check-out time is transmitted from the mobile device of one of the users to the server when the user leaves the venue, whereby the check-out time is assigned to the trace ID previously received for this user, so that the user's stay at the venue is stored.

[0214] According to embodiments of this method, those users are identified who also visited one or more of the identified venues during the past period and during a user's stay, for which purpose those trace IDs that were transmitted from the identified venues to the server during the past period are determined.

[0215] In the following, embodiments of "System 2" are explained in more detail with reference to drawings 8-12, each of which shows: Figure 8 shows a user data package containing the user data, which is encrypted twice; Figure 9 shows an embodiment of the trace ID; Figure 10 shows an embodiment for check-in; Figure 11 shows an embodiment for check-out; Figure 12 shows a UML diagram.

[0216] With regard to the Fig. 8 The registration process is described in the context of "System 2".

[0217] The user provides their contact information to the app (application program) on their mobile device. The application generates an EC secp256r1 key pair (user public key and user private key), a user trace secret (16 bytes entropy), a user verification secret (16 bytes entropy), and a user data key (16 bytes entropy).

[0218] The application then calculates an encryption key using ECDH with the user's private key and the public master key (entity key) of the health department. The app then encrypts the personal information and user verification secret with this encryption key using AES-128-CBC and encrypts the output using AES-128-CBC with the user's data key as the key. The application then uploads this encrypted data and signs it with the user's private key along with the user's public key. The server returns a user identifier, i.e., a user ID.

[0219] The following data is stored on the mobile device: user id (uuid) user public key (ec secp256r1) user private key (ec secp256r1) user data key (16 bytes random data) user trace secret (16 bytes random data) user verification secret (16 bytes random data) Check-in (see Fig. 9)

[0220] The app generates a signal with trace ID and ciphertext for each check-in, which is transmitted via direct communication, for example by displaying a QR code, to transmit a trace ID, an ephemeral ECC key pair secp256r1 and an encryption key as well as the ciphertext.

[0221] The trace ID is an HMAC-SHA256, derived from the user ID and the current timestamp (rounded down to the current minute) as data and the user trace secret as the key, and truncated to the first 16 bytes).

[0222] The encryption key is calculated using ECDH from the ephemeral private key and the public key of the Ministry of Health. The app will display a QR code with the following content (updated every minute with the current timestamp): QR code version (1 byte) Timestamp (4 bytes) Trace ID (16 bytes) Encrypted data (32 bytes) (Data key and user ID encrypted with AES-128-CBC, with the encryption key as the key and the trace ID as the IV) Ephemeral public key (33 bytes) Verification tag (8 bytes) (HMAC-SHA256 with trace ID and encrypted data as data and the user's verification secret as the key, truncated to the first 8 bytes)

[0223] The total payload is 94 bytes, which are concatenated and then encoded with ASCII85 as the QR code content. The ephemeral key pair can be discarded.

[0224] The venue device checks if the timestamp is recent and does not perform any further validation.

[0225] The venue encrypts the received encrypted data, the ephemeral public key and the verification tag using AES-128-CBC with the ECDH of an ephemeral key pair and the venue's public key.

[0226] The venue creates an authentication key using HMAC-SHA256 with the trace ID as the data and the verification tag as the key.

[0227] The venue will upload the check-in time, encrypted data, and authentication key to the server, see [link / reference]. Fig. 10 . Check-out (see Fig. 11)

[0228] When the user checks out via the app (geofence or manually), the app sends a checkout timestamp and an HMAC-SHA256 with the checkout timestamp as data and the authentication key (HMAC(data=trace id, key=verification tag) as the key). Infection (see Fig. 12)

[0229] A health authority requests the user's user ID and user trace secret. The health department can then calculate all possible trace IDs from the past two weeks (20,160 trace IDs) and query the server to find out which venues have uploaded data with those trace IDs. The health authority receives a list of the venues the user has visited.

[0230] The public health department can then request that the venues grant access to all user data of those who were present at the venue at the same time as the infected users. For this purpose, the corresponding trace ID is securely transmitted to the venue. The venue can then request from the server the uploaded data that overlaps with the check-in time of the trace.

[0231] The venue will download and decrypt the encrypted check-in data, which contains the data encrypted for the Ministry of Health, including the user ID, user data key, and verification tag.

[0232] The health authorities receive this list of encrypted data for each venue and decrypt it, and can then download the user data package and decrypt its contents with the user data key and its private key.

[0233] The health authority can now also verify the integrity of the check-in using the verification secrecy.

[0234] Implementations of "System 2" can be described, for example, according to the following clauses: Clause 1: 1. An electronic system comprising mobile devices, each assigned to a user, venue devices, and at least one server for tracing users for an entity, to which an asymmetric cryptographic key pair with a public and a private entity key is assigned, wherein the electronic system is configured to perform the following steps: storing user data of the users on a server at the time of registration, wherein the user data is encrypted by the public entity key and the result of this encryption is encrypted with a respective user data key of the user concerned; storing in each of the mobile devices a user data key, a user secret, and a user ID, wherein the mobile device has access to current time information via a network interface and the mobile device is configured to generate a trace ID.which is representative of a combination of user ID, user secret, and current time information, and for generating a ciphertext from the user data key and the user ID, wherein the public entity key is used to generate the ciphertext, and wherein the mobile device has a communication interface for direct communication with a venue device, via which the trace ID and the ciphertext are transmitted to the venue device, capture of one of the users by a venue device using the user's mobile device, wherein the venue device has an interface for direct communication with the corresponding interface of the mobile device, and with a network interface for communication with the server, wherein the venue device is configured to receive the trace ID and the ciphertext from the mobile device for user capture and to check whether the time information of a received trace ID is sufficiently current,and if this is the case, to transmit the trace ID to the server along with a venue ID and ciphertext assigned to the venue device; to store a received trace ID and ciphertext with the time information as an access key by the server; to receive a message of the user ID and user secret from one of the users to the entity; to generate possible past trace IDs for the user in question that lie within a specified past period; and to use the generated trace IDs as a search criterion to find corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues from which the user was tracked during the past period are determined; and to output the venue IDs of the determined venues to identify those venues that the user visited during the past period. 2. Electronic system according to clause 1,wherein the electronic system is configured such that a check-out time is transmitted from the mobile device of one of the users to the server when the user leaves the venue, the check-out time being associated with the trace ID previously received for that user, so that the user's stay at the venue is recorded. 3. Electronic system according to clause 2, wherein the electronic system is configured to identify those users who also visited one or more of the identified venues during the past period and during a user's stay, for this purpose by identifying the trace IDs that were transmitted from the identified venues to the server during the past period. 4. Digital storage medium containing program instructions executable by a mobile device processor for carrying out those steps for the execution of the electronic system according to clause 1.2 or 3 is configured, which pertain to the mobile device. 5. Computer-implemented procedure comprising the steps to be performed by the mobile device and / or the server according to "System 2". Revelation section "System 3", Figures 8-12

[0235] In another aspect, this revelation includes a further system ("System 3") for tracing users. "System 3" is also found, for example, in the Figures 8 to 12 Illustrated. Examples and explanations of the revelation section regarding "System 1" (illustrated, for example, using the Figures 1-7 ) and the part of the revelation concerning "System 2" (illustrated, for example, by the Figures 8-12 ) and / or the disclosure part regarding "System 3" (also illustrated, for example, by the Figures 8-12 These elements can be freely combined, provided they are not mutually exclusive. For the meaning of the terms "mobile device", "server", "venue", and "entity", please refer to the definitions above.

[0236] "System 3" refers to an electronic system for tracing users, particularly for combating a pandemic such as Covid-19, and a corresponding digital storage medium on which a computer program or app is stored.

[0237] To limit the spread of Covid-19, the current procedure is to require individuals attending public events or restaurants to provide their personal data. The associated documentation requirements are burdensome for the respective organizers and restaurant operators, especially since data protection regulations must also be observed.

[0238] In contrast, according to the technical doctrine of "System 3", an electronic system is created which ensures largely automated tracing while complying with data protection regulations.

[0239] The mobile device is uniquely assigned to a user. Tracing is intended to take place for an "entity".

[0240] According to embodiments of "System 3," the process begins with users registering using their mobile devices. This involves first collecting user data, for example, by entering the user data into the mobile device or by reading the user data, for instance, from the user's electronic identity card. The user data is then encrypted by the mobile device using the public entity key, such as a public key of the public health department. The result of this encryption is then encrypted with a user data key of the respective user, where the user data key is, for example, a random value with high entropy, such as a length of 16 bytes.

[0241] User data can be encrypted directly using the public entity key. Alternatively, a further key can be derived from the public entity key according to a predefined procedure, which is then used to encrypt the user data. For example, the further key can be derived from the public entity key and the user data key.

[0242] The entity key can be a master key or the key of a dependent entity associated with the entity. For example, in the case of the public health department, it could be the master key of the public health department itself or a key of the public health department responsible locally.

[0243] The user data key can be provided, for example, for registration purposes by the mobile device's operating system. For instance, the mobile device has a binary symmetric source for generating high-entropy random values.

[0244] The user data is stored on the server in a form that initially prevents the server from decrypting this user data, as this is not possible without the private entity key.

[0245] The mobile device persistently stores this user data key in non-volatile memory. Based on the registration with the server, the server generates a user ID, a unique identifier for the user in question, which the server returns to the mobile device. The user ID is then persistently stored in non-volatile memory on the mobile device.

[0246] To track a user's visit to a venue, the following procedure is now used: The mobile device generates a trace ID that is representative of a combination of the user ID and current time information. This current time information is the time the user checks in at the venue, which the mobile device determines via the network. Preferably, this current time is rounded according to a predefined rounding procedure, for example, rounded up or down to the nearest minute.

[0247] To register a user, the venue device checks whether the time information in the trace ID is sufficiently current. For this purpose, it also uses, for example, time information obtained via a network to synchronize with the time base used by the mobile device. The time information is considered current if, for example, it falls within a predefined tolerance range, meaning it is no older than a few seconds or minutes.

[0248] If the trace ID's timestamp is sufficiently recent, the venue device transmits the trace ID, along with a venue ID assigned to the venue device and the ciphertext, to the server. This information is then stored on the server.

[0249] Preferably, this is done for as large a number of users as possible, ideally for all users who visit a venue, in order to capture all users as comprehensively as possible.

[0250] Subsequently, it may be necessary to disclose to the entity the user(s) who visited the venue. This is the case, for example, if one of the users tests positive for Covid-19. This Covid-19-infected user reports this to the entity, in this case the health department, and provides the entity with their user ID and user secret.

[0251] Based on this information, all possible past trace IDs that could have been used to track a user by a venue device for a given period are generated. The number of these possible trace IDs is relatively limited, as not all possible times within the relevant period are considered, but only those that can actually occur due to the predefined rounding procedure.

[0252] These trace IDs are then used as a search criterion to locate corresponding trace IDs stored on the server for the past period, thus determining the venue IDs of those venues where the user was recorded during that period. This provides the public health department with the venue IDs of the identified venues the user visited during the past period, for example, two weeks, during which they may have already been infectious.

[0253] According to one embodiment of "System 3," the electronic system is configured so that, after a user checks in, their mobile device transmits a check-out time to the server when the user leaves the venue. This check-out time is associated with the trace ID previously received for that user, so that the server has information about the duration of the user's stay at the venue. Alternatively, this information can be provided by the venue device itself.

[0254] Preferably, this information is used to identify other users who were also present at the venue by limiting the search to users who not only visited the same venue but also stayed there for a period that overlaps at least with the identified user's stay. According to one embodiment of "System 3," this check-out occurs either through manual entry into the mobile device or automatically via geofencing. In the latter case, the check-out time, along with its associated trace ID, is automatically sent from the mobile device to the server as soon as the user leaves the venue. Alternatively, this can be done by the venue device itself.

[0255] The venue ID can be, for example, the name and / or address, an identifier, or even the geographical coordinates of the venue.

[0256] The implementation of the "System 3" concept proceeds as follows: a) Registration: The user encrypts their sensitive data using their mobile device, i.e., an app running on it, with the public entity key (for example, a public health department key or, depending on the implementation, a key derived from it) and uploads this encrypted sensitive data to the server. The server assigns a user ID to the encrypted sensitive data received from the user's mobile device and returns this user ID to the user's app. This user ID is stored by the app in the mobile device's memory. b) Check-in: The venue device receives the user ID from the user's mobile device. Depending on the implementation, this can occur by sending the user ID from the mobile device in plaintext or in encrypted form.In the latter case, a key can be generated for each check-in, so that the user ID appears to change each time; other encryption methods for the user ID are also possible if tracing based on the user ID is to be prevented. The venue device adds the timestamp and the venue ID to the user ID and sends this (possibly encrypted) to the server. c) Check-out: The check-out timestamp is sent from the venue or app to the server and assigned to the user ID (or a cipher copy thereof). 3. Infection:

[0257] a) The user provides their user ID to the public health department. This allows the department to determine, using data stored on the server, which venues the user has visited, for example, in the last two weeks. b) The department then queries which other user IDs were present at the venues during the relevant period at the same time as the infected user. c) The encrypted, sensitive data records of these users can then be decrypted using the public health department's private key and contacted by the public health department.

[0258] In another aspect, the technical teaching on "System 3" concerns a digital storage medium with program instructions executable by a processor of a mobile phone device.

[0259] For example, a user tracing procedure for an entity can be carried out using the following steps: Storage of user data of users upon registration on a server, wherein the user data is encrypted by the public entity key and the result of this encryption is optionally encrypted with a respective user data key of the user in question; provision of portable mobile devices, each assigned to a user, wherein a user ID is stored in each of the mobile devices, wherein the mobile device has access to current time information via a network interface and the mobile device is configured to generate a trace ID that is representative of a combination of user ID and the current time; and wherein the mobile device has a communication interface for direct communication with a venue device, via which the trace ID and the ciphertext are transmitted to the venue device. Capture of a user by a venue device using the user's mobile device, wherein the venue device has an interface for direct communication with the corresponding interface of the mobile device and a network interface for communication with the server, wherein the venue device is configured to receive the trace ID from the mobile device for user capture and to check whether the time information of a received trace ID is sufficiently current, and if so, to transmit the trace ID to the server along with a venue ID and ciphertext assigned to the venue device, storage of a received trace ID and ciphertext with the time information as an access key by the server, communication of the user ID and user secret of one of the users to the entity, generation of possible past trace IDs for the user in question.which lie within a predefined past period and use the generated trace IDs as a search criterion to find corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues from which the user was tracked during the past period are determined, output of the venue IDs of the determined venues to identify those venues that the user visited during the past period.

[0260] According to another embodiment of the method, a check-out time is transmitted from the mobile device of one of the users or the venue device to the server when the user leaves the venue, whereby the check-out time is assigned to the trace ID previously received for this user, so that the user's stay at the venue is stored.

[0261] According to another embodiment of the method, those users are identified who also visited one or more of the identified venues during the past period and during a user's stay, for which purpose those trace IDs that were transmitted from the identified venues to the server during the past period are determined.

[0262] In the following, embodiments of "System 3" will be explained in more detail with reference to the same drawings 8-12 that were already used to explain "System 2".

[0263] With regard to the Fig. 8 The registration process is described.

[0264] The user provides their contact information to the app (application program) on their mobile device. The application generates an EC secp256r1 key pair (user public key and user private key), a user trace secret (16 bytes entropy), a user verification secret (16 bytes entropy), and a user data key (16 bytes entropy).

[0265] The application then calculates an encryption key using ECDH, the user's private key, and the public master key (entity key) of the health department. The app calculates an HMAC-SHA256 key using the ECDH output as the data and the data key as the key. The application then encrypts the personal information and user verification secret with this encryption key using AES-128-CBC. The application then uploads this encrypted data and signs it with the user's private key along with the user's public key. The server returns a user identifier, i.e., a user ID.

[0266] The following data is stored on the mobile device: user id (uuid) user public key (ec secp256r1) user private key (ec secp256r1) user data key (16 bytes random data) user trace secret (16 bytes random data) user verification secret (16 bytes random data) Check-in (see Fig. 9)

[0267] The app generates a signal for each check-in to transmit the trace ID, which is transmitted via direct communication, for example by displaying a QR code, to transmit a trace ID, an ephemeral ECC key pair secp256r1, and an encryption key, preferably for each new QR code.

[0268] The trace ID is an HMAC-SHA256, derived from the user ID and the current timestamp (rounded down to the current minute) as data and the user trace secret as the key, and truncated to the first 16 bytes).

[0269] The encryption key is calculated using ECDH from the ephemeral private key and the public key of the Ministry of Health. The app will display a QR code with the following content (updated every minute with the current timestamp): QR code version (1 byte) Timestamp (4 bytes) Trace ID (16 bytes) Encrypted data (32 bytes) (Data key and user ID encrypted with AES-128-CBC, with the encryption key as the key and the trace ID as the IV) Ephemeral public key (33 bytes) Verification tag (8 bytes) (HMAC-SHA256 with trace ID and encrypted data as data and the user's verification secret as the key, truncated to the first 8 bytes)

[0270] The total payload is 94 bytes, which are concatenated and then encoded with ASCII85 as the QR code content. The ephemeral key pair can be discarded.

[0271] The venue device checks if the timestamp is recent and does not perform any further validation.

[0272] The venue encrypts the received encrypted data, the ephemeral public key and the verification tag using AES-128-CBC with the ECDH of an ephemeral key pair and the venue's public key.

[0273] The venue creates an authentication key using HMAC-SHA256 with the trace ID as the data and the verification tag as the key.

[0274] The venue will upload the check-in time, encrypted data, and authentication key to the server, see [link / reference]. Fig. 10 . Check-out (see Fig. 11)

[0275] When the user checks out via the app (geofence or manually), the app sends a checkout timestamp and an HMAC-SHA256 with the checkout timestamp as data and the authentication key (HMAC(data=trace id, key=verification tag) as the key). Infection (see Fig. 12)

[0276] A health authority requests the user's user ID and user trace secret. The health department can then calculate all possible trace IDs from the past two weeks (20,160 trace IDs) and query the server to find out which venues have uploaded data with those trace IDs. The health authority receives a list of the venues the user has visited.

[0277] The public health department can then request that the venues grant access to all user data of those who were present at the venue at the same time as the infected users. For this purpose, the corresponding trace ID is securely transmitted to the venue. The venue can then request from the server the uploaded data that overlaps with the check-in time of the trace.

[0278] The venue will download and decrypt the encrypted check-in data, which contains the data encrypted for the Ministry of Health, including the user ID, user data key, and verification tag.

[0279] The health authorities receive this list of encrypted data for each venue and decrypt it, and can then download the user data package and decrypt its contents with the user data key and its private key.

[0280] The health authority can now also verify the integrity of the check-in using the verification secrecy.

Claims

1. A method for tracing users who are temporarily located in different spatial areas, referred to hereinafter as venues, for an entity (246), in particular for emergency scenarios such as a pandemic, wherein the method comprises: - upon registration (102) of each of the users: storing user data (306) of the user on a server (202), wherein the user data (314) is encrypted by a user device assigned to the user with a user data key (310) that is unique to the user, wherein, in particular, a user ID (302) of the user is stored on the server in association with the encrypted user data (306); and storing the user ID and a user-specific user data decryption key (310) required for decrypting the encrypted user data in the user device, wherein the user data key and / or the user data decryption key (310) are preferably stored in a protected manner and are not accessible to the server; - during a check-in (104) of one of the users at one of the venues, generating a trace ID by the user device of the one user, wherein the trace ID is representative of a combination of the user ID of the one user and current time information, and storing the trace ID linked to the venue ID of the one venue on the server (202), wherein the trace ID is stored as an access key, - receiving (106) a message containing the user ID of one of the users with regard to whom the tracing is to be performed; - generating (108) candidate trace IDs for the user identified in the message, wherein the candidate trace IDs are possible past trace IDs that lie within a predetermined past time period, - use (110) of the generated candidate trace IDs as search criteria by the server (202) to find corresponding trace IDs stored on the server for the past period, so that the venue IDs (502) of those venues at which the user to be traced checked in during the past period are determined, and - outputting (112) the venue IDs of the determined venues by the server (202) for identifying those venues which the user to be traced has visited during the past period.

2. An electronic system (200) with user devices (204), each of which is assigned to a user (240), and with at least one server (202) for tracing users who are temporarily present in different spatial areas, hereinafter referred to as venues, for an entity (246), wherein the electronic system is configured to perform the following steps: - upon registration (102): storing user data (300) of the users on the server (202), wherein the user data is encrypted with a user data key (310) that is individual for the respective user, wherein, in particular, a user ID (302) of the relevant user is stored on the server in association with the encrypted user data (306); and storing the user IDs and a user-specific user data decryption key (310) required for decrypting the encrypted user data in each case in the user device assigned to the user, wherein the user data key and / or the user data decryption key (310) is preferably stored in a protected manner in the user device of the respective user and is not accessible to the server; during a check-in (104) of one of the users at one of the venues, generating a trace ID by the user device of the one user, wherein the trace ID is representative of a combination of the user ID of the one user and current time information, and storing the trace ID linked to the venue ID of the one venue on the server (202), wherein the trace ID is stored as an access key, - receiving (106) a message containing the user ID of one of the users for whom the tracing is to be performed; - generating (108) candidate trace IDs for the user identified in the message, wherein the candidate trace IDs are possible past trace IDs that lie within a predetermined past time period; - using (110) the generated candidate trace IDs as search criteria by the server (202) to find corresponding trace IDs stored on the server for the past period, so that the venue IDs of those venues at which the user to be traced checked in during the past period are determined, and - outputting (112) the venue IDs of the determined venues for identifying those venues that the user to be tracked has visited during the past period by the server (202).

3. The method or electronic system according to any one of the preceding claims, - wherein the trace ID generated during check-in is calculated by means of a derivation function as a function of the combination of the user ID to be represented and the current time information to be represented at check-in; and - wherein each of the candidate trace IDs is calculated by means of the same derivation function as a function of the combination of the user ID contained in the message and one of the candidate time information for a possible check-in time in the past, - wherein the derivation function preferably comprises rounding the current or candidate time information to times within predefined time intervals, wherein the time intervals are in particular minutes or hours or days.

4. The method or electronic system according to claim 3, - wherein the user device is configured to generate a random value (userTracingSecret, 410) during registration with the server and to store it in an access-protected manner exclusively in the user device; - wherein the derivation function calculates the trace ID as a function of the random value (410); - wherein the user device is configured to obtain confirmation from the user to whom it is assigned for the transmission of the random value, and only in response to the confirmation to transmit the random value to the server or to an entity device of the entity in order to enable the server or the entity to derive the candidate trace IDs.

5. The method or electronic system according to any one of the preceding claims, - wherein the user device is configured to generate a random value (412), hereinafter referred to as userVerificationSecret, during registration with the server and to store it in an access-protected manner exclusively in the user device; - wherein the user device is configured to use the userVerificationSecret during check-in with the venue to calculate a verification data value (414) as a function of the trace ID (406) and the encrypted ID data (408) and to store it on the server linked to the trace ID.

6. The method or electronic system according to any one of the preceding claims, - wherein the entity is assigned an asymmetric cryptographic key pair with a public entity key and a private entity key, - wherein the user device of the user is configured to additionally encrypt the user data already encrypted with the user data key (310) with the public entity key (332) during registration, and / or - wherein the user's user device is configured, during check-in, to encrypt the user data decryption key (310) required for decrypting this encrypted user data (306) using the public entity key together with the user ID of the user in order to generate encrypted ID data (408), and is configured to store the encrypted ID data (408, 506) in the course of the check-in linked to the venue ID (502) of the one venue on the server (202).

7. The method or electronic system according to claim 6, further comprising at least the entity device (208) assigned to the entity, - wherein the entity device is configured to generate, one after the other, a plurality of asymmetric cryptographic key pairs assigned to the entity, wherein, upon generation of a new entity key pair, the previously valid one is invalidated, wherein each of the entity key pairs is assigned a key version number, - wherein the at least one entity device is configured to transmit the public key of the generated and currently valid key pair to the user devices; - wherein the user devices are configured to always use only the most recently transmitted entity key (332) to generate the multiply encrypted user data and / or to generate the encrypted ID data (408), wherein in particular: - the entity device (208) comprises a plurality of entity devices, - wherein the entity device which generates the current asymmetric entity key pair is configured to send the private key of the currently generated asymmetric entity key pair in encrypted form to all other entity devices via a network, - wherein each of the entity devices is configured to generate an emergency message relating to one of the users and to send it to the server (202) and / or configured to decrypt the encrypted user data and / or the encrypted ID data (408) using one of the previously received private entity keys.

8. The method or electronic system according to any one of the preceding claims, further comprising a plurality of venue devices (206), wherein one or more of the venue devices are assigned to each of the venues, wherein, in particular: the user performs the check-in with one of the venue devices (206), wherein the one venue device includes a communication interface for direct communication with the user device of a checking-in user, wherein the user device and the one venue device are configured such that, during the check-in, the following occurs: - generation of the check-in data packet (400, 420, 430) by the user device, wherein the check-in data packet encodes the trace ID (406) and preferably also the encrypted ID data (408); - transmission of the check-in data packet from the user device to the venue device via the direct communication interface; - decoding of the received check-in data packet by the venue device to obtain the trace ID and preferably also the ID data (408) of the checking-in user and storing these on the server (202) linked to the venue ID of the venue to which the venue device is assigned; - wherein the direct communication link is preferably a near-field communication link or optical data transmission, wherein the optical data transmission comprises detection by an optical sensor of the venue device of a graphic code encoding the check-in data packet and displayed on a display of the user device.

9. The method or electronic system according to any one of the preceding claims, further comprising at least one carrier object with a graphical venue code of one of the venues, wherein the venue code encodes a venue ID under which this venue is registered with the server (202), wherein the user checks in to this venue, wherein the user device is configured such that the following occurs during the check-in: - capturing of the graphical venue code with a camera of the user device; - decoding of the venue code by the user device to obtain the venue ID of the venue; - wherein the trace ID and preferably also the identification data (408) of the checking-in user are transmitted to the server by the user device, wherein the decoded venue ID linked to the trace ID is also stored on the server (202); - wherein the venue code is preferably a QR code or barcode that is visible on a label or digital display, and / or wherein the carrier object is preferably a table display or a door sign for a vehicle, vehicle compartment, building or room.

10. The method or electronic system according to any one of the preceding claims, wherein the electronic system is configured such that a check-out time is transmitted to the server from the user device of one of the users or from the venue device when the user leaves the venue, wherein the check-out time is assigned to the trace ID previously received for this user, so that the period of time spent by the user at the venue is stored.

11. The method or electronic system according to any one of the preceding claims, wherein the system is configured to: - generate a tracing secret transfer object by the user device, wherein the tracing secret transfer object contains at least the user ID and the user data decryption key of the user to whom the user device is assigned; - encrypt the tracing secret transfer object with a public key (332) of the entity by the user device, wherein the public key is in particular the most recent of a series of consecutively generated public entity keys; - transmit the encrypted tracing secret transfer object via a network from the user device to the server; - in response to receiving the encrypted tracing secret transfer object, generating a TAN and storing the TAN linked to the encrypted tracing secret transfer object by the server, and issuing the TAN to the user; - receive the TAN from the user via an entity device (208) assigned to the entity; - use the TAN by the entity device to receive and decrypt the user's encrypted user data in interoperation with the server.

12. The method or electronic system according to claim 11, wherein using the TAN comprises: - sending a first user data request containing the TAN to the server (202) by the entity device (208); - receiving a first user data request containing the TAN by the server (202) from the entity device; - in response to receiving the user data request, sending the encrypted tracing secret transfer object stored in association with the TAN from the server to the entity device; - decrypting the tracing secret transfer object with the private entity key corresponding to the public key (332) of the entity to obtain the user ID and the user data decryption key (310) required for decrypting the encrypted user data of the user, by the entity device; and - using the decrypted user ID to generate a second user data request containing the user ID and sending it from the entity device to the server; and - receiving the encrypted user data of the user from the server by the entity device in response to the second request; and - decrypting the encrypted user data by means of the user data decryption key contained in the tracing secret transfer object by the entity device.

13. The method or electronic system according to any one of the preceding claims, wherein the trace IDs do not contain the user ID in plain text, and wherein the trace IDs are generated in such a way that it cannot be determined on the basis of an analysis of the trace IDs stored on the server alone whether two trace IDs represent the same or different user IDs.

14. The method or electronic system according to any one of the preceding claims, - wherein the user device is configured to detect its own current position during the check-in process; - wherein the system is configured to check during the check-in whether the user device is within a maximum distance from the position of the venue and to perform the check-in only if the user device is within the maximum distance from the position of the venue.

15. The method or electronic system according to claim 14, wherein the detection of the current position of the user device is selected from its group comprising: - capturing GPS data from the user device using a GPS sensor on the user device, whereby the GPS data determined by the user device is compared with position data from the venue to determine whether the user device is within the maximum distance from the venue at the time of check-in; - capturing a WLAN identifier of a locally available WLAN network, wherein the WLAN identifier determined by the user device serves as proof during the check when determining whether the user device is within the maximum distance from the venue during check-in; - detecting a near-field signal from a near-field signal transmitter of the venue, wherein the near-field signal encodes an identifier of the venue, and wherein the identifier of the venue determined by the user device via the near-field signal serves as proof during the check when the user device is within the maximum distance from the venue during check-in.

16. A computer program, computer program product or digital storage medium with program instructions executable by a processor of a data processing device for performing those steps for which one or more components of the electronic system according to any one of preceding claims 8-15 is configured, wherein these system components are the user device or the server (202) or the venue device or the entity device.