The BLE data is encrypted using AES-CCM. the TLS1.3 removed AES-CCM from the cipher-suits due to security issue.
My question : why don't they encrypt the BLE using chacha20-poly1205 ? is it because there is no hardware support for chach20-poly1305?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
TLS 1.3 has not removed AES-CCM, and it is not insecure. The issue with CCM modes is simply that they are very inefficient, requiring two invocations of the block cipher for every encryption of a single block. The only reason anyone would want to use CCM is if the device in question supports hardware-accelerated AES encryption and does not support hardware acceleration for components of GCM, or because of extreme space constraints that make re-using AES code better than implementing GCM.
The reason Bluetooth is using AES is because it was very important for this version to be fully FIPS-compliant. FIPS is a US government standard that specifies, among other things, the ciphers and modes of operation that are approved for government use. AES and CCM are part of FIPS, but ChaCha20 and Poly1305 are not. Remember that the previous versions of Bluetooth did not even use AES. Instead, they used their own homebrew stream cipher called E0, which turned out not to be particularly secure. It is vulnerable to a variety of attacks, in particular known-plaintext attacks.
An answer on our sister site explains this with more authority:
I know from being in a meeting that FIPS-140 validation for Bluetooth was an important conversation with the Bluetooth LE spec, which is why AES was added. I can only assume that AES was not used in the original ICs due to cost on the hardware side. Looking at 130nm dies (so, back in the day), AES would cost me about 0.03 USD in area. Just by guessing the area of E0, I would say it's 0.01 USD, so it must have mostly been an economic consideration during the time of early adoption.