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

[Tho-Mat]

Describe the bug

According to:
corona-warn-app/cwa-server#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

[daimpi]

Somewhat related: corona-warn-app/cwa-wishlist#88

If this issue is affecting both iOS and Android it should probably be moved to the documentation repo.

[Marco2907]

Hi @Tho-Mat, thank s for sharing your content. We will keep and discuss this point with our development team and will come back to you as soon as possible.

Thank you.

Best,
MP

---

Corona-Warn-App Open Source Team

[Marco2907]

Hello @Tho-Mat Hello @daimpi , if both of you agree I would close this issue here because this topic is similar to corona-warn-app/cwa-wishlist#88 . Based on corona-warn-app/cwa-wishlist#88 the community discuss this with our development team and I will come back to you as soon as possible.

Thank you.

Best,
MP

Corona-Warn-App Open Source Team

[Tho-Mat]

@Marco2907
I do not agree.
If time is not correct the app is useless.
So it's not a wish, its the same as if BT is off.
So this should result in: Risikoermittlung nicht aktiv

[daimpi]

I also don't think closing this issue is right…
corona-warn-app/cwa-wishlist#88 is about a quite different issue, which is only related in so far as that both issues concern the time-setting in your phone…

If anything I think this issue here should probably be moved to the documentation repo, as it affects both iOS and Android.

[Marco2907]

Hi @daimpi , sorry for the late response and misunderstanding, I will keep this issue to discuss with our development team. I will come back to you as soon as possible.

Thanks,
MP

Corona-Warn-App Open Source Team

---

Internal Tracking ID: EXPOSUREAPP-2591

[Tho-Mat]

This may be the next wrong time issue
corona-warn-app/cwa-server#764 (comment)

[Tho-Mat]

At the moment 2 of 4100 users that submit their keys seem to use the wrong time.
If i assume the same rate for the 18.000.000 users that download the app, we get round about 8800 users,
that do not know, the app is useless for them.

[Tho-Mat]

And again corona-warn-app/cwa-server#764 (comment)

So, if the assumption of wrong date/time is right, this should be fixed

soon.

[Tho-Mat]

and again...
corona-warn-app/cwa-server#764 (comment)

[Tho-Mat]

@JoachimFritsch
so at the moment we have 5 of 4871 users with wrong time.
That means 1‰ or 18000 of 18.000.000 with useless app

[Tho-Mat]

and another
2020-09-21-hour-09.zip

[mlenkeit]

Hi @Tho-Mat ,

thanks for raising this. We are currently looking into this with CWA Engineering and our partners in order to better understand the impact of this.

As you already suggested, we could interact with an external time server to check whether system time is off by more than e.g. 2 hours. While this sounds simple, integrating external services requires lots of iterations and approvals, depending on their service agreement.

Alternatively, we could share the server time with the client, for example in an HTTP header, but this also comes with the challenge of accuracy on slow network, etc.

My assumption is that in the end, we might only be able to inform users about the side effects of incorrect time settings and the risks associated with this.

We’ll keep you posted as we proceed in the discussions.

Oh, and btw, I think 5 of 4871 is rather 0,1% than 1% 😉

[Tho-Mat]

@mlenkeit

Oh, and btw, I think 5 of 4871 is rather 0,1% than 1% 😉
forgot ‰ sorry :-), corrected.

On the other hand with the missing 6 only those users are counted that have a time far in the future.
(1/2 to one day.)
All users, that have a time in the past also could not be found by this method.
So at least the number has to be doubled.

One easy solution would be to transmit the device time with the key-upload.
That would be an easy method to find wrong time devices.

Theoretically the server then could refuse the data, if device time is incorrect.
Correction of the time is not possible, since you do not know the start-time of the time-difference.
But better take the keys, even they do not work.

What about:
ntp1.t-online.de
"service agreement" should be included?

Time-share sounds nice for the moment.
Accuracy on slow networks is not a problem, since we have a time-period of 2 hours.

Best solution could only be made by Google/Apple, if they save the correct time and not the
device time. Are you in contact with them about this issue?

But at the moment we do not have this, so a solution has to be found with the things we can make ourselves.

[Tho-Mat]

@mlenkeit

some new sets arrived at
2020-09-21-hour-17
2020-09-21-hour-20
2020-09-22-hour-00
so in the last 24h at least 5 of 175 users are assumed to have the wrong time.

That looks to much. Maybe the assumption is not correct.
Since only the sets with keys in the far future could be identified, there could be 10 or more with the wrong time.

[Tho-Mat]

don't understand me wrong.
The time issue has to be solved. But the reason of the missing 6 could be something else.
The first time the missing 6 occurred was the 22.08.2020. But since then nothing important happend on the client side.

With
corona-warn-app/cwa-server#764
the server crew tries to find out more details.
but on the client side we only talk.

What are the plans to solve this?
"To be reviewed" should be changed to "in progress" or "milestone".

[ndegendogo]

A question on this missing key.
Do we know if it was even sent to the server?
Does the App perform some sanity checks or filtering on the keys retrieved from the ENF?
Have you verified that ENF does not suppress this key? And possibly the behavior differs here between Google and Apple implementation of ENF? and/or between the many iOS versions available meanwhile, including the betas?

[Tho-Mat]

@ndegendogo
Good questions.
The first may be answered after 30.09 when the new server version is published.

[Tho-Mat]

again we got the issue on:
2020-09-22-hour-08
2020-09-22-hour-15
2020-09-23-hour-03

Does anybody know when the first IOS14.0 beta was released, that supports cwa?
The massive increase in the issue count may be related to IOS14?

[daimpi]

Does anybody know when the first IOS14.0 beta was released, that supports cwa?

Beta 4 was the first iOS 14 version which supported ENF afaik. I think it was released around the time when I made this post to update the respective FAQ entry (4th August).

[ndegendogo]

The massive increase in the issue count may be related to IOS14?

Or, possibly to Apple's new implementation of the ENF that supports the API version 2.
That would be since iOS 13.7.

[Tho-Mat]

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

[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

[Tho-Mat]

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

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

[thomasaugsten]

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]

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

They use the device time set by The user

[mh-]

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]

Not really solved, but improved with 1.7.0:

#1426

The app will now show a message to the user if the device time is not correct.

[dsarkar]

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

[dsarkar]

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]

Also related: EXPOSUREAPP-3065