Risk analysis

The following sections describe risks we have identified to date.

Re-identifiability of QR code series

Since users print QR codes on their own in the current design and the codes remain with locality operators in asynchronous collection, if QR codes are collected consipratively, they could possibly try to trace different codes back to a single user. Certain printers, for example, generate so-called Machine Identification Codes (MICs), which are placed on a printout invisibly to the naked eye and can be read with the aid of technical aids. These codes allow a printout to be traced back to a specific printer. Third parties could therefore trace the codes back to a single user if several QR codes with such MICs were present.

Irrespective of the presence of such MICs, the print image and the paper used may already provide information about the printer used for production.

Various technical and organizational measures can be taken to reduce this traceability. QR code series can be pre-generated and pre-printed in large numbers, similar to checkbooks, for example. For example, users could obtain them from a trusted third party and use a QR code located in the booklet to link the given block to their contact information. However, in order to do this, the issuing third party and all parties involved in the production must be trusted, as they could record the QR codes. Nevertheless, in practice this variant would be a simple way to provide QR code series quickly and easily.

Loss or theft of QR codes

One risk of generating large numbers of QR codes is loss by the user. Found codes could easily be misused e.g. to bypass visit documentation. To prevent this, a mechanism for invalidating hashes can be introduced. In this case, the user would have to obtain an additional data structure for his own use, which contains the secret $H _ s$ (such a data structure can also be used to verify the data retrieval, which is described in a protocol extension below). The backend also publishes a token $Z _ h$ which can be queried by the user's web application. The application can then use $ H _ s $ to regenerate all hashes $H _ i $ of the user, combine this via a suitable hashing procedure with $ Z _ h$ and send the list of hashed tokens to the backend, which it then publishes (together with other hashes to ensure anonymity). Web applications of operators can obtain these lists (e.g., also as Bloom filters) and check whether a given hash has been invalidated when documenting a visit with the help of the token $ Z _ h $. Documentation based on this hash can then be rejected. However, to prevent visit documentation with an invalid QR code, this requires a direct check of the codes. However, even if checked later, the mechanism can prevent visits from being attributed to a user whose QR codes have been stolen or lost. Manipulated QR codes can generally only be detected when using the validation mechanism, however, generating manipulated codes is much easier for an attacker than stealing someone else's code to bypass visit documentation.

Reuse of QR codes

Since QR codes are only recorded decentrally, they can initially be used several times without being detected. For example, an operator or a third party who has access to a QR code already used by a user could use it to document visits in other locations.

However, this attack is easy to detect during contact tracing, and the data generated by multiple use of a QR code can presumably be easily removed. Possible sources of misuse can also be easily reconstructed on the basis of existing and missing data by questioning the affected user, and missing QR codes can subsequently be identified when checking an operator. Misuse is therefore not excluded (as with other methods), but in contrast to these can be effectively tracked and punished if necessary. This creates effective incentives for operators and users to keep QR codes safe and not to misuse them.

The risk of reuse can also be limited via a validity mechanism (e.g. certain QR codes can only be used on certain days). On the one hand, however, this would make the use of the codes by the user somewhat more complicated. On the other hand, a tamper-proof limitation of the validity of QR codes can only be achieved with the help of a validating third party, as described above. Whether this makes sense must be weighed up. A "simple" restriction of the validity of QR codes can be achieved by adding a timestamp, but this is easy to circumvent for a technically skilled attacker. Nevertheless, such a timestamp can be useful to prevent "casual abuse" of QR codes. Furthermore, the user's web application can create an HMAC-based checksum for this timestamp during initialization, this cannot be processed by the operator's application, but makes it easier to detect the misuse during analysis by the GA (which, however, is easily possible anyway).

Deposit of false data

The validation process described above can guarantee the presence and authenticity of certain user data in the system. However, it requires the involvement of a trusted party in the initialization process.

Reconstruction of visit histories

To reconstruct a visit history, an actor must know which values $H _ i$ belong to a given user. Since these values are generated using a secret key $ H _ s $, the attacker must therefore be in possession of this key in order to reconstruct the $H _ 1 \ldots H _ n$ series. The key $ H _ s $ is under control of the user and can only be decrypted by GÄ. An attacker must therefore possess both the GÄ private key and the user's QR code with the value $ H _ s$. In addition, the attacker must extract the visit data individually from the operators, e.g., by manipulating the web applications.

Assuming that at least one of these three attacks fails, the reconstruction of visit histories can be ruled out.