However, this only works once for each time the OnlyKey is connected/plugged in, and there doesn’t appear to be a way to view the current FIDO2 signCount or force an update to sync it with the current time. On the latter, I think this is due to this check for “if (timeStatus() == timeNotSet)” (assuming OnlyKey is using this Arduino Time Library, after initially setting the time it will presumably no longer be timeNotSet, though it may eventually end up being timeNeedsSync rather than timeSet).
So while it would be nice to view/update the FIDO2 signCount in the OnlyKey App/CLI, perhaps an easier solution would be to remove this check on timeStatus and have the OnlyKey update the time (and hence the FIDO2 signCount) every time it receives the OKSETTIME message?
As then we could force the update using either the OnlyKey CLI (via the settime command) or by closing and reopening the OnlyKey App, without needing to disconnect and reconnect (unplug/replug) the OnlyKey.
This feature request could also potentially help as a workaround for the time drift issue mentioned here:
If OnlyKey always updated the time on receiving the OKSETTIME message, the time could be periodically synced using the OnlyKey CLI (via the settime command).
PS: I would like to take this opportunity to say thank you again for producing OnlyKey and making it open source - it’s the main reason I bought it (in fact multiple OnlyKeys and OnlyKey DUOs) over alternatives such as YubiKey, as I could then look into the code like in the above.
Hey thanks for the detailed writeup here. Yes, OnlyKey only sets the time once when it receives the first timeset command. Then after that the internal OnlyKey clock stores and tracks the time until the OnlyKey restarts. There were issues with having the OnlyKey process each timeset command instead of just the first, and potentially issues with allowing an external application to set the time to an incorrect time. For security reasons, OnlyKey doesn’t read any USB messages until its unlocked so it has to have another timer that counts the time between since the device was powered on and when a correct PIN is entered (at this point it will start reading the USB messages received in the buffer which contains settime, and add that time to the counter which will equal the current time).
The OnlyKey processor is fairly good at keeping time, but its not an RTC so if say OnlyKey is plugged in for 30 days there is a chance it could be a little bit off over time. Is this what you are seeing here with the issue on github? That there is time drift if the device is plugged in for a long time?
The time drift issue was one I came across on that GitHub issue when looking into how OnlyKey keeps track of the current time in the context of using this time for to update the FIDO2 signCount each time the OnlyKey is connected when the OnlyKey App is open(ed). I haven’t noticed this myself as I don’t tend to have any of my OnlyKeys connected for more than a few minutes or so at a time. I mentioned it more in case the solution of having OnlyKey always respond to the settime command was feasible, as it could be a workaround for that issue and the one I’m seeing with the FIDO2 signCount.
For my particular use case, I want to ensure that the FIDO2 signCount doesn’t fall behind the current time, as I have duplicate keys in different locations/form factors as backups. I appreciate this isn’t the typically recommended way of doing backups, which is to have different keys and register all of them for each website/service, but I’m doing this for a combination of convenience of not having to register each different/backup key on every website/service and because for some of the websites/services I use it on they only allow registration of a single security key.
The issue occurs in this use case when I use one security key which has had its FIDO2 signCount updated to the current time, then another key which hasn’t and therefore has a signCount behind the first one - the website/service detects this and (correctly) identifies that the key may have been compromised by cloning (as I have indeed cloned/duplicated it, by design). An example of a service which does this check is Proton.
So for this use case, if I’m understanding your post correctly, another solution would be to change the OnlyKey firmware code to update the FIDO2 signCount on each update of the internal OnlyKey clock?