4 ms·

That's an excellent point. But IIUC it can be solved with a local clock of sufficient accuracy by making sure you got the message for the right time, at the rig

That's an excellent point. But IIUC it can be solved with a local clock of sufficient accuracy by making sure you got the message for the right time, at the right moment. This is now even feasible for handheld equipment, as "chip scale" atomic clocks are now commercially available, with dimensions on the order of a few cm on each side. This one is based on Rubidium: https://www.microsemi.com/product-directory/embedded-clocks-frequency-references/5207-space-csac https://www.microsemi.com/product-directory/embedded-clocks-..., and here's another based on cesium: http://www.jackson-labs.com/index.php/products/csac http://www.jackson-labs.com/index.php/products/csac At one point Digikey was even stocking them as an off-the-shelf item! Relatively cheap too, "just" thousands of dollars per unit.

cryptonector 6y ago
Right, to protect against delayed broadcasts this system requires that the receiver have a reasonable clock. If there's only one frequency of signed key distribution, then it has to be very high frequency, and the clocks can't suck too much. This can be ameliorated by having a second, lower frequency signed key distribution schedule (basically: every N) that can enlarge bad clock tolerance. Starting from scratch, with invalid time will make the device susceptible to attack, but if this is a rare event then it hardly matters because attacks should be detected by other devices ("herd immunity"?), but if there's a sufficiently low frequency key distribution schedule then a user can validate that the time the device got from Galileo seems right.
- petertodd 6y ago
  For a lot of applications you start off in a location where you have a high assurance of being able to receive GPS/Galileo signals without interference, allowing you to set your clock accurately at the start of your mission (eg military or aviation).

cryptonector 6y ago

Right, to protect against delayed broadcasts this system requires that the receiver have a reasonable clock. If there's only one frequency of signed key distribution, then it has to be very high frequency, and the clocks can't suck too much. This can be ameliorated by having a second, lower frequency signed key distribution schedule (basically: every N) that can enlarge bad clock tolerance. Starting from scratch, with invalid time will make the device susceptible to attack, but if this is a rare event then it hardly matters because attacks should be detected by other devices ("herd immunity"?), but if there's a sufficiently low frequency key distribution schedule then a user can validate that the time the device got from Galileo seems right.

petertodd 6y ago
For a lot of applications you start off in a location where you have a high assurance of being able to receive GPS/Galileo signals without interference, allowing you to set your clock accurately at the start of your mission (eg military or aviation).