Fraud protection

[jucktnich]

I hope this is the right place for the issue

Problems

1 - good intent

People try to verify DCCs with their wallet apps. This leads to an unwanted list of all visitors, their DoBs, vaccination status, etc.

2.1 - bad intent

People try to get valid DCCs to participate in events or locations where they are not allowed to join, or to join only with too big of extra effort.

2.2 - super bad intent

People try to get valid DCCs to sell/donate(to harm the system) them on platforms like Telegram or RaidForums.

Solutions

only for problem 1

Add a 'Do not Import' mark on DCCs displayed in the wallet app (wallet apps should get an export feature without this mark).This could look something like this: HC3-dni:payload

for both problems

Old version below

1 certificate is created

1. The normal certificate payload is created (except that you maybe add a "hcversion": "4", to the JSON to prevent fraudulent downgrades) (the payload is everything behind the "HC1:").
2. The server creates a private/public key pair (this used only for this one certificate, it's create new every time) (let's call them certificate keys).
3. The server takes the "Unique Certificate Identifier" and the "public certificate key" and encrypts them together (they need to be encrypted together so they are chained together)
4. The server takes the payload, the encrypted part from 3, the private and public certificate keys and puts it into an QR Code.

   2 certificate is processed by the wallet app

5. The wallet app Scans the certificate.
6. If the user shows the code to be scanned by a verifier app, the wallet app does the following things:
7. The app removes the private certificate key from the cert.
8. The app takes the private certificate key to encrypt the end-of-life-date-and-time. Normally it uses the current time + 5mins.

   3 certificate is processed by the verifier app

9. The verifier app Scans the qr code.
10. The app decrypts the part from 1.3 and checks if the signature is correct.
11. The app takes the public certificate key from there, decryptes the end of life date and checks if it's later then this date.
12. The app checks the normal things (with the data from 1.1).

Old version: When the certificate is created, the server creates a private/public key pair. The public key + the signature of the certificate get encrypted by the privat key of the server. The private key and the encrypted(public key + signature) are added at the end of the DCC.When the certificate is now scanned by a wallet app, and the wallet app should show the DCC, the wallet app encrypts an end of life date (like five minutes later or so) + the dcc (without the encrypted public key + private key of course). The app now adds the encrypted public key to the end like this:

HC4-dni:certificate-private-key-encrypted(end of life date + dcc) + server-private-key encrypted(certificate public key + signature)

An verifyer app now encrypts the certificate public key, uses it to decrypt the rest of the dcc, checks the end of life date and checks if the signature matches the dcc. There should be a secure way to store that it's a HC4 (to prevent downgrades by fraudster), Like another key pair or something added to the payload.

[Jo-Achim]

I would very much like to see this proposal implemented - even if it could only be implemented in the CWA.

[jschlyter]

Interesting input! One should note that there are no requirements for HCERT to address any of these problems. If such requirements would arise, we will keep your proposal in mind.

An explicit requirement for the current specification is that one should be able to print the HCERT on paper, resulting in any sort of cryptographic copy protection difficult. Also, there are no requirements for trusted apps handling the HCERTs - a generic wallet app (e.g. Apple Wallet) can be used, adding to this even if the paper requirement would be removed.

[jucktnich]

@jschlyter You could make the end-of-life date to a date you like. So the Wallet app could f.e. show an export button which sets the end-of-life date to 1y later or to the expiration date of the "normal" certificate.

[jschlyter]

The entire HCERT is signed by the issuer. The "wallet app" can't change the payload - it's just a bearer.

[jucktnich]

In my proposal the wallet app can only add an end-of-life-date, the rest it can't change.

[jucktnich]

I could maybe try to explain my proposal again, or someone else who understood my proposal could try it

[jschlyter]

What is this "wallet app" you are referring to? It is a secure tamperproof environment, the mobile operating systems "wallet" (e.g., Apple Wallet) or something different? Please elaborate. Keep in mind that many citizens do not have a smartphone and rely on paper-based HCERTs.

[jucktnich]

1 certificate is created

1. The normal certificate payload is created (except that you maybe add a "hcversion": "4", to the JSON to prevent fraudulent downgrades) (the payload is everything behind the "HC1:").
2. The server creates a private/public key pair (this used only for this one certificate, it's create new every time) (let's call them certificate keys).
3. The server takes the "Unique Certificate Identifier" and the "public certificate key" and encrypts them together (they need to be encrypted together so they are chained together)
4. The server takes the payload, the encrypted part from 3, the private and public certificate keys and puts it into an QR Code.

   2 certificate is processed by the wallet app

5. The wallet app Scans the certificate.
6. If the user shows the code to be scanned by a verifier app, the wallet app does the following things:
7. The app removes the private certificate key from the cert.
8. The app takes the private certificate key to encrypt the end-of-life-date-and-time. Normally it uses the current time + 5mins.

   3 certificate is processed by the verifier app

9. The verifier app Scans the qr code.
10. The app decrypts the part from 1.3 and checks if the signature is correct.
11. The app takes the public certificate key from there, decryptes the end of life date and checks if it's later then this date.
12. The app checks the normal things (with the data from 1.1).

[mlenkeit]

@jschlyter I think the solution to problem 1 - a prefix other than HC1 such as HC3-DNI would be a rather simple extension to the HCERT spec and could help against wide spread (accidental?) use of wallet apps for verification purposes (instead of using a verifier app for that).

As this change only affects the prefix in the QR-code which is not subject to the signature, certificates wouldn't need to be re-issued.

The paper-based certificate could still contain HC1 to allow scanning by wallet apps and verifier apps alike (which still opens the door for scanning paper-based certificates with wallet apps for verification purposes).

Once a certificate is imported into a wallet app, it would be displayed with e.g. HC3-DNI instead of HC1

When scanning a certificate with a wallet app, it would only allow to scan certificates that start with HC1 and reject any certificates that start with HC3-DNI (preventing import from other wallet apps).

When scanning a certificate with a verifier app, it would allow to scan certificates with either HC1 and HC3-DNI.

As a result, people who use a wallet app that supports HC3-DNI could be sure that their certificate can only be checked by verifier app and not accidentally by a wallet app (assuming that the app is genuine and the person who uses the app can be trusted). This would protect against people accidentally or purposely using a wallet app for verification purposes and collecting certificates (to potentially misuse them, e.g. re-sell online, etc.)

@jucktnich fyi, any changes would need to be upper-case only in order to not break out of the alphanumeric input mode for QR codes of HCERTs.

[mlenkeit]

What is this "wallet app" you are referring to? It is a secure tamperproof environment, the mobile operating systems "wallet" (e.g., Apple Wallet) or something different? Please elaborate. Keep in mind that many citizens do not have a smartphone and rely on paper-based HCERTs.

@jschlyter I assume he's referring to the wallet app as per Technical Specifications for Digital Green Certificates, Chapter 6.4 Wallet App. So it's not e.g. the Apple Wallet, but just a regular app with the purpose of storing DCCs/HCERTs of the user to show them for verification purposes (e.g. to be scanned by a verifier app).

[asitplus-pteufl]

@jucktnich can you Elaborate again on the problem you are trying to solve?

[asitplus-pteufl]

@jucktnich or let me try to summarize it: You are trying to solve the problem that DCCs get "stolen" by simply scanning them, right? Some things to consider here:

• first, this is why the DCC is not valid without an ID card, so you need to have an ID card and a valid DCC (although it's clear by now that ID cards are typically not validated)
• second, the structure was created to have electronic/paper use cases at the same time
• third, ideally in an electronic-only solution you would need those ingredients: during issuing the DCC would need to be bound to the user by another cryptographic key that is stored in the device and linked to the specific instance of the DCC by the issuer, during presentation you would need to prove that you are in possession of this binding key (might be related to your suggestion), this is also done for the driving license standards and of course many other best-practice ways/standards for proving something. to address the problem of privacy (bad verification apps that steal your data) you have two primary options: first use some zero-knowledge proof based presentation, although that might get complicated due to missing crypto-libs in the mobile phones (especially if you want to base your security on the secure elements/trust zones), second and that's much easier: you need to be able to trust the validation apps on the other side. for this you could easily rely on the established key/app attestation methods of the devices which prove that a correct app is used. Problem, you would need a handshake between those devices (you would need to create a challenge for the validation app that is then signed by the app and returned to your app before transmitting the DCC)

added: if you are in an electronic-only use case you can also easily limit the hard technical lifetime of the DCCs (to prevent "stealing"), if you assume that your wallet app can easily refresh the DCCs. very short lifetimes (max. days) could be used.

added 2: and let me include the comment of @jschlyter here "what prevents me from showing a "paper" HCERT on an app (i.e., a downgrade attack). You are allowed to present your HCERT as a PDF on a your mobile phones screen". Even if you have a great wallet-app that does all that stuff and perfectly attested validation apps for those wallet apps, you still can downgrade to the paper-mode, with the paper-mode you will also not be able to validate the "validation app"... Thus, we are back to the necessity to show the DCC and your ID card (also: as long as you do not have a picture in the DCC, which would be a size problem for one static qr code, you will always need the ID card).

[jschlyter]

When scanning a certificate with a verifier app, it would allow to scan certificates with either HC1 and HC3-DNI.

@mlenkeit, what prevents me from showing a "paper" HCERT on an app (i.e., a downgrade attack). You are allowed to present your HCERT as a PDF on a your mobile phones screen.

[mlenkeit]

When scanning a certificate with a verifier app, it would allow to scan certificates with either HC1 and HC3-DNI.

@mlenkeit, what prevents me from showing a "paper" HCERT on an app (i.e., a downgrade attack). You are allowed to present your HCERT as a PDF on a your mobile phones screen.

@jschlyter Nothing. The "adversary" is not the person showing the certificate but the person who verifies the certificate. The mechanism would protect the person showing the certificate in a wallet app. However, it only protects against low-effort attacks (i.e. adversaries using a genuine app) and accidental use of a wallet app instead of verifier app but is no bullet-proof protection (e.g. a modified verifier/wallet app could still collect HCERTs even though they start with HC3-DNI).

But IMO it's a low-effort and medium/high-gain proposal and thus worth pursuing.

[jschlyter]

@mlenkeit You then put additional requirements on verifier apps. The system was designed to have an open ecosystem for verifiers - anyone should be able to scan and read a HCERT. In fact almost every country has at least one HCERT verifier app now.

[mlenkeit]

@mlenkeit You then put additional requirements on verifier apps.

@jschlyter Exactly, it's a new requirement for verifier apps (to support an additional prefix such as HC3-DNI in addition to HC1) and an option for wallet apps to display HCERTs either with HC1 or HC3-DNI.

My understanding is that the prefix is also part of the HCERT spec, so it seems that this is the right repo to discuss this, isn't it?

[jschlyter]

@mlenkeit We have currently no requirements to support these use cases. The way forward would be to define any new requirements first and then look at how those requirements can be met. There are multiple efforts to provide verifiable credentials and any changes to this one should probably take a look at those as well before diving into a design phase (once the requirements are set).

[jkrwdf]

In https://github.com/corona-warn-app/cwa-wishlist/issues/601 I suggested to realize a bit with the meaning of "Do not import" (to be set in the presentation screen of wallet apps) in the unprotected part of the COSE structure of the DCC.

IMHO this is more lightweight than introducing a completely new HC-type, as verifier apps should ignore unknown content in the unprotected section (of course it would need to be tested nevertheless).

The argument why this issue was closed was "But then it is not longer possible to take over a cert from one device to another" is countered with the mitigation that only the "Presentation Screen" shall have DNI set, but not the QR codes in the detail areas of the apps or the PDF printout.

[jschlyter]

@jkrwdf Yes, using the headers to indicate this is way better. You could use a claim in the protected header for this if you want to as well (but since it is a recommendation only it doesn't really give you anything).

[schlichtanders]

(but since it is a recommendation only it doesn't really give you anything).

It gives you that others cannot easily steal your cert just by showing it to them via the app. (as most won't have a custom scan tool, but use the default corona app of the country)

[schlichtanders]

"But then it is not longer possible to take over a cert from one device to another"

For my security understanding it is totally fine to let users rescan their doctor's printout, in case of device change, or if the printout is lost, they can always let their doctor recreate a printout given their vaccination passport.

[jucktnich]

@asitplus-pteufl regarding "added": that's the way I proposed Regarding "added2": in my proposal I've added a key value pair to the protected part (the part which is used today) which says it's an HC4. This would prevent downgrade. For paper mode the expiration date should just be set to the date in f.e. one year.

[Jo-Achim]

Personally, I am definitely in favor of comfort and convenience, but where it does not work or ways out are too complicated, I can join @schlichtanders statement without restrictions:

For my security understanding it is totally fine to let users rescan their doctor's printout, in case of device change, or if the printout is lost, they can always let their doctor recreate a printout given their vaccination passport.

Incidentally, even in the electronic age, nobody has to throw away their digital paper vaccination certificate.

[jucktnich]

@Jo-Achim at least in the German corona warn app and cov pass app there's an export function, which should use the HC1 prefix/include the private key

[Jo-Achim]

[OT] According to a current newspaper article, the CWA should become the standard 'Check-in-App' from the perspective of the new Infection Protection Act. See: Corona-Warn-App: Die Rückkehr des "zahnlosen Tigers".

If this is the case, security becomes much more important. [/OT]

[jucktnich]

@Jo-Achim in which way does this affect certificate safety?

[mlenkeit]

In corona-warn-app/cwa-wishlist#601 I suggested to realize a bit with the meaning of "Do not import" (to be set in the presentation screen of wallet apps) in the unprotected part of the COSE structure of the DCC.

@jkrwdf that's a pretty clever proposal, not sure how I missed that. We'll keep that in mind, because that's something that CWA could implement without breaking compatibility with apps of other EU member states.

@jkrwdf Yes, using the headers to indicate this is way better. You could use a claim in the protected header for this if you want to as well (but since it is a recommendation only it doesn't really give you anything).

@jschlyter any modifications to the protected header would require to update the signature. At least for some the the threats outlined here, a bit in the unprotected header would be sufficient.

[Jo-Achim]

@jucktnich,

@Jo-Achim in which way does this affect certificate safety?

Not at all. But the other way around it turns into a shoe: With the increasing importance of the CWA, the security requirements, for example not being able to abuse the CWA, become higher.

[vaubaehn]

@mlenkeit @jkrwdf @jucktnich and all others:

In the scope of preventing "accidental" storage of DCCs with the official wallet apps (and not to prevent frauds that require more criminal intentions and at least some very basic skills on handling other QR scanners), I also vote for this idea.

The idea to put a flag into the unprotected COSE header is brilliant and easy.

However, when implemented it needs a very clear communication to the public about its purpose to not have many complaints from "security experts" about the short comings of this approach.

For the implementation into wallet apps, I strongly propose to make the use of the DNI flag optional. It could be the default behavior, but it should be able to have it turned off for the use cases when the paper printout was lost, and users want to copy their DCCs from one phone to the other (or for an adhoc sharing in any "family" scenario). Onboaring after update could take the user to the settings menu with focus on the new option and a small explaining text overlay.

Thanks for working on this! ❤️

(edit: I don't know why, but somehow this approach reminds me on the good old times, when we had our tape recorders. You could easily circumvent the write protection by sticking a piece of glue tape over the "write-protection-hole", but anyway you were still protected from accidentally overwriting your favorite music tape with some silly radio show 😉 )

[jkrwdf]

For the implementation into wallet apps, I strongly propose to make the use of the DNI flag optional. It could be the default behavior, but it should be able to have it turned off for the use cases when the paper printout was lost, and users want to copy their DCCs from one phone to the other (or for an adhoc sharing in any "family" scenario). Onboaring after update could take the user to the settings menu with focus on the new option and a small explaining text overlay.

I can only speak for the two German wallet apps (CWA and CovPass). Both render the DCC QR code at two different locations.

One is the "Presentation Screen" you reach when starting the app or switch to the certificates area. This is the candidate for DNI as it is the thing you present to others regularly.

The other one is the "Certificate Details" which you reach by tapping on the presentation screen and then selecting the desired certificate. Here, DNI is not necessary.

User guidance for the "Device migration" use-case is this: When the wallet app scans a QR code with DNI set, it shows a message like this:

The scanned QR code is intended for verification only (in Germany, use CovPassCheck for this purpose). To transfer your digital certificates from one device to another, scan the QR code you can generate from the certificate details

Bonus of this approach: The user is made aware of the fact that the QR code shown in the presentation screen is only a single one and it would be incomplete to migrate only this one.

Assume the user has two vaccinations and a current rapid-antigen-test in his wallet, the wallet chooses the RAT certificate for presentation. When the user then uses this "Settings switch" to remove DNI here, he would successfully take over the RAT certificate and miss the fact that in the details there are dormant vaccination certificates.

[jucktnich]

This article (in German) shows how important it is to at least implement solution 1. https://www.ksta.de/koeln/datenspeicherung-koelner-gastwirt-warnt-vor-corona-warn-app-bei-2g-kontrollen-39197126

[Jo-Achim]

This article (in German) shows how important it is to at least implement solution 1. https://www.ksta.de/koeln/datenspeicherung-koelner-gastwirt-warnt-vor-corona-warn-app-bei-2g-kontrollen-39197126

Quote:

„Wie bei so vielen anderen Verordnungen auch, hat es ja auch für die Durchführung der 2G-Kontrollen keine Anleitung oder Gebrauchsanweisung gegeben“. "As with so many other regulations, there were no instructions or instructions for use for carrying out the 2G controls."

There is a massive shortage here! The best app on the planet is useless if nobody knows what to do with it and how - or not.

The fact that organizers want to switch to "2G plus" may be a workaround, but if this workaround has no infection / health protection reasons, it is pretty pointless. And increases the effort compared to "2G" and a scan with CovPassCheck.

Also because of this: Marketing for the CWA or maybe I should go back to the original topic of the link "Promotion of the CWAs 'Check-in' functionality ..." and expand it to CovPassCheck / CovPass.

[vaubaehn]

@jucktnich and @Jo-Achim Regarding the referenced newspaper article, it looks like first countermeasures for the CWA are on their way: https://github.com/corona-warn-app/cwa-app-android/pull/4502

While CWA can be seen as a blueprint for the general problem affecting the EU wide system, I'm a bit insecure whether we should focus more on the general topic as this is the ehn hcert spec repo? 🤔

[Jo-Achim]

@vaubaehn, thanks for the link.

As for the "blueprint for the general problem", it might not hurt to post possible effects of the problem here as well. Even if it is only to underline the urgency of a solution or to make it clear that outside of the CWA design and its implementation, more of the advantages of the CWA are to be made public. (Whether this is always the correct target address here or elsewhere (in the forum) may, in my opinion and in the sense of a support, be open.)

[jucktnich]

Just to mirror some links regarding bad press cause of this "security flaw" from the Corona-warn-app repos:

• https://www1.wdr.de/fernsehen/lokalzeit/koeln/videos/video-missbrauch-mit-impfzertifikaten-per-warn-app-100.html
• https://www1.wdr.de/nachrichten/rheinland/barbesitzer-deckt-sicherheitsluecke-corona-warn-app-auf-100.html
• https://heise.de/-6289943

[jucktnich]

The German CWA will start to limit the number of certs in the wallet, this should show how urgent the problem is. Cause a limit is not the optimal way, I ask you @jschlyter to maybe reevaluate this topic with the EU, to at least implement an "Do-not-import" tag.

[Ein-Tim]

FYI: https://github.com/corona-warn-app/cwa-app-android/pull/4502#issuecomment-990303506 says:

this [= a "Do Not Import" flag in the QR code to prevent accidentally importing certificates again] is also coming soon , wait for it.

So seems like at least the CWA has found a solution.

[jschlyter]

The German CWA will start to limit the number of certs in the wallet, this should show how urgent the problem is. Cause a limit is not the optimal way, I ask you @jschlyter to maybe reevaluate this topic with the EU, to at least implement an "Do-not-import" tag.

I believe Germany needs to bring this to the EHN for discussion regarding schema changes, I'm only but a humble servant of the Swedish eHealth authority (where we do not have this issue).

[ryanbnl]

This hasn't been taken to the eHN for discussion. I'll close the ticket for now, if anything changes then it will be re-opened.