User's Manual

Enhanced Class 1 Bluetooth v2.1 Module
User’s Guide
Americas: [phone] Option 2
Europe: [phone]
Hong Kong: [phone]
www.lairdtech.com/wireless
177
CONN-GUIDE-BT740_v0.2
14.7.2 Authentication and Encryption
The module and firmware is BT v2.1 compliant so it uses Simple Secure Pairing (SSP) to authenticate
devices to trust, and only invokes a legacy pairing procedure when a peer device is v2.0 or older.
It is not possible to configure the unit to be only capable of legacy pairing and still have v2.1 approvals.
The purpose of pairing, whether legacy or SSP, is to generate the same random 16 byte key at both ends.
The key is then used in subsequent connections for authentication and encryption.
14.7.3 Legacy Pairing
A legacy pairing procedure is automatically used when pairing is initiated (by either end) and the peer is
approved to v2.0 and below.
14.7.3.1 Outgoing
To initiate a pairing, the host shall submit the command “AT+BTW<bd_addr>” to which it gets an
immediate OK or ERROR response. The host then waits for a “PIN ? <bd_addr>” response to which it
responds with the command AT+BTK=”pincode”.
When the pairing procedure completes, the module sends to the host the following asynchronous
response: “PAIR N <bd_addr>”. N is 0 when the pairing is successful, 1 for a timeout, and 2 for a generic
failure (for example, mismatching pincode).
14.7.3.2 Incoming
The module has to be in at least connectable mode for it to participate in a pairing initiated from a legacy
peer. The first indication the host gets that an incoming legacy pairing has initiated is when it receives the
asynchronous response “PIN ? <bd_addr>”. To this, the host responds with a shared pincode conveyed
in the command AT+BTK=”pincode”.
When the pairing procedure completes, the module sends to the host the following asynchronous
response: “PAIR N <bd_addr>”. N is 0 when the pairing is successful, 1 for a timeout, and 2 for a generic
failure (for example, mismatching pincode).
14.7.4 Simple Secure Pairing
Simple secure pairing was introduced in v2.1 of the Bluetooth specification to simplify the pairing
procedure so it did not rely on a pre-shared pincode and so that all connections are forced to be
encrypted. Unlike pre v2.1 devices, it is not possible to create connections without encryption.
Simple secure pairing uses the Diffie-Hellman public/private encryption methodology to expedite a
common 128 bit key at both ends. This eliminates the need for pre-shared pincodes but introduces the
‘man in the middle’ (MITM) attack vulnerability.
To address the MITM vulnerability the concept of verification via a 6 digit passcode was also added. A 6
digit passcode was selected, as that reduces the probability of a random MITM attack succeeding to one
in a million.
The 6 digit passcode is NOT a pre shared code, but is a random 6 digit artefact derived from the Diffie-
Hellman calculations such that knowledge of that 6 digit number by an attacker cannot result in back-
calculation of the 128 bit key that generated.
For a user to interact and process the 6 digit passcode the SSP procedure requires that each Bluetooth
device have an I/O capability which is one of the following: