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

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

  • Contest Winner

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

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

  • Contest Winner

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

  • Contest Winner

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

  • Contest Winner

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

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

  • Contest Winner

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

  • 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 😉

  • Contest Winner

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

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

  • Contest Winner

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

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

  • Contest Winner

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

  • Contest Winner

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

  • Contest Winner

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

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

  • Contest Winner

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

  • Contest Winner

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

  • 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 😉