Data verification is based on device time, instead of verified server time

NiccoloSegato commented 3 years ago

Describe the bug

In the Android application it is sufficient to modify the device date to change the validity of a certificate. For example, by anticipating the date of the device, a certificate that has already expired can be verified.

Expected behaviour

The date and time should be taken from a certified and unique source, such as a government server, rather than the device date.

Steps to reproduce the issue

From the system settings it is sufficient to change the date of the device to change the result of the verification. It was tested with a certificate issued 11 days after the first dose, therefore not yet valid by law and rightly detected as not yet valid by the app with correct device date settings. Changing the date to a later date 15 days from the dose, then from the date of entry into force of the certificate, and performing the scan again, this gives a positive result.

Technical details

Any Android device

Possible Fix

The date and time should be taken from a certified and unique source, such as a government server, rather than the device date.

giusep1995 commented 3 years ago

A possible solution is to force the connection to internet the first time and syncronize a variable with the server. When the smartphone is without internet connection the app can control the variable and eventually block the app requesting the synchronization of the smartphone time.

jacopo-j commented 3 years ago

How is this a bug of this app? This is part of how offline certificate verification works. If I change the date of my computer backwards I can also browse on websites with expired SSL certificates, duh.

The threat model for this app involves trusting the person executing the check. Otherwise, even taking the current date "from a certified and unique source" would be useless. A malicious checker could just use an altered version of the app that skips any verification and accepts/rejects any certificate.

enricomiletto commented 3 years ago

@NiccoloSegato I don't think this is really an issue imho. It is in the best interest of the checker that the app works as intended (with the time correctly set) as it is the only way for them to ensure that, in the case of a restaurant or a gym for example, they can't get in trouble for letting people without a valid Covid Certificate in.
The fact that the app (with incorrect time & date) showed the certificate was valid at the entrance obviously doesn't mean the checker is not liable for letting a person in if his certificate was expired/not yet valid.

Moreover, as @jacopo-j pointed out if a checker really wanted to "maliciously" let people with unvalid certificated in while still appearing to be checking with the app (to show other clients of the restaurant that they are checking the DCCs, for example) it would be easier for them to use a modified version of the app because by changing the time of the smartphone you would probably invalidate equally as many actually valid DCC's as you would make non valid ones look valid (think of the DCC's for a COVID test that only last for 48h).

I hope i have been useful ;)

Lazza commented 3 years ago

Can we please stop spreading misinformation and false bugs on Github and elsewhere?

Pretty please?

This is clearly not a bug and does not violate the threat model at all. Assuming both the certificate owner and the verifier are accomplices and want to fake the checks does not make sense, as they could do it in a billion ways with no official app at all.

A few online newspapers are already spreading the "news" about this "bug", scaring away non-tech-savvy users and reducing trust in the digital certificate.

By the way this "bufala" has been around for a few days already.

https://mobile.twitter.com/EnricoBassetti/status/1418935571691548685

NiccoloSegato commented 3 years ago

I reported the bug right here on Git to avoid confusion, bringing it to the attention of developers and the development community. Mine is just an open discussion on how to solve the problem, if it can be defined so, going to address the issue together with the developers. I absolutely do not want to create alarmism, otherwise I could have contacted newspapers or blogs 🙏🏼

Lazza commented 3 years ago

Sorry if it seems that I am targeting only your report specifically, but this is the last straw of a too exhausting series of misinformation on the Green Pass that originates from a lack of understanding of how offline verification should work (and the threat model).

First, there was Italian Tech with an invented "flaw" (they then amended the title, but still): https://www.italian.tech/2021/07/31/news/il_sistema_del_green_pass_ha_un_buco_di_sicurezza_la_scoperta_swascan-312372691/

And now this GitHub issue, which has already been exploited by Punto Informatico to create a fake news about a "severe bug": https://www.punto-informatico.it/green-pass-verificac19-app-grave-bug/

(for instance, I indeed discovered this issue because of the fake news article by Punto Informatico)

aiotech-pub commented 3 years ago

Well, this is a bug that is not acceptable on a SW that should be certified as a medical device and it can not because the undergoing HW device is not certifiable at all (being any smartphone). Apart that, the solution is very simple. Considering that the app should work at least 24h offline is sufficient to synchronize the system time using the internal GPS every N minutes. So, to assure that the verifier does not alter the system time, should be implemented this procedure:

When the app starts checks if there is or not a working data connection (via wifi or mobile network) and the app will monitor the data connection status continuously. 1-bis The app checks for the minimum requirements to work: presence of internal GPS, camera and so on
The app acquires the system time
The app acquires the time from a time server on internet (NTP protocol) or if there is no data connection from the internal GPS
If both the remote times are not available the app shall not work and shall advise the verifier to establish a data connection or move around until it will be able to receive the GPS signal
The system time shall be verified against a remote time server or GPS every minute or less
Just in case the app verifies the system time is wrong compared with the remote time more than N (may be 3 or 5) times per day will send a message/email to a central server signaling the verifier and the device. Remember that altering a device used to verify anything in Italy is a crime.

Enrico204 commented 3 years ago

