Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
You need to authenticate the messages and add measures against replay attacks*. It is also a good idea to use different keys for authentication and encryption. The Pre-Shared keys should not be used for communication, but only to do a key exchange for session keys.
Very important: A CRC can not be used for message authentication. See how WEP failes.
* The timestamp method is acceptable, but bear in mind, that you have to securely sync the clocks. -
If you do Homebrew things and don't need to deploy on scale. Just use a hardcoded 128/256 AES key for each device (obviously a different key for each one)
And then you make sure that unencrypted/faulty messages are thrown away and doesn't crash anything. Also make sure there is no buffer overflow.
edit:
Add a timestamp and a hash aswell. Cheers. -
@BigBoo I agree, but I would add authentication and measures against replay attacks as essential.
Security is very interesting, but easy to fuck up. Definitely one of my goals to learn more and get more confident. -
@Scade Why authentication when there is only one user? If there is some hash verification it should be fine.
Or do you mean a response/challenge thing? -
@BigBoo I mean messenge authentication like HMAC. Sorry, for being imprecise.
-
@Scade This is what I meant with a hash. Lol.
-
@BigBoo Commented before your edit ;)
-
Thanks for your input, it all makes sense! Not sure if session keys are really required for such small private usecase - well, if everything fits on the arduino in the end, it will be fine to implement.
Forgot to add a requirement btw: Sequence number!
So my question is basically, if somebody knows, am I reinventing the wheel here? Or do you know of trustworthy libs to achieve such protocol scheme on arduino? -
@nona42
I would be shocked if you can't find all bits and pieces already implemented. But idk if there is a ready to use solution. -
@BigBoo yep, will happily put something together when money comes in again to get the required components.
-
@Skayo understandable, it looks odd at first.
More specific: Make 433Mhz as secure / drive-by-secure as possible.
It's obvious that basic communication over this band is normally not implemented securely at all.
See it as 'SFTP over self-constructed TCPish protocol over UDP' - if you know what I mean.
Overkill but interesting nonetheless imo -
<@nona42>
Alright, sounds interesting! -
@Skayo
With 433GHz reciever you dont need to worry about anything! Nobody is going to sniff that :p
Related Rants
Did you say security?
10 points for next century option.
Avoided IoT(IoS - InternetOfShit) for a long time now, due to the security concerns with retail products.
Now I looked into 433 Transceiver + Arduino solutions.. to build something myself, just for the lolz.
Theory:
Smallest Arduino I found has 32 KByte of programmable memory, a tiny tiny crypto library could take around 4 KBytes...
Set a symetric crypto key for each homebrewn device / sensor / etc, send the info and commands (with time of day as salt for example) encrypted between Server <-> IoT gadget, ciphertext would have checksum appended, magic and ciphertext length prepended.
Result:
Be safe from possible drive-by attacks, still have a somewhat reliable communication?!
Ofc passionate hackers would be still able to crack it, no doubt.
Question: Am I thinking too simple? Am I describing just the standard here?
question
iot
security
rf
cryptography
433mhz