Bluetooth Secure Simple Pairing Using NFC Part 2

Bluetooth Secure Simple
Pairing Using NFC
Part 2
2014 NFC World Congress
September 24, 2014 | Marseille, France

Presenter:
Tore Austad
Senior R&D Engineer, Wireless Design, Nordic Semiconductor ASA, Norway
Tore Austad has worked at Nordic Semiconductor ASA for 15 years as a Senior R&D engineer. Tore has been involved in
development projects for ultra-low power wireless ICs for the 433 MHz, 915 MHz and 2.4 GHz ISM bands. For the last two
years, Tore has focused on how to combine NFC and Bluetooth Low Energy technologies and ways to improve the user
experience.
Tore has been a member and an active contributor to the NFC Forum Reference Application Framework Working Group
from 2012 to 2014.
Nordic Semiconductor ASA
2

Outline
• NFC Data Exchange Format (NDEF)
• Connection Handover Record Types
• Bluetooth LE configuration data
• Bluetooth BR/EDR configuration data
• Example of Handover message
• Bluetooth Fast Connection
• Peer2Peer or reading a Tag
• Dynamically and non-dynamically programmable tag types
• Question and Answers
3

NFC Data Exchange Format
(NDEF)
The NFC Data Exchange Format
(NDEF) specification is a common
data format for NFC Forum
Devices and NFC Forum Tags
4

NDEF Record Outline
MB (message begin)
First record in a NDEF message
ME (message end)
Last record in a NDEF message
CF (Chunk flag)
First or middle record in a chunk
SR (Short Record)
Payload Length is one octet if set else four
IL(ID_LENGTH present )
If set ID_LENGTH and ID is present else not
TNF (Type Name Format )
0x00 : empty
0x01 : NFC Forum well-known type
0x02 : Media-type
0x03 : Absolute URI
0x04 : NFC Forum external type
0x05 : unknown
0x06 : unchanged
0x07 : reserved
5

NDEF Message
A NDEF message can consist of several NDEF records
• Message Begin (MB) and Message End (ME) are used to indicate first and last record in
the message.
• NDEF messages can be nested by carrying a full NDEF message as the payload within a
NDEF record.
A NDEF message can consist of chunks of payload by using the
Chunk flag
• First and each middle records set Chunk flag
• Each middle and last records set Type length and IL “0”
• Last record clears Chunk flag
• All chunks must be within one NDEF message so ME can not be set for
first or middle chunk records
6

Connection Handover Record
Types and Message Composition
– Message
composition
– Handover message
records
7

Message Composition, Handover
A handover message is a sequence of one or more NDEF records where the first is a Request,
Select, Mediation or initiation record.
Global record types
• Hr (0x48,0x72) Handover Request Record
• Hs (0x48,0x73) Handover Select Record
• Hc (0x48,0x63) Handover Carrier Record
• Hm (0x48,0x6D) Handover Mediation Record
• Hi (0x48,0x69) Handover initiator Record
Local record types
• ac (0x61,0x63) Alternative Carrier Record
• cr (0x63,0x72) Collision Resolution Record
• err (0x65,0x72,0x72) Error Record
8

Message Composition
Handover Request Record
Specification version number
16 bit random number for anti collision
Each record defines an alternative carrier
Note: Each record uses the NDEF with TNF = NFC Forum Well Known Type format
to define itself
9

Message Composition
Alternative Carrier Record
Pointer to a Handover Carrier Record or a
Carrier Configuration Record
Number of following auxiliary data ref.
Reference to NDEF record with
auxiliary data of the alternative carrier
10

Message Composition
Carrier Power State
• If CPS is set to “active” the peer device can
immediately use the configuration data and
connect to the carrier.
• IF CPS is set to “activating” the peer device
should expect a delay since the carrier was not
powered when message was sent.
• A Handover Selector may return one or more
carriers to “inactive” to save power and wait for
the Requestor to select one. The Requestor
should then send a new Request with exactly
one carrier.
• If the Selector is an NFC Tag (static handover) it
may provide a number of inactive alternative
carriers. This usually means that the user needs
to activate the carrier and the requestor could
try to connect to the carrier.
Should try to avoid this case and make
implementations where the carrier power state
can be set to active or activating. The host then
needs to know if the NFC Tag is read.
11

