Questioning the use of 2FA (TAN) for the installation of a DGC the user already possesses

[jquade]

Regarding section 5.1, 5.2 in the Guidelines on Technical Specifications for DGCs, Volume 4, European DGC Applications, v1.3

I am unsure, if I understand the DGC installation process in the Wallet App correctly, especially the planned use of a TAN via SMS (or on paper) to move a test result from an e-mail (or paper) into the app.

I assume the following:

• the QR code shown in the Wallet is the same as on the printed version (its just the DGC)
• it is always necessary to check if the ID of the person presenting the DGC matches the DGC, and of course the signature
• there is maybe some protection against just presenting a screenshot, like a moving counter or so on the wallet screen
• on the other hand, localized versions of the wallet may have different appearances
• it is possible to build an app not doing the TAN/DGCI check on DGC installation, that still looks like the wallet and presents DGCs
• it is even possible (but probably illegal) to use a rogue verifier app at an venue that just records DGC, with or without actually verifying the signature

So, the protection offered by the TAN requirement is somewhat limited, as the data to display is already transmitted to the user and only the installation in the app is a bit more difficult.

I think it is useful to only allow one installation of the DGC in the official wallet app by registering the installation's public key with the backend and only allow registration for a limited time after issuing the certificate as planned. The wallet app should inform the user that the DGC can only be installed in one wallet before registering the DGCI with the backend.

This would help against the "normal" DGC reuse attempts, like forwarding a test result email to a friend, or trying to scan the QR code from the wallet of another person.

But I don't understand the benefit of a second factor in this situation. Maybe I have missed something important?

[SchulzeStTSI]

The sense of the TAN is to provide a one time factor for installing the DGC in the app by checking it with the backend. Issued on a second channel, the DGC can be lost, copied etc., but without the TAN it's not able to install the DGC in the wallet app. Of course, if you use a fake wallet app you can do what you want. But without a correct claiming over the TAN in the issuer backend, the DGC can not be linked to the wallets public key. Without the TAN, the possibility to evaluate if the user can really claim this DGC is lost, because the issuer did already an evaluation (e.g. a doctor), but it's not trustworthy anymore. This is especially with printed papers the case or with QR codes which you found in the internet. The missing TAN makes all this illegal copies worthless, because you can not register your public key. So everyone can check against the issuing backend, if the user of the DGC have the right private key. During a physical check of the DGC is it not necessary (name and birthdate can be checked), but in future online scenarios is it important to have a cryptographically basis.

[J08nY]

The sense of the TAN is to provide a one time factor for installing the DGC in the app by checking it with the backend. Issued on a second channel, the DGC can be lost, copied etc., but without the TAN it's not able to install the DGC in the wallet app.

The specification explicitly allows to send the TAN alongside the DGC, thereby removing the second-factor: "Second, the TAN could be returned in conjunction with the signed DGC (as shown in the flow diagram below) or sent directly to the user’s phone." on page 15.

Of course, if you use a fake wallet app you can do what you want. But without a correct claiming over the TAN in the issuer backend, the DGC can not be linked to the wallets public key.

As far as I can tell, the public key is not used anywhere in the specification and thus no validation is done on the verifier and thus is doesn't really matter that the fake wallet app doesn't have the private key. The user always has to have an option to present a paper DGC and thus any attempt at increasing security above that of the paper DGC is pointless. In fact, this whole TAN + public key binding nonsense impacts the usability of the app significantly (and thus also security you could achieve). It allows one DGC to only reside in one (official) wallet app, which is way worse usability than just keeping the DGC in the form of a document or image file (The scenario would be a family travelling where the spouses would like to have each others certificates in case something happened to their devices). Also, what do you do in case someone loses access to the device the DGC is bound to? What if they just uninstall the app? It is undocumented that the DGC enrollment is a one-time process and cannot be repeated on another device. Due to this limitation, the app provides worse usability than just keeping the DGC as a file, which completely stops any security improvement that could be had from the users having their DGCs in the wallet app and bound to the device.

Without the TAN, the possibility to evaluate if the user can really claim this DGC is lost, because the issuer did already an evaluation (e.g. a doctor), but it's not trustworthy anymore. This is especially with printed papers the case or with QR codes which you found in the internet.

What does it mean that the "issuer did already an evaluation (e.g. a doctor), but it's not trustworthy anymore"? I don't understand.

The missing TAN makes all this illegal copies worthless, because you can not register your public key.

Given a DGC, or in fact just a DGCI, not even the full DGC that is not registered with the backend. The attacker can exhaust the tries of the TAN on the backend and essentially perform a DoS against the users DGC. The user will then not be able to enroll their DGC into the official wallet app. What happens then? How does the user get notified of this? How do they get their DGC into the app?

This whole TAN second/first-factor and public key binding is really just security theater and doesn't add any desirable security properties which are not negated by the usability hit incurred. Trying to add security properties above that of a paper DGC is simply pointless as one can not discriminate and paper DGCs have to provide the same features and access to freedom of movement as do digital DGCs.