search

UAVTracking / UAVTrackingProtocol

An open radio protocol for transmitting UAV flight data in real time.
https://xkcd.com/927/
11 stars 4 forks source link

How about challange-response authentication #29

Open pjalocha opened 6 years ago

pjalocha commented 6 years ago

Just got an idea: why not use challenge-response authentication ?

As we conclude drones must both transmit and listen (for traffic awareness) we can make the response to challenges according to their stored secret keys.

You may ask: who would give the challenge ? Well, it could be the groundstation - it is not that difficult to attach say RFM69 to Raspberry PI (I did this !) or the drones them self !

Suppose drones transmit themself challenges say every minute and every drone who hears it is obligated to respond within certain time, say another minute). Every drone would give a different response, as it has a different key. These responses would be recorded and transmitted on APRS. Then the french autority server could verify who responds correctly and who only pretends...

This would give us several advantages:

  1. false responses would yield immediate spotting of the "bad guys"
  2. lack of responses would yield guys who either don't listen for traffic (real bad...) or who are not really there (fake signal generators)
  3. analysis of who responds to whom would yield analysis of range, etc.
  4. OGN ground receivers would need not to know anything about the keys or even algorithm of the authentication. They would simply receive challenges and responses, interpretation of which would be left to the government processing server, which can simply pick up the data from the APRS.
  5. Communication of the positions would be not affected by the authentication, I assume for which only like one packet per minute would be transmitted by every drone.
  6. Existing OGN protocol can be used, with ev. improvements and addition of two packet type: authentication-challenge and authentication-response.
  7. OGN receivers need only to be made read and transmit on APRS the above two packet type.

The packet content would not be signed but the positions/speeds could be verified with MLAT technology.

It would be good to invent a scheme so that the challenges do not repeat or we can count on very low probabilities of such repetitions.

The challenge/response packet would be same size but different type from position packets thus we wouldn't need to enlarge the position packets by the signature. The challenge response could possibly be of 128-bit size, would this be enough ?

I think this is really attractive and would allow to resolve several issues we could not resolve this far: authentication with reasonable packet sizes and spotting of fake signals.

pjalocha commented 6 years ago

After rethinking I find this scheme is not really different from authenticating every Nth position packet. Nevertheless I would propose the following scheme:

In the packet header there is a 2-bit field, let's call it "Auth".

The interpretation is the following:

Auth=00 => no authentification (for this position packet)

Auth=01 => I will sign this position packet (or respond to this challenge - it is equivalent I believe) Here the packet becomes the challenge (or the data to sign) - this is 160bits in my packet format. I would add the 32-bit time which corresponds to this position and 64-bit of some other data (could be part of the secret key) to form 256bit challenge (or data to sign)

After this the drone transmitter has lot of time to compute the response (or signature). This could be a low priority task running in the background so it would be doable by any CPU. When the response (or signature) is computed the transmitter sends it out with:

Auth=10 => this packet is the first half of the response (signature): 128-bit of data follows Auth=11 => this packet is the second half of the response (signature): 128-bit of data follows.

The OGN reciever job would be to pick up and send to APRS the challenge (data to sign) when Auth=01 and record the two parts of the response (signature) when Auth=10 or 11. The OGN receivever needs not to know anything about the individual keys or anything about the authentication algorithm.

Authentication algorithm can be defined independently, possibly different algorithms can be used, the transmitter would signal which algorithm it uses in the information packets.

What happens when packets are lost ?

When Auth=01 is lost, too bad, we have to wait for another occasion. When either of the Auth=10 or 11 is lost, we can still compare half of the response. When both are lost: well, wait another occcasion.

This would work I believe with the fixed sized packets of 26 bytes like the current OGN or a similar size if we decide to modify it. I would suggest to modify the OGN a little and add 2byte to FEC code, so it becomes full 64-bit and less packets are lost.

acasadoalonso commented 6 years ago

Pawel et al:

I think that schema could work, it will require some testing and proof with several targets, but is worth to try it.

AC/. Sent from my iPad

On 20 Oct 2017, at 12:39, pjalocha notifications@github.com wrote:

After rethinking I find this scheme is not really different from authenticating every Nth position packet. Nevertheless I would propose the following scheme:

In the packet header there is a 2-bit field, let's call it "Auth".

The interpretation is the following:

Auth=00 => no authentification (for this position packet)

Auth=01 => I will sign this position packet (or respond to this challenge - it is equivalent I believe) Here the packet becomes the challenge (or the data to sign) - this is 160bits in my packet format. I would add the 32-bit time which corresponds to this position and 64-bit of some other data (could be part of the secret key) to form 256bit challenge (or data to sign)

After this the drone transmitter has lot of time to compute the response (or signature). This could be a low priority task running in the background so it would be doable by any CPU. When the response (or signature) is computed the transmitter sends it out with:

Auth=10 => this packet is the first half of the response (signature): 128-bit of data follows Auth=11 => this packet is the second half of the response (signature): 128-bit of data follows.

The OGN reciever job would be to pick up and send to APRS the challenge (data to sign) when Auth=01 and record the two parts of the response (signature) when Auth=10 or 11. The OGN receivever needs not to know anything about the individual keys or anything about the authentication algorithm.

Authentication algorithm can be defined independently, possibly different algorithms can be used, the transmitter would signal which algorithm it uses in the information packets.

What happens when packets are lost ?

When Auth=01 is lost, too bad, we have to wait for another occasion. When either of the Auth=10 or 11 is lost, we can still compare half of the response. When both are lost: well, wait another occcasion.

This would work I believe with the fixed sized packets of 26 bytes like the current OGN or a similar size if we decide to modify it. I would suggest to modify the OGN a little and add 2byte to FEC code, so it becomes full 64-bit and less packets are lost.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

snip commented 6 years ago

OGN receiver is easy to install because it is just connecting standard equipments. Adding something to allow it to transmit raise the complexity. So some ground receivers may have this bidirectional feature but for sure not all.

The other point is that UAV will have more difficulties to receive messages from ground transmitter than the opposite as the ground receiver has very high sensitivity thanks to SDR.

So i think it is better to have only one way communication for signature.