Revocation of a green pass about it-dgc-verificac19-android HOT 91 CLOSED

Just my 2 cents:

• The european rule aimed to create a digital green CERTIFICATE, to allow for easier checking that a person either had been vaccinated, had a negative COVID test in the immediate past or had recovered from the disease. So, invalidate a certificate in case of a new infection is semantically wrong (i.e. it is not because now I am positive that I have not been vaccinated in the past)
• Here in Italy we decided that this should be a green PASS, to allow for access in public places

Certificate and pass are two very different concepts, but someone failed to realized that.

So, AFAIK, at the moment there is no mean of invalidating a green pass in case of reinfection. This is not to attribute to the VerificaC19 app though. Simply, the app (correctly, i.e. according to the european standards) validates a certificate and not a pass.

Solution: emit green passes with a duration of e.g. 3 days, to renew until the expiry of the e.g. 9 months the vaccination is valid. This way, without the need of a CRL, any pass will be valid for a short period of time, and, in case of reinfection it could be not reemitted. This will obviously penalize anyone that does not have ready access to the Internet, to renew the pass, e.g. the elderly.

from it-dgc-verificac19-android.

How is possible to get the annexes of DPCM 17 06 2021? The text states that the annexes are in the ministero salute site; can someone give me the related page address? Thanks

https://www.governo.it/sites/governo.it/files/Green_Pass_all_B.pdf (don't swear on image PDF, I have abused profanities enough for everybody)

from it-dgc-verificac19-android.

I am afraid that VerificaC19 failing to recognize an invalid green pass (due to a vaccinated person getting infected) may lead to bad PR if reported on mainstream media
“Green passes do not stop Covid-infected persons from getting into restaurant”
Or even more extreme “I’ve got no covid and no green pass, and I can’t enter restaurants; he is vaccinated and has covid, and he can! Big pharma ************!”

I think that covidc19 should implement paragraph 2 of dpcm annex by checking into a national “DGC revocation list” which contains the IDs of revoked green passes, exactly like described in paragraph 2.

If this “DGC revocation list” is not foreseen by European framework, this is not an issue. DPCM is an Italian law and there is no need to share it with other European countries.

Let’s not forget that VerificaC19 is not in communication with the European gateway but only with the Italian backend.
The Italian backend may implement this “DGC revocation list”. It will be used by VerificaC19 but it won’t be shared with the European gateway.

from it-dgc-verificac19-android.

A CRL is not excluded for privacy concerns.

Actually Annex B of DPCM, paragraph 2, explicitly introduces such CRL.

Garante della Privacy has not objected to such CLR, so far.

from it-dgc-verificac19-android.

It seems that v1.1.6 implemented a blacklist mechanism or so. None of QR in https://github.com/denysvitali/covid-cert-analysis/blob/master/RESULTS.md is verified anymore.

It's a quick "dirty" fix using the certificate validation rules (https://get.dgc.gov.it/v1/dgc/settings). Only these 4 certificates have been blacklisted:

{
   "name":"black_list_uvci",
   "type":"black_list_uvci",
   "value":"URN:UVCI:01:FR:W7V2BE46QSBJ#L;URN:UVCI:01:FR:T5DWTJYS4ZR8#4;URN:UVCI:01DE/A80013335/TCXSI5Q08B0DIJGMIZJDF#T;URN:UVCI:01:PL:1/AF2AA5873FAF45DFA826B8A01237BDC4;"
}

from it-dgc-verificac19-android.

Hi, this is hardly an enhancement. This is a hard requirement. Otherwise you give OK to GP which must be revoked.

from it-dgc-verificac19-android.

I think the attack scenario for CRL is that anytime any verifier should be able to download the full list of revoked passes

They'd be just random numbers, until one could match them with a real certificate. Then, the only information that can be desumed is that that certificate's owner might have become ill OR their pass might have been stolen, which adds very little to what can already be known by processing valid certificates: even in that case, one can know that a person has gotten ill: that info is written right into the certificate.

In this scenario, ZKP doesn't seem to be a solution because, even if one doesn't know what is into the CRL, the moment a certificate is checked through ZKP against it, then one knows that that certificate is in the CRL, and that info can be shared with other copies of the malicious app through a side channel.

from it-dgc-verificac19-android.

Paragraph 2 of Annex B of DPCM may be due to a misunderstanding, however the DPCM is law in Italy and its intent is clear: if a vaccinated person gets infected, his green pass becomes invalid.
Perhaps the revocation of green passes can’t be implemented with CRLs mentioned in the EU document, but it must be implemented anyway otherwise VerificaC19 does not comply with Italian DPCM.

from it-dgc-verificac19-android.

The DPCM states the rules for validity of green passes. VerificaC19 is the official app to check green passes.

Among these rules, green passes may become invalid if a vaccinated person gets infected (as long as this infection is reported).

It could be that no green pass has been revoked so far (although there are vaccinated people who got infected according to official statistics); but, if it happens, will VerificaC19 show that those green passes are invalid?

from it-dgc-verificac19-android.

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

Doesn't the same issue exist on the opposite side of the fence? Like, a modified app could store all certificates to know who's been tested/vaccinated/ill. On the other end, a health certificate could be revoked for a set of multiple reasons, not just the infection: a hcert could be stolen, for instance, as it actually happened already.

Even "worse": a modified app could connect with a central db to store that info, linked with the location data of the hcert validation event, to track a person's habits and their movements.

