Better security without the need of a cryptoprocessor: out-of-band authentication
-
I had similar ideas with two firmwares. One for initialization and one running MySensors.
If asymetric encryption is used, there is no need for an PSK for encryption. A key is calculated on both sides this can be used as a node key. A library supporting 8 bit and 32 bit MCU is micro-ecc. The problem is, the key must be compared on both sides to detect man in the middle attacks. This could be by synchronous LED blinking the hash of the calculated key and accepting the key on the gateway. This allows to integrate sensors without the need of the SecurityPersonalizer.
The 32 byte package size can be extended by an nRF24/ECB protocol extension. First packet is send without ACK and when a second packet is received the ACK payload reports if the first packet is received. Then we have 64 byte packages, compatible with classic hardware.
I'm unsure if routing encrypted packages is a good idea. An attacker can force the relay to route invalid packages. On the other side the attacker can block the complete channel by sending invalid data.
When the motivation of the new security scheme is to reduce the cost. There are nRF51822 boards starting at less than 2.50€ and nRF52832 boards for less than 4.50€.
Compared the Arduino Pro Mini + nRF24 solution with the nRF51 you get ~100 times more performance without the 2k RAM limit and a lot of Flash for 0.50€ more costs. The nRF51 has an better range compared with the nrf24, allows to implement better radio protocols or switching to BLE (actually without MySensors) and it's possible to connect RFM modules. I think in six month the pricing is eqal.
With an bootloader like mcuboot, which needs porting to MySensors the key can be protected by disallowing flashing unsigned firmware and disable debugging.
I think we shouldn't do compromises to support 8 bit MCUs.
@d00616 asymetric encryption has some advantages but ECC is more computing intensive and asymetric encryption needs double decryption compared to single decryption with a symetric algorithm. I went with symetric because it's usually lighter and faster. Also, you would still need an initializing PSK to be able to differentiate a rogue sensor trying to register on your network vs. one of your own sensors. I don't thing a LED flashing a hash is really practical.
P.S.: I know that current cheap platforms, like NRF5, are much more powerful for not much more money, but we should also keep in mind that a lot of existing sensors have already been deployed. If we drop the Atmega328 support, anyone who want to benefit of the new security solution will have to throw away all its existing sensor and rebuild new ones. That's why I am a strong advocate of legacy support, I hate throwing away something that could still works just because there is something new and shinner available for the same price.
-
In fact I initially thought that more than one GW was possible in a MyS network. That messages where broadcast until a receiver ACK-ed for it.
@Anticimex I totally agree with you.
@Eurbaix Not only the hardware. Some people are doing a great job in NodeManager that could need re-adaptations (dunno).I almost always work with async encryption. Well... I think a mixed, cascaded solution may be ideal on this scenario. Just use sha256 ciphered key, surrounded by more packets sync-ciphered and wrapped together.
I don't know if the hardware may support it, but could be like peeling an onion, if you understand. Only the GW knows the key and deciphers the message.Payload is hardly inescapable.
-
@d00616 asymetric encryption has some advantages but ECC is more computing intensive and asymetric encryption needs double decryption compared to single decryption with a symetric algorithm. I went with symetric because it's usually lighter and faster. Also, you would still need an initializing PSK to be able to differentiate a rogue sensor trying to register on your network vs. one of your own sensors. I don't thing a LED flashing a hash is really practical.
P.S.: I know that current cheap platforms, like NRF5, are much more powerful for not much more money, but we should also keep in mind that a lot of existing sensors have already been deployed. If we drop the Atmega328 support, anyone who want to benefit of the new security solution will have to throw away all its existing sensor and rebuild new ones. That's why I am a strong advocate of legacy support, I hate throwing away something that could still works just because there is something new and shinner available for the same price.
@Eurbaix said in Better security without the need of a cryptoprocessor: out-of-band authentication:
P.S.: I know that current cheap platforms, like NRF5, are much more powerful for not much more money, but we should also keep in mind that a lot of existing sensors have already been deployed. If we drop the Atmega328 support, anyone who want to benefit of the new security solution will have to throw away all its existing sensor and rebuild new ones. That's why I am a strong advocate of legacy support, I hate throwing away something that could still works just because there is something new and shinner available for the same price.
I agree here. Atmega can be supported by switching back to the old scheme or by dropping features for this platform.
-
@Eurbaix said in Better security without the need of a cryptoprocessor: out-of-band authentication:
As for OTA, the initialization I proposed never send a clear key OTA. The initialization PSK is written on the sensor when you flash it (so, wired comms) and not part of the firmware. I was thinking something along the line of:
Flash and run a small firmware (which has the initialization PSK hardcoded) that will just store the initialization PSK in the EEPROM.
Flash and run the full MySensor firmware (which doesn't have the PSK hardcoded), then run the initialization using the PSK in the EEPROM.
This way, the full MySensor firmware, that will be updated OTA, never have to include a PSK so it can be sent in clear. Also, since comms are now encrypted, OTA updates could be encrypted although I don't see a need to encrypt firmware updates since they do not contain sensitive information.Why not having mysensors framework generating this key on the first start-up? If you're concerned about some-one getting through the algorithm, it could require some seed from the user that may be common for him. That's still compatible with my approach of a code generator if the generator asks for the seed.
Also, I don't understand why the repeaters are a problem. I don't see why they have to read all the messages, hence being deciphered. Why they don't just "relay" them?
@Sergio-Rius The reason for the initialization PSK is to be able to differentiate a sensor you flashed yourself from a sensor someone else flashed and try to register on your network.Of course, you could use the sensor name as the key, but it is a weak key and it would also require to store the new sensor name on the GW every time you want to initialize a new sensor. The initialization PSK being common to all nodes, you don't need to change anything on the GW when you build a new sensor.
You can't use an initial key generated by the GW because it would then need to be sent OTA to the sensor. Since the sensor do not have a PSK yet, this generated key would have to be send in clear. A rogue sensor listening at this moment could read this key and register instead of your own sensor. Although limiting the time during which a GW would accept a new sensor is limited by the "WPS" button, you have to think about a rogue sensor constantly listening and trying to register on your network until the GW is in "WPS" mode. (Note that I only refer to the basic concept of "WPS", which is limiting the time when a new sensor can register by using a button to initiate a 5-10 seconds window where the GW would accept a new sensor. The idea is simply that, since the initialization is using a common PSK which is a security risk if it is stored in easily accessible EEPROM, you want to limit as much as possible when this initialization PSK can be used, so only once during the initialization then it is deleted, and only if a button has been pressed on the GW within the last 5-10 seconds).
Also, when using several separate networks (i.e. different GW linked to the same controllers, but each GW talking to its own sensor network), by using a different initialization PSK on each gateway (and on the sensors that must register on a specific gateway), you make sure that a sensor can only register on the right gateway. Then, each GW has only the list of sensor PSK for his own network so there is no risk a sensor attempt to talk to a GW it is not supposed to (if that's a concern, like having a low security sensor network and a high security sensor network).
Also, I assume that GW are always in a secure location (cannot be stolen and read). If a GW can be compromised, we're opening an entirely new can of worms.
And regarding your last comment: I, also, think async encryption is a better solution on non-constrained network (i.e. when memory and computing power is not a big concern). But, in this context, if we want to keep legacy support, we better look for the most lightweight encryption algorithms. Also, anything using a 256 key cannot be used with the current protocol since a 256 key or token would take the entire packet, with no room left for the routing information. Since "out-of-band" needs to send new tokens regularly, we have to stay with 128 bits. Going with 256 keys would require to also modify the protocol and make the entire thing much more complex to implement
-
No matter what path we choose it is not dropping support per se. Worst case is that atmega users have to stick with current solution. Best case is a sw equivalent that might or might not leverage features of the atsha204a to accomplish the things needed by a new security infrastructure capable of fitting into legacy devices with reasonable space to spare.
-
@Sergio-Rius The reason for the initialization PSK is to be able to differentiate a sensor you flashed yourself from a sensor someone else flashed and try to register on your network.Of course, you could use the sensor name as the key, but it is a weak key and it would also require to store the new sensor name on the GW every time you want to initialize a new sensor. The initialization PSK being common to all nodes, you don't need to change anything on the GW when you build a new sensor.
You can't use an initial key generated by the GW because it would then need to be sent OTA to the sensor. Since the sensor do not have a PSK yet, this generated key would have to be send in clear. A rogue sensor listening at this moment could read this key and register instead of your own sensor. Although limiting the time during which a GW would accept a new sensor is limited by the "WPS" button, you have to think about a rogue sensor constantly listening and trying to register on your network until the GW is in "WPS" mode. (Note that I only refer to the basic concept of "WPS", which is limiting the time when a new sensor can register by using a button to initiate a 5-10 seconds window where the GW would accept a new sensor. The idea is simply that, since the initialization is using a common PSK which is a security risk if it is stored in easily accessible EEPROM, you want to limit as much as possible when this initialization PSK can be used, so only once during the initialization then it is deleted, and only if a button has been pressed on the GW within the last 5-10 seconds).
Also, when using several separate networks (i.e. different GW linked to the same controllers, but each GW talking to its own sensor network), by using a different initialization PSK on each gateway (and on the sensors that must register on a specific gateway), you make sure that a sensor can only register on the right gateway. Then, each GW has only the list of sensor PSK for his own network so there is no risk a sensor attempt to talk to a GW it is not supposed to (if that's a concern, like having a low security sensor network and a high security sensor network).
Also, I assume that GW are always in a secure location (cannot be stolen and read). If a GW can be compromised, we're opening an entirely new can of worms.
And regarding your last comment: I, also, think async encryption is a better solution on non-constrained network (i.e. when memory and computing power is not a big concern). But, in this context, if we want to keep legacy support, we better look for the most lightweight encryption algorithms. Also, anything using a 256 key cannot be used with the current protocol since a 256 key or token would take the entire packet, with no room left for the routing information. Since "out-of-band" needs to send new tokens regularly, we have to stay with 128 bits. Going with 256 keys would require to also modify the protocol and make the entire thing much more complex to implement
@Eurbaix said in Better security without the need of a cryptoprocessor: out-of-band authentication:
Of course, you could use the sensor name as the key, but it is a weak key and it would also require to store the new sensor name on the GW every time you want to initialize a new sensor. The initialization PSK being common to all nodes, you don't need to change anything on the GW when you build a new sensor.
We are seeing this from a different point of view. I can't get the controller out of this equation (by my own limitations). I would like to start the pairing process from the controller, see whats available and only authorize what it was meant to. That's why I was thinking more on a "identification key"
If I understand well:
A key is hardcoded (to say) in the GW.
Then you must write that key in the new sensor (other network will have a different key).
The pairing process is initiated, so you turn on the sensor.
The GW acknowledges with the sensor and sends to him a new key that is saved and then starts authentication and encryption as normal.As for sha256, anything below that is crackeable. And so, yes, were're not designing the next pentagon network here. But you must think if 256+ size messages will be the next logical step or a question of time.
By now, I totally agree with you.I personally think atmega is so charismatic. ESP32 had to be the panacea, but I'm still waiting for it.
-
No matter what path we choose it is not dropping support per se. Worst case is that atmega users have to stick with current solution. Best case is a sw equivalent that might or might not leverage features of the atsha204a to accomplish the things needed by a new security infrastructure capable of fitting into legacy devices with reasonable space to spare.
@Anticimex Totally agree. The initial idea of my proposal was a security scheme compatible with existing sensors where a compromised sensor without an atsha204a can be easily blacklisted, this preferably with a minimal impact on the firmware size compared to the purely software solution already implemented. Also, it would provide obfuscation in addition to authentication, since I am not really comfortable with someone knowing if my house is empty and/or locked.
Since the existing software solution already have AES, and "out-of-band" with token generated from the GW doesn't require a random number generator on the sensors, I think the "out-of-band" security could be implemented without a significant increase in the firmware size. The only compromise would be a 16 bytes encrypted payload if we stay with AES 128. Personnaly, I would accept this compromise so people using more modern platform can take advantage of the HW AES and free up some memory for the more complex sensors. After all, MySensors don't normally send tons of data, so it would only mean sending 2-4 packets instead of 1-2. Also, since the firmware updates do not contain any key, they don't need to be encrypted and can use the full payload.
-
@Eurbaix said in Better security without the need of a cryptoprocessor: out-of-band authentication:
Of course, you could use the sensor name as the key, but it is a weak key and it would also require to store the new sensor name on the GW every time you want to initialize a new sensor. The initialization PSK being common to all nodes, you don't need to change anything on the GW when you build a new sensor.
We are seeing this from a different point of view. I can't get the controller out of this equation (by my own limitations). I would like to start the pairing process from the controller, see whats available and only authorize what it was meant to. That's why I was thinking more on a "identification key"
If I understand well:
A key is hardcoded (to say) in the GW.
Then you must write that key in the new sensor (other network will have a different key).
The pairing process is initiated, so you turn on the sensor.
The GW acknowledges with the sensor and sends to him a new key that is saved and then starts authentication and encryption as normal.As for sha256, anything below that is crackeable. And so, yes, were're not designing the next pentagon network here. But you must think if 256+ size messages will be the next logical step or a question of time.
By now, I totally agree with you.I personally think atmega is so charismatic. ESP32 had to be the panacea, but I'm still waiting for it.
@Sergio-Rius Yes, your description is exactly what I was thinking about (except in much less words than I used). One important step you missed is that the initial "hardcoded" key must be erased during the "pairing" process so it cannot be compromised if a sensor is stolen. That's why it has to be in EEPROM on an atmega (other platforms, like the NRF5, have no EEPROM but can erase a flash page, which would do the same thing).
As for 128 keys, yes they are crackeable. You only need all the computers of the Cambridge university (or was it Oxford?) during the entire weekend to crack a single cypher block. After all, banks still use AES 128 and, last time I checked, there was still some money left on my bank account ;-). Sure, at one point, 128 encryption will be brakeable in minutes (or nanoseconds if the Chinese are not lying about their prototype Qubits computer) but we're not there yet.
P.S.: I don't know about the charisma of the atmega, but when it comes to I/O per dollar, it's hard to beat. And since I started programming on a portable TRS-80 PC-3 (1.4KB of RAM!) I still think there's lot we can do with the "huge" memory of the atmega. As long as we're not trying to implement edge-computing in MySensors, the atmega still has a future as a very affordable IoT platform to play with.
-
Actually, the block size is 16 bytes also for 256 bit AES keys.
-
I had similar ideas with two firmwares. One for initialization and one running MySensors.
If asymetric encryption is used, there is no need for an PSK for encryption. A key is calculated on both sides this can be used as a node key. A library supporting 8 bit and 32 bit MCU is micro-ecc. The problem is, the key must be compared on both sides to detect man in the middle attacks. This could be by synchronous LED blinking the hash of the calculated key and accepting the key on the gateway. This allows to integrate sensors without the need of the SecurityPersonalizer.
The 32 byte package size can be extended by an nRF24/ECB protocol extension. First packet is send without ACK and when a second packet is received the ACK payload reports if the first packet is received. Then we have 64 byte packages, compatible with classic hardware.
I'm unsure if routing encrypted packages is a good idea. An attacker can force the relay to route invalid packages. On the other side the attacker can block the complete channel by sending invalid data.
When the motivation of the new security scheme is to reduce the cost. There are nRF51822 boards starting at less than 2.50€ and nRF52832 boards for less than 4.50€.
Compared the Arduino Pro Mini + nRF24 solution with the nRF51 you get ~100 times more performance without the 2k RAM limit and a lot of Flash for 0.50€ more costs. The nRF51 has an better range compared with the nrf24, allows to implement better radio protocols or switching to BLE (actually without MySensors) and it's possible to connect RFM modules. I think in six month the pricing is eqal.
With an bootloader like mcuboot, which needs porting to MySensors the key can be protected by disallowing flashing unsigned firmware and disable debugging.
I think we shouldn't do compromises to support 8 bit MCUs.
@d00616 said in Better security without the need of a cryptoprocessor: out-of-band authentication:
I had similar ideas with two firmwares. One for initialization and one running MySensors.
If asymetric encryption is used, there is no need for an PSK for encryption. A key is calculated on both sides this can be used as a node key. A library supporting 8 bit and 32 bit MCU is micro-ecc. The problem is, the key must be compared on both sides to detect man in the middle attacks. This could be by synchronous LED blinking the hash of the calculated key and accepting the key on the gateway. This allows to integrate sensors without the need of the SecurityPersonalizer.
The 32 byte package size can be extended by an nRF24/ECB protocol extension. First packet is send without ACK and when a second packet is received the ACK payload reports if the first packet is received. Then we have 64 byte packages, compatible with classic hardware.
I'm unsure if routing encrypted packages is a good idea. An attacker can force the relay to route invalid packages. On the other side the attacker can block the complete channel by sending invalid data.
When the motivation of the new security scheme is to reduce the cost. There are nRF51822 boards starting at less than 2.50€ and nRF52832 boards for less than 4.50€.
Compared the Arduino Pro Mini + nRF24 solution with the nRF51 you get ~100 times more performance without the 2k RAM limit and a lot of Flash for 0.50€ more costs. The nRF51 has an better range compared with the nrf24, allows to implement better radio protocols or switching to BLE (actually without MySensors) and it's possible to connect RFM modules. I think in six month the pricing is eqal.
With an bootloader like mcuboot, which needs porting to MySensors the key can be protected by disallowing flashing unsigned firmware and disable debugging.
I think we shouldn't do compromises to support 8 bit MCUs.
OMG... Please don't take offence. Just some thoughts after a lot of sangria in a very hot evening :smile: Do you work for Nordic? :laughing: :trollface:
The nRF51 has an better range compared with the nrf24
16meters instead of 15 meters? :laughing: Very good range for wireless mouses and keyboards...
it's possible to connect RFM modules.
Have you tested it yet enough? If yes... what is the reason for using this chip with rfm and overhead internal radiomodule instead of one from among much more powerful honest well known ARM MCUs?
without the 2k RAM limit
64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.
I think in six month the pricing is eqal.
I will be happy if we will have a stable framework in a year :sparkles:
So... I think we shouldn't hurry to bury the 8bit MCU's without adequate and well tested replacement.
-
@d00616 said in Better security without the need of a cryptoprocessor: out-of-band authentication:
I had similar ideas with two firmwares. One for initialization and one running MySensors.
If asymetric encryption is used, there is no need for an PSK for encryption. A key is calculated on both sides this can be used as a node key. A library supporting 8 bit and 32 bit MCU is micro-ecc. The problem is, the key must be compared on both sides to detect man in the middle attacks. This could be by synchronous LED blinking the hash of the calculated key and accepting the key on the gateway. This allows to integrate sensors without the need of the SecurityPersonalizer.
The 32 byte package size can be extended by an nRF24/ECB protocol extension. First packet is send without ACK and when a second packet is received the ACK payload reports if the first packet is received. Then we have 64 byte packages, compatible with classic hardware.
I'm unsure if routing encrypted packages is a good idea. An attacker can force the relay to route invalid packages. On the other side the attacker can block the complete channel by sending invalid data.
When the motivation of the new security scheme is to reduce the cost. There are nRF51822 boards starting at less than 2.50€ and nRF52832 boards for less than 4.50€.
Compared the Arduino Pro Mini + nRF24 solution with the nRF51 you get ~100 times more performance without the 2k RAM limit and a lot of Flash for 0.50€ more costs. The nRF51 has an better range compared with the nrf24, allows to implement better radio protocols or switching to BLE (actually without MySensors) and it's possible to connect RFM modules. I think in six month the pricing is eqal.
With an bootloader like mcuboot, which needs porting to MySensors the key can be protected by disallowing flashing unsigned firmware and disable debugging.
I think we shouldn't do compromises to support 8 bit MCUs.
OMG... Please don't take offence. Just some thoughts after a lot of sangria in a very hot evening :smile: Do you work for Nordic? :laughing: :trollface:
The nRF51 has an better range compared with the nrf24
16meters instead of 15 meters? :laughing: Very good range for wireless mouses and keyboards...
it's possible to connect RFM modules.
Have you tested it yet enough? If yes... what is the reason for using this chip with rfm and overhead internal radiomodule instead of one from among much more powerful honest well known ARM MCUs?
without the 2k RAM limit
64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.
I think in six month the pricing is eqal.
I will be happy if we will have a stable framework in a year :sparkles:
So... I think we shouldn't hurry to bury the 8bit MCU's without adequate and well tested replacement.
-
@Anticimex Agreed for the payload. The problem is you have to send this 256 AES key (the token) and there will be no room left in a 32 bytes packet for the hash that provides integrity check for the token. 256 keys could be used in SensorKeys in my proposal, as it is only send OTA once during the initialization, and we can decide for this reason to let go of the integrity check for the SensorKey. On the other hand, a token is sent everytime a sensor initiate a communication, or even for every packet if the TTL of the token is only one packet, so I think we should keep integrity check for tokens, therefore leave enough room for a hash in the 32 bytes packet. The options would be 192 AES with 64 bits hash, although I'm not sure there's may HW that support 192 AES, or 128 AES key with 128 bits hash.
P.S.: One attack that is frequently forgotten is sending "garbage", i.e. random payloads which, once decrypted will be considered as valid payload and be interpreted by a node, creating all kind of unpredictable side effects. That's why I want to make sure "garbage" can be detected in all exchanges, using a hash.
-
@d00616 said in Better security without the need of a cryptoprocessor: out-of-band authentication:
I had similar ideas with two firmwares. One for initialization and one running MySensors.
If asymetric encryption is used, there is no need for an PSK for encryption. A key is calculated on both sides this can be used as a node key. A library supporting 8 bit and 32 bit MCU is micro-ecc. The problem is, the key must be compared on both sides to detect man in the middle attacks. This could be by synchronous LED blinking the hash of the calculated key and accepting the key on the gateway. This allows to integrate sensors without the need of the SecurityPersonalizer.
The 32 byte package size can be extended by an nRF24/ECB protocol extension. First packet is send without ACK and when a second packet is received the ACK payload reports if the first packet is received. Then we have 64 byte packages, compatible with classic hardware.
I'm unsure if routing encrypted packages is a good idea. An attacker can force the relay to route invalid packages. On the other side the attacker can block the complete channel by sending invalid data.
When the motivation of the new security scheme is to reduce the cost. There are nRF51822 boards starting at less than 2.50€ and nRF52832 boards for less than 4.50€.
Compared the Arduino Pro Mini + nRF24 solution with the nRF51 you get ~100 times more performance without the 2k RAM limit and a lot of Flash for 0.50€ more costs. The nRF51 has an better range compared with the nrf24, allows to implement better radio protocols or switching to BLE (actually without MySensors) and it's possible to connect RFM modules. I think in six month the pricing is eqal.
With an bootloader like mcuboot, which needs porting to MySensors the key can be protected by disallowing flashing unsigned firmware and disable debugging.
I think we shouldn't do compromises to support 8 bit MCUs.
OMG... Please don't take offence. Just some thoughts after a lot of sangria in a very hot evening :smile: Do you work for Nordic? :laughing: :trollface:
The nRF51 has an better range compared with the nrf24
16meters instead of 15 meters? :laughing: Very good range for wireless mouses and keyboards...
it's possible to connect RFM modules.
Have you tested it yet enough? If yes... what is the reason for using this chip with rfm and overhead internal radiomodule instead of one from among much more powerful honest well known ARM MCUs?
without the 2k RAM limit
64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.
I think in six month the pricing is eqal.
I will be happy if we will have a stable framework in a year :sparkles:
So... I think we shouldn't hurry to bury the 8bit MCU's without adequate and well tested replacement.
@Koresh I am sorry to disagree but, yes, NRF5, which is now reasonably close (less than 2x) to the price of Arduino Mini + NRF24L01, is a big step forward (although I think we shouldn't drop legacy atmega support). As an example, I'm thinking about a project for MySensors bird song detection, using FFT and band detection on edge-computing to limit the required bandwidth and it would easily fit on a typical 32 bit MCU like NRF5 but there is no way to have 10bit ADC plus FFT plus frequency band detection running at a decent frequency on an Arduino. Plus, having the radio and MCU in one unit really simplify the assembly and limit the risk of a connection going wrong.
Not saying the arduino should be dropped, but there is really a point in also developing support for a platform like NRF5 (or any other 32 bit MCU with integrated radio, but the advantage of NRF5 is its radio compatibility with legacy NRF24L sensors).
-
@Anticimex Agreed for the payload. The problem is you have to send this 256 AES key (the token) and there will be no room left in a 32 bytes packet for the hash that provides integrity check for the token. 256 keys could be used in SensorKeys in my proposal, as it is only send OTA once during the initialization, and we can decide for this reason to let go of the integrity check for the SensorKey. On the other hand, a token is sent everytime a sensor initiate a communication, or even for every packet if the TTL of the token is only one packet, so I think we should keep integrity check for tokens, therefore leave enough room for a hash in the 32 bytes packet. The options would be 192 AES with 64 bits hash, although I'm not sure there's may HW that support 192 AES, or 128 AES key with 128 bits hash.
P.S.: One attack that is frequently forgotten is sending "garbage", i.e. random payloads which, once decrypted will be considered as valid payload and be interpreted by a node, creating all kind of unpredictable side effects. That's why I want to make sure "garbage" can be detected in all exchanges, using a hash.
-
@d00616 said in Better security without the need of a cryptoprocessor: out-of-band authentication:
I had similar ideas with two firmwares. One for initialization and one running MySensors.
If asymetric encryption is used, there is no need for an PSK for encryption. A key is calculated on both sides this can be used as a node key. A library supporting 8 bit and 32 bit MCU is micro-ecc. The problem is, the key must be compared on both sides to detect man in the middle attacks. This could be by synchronous LED blinking the hash of the calculated key and accepting the key on the gateway. This allows to integrate sensors without the need of the SecurityPersonalizer.
The 32 byte package size can be extended by an nRF24/ECB protocol extension. First packet is send without ACK and when a second packet is received the ACK payload reports if the first packet is received. Then we have 64 byte packages, compatible with classic hardware.
I'm unsure if routing encrypted packages is a good idea. An attacker can force the relay to route invalid packages. On the other side the attacker can block the complete channel by sending invalid data.
When the motivation of the new security scheme is to reduce the cost. There are nRF51822 boards starting at less than 2.50€ and nRF52832 boards for less than 4.50€.
Compared the Arduino Pro Mini + nRF24 solution with the nRF51 you get ~100 times more performance without the 2k RAM limit and a lot of Flash for 0.50€ more costs. The nRF51 has an better range compared with the nrf24, allows to implement better radio protocols or switching to BLE (actually without MySensors) and it's possible to connect RFM modules. I think in six month the pricing is eqal.
With an bootloader like mcuboot, which needs porting to MySensors the key can be protected by disallowing flashing unsigned firmware and disable debugging.
I think we shouldn't do compromises to support 8 bit MCUs.
OMG... Please don't take offence. Just some thoughts after a lot of sangria in a very hot evening :smile: Do you work for Nordic? :laughing: :trollface:
The nRF51 has an better range compared with the nrf24
16meters instead of 15 meters? :laughing: Very good range for wireless mouses and keyboards...
it's possible to connect RFM modules.
Have you tested it yet enough? If yes... what is the reason for using this chip with rfm and overhead internal radiomodule instead of one from among much more powerful honest well known ARM MCUs?
without the 2k RAM limit
64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.
I think in six month the pricing is eqal.
I will be happy if we will have a stable framework in a year :sparkles:
So... I think we shouldn't hurry to bury the 8bit MCU's without adequate and well tested replacement.
@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
Do you work for Nordic?
No. I have ported MySensors to the nRF5 platform and contributed nRF5 code to arduino-nrf5 and RIOT OS.
Actually this is the most complete port supporting hwSleep() or hwCPUVoltage(). The good news is, there are a lot of other 32 Bit MCUs available and MySensors supports actually:
- ESP8266
- nRF5
- SAMD
- STM32F1
- Teensy3
The number of ported 32 bit MCU's are the reason for my opinion of 8 bit support. I'm sure we see much more interesting MCU's supporting MySensors in the future.
@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
16meters instead of 15 meters? Very good range for wireless mouses and keyboards...
For long range sub GHz is the better choice. This is physics.
btw: https://www.youtube.com/watch?v=wRpW2KIPfVo@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
without the 2k RAM limit
64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.
If you are right, we can provide the same security level for both platforms without compromises. That's fine.
I think the question about the mass of data are storable in the RAM is a question of data alignment and the stack should be larger. With perfect misalignment, you can loose 5/8 of data memory. If you call all your functions with 8 bit arguments, then you loose 3/4 of stack.
In the unrealistic 3/4 scenario 2k 8 bit ram is comparable with 8k 32 bit ram.
@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
I think in six month the pricing is eqal.
I will be happy if we will have a stable framework in a year
Please help by reporting the issues you have found, so we can create stable 32 bit platform support.
-
@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
Do you work for Nordic?
No. I have ported MySensors to the nRF5 platform and contributed nRF5 code to arduino-nrf5 and RIOT OS.
Actually this is the most complete port supporting hwSleep() or hwCPUVoltage(). The good news is, there are a lot of other 32 Bit MCUs available and MySensors supports actually:
- ESP8266
- nRF5
- SAMD
- STM32F1
- Teensy3
The number of ported 32 bit MCU's are the reason for my opinion of 8 bit support. I'm sure we see much more interesting MCU's supporting MySensors in the future.
@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
16meters instead of 15 meters? Very good range for wireless mouses and keyboards...
For long range sub GHz is the better choice. This is physics.
btw: https://www.youtube.com/watch?v=wRpW2KIPfVo@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
without the 2k RAM limit
64kb ram with 32bit mcu is not big progress relative the 2kb ram with 8bit mcu.
If you are right, we can provide the same security level for both platforms without compromises. That's fine.
I think the question about the mass of data are storable in the RAM is a question of data alignment and the stack should be larger. With perfect misalignment, you can loose 5/8 of data memory. If you call all your functions with 8 bit arguments, then you loose 3/4 of stack.
In the unrealistic 3/4 scenario 2k 8 bit ram is comparable with 8k 32 bit ram.
@Koresh said in Better security without the need of a cryptoprocessor: out-of-band authentication:
I think in six month the pricing is eqal.
I will be happy if we will have a stable framework in a year
Please help by reporting the issues you have found, so we can create stable 32 bit platform support.
@d00616 said in Better security without the need of a cryptoprocessor: out-of-band authentication:
For long range sub GHz is the better choice. This is physics.
You are right. But almost in every country RF laws allow to use 2.4G transmitters up to 100mw (+20dbm) without permitions. It would extend the range a lot.
Please help by reporting the issues you have found, so we can create stable 32 bit platform support.
I will try :wink:
