💬 MySensors NRF5 Platform




  • Contest Winner

    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

    Using message signing combined with encryption helps somewhat as part of the encrypted payload will be random in nature.



  • @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.


  • Contest Winner

    @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.


  • Admin

    @d00616, an impressive first post here in the community. Welcome!

    Great job on porting the library to a new platform.


  • Admin

    @d00616

    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?


  • Hardware Contributor

    @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:



  • @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.



  • @hek

    @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



  • @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.


  • Contest Winner

    @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.


  • Hardware Contributor

    @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.



  • @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.


  • Contest Winner

    @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.




  • Contest Winner

    @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.


  • Contest Winner

    @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.


Log in to reply
 

Looks like your connection to MySensors Forum was lost, please wait while we try to reconnect.