BLE pairing (explained earlier in this chapter) starts by a device initiating a Pairing_Request and exchanging capabilities, requirements, and so on. Nothing involving security profiles occurs at the initial phase of a pairing process. For that matter, the pairing security is similar to the BR/EDR four methods (also known as association models), but differs slightly in Bluetooth BLE 4.2:

• Numeric comparison: This is the same as Just Works, but at the end, both devices will generate a confirmation value that is displayed on the host and device screens for the user to validate the match. 
• Passkey entry: Similar to BR/EDR mode, except that the non-initiating device creates a random 128-bit seed called a nonce to authenticate the connection. Every bit of the passkey is authenticated separately on each device by generating a confirmation value for that bit. The confirmation values are exchanged and should match. The process continues until all bits are processed. This provides a fairly robust solution for MITM attacks.
• Just Works^TM : After devices exchange public keys, the non-initiating device creates a nonce to generate a confirmation value Cb. It transmits the nonce and Cb to the initiating device, which in turn generates its own nonce and transmits it to the first. The initiating device will then confirm the authenticity of the non-initiating nonce by generating its own Ca value which should match Cb. If it fails to match, the connection is corrupt. This again is different to BR/EDR mode.
• Out-of-band (OOB): This is the same as in BR/EDR mode. It will only protect from eavesdropping and MITM if the OOB channel is secure.

In BLE, (as of Bluetooth 4.2) key generation uses LE secure connections. LE secure connection was developed to resolve the security hole in BLE pairing that allowed an eavesdropper to see the pairing exchange. This process uses a long-term key (LTK) to encrypt the connection. The key is based on an elliptical-curve Diffie-Hellman (ECDH) public key cryptography. Both the master and slave will generate ECDH public-private key pairs. The two devices will exchange their public portion of their respective pairs and process the Diffie-Hellman key. At this point, the connection can be encrypted using AES-CCM cryptography.

BLE also has the ability to randomize its BD_ADDR. Remember, the BD_ADDR is a 48-bit MAC-like address. Rather than a static address for the value, as mentioned earlier in this chapter, there are three other options:

• Random static:  These addresses are either burned into the device’s silicon during manufacture or generated when the device power cycles. If a device routinely power cycles, a unique address will be generated and this remains secure as long as the frequency of power cycling is high. In an IoT sensor environment, that may not be the case.
• Random private resolvable: This addressing method can only be used if the Identity Resolving Key (IRK) is exchanged between the two devices during the bonding process. The device will use the IRK to encode its address into a random address in the advertisement packet. A second device that also possesses the IRK will convert the random address back into the authentic address. In this method, the device will periodically generate a new random address based off the IRK.
• Random private non-resolvable: The device address is simply a random number and a new device address can be generated at any time. This offers the highest level of security.