Message Composition
Collision and Version Handling
Collision:
• Collision resolution record
• If two devices both send a Handover Request message, the device
with the lower or greater random number, depending on the LSB
bits in the random numbers, shall take the role of the Handover
selector
Version:
• The handover messages carry a version number that shall be set to the Connection
Handover specification version number of which the messages are encoded.
• Minor version number means backward compatible
• Major version number means not backward compatible
• If not compatible and major version number is lower than the received, respond with a
handover select record without an alternative carrier record
• This tells the sender which highest version number you support
12

Message Composition
Handover Carrier Record
The carrier data reference can point to an NDEF record containing
• a Handover Carrier Record
• or a Carrier Configuration Record
Handover Carrier Record is used when a carrier is proposed
When no configuration data is to be provided
Additional carrier information,
length set by NDEF definition
13

Message Composition
Handover Select Record
Error record (reason + data )
not present if no error
Almost equal to the Handover Request Record but does not contain the
collision resolution record and may contain the error record
14

Message Composition
Handover Mediated Record
Response to a Handover Request message with one Handover Carrier
Record with carrier type “Hm”
Almost equal to the Handover Select Record but does not contain the
error record
15

Message Composition
Handover Initiate Record
Identifies the carrier that the Handover Mediator identifies that shall be
used for connection between the two other devices.
Almost equal to the Handover Mediated Record apart from the type
16

Message Composition
Handover Carrier Record vs. Carrier
Configuration Record
The Carrier Configuration Record is used when the record is not a
Handover Carrier Record. This record is identified with NDEF TNF value and
the payload MUST provide carrier-specific configuration information.
Note that Carrier Configuration Record is only a conceptual name and
no such record is covered in the specification
The Carrier Configuration Record is used to send carrier-specific
configuration data, for example Bluetooth out-of-band configuration
data.
In the case of Bluetooth LE pairing an NDEF is used with TNF=10b =
“media-type” with record type “application/vnd.bluetooth.le.oob” as
Carrier Configuration Record.
17

Bluetooth LE Configuration Data
– AD data composition
– Description of mandatory data
– Description of optional AD types
18

Bluetooth LE Configuration Data,
Message Composition
The Carrier Configuration Record is made by an NDEF record with:
SR set to 1b if payload does not
exceed 255 octets and CF to 0b.
TNF = 0x02 = “Media-type as defined in RFC 2046”
Set MB = 0b and ME = 1b if last
record (only carrier)
Type = “Record Type Name:
application/vnd.bluetooth.le.oob”
and Type length to 0x20
Bluetooth LE configuration data will
go into the payload and payload
length must be set accordingly
19

Advertise and Scan Response Data Format (AD)
The NDEF record payload shall consist of a set of AD data types describing the LE
configuration data. AD data types consist of a length field, an AD type field and an
AD Data field. Structure is defined in Bluetooth Core specification V4.0 Volume 3,
part C, section 11
Note! Non-significant part shall not be included in the NDEF payload
and set is not limited to 31 octets.
Total length of data is set as NDEF payload length
20
Bluetooth Core specification V4.0 Volume 3, part C, section 11

Mandatory Fields – LE Role
A Bluetooth device can take four different operation roles when operating on the
LE physical channel:
1. Broadcaster
2. Observer
3. Peripheral
4. Central
A Broadcaster sends advertising events; establishing a link is not defined for this role.
An Observer receives advertising events; establishing a link is not defined for this role.
A Peripheral device will be the slave in the connection states and will send advertising
events to establish a connection.
A Central device will be the master in the connection states and will be the device that
initiates the link.
Before establishing a link on the LE transport one device needs to take the Central role
and the other the Peripheral role. During NFC data exchange the device roles need to
be resolved.
21
Bluetooth Core specification V4.0 Volume 3, part C, section 2

Negotiated Handover
NFC ( Handover Request)
NFC ( Handover Select)
NFC Device
Peer mode
NFC Device
Peer mode
BT device role
central
or peripheral
BT device role
central
or peripheral
central scan advertise peripheral
peripheral advertise scan central
central need role change to continue
central
peripheral need role change to continue peripheral
22

Static Handover
NFC ( Read memory)
NFC ( Handover Select)
NFC Device
Read/Write
NFC TAG
BT device role
central
or peripheral
BT device role
central
or peripheral
central scan advertise peripheral
TAG device has not address of peripheral
and can not continue with scanning for
particular device.
peripheral central
central central
Need role change to continue peripheral peripheral
Same as above and need role change
on NFC device
advertise
23

Bluetooth Core spec. supplement section 1.17
If two devices have the same role preferences and both have
peripheral and central role capabilities, the Handover Requester
should change its role.
Date type value: 0x1C (Bluetooth assigned numbers generic access profile)
24

Mandatory Fields – LE Bluetooth Device Address
• Different Address types can be used for Bluetooth LE devices. Address type needs
to be communicated to the peer device over NFC.
• The LE Bluetooth Device Address data type is defined in [BLUETOOTH_CSS] Section
1.16. The LE Bluetooth Device Address data value consists of 7 octets. The 6 least
significant octets contain the 48-bit address that is used for the Bluetooth pairing
over the LE transport and will identify the peer device to establish a connection
with. The least significant bit in the most significant octet defines the address type.
The Address sent in the LE
Bluetooth Device Address
data type should be used on
the LE transport for at least
10 minutes after the NFC
data exchange.
Date type value: 0x1B (Bluetooth assigned numbers generic access profile)
25

Optional Data Types
The application may send a set of optional AD types for better user
experience.
Available AD types are listed in the Bluetooth Core Specification Supplement
and are defined by the Bluetooth SIG. Refer to the supplement for latest
updates when implementing.
An NFC Handover implementation receiving OOB AD formatted data should be
prepared to receive all possible AD type values, including values that are
currently reserved for future use, in any order. Any AD type that is not
supported by an implementation is ignored without inspecting the associated
AD values.
The following slides show some examples of optional data types that can be
sent over the NFC OOB channel for better user experience.
26

Optional Data Types: Appearance
The Appearance data type is defined in [BLUETOOTH_CSS] Section
1.12. The appearance characteristic defines the representation of the
external appearance of the device. The appearance characteristics may
be used by the discovering device to represent an icon, string, or
similar to the user.
Date type value: 0x19
(Bluetooth assigned numbers generic access profile)
Examples:
Mouse 0x03 0xC2
Keyboard 0x03 0xC1
Joystick 0x03 0xC3
G. Remote control 0x01 0x80
G. Computer 0x00 0x80
Bluetooth Assigned Numbers Gap Appearance
27

Optional Data Types: Local Name
The Local Name, if configured on the Bluetooth device, is the user-friendly name
presented over Bluetooth technology, as defined in [BLUETOOTH_CORE] Volume
3, Part C, Section 3.2.2. This is the name that may be displayed to the device
user as part of the UI involving operations with Bluetooth devices. The Local
Name data type is defined in [BLUETOOTH_CSS] Section 1.2.
Date type value: 0x08 (Shortened)
0x09 (Complete)
Example:
DeviceName: 0x44 0x65 0x76 0x69 0x63 0x65 0x4e 0x61 0x6d 0x65
28
Bluetooth Core specification 4.0 Volume 2, part C, section 3.2.2

Optional Data Types: Security Manager TK Value
The Security Manager TK value is defined in [BLUETOOTH_CSS] Section 1.8 and
is used by the LE Security Manager, which is described in [BLUETOOTH_CORE]
Volume 3, Part H. If the OOB association model is used, the TK value may be
exchanged over the OOB channel, in this case NFC. The TK value requirements
for such exchange are described in [BLUETOOTH_CORE] Volume 3, Part H,
Section 2.3.5.4.
Date type value: 0x10
Security consideration is out of scope of the application document.
Consideration must be done for each application.
29

Bluetooth BR/EDR Configuration
Data
– OOB mandatory field
– EIR data composition
– Description of optional EIR types
30

Data, Message Composition
The carrier configuration data record is made by an NDEF record with:
SR set to 1b if payload does not
exceed 255 octets and CF to 0b.
TNF = 0x02 = “Media-type as defined in RFC 2046”
Set MB = 0b and ME = 1b if last
record (only carrier)
Type = “Record Type Name:
application/vnd.bluetooth.ep.oob”
and Type length to 0x20
Bluetooth BR/EDR configuration
data will go into the payload and
payload length must be set
accordingly
31

Data, Mandatory Fields
The NDEF record payload shall always contain the OOB block as defined in
the Bluetooth Core specification V4.0 Volume 3, part C, section 5.2.2.7
Data length is the total
length including length
and all optional data. The
length will be the same as
the NDEF payload length
All Bluetooth devices have
an address and it is
mandatory to include in
OOB block. The Bluetooth
device address is
described in Bluetooth
Core specification V4.0
Volume 2, Part B, Section
1.2
The OOB block may
contain optional data. The
EIR tag format shall be
used for optional data
32
Bluetooth Core specification V4.0 Volume 3, part C, section 5.2.2.7

