RfidResearchGroup / ChameleonUltra

The new generation chameleon based on NRF52840 makes the performance of card emulation more stable. And gave the chameleon the ability to read, write, and decrypt cards.
https://chameleonultra.com
GNU General Public License v3.0
922 stars 153 forks source link

Insecure BLE connection / pairing process (Big ish security issue) (Allowing unauthorized pairing) #39

Closed GameTec-live closed 1 year ago

GameTec-live commented 1 year ago

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.

nieldk commented 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

Markg546 commented 1 year ago

Hello how do you connect to it? Mine just can't seem to pair.

xianglin1998 commented 1 year ago

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.

xianglin1998 commented 1 year ago

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.

xianglin1998 commented 1 year ago

The API I expect to implement:

  1. Set and get the ble key through the usb serial port
  2. During ble communication. Judge whether to unlock. Send the secret key to unlock.
doegox commented 1 year ago

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 ?

xianglin1998 commented 1 year ago

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.

  1. How to pairing? Is it easy to implement for firmware and Client?

  2. If pairing is not considered, is it reasonable to manually encrypt data in communication through AES?

xianglin1998 commented 1 year ago

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.

doegox commented 1 year ago
  1. To be seen how 1. is easy to do or not based on their examples, honestly I've no idea.
  2. If manually I'd suggest sth like this:

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.

xianglin1998 commented 1 year ago

At present, the community needs to solve two security issues:

  1. Prevent hackers from connecting to Bluetooth at will, jumping the device to boot and then flashing a malicious boot to brick the device.
  2. Randomly read dump and nickname

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

xianglin1998 commented 1 year ago

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.

xianglin1998 commented 1 year ago

If the user changes their phone and needs to pair again, they can clear the pairing status through USB.

GameTec-live commented 1 year ago

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?

xianglin1998 commented 1 year ago

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

GameTec-live commented 1 year ago

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

doegox commented 1 year ago

I read somewhere that nRF SDK can track sth like 8 phones but not more. Sounds enough, but to be tested

GameTec-live commented 1 year ago

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

doegox commented 1 year ago

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)

xianglin1998 commented 1 year ago

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.

GameTec-live commented 1 year ago

So you could do: If no password defined? Ask user to press button to pair. Password defined via usb? Pair with password.

Thats good?

GameTec-live commented 1 year ago

And ig if its paired once you dont need to do it again unless you unpair?

xianglin1998 commented 1 year ago

And ig if its paired once you dont need to do it again unless you unpair?

Yes

xianglin1998 commented 1 year ago

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

doegox commented 1 year ago

while at it, maybe provide fcts to rename the device name advertised over BLE

GameTec-live commented 1 year ago

while at it, maybe provide fcts to rename the device name advertised over BLE

that would be useful, indeed... (Chameleon Nickname XD)

xianglin1998 commented 1 year ago

Implemented by ae6df052f571901f66cd9c6e267756a1970aab79