View previous topic :: View next topic |
Author |
Message |
EDC
Joined: 26 Mar 2014 Posts: 971
|
Posted: Thu Jun 16, 2022 7:19 pm Post subject: Rolling code - send data more secure |
|
|
Some radiolink have built-in encoding for transmissions but most of them not.
In Bascom you can encode your data with Xtea but look what happen when you send the same data.
Coded Hexstring always look the same.
So if anybody record your transmission then when if it will be played back then your device will respond the same.
We can blurr this and crypt harder
Xtea array must be multiple of 8. Means 8, 16, 24, 32 etc.
This is the shortest example of sending EXACTLY THE SAME string with ALWAYS another encoding.
Array of 16 bytes is overlayed by our string but with one byte shift so first is for as.
Also string is shorter and we have two bytes at the end of the array.
Into 15`th byte we draw some random value, then we calculate CRC from whole array and put it in the first byte. So we can even check data integrity on receiver side.
If we now crypt our array with Xtea we got blurred hexstring everytime.
We are done right? Not exactly..
Nobody knows what data we send but if that data will be captured and played back then it will be valid again!
So that is why I put some Synchro value into 16`th byte.
This Synchro is increased everytime by value of constant Rolling = 3 and only transmitter and receiver knows what value it is.
Means recorded transmission IS USELESS now
Single Synchro without Random 15 may be insufficient because after byte overflow someday message will be valid again.
You can build a remote and even when you transmit out of range then after second click you will be synchronized again. Simillary like cars remote.
So check how this can be done. This can be used even on some RS485 transmisions.
Code: |
' SIMULATION - crypted rolling code
$regfile = "m328pdef.dat"
$crystal = 16000000
$hwstack = 64
$swstack = 32
$framesize = 64
$sim
Config Submode = New
Const Rolling = 3
Dim N As Byte , I As Byte
Dim Xkey(16) As Byte
Xkey(1) = 16
Xkey(2) = 15
Xkey(3) = 14
Xkey(4) = 13
Xkey(5) = 12
Xkey(6) = 22
Xkey(7) = 22
Xkey(8) = 44
Xkey(9) = 55
Xkey(10) = 0
Xkey(11) = 9
Xkey(12) = 8
Xkey(13) = 7
Xkey(14) = 6
Xkey(15) = 5
Xkey(16) = 4
Dim Xmsg(16) As Byte
Dim Mymsg As String * 12 At Xmsg(1) Overlay
Sub Send_crypted(byval My_string As String * 12)
Mymsg = My_string
Xteaencode Xmsg(1) , Xkey(1) , 16
For I = 1 To 16
Print Hex(xmsg(i));
Next
Print " ";
End Sub
Sub Decrypt_msg()
Xteadecode Xmsg(1) , Xkey(1) , 16
Print Mymsg
End Sub
Print "Send crypted normally"
For N = 1 To 5
Call Send_crypted( "Send crypted")
Call Decrypt_msg()
Next
'------------------[CRYPTED RANDOMLY]-----
Print ""
Print "Now send the same but crypted randomly"
Dim Synchro_tx As Byte
Dim Txarr(16) As Byte 'array
Dim Txstr As String * 12 At Txarr(2) Overlay 'shifted +1
Sub Send_crypted2(byval My_string As String * 12)
Txstr = My_string
Txarr(15) = Rnd(255) 'always random
Synchro_tx = Synchro_tx + Rolling
Txarr(16) = Synchro_tx
Txarr(1) = Crc8(Txarr(1) , 16) 'first always random
Xteaencode Txarr(1) , Xkey(1) , 16
For I = 1 To 16
Print Hex(txarr(i));
Next
Print " "; 'space in terminal
End Sub
Dim Synchro_rx As Byte
Dim Rxarr(16) As Byte 'array
Dim Rxstr As String * 12 At Rxarr(2) Overlay 'shifted +1
Sub Decrypt_msg2()
Xteadecode Rxarr(1) , Xkey(1) , 16
Print Rxstr ;
Print " " ;
If Rxarr(16) = Synchro_rx Then
Print "OK VALID"
Else
Print "NOT VALID! " '; Synchro_rx ; " " ; Rxarr(16)
End If
Synchro_rx = Rxarr(16) + Rolling
End Sub
For N = 1 To 5
Call Send_crypted2( "Send crypted")
For I = 1 To 16
Rxarr(i) = Txarr(i) 'emulate that we receiving data in another device
Next
'I = Memcopy(txarr(1) , Rxarr(1) , 16 , 3) 'same here
Call Decrypt_msg2()
Next
End
|
|
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Thu Jun 16, 2022 7:42 pm Post subject: |
|
|
now that is what i call an expert genius idea
this is very useful indeed !
this because with only one way you can not do a handshake.
and with such little code, love it! _________________ Mark |
|
Back to top |
|
|
EDC
Joined: 26 Mar 2014 Posts: 971
|
Posted: Thu Jun 16, 2022 8:06 pm Post subject: |
|
|
Thank you! it is an honour read that.
Im just working on some remote device. Im blurring with Rnd(255) for some time but...people are smarter everyday this days and I dont want troubles when some "young hacker" will record my transmission. So today brings me that idea to add rolling and synchro.
Two transmissions should be always in sync. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Thu Jun 16, 2022 8:18 pm Post subject: |
|
|
i never checked out how rolling code exactly worked. you want to know about everything but there is always too little time.
it was a pleasure to learn how it can be done.
for full safety(does that exist?) you would need 2 transceivers. using AES with some challenge. and this challenge would be different each time. like a simple sum.
i guess it would be hard to *****. but a transceiver is bigger, uses more current etc. so at some point you need to consider if all the additional work is worth it. i would say that your code is little more effort but improves safety in a big way.
i appreciate the fact that while you must be busy too, you take the time to post your projects. _________________ Mark |
|
Back to top |
|
|
dk9uv
Joined: 07 Jan 2012 Posts: 21
|
Posted: Sun Nov 05, 2023 8:28 pm Post subject: |
|
|
Good idea,
but what happens when someone records 2 consecutive data transmissions?
I think then a replay attack is possible again. |
|
Back to top |
|
|
EDC
Joined: 26 Mar 2014 Posts: 971
|
|
Back to top |
|
|
dk9uv
Joined: 07 Jan 2012 Posts: 21
|
Posted: Mon Nov 06, 2023 8:34 am Post subject: |
|
|
What about a large size counter in the transmitter and in the receiver?
A data transmission is only accepted if the transmitted counter value
is larger than the receiver counter. Counters will be incremented and
stored in EEPROM, so that even in the case of battery change or reset
counter values are not lost. Another idea is using a timer in both
transmitter and receiver, e.g. a battery buffered real time clock,
see https://ww1.microchip.com/downloads/en/Appnotes/00001683A.pdf
I am looking for a solution with reasonable security and low effort
for implementation. Additional real time clock is quite some effort.
Storing counters in EEPROM can be a problem of course (max. write cycles,
execution time and power consumption). |
|
Back to top |
|
|
EDC
Joined: 26 Mar 2014 Posts: 971
|
Posted: Mon Nov 06, 2023 9:12 am Post subject: |
|
|
This was designed for my "Only one way trasmission" like remote controller. Intention also was that devices can lose Sync (ex. remote out of range) so in some way they should be capable of resynchronising. Everything have pros and cons.
Buffer of 10 x 16B = 160B is not a big SRAM challenge nowadays...
You can store then 10 valid transmissions in the circullar buffer like I propose in the previous post.
Then you can check if such data was received in the past.
If "replay" transmission detected then you can treat it as an attack and hold processing of new messages for 10sec for example to avoid some "brute force"... Such a message offcourse should not to be stored again in the buffer but SynchroTx should be increased about "Rolling" value so even oryginal and valid sender will have to synchronise again by generating two new valid transmissions that will be unique again.
You can check if previous synchro was lower than new because "Synchro_tx = Synchro_tx + Rolling" but care must be taken about byte overflow.
In my small example the data was constant (string "Send crypted") but you can change and add anything. _________________ Check B-Flash -my MCS bootloader app for Android |
|
Back to top |
|
|
|