4 ms·

The article makes a good description of the problem, explains how the solution works, but doesn't really explain why the solution solves the problem. How can it

by ris 6y ago

The article makes a good description of the problem, explains how the solution works, but doesn't really explain why the solution solves the problem. How can it protect against a delayed identical signal being re-transmitted at a higher power by a relay station? All its cryptography will check out. How does the key being transmitted afterwards actually help it? If we need a chain of message keys to be able to decode a block of messages, and messages frequently go missing, doesn't this mean missing a message in the chain makes authenticating any later (er... previous?) messages of the block impossible?

oritsnile 6y ago
There a certain time windows where a key is valid, so you can delay a few days for example (keys are disclosed either after 30s or 5min). You can really protect against real time replay of the signal, at least not in the authentication protocol. But there are other Methods of detecting relays. The delayed publication of the key give the algorithm the needed asymmetricity. Since a key only authenticates message in a specific time window, attackers can't reuse the key once it's out there. Regarding your last point, you can reconstruct "used" key with new keys. The keys are basically generated with K_{n-1} = F(K_n), where F is a hash function. So with the current key you can authenticated all previous messages.
petertodd 6y ago
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).
cameldrv 6y ago
It doesn't, and I don't think that there is really a software solution to this. IMO the proper solution is to use multiple receive antennas to verify that the signals are coming from the expected direction. Then if your adversary isn't capable of orbiting a clone of all of the GNSS constellations or flying dozens of precisely positioned drones above you, you can't be spoofed.

by ris 6y ago

oritsnile 6y ago

There a certain time windows where a key is valid, so you can delay a few days for example (keys are disclosed either after 30s or 5min). You can really protect against real time replay of the signal, at least not in the authentication protocol. But there are other Methods of detecting relays. The delayed publication of the key give the algorithm the needed asymmetricity. Since a key only authenticates message in a specific time window, attackers can't reuse the key once it's out there. Regarding your last point, you can reconstruct "used" key with new keys. The keys are basically generated with K_{n-1} = F(K_n), where F is a hash function. So with the current key you can authenticated all previous messages.

petertodd 6y ago

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).

cameldrv 6y ago

It doesn't, and I don't think that there is really a software solution to this. IMO the proper solution is to use multiple receive antennas to verify that the signals are coming from the expected direction. Then if your adversary isn't capable of orbiting a clone of all of the GNSS constellations or flying dozens of precisely positioned drones above you, you can't be spoofed.