Better security without the need of a cryptoprocessor: out-of-band authentication

[Eurbaix]

Although I was really impressed by Anticimex contribution on MySensors security, especially how he explained in very simple words the how and why of its authentication approach, there is a serious weakness in his authentication approach: the common PSK used for your entire MySensors network. If one sensor's PSK is compromised, your entire MySensors network is compromised and you have to reflash everything with a new PSK. Hence the use of a cryptoprocessor to make sure noone can read the PSK even if he has stolen a sensor. Except this solution is not cheap since even a very basic cryptoprocessor as the one Anticimex chose cost more than a complete node (Arduino Mini plus NRF24L01.

Out-of-Band authentication would allow any node to talk to any other node, even it knows only its own personal PSK, which is not shared with any other node.

• The gateway, which is normally in your secure space, so should not be stolen, allocate separate, random PSK to every node and keep a list of all these PSK.
• When a node wants to talk to another node (or even to the gateway), it requests a temporary token to the gateway, authentifying itself using its PSK that the gateway knows.
• The gateway sends a random token (something that is both a nonce and a PSK) to the node who requested it, and also to the node the first node wants to talk to.
• For a few seconds, the two nodes can talk to each other using this token.

Since the token is temporary, it plays the same role as a nonce to avoid replay attack. Since the gateway knows everybody's PSK (even an ESP8266 has enough memory to store everybody's 128bit PSK for a fairly large network), the gateway can authentify the initial token request and make sure the request is only sent to the two sensors that want to talk to each other by using each sensor PSK to encrypt the token.

So, at the end, since a compromised sensor will only reveal its own PSK but not the other sensor's PSK, and you can easily blacklist this sensor by erasing its PSK on the gateway (which is normally more easily accessible than most of your sensors), you can have a fairly safe network without using an relatively expensive cryptoprocessor.

Let me know if I missed something.

And, yes, I should not only talk about it but try to implement it myself. Except, since the last time I actually coded something myself, it was in Turbo Pascal (yes, before it was called Delphi), catching up with today's programming language then go through the entire MySensor firmware to make sure I implement this correctly will probably take me a couple of year. So I think it would be best to let someone more knowledgeable than me implement this.

On the other hand, if someone is interested, I have a few idea on how to make this really easy to use, i.e. using automatic PSK generation and allocation with a more secure version of "WPS", a simple way to very securely blacklist a stolen node and so on.

Also, I know a bit about out-of-band authentication but I am not a network security specialist so I may have missed a big security hole. Let me know if it's the case.

[Anticimex]

@Eurbaix thank you for your input. You are perfectly correct and the core team is currently discussing alternative approaches for more modern hardware (we have to consider that many users still base their designs on the atmga328p).
But we are looking into implementing some form of PKI based security solution which is in many ways similar to your proposal. I don't have and eta for this yet though. But the new security infrastructure will not support a atmga328p based gw.
Me and @d00616 have been discussing back and forth but we are all limited in time, and implementing security features should be done with care so things take time.

[Eurbaix]

PKI is even better than out-of-band although a bit more complex to implement, I was aiming for KISS as out-of-band is really not more complicated to implement than regular PSK.

Regarding your comment about supporting the legacy platform, it is certainly a constraint. For me, the most important constraint is to keep the cost as low as possible so we can keep experimenting with sensors we don't really need because who cares, it's only 5$.

A good alternative, and I'm surprised its not more popular in MySensor, is STM32F103, basically the same price as an arduino mini pro, no hardware encryption or secure memory but plenty of CPU and memory for software encryption, which should be OK as long as blacklisting a sensor is easy.

Also, what about assymetric encryption, which would perfect here?

[Anticimex]

@Eurbaix you are welcome to submit a pull request and we can have a look on your proposal.

[d00616]

@Eurbaix said in Better security without the need of a cryptoprocessor: out-of-band authentication:

A good alternative, and I'm surprised its not more popular in MySensor, is STM32F103, basically the same price as an arduino mini pro, no hardware encryption or secure memory but plenty of CPU and memory for software encryption, which should be OK as long as blacklisting a sensor is easy.

I think in the near future you can see more Sensors based on nRF5 (Cortex-M0/4 and integrated nRF24 compatible radio) or SAMD platform.

Both SAMD and STM32 platform are not ready for battery powered sensors. Sleep() is not implemented. I think SAMD and STM32 are no good choices for asymmetric cryptographic operations because they don't have a hardware random number generator. This requires additional hardware like the ATSHA204.

There are another interesting MCU, the TI CC1350. Arduino and MySensors support is missing at the moment, but this MCU is an dual band wireless controller.

Also, what about assymetric encryption, which would perfect here?

The nRF5 and CC1350 MCU are supporting AES-CCM in hardware. Other MCU with integrated radio seems to supporting AES-CCM or AES-CCM* In my opinion the symmetric encryption should be AES-CCM. Hashing should be based on AES-CCM.

The asymmetric encryption is not so easy to answer. Hardware support is rare. The upcoming MCU nRF52840 has a CryptoCell 310 hardware included. This hardware supports RSA and some ECC algorithm. In my opinion we should use ECC to keep the RAM requirement low.

For ECC there are some implementations like micro-ecc or curve25519-donna. I think the curve should be selected carefully.

[Anticimex]

@Eurbaix regarding asymmetric encryption, do you have something special in mind?
And I also have a few questions on your original proposal;

GW generate random PSK for every new node? How? What prevents the GW from accepting "rogue" nodes and adding them? Inclusion mode?

After the node has authenticated with the GW and received a communication token, is it not possible for a different node to use that token (since the PSK can be assumed to be known as it is distributed OTA from the GW, right?) during the time window he token is valid?

Your proposal is interesting but let's discuss it some more

Edit: I also find the term PSK a bit misleading if the GW calculate and distribute them (or I misunderstood you). PSK suggests it is pre-shared and hence not distributed OTA (and therefore not subject to eavesdropping).

[Sergio Rius]

I was from two days ago thinking on a system for making the same proposal, and arrived to the same conclusion.

@Anticimex I would recommend to take just one step in the direction we decide is correct. We are forgiving here the controller. The controller can calculate keys during the pairing process. Expecting the controllers to adapt to this would be presumptuous, but we have community handled controllers that could make this job if we sacrifice the "temporary" nature of the key/token for a while.

The key should be doing things compatible with the path we want to take.
All of this, thinking on not changing supported mcus platforms.

[Anticimex]

@Sergio-Rius I disagree. Controllers should NEVER be involved in the OTA security protocol. Then the OTA security is dependent on the controller, and we have a LOT of different controllers with various levels of support.

[Sergio Rius]

I'm very interested on this and I would want to contribute. I think I could be of some help if you tell me where to follow this subject

[Anticimex]

@Sergio-Rius This thread is as good as anyone. But just leave the controller out of this.

Also, generically from a key distributing and encryption point of view, remember that we are dealing with a mesh network.
If we use node specific keys and encrypt the messages based on this key, any repeater-nodes have to be able to convey the messages as well.

[Sergio Rius]

@Anticimex you're probably right, but could a "security protocol and messaging" be defined. One that could be selectively implemented by controllers. I mean as a way of decoupling the key/nonce generator like a radius server.
You could implement a security node Independent from the radio or gateway chosen.

[Anticimex]

@Sergio-Rius I don't like it. I don't think any trust should be placed on the controllers. And how would it work if you have a multi-controller setup if one controller starts jabbering about things other controllers have no clue about?

[Sergio Rius]

@Anticimex I didn't mean it to be in the controller. I just talked about a key generator (and perhaps storage) node, that could be on the network and recognized by the gateway or/and the repeaters.
That should be a way of only implementing one time the most expensive components and decoupling for compatibility.

Of course all of this are ideas and all need time to studying.

[Anticimex]

@Sergio-Rius Oh, I just read your "selectively implemented by controllers" and thought that it should be up to the controller to use that.
Well, a dedicated key storage node is a thought, although as things are with and without security currently, the use of atmega328p based GW:s is coming to an end.
So we should not base future security functionality on basis that the GW is performance limited.
Me and @d00616 have been discussing a scheme where the GW generates a root key and distribute node specific keys. But there are many aspects to cover still, one such is handling of repeater nodes, and we are also constrained in time for how much time and effort we can spend on this at the moment. There is already a security scheme in place and although it is not perfect, it is adequate from a security point of view.
And personally, I currently simply don't have the time to spare to design and implement something newer right now. Suggestions and PR:s are always welcome. That's how I started out, others are welcome to do the same
Although since then I have been elevated to some form of security responsible, so I will for that sake, place some pointers to what a new security scheme need to cover:

• Authentication
• Obfuscation
• Handle node-jumping (repeater nodes)
• Support resource limited nodes (not necessarily GW:s)
• Not transmit sensitive data OTA
• Be simple to use
• Be well documented
• Either support key protection or simple key revocation (preferably on a per-node basis)

That's all I can think of right now

[d00616]

@Anticimex said in Better security without the need of a cryptoprocessor: out-of-band authentication:

That's all I can think of right now

That's most complete.

Looking at the most modern MCU's (nRF51, nRF52, CC1350, EFR32BG13P733) with integrated radio mostly AES-CCM is available as hardware component. With AES-CCM encryption and authentication is available. AES-CCM is part of the BLE specification. I think this type of MCU's are the future and the time of 8 Bit MCUs with external radio modules are mostly over. The nRF5 MCU's are compatible with MySensors starting with release 2.2.

In my personal opinion AES-CCM is a good choice for battery powered nodes, but I think it's no problem to accept other security schemes.

[Anticimex]

@d00616 I agree. It is good to base any scheme of something that at least some HW can provide already. As such, I don't think the actual algorithms is the key issue though. It is the routing I mostly worry about. If we do full encryption and expect the mesh network to be working, key needs to be shared at least with the repeaters and the endpoint.
But it could be that we settle for leaving the message header unencrypted, but then we need to also handle padding of the payload (algorithm specific). Not a huge issue but something to consider.
Also, the payload sizes do have an effect on how to do this. But there are huge changes planned for version 3 of the library when it comes to protocol and payloads, so we also need to decide if the security layer sits close to the transport (RF specific) or higher up in the stack.
I for one, feel that what we primarily want to protect is the payload. But perhaps also certain parts of the header (like sensor type, etc). We should probably align this with other core team members looking into protocol changes, so that we separate routing parts in the header from "semi-payload" data (sensor type, etc).

[Sergio Rius]

@Anticimex With that scheme, what happens when the GW fails?
Once keys are generated should they be saved on nodes and locked like now?
Could it be possible for a malicious user to hang the GW and supplant it, or take control of a far part of the network?

I really like the idea of those new platforms. But I wonder what problems would arise if they're tired to an specific radio. I almost can't use the 2.4ghz band, for example.

[Anticimex]

@Sergio-Rius if the GW fails your hub is out and your controller isolated from the sensor network.
If you have a different use case, just present a proposal and ideally a PR. Just leave the controller out of the equation.
What would be different in this situation from your key storage node failing?

[Anticimex]

@Sergio-Rius regarding tied to a specific radio, I don't think I have ever suggested such a thing?
When it talk transport, it is still in the library context. Not the physical layer which I consider the radio to be.

[Sergio Rius]

I was only presenting possible situations for discussing.
I'm analyst (processes, reliability and security). Perhaps I'm too anal with my profession. Also I'm not too good expressing myself in English.
I'm so sorry if I'm a hassle.
I'm on holidays, I should better come back to work

[Anticimex]

@Sergio-Rius you are not a hassle. And I am sure as a analyst you appreciate challenging and be challenged
I suggest if we should be a bit mot concrete, that you if you would like, describe your proposal or thoughts in the context of the bullet list I presented above.
For sure those bullets can all be addressed on various ways, but any security solution should adresse them all (and no, the proposal does not have to be fully documented from the start :))

[Eurbaix]

@Anticimex There are, in fact, three different keys in my proposal:

• A initialization PSK which should be stored in EEPROM, not the firmware, so it can be erased after the sensor registration. This PSK is common to all new sensors but only used once.
• A sensor PSK, which is sent over the air during the registration, encrypted with the initialization PSK.
• The sensor PSK is used to encrypt the token request and answer so another sensor cannot "read" the token since it doesn't have the same sensor PSK.
• The token is then used as an authentication and encryption key during the rest of the communication.

So here's a few more details about how it would work:

• When firmware is initially loaded on a new sensor, the initialization PSK is also loaded in the sensor EEPROM.
• The GW needs a "WPS" button (as modern routers have)
• Just before powering-up a sensor for the first time, press the GW's "WPS" button, the sensor will accept a connection with the initialization PSK for a few seconds (10-15s) and, along the normal sensor "registration", also send a new key to the sensor. The sensor will then erase the original PSK and replace it with this "sensor PSK", which is specific to this sensor. Since this original PSK is only used during the initial registration then deleted, it will only exist in the sensor memory while the sensor is in a secure location. In case this PSK is compromised, you only need to create a new key in the gateway, that will then be used when you load new sensors.
• This sensor PSK is then used to encrypt the token request since the GW knows each sensor key. The token is sent encrypted with this sensor PSK so another sensor cannot "read" this token. If the token is requested for a sensor-to-sensor communication, the GW will also send the token to the second sensor, encrypted with the second sensor PSK.
• For the rest of the communication (sensor to sensor, or sensor to GW), this token becomes the encryption key and authentication key.

