Bluetooth v4.1 On Pronto 1.4.1 Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Bluetooth® v4.1 on Pronto 1.4.
1 Overview
80-NM498-1 A
Confidential and Proprietary – Qualcomm Technologies, Inc.

Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm or its subsidiaries without the express approval of Qualcomm’s Configuration Management.

NO PUBLIC DISCLOSURE PERMITTED: Please report postings of this document on public servers or websites to: [email protected].
Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm or its subsidiaries without the express approval of Qualcomm’s
Configuration Management.
Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others without the express written permission of
Qualcomm Technologies, Inc.
Qualcomm reserves the right to make changes to the product(s) or information contained herein without notice. No liability is assumed for any damages arising directly
or indirectly by their use or application. The information provided in this document is provided on an “as is” basis.
This document contains confidential and proprietary information and must be shredded when discarded.
Qualcomm is a trademark of QUALCOMM Incorporated, registered in the United States and other countries. All QUALCOMM Incorporated trademarks are used with
permission. Other product and brand names may be trademarks or registered trademarks of their respective owners.
This technical data may be subject to U.S. and international export, re-export, or transfer (“export”) laws. Diversion contrary to U.S. and international law is strictly
prohibited.
Qualcomm Technologies, Inc.
5775 Morehouse Drive
San Diego, CA 92121
U.S.A.
© 2014 Qualcomm Technologies, Inc.
All rights reserved.
PAGE 2 80-NM498-1 A Feb 2014 Confidential and Proprietary – Qualcomm Technologies, Inc. | MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
Revision History
Revision Date Description
A Feb 2014 Initial release
Contents
 Multislot ACL with Synchronous Link

 BR/EDR Secure Connections
 LE Link Layer Topology
 LE Ping
 References
 Questions?
Multislot ACL with Synchronous Link
Why Multislot ACL with Synchronous Link
 The ACL link was previously restricted to single-slot packets to make

scheduling easy.
 Without this, it is possible for the remote device to always poll us or
attempt to send a multislot packet right before the SCO reserve frame.
 There is support for multislot ACL packets while SCO/eSCO exists.
 The SCO + FTP scenario as master or slave cases is improved.
BR/EDR Secure Connections
Abbreviations
Acronym Definition
AES Advanced Encryption Standard
CCM Counter with CBC-MAC
ECCH Elliptic Curve Diffie-Hellman
ACO Authenticated Ciphering Offset
Why BR/EDR Secure Connections
 BR/EDR connections currently use E0 encryption/cipher.

 E0 is considered to be weak. Several attacks and attempts at
cryptanalysis of E0 and the Bluetooth® protocol have been made, and a
number of vulnerabilities have been found.
 Additionally, E0 is not an approved cipher by NIST.
 In order to increase the security of BR/EDR and make it consistent with
Bluetooth low energy and 802.11, AES-CCM is a proposed new
encryption for BR/EDR.
 Secure Simple Pairing (SSP) is upgraded to utilize the P-256 elliptic curve
and the key derivation and authentication to use FIPS-compliant
algorithms.
Feature Summary
 Upgrades the encryption mechanism

 E0→AES-CCM-128
 Upgrades key establishment procedures for Bluetooth BR/EDR
connections to provide 128-bit strength
 P-192→P-256 elliptic curve
 Adds a Message Integrity Check (MIC)
 Provides cryptographic integrity protection of transmitted data vs relying on a
noncryptographic checksum, i.e., Cyclic Redundancy Check (CRC)
 Adds a Secure Connections Only mode of operation
 Allows devices to reject connections where the level of security does not meet
the minimum requirements
 No user experience changes compared with Simple Pairing (ver 2.1)
Bluetooth Security Model
 Pairing – The process for creating a shared secret key, i.e., the link key
 Bonding – The act of storing the link key created during pairing for use in
subsequent connections in order to form a trusted device pair
 Device authentication – Verification that the two devices have the same
link key
 Encryption – Message confidentiality
 Message integrity – Protects against message forgeries
Security Mechanisms
Security Secure connections ver

Legacy before ver 2.1 SSP ver 2.1 and after
mechanism 4.1
Pairing (key E21 and E22 algorithm P-192 ECDH P-256 ECDH
generation) based on SAFER+ HMAC-SHA-256 HMAC-SHA-256
(FIPS-approved (FIPS-approved
algorithms) algorithms)
Device E1 algorithm based on -do- HMAC-SHA-256

authentication SAFER+ (FIPS-approved
algorithms)
Encryption E0 algorithm -do- AES-CCM

(Massey-Rueppel (FIPS-approved
algorithm) algorithms)
Message No cryptographic -do- Message integrity

integrity message integrity; only supported by (AES-CCM)
CRC and CRC
Authentication
 Secure authentication shall be performed when both devices support the

Secure Connections (Controller Support) and Secure Connections (Host
Support) features.
 Secure authentication is a mutual authentication. Both the verifier and the
claimant perform the authentication at the same time.
Legacy Authentication
Claimant has link key
Claimant has no link key

Note: This sequence is identical for both legacy and secure
authentication.
MSC – Authentication Requested (Legacy)
Secure Authentication
1. The initiator sends LMP_au_rand.

2. If the responder has a link key, it responds with LMP_au_rand.
3. Both the initiator and the responder calculate the master and slave
responses.
4. The slave responds first with the LMP_sres (slave) response, then the
master responds with LMP_sres (master).
5. Both verify the received responses with the internally calculated
responses.
MSC – Authentication Requested (Secure Connections)
Encryption
 When E0 encryption is used, the entire payload shall be encrypted.

 When AES-CCM encryption is used, only the payload body and MIC shall
be encrypted; the payload header and CRC shall not be encrypted.
 If both devices support the Secure Connections (Controller Support) and
Secure Connections (Host Support) features:
 AES-CCM Encryption is enabled.
 Setting the encryption mode to 0 shall not be allowed.
MIC
 When encryption with AES-CCM is enabled, a MIC is added to the payload

before the CRC for packets that are defined to include the MIC.
 The MIC is not checked when the CRC is invalid.
Packet types MIC inclusion
Link control packets, e.g., ID, NULL, No MIC

POLL, FHS
SCO packets No MIC
eSCO packets No MIC
ACL packets MIC present when encryption with AES-CCM is

enabled
 Three authentication failures shall be permitted during the lifetime of an

encryption key. The third authentication failure shall initiate an encryption key
refresh as described in [S1]. If a fourth authentication failure occurs prior to
the encryption key refresh procedure completing, the link shall be
disconnected with reason code Connection Rejected Due to Security
Reasons (0x0E).
LMP Feature Definitions
 Secure Connections (Controller Support) [Ext Feature Mask Page 2 Byte 1

bit 0]
 This feature indicates whether the controller is able to support AES-CCM, the
P-256 elliptic curve for SSP.
 This feature bit shall only be set if the “Secure Simple Pairing (Controller
Support)” feature bit is set.
 Secure Connections (Host Support) [Ext Feature Mask Page 1 Byte 0 bit 3]
 This feature indicates whether the host is capable of supporting secure
connections.
 If HCI is supported, this bit shall be set if the Write Secure Connections Host
Support command has been issued by the host.
 When HCI is not supported, this bit may be set using a vendor-specific
mechanism.
 This bit shall only be set if the Secure Connections (Controller Support) bit and
the Secure Simple Pairing (Host Support) bit are set.
Enabling Secure Connections
 To enable BR/EDR secure connections, the host must use the HCI_Write_
Secure_Connections_Host_Support command, set to Enabled.
 This command must be sent before any connections are created.
 Firmware checks whether both the devices have support for secure
connections at both the controller and host levels and uses the secure
connections.
Authenticated Payload Timeout
 The Authenticated_Payload_Timeout configuration parameter allows the

host to configure the maximum interval between packets containing a MIC
received from the remote device when AES-CCM encryption is enabled.
 Default authentication payload timeout is set to 30 sec.
 On expiry, the controller indicates HOST via the Authenticated Payload
Timeout Expired Event.
 The host may choose to disconnect the link when this occurs.
New HCI Commands and Events
 Commands
 Read Secure Connections Host Support
 Write Secure Connections Host Support
 Read Authenticated Payload Timeout
 Write Authenticated Payload Timeout
 Read Local OOB Extended Data
 Added to read both P-192 and P-256 local OOB data
 Simple pairing hash and randomizer values
 Remote OOB Extended Data Request Reply
 Shares the remote device P-192 and P-256 OOB data to controller on request
 Write Secure Connections Test Mode
 Events
 Authenticated Payload Timeout Expired
Updated HCI Commands
 Link Key Request Reply

 Controller shall discard the link key once the connection is disconnected
 Set Connection Encryption
 Turn Link Level Encryption Off is not allowed on a connection established with
AES-CCM
 Master Link Key
 Use Temporary Link Key is not allowed when all slaves in the piconet support
AES-CCM
 Setup Synchronous Connection
 Accept Synchronous Connection Request
 HCI Enhanced Setup Synchronous Connection
 HCI Enhanced Accept Synchronous Connection Request
 SCO connection on an ACL link with AES-CMM is not allowed
Updated HCI Commands (cont.)
 IO Capability Request Reply

 Updated to mention what type of OOB data is present (P-192/P-256)
 Write Stored Link Key
 In Secure Connections Only Mode, host should not store link keys in the
controller
 Set Event Mask Page 2
 Update for the new Authenticated Payload Timeout event
 Write Simple Pairing Debug Mode
 Updated with new P-256 debug key, which is used for SSP Debug mode
Updated HCI Events
 Encryption Change
 On Set Connection Encryption Command, if both devices support secure
connections, the controller responds with the Encryption Change event with
parameter Encryption_enabled = 0x02 on successfully enabling the AES-CCM.
 Link Key Notification
 The Key Type value is updated to indicate whether the key is generated using
P-256.
 Remote OOB Data Request
 If both the Host and Controller support Secure Connections, the Host shall
respond with the Remote OOB Extended Data Request Reply command.
LE Link Layer Topology
Motivation
 Ver 4.0 does not permit:

 BR/EDR/LE devices to be LE peripherals
 This means BR/EDR/LE cannot communicate over LE with another BR/EDR/LE device
 An LE device to be master (central) or slave (peripheral) at the same time
 A4WP use cases require this capability, since phone is peripheral in A4WP use case
but central in other use cases
 An LE device to be a slave to multiple masters
Feature Summary
 Role combination changes

 This enhancement allows the link layer to operate in the LE master role and the
LE slave role at the same time. It also allows the link layer to operate as an LE
slave to multiple masters at the same time.
 LE slave-initiated connection parameter update
 The LE slave-initiated connection parameter update uses a new Connection
Parameters Request Link Layer Control procedure. This enhancement provides
the LE slave more control to avoid scheduling conflicts with multiple masters.
 Slave-initiated feature exchange procedure
 To support these enhancements, slave-initiated feature exchange is added so
that the devices can discover that the feature is supported by the remote device.
 Extended reject indication
 LL_REJECT_IND_EXT is used instead of LL_REJECT_IND.
Dual Mode Topology
 In ver 4.0, requirements in GAP prevented BR/EDR/LE devices:

 From connecting to other BR/EDR/LE devices
 To have any BR/EDR activity while acting as an LE peripheral device
 The Dual Mode Topology feature removed these restrictions and enables:
 BR/EDR/LE device connecting with another BR/EDR/LE device over LE as a
slave
 LE-only device connecting with a BR/EDR/LE device over LE as a slave
 A4WP (Rezence) use case requires dual mode topology, since the phone
is a peripheral to the charging pad
Link Layer Topology
 Enables mechanisms in the controller that will enable more complex link
layer topologies and mitigates scheduling conflicts
 Slaves connecting to multiple masters
 Masters that can also be slaves
 Scatternets
 Provides ability for slaves to move anchor points
Feature Exchange
 Local Feature Set should be updated so that all the new link layer features
would be masked in:
 Connection parameters request procedure
 Extended reject indication
 Slave-initiated features exchange
 Slave-initiated features exchange is initiated by the LE Read Remote
Supported Features HCI command.
Host A LL A LL B Host B
(master) (master) (slave) (slave)
Step 1 – Device B as Slave requests Remote Used Features from Master
LE Read Local Supported LE Read Local Supported

Features Features
Command Complete Command Complete
LE Read Remote
SupportedFeatures
Command Status
LL_SLAVE_FEATURE_REQ
LL_FEATURE_RSP
LE Read Remote Used
Features Complete
Figure 6.5 – Slave-initiated Features Exchange
Connection Update
(master) (master) (slave) (slave)
Step 1 – Device A and B are in a connection. Host A wishes to change the connection parameters
LE Connection Update
Command Status
LL_CONNECTION_UPDATE_REQ
Updated connection parameters used
LE Connection Update LE Connection Update

Complete Complete
Figure X – Connection update (old)
Host A LL A LL B Host B Host A LL A LL B Host B

(master) (master) (slave) (slave) (master) (master) (slave) (slave)
Step 1 – Host A wishes to change the connection parameters. Host B accepts. Step 1 – Host B wishes to change the connection parameters. Host A accepts.

Command Status Command Status
LL_CONNECTION_PARAM_REQ LL_CONNECTION_PARAM_REQ
LE Remote Connection LE Remote Connection
Parameter Request Parameter Request
LE Remote Connection LE Remote Connection
Optional Optional
Parameter Request Reply Parameter Request Reply
Command Complete
Command Complete
LE_CONNECTION_PARAM_RSP


LE Connection Update LE Connection Update Complete Complete
Complete Complete
Figure Z – Connection update (new), from slave

Figure Y – Connection update (new), from master
LE Ping
Summary
 Motivation
 Part of a larger improvement to security for LE (LE Secure Connections)
 Only part of LE secure connections in the controller
 Released in ver 4.1 to speed time-to-market for LE Secure Connections
 New link layer sequence forces remote link layer to send a packet
containing a MIC
 For use cases where data is only being sent intermittently, many packets sent
may not contain any data and will thus lack a MIC. This could be exploited by an
attacking device to pretend to be the target device when only Acks and Nacks
are being sent over the air. This is known as a “forged ack attack.”
 Time between pings is configurable (TLE_Authenticated_Payload) by the
upper stack/application
Ping Timer
 A Host may use the HCI_Write_Authenticated_Payload_Timeout

command to change the maximum interval between packets containing a
valid MIC that the link layer will enforce when the encryption is used.
Step 1 – Write Authenticated Payload Timeout on Device A
Write Authenticated Payload

Timeout
Command Complete
Figure 6.23 – Set LE Authenticated Payload Timeout
Related HCI Commands and Events
7.3.94 Write Autheticated Payload Timeout command

Command OCF Command parameters Return parameters
HCI_Write_Authenticated 0x007C Connection_Handle, Status,

_Payload_Timeout Authenticated_Payload_Timeout Connection_Handle
7.3.93 Read Authenticated Payload Timeout command

HCI_Read_Authenticated_ 0x007B Connection_Handle Status, Connection_Handle,

Payload_Timeout Authenticated_Payload_Timeout
7.3.69 Set Event Mask Page 2 command
HCI_Set_Event_Mask_Page_2 0x0063 Event_Mask_Page_2 Status
7.7.75 Authenticated Payload Timeout Expired event

Event Event code Event parameters
Authenticated Payload Timeout Expired 0x57 Connection_Handle
Ping Procedure 1
 Either link layer can authenticate the remote device using the LE Ping
procedure even if the remote device does not support the LE Ping feature.
This procedure can also be used for soliciting a packet from the remote
device containing a valid MIC. LL A may be a master or a slave.
Link is encrypted
Packet containing a MIC
TLE_Authenticated_Payload
nearly expired
LL_PING_REQ
LL_PING_RSP or
LL_UNKNOWN_RSP
Figure 6.24 – Successful LE Ping
Ping Procedure 2
 When a packet with a valid MIC has not been received within the LE
Authenticated Payload Timeout, the Host is notified that the timer has
expired.
Link is encrypted
Packet containing a MIC
nearly expired
LL_PING_REQ
expired
Authenticated Payload
Timeout Expired Event
Procedure response
timeout expired
Disconnection Complete
Figure 6.25 – Unsuccessful LE Ping

References
Ref. Document
Qualcomm Technologies
Q1 Application Note: Software Glossary for Customers CL93-V3077-1
Standards
S1 Specification of the Bluetooth® System Core Ver 4.1
Questions?
https://support.cdmatech.com

Bluetooth v4.1 On Pronto 1.4.1 Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Uploaded by

Copyright:

Available Formats

Bluetooth v4.1 On Pronto 1.4.1 Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bluetooth v4.1 On Pronto 1.4.1 Overview: Confidential and Proprietary - Qualcomm Technologies, Inc

Uploaded by

Copyright:

Available Formats

Bluetooth® v4.1 on Pronto 1.4.

Confidential and Proprietary – Qualcomm Technologies, Inc.

Confidential and Proprietary – Qualcomm Technologies, Inc.

Revision Date Description

A Feb 2014 Initial release

 Multislot ACL with Synchronous Link

 The ACL link was previously restricted to single-slot packets to make

AES Advanced Encryption Standard

CCM Counter with CBC-MAC

ECCH Elliptic Curve Diffie-Hellman

ACO Authenticated Ciphering Offset

 BR/EDR connections currently use E0 encryption/cipher.

 Upgrades the encryption mechanism

Security Secure connections ver

Device E1 algorithm based on -do- HMAC-SHA-256

Encryption E0 algorithm -do- AES-CCM

Message No cryptographic -do- Message integrity

 Secure authentication shall be performed when both devices support the

Claimant has link key

Claimant has no link key

1. The initiator sends LMP_au_rand.

 When E0 encryption is used, the entire payload shall be encrypted.

 When encryption with AES-CCM is enabled, a MIC is added to the payload

Packet types MIC inclusion

Link control packets, e.g., ID, NULL, No MIC

SCO packets No MIC

eSCO packets No MIC

ACL packets MIC present when encryption with AES-CCM is

 Three authentication failures shall be permitted during the lifetime of an

 Secure Connections (Controller Support) [Ext Feature Mask Page 2 Byte 1

 The Authenticated_Payload_Timeout configuration parameter allows the

 Link Key Request Reply

 IO Capability Request Reply

 Ver 4.0 does not permit:

 Role combination changes

 In ver 4.0, requirements in GAP prevented BR/EDR/LE devices:

Step 1 – Device B as Slave requests Remote Used Features from Master

LE Read Local Supported LE Read Local Supported

Figure 6.5 – Slave-initiated Features Exchange

Updated connection parameters used

LE Connection Update LE Connection Update

Figure X – Connection update (old)

Host A LL A LL B Host B Host A LL A LL B Host B

LE Connection Update LE Connection Update

Updated connection parameters used

LE Connection Update LE Connection Update

Figure Z – Connection update (new), from slave

 A Host may use the HCI_Write_Authenticated_Payload_Timeout

Step 1 – Write Authenticated Payload Timeout on Device A

Write Authenticated Payload

Figure 6.23 – Set LE Authenticated Payload Timeout

7.3.94 Write Autheticated Payload Timeout command

HCI_Write_Authenticated 0x007C Connection_Handle, Status,

7.3.93 Read Authenticated Payload Timeout command

HCI_Read_Authenticated_ 0x007B Connection_Handle Status, Connection_Handle,

7.3.69 Set Event Mask Page 2 command

Command OCF Command parameters Return parameters

HCI_Set_Event_Mask_Page_2 0x0063 Event_Mask_Page_2 Status

7.7.75 Authenticated Payload Timeout Expired event