Bluetooth Encryption

[Neodym]

Hello,

can anyone tell me something about the security level of the connection like it is made in the Heart Rate Sensor Example. Is the connection encrypted or can everyone sniff the data?

Best regards

[Tim]

An encrypted connection does not always mean that everyone cannot sniff the data. If it uses Just Works then it's encrypted, but everyone can sniff the data, as long as they also sniff the pairing and bonding of course.

[Neodym]

If i understand right, it means that the data its always encrypted. But its possible to encrypt it when the intruder sniff the paring or bonding process.

[Tim]

No, the data may be unencrypted, it has to be configured in some way to be (or not to be) encrypted, that's all in Nordic's examples and tutorials. But if it has to be encrypted, and if the pairing method is Just Works, then someone who listens during the pairing/bonding could totally decrypt the transfer of data, even after a disconnection and reconnection.

[bjorn-spockeli]

Hi Neodym,

the Heart Rate Sensor example in the SDK does not enrypt the link and all data is sent over the air in plain text, i.e. everyone can sniff the data.

If you want to encrypt the link you will have to pair and bond with the device. In Bluetooth 4.0 the following paring/bonding methods may be used

• Just Works: STK generated on both sides, based on packets sent in plain text. No security against MITM attacks
• Passkey Entry: One Peer display randomly generated, six-digit passkey that is entered on the other side. Provides protection against MITM attacks
• Out-of-Band(OOB): Additional data transferred by other means than the BLE radio, e.g. NFC. Provides protection against MITM attacks

However, as @timf(Tim) states there are paring/bonding methods, like Just-Works that does not protect against so called "Man-in-the-Middle attacks".

Bluetooth 4.2 introduced LE Secure Connections which uses the Elliptic Curve Diffie-Hellmann(ECDH) key agreement protocol that allows two parties, each having an elliptic curve public–private key pair, to establish a shared secret over an insecure channel, i.e. it is not possible to sniff the encryption key.

The ECDH key exchange is added to the the bonding methods mentioned above and an additional method called Numeric Comparison has been added to the list of available bonding methods.

The S130 v2.0.0 and S132 v2.0.0 (and newer) Softdevices both support LE Secure Connections and you can find Message Sequence Charts for the different bonding methods on the Nordic Infocenter. I have added a couple of links below:

LINKS:

S130 Peripheral Security Procedures

S130 Central Security Procedures