This way, a common PSK is only used during the initialization and can only be used for initialization. This PSK is not accepted for regular communication with the GW (or other sensors). Also, a rogue sensor who have this initialization PSK can only request a "sensor PSK" when the WPS button is pressed. The chance of a rogue sensor sending a initialization request just after the WPS button has been pressed is minimal (except if you routinely initialized dozens of sensors everyday). If fact, the chances are low enough that the initialization PSK is even optional, in my opinion. After all, router use WPS without initialization PSK and this approach is considered reasonnably secure.

Last, if a "sensor PSK" is compromised, you only have to erase this entry in the sensor PSK table on the GW and the rest of your sensor network will be secure. If we are not using a cryptoprocessor to store the sensor PSK, the risk of the sensor PSK to be read in a stolen sensor exist, but the fact that sensor PSK are individuals make this risk easier to mitigate (as long as you notice that a sensor has been stolen of course).

[Anticimex]

@Eurbaix sounds good. Just a few comments.

• WPS is considered broken (but I have not read up on the details, I am not sure it is due to the theory of operation as you outlined)
• if all communications are encrypted, is it the full payload or partial? Which algorithm do you suggest? Currently, we are limited to a full payload length of 32 bytes. Some bytes of these are for routing info so that repeater nodes can relay the message. I suppose these repeaters will be unable to decrypt messages not ment for them so at least the routing bytes need to be sent in plain text. And the algorithm block size might then be an issue given the current limitations of the payload size.

All in all I think the suggestion is sound and much in line with what we have already been theorizing around in the core team.

[Eurbaix]

@Anticimex A few additional points to address the rest of the conversation:

• Since we are in a mesh network, I believe encrypting the routing information is not really an option as it would mean decrypting and reencrypting at each hop. Beside, if not using a common PSK, managing key exchange would become a nightmare. So, the security would only be end-to-end, with the intermediate node seeing the routing information (sensor IDs) but not the payload (sensor type and data).
• I agree that security should be handled entirely by the gateway and sensors, as it is the only nodes we fully control the firmware. Involving any external component like the controller would be this a nightmare to maintain since we do not have full control on the firmware evolution of anything outside the GW and sensors.
• Although new sensors will probably not be based on 8bits Atmegas, there are plenty of existing sensors that use 8bits Atmegas so I believe we should aim to implement a fully software solution, light enough to run on an 8bit Atmega. In my proposal, the only modification required would be to add a button on the gateway so it can still be easily implemented in an existing network. HW support (encryption or key generation) would be optional but I would keep the option to simply generate a key from an floating analog input.
• As for the encryption, I would simply choose one that is supported by most hardware platforms but light enough to be able to implement software encryption in existing 8bits sensors, although I'm not sure there is still enough flash available to add software encryption on legacy sensors.

Also note that my proposal does not aim at absolute perfect security, simply something that would allow to easily revoke a node so we don't need a cryptoprocessor to store authentication/encryption keys.

[Anticimex]

@Eurbaix your proposal is in my opinion fully adequate from a security point of view.
As for encryption on "legacy" hardware we already have a sw AES crypto driver (although weak).
The button on the GW actually already exist for "inclusion mode". And we also already have a software equivalent that is triggered from the controller for those who don't have or don't want a button on the GW.
A lightweight security personalizer should be enough to store the initial PSK in the nodes. For those who have used the current signing solution, that should not be a deterrent. Some new users might be annoyed by it but I don't see a good alternative. Sending it OTA is a big nono. And having it as an optional FW defined static is bad practice in case the FW leaks (even though we have inclusion mode).
If you want we can set up some shared document to flesh out the implementation details for this?
@d00616 do you have any additional input?

[Eurbaix]

@Anticimex I believe the difficulty is not in making "out-of-band" secure, as it has been used and reviewed many times from a security point of view. My concern was more: can we keep it simple enough so it could be deployed on existing 8 bit platforms.

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.

As for packet size limitation, that's one of the reason I went with short TTL tokens that also act as nounce. The tokens are sent in a separate packet from the gateway so there is no need to exchange nounce for the rest of the communication as long as the token TTL is short enough. I would guess 5 or 10 packets using the same token should not be enough for a brute force attack. This leaves the entire packet free for payload (minus routing information), the usable payload is in fact the same as in non-secured comms.

