corona-warn-app / cwa-app-ios

Native iOS app using the exposure notification framework from Apple. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
1.68k stars 285 forks source link

App does not work if the device UTC time differ more than 2h from the correct UTC time #1097

Closed Tho-Mat closed 3 years ago

Tho-Mat commented 4 years ago

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

Tho-Mat commented 4 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.

Tho-Mat commented 4 years ago

@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).

Tho-Mat commented 4 years ago

My expectation for the test if the user set device time is used: image

If the correct GPS time or internet time would be used, then the user set time is not relevant. image

Tho-Mat commented 4 years ago

@thomasaugsten Now that you've been testing for 8 days, I'm looking forward to the presentation of the results.

thomasaugsten commented 4 years ago

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

Tho-Mat commented 4 years ago

@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.

Tho-Mat commented 4 years ago

@thomasaugsten And what about the today key? Any news about that? You should also have seen this in your tests.

thomasaugsten commented 4 years ago

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

Tho-Mat commented 4 years ago

@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?

thomasaugsten commented 4 years ago

They use the device time set by The user

mh- commented 4 years ago

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.

Ein-Tim commented 3 years ago

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.

dsarkar commented 3 years ago

Thanks, @Ein-Tim. Related Internal Tracking ID: EXPOSUREAPP-3241

dsarkar commented 3 years ago

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

dsarkar commented 3 years ago

Also related: EXPOSUREAPP-3065