[OpenTRV-dev] Thinking aloud: preventing replay attacks

Mike Stirling EMAIL ADDRESS HIDDEN
Wed Dec 10 09:45:54 GMT 2014


If the MAC layer provides authentication as well then there's no need to 
worry about replay attacks anyway.  Of course how you provide the 
authentication...

If you assume you will always have a back-channel, and I think you need 
this for the security to work well, then you can always allow for ACKs 
on any important packets and then just use a simple sequence number.  If 
you have a receiver then you can also solve the timing problem by using 
a superframe structure where a transmission can be made invalid if sent 
outside of the superframe in which it was first sent.

I'm actually testing TinyHAN using ACKed packets from the sensor nodes 
and it is working very well.  You get to see straight away if your 
sensor is in range by the colour of the LED blink you get when it wakes up.

Mike

On 09/12/14 07:26, Damon Hart-Davis wrote:
> Well,, except that the sizes of all the parts used in the IPSec (numbers of bits in hashes) are potentionally too large for our 64-byte frames if we’re to actuslly get any data in there, but that’s another matter!
>
> Rgds
>
> Damon
>
>> On 8 Dec 2014, at 21:09, Bruno Girin <EMAIL ADDRESS HIDDEN> wrote:
>>
>>
>>
>> On 8 December 2014 at 00:43, Damon Hart-Davis <EMAIL ADDRESS HIDDEN> wrote:
>>>
>>> Thought…
>>>
>>> I imagine that at pairing / key exchange that I could set a largish (eg 64-bit) counter at both ends to the same value (or just 0) and send its value or a hash of it with nonce in each encrypted frame, and the hub with lots of memory could remember all previous values used to reject any replays and/or reject any received counter value less than the starting value and allow only a smallish window for new values to allow some frame loss.  In fact maybe the hub only needs the counter which it advances to the received value when it gets a decent frame.
>> I think that I just badly reinvented something like the IPSec sliding window mechanism, which is potentially fine…
>>
>> http://www.ipsec-howto.org/x202.html
>>
>> Good. That proves that you were thinking along the right lines and the fact that you checked before implementing saved time. Besides, adapting a mechanism that is used by IP will lead to consistency and make it a lot easier for people to accept it. IPSec over RF?
>>
>> Bruno
>>
> _______________________________________________
> OpenTRV-dev mailing list
> EMAIL ADDRESS HIDDEN
> http://lists.opentrv.org.uk/listinfo/opentrv-dev



More information about the OpenTRV-dev mailing list