Last: Yes, a shared document would be a good idea so we don't have go through all the posts to remember what we already discussed. I have Google Docs and One Drive accounts, but can also register on another collaboration platform.

[Anticimex]

@Eurbaix I know. Hence my connection to the existing security personalizer which does the exact same thing.
The packet size concern is more about that certain crypto algorithms produce a ciphertext of a specific size, which had to fit in the message frame. So if parts of the buffer is in plain text, some limitation is put in the allowed size of the ciphertext (and the original plaintext which could produce a ciphertext spanning multiple crypto blocks which then would not fit the message buffer). But this is specific to the chosen algorithm.

I'll look into facilitating some document sharing later. A bit busy right now and out of computers reach.

[Eurbaix]

@Anticimex You raise a good point regarding cyphertext size. I was thinking initially AES 128 would be a good choice but, if routing is in clear, the encrypted part of the packet is now reduced to 16 bytes. Something to look at... or may be 16 bytes is acceptable in the use case scenario of MySensors since not all information is necessarily sensitive.

Also, what are you referring to when you say "security personalizer"? I don't remember something with this name in the current security in MySensors?

P.S.: No rush for the document sharing. It will take a while anyway to come up with something that covers all the basics so a few days more or less won't make a real difference.

I

[Anticimex]

@Eurbaix security personalization is the corner stone of the current signing solution you can't use it without personalization (except for the simplified security flag on the development branch).

[Eurbaix]

@Anticimex Well, it seems I missed something important in the current signing implementation. I'll have a second look.

[d00616]

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.

[Sergio Rius]

@Eurbaix said in Better security without the need of a cryptoprocessor: out-of-band authentication:

There are, in fact, three different keys in my proposal

Here you're basically proposing a handshake system, but, what you talk about in the first section of points, are you referring to the GW or nodes?
I don't see the need of this first key. Anything that identifies the sensor, like it's name would serve the same purpose. Or I understand it wrong?

I think that if you have two networks/channels, as I have, sensors from the two networks would have different keys. Then if we wanted to add a new sensor to one of the networks, what prevents the GW1 to see a sensor from the second network (that may have connectivity issues, alias it may be asking for reconnection) as a new sensor?

[d00616]

For an mixed network with classic hardware and new hardware we can work with two address ranges. This is possible for nRF networks.

[Sergio Rius]

I see, but I always try to address security and script burning in general trying to arrive an scenario where programming knowledge isn't necessary. Like choosing from a web page the sensor I want, connecting it to the computer via usb and letting the page/program/whatever to do it all.

WPS was considered insecure because there where ways of wirelessly force the router to start the WPS procedure. Then added a password to the WPS process and now they're removing this support, whats I think it's an error.

[Sergio Rius]

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

[Anticimex]

@Sergio-Rius if the message is fully encrypted, how would the repeaters know how to route?

[Sergio Rius]

@Anticimex It may not be fully encrypted, but having description packets. Other protocols do like this.
I understand that the repeaters should only care for messages directly sent to them. Like a remote-button to a garage door node. Other messages should then be relayed to the network. I think that is more productive and increase performance.

Perhaps I miss a more complex scenario.

[Anticimex]

@Sergio-Rius no that is correct. But repeaters to understand if a message is directed for them or to be repeated, part of the message need to be in plain text and then we need to mind the crypto algorithm vs payload limitations.
There are many solutions to this, I am just saying that it has to be taken into account as well.
This is not an issue when encryption is handled by the physical layer (the radio itself) but then security is specific to the radio. And we don't want that.

[Eurbaix]

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

[Sergio Rius]

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]

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

@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

[Anticimex]

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]

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

[Eurbaix]

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

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

[Anticimex]

Actually, the block size is 16 bytes also for 256 bit AES keys.

[Koresh]

@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 Do you work for Nordic? :trollface:

The nRF51 has an better range compared with the nrf24

16meters instead of 15 meters? 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

So... I think we shouldn't hurry to bury the 8bit MCU's without adequate and well tested replacement.

[Anticimex]

@Koresh well, no offense, but the platforms the boards @d00616 mentioned are based on aren't exactly cutting edge technology either. And a hell of a lot more modern than antiquated atmga328p:s.

[Eurbaix]

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

[Eurbaix]

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

@Eurbaix hm, yes that is correct. And good point on the garbage attack. Even if the routing info goes in plain text, the target node need to validate the sanity of the encryption before blindly trusting the data.

[d00616]

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

@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