Signing or encrypting the data
-
Hi,
i thin it is very important that the messages which will be send from nodes or from gateway are signed, or encrypted.
Can somebody explain how to do this with the new api for beginners. I am not really good in this, and would be happy to get explained how to go on for dummies.
Thank you
Greets Eddie
-
First you need to determine if you want signing or encryption. A good place to start is answering "why" (instead of what).
When you have decided, go to http://forum.mysensors.org/topic/1021/security-introducing-signing-support-to-mysensors for signing and http://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24/1 for encryption.
-
@mfalkvidd : why not using both signing and encryption ? I am using both (encryption with RFM69) and really want to know if I am a little bit 'paranoiac'
-
You might not be paranoid enough. A lot of what your sensors do can probably be deduced from the timing of the messages, even if the messages are encrypted.
So by using encryption you might think that you are more protected than you really are. I think that is a dangerous situation.
It is all about the why. If the why is "I don't want other people to turn on and off my lights/lock/heat/stereo" the answer is not encryption.
If the why is "I don't want someone dedicated to map my life to figure out when I'm home, what room I am in when I'm home, when I listen to music, what time I get up in the morning, etc" the answer is not encryption.If the why is "Because I want to be cool and I think encryption is makes me cool" then yes, the answer is encryption.
-
@mfalkvidd said:
If the why is "Because I want to be cool and I think encryption is makes me cool" then yes, the answer is encryption.
So using both is the solution. I don't want someone read my data (presence, alarm status, etc.) and I don't want someone able to open my garage door. No ?
David.
-
No. It is quite likely that someone who is interested in that data will be able to figure it out even if you are using encryption. If you think encryption makes it impossibe to figure out what time you come home each day, what time you go to bed and turn on the alarm, what time you get up and turn off the alarm, etc, you think you are more secure than you really are.
-
Ok but it's true for all wireless system and encryption just give you a better security but as all system it's not perfect.
For me, the security of my sensors are the same as my door. My door is strong but not unbreakable. It's just strong enough to avoid anybody entering my house easily. It's possible to break it but you need time and specific tool.
For my sensors it's the same, you could learn my usage but it will cost a lot of effort and time for ..... nothing else my 5 years old TV and some pantiesDavid
-
@mfalkvidd said:
It is all about the why. If the why is "I don't want other people to turn on and off my lights/lock/heat/stereo" the answer is not encryption.
If the why is "I don't want someone dedicated to map my life to figure out when I'm home, what room I am in when I'm home, when I listen to music, what time I get up in the morning, etc" the answer is not encryption.If the why is "Because I want to be cool and I think encryption is makes me cool" then yes, the answer is encryption.
OK, i thought, when encrypted, that nobody else can read the messages.
I dont want be cool :-), i really want to be safe, that nobody can turn on/off anything, or read the states of my sensors to get the informations you wrote above.
The sensors can give a really sensitive information. Because when somebody can read the states maybe he can recontruct your day. And then he knows exactly when you are not at home.
-
Yes, that's exactly my point. If you think encryption makes it impossible to see when you are home, you've been misled.
If someone can look out their window and see you come and go, they can map your day.
If someone can see through your windows when lights are on, they can map your day.
If someone can see when your sensors send messages, they can map your day.Using encryption will not change that.
There are some benefits to encryption, but encryption does not solve all problems.
-
I would preffer to sing and encrypt the messages. So it sure that the data is from correct node/controller, and is not faked. And encrypted and so not readable for third.
But i would to use OTA too, and if i have correct understood, then its not possible. Because the bootloader needs the data unencrypted.
Please correct me when i am false.
i wish some how to's for dummies. Signing, Encrypting and OTA.
It would be the perfect System, sure and future-proof.
-
OK, 100% safety you will never get, but its more safer then to send messages readable for everyone.
-
If there is anything in the documentation about signing that is unclear just let me know. I have tried to write it in a manner that makes it accessible to anyone. And I totally support @mfalkvidd in his stance on encryption. It is essentially pointless in a mysensors context. If you stream audio or video it would make sense but for sensor data, considering the predictability of that data, encryption makes you no safer in any sense. It merely obfuscate the data slightly.
-
please dont get angry with me, and correct if i am wrong. But when a sensor sends a message that a window is opened. And somebody can read this message then he konws that the window is not closed.
When the message is signed then i know that the message is correct and comes from cerrect node. But the message is readable for "everyone" (is it right?)
So everybody can read your sates. (is it right too?)
When messages are singed and encrypted, then this anybody who can "listen" cant read the messages. He can still receive them but he cant start anything with them. He has only the info that one of the sensors has send data, but dont get the content of the data
-
@meddie What's preventing anyone from walking up to your window and feeling if it is locked or not?
Or look at it this way:
1 = open, 0 = locked. If sent in clear text, an eavesdropper sees '1' or '0'. Now, assuming he knows which is what, then he knows the window is opened or closed. But that is really not important information.
So what do you get by encrypting that data? Well, you achieve "some certainty" that an eavesdropper don't know if you just locked your window. But he will know for sure you did something with the window at that point in time. And there is a 50% chance, you locked the window.
Now, that being said; encryption is supported for both NRF24 and RFM69 radios, so if it makes you feel better, just enable it. It won't makes things worse. But signing provides a far greater security value than encryption, so if you really care about security, you should prioritize signing.
-
Yes you have 100% right. I think the combination of signing and encrypting should be the better choice.
But is IT right that ota wont work if encrypting?
-
That depend on what bootloader you use. If you use MYSbootloader, then it won't work as it is the bootloader that manages the radio. But if you use dualoptiboot, the OTA solution is radio independent as the firmware is transferred in a "mysensors context" and stored on external flash before rebooting and then the dualoptiboot bootloader moves that firmware to internal flash. So with dualoptiboot, it should be possible to encrypt the data.
But note that in both cases, signing won't be used for performance reasons. The checksum of the firmware will be signed though.
It is in the pipeline to support SHA256 checksumming the firmware and sign that checksum for greater security (it currently uses crc). But it is not yet in place. @tekka is our core team OTA developer, he might fill you in on the details on OTA with respect to signing and encryption and which variant supports what.
-
@Anticimex If I remember well, It was mentioned in a conversion between you and mfalkvidd that even if I am using dualOptiboot and the messages are singed then I am not fully secured.as a hacker can easily flash a new bootloader with no signing support. This will happen currently as OTA doesn't support signing and this is currently in the development phase by tekka as far as I know.
-
@ahmedadelhosni well, that depends on what level of security you seek. Messages are signed if you configure your nodes properly. Just not stream type payloads. But the messages to initiate and finalize OTA are signed. The discussion I had with mfalkvidd concerned the use of crc which is a checksum easier spoofed than for instance sha256.
-
@Anticimex said:
That depend on what bootloader you use. If you use MYSbootloader, then it won't work as it is the bootloader that manages the radio. But if you use dualoptiboot, the OTA solution is radio independent as the firmware is transferred in a "mysensors context" and stored on external flash before rebooting and then the dualoptiboot bootloader moves that firmware to internal flash. So with dualoptiboot, it should be possible to encrypt the data.
OK, nice to hear that its possible. When i have to put an external flash and a dualoptibootloader, then its not the problem.
But note that in both cases, signing won't be used for performance reasons.
What do mean, i didnt understand. Can you explain this please.
Thank you very much!
Greets Eddie
-
@Anticimex said:
@meddie What's preventing anyone from walking up to your window and feeling if it is locked or not?
Or look at it this way:
1 = open, 0 = locked. If sent in clear text, an eavesdropper sees '1' or '0'. Now, assuming he knows which is what, then he knows the window is opened or closed. But that is really not important information.
So what do you get by encrypting that data? Well, you achieve "some certainty" that an eavesdropper don't know if you just locked your window. But he will know for sure you did something with the window at that point in time. And there is a 50% chance, you locked the window.
Now, that being said; encryption is supported for both NRF24 and RFM69 radios, so if it makes you feel better, just enable it. It won't makes things worse. But signing provides a far greater security value than encryption, so if you really care about security, you should prioritize signing.Maybe it's my bad English or I really haven't understood it correctly.
Signing: Verifies the sender and receiver are known.
Encryption: Encodes the message so it's only readable for you.So in conclusion, if I'm signing my messages I'm only getting my messages and only I am able to read my messages. So no third party can give me wrong messages and can't read my messages? He also should not be able to read if I'm playing with my door/window nore if I'm opening or closing it.
-
@meddie a signature takes up part of the available payload space. For nrf24 it is 27 bytes. For a signature to be efficient it needs to be reasonably large, say have the available payload. That leaves have the amount left for binary data. OTA require MANY packages to transfer a typical sketch. For each package a nonce exchange will take place. For this reason, signing is not used for streams. And it does not have to be. A stream should always be checksummed in order to be fully validated. A signature only needs to cover that checksum.
-
@Rasenheizung well, I thought I just explained why encryption is pointless in this case. Unless the attacker is exceptionally stupid, he will be able to deduce the content of a simple message, encrypted or not, by just examining the traffic over a period of time. It is dangerous to underestimate your adversary so that is why I do not recommend encryption only I'd you care about security. But as I said, if you feel better with it, just use it. But don't expect your data to be truly private just because you obfuscate it.
-
@Anticimex
no, 100% safety wll never be possible. But i would feel me better when i know that the messages are not so easy readable for someone who has a mysensors too.
I have some weeks ago read in the FHEM Forum, there has a user build a second gateway just for testing, and as he started them the whole sensors has sended the data twice to both gateways. The logical
I didnt try this, but it's scary when it is so easy possible to read the sensors.
-
@meddie This is not uncommon, build yourself a 433mhz gateway and you will receive every 433 message in that gateway range... also a bit scary since many home alarms and other security things use 433mhz.
-
@Anticimex said:
OTA require MANY packages to transfer a typical sketch. For each package a nonce exchange will take place. For this reason, signing is not used for streams. And it does not have to be. A stream should always be checksummed in order to be fully validated. A signature only needs to cover that checksum.
Please bear with me. I just want to be sure I understand it well.
"For this reason, signing is not used for streams." Means that signing is not used when uploading a sketch. Does this lead to a hacker replacing my sketch ?A stream should always be checksummed in order to be fully validated
Checksum will make sure that the sketch is transferred correctly to avoid data corruption, NOT security, correct ?
A signature only needs to cover that checksum
So you propose that a signature must be added with the checksum for security, correct ??
So in brief. OTA is not secured at the moment and the code can be replaced easily with an unsigned one, correct ?
Thanks.
-
You are perfectly correct. But if you reach my level of paranoia, you will find that encryption provides little comfort. But you may use it to your hearts content of course.
-
@ahmedadelhosni said:
Please bear with me. I just want to be sure I understand it well.
"For this reason, signing is not used for streams." Means that signing is not used when uploading a sketch. Does this lead to a hacker replacing my sketch ?No, I stated that the sketch is checksummed and that checksum is signed. So no, a hacker won't (probably) be able to replace your sketch. Lest he is able to produce one that yields the exact same checksum AND manages to inject it so that the signed checksum is arrived in a timely manner for the receiver to take it into account.
Checksum will make sure that the sketch is transferred correctly so to avoid data corruption, correct ?
"Sure" in this aspect is a very relative term. But yes, that is it's purpose.
So you propose that a signature must be added with the checksum for security, correct ??
No, I say it is added if signing is enabled. But please be aware that the current version of MYSBootloader does not support signing. Future versions will do.
So in brief. OTA is not secured at the moment and the code can be replaced easily with an unsigned one, correct ?
No, as I said, dualoptiboot should be secure. But the use of CRC as checksum is not as secure as SHA256 would be, so the security is not as good as it can be.
-
@Anticimex Great. now it is very clear
Thanks a lotI will order all ICs soon and test this in real life
-
@ahmedadelhosni
Fine, please let stay me informed, because i am very interested too.
-
@meddie Sure. Maybe by the end of that month I may begin in OTA process.
I hope I can find good documentation
-
one more question: is it possble to run the atmega with dualoptiboot bootloader at 1MHz. For battery use. And use the the encryption and signing and OTA.
-
@ahmedadelhosni
fine, thank you in advanced
-
@meddie Please direct OTA questions to @tekka He can better explain what is supported in which solution and when any unsupported features will be available if planned.
Generally, 1MHz offer little battery benefit over 8MHz.
-
for a MCU that never enters sleep states, running at 1Mhz can save you some power, compared to running at 8Mhz. But if you plan to enter sleep state, and only wake up periodically, you won't gain that much. As sleepmode current is the same for both 1Mhz and 8Mhz.
One can also argue that if you are using 1Mhz, then the program execution will be longer, compared to 8Mhz. So when it wakes up from sleep mode, it will stay awake for a longer time, if running at 1Mhz, compared to 8Mhz.
-
@tbowmo Good points. Neven thought about it as I flash 1Mhz always.
I may try power consumption using 8Mhz in a new sensor node.
Thanks for the info.
-
yes me too. i will try my test setup to burn the bootloader at 8 mhz. It would make much easier.
-
Any one tried to run a atmega with encryption and software signing? And with Hardware Signing?
-
Yes.
