Closed Tho-Mat closed 3 years ago
I know no same day key with risk level 5 is submitted by the users. But that may depend on the app implementation. The keys the app receives from the ENF could contain a key for today that gets the 6 by the app.
@thomasaugsten on 2020-09-27 (hour-files 03-22) at least 41 users report a sameDay key 2020-09-27 with risk level 6. Those keys were publish at 2020-09-28-hour-03. That is round about 40% of the reporting users. on 2020-09-28 (hour-files 03-20) at least 70 users report a key for 2020-09-28 with risk level 6. Those keys were publish at 2020-09-29-hour-03. That is round about 47% of the reporting users. If I look on the market share this could could indicate to android.
(Just saw you forget a device with a time in the future, but I think it will not be needed if all devices act as infected).
My expectation for the test if the user set device time is used:
If the correct GPS time or internet time would be used, then the user set time is not relevant.
@thomasaugsten Now that you've been testing for 8 days, I'm looking forward to the presentation of the results.
Hi I have first results here and it looks like Google and Apple following this +-2h window. I will create tickets to help the users with an incorrect time
@thomasaugsten
Hi I have first results here and it looks like Google and Apple following this +-2h window. I will create tickets to help the users with an incorrect time
What do you mean about tickets? Will a user be informed by the App?
It is not enough to just add a new entry to the FAQ. Nobody with incorrect time will read it. Since he does not see an error and does not know the app is useless for him.
@thomasaugsten And what about the today key? Any news about that? You should also have seen this in your tests.
Ticket mean we created a backlog item to create a design to warn people with incorrect time and please them to correct the time. Yes we see the sameDay TEK but Google is still searching why this is activated for Germany
@thomasaugsten I would like to remind you in my open questions: Do both, iOS and Android use the user-set device time? (Should be answered by your tests) If not, did you ask apple and google to change this?
They use the device time set by The user
While IMHO the published code can’t be the production code, I think this shows what Google is doing with the 2 hour window: https://github.com/google/exposure-notifications-internals/blob/e953a09dd3c20c04dfa29e362eef461890dac25c/exposurenotification/src/main/java/com/google/samples/exposurenotification/matching/ExposureMatchingTracer.java#L648 Note that this is done after matching.
The expensive operation is AES, not the 16 byte comparison.
Not really solved, but improved with 1.7.0:
https://github.com/corona-warn-app/cwa-app-ios/pull/1426
The app will now show a message to the user if the device time is not correct.
Thanks, @Ein-Tim. Related Internal Tracking ID: EXPOSUREAPP-3241
HI @Tho-Mat
This has been fixed already in release 1.11. Related internal ticket EXPOSUREAPP-2998.I suggest closing this issue. Best wishes, DS
Corona-Warn-App Open Source Team
Also related: EXPOSUREAPP-3065
Describe the bug
According to: https://github.com/corona-warn-app/cwa-server/issues/723 @michael-burwig reports: "We do not check whether an end device has its time set correctly."
As far as I understand: The correct UTC-time of a device is very important. If the times of two meeting devices defer more than 2h, i.e. |t1-t2|>2h then no key-match will be found, if one of them reports his/her/its infection. Moreover: if the device of the infected user with an UTC-time & date ti that defers more 2h from the correct UTC-time tu, i.e. |ti-tu|>2h, then all of the transmitted keys are invalid / useless for others. On the other hand, if the device time of an CWA user is wrong, he will receive the keys but no match will be found, also. Note: Even the device shows the correct time and date the UTC-time may be wrong.
I assume IOS and Android devices are effected?
Expected behaviour
The user-set device time should not be important for value matching. I could not find any information about that.
Possible Workaround
As long as the OS uses the (user-set) device time and not the correct time (from internet, GPS or mobile network) to store the received BT-keys and their own active day-keys, the CWA app should check if the device time is set correct. The user should be informed that he has to set his device-time to the correct value to ensure the app will work. This could be done by calling an external time server or a one to be implemented on the CWA server.
Additional context
https://blog.google/documents/69/Exposure_Notification_-_Cryptography_Specification_v1.2.1.pdf page 9 https://app.slack.com/client/T019BKJF80K/C0194ML0MLN/thread/C0194ML0MLN-1598688186.242400 Thanks to Michael Huebler and Paul-Olivier Dehaye
Internal Tracking ID: EXPOSUREAPP-2591