6 Replies Latest reply on Sep 1, 2017 12:29 PM by epr_1639216

    Security without bonding




      I am now working on a project in which there is a client and up to eight servers from which the client has to read information.


      What concerns me is the security aspect of this project. Given that there is no support for more than four devices for the client to bond with we have to use pairing instead of bonding which means that there will be an exchange of keys with every connection, so someone could be reading that sensitive data. Connections will happen constantly.


      Another thing is that the servers have no input/output capabilities so the short term keys are always going to be zeroes.


      How can I securely exchange information with these two constraints (Bonding limit and no input/output capabilities)? I know it is a long stretch but is there a way to do so?


      Both servers and client are BLE 4.1.



        • 1. Re: Security without bonding

          I can think of few work-arounds but cannot comprehend the robustness of these solutions:

          1) Fixed passkey or Out Of Band Pairing.

          2) Custom handshake upon connection before data exchange

          • 2. Re: Security without bonding

            Another thing is that the servers have no input/output capabilities so the short term keys are always going to be zeroes.

            I'm confused why not having IO would cause a STK of 0. Can you explain this a little more?


            As sujayy_46 said, you could try

            1) OOB Pairing

            2) Custom handshake upon connection before data exchange (This could be as simple as implementing the bonding process yourself, rather than having the Cypress API handle it for you)

            • 3. Re: Security without bonding

              Thank you so much for the responses.


              Well, the short term key (STK) would not be composed of 0s, but the temporary key (TK) would be, as the just works pairing method would have to be implemented. This, I believe, is the standard procedure when it comes to the just works paring mechanism specified by the Bluetooth SIG.

              • 4. Re: Security without bonding

                The problem here is that using OOB would increase the price of the end product, and also, I'm not sure about how secure using a fix key would be.


                I think that implementing a security feature by myself may not be a good idea either as I'm not qualified to do that.


                Of the two solutions I think the first one would be the way to go, but again, I'm still open to suggestions.

                • 5. Re: Security without bonding

                  That seems odd that the keys would default to all zeroes; I would assume that there would be some sort of negotiation on the connection to establish the key to use for that connection, which would then be put into the TK for use for that connection.

                  I'll trust that you are correct as I don't have any knowledge otherwise

                  • 6. Re: Security without bonding

                    I agree with not implementing security features unless necessary, but when the only other options are add cost to the project, or rethink it....

                    Potentially, if you are BLE application handy, then you could manually set the TK using PRNG/RNG or some other method of randomization on the devices. Obviously, this would go back to implementing a security feature yourself, but the only other option afaik would be the OOB pairing.

                    Here is an excellent explanation of the general setup for security: BLE security and changing services dynamically - Question | Mbed

                    Ultimately, you want the TK to only be known between the two devices, but without having it setup/stored beforehand, then you will need to negotiate it with the other side in some way or another. Generally, to accomplish this, "secure" connections will create asymmetrical key pairs that only allow the holder of the "private" key to decrypt the messages. Since this method of security doesn't rely on the medium, it would theoretically work for BLE as well. But, it would involve building your own security implementation....