whats your security tacticts via hackers or sniffers?

[halukmy]

i prefer xxtea for secure message, but still it can be copyable by sniffers, whats your security plans or functions anti-hack or save data from sniffers?

[IoTThinks]

Aes?

[halukmy]

@IoTThinks aes is good but .. if i copy aes message, node will do what crypted message does, hwo can we handle it?

[beowulff]

You need to use a timestamp or non-repeating message number to prevent replay attacks.

[IoTThinks]

Haha, like framecounter in LoRaWAN

[halukmy]

You need to use a timestamp or non-repeating message number to prevent replay attacks.

Thanks @beowulff can you share a sample if you have?

[beowulff]

Sorry, I don’t have any code right now (I’m in the middle of working on it for a project I’m involved with). But I’ll say this:

1) Using synchronized Real-Time Clocks is the easiest method. The RTCs need to be temperature-compensated, with drifts less than a few seconds / year. Something like a DS3231. Synchronize the sender and receiver clocks. Time-stamp each message with the current time. When the receiver decodes the message, check the message time stamp to it’s time, and reject any messages that are older or newer than the current time (use a window of a few seconds or more to allow for clock drift). Keep track of the checksums of the last N messages to prevent instantaneous replay attacks.

2) Monotonically increasing message numbers don’t require RTCs, but do require the sender and receiver to store sent and received message numbers in non-volatile memory (Flash, EEPROM, FRAM, battery-backed SRAM, etc.). Sender increments a message number for each message, receiver will not not accept a message number less than the current one it has a record of. As long as the message number is greater, the message is valid, which allows for missed messages. The only hitch is - if you store the message number in Flash, you need to be careful about wear-leveling. Flash has limited write/erase cycles, so something like dedicating a page to storing the numbers, and writing into the next available slot might work, or using a library that supports wear-leveling, like NVS on ESP-32. If you can detect power-fail conditions reliably, then you can store the message number when a power-fail is detected, and save an enormous number of writes.

Hope this has been helpful.

[neo7530]

Add a counter in encrypted message to prevent replay-attacks. Save the last valid counter to eeprom for power lost reason and accept only counter values greater than the last counter. This is how rolling codes are working (e. G. Keeloq)

Maybe you can add some signing scheme to the packets sent (Sha1 hmac is secure enough for that)

[halukmy]

@neo7530 you must be choicen one so what is signing scheme to the packets sent (Sha1 hmac)?

[neo7530]

I haven't chosen one yet. I do xtea encryption on my nodes and add a last round xtea as signature. Cost me 64bit extra payload.

[IoTThinks]

Security has a price. Hehe

[neo7530]

FYI: Have pushed some XTEA CBC-Code on my repo:

https://github.com/neo7530/arduino-LoRa/tree/master/examples/LoRaSimpleNode_xtea

it uses a Frame-Counter in encryption, so every code sent is completely different, even when you send the same message.

[IoTThinks]

So interesting. Let me take a look tmr. Thanks a lot. :D

[neo7530]

Have added some features in my repo. Have built in some kind of menu and enhaced security ;)

Have Fun.

[halukmy]

@neo7530 is every message diffrent about secure replay attack?

[neo7530]

Every message is different, but I didn't build counter-check in yet. After a reset the counter start at 0. On the receiving side there isn't a counter check either. You can build it for your own... Simply safe the received counter to eeprom and accept only messages, that have a counter greater than the last received message. And your replay safe node is ready.

[beowulff]

If this is going to be running for a long time, or send lots of messages, you need to be concerned with Flash wear-leveling. Use NVS, and not EEprom.

[neo7530]

I use FRAM instead ;)

[halukmy]

@neo7530 fram? i cant find it @beowulff also cant find how to use nvs on arduinıo

[neo7530]

Non volatile ferroelectic ram. F-Ram. 10 trillion write cycles per cell.

[beowulff]

Sorry, NVS is on ESP-32. But FRAM is probably the way to go - search on DigiKey. 4K chips are under $2.