from it-dgc-verificac19-android.

@cifred98

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

But here comes the law, prohibiting to retain information. Yet, at least on paper...

We know that these certificates/passes already reveal a lot of information. If on August 10th I show a valid certificate expiring in less than 48 hours, chances are that I made a swab (thus I am not vaccinated). Worse if I bring always a new short-lived certificate with a different serial number. I am forbidden to process such information in a modified app, despite technically feasible.

A malicious verifier can already do a lot of nasty things, including geolocation tracking (as soon as the malicious app is given to a number of verifiers scattered around). Pass contains subject's biographic data that could be matched with marketing lists etc, adding precious health information to the subject's profile.

These dangerous behaviours are particularly forbidden, but nobody is tearing their hair because of the possibility of a mass surveillance with few changes to the code of this app. So I really don't fully understand why we are reluctant to implement CRLs the classic way while the population can be under surveillance since yesterday.

In the case of revocation list, the presence of a mere ID in the revocation list reveals that the certificate is now invalid. This may be caused by:

• The subject got infected
• The pass was abused

There is no 100% assurance on the first event. Yet, any kind of processing of this data is forbidden under the law.

@jaromil

as mentioned by @ddbit privacy concerns could be solved by use of zero-knowledge proof, but this unfortunately requires an entirely different procedure for signatures that should replace the EU '90s style crypto scheme with something actual.