Data, Optional Data
Optional data is coded in EIR format. The length field is 1 octet and the
value is equal to the sum of the EIR data type and EIR data length.
Example:
Class of device:
Length = 0x04
EIR data Type = 0x0D (Class of device, Bluetooth Core specification volume 3, part C, section 3.2.4)
Assigned numbers, generic access profile
EIR data = 0x08 0x06 0x04 (Capturing, Imaging, Camera)
Assigned numbers , baseband
33
Bluetooth Core specification volume 3, part C, section 8

Data, Optional Data
Optional data is mainly described in:
• Bluetooth Core specification Volume 3, part C section 3 and section 8.
• Bluetooth core specification supplement
• Link to most relevant optional data types is given in the application
document.
• EIR data type values and data values are given in Bluetooth Assigned
numbers .
34

Example of Handover Connection
Message
35

Offset
(Octets)
Content Length
(Octets)
Explanation
0 0x91 1 NDEF record header:
MB=1b ME=0b CF=0b SR=1b IL=0b TNF=001b
1 0x02 1 NDEF record type length = 2 octets
2 0x11 1 NDEF payload length = 17 octets
3 0x48 0x72 2 Record type = ‘Hr’
5 0x12 1 Connection Handover specification version 1.2
6 0x91 1 NDEF Record Header:
MB=1b, ME=0b, CF=0b, SR=1b, IL=0b, TNF=001b
7 0x02 1 Record Type Length: 2 octets
8 0x02 1 Payload Length: 2 octets
9 0x63 0x72 2 Record Type: “cr”
11 0x01 0x02 2 Random Number: 0x01 0x02
13 0x51 1 NDEF record header:
14 0x02 1 NDEF record type length = 2 octets
15 0x04 1 NDEF payload length = 4 octets
16 0x61 0x63 2 Record Type ‘ac’ alternative carrier
18 0x01 1 Carrier Flags: CPS=1 “active”
19 0x01 1 Carrier Date Reference Length: 1 octet
20 0x30 1 Carrier data reference = “0”
21 0x00 1 Auxiliary Data Reference Count: 0
22 0x5A 1 NDEF record header:
23 0x20 1 NDEF Record Type length 32 octets
24 0x31 1 NDEF Payload length = 49 octets
25 0x01 1 ID length
26
0x61 0x70 0x70 0x6C 0x69
0x63 0x61 0x74 0x69 0x6F
0x6E 0x2F 0x76 0x6E 0x64
0x2E 0x62 0x6C 0x75 0x65
0x74 0x6F 0x6F 0x74 0x68 0x2E
0x6c 0x65 0x2E 0x6F 0x6F 0x62
32 Record Type Name:
application/vnd.bluetooth.le.oob
58 0x30 1 Payload ID = 0
Handover request
record
Collision
resolution
record
Alternative
carrier
record
Carrier
configuration
record
36

59 0x08 1 LE Bluetooth Device Address length: 8 octets
60 0x1B 1 LE Bluetooth Device Address data type
61 0x01 0x07 0x80
0x80 0xBF 0xA1
0x00
7 Bluetooth Device Address:
Public Address A1:BF:80:80:07:01
68 0x02 1 LE Role Length: 2 octets
69 0x1C 1 LE Role data type
70 0x03 1 LE Role:
Central and peripheral capabilities with the
central role preferred.
71 0x11 1 Security Manager TK value length: 17 octets
72 0x10 1 Security Manager TK value data type
73 0x00 0x00 0x00 0x11
0x00 0x00 0x00 0x11
0x00 0x00 0x00 0x11
0x00 0x00 0x00 0x11
16 Security Manager TK value
89 0x03 1 Appearance length: 3 octets
90 0x19 1 Appearance data type
91 0x00 0x80 2 Appearance: Generic Computer
93 0x0B 1 Local name length: 11 octets
94 0x09 1 Local name data type
95 0x44 0x65 0x76 0x69
0x63 0x65 0x4e 0x61
0x6d 0x65
10 Local name Ascii: “DeviceName”
105 0x02 1 Flags length: 2 octets
106 0x01 1 Flags data type
107 0x06 1 Flags:
LE General Discoverable Mode, BR/EDR not
supported
6 AD types
Length
Types
Value
37

Simplified Tag Format
In the case where a Handover Selector device would advertise only one
alternative carrier (e.g., a Bluetooth carrier), a simplified format without
the Handover Select record may be used. In this case, the NFC Forum Tag
contains an NDEF message with only the Bluetooth OOB information.
Offset
(Octets)
Content Length
(Octets)
Explanation
0 0xD2 1 NDEF record header:
1 0x32 1 Record Type Length 32 octets
2 0x1C 1 Payload Length = 28 octets
3
0x61 0x70 0x70 0x6C 0x69
0x63 0x61 0x74 0x69 0x6F
0x6E 0x2F 0x76 0x6E 0x64
0x2E 0x62 0x6C 0x75 0x65
0x74 0x6F 0x6F 0x74 0x68 0x2E
0x6c 0x65 0x2E 0x6F 0x6F 0x62
32 Record Type Name:
application/vnd.bluetooth.le.oob
35 0x08 1 LE Bluetooth Device Address length: 8 octets
36 0x1B 1 LE Bluetooth Device Address data type
37 0x18 0x3B 0x4B 0x1C 0x3B
0xCA 0x01
7 Bluetooth Device Address:
Static Address: CA:3B:1C:4B:3B:18
44 0x02 1 LE Role Length: 2 octets
45 0x1C 1 LE Role data type
46 0x00 1 LE Role: Only peripheral role capabilities
47 0x03 1 Appearance Length: 3 octets
48 0x19 1 Appearance data type
49 0x03 0xC2 2 Appearance Data: Mouse
51 0x0B 1 Local Name length: 11 octets
52 0x09 1 Local Name data type
53 0x44 0x65 0x76 0x69
0x63 0x65 0x4e 0x61
0x6d 0x65
10 Local Name Ascii: “DeviceName”
Both MB and ME are set
38

Bluetooth Fast Connection for LE
Reduce connection
setup
time after an NFC TAP
39

Fast Connection Establishment
Parameters for Bluetooth LE
After an NFC tap and exchange of handover connection messages it is
recommended to use the fast connection establishment parameters.
BLUETOOTH Core spec addendum 3, GAP Connection Parameters Changes, Sections 1.11
BLUETOOTH Core spec addendum 4 Part D, Section 1.3
Central device scan parameters
• scan_fast_interval
• scan_fast_window
• scan_fast_period
Peripheral device
• adv_fast_interval
• adv_fast_period
Addendum now included in version Bluetooth version 4.1
40

Peer2Peer or Reading a Tag
– Peer mode
– Reader/writer mode
41

Peer2Peer or Reader/Writer
Mode
Handover messages are exchanged between two devices in NFC Forum Peer-to-Peer
Mode or retrieved from an NFC Forum Tag by a device in NFC Forum Reader/Writer
Mode.
Negotiated Handover
• Peer2Peer mode messages shall be exchange d over LLCP data link and
the link shall be initiated by the Handover Requestor.
Static Handover
• One device in read/write mode reading the Handover Select message
from the other device, which is an NFC Forum Tag or an NFC Forum
device in card emulation mode.
42

Dynamically or Non-dynamically
Programmable Tags from Host
43

Dynamically Programmable Tags
Dynamically programmable Tags Tags with field detect Tags with no interface to host
Flexible solution:
• Can update non-static
addresses
• Can set accurate carrier
power state
• Only power up BL-LE
when Tag is read
• Can update security keys
Can be made power efficient:
• Only power up BL-LE
when Tag enters NFC field
• Date can not be updated
by host
• Can not use non-static
address types for pairing
Cheap solution:
• Major drawback: can not
inform host to power up
BT-LE for pairing. Needs to
be done by user
44

Connection Handover White Paper
Just Announced!
45
• Informative guide for
developers
• Hands on tips for
using Connection
Handover
• Free download:
• http://nfc-forum.
org/connection-handover/

Summary:
47
Assigned numbers:
https://www.bluetooth.org/en
-us/specification/assigned-numbers

Questions and Answers
– 20 minutes Q&A period
– You may also visit:
– http://nfc-forum.org/what-is-nfc/resources/
– http://nfc-forum.org/contact-us/
48

Bluetooth Secure Simple Pairing Using NFC Part 2

More Related Content

Similar to Bluetooth Secure Simple Pairing Using NFC Part 2 (20)

More from NFC Forum (20)

Recently uploaded (20)

Bluetooth Secure Simple Pairing Using NFC Part 2