💬 MySensors NRF5 Platform
-
@Anticimex said in 💬 MySensors NRF5 Platform:
Nice! However from a security point of view I would advice against using ECB mode for encryption as explained here: https://crypto.stackexchange.com/questions/20941/why-shouldnt-i-use-ecb-encryption
Thank you for the link. At the moment the "encryption" is implemented like it is for NRF24. I have commented it here https://github.com/mysensors/MySensors/pull/830/files#diff-cf14b6301beb3a4dbaded9b95bb190feR673
The nRF5 series is flexible enough to do a better encryption job. Its also possible to do things like frequency hopping or enable the RX mode at specific time slots to create battery powered actors.
@d00616 ok, but the encryption for RF24 is also rather useless as it does not use initialization vectors. So the first part of the message (if the message is up to the encryption block size in size) will always yield the same cipher text and thus be predictable. But perhaps this hw handles that. I have not read up on it. I believe the rfm69 radio does since it states that the payload size decreases if encryption is enabled, suggesting that there is room reserved for syncing IV:s.
Nevertheless, encryption is not the key to security imo. Authentication is. Encryption gives obfuscation. -
@d00616
very nice work :clap:I've also some projects with nrf52832, and waiting for pcb i'll release soon. I'm using raytac modules, was very tempted to try to make my antenna too but for the moment i'm sticking with those modules. I've not tried range yet, what do you get?
Can't wait to get some 52840 modules.. (a bit expensive for the moment) because package need special pcb.
Regarding authentication, i have added signing ic (atsha204a i2c) on my boards in case..Thank you very much for your porting to Mysensors, that's awesome :+1:
-
@d00616 ok, but the encryption for RF24 is also rather useless as it does not use initialization vectors. So the first part of the message (if the message is up to the encryption block size in size) will always yield the same cipher text and thus be predictable. But perhaps this hw handles that. I have not read up on it. I believe the rfm69 radio does since it states that the payload size decreases if encryption is enabled, suggesting that there is room reserved for syncing IV:s.
Nevertheless, encryption is not the key to security imo. Authentication is. Encryption gives obfuscation.@Anticimex
The implemented encryption is in the same state like NRF24. I know about the IV(0) problem, but my first goal was the NRF24 compatibility.For an nRF5 only protocol, the hardware AES-CCM encryption can be used. At the moment, I have no plans to start with a new radio protocol. When I should start with, my idea is to use dynamic keys exchanged with micro-ecc. An IV based on a shared part the node id and a value from synchronized RTC.
Nevertheless, encryption is not the key to security imo. Authentication is. Encryption gives obfuscation.
I agree here.
-
BTW. Have you had any time reading up on frequency hopping and how much stay-away-windows affect battery consumption? How is the time synchronization handled between nodes?
@hek said in 💬 MySensors NRF5 Platform:
BTW. Have you had any time reading up on frequency hopping and how much stay-away-windows affect battery consumption? How is the time synchronization handled between nodes?
The main problem of frequency hopping is finding the right time slot initially. I have no idea about a good way to implement this.
When I see the number of retransmits on my location, frequency hopping has no real benefit. What I interested is to use time slots for battery powered actors. The Gateway or Relay needs to cache packages and transmit it at the correct time. The node needs to listen at a specified time. When no data is transmitted the radio can be disabled after the time the address should send. To implement this Shortcuts and a bit counter is available. To use a low power mode to to this, the 32kHz crystal is required.
I use some of the functionality to disable the radio in the ESB mode when no ACK packet is received or after ACK is received.
To control this, the RTC trigger points needs to synchronized. Maybe with an protocol extension, but this needs access to the signing logic.
If you find out what is possible, there is an calculation tool for ANT+ protocol. https://www.thisisant.com/developer/components/developer
-
@d00616
very nice work :clap:I've also some projects with nrf52832, and waiting for pcb i'll release soon. I'm using raytac modules, was very tempted to try to make my antenna too but for the moment i'm sticking with those modules. I've not tried range yet, what do you get?
Can't wait to get some 52840 modules.. (a bit expensive for the moment) because package need special pcb.
Regarding authentication, i have added signing ic (atsha204a i2c) on my boards in case..Thank you very much for your porting to Mysensors, that's awesome :+1:
@scalz said in 💬 MySensors NRF5 Platform:
I'm using raytac modules, was very tempted to try to make my antenna too but for the moment i'm sticking with those modules. I've not tried range yet, what do you get?
I haven't measured the range yet.
Can't wait to get some 52840 modules.. (a bit expensive for the moment) because package need special pcb.
I think the final nRF82840 isn't launched yet.
-
@Anticimex
The implemented encryption is in the same state like NRF24. I know about the IV(0) problem, but my first goal was the NRF24 compatibility.For an nRF5 only protocol, the hardware AES-CCM encryption can be used. At the moment, I have no plans to start with a new radio protocol. When I should start with, my idea is to use dynamic keys exchanged with micro-ecc. An IV based on a shared part the node id and a value from synchronized RTC.
Nevertheless, encryption is not the key to security imo. Authentication is. Encryption gives obfuscation.
I agree here.
@d00616 yes I agree that protocol compatibility is priority. I just wanted to point out the current flaws with that encryption but you obviously know what you are doing :)
Best would be to come up with a solution that was radio agnostic, but for me encryption is not worth spending too much effort on. I'd say it's obscure enough as it is. Combined with signing, I think people will have a hard time breaking into it. -
@d00616
oki. i'll try to do some range tests, and your PR too! when i'll get more time :)
Would be nice if they would release a better package footprint for the 840..I said this because i've seen Fanstel is selling modules but not so cheap, so i prefer to wait a bit.
And i agree with you the 832 is already very nice, even if 840 has some nice feature. -
@d00616 yes I agree that protocol compatibility is priority. I just wanted to point out the current flaws with that encryption but you obviously know what you are doing :)
Best would be to come up with a solution that was radio agnostic, but for me encryption is not worth spending too much effort on. I'd say it's obscure enough as it is. Combined with signing, I think people will have a hard time breaking into it.@Anticimex said in 💬 MySensors NRF5 Platform:
Best would be to come up with a solution that was radio agnostic, but for me encryption is not worth spending too much effort on. I'd say it's obscure enough as it is. Combined with signing, I think people will have a hard time breaking into it.
What do you think about switching signing and encryption to AES-CCM? AES-CCM is part BLE(AES-CCM) and ZigBee(AES-CCM*) specification and available as hardware unit in NRF5 and other MCU. With AES132A a coprocessor is available.
AES-CCM provides encryption and authentication. With AES-CCM the SHA code can be removed. http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fccm.html&cp=2_2_0_28&anchor=topic
My thesis needs testing; I think AES-CCM on an AVR is faster than AES-CBC with SHA signing in Hardware and requires transmitting less data than the actual signing implementation.
I don't know something about the code size of AVR projects. When 8k are available, it's possible to store a unique AES-128 key per node in 4k. For AES key updates, a second 4k page is required.
The keys can be managed with the VirtualPage class: https://github.com/d00616/MySensors/blob/add_nrf5_platform/drivers/NVM/VirtualPage.h
For key exchange a library like micro-ecc is available. A device can authenticated with an preshared secret.
The IV can be built by the node ID and a counter incremented with every packet and a global distributed timestamp.
The counter can be stored in EEPROM after ~1000 packages and is rounded up to next 1000 after a reboot of a node.
If a node counter reaches the end, a new AES-Key is generated and distributed by the gateway.
-
@Anticimex said in 💬 MySensors NRF5 Platform:
Best would be to come up with a solution that was radio agnostic, but for me encryption is not worth spending too much effort on. I'd say it's obscure enough as it is. Combined with signing, I think people will have a hard time breaking into it.
What do you think about switching signing and encryption to AES-CCM? AES-CCM is part BLE(AES-CCM) and ZigBee(AES-CCM*) specification and available as hardware unit in NRF5 and other MCU. With AES132A a coprocessor is available.
AES-CCM provides encryption and authentication. With AES-CCM the SHA code can be removed. http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fccm.html&cp=2_2_0_28&anchor=topic
My thesis needs testing; I think AES-CCM on an AVR is faster than AES-CBC with SHA signing in Hardware and requires transmitting less data than the actual signing implementation.
I don't know something about the code size of AVR projects. When 8k are available, it's possible to store a unique AES-128 key per node in 4k. For AES key updates, a second 4k page is required.
The keys can be managed with the VirtualPage class: https://github.com/d00616/MySensors/blob/add_nrf5_platform/drivers/NVM/VirtualPage.h
For key exchange a library like micro-ecc is available. A device can authenticated with an preshared secret.
The IV can be built by the node ID and a counter incremented with every packet and a global distributed timestamp.
The counter can be stored in EEPROM after ~1000 packages and is rounded up to next 1000 after a reboot of a node.
If a node counter reaches the end, a new AES-Key is generated and distributed by the gateway.
@d00616 I don't see how this relate to the signing solution we use. We use HMAC-SHA256. We already have hw support for this in the atsha204a. There is no plan to replace this.
Encryption is also already existing in certain radios already (like the rfm69). So it will in a sense always be radio specific and needs to be in order to be effective.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@d00616 I don't see how this relate to the signing solution we use. We use HMAC-SHA256. We already have hw support for this in the atsha204a. There is no plan to replace this.
Encryption is also already existing in certain radios already (like the rfm69). So it will in a sense always be radio specific and needs to be in order to be effective. -
@Anticimex Ok.
@d00616 I don't however see it as a problem if you implement some underlying security solution specific to nrf5 as long as it don't require protocol "awareness". That's just a bonus so feel free to have a look at that. But things will quite fast become quite messy if we start mixing security schemes in the protocol.
The signing backend does have versioning support so it is possible to extend it with new schemes, but so far the scheme we use is supported across all radio variants and it would be a pity to give up that compatibility unless the new scheme offer some improvement over the current one.
The main drawback with the current one is the message size limitation imposed by the current protocol version which forces us to truncate the signatures but in version 3 of the MySensors protocol, this limitation will be overcome by protocol upgrades.Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
-
@d00616 I don't however see it as a problem if you implement some underlying security solution specific to nrf5 as long as it don't require protocol "awareness". That's just a bonus so feel free to have a look at that. But things will quite fast become quite messy if we start mixing security schemes in the protocol.
The signing backend does have versioning support so it is possible to extend it with new schemes, but so far the scheme we use is supported across all radio variants and it would be a pity to give up that compatibility unless the new scheme offer some improvement over the current one.
The main drawback with the current one is the message size limitation imposed by the current protocol version which forces us to truncate the signatures but in version 3 of the MySensors protocol, this limitation will be overcome by protocol upgrades.@Anticimex At the moment I have other priorities than implementing another security solution or protocol for NRF5. Another protocol can be implemented as a second radio driver including breaking the NRF24 compatibility with larger packet sizes and protocol optimization.
-
@Anticimex At the moment I have other priorities than implementing another security solution or protocol for NRF5. Another protocol can be implemented as a second radio driver including breaking the NRF24 compatibility with larger packet sizes and protocol optimization.
@d00616 with v3 the protocol backwards compatibility will be broken nevertheless in a way which will support the current generic security protocol fully across all radio transports.
But there are basically two layers. A mysensors layer where signing is handled using HMAC-SHA256 with nonce exchange, timeouts, lock detection and whitelisting. A rf specific layer can implement additional security solutions (typically encryption) that work transparently with the MySensors protocol. For signing, it is probably not needed as we already have that in place, but encryption could be a relevant feature for the lower level layers. -
@Anticimex At the moment I have other priorities than implementing another security solution or protocol for NRF5. Another protocol can be implemented as a second radio driver including breaking the NRF24 compatibility with larger packet sizes and protocol optimization.
Hi,
This is a such great addition for this project. For long time I wanted something like this: a RF SOC with pretty good and usable software support and low power also(and a Cortex arch - pff..that's too much :simple_smile: ). I just wanted to congratulate you for your work and bringing this in to MySensors project - it's very neat and useful.
I tested it and it works just great so far. I would give you 100 likes on openhardware.io if it would be possible :simple_smile: . Thanks once again for your effort.
-
Hi,
This is a such great addition for this project. For long time I wanted something like this: a RF SOC with pretty good and usable software support and low power also(and a Cortex arch - pff..that's too much :simple_smile: ). I just wanted to congratulate you for your work and bringing this in to MySensors project - it's very neat and useful.
I tested it and it works just great so far. I would give you 100 likes on openhardware.io if it would be possible :simple_smile: . Thanks once again for your effort.
@mtiutiu Thank you very much. I like to read your words. Have fun with this port.
I have started 2014 to work on Sensors based on the nRF51 chips. At this time the MCU was well documented, but Software was only available under an NDA. Without luck, I tried to build a free Arduino version based on RFduino. There are problems with my linker scripts.
My next attempt was to use RIOT OS as the base for my Sensor project. Later I have found the great MySensors project. I have started to extend the RIOT Arduino layer to let MySensors running. On my research, I found the Arduino port of Sandeep Mistry (thank you!), so it was easier for me add the missing functionality to MySensors and arduino-nrf5 instead to RIOT OS. From this point, I required eight months to a functional MySensors port.
-
Congratulations on winning the contest. That convinces me to give it a try.
Even though this has been available for months, I'm not seeing much discussion on:- Improvements on range.
- The best module to purchase for the simplest nodes - like temperature.
- Battery performance.
Anyone have feedback on those yet?
Thanks ahead of time
-
@ileneken3
I'm having some fun with @d00616 work :) And it's working fine so far (thx again).I have not tested battery performance for the moment.. NRF52 is capable of very low power but i think the low power is not enabled yet in the porting, it's explained in the project prez if i remember
Regarding range, sure NRF52 is an improved chip compared to NRF24 for instance, but the most important part is the antenna. That's the case for all mcu though. Take a long range capable mcu and a bad antenna choice, or a bad antenna design (bad gnd plane, bad clearance for antenna etc) and you'll never get the long range (example: miniaturized chip antenna, or some pcb antennas too).
For the simplest devices to buy, no idea as i'm making custom boards.
-
Congratulations on winning the contest. That convinces me to give it a try.
Even though this has been available for months, I'm not seeing much discussion on:- Improvements on range.
- The best module to purchase for the simplest nodes - like temperature.
- Battery performance.
Anyone have feedback on those yet?
Thanks ahead of time
@ileneken3 Thank you.
Like @scalz has written, the range depending mostly on the antenna. With the same antenna the nRF52 series are more efficient.
If you need a simple module to start with, a RedBear BLE Nano 2 or Nano is a good module. It's a small module with integrated voltage regulator and 2.54mm pins. This module is available in the second generation with compatible pin layout.
If you need an cheap module, there are some starting at 3-6€ with an nRF51. I don't know how long these modules are sold. If possible, use nRF52 based modules. The nRF52 is faster (https://github.com/mysensors/MySensors/pull/845), more flexible and less current consuming then nRF51. The interrupt vector of the nRF52 can be moved into RAM. This reduces the interrupt latency and allows to implement OTA updates in an simple way.
Most peripherals (e.g. expect ADC) can be assigned to any IO pin. So you can change the role in arduinos board definition.
You can find detailed information about the current consumption in the datasheets. The MySensors sleep function consumes 3µA until you want to wait for an Interrupt (1mA). To fix this cores/nRF5/WInterrupts.c needs an partitial rewrite. I have no time at the moment to fix this issue. The discussion about how to fix is sleeping: https://github.com/sandeepmistry/arduino-nRF5/issues/153
Another point to save some energy is to manage the DCDC converter (not available on all boards) in the radio or sleep code. -> https://devzone.nordicsemi.com/question/685/ldo-vs-dcdc-nrf51822/
More energy savings, requires breaking the compatibility to NRF24 radios and implementing an additional communication protocol. This allows to implement battery powered nodes which can receive packages.
When issue 153 is fixed, I think the nRF5 platform is a good choice to start new developments of sensors without the CPU and memory limitations of ATMEGA or maybe in the future the limitations of NRF24 radio. When its not fixed this is a good platform for main powered components and sensors which are only waking up by time.
