Post by Admin on Jan 23, 2015 3:10:32 GMT
The RFM69 library uses AES encryption, so it's pretty difficult for anyone to take apart your transmission or send you modified data. However, it's possible (even if it's unlikely) that they could do a replay attack. It's possible to capture your data, and without decrypting it, simply re-broadcast it.
Back when I started the gateway code, I had plan to use the "unsigned long" int to be used as a counter of sorts. The gateway would keep track of each sending node's counter value, and each transmission should be larger than the previous received transmission. The sensor nodes would know to increment this value. This would prevent replay attacks, since the attacker can only replay a previously recorded signal, they can't take it apart and resend it with an incremented counter value.
I would also have to build in some means of resetting the counter value (either on start-up or counter roll over). So if the counter value is 0 AND both var2_float and var3_float have values of "123". Or something like that. It's not bullet proof, as the attacker can still capture this special reset transmission, but it's an improvement.
The gateway could keep track of "current" counter values for each nodeID & sensorID pair in a 1000x10 matrix. Where (<nodeID>,<sensorID>) forms a coordinate into the matrix, and the value stored in the matrix is the current counter value. Zero out this counter value when the special reset transmission is received. And simply don't post MQTT data if message is received whose counter value isn't greater than the (X,Y) value. Some lead way might be needed in case the reset transmission isn't received by the gateway, which I was going to solve by enabling the ACK.
Well, never got around to implementing this. But perhaps someone will want to work on it. Or have a better idea for doing this.
Eric
Back when I started the gateway code, I had plan to use the "unsigned long" int to be used as a counter of sorts. The gateway would keep track of each sending node's counter value, and each transmission should be larger than the previous received transmission. The sensor nodes would know to increment this value. This would prevent replay attacks, since the attacker can only replay a previously recorded signal, they can't take it apart and resend it with an incremented counter value.
volatile struct
{
int nodeID;
int sensorID;
unsigned long var1_usl; // increment this value on every transmission
float var2_float;
float var3_float;
int var4_int;
}I would also have to build in some means of resetting the counter value (either on start-up or counter roll over). So if the counter value is 0 AND both var2_float and var3_float have values of "123". Or something like that. It's not bullet proof, as the attacker can still capture this special reset transmission, but it's an improvement.
The gateway could keep track of "current" counter values for each nodeID & sensorID pair in a 1000x10 matrix. Where (<nodeID>,<sensorID>) forms a coordinate into the matrix, and the value stored in the matrix is the current counter value. Zero out this counter value when the special reset transmission is received. And simply don't post MQTT data if message is received whose counter value isn't greater than the (X,Y) value. Some lead way might be needed in case the reset transmission isn't received by the gateway, which I was going to solve by enabling the ACK.
Well, never got around to implementing this. But perhaps someone will want to work on it. Or have a better idea for doing this.
Eric
