eu-digital-green-certificates / dgc-overview

This repository provides an overview over the EU Digital Green Certificates (DGC) project.
Apache License 2.0
209 stars 29 forks source link

TAN fails as a second factor with current approach #42

Closed p-dealwis closed 1 year ago

p-dealwis commented 3 years ago

This issue is based around the closed issue #7, even though it is closed it is not solved.

The TAN second-factor is quite redundant. It would only make sense if the DGC standard only allows for digital certificates; paper versions of the QR code would not be allowed.

However, currently a bad actor can use a DGC, the only thing stopping them from getting past health checkpoints is the mismatched ID details on the passport or any other type of ID being used. I understand the TAN is being used to stop people from having multiple digital copies of a DGC but I'm not sure how that would help user's protect their DGC; it just makes the digital on-boarding less user friendly. If we are to make digital certificates secure we must have another process in place to generate the certificates.

Maybe we should only allow generation of paper certificates based on information the user should have. This could be a flow like the following:

  1. User scans QR code (with the DGCI)
  2. QR code takes the user to a webpage/app(via deeplink) which asks them to give the TAN code.
    • If the user goes through the app the typical app flow applies with the keypair generation.
    • If the user goes through the webpage then the browser makes it's own keypair(acts as an ephemeral key) which it uses to make the transaction. This allows the API calls to be consistent in the webpage and app versions as well as allowing the webpage session the ability to create a derived DGC(we will call this dDGC from now on).
  3. Upon verifying the TAN code with the DGCI the DGC is given to the user to print or store on their device.
    • This DGC should be used to generate dDGCs which will be used for presentation to the validation apps. This works because the DGC will have the holders public key enclosed. On validation of the dDGC the validator will check to make sure the signature of the dDGC is valid and the dDGC hasn't expired.
    • The webpage will generate a dDGC for the user to print, this dDGC will have a long time expiry.

Considerations of this approach:

The presentation of dDGCs will still be QR codes adding another signature and expiry on top will not be heavy. I understand this is quite different to the current flow but this is the only way we can make sure the certificates are more secure and uses the technology we have better. We should not allow our mobile devices to be just a glorified storage medium with a screen. We need to leverage their real time capabilities to provide a more secure presentation interface, hence the usage of dDGCs.