@aiotech-pub this is not a bug, stop spreading misinformation. A evil verifier will use a false app to scan the green pass, if ever.

There is no improvement in the threat model if you force a time sync like that. The verifier can use another app with a similar screen. Or it can ignore the verification at all.

Also, this is not a software for a medical device, or any sensitive device. Those devices are already protected.

Lazza commented 3 years ago

that should be certified as a medical device

What in the name of... Are you talking about?

It's a reader app, it needs to read something. If the user does not want to care about the correctness of what is read they can simply avoid reading it all together.

Moreover, it is not a medical device even by the broadest definition you could possibly invent.

aiotech-pub commented 3 years ago

I am not inventing anything I have more than 25 years experience in R&D of medical devices and I know their regulations. A SW that manages health data shall be certified following the MDD 93/42 and this type of SW falls inside the definition at article 2 point (a). And for the same article the SW and the device where it is installed is a "medical device" so it has to be certified. And, considering that the app may be installed in any Android and iOS smartphones on the market it is IMPOSSIBLE to obtain the certification so this SW should be retired by the market because is not MDD 93/42 compliant and its use without the certification is illegal. In the next days I will inform the regulatory boards asking for urgent seizure of this SW. Laws and regulations have to be valid for everyone there are too many similar cases of similar SW stopped by MDD 93/42 art. 2-a.

aiotech-pub commented 3 years ago

Second... is available a QR code just for testing? I mean a fake but working QR to test the app with a reference QR? Or do you havea test SW to make fakes QR for testing? If you don't have them how did you test that the app is working properly? And is available the app testin plan?

studiofuga commented 3 years ago

What about the hardware? Shouldn't it be certified as well?

spoiler: no. It's not a medical device. In Any means. Full Stop.

aiotech-pub commented 3 years ago

Please read better what I wrote and then read the MDD 93/42 art. 2-a and you will learn something. I am not alone thinking that and in any case the regulatory board will decide not you. Who are you to say it is not a medical device? Are you an expert on MDD 93/42? Do not say me full stop, you can't. Right?

studiofuga commented 3 years ago

Ok you just need to make a certification on all the hardware. Good luck.

...and... "full stop" 🤣

Lazza commented 3 years ago

If you don't have them how did you test that the app is working properly?

In order to understand this you would need some experience in software development and information security.

Enrico204 commented 3 years ago

I am not inventing anything I have more than 25 years experience in R&D of medical devices and I know their regulations. A SW that manages health data shall be certified following the MDD 93/42 and this type of SW falls inside the definition at article 2 point (a).

No. This is the MDD 93/42 article 2 point (a):

Ai fini del presente decreto s'intende per: a) dispositivo medico: qualunque strumento, apparecchio, impianto, software, sostanza o altro prodotto, utilizzato da solo o in combinazione, compreso il software destinato
dal fabbricante ad essere impiegato specificamente con finalità diagnostiche o terapeutiche e necessario al corretto funzionamento del dispositivo, destinato dal
fabbricante ad essere impiegato sull'uomo a fini di diagnosi, prevenzione, controllo,
terapia o attenuazione di una malattia; di diagnosi, controllo, terapia, attenuazione o
compensazione di una ferita o di un handicap; di studio, sostituzione o modifica
dell'anatomia o di un processo fisiologico; di intervento sul concepimento, il quale
prodotto non eserciti l'azione principale, nel o sul corpo umano, cui è destinato, con
mezzi farmacologici o immunologici né mediante processo metabolico ma la cui
funzione possa essere coadiuvata da tali mezzi;

See https://www.salute.gov.it/imgs/C_17_pagineAree_1636_listaFile_itemName_1_file.pdf

Let's see if this software falls in these categories:

"diagnosi, prevenzione, controllo, terapia o attenuazione di una malattia" (not certified translation: diagnosis, prevention, control, therapy or alleviation of a disease): this app is not meant to diagnose, prevent, control or cure a disease. This app is used to verify a digital signature. In fact, a green pass can be issued even without some information (for example, in those case where a vaccine is not the reason for green pass).
"di diagnosi, controllo, terapia, attenuazione o compensazione di una ferita o di un handicap" (not certified translation: to diagnose, control, treat, alleviate or compensate for an injury or handicap): no injury or handicap is involved in the green pass
"di studio, sostituzione o modifica dell'anatomia o di un processo fisiologico" (translation: study, replacement or modification anatomy or physiological process): the anatomy of a person is not the subject of the green pass
"di intervento sul concepimento" (translation intervention on conception): again, this is not related to this point.

Enrico204 commented 3 years ago

If, and only if, this app will ever be able to "diagnose, prevent, control or cure" the SARS-Cov-2 disease, then it will be a medical device. However, this app is not (and never will be) able of doing that.

The only feature of this app is to pick a signed QR code and verify the signature (and the expiration).

aiotech-pub commented 3 years ago

Enrico204: first of all the valid text of MDD 93/42 is in English, so the word is "monitor" that does not means - exactly - "controllo" the nearest translation is "tenere sotto controllo" meaning a form of control during a period of time. So this is an app to monitor the state of disease, because the QR comes from (also) a result of a diagnostic test (green pass) and certifies if a person is negative or not to the test, the test is a system to say if a person is or not infected by covid so because the app reports the result of a test it is part of a monitor system. For this reason IT IS a medical application that has to be certified. Not so difficult to understand.