I am not sure this could be possible. As discussed, a malicious user (for example, gym owners are currently retaining a copy of their customers' passes) is supposed to be retaining the unique ID of the certificate along with the subject's data. Forgive me for not having read the articles yet, but if a genuine verifier can (live, on the fly) check that a certain certificate ID is (not) revoked, why shouldn't someone who already pwned the full QR code?

@MatteoPier

Solution: emit green passes with a duration of e.g. 3 days, to renew until the expiry of the e.g. 9 months the vaccination is valid. This way, without the need of a CRL, any pass will be valid for a short period of time, and, in case of reinfection it could be not reemitted. This will obviously penalize anyone that does not have ready access to the Internet, to renew the pass, e.g. the elderly.

If all passes have 48-hours duration this will definitely not reveal any information about the vaccination/recovery/swab status of the subject. But as you clearly mentioned, people without proper IT education or those without ready internet access will suffer the most.

from it-dgc-verificac19-android.

In this scenario, ZKP doesn't seem to be a solution because, even if one doesn't know what is into the CRL, the moment a certificate is checked through ZKP against it, then one knows that that certificate is in the CRL, and that info can be shared with other copies of the malicious app through a side channel.

ZKP proofs (certificates to check) are untraceable and their fingerprint is the same only within the same context (UID). One malicious app disregarding the data-retention policy would not be able to track them across contexts whose definition very much depends on implementation specifics (time-based, location based etc.)

Also by applying the accumulator / witness approach detailed in hyperledger, the CRL would not expose fingerprints in clear.

So let me dissent here: if properly applied a ZKP crypto scheme would not allow malicious apps to track revocations.

from it-dgc-verificac19-android.

We agree to disagree then, also about being blatant... the world is full of unqualified experts and we must live with that.

FTR and all technicalities considered, my humble opinion about the policy is to agree with @MatteoPaier:

Certificate and pass are two very different concepts, but someone failed to realized that.

So, AFAIK, at the moment there is no mean of invalidating a green pass in case of reinfection. This is not to attribute to the VerificaC19 app though. Simply, the app (correctly, i.e. according to the european standards) validates a certificate and not a pass.

This is also well explained by an authoritative expert here https://www.giornalettismo.com/revoca-green-pass-verifica-c19-stefano-zanero/

from it-dgc-verificac19-android.

Any news on this one? We are developing an international software and just checked with an italian lawyer that we have to comply with this law (which was also cited here) in order to offer our service in Italy. But after reading this whole thread, it doesn't seem to me there is any implementation (or even an actual finished concept) for this law or any revocation lists yet, is there? I mean all in all this is the official app for Italy, if that doesn't have an implementation for revoking, so doesn't comply with this law, how are we supposed to do it?

from it-dgc-verificac19-android.

So at the end of the discussion, what we know is that an idea which was created to protect people (privacy) is actually endangering people (by allowing spreading of a disease).

It's a real mistery for me why the information about a person being or not harmful for millions of people should be kept secret.
As a matter of fact, currently if a person is a killer and is walking around, people is immediately informed and warned; if a person is infected by a killer and contagious disease and is walking around, it must be kept secret.
It's just insane.

Apart from this, I don't understand why such a critical issues didn't go mainstream yet: with current version of the app, during next Covid peak we could have ten millions people infected but "legally" free to walk around destroying society.

from it-dgc-verificac19-android.

It was all a design defect in the earliest project stages. It was clarified several times that the best privacy-preserving approach is short-lived certificates (all 48 or 72 hours, but vaccinated/recovered would get a free renewal online).

My best educated guess is that a lot of people, especially the computer science illiterates (analfabeti informatici) that do now own a smart device or own a smart device too old prefer paper certificates. Some of them even line up at pharmacy (and spend up to 4€ according to unverified sources) to get a printed copy of the green pass. Now these people would have to regenerate the pass every 48 hours and print it on a new sheet of paper.

Owners of IO/Immuni apps could get their certificate renewed online already, but it requires the phone to go online regularly to update. IO app requires a new login every 30 days.

Of course there is a privacy misconception again: some people will argue that they will have to go online every 48 hours to download a new pass, but that's the same who are 24/7 connected and Accept every kind of privacy-related question by questionable mobile apps (e.g. you complain the Government is tracking you but you granted a free game access to your live GPS location for marketing purposes).

It's a real mistery for me why the information about a person being or not harmful for millions of people should be kept secret.

This is the core concept of privacy. Unless there is a legal basis, information regarding one's health is heavily protected. Discrimination and prejudice are behind the corner. Until the law changes, this information is private.

As a matter of fact, currently if a person is a killer and is walking around, people is immediately informed and warned

I disagree with the statement because the statement is not well-posed. Being a killer does not affect one's appearence and make someone more recognizable. I never had the privilege (sarcasm on) of meeting one of them, but I am totally confident that in certain Southern cities (e.g. Naples, Foggia, Locri...) killers are walking around like normal people waiting to get their next job from organized crime.

if a person is infected by a killer and contagious disease and is walking around, it must be kept secret.

Thanks to the vaccination campaign that dropped the fatality rate, I'd refrain from calling SARS-CoV-2 a killer agent nowadays.

Call it private information, sensitive or discreet information. Only authorized people (medical doctor, national health service...) are allowed to know one's health and vaccination status. The privacy law prohibits the employer, the gym owner etc. from knowing one's health status, make questions about why didn't you get vaccinated? etc.

from it-dgc-verificac19-android.

It looks like a DRL (D stands for …?) is being developed.

Looking at committed code, its main features are:

1. Improved download to handle larger files
2. Revocation list contains hashed certificate ids

Probably the current implementation (revoked ids mixed together with business rules) was not considered scalable.

In the meantime the current revocation list is (mildly) updated. There are now 200+ Italian certificates revoked.

from it-dgc-verificac19-android.

Actually "certificazioni verdi" can be revoked, according to Italian DPCM, see paragraph 2 here

from it-dgc-verificac19-android.

Aside from DPCM rules about revoking individual GPs because holders could get infected, what about the fact that GPs could be lost or stolen and used by someone else?

Should exists a way for the holder to self revoke her/his stolen GP? Does it make sense?

from it-dgc-verificac19-android.

It's not a bug, it's a feature. See paragraph 6.1 here

It is anticipated that health certificates can not be reliably revoked once issued, especially not if this specification would be used on a global scale. Publishing of revocation information containing identifiers may also create privacy concerns, as this information is per definition Personally Identifiable Information (PII).
For these reasons, this specification requires the Issuer of HCERTs to limit the validity period of the signature by specifying a signature expiry time. This requires the holder of a health certificate to renew it at periodic intervals.

I wonder: couldn't the digital signature itself be put in a "black list"? Not the signing certificate key, nor the health certificate itself, but the final signature. This way no personal info would be disclosed.

Or what am I missing?

from it-dgc-verificac19-android.

I wonder: couldn't the digital signature itself be put in a "black list"? Not the signing certificate key, nor the health certificate itself, but the final signature. This way no personal info would be disclosed.

For that matter there is already an Unique Certificate Identifier that could be used to revoke them, no need to use the signature

Or what am I missing?

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

from it-dgc-verificac19-android.

The privacy violation is knowing that a certain certificate has been revoked. For example someone could store all the certificates that he has access to (e.g. using a modified verifier app) and then check every day the revocation list to see which of their previous customers got infected.

Doesn't the same issue exist on the opposite side of the fence? Like, a modified app could store all certificates to know who's been tested/vaccinated/ill. On the other end, a health certificate could be revoked for a set of multiple reasons, not just the infection: a hcert could be stolen, for instance, as it actually happened already.

from it-dgc-verificac19-android.

The HCERTS spec already has the concept of revocation list, and the mere fact that a hcert can expire means that its semantics already include the fact that what was certified once is not certified anymore.

The semantic problem I'm referring to is that if the certificate says that I am vaccinated and I am really vaccinated, it is wrong to invalidate it because of a reinfection. The fact that I'm vaccinated it's not related to the reinfection.
The HCERT must be invalidated if the thing that it certificates ceases to exists, say e.g. that it comes out that I was in fact vaccinated only with water.

Reducing the cert validity is a patch to allow for easy revoking. Since it is automatically revoked every n days, it is possible to not reissue the HCERT in case of reinfection.

But the key problem remains: we are using certificates as passes, while we probably need two different things. Green Certificates to adhere to the European standards (and allow for international travel) and Green Passes to enter public places.

(Moreover: let's say that we now discover that the lot I was vaccinated with had a fabrication issue and does not protect me from the virus. At the moment it is not possible to invalidate my DGC, since it is signed for 9 months and there is no CRL. The only way to solve a case like that is to revoke the signing keys and reissue all the valid certificates.)

from it-dgc-verificac19-android.

The HCERTS spec already has the concept of revocation list, and the mere fact that a hcert can expire means that its semantics already include the fact that what was certified once is not certified anymore.

The semantic problem I'm referring to is that if the certificate says that I am vaccinated and I am really vaccinated, it is wrong to invalidate it because of a reinfection. The fact that I'm vaccinated it's not related to the reinfection.

I understood that, but you are "still vaccinated" even if the hcert expires, and especially if it expires, as you propose, every three days. That means that the validity of the hcert is not connected with the concept that you are vaccinated. Revoking an hcert because you got ill, thus, doesn't hinder its semantics.

The crux of the issue is that certifying you're vaccinated has a purpose. That purpose can be, among the others, as the EU itself says, a "Travel purpose", i.e., at all effects, the hcerts assume the role of a travel pass.

And if it can be used to determine whether you can travel, it's only a natural consequence that it can be used to determine whether you can enter a shop.

from it-dgc-verificac19-android.

The purpose of VerificaC19 may technically be “to validate the certificate”, but its practical purpose is to allow / don’t allow someone inside a shop / restaurant / whatever.

That is, the owner of the restaurant checks a green pass with VerificaC19. If VerificaC19 says “Ok”, the customer is allowed (as long as the certificate matches the personal ID).

DPCM says that the green pass of a vaccinated person who gets infected is revoked; that is, that person should not be allowed inside the restaurant.

Therefore I argue that VerificaC19 should, in that case, show “not valid” to the restaurant owner, even if that person is “still vaccinated” and therefore the green pass is still “true”. Otherwise, how can the restaurant owner know that the customer should not be allowed in?

from it-dgc-verificac19-android.

FWIW, Switzerland implements such a revocation mechanism via a remote CRL, as described e.g. here on page 8 https://github.com/admin-ch/CovidCertificate-Documents/blob/main/20210617_CovidZertifikat_Presentation_System_Integration.pdf

from it-dgc-verificac19-android.

if a revocation list (even of hashed certificates ) is a privacy concern, did anyone think of using zero-knowledge proofs or rsa accumulators to prove that a certificate is in a encrypted revocation list?

from it-dgc-verificac19-android.

if a revocation list (even of hashed certificates ) is a privacy concern, did anyone think of using zero-knowledge proofs or rsa accumulators to prove that a certificate is in a encrypted revocation list?

developers spent more time drafting the base45 encoding than focusing on such details. Here my post detailing how ZKP can already be done using software we developed in a flagship EU research project https://medium.com/think-do-tank/the-eu-vaccine-passport-c0af92f0bc1c

from it-dgc-verificac19-android.

from it-dgc-verificac19-android.

So let me dissent here: if properly applied a ZKP crypto scheme would not allow malicious apps to track revocations.

The moment you need to check whether a certificate is valid or not, you are going to know whether a certificate, with its unique ID and related personal info, is valid or not. That information can be shared to other malicious apps through a side channel.

Given that the certificate itself contains information about its own expiration date - and this cannot be changed - it means that if the expiration date hasn't been reached yet, it can only be invalid for reasons that are not related to the expiration date, and those reasons are exactly the information you'd not want to be known and which prompted you to postulate the necessity of ZKP.

That's why I state that ZKP is not useful in this context.

from it-dgc-verificac19-android.

from it-dgc-verificac19-android.

We agree to disagree then, also about being blatant... the world is full of unqualified experts and we must live with that.

Putting this on a personal level is very typically Italian, yet you have not proved the correctness of your claims nor you have proved the incorrectness of mines.

from it-dgc-verificac19-android.

I agree with keeping the "idiological" discussion out of here. You're right that this is something the ministry of health needs to figure out and supply this "database" (how ever this might look). But then again, this literally is the Github page of the ministry of health, so I can't think of a better place for this issue, so I disagree on the "WONTFIX" as long as this law is in place/until this section gets removed by the italian government.

from it-dgc-verificac19-android.

It seems that v1.1.6 implemented a blacklist mechanism or so. None of QR in https://github.com/denysvitali/covid-cert-analysis/blob/master/RESULTS.md is verified anymore.

from it-dgc-verificac19-android.

It seems that v1.1.6 implemented a blacklist mechanism or so. None of QR in https://github.com/denysvitali/covid-cert-analysis/blob/master/RESULTS.md is verified anymore.

It's a quick "dirty" fix using the certificate validation rules (https://get.dgc.gov.it/v1/dgc/settings). Only these 4 certificates have been blacklisted:

{
   "name":"black_list_uvci",
   "type":"black_list_uvci",
   "value":"URN:UVCI:01:FR:W7V2BE46QSBJ#L;URN:UVCI:01:FR:T5DWTJYS4ZR8#4;URN:UVCI:01DE/A80013335/TCXSI5Q08B0DIJGMIZJDF#T;URN:UVCI:01:PL:1/AF2AA5873FAF45DFA826B8A01237BDC4;"
}

How can they just disable some certificates? This would invalidate some millions of valid DGCs!!

from it-dgc-verificac19-android.

If you go to https://get.dgc.gov.it/v1/dgc/settings you’ll see a list of revoked (blacklisted) green passes.
Several of them are Italian

from it-dgc-verificac19-android.

Would be nice to have an "official" statement of the ministry of health what that list under https://get.dgc.gov.it/v1/dgc/settings really contains. Just like @djechelon I too think, we're talking about two different things here. As far as I understood the lawyer, the law say that if a vaccinated person was to be tested positively, the green pass shall be revoked (postponed) until that person was to be tested negatively again. Of course that can/maybe has been/will be implemented in the same blacklist under https://get.dgc.gov.it/v1/dgc/settings but currently it is unclear to me whether these are only some blacklisted (fake) certificates or whether that blacklist is the actual "database" for "postponing" green passes mentioned in the law.

from it-dgc-verificac19-android.

They won’t revoke DGCs of who get tested positive because unique IDs of these certs are PII (Personal Identifiable Information. They revoke only DGCs emitted to to not existent people (so not PII) and to stop media resonance too

from it-dgc-verificac19-android.

Yes. But I think the issue in publishing PII in revocation list came from GDPR, art. 9 n. 2 letters i) and h). These data are processed by anyone and this is forbidden by art. 9 n. 3 (and too art. 6 n. 3 par. 2)

from it-dgc-verificac19-android.

The CRL implementation adopted makes use of idemix, originally adopted by the Dutch app. This is a "first generation" ZK scheme that produces non-aggregable unique identifiers (UID) of the data whose only privacy feature is being "keyed" with a nonce or context-uid.
According to the law (IANAL) any unique identifier of private data is considered private: in this ZK case the knowledge of the UID and nonce is pretty much the same as a new hash of the data. Therefore this CRL implementation still leaks private data.
A privacy preserving implementation should use aggregate lists of CRL and therefore a ZK implementation producing aggregable UIDs, i.e. as described by the hyperledger revocation list implementation I linked in a previous comment.

from it-dgc-verificac19-android.

There are now 128 Italian green passes revoked / blocked / blacklisted.

I don’t know who those green passes belong to and why they were revoked. Anyway I think it doesn’t matter.

A revocation list is in place, it’s updated and VerificaC19 checks it. I think this closes this issue (which was “does VerificaC19 handle green pass revocation?”)

If someone thinks that a green pass blacklist violates privacy, this is an issue against DPCM (and not against VerificaC19, which is now compliant with DPCM) and should raise the issue with Garante della Privacy.

from it-dgc-verificac19-android.

It's not a bug, it's a feature. See paragraph 6.1 here

It is anticipated that health certificates can not be reliably revoked once issued, especially not if this specification would be used on a global scale. Publishing of revocation information containing identifiers may also create privacy concerns, as this information is per definition Personally Identifiable Information (PII).
For these reasons, this specification requires the Issuer of HCERTs to limit the validity period of the signature by specifying a signature expiry time. This requires the holder of a health certificate to renew it at periodic intervals.

from it-dgc-verificac19-android.

AFAIK the gateway doesn't support CRLs of DGCs.
I think that paragraph 2 of Annex B of the DPCM is the result of a misunderstanding of paragraph 3.3 here. The CRLs mentioned in the EU document are meant to revoke signing certificates, not individual DGCs.

from it-dgc-verificac19-android.

If a vaccinated person gets infected they must stay home. Not at a restaurant, not in a bus, not in an airplane, home.

Yes, I know, we know Italy well and we know what happens in Italy, but this is exactly the same problem that we had a few months ago.

The solutions that should apply here are the same that used to apply before the green pass was a thing. Putting people's privacy at risk (more than it already is, since the certificate is personally identifying) is not a better solution.

from it-dgc-verificac19-android.

How is possible to get the annexes of DPCM 17 06 2021? The text states that the annexes are in the ministero salute site; can someone give me the related page address? Thanks

from it-dgc-verificac19-android.

Doesn't the same issue exist on the opposite side of the fence?

Yes, we are already giving up some privacy with the current certificates.
Let's not make it worse.

from it-dgc-verificac19-android.

Doesn't the same issue exist on the opposite side of the fence?

Yes, we are already giving up some privacy with the current certificates.
Let's not make it worse.

I think the surface area of privacy attacks is large enough that one more thing can't really make it that much worse. One must weigh the pros and cons. The question bodes down to: is it an essential feature to be able to revoke hcerts, to the point that not having it hinders the whole purpose of hcerts?

from it-dgc-verificac19-android.

Just my 2 cents:

• The european rule aimed to create a digital green CERTIFICATE, to allow for easier checking that a person either had been vaccinated, had a negative COVID test in the immediate past or had recovered from the disease. So, invalidate a certificate in case of a new infection is semantically wrong (i.e. it is not because now I am positive that I have not been vaccinated in the past)
• Here in Italy we decided that this should be a green PASS, to allow for access in public places

Certificate and pass are two very different concepts, but someone failed to realized that.

Not sure I agree with your reasoning.

The HCERTS spec already has the concept of revocation list, and the mere fact that a hcert can expire means that its semantics already include the fact that what was certified once is not certified anymore.

If you reduce the hcert validity to 3 days, it's basically the same as revoking it every 3 days.

from it-dgc-verificac19-android.

I understood that, but you are "still vaccinated" even if the hcert expires, and especially if it expires, as you propose, every three days.

IMHO expiration and revocation of a Certificate are quite different. In both cases the certificate is no longer valid but, while in the first case the reason is the natural "death" of a certificate (like SSL certificates, that do not live forever), in the second the reason is much more serious (remaining on SSL, e.g. a compromised private key).

I know that my proposed solution is not pretty (it tries to patch the current implementation) but I fail to find another (except for a CRL, that I assume it's excluded for privacy concerns).

from it-dgc-verificac19-android.

I think that if we were to start checking Certificates against a CRL in order to allow the revocation in case of infection, we should allow this check to be disabled or otherwise the app would stop being suitable as EU Digital COVID Certificate validator since the European specifications do not provide for this behaviour.
I personally liked the idea of a switch between Italian/European validation rules as suggested by @Aldo97 (even though it was for another issue #110 (comment))

from it-dgc-verificac19-android.

DPCM (with its annex B) is law.
According to DPCM:

1. VerificaC19 is the official app to check green passes
2. If a vaccinated person gets infected, his green pass becomes invalid after being inserted in a revocation list.

I think that VerificaC19 should check this revocation list while verifying green passes. No other app can do that. No other mechanism can be implemented.

Garante della privacy already scrutinized DPCM and made a few remarks, but none on revocation lists.

from it-dgc-verificac19-android.

A CRL is not excluded for privacy concerns.

as mentioned by @ddbit privacy concerns could be solved by use of zero-knowledge proof, but this unfortunately requires an entirely different procedure for signatures that should replace the EU '90s style crypto scheme with something actual.

FTR the following papers detail a suitable ZKP crypto scheme:

• https://arxiv.org/abs/1802.07344 - using the ζ signature produced by the petition scheme in a CRL
• https://ui.adsabs.harvard.edu/abs/2021arXiv210514527R/abstract - where we did precisely that, ζ is called "fingerprint"

Another approach for a privacy preserving CLR is the one developed in hyperledger indy:

• https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0011-cred-revocation/README.html
  where a crypto accumulator (modulo EC), a private factor and a witness are used for blind verification.

AFAIK the latter approach is more complex and requires more space and computation.

One or the other may be implemented adding functionalities to the national issuer without requiring changes in the EU infrastructure.

from it-dgc-verificac19-android.

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once,

As said, those are just random numbers, whose meaning can only be understood when they are matched with a live certificate.

But for the reasons depicted above, when that moment arrives, then there's no difference between the ZKP approach and the non-ZKP approach.

I believe we must live with the fact that hcerts disclose certain amount of personal info for design reasons and that cannot be fixed. The Italian Privacy Authority has already had the matter under its scrutiny and has come out with a verdict that states that the current law and hcerts are ok, under the current privacy framework, given their application scope.

Therefore, like others have said before me, the italian app must just abide by the law.

from it-dgc-verificac19-android.

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once,

As said, those are just random numbers, whose meaning can only be understood when they are matched with a live certificate.

But for the reasons depicted above, when that moment arrives, then there's no difference between the ZKP approach and the non-ZKP approach.

I don't know about you, but I work as an applied cryptographer since 15 years and I lead the technical development of flagship projects for the European Commission focused on privacy-by-design research and data sovereignty. I hereby declare the above is false in my informed opinion: a ZKP approach can make a big difference.

I don't say this to influence any decisional process, but since I am a scientist and this is my field of interest I like facts to be defined with correct information.

from it-dgc-verificac19-android.

Though it makes a lot of difference having a CRL in clear or even with hashed items disclosed by the authorities at once,

As said, those are just random numbers, whose meaning can only be understood when they are matched with a live certificate.
But for the reasons depicted above, when that moment arrives, then there's no difference between the ZKP approach and the non-ZKP approach.

I don't know about you, but I work as an applied cryptographer since 15 years and I lead the technical development of flagship projects for the European Commission focused on privacy-by-design research and data sovereignty. I hereby declare the above is false in my informed opinion: a ZKP approach can make a big difference.

That's a blatant appeal to authority, which doesn't address the crux of the matter in any way.

I'll be happy to be proven wrong, about the specific issue I raised, alas that's not what you are doing.

from it-dgc-verificac19-android.

I think that the distinction between a certificate and a pass is not useful.

An “analog” standard passport, issued by a government, is a “certificate”: it associates a picture with a name and a nationality.
However, standard passport may be “revoked” when the passport holder loses the right to go abroad.

How is this possible? A passport should just be a “certificate”, i.e. - even if the passport holder loses the right to go abroad - his name, nationality and picture do not change!

Of course this happens because a passport is not only a certificate, but also a pass!
I argue that the same holds true for a digital green certificate aka green pass.

The difference with the analog, real world case is that a digital passport - whose validity is checked offline - can’t be easily revoked. The digital green certificate may simply keep a copy of the certificate which - being verified offline - would still appear “valid” to the verifier app.

The solution prescribed by the DPCM (which is law!) is to supplement offline verification with a hybrid offline/online verification, where the verifier app periodically downloads a “revocation list” (daily?) and checks if the digital certificate is listed there.

This works (if it’s implemented, which is not the case currently) as long as the revocation list doesn’t grow too big. Otherwise one could simply download a “good certificate list” and check if the certificate is there!

from it-dgc-verificac19-android.

I think a CRL, even with ZKP, reveals a lot about the size of the list itself.

from it-dgc-verificac19-android.

I have an unfinished implementation made as a Zenroom.org portable scenario, feel free to contact me via email at [email protected] if interested. @marcomarsala is correct in saying that the quantity of revokations is leaked. In my application of ZKP based on Sonnino's Coconut the zeta is a sort of pseudonym related to UID (found in the petition use-case), I haven't studied this use-case enough yet to be sure this would be the best solution.

from it-dgc-verificac19-android.

Everybody forgot that a centralized database of all Italian citizens already exists, and that each Italian citizen holds in his pocket a microchip of Ministero Della Salute, probably invented just to allow easy updates when needed. It would be just a matter of having in each pharmacy a reader/writer for this card (probably it's already there since many years).

There is also a barcode on the card, which any cellphone could read and compare with a database of authorized citizens.

There was no need at all to invent greenpass and qrcode and VerificaC19 app, a whole system able to handle a "health authorization" already exists since 2003.
Probably such a system has been blocked/destroyed/dismantled by privacy laws.

from it-dgc-verificac19-android.

But here they needed offline verification too

from it-dgc-verificac19-android.

@jumpjack the CNS/EHIC card is issued only to EU citizens. The DGC is also issued to extra-EU citizens who got vaccinated in EU.

Chipped EHIC card is not feasible

1. The chip is not deployed in all EU member states, thus is not interoperable. Italian EHICs (TEAM card) has a chip, others don't
2. Reading the chip requires specialized hardware
3. Reading the barcode is possible only in Italy, because EU EHIC cards do not require barcodes according to standard
4. Reading a barcode with national health ID requires permanent online access as @marcomarsala

We have already revealed that long-lived DGCs are a design flaw, and I have tried to explain that the reason behind this flaw is somehow a balance between multiple interests in privacy, effectiveness and technical requirements.

I'd suggest to close this issue because Github issues are a space to discuss technical issues that can be implemented. I believe this issue is a strong WONTFIX that must be addressed by the Ministry of Health.

Of course I am available to contribute by explaining how and why things are done, up to my knowledge.

from it-dgc-verificac19-android.

Or until the government waives the DGC/green pass rule, which should happen by Dec 31st 2021

Or could be renewed till..............................................................

from it-dgc-verificac19-android.

This issue didn't age very well, did it?
Two private keys have been leaked, how will you handle this issue without a CRL?

from it-dgc-verificac19-android.

Keys have been already revoked.
Today the alleged Mr. Hitler certificate is invalid.

This issue discusses revoking individual digital green passes, not the key used to issue them

from it-dgc-verificac19-android.

Mickey Mouse and Hitler greenpass CANNOT be revoked, because the key used to sign them has been used for other millions of greenpass.
This is what is being discussed in this thread since august.

from it-dgc-verificac19-android.

I was reading https://attivissimo.blogspot.com/

Yesterday, Hitler certificates were not recognized by my VerificaC19 (in the blog, you can see screenshot of failed check). Today, the post got an update. I can confirm all certificate listed in the blog work to me after VerificaC19 downloaded latest rules.

I'd also add that Rokotepassieu Ota Yhteyttä Wickr is recognized by my VerificaC19 instance, but Attivissimo claims that his own instance of VerificaC19 fails the check.

The situation is worse than expected.

from it-dgc-verificac19-android.

They could revoke individual certificates adding a rule in the app that denies these certificate unique IDs, or a general rule to refuse certificates with date of birth too past (so it’s sure that belongs to a dead person)

from it-dgc-verificac19-android.

Thanks @cifred98

How can they just disable some certificates? This would invalidate some millions of valid DGCs!!

They are not not revoking the single x509 italian signing cert (DSC), only blacklisting the obviously fake DGC not emitted by MK. MK DSC was already removed in past days.

from it-dgc-verificac19-android.

Has the corresponding code already been published to GitHub? I can't find it

from it-dgc-verificac19-android.

Has the corresponding code already been published to GitHub? I can't find it

Still not published I guess.

from it-dgc-verificac19-android.

Thanks @cifred98

How can they just disable some certificates? This would invalidate some millions of valid DGCs!!

They are not not revoking the single x509 italian signing cert (DSC), only blacklisting the obviously fake DGC not emitted by MK. MK DSC was already removed in past days.

Ah ok, I thought they blacklisted KIDs coded in some weird fashion.... Instead now I see they are blackilisting by UVCI.
But there are only 4 items in blacklist, while (at least) 9 fake DGCs: https://github.com/denysvitali/covid-cert-analysis/blob/master/RESULTS.md

UVCI specifications:

 "certificate_id": {
 "description": "Certificate Identifier, UVCI",
 "type": "string",
 "maxLength": 50,
 "unique": true
 }

Field name: "ci"

 "ci": {
 "description": "Unique Certificate Identifier: UVCI",
 "$ref": "https://ec.europa.eu/dgc/DGC.Core.Types.schema.json#/certificate_id"   // Link is dead, but schema is [here](https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_dt-specifications_en.pdf)
 }

v/ci Unique certificate identifier
Unique certificate identifier (UVCI) as specified in the vaccinationproof_interoperability-guidelines_en.pdf (europa.eu)
The inclusion of the checksum is optional. The prefix "URN:UVCI:" may be added.
Exactly 1 (one) non-empty field MUST be provided.

Examples:
"ci": "URN:UVCI:01:NL:187/37512422923"
"ci": " URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"
Source: https://ec.europa.eu/health/sites/default/files/ehealth/docs/covid-certificate_json_specification_en.pdf

from it-dgc-verificac19-android.

It looks like a revocation mechanism is now in place, as explained above.
Several Italian green passes have been revoked (blacklisted / blocked)
I think this issue can now be closed?

from it-dgc-verificac19-android.

I think we are talking about a couple different things. One is revoking the pass of a single infected patient, one is revoking all fake passes generated from the same key

See also: https://www.mediasetplay.mediaset.it/video/leiene/martinelli-si-possono-avere-covid-e-green-pass-ancora-valido-nello-stesso-momento_F311370301006C02

from it-dgc-verificac19-android.

Yes, we have 2 topics:

• permanently disable fake DGCs
• temporarily suspend valid DGCs of infected people

from it-dgc-verificac19-android.

The blacklist looks "a little" short: currently there are 85287 illegal but valid DGCs only in Italy (7th column, "totale positivi").

from it-dgc-verificac19-android.

@marcomarsala then is this a lie?

«I certificati sono stati disattivati presso il database del ministero della Salute.»

https://tg24.sky.it/roma/2021/11/03/green-pass-falsi-pippo-franco

from it-dgc-verificac19-android.

I don’t think the reason why a green pass is revoked (blocked, blacklisted) matters.
Also, I don’t think we should know whether revoked green passes belong to real people or are fake.
This is for privacy.

Annex B of Dpcm postulates a list of revoked green passes which should be checked by VerificaC19.

To me, it looks like a list is in place and the app checks it.

Now it’s just a matter of populating the list correctly, but this is not an app issue.

from it-dgc-verificac19-android.

I don’t think the reason why a green pass is revoked (blocked, blacklisted) matters.

There is only one cause of revocation, that is testing positive. So the presence of a cert in the revocation list tells health information about the owner.

Also, I don’t think we should know whether revoked green passes belong to real people or are fake. This is for privacy.

Privacy applies only to real and alive, people.

from it-dgc-verificac19-android.

@marcomarsala then is this a lie?

«I certificati sono stati disattivati presso il database del ministero della Salute.»

https://tg24.sky.it/roma/2021/11/03/green-pass-falsi-pippo-franco

If the only revocation list is https://get.dgc.gov.it/v1/dgc/settings it contains 11 Italian DGC unique IDs and we don’t know who these certs belongs to. If they are certs of people mentioned in the article you cited, I think they had revoked these certs without privacy issues because the event was always of public domain, as newspapers wrote about that. It isn’t the same as revoking certs of who tested positive

from it-dgc-verificac19-android.

Does 01IT3DA01DD1A0AA4E4E92A10C11B04D39DB#8 belong to a real person or a fake? How do you know?
(This is a real Zero Knowledge list! Even after looking at it, you don’t know what it contains…)

Does it matter if 01IT3DA01DD1A0AA4E4E92A10C11B04D39DB#8 was revoked due to infection? Should VerificaC19 work differently?

from it-dgc-verificac19-android.

I know if I already meet that cert.

For example, if I scan certs of my customers with a modified version of the app, that keeps a copy of all cert data, I can know if any of my customers will test positive in the future, just looking if his/her cert id appears in revocation list.

from it-dgc-verificac19-android.

Using a modified version of the app which keeps the data is a privacy violation. Garante della Privacy was clear about this.

from it-dgc-verificac19-android.

If they did want to protect personal information in the certificate, they should have encrypted it rather than just signing.
The QRcode is instead just the "computer readable version" of the printed version of DGC in A4 format, which contains all the same data of QR.

from it-dgc-verificac19-android.

Does 01IT3DA01DD1A0AA4E4E92A10C11B04D39DB#8 belong to a real person or a fake? How do you know?

By sure it's not Spongebob's or Mickey Mouse's DGC:
https://github.com/denysvitali/covid-cert-analysis/blob/master/RESULTS.md

from it-dgc-verificac19-android.

As you are the author of the issue you can do whatever you want with your issue. If you are fine with the revocation list as it is, you're free to close your ticket. But I for myself don't have the answers (an official statement) I was looking for and if this issue here gets closed I would create a new one on my own. Because I still don't know if that very revocation list you mentioned complies with this specific law (which was also discussed above) an italian lawyer sent us (I believe it was article 8 of the DPCM)

Gli effetti della validità di ogni certificazione cessano decorso il periodo di validità della stessa, definito dall’allegato B (ovvero, dopo 6 mesi dall’avvenuta guarigione dal Covid-19, dopo 9 mesi dalla seconda dose del vaccino, dopo 48 ore dal tampone negativo, ndr). Nell’eventualità in cui una struttura sanitaria afferente ai servizi sanitari regionali, un medico di medicina generale, un pediatra di libera scelta o un medico USFAM o SASN comunichi alla piattaforma nazionale la positività del Sars-Cov-2 di una persona vaccinata o guarita, la piattaforma nazionale genera una revoca delle certificazioni verdi Covid-19, eventualmente già rilasciata alla persona e ancora in corso di validità, inserendo gli identificativi univoci di dette certificazioni revocate e comunicandoli al Gateway europeo. Della revoca, la piattaforma invia notifica all’interessato

And by the pure number of only 128 revoked green passes I somehow doubt it.

from it-dgc-verificac19-android.

FYI: There are now more than 700 GreenPass(es) stolen and shared on eMule. I tested some samples, and verificaC19 accepted all of them. Is the blacklist updated and really working?
see: https://www.youtube.com/watch?v=12Yemlt2pkI

from it-dgc-verificac19-android.

from it-dgc-verificac19-android.

When the list will start containing hundreds of thousands of invalid greenpasses to be dwonloaded each day, things will become interesting.

@marcomarsala , not that "legal" does not match with "as per VerificaC19" app: it's not legal to go around for sick people, but VericaC19 considers valid their greenpasses.

from it-dgc-verificac19-android.

#192
#194
#196
#198

from it-dgc-verificac19-android.

Since december 18th 2021 is now mandatory to disable/revoke greenpass of infected people:
https://www.leggo.it/italia/cronache/green_pass_revoca_positivi_covid_gateway_europeo_cosa_succede-6392003.html

from it-dgc-verificac19-android.

Ubi maior minor cessat 🙄

from it-dgc-verificac19-android.