Deny of service through time spoofing attacks
From simulated experiments (through manual time/data change + auto time setting resume), my understanding of current app behavior is that it stops with a notification (or error if app in in foreground) because it can not retrieve EBID for the system clock provided time.
If the user does not notice the notification (e.g. telephone in pocket), the app do not resume automatically when clock returns to normal (end of the attack with phone time settings to auto) and the proximity notification service stops until the user manually restarts the app.
This report : http://library.usc.edu.ph/ACM/SIGSAC%202017/spsm/p13.pdf documents actual ways to achieve remote time spoofing attack. My best guess (no way to experiment) is that the NITZ spoofing would be the most efficient, and not too hard to achieve. From tests I have done (not including NITS spoofing), it seems NITZ is the priority one time source for most phones I've been able to try.
In the past, I'm pretty sure I achieved this system clock spoofing through GPS spoofing with very simple hardware (HackRF + https://github.com/osqzss/gps-sdr-sim). This was 1-2 years ago and as far as I can remember I was able to remotely change clocks for some iPhones 5 or 6. I tried again this week (on an iPhone 6 and a few Android devices, but despite being able to spoof position on some device, I was not able to spoof system time except on some Garmin Sport watches which are not relevant to this issue). Tests were conducted into high value Faraday cage... https://photos.app.goo.gl/R5dkeWZNnYVTyrug8.
Still I believe this type of attacks should/could be mitigated by :
-
handling differently a manual (action of the user)/ automatic broadcast stop, and having the app trying to resume broadcast/listening at some time interval if it stopped without user interaction so the effect of the attack is time limited.
-
implement a simple secured time check / request with respect to control server (would work only if network data is available), in order to check system clock vs a secure time provider and try detecting time spoofing attack.
-
in case the system clock fall outside of the available EBID list, keep broadcasting last one and issue a warning instead of stopping broadcast. Initiate dialog with server to try providing new EBID / detecting time spoofing attack instead of stopping broadcast.
A more silent version of the attack would be to shift the phone clocks off by a few epochs (outside of tolerance) so the app takes a wrong EBID (but most probably all phones in the neighborhood would also take the same time). I have not been thinking too much about the effects at protocol level, but that may mess things up.
Screenshot of app errors/notification displayed when app is to unable to retrieve a valid EBID from it's database.