Lazza commented 3 years ago

The proccess which is used to emit a certificate is certified.

Not so difficult to understand.

aiotech-pub commented 3 years ago

Guys, please, not be offensive without knowing who I am. My name is Massimo Manca, I am a well known consultant also in the field of cybersecurity, payment systems (certified by NXP for R&D using secure microcontrollers, NFC, secure memories and security components in the foeld of payment, ATM and credit cards) so I think to have just alittle more experience, practice and know-how you supposed i may have. If you have not used any fake QR code to test this app you can not be defined "professional", you have no idea about how serious has to be the testing procedure of a sw application and at this point I can understand why so many people contacted me saying that they are not able to use the app just using some of the QR they have (their personal QR and that of some relatives, friends and so on). Guys, have you any idea that if they will document that the app sometimes works and sometimes no (and this will affect their income) how many claims for damages will opened on the courts in few days?

Lazza commented 3 years ago

I am a well known consultant also in the field of cybersecurity, payment systems

Do you mean the Professor of Latin Literature at Ca' Foscari University of Venice, or the one who has got a website accessible in plain HTTP?

Nevertheless:

If you have not used any fake QR code to test this app you can not be defined "professional"

Feel free to test as many QR codes as you wish. The codes are digitally signed by the Ministry of Health and the specification is freely available, also documented on various websites (example).

The production version of VerificaC19 uses the official certificates to verify the signature, but for testing purposes you might as well build your own version using testing/development keys.

you have no idea about how serious has to be the testing procedure of a sw application

LOL this thread has seen participation by several software developer, but whatever.

If you think you have found a way to break the standard cryptographic routines that are used by the app, or proved that P=NP, you should go and claim your well-deserved prize.

Enrico204 commented 3 years ago

Enrico204: first of all the valid text of MDD 93/42 is in English

Can you please share a link with the original text, as I did?

so the word is "monitor" that does not means - exactly - "controllo" the nearest translation is "tenere sotto controllo" meaning a form of control during a period of time. So this is an app to monitor the state of disease, because the QR comes from (also) a result of a diagnostic test (green pass) and certifies if a person is negative or not to the test, the test is a system to say if a person is or not infected by covid so because the app reports the result of a test it is part of a monitor system. For this reason IT IS a medical application that has to be certified. Not so difficult to understand.

No, the app NOT is meant for monitor the disease, and you said so:

because the QR comes from (also) a result of a diagnostic test

That is the point. The green pass MAY come from a diagnostic test. However, this app won't differentiate between green pass done with tests or green pass done for whatever other reason. And, most important, the app won't check the "health-related" data of the test. In fact, this app checks only the QR code signature. Which may come for whatever reason the certificate emitter think is possible.

The MDD 93/42 covers medical devices. This is a signature checking app. This app won't emit certificates.

Guys, please, not be offensive without knowing who I am. My name is Massimo Manca, I am a well known consultant also in the field of cybersecurity, payment systems (certified by NXP for R&D using secure microcontrollers, NFC, secure memories and security components in the foeld of payment, ATM and credit cards) so I think to have just alittle more experience, practice and know-how you supposed i may have.

I'll just skip commenting this part.

If you have not used any fake QR code to test this app you can not be defined "professional", you have no idea about how serious has to be the testing procedure of a sw application

Why you think that we didn't do any test?

Also: have you read the documentation? The underlying technologies are very battle-tested and standards. Literally the whole internet works thanks to those technologies.

and at this point I can understand why so many people contacted me saying that they are not able to use the app just using some of the QR they have (their personal QR and that of some relatives, friends and so on). Guys, have you any idea that if they will document that the app sometimes works and sometimes no (and this will affect their income) how many claims for damages will opened on the courts in few days?

If you have any reproducible case of issue reading the QR code, you can open an issue. This issue is relative to the data verification "problem" (which is not a problem at all)

aiotech-pub commented 3 years ago

because it may come from a diagnostic test it is mandatory to follow the MD 93/42 and the app needs to be certified. That's all, may is sufficient.

aiotech-pub commented 3 years ago

This is an original copy, go to page 5 and 6: https://da4284glbbt4.cloudfront.net/Directives/MDD%20Directive%2093_42.pdf

aiotech-pub commented 3 years ago

User testing is an essential part of testing. If you don't test the app against what it is supposed to test you are not a professional, you are just playing. I am used to develop SW and HW on critical medical devices and other fields where errors and bugs as well are not accepted. I/we are used to develop assuring "zero errors against requirements", I understand this app is very far from this situation if nobody test the app against a set of different QR codes (also if they are fakes) simply because you can not demonstrate to had tested afgainst them that is very very very stupid.

Lazza commented 3 years ago

If you don't test the app against what it is supposed to test you are not a professional, you are just playing. I am used to develop SW and HW on critical medical devices and other fields where errors and bugs as well are not accepted

https://www.youtube.com/watch?v=RIiS3gn4x9Y

Enrico204 commented 3 years ago

because it may come from a diagnostic test it is mandatory to follow the MD 93/42 and the app needs to be certified. That's all, may is sufficient.

No. The certificate is coming from the diagnostic test, not the app result. The app verifies of validity of the green pass document, not the validity of the test.

From the document you linked:

diagnosis, prevention, monitoring, treatment or alleviation of disease,

This app won't do a diagnostic test, won't prevent, won't treat and won't alleviate the disease.

The app checks only the signature of the green pass. The app don't check that the green pass data are "correct" from a clinical point of view. The app checks only that the signature of the document is valid.

User testing is an essential part of testing. If you don't test the app against what it is supposed to test you are not a professional, you are just playing.

Again, why you say that? Do you have any proof that the authors of this app didn't test the app with any user? If so, please post them here.

I am used to develop SW and HW on critical medical devices and other fields where errors and bugs as well are not accepted. I/we are used to develop assuring "zero errors against requirements"

This is not a medical device.

I understand this app is very far from this situation if nobody test the app against a set of different QR codes (also if they are fakes) simply because you can not demonstrate to had tested afgainst them that is very very very stupid.

You're accusing someone that they didn't test the app. However these are false claims, because authors send you a reply with details about app testing material that they use for testing: #94 . So, testing is part of the development process.

Also, another user replied to you with details about testing material from official authorities here: https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/88#issuecomment-894341258

enricomiletto commented 3 years ago

@Enrico204

this app won't differentiate between green pass done with tests or green pass done for whatever other reason

In fact, this app checks only the QR code signature

Please correct me if I'm wrong, but the app does differentiate between Vaccination, Recovery and Test certificates as this is reqired to check whether the DCC is still valid from a temporal stand point. This "date of expiry" is not present in the json data (AFAIK) but has to be be inferred from the type of certificate. If the app only checked the signature every DCC ever issued by trusted party would always be marked as valid

Enrico204 commented 3 years ago

@Enrico204

this app won't differentiate between green pass done with tests or green pass done for whatever other reason

In fact, this app checks only the QR code signature

Please correct me if I'm wrong, but the app does differentiate between Vaccination, Recovery and Test certificates as this is reqired to check whether the DCC is still valid from a temporal stand point. This "date of expiry" is not present in the json data but has to be be inferred from the type of certificate. If the app only checked the signature every DCC ever issued by trusted party would always be marked as valid

Correct. However this is only for the expiration. What I meant is that the outcome "OK/KO" is not based on a health-related information, and the app doesn't validate the type of certificate from a clinical point of view. So the app is not a medical device.

aiotech-pub commented 3 years ago

@Enrico204

this app won't differentiate between green pass done with tests or green pass done for whatever other reason

In fact, this app checks only the QR code signature

Please correct me if I'm wrong, but the app does differentiate between Vaccination, Recovery and Test certificates as this is reqired to check whether the DCC is still valid from a temporal stand point. This "date of expiry" is not present in the json data but has to be be inferred from the type of certificate. If the app only checked the signature every DCC ever issued by trusted party would always be marked as valid

Correct. However this is only for the expiration. What I meant is that the outcome "OK/KO" is not based on a health-related information, this is wrong and the app doesn't validate the type of certificate from a clinical point of view. So the app is not a medical device. and also this is wrong

Lazza commented 3 years ago

Pro-tip: facts are not true or false based on what you like to write on Github.

There is no "ipse dixit" approach in software development, especially when "ipse" is a user who appeared out the blue demonstrating they did not study the functioning of the app nor the threat model.

libo commented 3 years ago

This "date of expiry" is not present in the json data (AFAIK) but has to be be inferred from the type of certificate.

By reading the DGC SPEC 1.0.5 and the JSON Schema Specification you can see there are two expires:

the first is the CWT (CBOR Web Token), claim key 4. This basically defines the Expiration time of the QR code itself (as defined in rfc8392
the second is in the payload itself and as you said can be inferred. More in details:

t/sc "Date and time of the test sample collection". For tests
r/df "Certificate valid from" for people who recovered from Covid.
r/du "Certificate valid until" for people who recovered from Covid.
v/dt "Date of vaccination" for vaccinated.

I might be wrong and I let @Lazza or @Enrico204 chime in on the correctness of my assertions, it looks like they have been working on these specs for a while.

I just started looking into this and to be honest I am amazed that the EU, the same authors of the Cookies Consent Banner, this time used some battle tested de-facto standard technologies instead of training all of us to click "Accept" buttons without reading what we are doing like Pavlov's dogs :-) Just kidding!

aiotech-pub commented 3 years ago

There are many flaws in data and time management in this app. May be interesting for a user to move the system data behind or beyond the real depending what he needs to do, just checking the certificate emission date (certificate valid from) the problem may be reduced but not solved, so it is essential to guarantee that the user can not move the system date. The problem born because this app is a fork of the EU app that as written in the specifications will be used by sanitary and airport/port security personel, instead in Italy it will be used by private persons.

libo commented 3 years ago

@aiotech-pub I have mixed feelings about your point of view.

First of all, I wonder if a medical-grade ultrasound scanner that I believe should honor MDD 93/42, does checks for its correct date-time by calling an NTP server and validates its time zone. The last I saw was running Windows 95 (10 years ago), and it had a time drift of some hours. But that's really not the point. That machine function is to check if babies are doing fine and not to validate a certificate :-)

I am not a legal expert, and I let legal offices do their work. However, I believe that private citizens should have the same moral obligations as "sanitary and airport/port security personnel". But I see what you mean. For example, one could be in charge of checking people getting into a party, see someone in the queue that doesn't want in, and by temporarily putting the date a year in the future will make this app report the pass as invalid. Is that a crime? Probably. Are we intentionally excluding people using this technology? Sure we are.

From an engineering point of view, this is not a bug. The first requisite to verify if something is expired is to have a correct date-time set in the device checking that.

This is where the UI conversation comes in. Try to put your laptop three years into the future and browse the internet. If you can reach your browser because I have experienced that all the app I was running started to report errors.

This is what Chrome reports. The browser is doing that extra step to tell the user what is wrong.

So while I disagree that this is a flaw of any sort, I believe you have a point, and this is a valid feature request. A feature request that the owner of this repo should consider because, on the one hand, there are a few lines of code, and on the other hand overcoming the unjustified skepticism that already exists in our Country regarding this green pass.

Enrico204 commented 3 years ago

@aiotech-pub

Correct. However this is only for the expiration. What I meant is that the outcome "OK/KO" is not based on a health-related information, this is wrong and the app doesn't validate the type of certificate from a clinical point of view. So the app is not a medical device. and also this is wrong

I repeat, the app doesn't validate the type of certificate from a clinical point of view. This is a fact. To verify this fact, please open the source code of the app and check yourself.

After that, please tell me the part where the app is checking from a clinical point of view the certificate. Please link those lines of code here.

There are many flaws in data and time management in this app. May be interesting for a user to move the system data behind or beyond the real depending what he needs to do, just checking the certificate emission date (certificate valid from) the problem may be reduced but not solved, so it is essential to guarantee that the user can not move the system date. The problem born because this app is a fork of the EU app that as written in the specifications will be used by sanitary and airport/port security personel, instead in Italy it will be used by private persons.

An airport security officer will not use his/her personal smartphone to verify EU green pass. The airport security authority is providing locked and certified devices to all personnel for this kind of verification.

If a local administrator fails to lock and certify a device, then the user can manipulate the device in every possible way. An app can't do anything. This is a basic cybersecurity principle.

Also, an evil verifier (I mean, "an evil person") simply:

won't scan the EU green pass; or
will scan every time a good EU green pass; or
will use a dummy "EU green pass scanner" app

This is in the threat model. There is no way for this app to protect from these actions.

Enrico204 commented 3 years ago

@libo

So while I disagree that this is a flaw of any sort, I believe you have a point, and this is a valid feature request. A feature request that the owner of this repo should consider because, on the one hand, there are a few lines of code, and on the other hand overcoming the unjustified skepticism that already exists in our Country regarding this green pass.

I'm not the maintainer of this repo, so it's not up to me to decide. However, I think that the proposal of checking the local time is not feasible, and it will change a lot of the architecture for a little gain.

Let make an example: if you use the simple-yet-useful solution of checking time via (s)NTP, then you might add these issues in the threat model:

your internal clock depends either from the phone clock (so we gain nothing) or the CPU "steps", which means that the app should handle the clock drift and periodical sync. This poses another challenge: the app, currently, is not 24x7 in background, so it's not capable to keep track of clock drift correctly.
(s)NTP is not authenticated. Currently, there is no a widely used standard for an authenticated NTP protocol replacement
- non-authenticated NTP means that an attacker can change the clock of remote phones remotely, creating a denial-of-service (if we're lucky) or even accepting/rejecting EU green pass based on wrong information (possibly creating life threatening situation) - this issue is worse than having the user changing the local time - so it's a no-go
the NTP server list should be ultimately trusted and reliable (not a big concern, however this should be considered)
what clock do you use for the TLS (HTTPS) connection to the key material repository? If you use the internal clock, you need to import and implement a lot of TLS subroutines. This is a very risky action, it might open the door of TLS interception and blacklist manipulation. Or you can use the system clock for TLS, so no gain from this change

Let's say that you use GNSS (satellite location):

actually, very few phone can receive and correctly verify Galileo signed data. Other constellations signal are spoofable (GPS for sure, GLONASS I'm not sure of that)
the smartphone should be able to receive the GNSS signal. So the phone should be near a window or in external spaces. This is not true for a lot of places (e.g. big supermarkets)
the app will receive the user location. This is a new permission that the user should grant explicitly.
- even if the app will say "your location won't be used", how can you possibly trust the app? If the location is not needed, why ask for location in the first place? This will create distrust, for a little gain.
same issues for TLS from above

As you can see, there are a number of problems choosing this approach. And basically all approaches won't block an evil verifier that modifies the app, or install another app, or simply skip the whole green pass check.

Currently, the app is showing the date and time of the scan (meaning, the current date/time). For a non-evil verifier using a "manipulated" phone is ok (he/she is supposed to verify the person ID data)

libo commented 3 years ago

@Enrico204 thank you for your feedback

As I understand, the app periodically (every 24 hours?) calls back the backend to fetch the updated list of public keys and the business rules that determine if the pass is valid, like rapid_test_end_hours (you can see all the parameters at this URL: https://get.dgc.gov.it/v1/dgc/settings And you can find here the BASE_URL )

Here is the code I am referring to: https://github.com/ministero-salute/it-dgc-verificaC19-android/blob/develop/app/src/main/java/it/ministerodellasalute/verificaC19/data/remote/ApiService.kt#L32-L41

Here the documentation: https://github.com/ehn-dcc-development/hcert-spec/blob/main/hcert_spec.md#appendix-a---trust-management

If we store a hypothetic last_updated_at on the device every time we fetch these pieces of information and then compare that timestamp with the device time when we scan, we could display a warning prompting to fix the device date and time (similar to what Chrome does) when the difference is greater than 24 hours. We could get the last_updated_at from the HTTP Date response header that the backend is returning us. (I checked it's Cache-Control: private).

Furthermore we could also check the the HTTP Date response header and the device time do not differ by more than X minutes.

I know it's not perfect, and there are edge cases, but at least it is helping the user to repair a misconfigured device while assuming good intention.

Lazza commented 3 years ago

we could display a warning prompting to fix the device date and time (similar to what Chrome does)

Wait, are you assuming that a malicious actor that wants to alter GP checks will kindly obey to a friendly warning?

libo commented 3 years ago

Hi @Lazza The scenario I envision is where the victim showing a valid pass gets intentionally excluded from a venue by someone that pushes the date of the device a year into the future.

If the person checking these green passes (let's call them the concierge) doesn't allow someone in, the evil concierge must show that the pass is not valid. If the app instead reports a date-time warning, I think that is valid feedback for the victim too.

At this point the victim can kindly ask the concierge to fix the date of the phone or call the police.

I also envision a genuinely misconfigured device as I said by assuming good intentions.

Lazza commented 3 years ago

the victim showing a valid pass gets intentionally excluded from a venue by someone that pushes the date of the device a year into the future

Or the bad guy could just use a custom fork of the app that shows "OK" or "invalid" depending on an arbitrary choice, a parameter, the press of a button or whatever.

libo commented 3 years ago

@lazza sure. You are totally right.

What seriously worries me is that as of today, a concierge of a venue can discriminate and exclude people. What is needed is two phones both running the official app from Ministero della Salute. One with a system date a year in the future. One in each pocket.

A year in the future is enough to invalidate all QR-codes out there by claim key 4 as defined in rfc8392, I mean the epoch timestamp in this example:

The phone with the date in the future will report that the green-pass is not valid and the guest will not be admitted.

I agree this kind of discrimination is a crime no matter what, but I believe we could send a better message to the green-pass skeptics by implementing a check that the device can actually validate those QR codes and some sort of ~~authentication and authorisation between the app and backend so to stop any proliferation of hacked apps.~~

EDIT: authentication and authorisation do not solve the scenario of a custom fork of the app that shows "OK" or "invalid" depending on button or whatever as @lazza pointed out. The problem is the authenticity of the scanning app. A possible solution is a secret shared between the scanning app and the app that shows the QR-code. For example a double QR-code exchange would do it. The problem is that we are supporting printed PDF. So this is what we get.

EDIT 2: I am honestly having a hard time finding a solution to guarantee the authenticity of the scanning app and rule out the problem where a concierge has one that looks identical to the official but gives green or red depending on whether the volume up or down button is pressed during the scan. It is a counterfeiting problem similar to a fake but perfectly reproduced ATM that holds my card just after I have punched in my pin. Living in a society means that we must trust each other and at the same time be aware of the risks.

My 2 cents. Have a great weekend!

Enrico204 commented 3 years ago

Hi @Lazza The scenario I envision is where the victim showing a valid pass gets intentionally excluded from a venue by someone that pushes the date of the device a year into the future.

If the person checking these green passes (let's call them the concierge) doesn't allow someone in, the evil concierge must show that the pass is not valid. If the app instead reports a date-time warning, I think that is valid feedback for the victim too.

At this point the victim can kindly ask the concierge to fix the date of the phone or call the police.

I also envision a genuinely misconfigured device as I said by assuming good intentions.

Actually, the app is already showing the current date and time (the date and time when the scan happened), and the last update in the main view (iirc at the bottom of the view). So it's pretty easy to check those values (both for the verifier and the user) in case of issues.

Anyway, I think that your suggestion is good and can be implemented without issues. However I still think that an evil verifier will not use the original app (or an evil "owner of device", in case the person that checks GP is not aware of the device tampering).

What seriously worries me is that as of today, a concierge of a venue can discriminate and exclude people. What is needed is two phones both running the official app from Ministero della Salute. One with a system date a year in the future. One in each pocket.

Actually, as @Lazza said, the "simpler" solution for an evil verifier is to ask his/her cousin (i.e. the one that is "good with computers", "an hacker, whatever this means") to create a fork with custom actions and answers.

Furthermore we could also check the the HTTP Date response header and the device time do not differ by more than X minutes.

I think that this check is not needed, because:

if the time difference is minimal (few seconds, few minutes < 5/10m), chances are that no one will try to use the green pass
- for example, the swab is valid for 48h, I doubt that one will try to use the green pass 47h 50m after the swab result, mostly because of queues, traffic to reach the destination, etc
if the time difference is high (more than 5 or 10 minutes), then TLS will break, and the update will not occur

So it can be done, however I don't see any real advantage in this check. Setting last_updated_at when the last update occurred seems to be enough in all cases (correct me if I missed something).

Thanks everyone for your ideas!

libo commented 3 years ago

@Enrico204 I haven't noticed before but I can confirm that the app actually reports the scanning date. That is very good! 🎉

Thanks!

p.s. the time validation I am talking about is not the "after the swab result" but the one defined on claim key 4 that defines the duration of the QR code itself and is part of the security envelope based on the COSE protocol that wraps the CWT (CBOR Web Token). See my screenshoot above.

libo commented 3 years ago

For what it is worth, I vote in favor of closing this issue.

This conversation already happened ~2500 years ago with Plato and later Giovenale _"Quis custodiet ipsos custodes?”_

NiccoloSegato commented 3 years ago

Thank you all for the comments, explanations and implementation ideas that have emerged 🙏🏼 I think I can close this report as it has provided many ideas to the developers and the community as a whole, creating an educational open discussion.

vincenzoiovino commented 3 years ago

Hi, this is effectively a bug. I and other researchers had independently discussed about that. In my opinion, the issue is not that someone at a bar or conference can manually set the incorrect data to exclude someone: it is always possible to do that using a different app that looks identical, we cannot require people to verify the verifiers! The issue is in time machine attacks that I and other researchers already used to successfully "attack" Immuni, see the following video with samples of the different practical possibilities in which it is possible to REMOTELY alter the phone date/time: https://vimeo.com/476901083 the research was published at CT-RSA 2021, see this paper. https://eprint.iacr.org/2020/1393 (therein you can also find the references to the issues in the github of Immuni and other contact tracing apps) and presented at the Chaos Communication Congress 2020. The same attacks apply to this dgc verification apps as well, not just the Italian one. This does not imply that each phone is under attack under any circumstance. Some phone can be attacked in some circumstances and using some technology (just NTP spoofing, with base stations, etc.), but this subset is not small and since milions of people will use these apps the threat is significant. In the end, these are very known attacks, see the references cited in our paper.

Disclaimer: This thread was very long, I did not read it all so I apologize if somebody already discussed this earlier.

Kind regards

Enrico204 commented 3 years ago

@vincenzoiovino

Disclaimer: This thread was very long, I did not read it all so I apologize if somebody already discussed this earlier.

I suggest you to read the whole issue before writing anything else. These problem that you are rising have been already discussed.

TL;DR the (original) verifier app shows the current time and date, so:

if there is a rejection for a valid green pass, the "rejected user" can ask to see the screen of the phone with the rejection response. If the date and time are not correct, the user will see that and will take appropriate actions (call the police?)
if there is an approval for a green pass, the verifier can check whether the date and time (displayed in the app) are correct, along with the person ID card. If something is wrong, his/her device was tampered with (either locally or remotely)

So, when using the "original" app, this issue has been already mitigated.

If you consider the possibility of a fake app or evil verifier, there is nothing that anyone can do currently, of course (as the green pass check might not occur at all).

Also: some solutions has been discussed above: https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/88#issuecomment-894658936 and https://github.com/ministero-salute/it-dgc-verificaC19-android/issues/88#issuecomment-894679429 . Also (2): this app is meant to be used by non-critical sector operators. Airport security, military, etc, they should already have proper hardened smartphones (or devices, in general).

Enrico204 commented 3 years ago

Addendum: some phones don't use NTP at all if the mobile provider supports NITZ. Some others sync with GNSS. To be viable, this attack requires that:

the subject of verification (aka the person with the green pass) is aware of this, otherwise he/she can object that the date and time of the verifier app are not correct when rejected
the verifier "person" should NOT check his/her phone screen for the correct date and time label that is in the same app view of the check result
the attacker should be in control for all of:
- NTP via Wi-Fi (so: rogue Wi-Fi / MITM in Wi-Fi, or Wi-Fi jammer)
- NTP via mobile network (so: rogue illegal base station or illegal jammer)
- NITZ (so: rogue illegal base station or illegal jammer)
- GNSS (so: rogue illegal GNSS transmitter or jammer)
the verifier smartphone should have at least one of these technologies active during the "hack": NTP, mobile network, GNSS
the verifier smartphone needs to sync its clock (it can be forced only by the verifier himself/herself)
the verifier should not open any other app that uses internet (e.g. Facebook/Instagram/Whatsapp, for instance), as these app detects that something is wrong in SSL/TLS certificate verification (which uses the current time and date)
other "good" green pass must be checked OK, so the manipulated time and date should be in a range that is acceptable (otherwise a person in the GP check queue might be falsely rejected and the tampering will be discovered shortly)

I think that these are good assumption for a theoretical attack, but a "real-world" attack won't be viable, due to hardware costs, risks (think about GNSS and illegal BTS transmitters) and limits[1]. We're still considering a green pass check, are we?

[1] You will need to have multiple antennas (2.4/5 GHz Wi-Fi, and a very long list of frequencies for mobile networks and GNSS) and wireless beams directly pointed to the verifier smartphone, this is not something that you can hide for a long period of time, and they will be difficult to move along with you. In case of Wi-Fi, you need also to discover the current Wi-Fi password and be able to overcome the signal from the current AP, or jamming the signal directly. The same for the operator mobile network. GNSS is the easier option, as GPS is not authenticated; however you should hope that the target smartphone doesn't support Galileo as it's authenticated.

vincenzoiovino commented 3 years ago

@vincenzoiovino

Disclaimer: This thread was very long, I did not read it all so I apologize if somebody already discussed this earlier.

I suggest you to read the whole issue before writing anything else. These problem that you are rising have been already discussed.

TL;DR the (original) verifier app shows the current time and date, so:

if there is a rejection for a valid green pass, the "rejected user" can ask to see the screen of the phone with the rejection response. If the date and time are not correct, the user will see that and will take appropriate actions (call the police?)

if there is an approval for a green pass, the verifier can check whether the date and time (displayed in the app) are correct, along with the person ID card. If something is wrong, his/her device was tampered with (either locally or remotely)

So, when using the "original" app, this issue has been already mitigated.

If you consider the possibility of a fake app or evil verifier, there is nothing that anyone can do currently, of course (as the green pass check might not occur at all).

Also: some solutions has been discussed above: #88 (comment) and #88 (comment) . Also (2): this app is meant to be used by non-critical sector operators. Airport security, military, etc, they should already have proper hardened smartphones (or devices, in general).

Ok. I see you already discussed this. But it is worthy to point out the above reference for me since they regard the same class of attacks to another project of National interest so it is more surprising to see that this attack again affects another project and you did not take in account previous known literature and issues.

I had seen the update of 9th of August. Imho (and not only mine) this only worsen the situation. The attack is still applicable but the purpose of the attacker will be different. After the new update an attacker can do the following. The attacker is not interested in passing without a valid pass. The attacker can for instance remotely manipulate the verifier's time inducing the verifier to suspect that the verifier close to him/her is suspicious, or just make the.verifier understand that there is an ongoing attack so that the verifier will need to verify all passes more slowly and eventually call the police. In a stadium or for a big event this is a big issue, just doing the attack once will cause panic in the verifier(s) and the queue will proceed much more slowly. The situation is worse because in this case the attack is.statistical: the attacker can try many times until it succeeds.

vincenzoiovino commented 3 years ago

Addendum: some phones don't use NTP at all if the mobile provider supports NITZ. Some others sync with GNSS. To be viable, this attack requires that:

the subject of verification (aka the person with the green pass) is aware of this, otherwise he/she can object that the date and time of the verifier app are not correct when rejected

the verifier "person" should NOT check his/her phone screen for the correct date and time label that is in the same app view of the check result

the attacker should be in control for all of:

NTP via Wi-Fi (so: rogue Wi-Fi / MITM in Wi-Fi, or Wi-Fi jammer)

NTP via mobile network (so: rogue illegal base station or illegal jammer)

NITZ (so: rogue illegal base station or illegal jammer)

GNSS (so: rogue illegal GNSS transmitter or jammer)

the verifier smartphone should have at least one of these technologies active during the "hack": NTP, mobile network, GNSS

the verifier smartphone needs to sync its clock (it can be forced only by the verifier himself/herself)

the verifier should not open any other app that uses internet (e.g. Facebook/Instagram/Whatsapp, for instance), as these app detects that something is wrong in SSL/TLS certificate verification (which uses the current time and date)

other "good" green pass must be checked OK, so the manipulated time and date should be in a range that is acceptable (otherwise a person in the GP check queue might be falsely rejected and the tampering will be discovered shortly)

I think that these are good assumption for a theoretical attack, but a "real-world" attack won't be viable, due to hardware costs, risks (think about GNSS and illegal BTS transmitters) and limits[1]. We're still considering a green pass check, are we?

[1] You will need to have multiple antennas (2.4/5 GHz Wi-Fi, and a very long list of frequencies for mobile networks and GNSS) and wireless beams directly pointed to the verifier smartphone, this is not something that you can hide for a long period of time, and they will be difficult to move along with you. In case of Wi-Fi, you need also to discover the current Wi-Fi password and be able to overcome the signal from the current AP, or jamming the signal directly. The same for the operator mobile network. GNSS is the easier option, as GPS is not authenticated; however you should hope that the target smartphone doesn't support Galileo as it's authenticated.

We showed at CCC 2021 how this attack is practical on many phones and in which situations it is practical.

The attack is NOT practical in many situations and against many devices.
The atrack is practical against many devices.and in sever situation.

You just point out 1) and I do agree. I also point out 2).

Moreover, as explained in the previous comment, after the new update there is a new class of attack for which the situation is worse: in fact the attacker will not be interested in manipulating the time in relation to a specific dgc but will be interested in a statistical attack. Over thousands people if the attacker can succeed just once, this will cause alarm and panic with many social (and also epidemiologic) consequences.

ministero-salute / it-dgc-verificaC19-android