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