Signing or encrypting the data
-
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. -
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 -
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. -
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.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
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.
-
@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.
-
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 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 -
@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.@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.
-
@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@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.
-
@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.
@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.
-
@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.
-
@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.
@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.
-
@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.
@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.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@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 lot
I will order all ICs soon and test this in real life :)
-
@Anticimex Great. now it is very clear :) Thanks a lot
I will order all ICs soon and test this in real life :)
