Closed GameTec-live closed 1 year ago
We could do some workaround, it’s a known issue, but the connection will be insecure, at least until first binding.
https://devzone.nordicsemi.com/f/nordic-q-a/13314/nrf51822-secure-connection-with-password
Hello how do you connect to it? Mine just can't seem to pair.
If the possibility of being sniffed for BLE communication is not considered, adding a logic that does not allow communication without sending a password to all BLE APIs is a good solution.
If the possibility of being sniffed for BLE communication is not considered, adding a logic that does not allow communication without sending a password to all BLE APIs is a good solution.
And it is also easy to implement.
The API I expect to implement:
This sounds a bit too basic. BLE sniffing is a thing, much easier than with Bluetooth and likely to happen if you bring your toy to hacking conventions ;) Why not using BLE LESC as in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Fble_sdk_app_gls.html ?
This sounds a bit too basic. BLE sniffing is a thing, much easier than with Bluetooth and likely to happen if you bring your toy to hacking conventions ;) Why not using BLE LESC as in https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_nrf5_v17.0.2%2Fble_sdk_app_gls.html ?
I remember that LESC is implemented based on pairing, so we need to consider some things.
How to pairing? Is it easy to implement for firmware and Client?
If pairing is not considered, is it reasonable to manually encrypt data in communication through AES?
The binding operation is quite complicated, so I am considering UX issues. If we can solve various problems that may occur during the binding and unbinding process, then I do recommend using pairing to achieve encrypted communication too.
a) use some Balanced PAKE to authenticate with a password, without risk of sniffing and offline bruteforce on it. At the end of the PAKE a per-session shared secret will be available. b) derive AEAD keys from the shared secret, e.g. with some HKDF c) use keys in some AEAD like AES-GCM
It might be possible to limit the use of AES-GCM to the really sensitive info like dumps rather than encrypting systematically all communications.
At present, the community needs to solve two security issues:
In theory, simple secret key verification to unlock the device can solve the security problems described above, but it cannot solve the problem of secret keys or dump data being sniffed. If need to solve this problem. which is best solved by pairing.
@doegox
I have reviewed some documents and found that the pairing process of BLE will be automatically taken over by the system. Assuming we can set and get the pairing key through USB, and clear the pairing status through USB. This pairing process will become incredibly simple. The APP only needs to consider creating a ble connection. During the BLE link creation process, the system will pop up a pairing dialog(if it has not been paired before), and users only need to enter the key of USB communication settings to pair.
If the user changes their phone and needs to pair again, they can clear the pairing status through USB.
I have reviewed some documents and found that the pairing process of BLE will be automatically taken over by the system. Assuming we can set and get the pairing key through USB, and clear the pairing status through USB. This pairing process will become incredibly simple. The APP only needs to consider creating a ble connection. During the BLE link creation process, the system will pop up a pairing dialog(if it has not been paired before), and users only need to enter the key of USB communication settings to pair.
oh, thats neat, so like the "enter 5 digit pairing code" thing, which in this case we get via usb?
I have reviewed some documents and found that the pairing process of BLE will be automatically taken over by the system. Assuming we can set and get the pairing key through USB, and clear the pairing status through USB. This pairing process will become incredibly simple. The APP only needs to consider creating a ble connection. During the BLE link creation process, the system will pop up a pairing dialog(if it has not been paired before), and users only need to enter the key of USB communication settings to pair.
oh, thats neat, so like the "enter 5 digit pairing code" thing, which in this case we get via usb?
Yes
If the user changes their phone and needs to pair again, they can clear the pairing status through USB.
can you pair multiple phones at the same time? some people (i dont, but some), have multiple phones / phone and tablet, etc...
I read somewhere that nRF SDK can track sth like 8 phones but not more. Sounds enough, but to be tested
I read somewhere that nRF SDK can track sth like 8 phones but not more. Sounds enough, but to be tested
that should be enough for everyone. Id say 2 Devices is more or less a must (phone and tablet or private phone and work phone, etc)...
You should be able to provide LESC with either a button press (if no pwd was defined firstly via USB) or with the pwd (which provides even MitM protection during pairing)
You should be able to provide LESC with either a button press (if no pwd was defined firstly via USB) or with the pwd (which provides even MitM protection during pairing)
BTN is a optional item.
So you could do: If no password defined? Ask user to press button to pair. Password defined via usb? Pair with password.
Thats good?
And ig if its paired once you dont need to do it again unless you unpair?
And ig if its paired once you dont need to do it again unless you unpair?
Yes
So you could do: If no password defined? Ask user to press button to pair. Password defined via usb? Pair with password.
Thats good?
Yes
while at it, maybe provide fcts to rename the device name advertised over BLE
while at it, maybe provide fcts to rename the device name advertised over BLE
that would be useful, indeed... (Chameleon Nickname XD)
Implemented by ae6df052f571901f66cd9c6e267756a1970aab79
The current implementation of BLE / BLE UART allows anyone to connect and piar to any chameleon without authorization. This potentially allows someone to without authorization wipe cards or "steal" cards containing sensitive data from the device.
Suggestion to solve this problem: Either password protect (eg not respond to commands until password is sent) or require the confirmation on hardware via a button press or similar to allow connecting / pairing.