-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clock skew should be taken into account when generating proof #1
Comments
This is pretty abstract. What operating system and device are you using, and what does the time synchronization script at https://time.is/ report? For example: "Your clock is 1 minute and 13.9 seconds ahead.". |
I'm using an Android device. At the time.of testing my device was set to automatic time, and was 50 seconds behind. At the current settings that means that there's about a window of 10 seconds for a correct code to scan as such. Just to say that this is a very real issue. This is similar to issues seen with for example OTP apps. Basically all of those apps use some kind of clock sync to make sure the nonce / time used is the one needed for correct code generation. |
What exact operating system (i.e. a ROM or stock Android) and device (vendor, model) are you using? Also, which telephony provider? |
This sample was on a Nokia 8.1, running the stock rom (Android 11) on KPN network. |
Describe the bug, issue or concern
In https://github.com/minvws/nl-covid19-coronacheck-idemix/blob/main/holder/disclosure.go#L13 "now" is used for the current time. However on a mobile device it's very much possible that the device time is incorrect and when presenting a proof with an incorrect time the proof might not verify on the scanner app.
The mobile apps acknowledge this (at least for Android) by showing a warning that the device time has drifted too far, by comparing with the server timestamp and shows the user a warning. Unfortunately this isn't very actionable for a user; the time might be set to "automatic sync" and still be skewed.
A better solution would be to allow specifying the actual observed clock skew or time and pass this into the linked method above. This way the generated proof will always have the correct time. Assuming that the scanner is also synced by ntp or some other method this should yield in a more reliable way to represent the intended, current time.
Governance
The text was updated successfully, but these errors were encountered: