Signing or encrypting the data
-
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 :)
-
@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 :) -
@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.
-
@meddie Sure. Maybe by the end of that month I may begin in OTA process.
I hope I can find good documentation :)@ahmedadelhosni
fine, thank you in advanced -
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.
-
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.
