Secure Bluetooth Pairing Made Easy Using NFC · 2019-12-30 · Secure Bluetooth Pairing Made Easy Using NFC RFID and Memory Division December 2019. What is NFC? 2. NFC Technology

Secure Bluetooth Pairing

Made Easy Using NFC

RFID and Memory Division

December 2019

What is NFC?

2

NFC Technology Overview 3

An interactive technology enabling IoT devices

• Near Field Communication, a short range Radio Frequency Identification (RFID)

wireless technology

• Typically uses an active reader and a passive memory tag

• Operating at 13.56MHz

• Based on the HF RFID standards ISO14443A/B, ISO15693, FELICA

• Interactive and zero power, enabling convenient connection to the Internet of Things

NFC tags harvest their operating power from the NFC field

• NFC is maintained by the NFC Forum

• Ensures Interoperability between devices

• Standardized use cases (web link, Bluetooth handover,…)

• Fast growing deployment in mobile phones

• In 2018, two out of every three phones to come with NFC

• NFC is used for Apple Pay®, and in 2017 Apple® added support of NFC reader mode from iOS11 onward. In iOS13 both NFC read and write modes have been enabled.

https://en.wikipedia.org/wiki/Near-field_communication

https://nfc-forum.org/

NFC in Depth• Requires an action such as bringing your card/phone

near the reader in order to use

• NFC operating modes

• Read/Write (reader-to-passive tag/card)

• Card Emulation (e.g. Apple Pay, Android Pay, Samsung Pay, etc.)

• Peer-to-Peer (i.e. reader-to-reader)

• Maximum data transfer rate is 424 kbps (P2P)

• Proprietary modes can go up to 6.8 Mbps

• Tag data rates vary from 27kbps to 106kbps

• Defined Tag Types

• Various combinations of features, storage and security

• Types 1-5. ST offers Type 4 & 5 (the most popular)

• Applications include Bluetooth/WiFi pairing, access

control, payments, electronic passports, ticketing

4

NFC in the Wireless Spectrum

• NFC is a flavor of RFID

• Subset of RFID HF standard: 13.56MHz

• NFC is complementary in the wireless

spectrum

• Short distance, Low data-rate & Zero

power for applications

• NFC is complementary to Wi-Fi and

Bluetooth technologies

• Tap & Pair: convenient pairing use case

BT/ BLE

ZigBee

HF

(RFID)

1 000

100

100 000

10 000

0.10.01 101 1k100 Distance (m)

WiFi

GSM

3G

Speed

(kbps)

UHF

(RFID)NFC

5

iOS13 NFC capabilities

• Provided support for reading/writing tags using native commands

• NFC Type 5 - ISO15693 : Implemented full set + extended commands as defined in ISO15693-3 standard

• Read/Write single/multiple blocks

• Custom Commands : ST25 Password, TruST25 Digital Signature, Fast Transfer Mode, PWM settings, Tamper

Detection…

• NFC Type 4 – ISO14443A read/write commands

• Ex : ST25TA TruST25 Digital Signature management

• Smart Card read/write commands

• FeliCa read/write commands

• Added support for writing NDEF messages across different tags from Type1 up to Type 5

• Ability to permanently lock an NFC tag that has been encoded with an NDEF message

• Additional enhancements to Apple Pay for NFC

• iOS13 comes with new feature for processing Value added Service (VAS) tags. This feature is still unclear at

the moment. More details to come later…

6

https://en.wikipedia.org/wiki/FeliCa

NFC for Bluetooth Pairing

7

Bluetooth Evolution 8

1.0 1.1 1.2 2.0 2.1 3.0 4.0 4.1 4.2 5.0

1999 2000 2003 2004 2007 2009 2010 2011 2014 2016

Classic

BluetoothLE Legacy Secure

ConnectionsBR/EDR

Secure

Simple Pairing

BR/EDR

Secure

How does NFC help with Bluetooth pairing?

• There are a number of ways to pair two

Bluetooth devices (e.g. PIN numbers,

numerical comparison, etc.).

• One method is called Out Of Band (OOB)

pairing. QR codes and NFC are two

examples of OOB pairing mechanisms.

• With a simple tap, a smart phone can read

the pairing information off of a NFC tag and

use it to automatically pair with a BT device.

No other input is needed!

NFC simplifies the pairing process

How does NFC pairing with BT work? 10

1. Tap to trigger the NFC

reader in the phone

3. Handover to BT

2. Read BT ID and secure

pairing credentials

3. Use credentials to

securely pair over BT

Wake

Benefits to end-customer

• Faster and simpler – no need for BT/Wi-Fi sub-menus

or searching through lists to find surrounding devices

• No conflicts – pair only the devices you intend to pair

• Secure communications – encrypt a BT link by

exchanging credentials securely with just a tap

• Low cost - ideal for BT devices that are too small or

cannot afford a user interface for PIN or password

entry

• Ease of use - unlike QR codes, Line of Sight is not

required with NFC

• Save power – use NFC to automatically turn on a

battery-powered BT device and instantly pair

11

• NFC Data Exchange Format (NDEF) is a standard format defined by the NFC forum to store

data on a NFC tag

• Different types of NDEF records :

• SMS (Short Messaging Service)

• URI (Universal Resource Identifier)

• Text

• Bluetooth Pairing (handover)

• Smart poster….

• The type of NDEF record is defined by the Record Type Definition (RTD) field, located in the

NDEF header. A Well Known Type (WKT) of NDEF record used for Bluetooth handover is a

MIME type

The NDEF Record Format

How is pairing information stored?

for detailed Info for NDEF record structure, please refer to the Technical Specifications of the NFC Forum!

http://members.nfc-forum.org/specs/spec_list/

NFC/Bluetooth Pairing Record Types

MIME (Multipurpose Internet Mail Extensions) type

MIME is an Internet format used to transmit text, audio, images, etc. via email

and is defined by Internet Assigned Numbers Authority (IANA). Bluetooth

pairing records are a specific MIME application type embedded within a NDEF

record [RFC 2046 Multipart Message/Digest]

• Bluetooth BR/EDR configuration NDEF record MIME type : application/vnd.bluetooth.ep.oob

• Bluetooth LE configuration NDEF record MIME type : application/vnd.bluetooth.le.oob

• BR/EDR and LE can be defined in the same handover message by using two configuration

records with different record type names

13

-> for more information please see http://www.iana.org/assignments/media-types/media-types.xhtml#application

https://www.iana.org/

http://www.iana.org/assignments/media-types/media-types.xhtml#application

Simplified Tag - Bluetooth LE Example

How data is stored as a NDEF record 14

4 byte Capability

Container

NDEF Message

Record 1

Record 2

Record n

Beyond NDEF

Information

(optional)

64kbit device

0x0000h

0x1FFFh

ST25DVxx

Byte Content Length Explanation

0 0xD2 1 NDEF Record Header:

MB=1b, ME=1b, CF=0b, SR=1b, IL=0b, TNF=010b

1 0x32 1 Record Type Length = 32 bytes

2 0x1C 1 Payload Length= 28 bytes

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/v nd.bluetooth.le.oob

35 0x08 1 LE Bluetooth Address Length: 8 bytes

36 0x1B 1 LE Bluetooth Device Address Data Type

37 0x18, 0x3B, 0x4B, 0x1C, 0x3B, 0xCA, 0x01 7 Bluetooth Static Address: CA:3B:1C:4B:3B:18

44 0x02 1 LE Role Length: 2 bytes

45 0x1C 1 LE Role Type

46 0x00 1 LE Role: only peripheral

47 0x03 1 Appearance Length: 3 bytes

48 0x19 1 Appearance Type

49 0x03, 0xC2 2 Appearance Data: Mouse

51 0x0B 1 Local Name Length: 11 bytes

52 0x09 1 Local Name Type

53 0x44, 0x65, 0x76, 0x69, 0x63, 0x65, 0x4E,

0x61, 0x6D, 0x65

10 Local Name ASCII: “DeviceName”

Type Name Format (TNF) = 0x02 = MIME Format

MIME Record Name = application/vnd.Bluetooth.le.oob

15

Flexible Solution

• Can implement dynamic MAC addressing

• Can identify current carrier power states

• Power up BLE when NFC field detected

• Can create new keys and randomizers after

every pairing

ST Offerings

• ST25DV

• M24SR

Dynamic I2C Tags

Tags for Bluetooth pairing

Host

ST25DV

STM32WB55

Field

Detect

I2C

Data

Example application: Wearable Patient Monitor. A nurse can tap their tablet to the monitor to

securely download a log of the last several hours of collected heat rate, blood pressure, etc. data. A

while later, a doctor could do the same with a different set of security keys

https://www.st.com/content/st_com/en/products/nfc/st25-nfc-rfid-tags-readers/st25-dynamic-nfc-tags/st25dv-i2c-series-dynamic-nfc-tags.html

https://www.st.com/content/st_com/en/products/nfc/st25-nfc-rfid-tags-readers/st25-dynamic-nfc-tags/m24sr-series-dynamic-nfc-tags.html

16

Power Efficient

• Only power-up BLE when NFC field detected

• Cannot implement dynamic addressing

• Cannot update secure pairing information

• Must advertise all carriers (capabilities)

ST Offerings

• ST25TA02KB-P

NFC Tags with Field Detect


Host

ST25TA

STM32WB55

Field

Detect

Example application: Low cost Bluetooth speaker for playing music. By tapping your phone to the

speaker you can power the device on and starts the pairing process. This eliminates the need for a

power button. Device authentication isn’t as critical in this case.

https://www.st.com/content/st_com/en/products/nfc/st25-nfc-rfid-tags-readers/st25-nfc-rfid-tags/st25ta-series-nfc-tags/st25ta02kb-p.html

17

Low Cost

• Can only store basic pairing information, no

authentication data for secure pairing

• Cannot wake the BLE radio on field detect

• Cannot implement dynamic MAC addressing

• Must advertise all carriers (capabilities)

regardless of their current power state

ST Offerings

• ST25TA

• ST25TV

Standalone NFC Tags


Host

ST25TV

STM32WB55

Example application: Low cost (always on) environmental monitor. The tag stores the Bluetooth

address and device role making pairing easy. Also, the tag could be added “after-the-fact” with no

wiring to the radio required

https://www.st.com/en/nfc/st25ta-series-nfc-tags.html

https://www.st.com/en/nfc/st25tv-series-nfc-tags.html

18

CharacteristicBluetooth BR/EDR Bluetooth Low Energy

Prior to 2.1 v2.1 to v4.0 v4.1 and beyond v4.0 and v4.1 V4.2 and beyond

RF Channels 79 channels with 1MHz spacing 40 channels with 20MHz spacing

Discovery Method Inquirery/Paging Advertising

Max Piconet Slaves 7 active / 255 total Unlimited

Device Address Privacy None Private Addressing

Max Data Rate 1 – 3 Mbps 1 Mbps (GSMK)

Output Power/Range 100mw (20dBm) / 30M 10mW (10dBm) / 50M

Security Version BR/EDR Legacy Secure Simple Pairing BR/EDR Secure LE Legacy LE Secure

Pairing Method SAFER+ (E21 & E22)ECDH P-192

HMAC-SHA-256

ECDH P-256

HMAC-SHA-256

TK and STK with

AES-128

ECDH P-256

HMAC-SHA-256

Device Authentication SAFER+ (E1) SAFER+ (E1) HMAC-SHA-256 AES-CCM AES-CCM

Encryption SAFER+ (E0) SAFER+ (E0) AES-CCM AES-CCM AES-CCM

Different versions of Bluetooth have different security methods

BR/EDR and LE Feature Comparison

BR/EDR Secure and LE Secure together are known as Secure Connections

http://www.cs.sjsu.edu/faculty/stamp/students/cs298ReportSteven.pdf

19

Passive eavesdropping is where a third party listens in to the data being exchanged between

two paired devices. NFC overcomes this by providing a larger encryption key (LE Legacy) and,

with its inherently short range, NFC can be used to securely transfer credentials used for

secure pairing.

Passive Eavesdropping

Bluetooth Security Threats

Bluetooth Link

20

MITM (i.e. active eavesdropping) is a process by which a third party impersonates the Initiator

and Responder, in order to trick them into connecting to it. The BLE central and peripheral

devices will connect to the malicious party which intercepts all data being sent between them.

The malicious party can also insert false data or remove data before it reaches the recipient.

NFC provides the highest level of resistance to MITM attacks due to its short communications

range and 128-bit key size (LE Legacy).

Man In The Middle


Bluetooth Link Bluetooth Link

21

Using the Bluetooth hardware MAC ID, a malicious entity may be able to associate the

hardware address of a BLE device with a specific user and then track their physical location

when the BLE device advertises its. Bluetooth LE can overcome this is by periodically changing

the device address (a Resolvable Private Address).

Identity Tracking


BT pairing process – overview

Pairing is a three-phase process for establishing keys used for secure communications. The first two

phases are always used and may be followed by a 3rd optional phase for transport specific key

distribution

• Phase 1 – Feature Discovery: The two devices tell each other what their capabilities are by reading their

Attribution Protocol (ATT) values. These determine which pairing method is used in phase 2, what the devices can

do and what they expect.

• Phase 2 – Key Agreement / Generation: In LE Legacy pairing a Short Term Key (STK) is generated in this phase

by the devices agreeing on a Temporary Key (TK) combined with random numbers to derive the STK. The STK

itself is never transmitted between devices.

If the Secure Connections pairing is being used instead, both devices simply compute a Long Term Key (LTK)

instead of an TK/STK.

• Phase 3 – Key Distribution: The key from phase 2 is used to distribute any other keys needed for

communication. If an LTK wasn’t generated in phase 2 (LE Legacy), one is generated in phase 3. Examples of

other keys are the Connection Signature Resolving Key (CSRK) for data signing and the Identity Resolving Key

(IRK) to decrypt the Random Private Resolvable address (used by iOS devices)

Bonding devices store encryption keys for later secure communication.

22

Bluetooth Pairing Methods and Mechanisms

The introduction of Secure Simple Pairing in BT v2.1 defined 4 types of pairing methods: Just

Works, Passkey, Numeric Comparison and Out Of Band.

• Just Works: No key entered. Good for devices with no user input like sensors. No MITM protection.

• Passkey Entry: Six digit PIN code

• Numeric comparison (LE Secure): When both devices have a display. If the same number shows up

on both displays, the user would confirm a match

• Out of band: Use of an alternative communications channel (NFC or QR code) to execute a handover

by exchanging authentication data and Bluetooth MAC IDs

For LE Legacy Pairing (v4.0 and v4.1)

• No Numerical Comparison equivalent

• Just Works and Passkey Entry do not provide any passive eavesdropping protection. This is because

Secure Simple Pairing uses Elliptic Curve Diffie-Hellman (public-private key pairs) and LE legacy

pairing does not

23

NFC Handover Terms

Handover Requestor (Initiator)

NFC Forum device that initiates the handover operation. The requestor is also sometimes

referred to the “master”

Handover Selector (Responder)

NFC Forum device or NFC Forum Tag that responds to the Handover Requestor. The selector

is sometimes referred to as the “slave”

Handover Mediator

NFC Forum device that can facilitate connection between two other NFC enabled devices. An

example would be a smart phone used to configure a wireless network.

24

• Common to BR/EDR and LE

• Mandatory for all LE profiles

• Procedures to discover and connect to

devices

• Roles• Peripheral (Slave)

• Central (Master)

• Broadcaster (Advertiser)

• Observer (Scanner)

• Security• Creating bonds with peer devices

• Attribute access security requirements

• Privacy

• Advertising data format

25

• Security Manager• Handles pairing and bonding

• Security parameter negotiation

• Encryption key generation and distribution

The Generic Access Profile

How do two BT devices know how to pair?

Service Discovery

Protocol (SDP) Attribute Protocol (ATT)

Generic Attribute Profile

(GATT)

Logical Link and Adaptation Control Protocol (L2CAP)

Link Manager Protocol (LMP) Link Layer (LL)

Security

Manager

(SM)

Generic Access Profile

When does this happen?

• Pairing is a 3 phase process. The method is decided upon in the 1st phase:

• The master (initiator) advertises its IO capabilities, key size, and pairing methods over BT

• The slave responds with its IO capabilities, key size, and pairing methods over BT

• If both devices have their OOB Data Flag set, then OOB NFC handover is used

26

Initiator

(Master)

Responder

(Slave)

Step 1 – Master initiates pairing

Phase 2 pairing method selected from parameters of pairing request and pairing response

Pairing Request (IO Capability, OOB Data Flag, Auth Req, Max Enc Key Size, InitKey Distribution, Resp Key Distribution)

Pairing Response (IO Capabil ity, OOB Data Flag, Auth Req, Max Enc Key Size, Init Key Distribution, Resp Key Distribution)

• Used in cases where the Handover Selector (responder) device is equipped with a NFC Forum Tag only. The initiator

reads the MAC ID of the responder along with some descriptive info about the responder’s role.

• Due to the static nature of data on a tag, a pre-stored Handover Select Message will have to indicate all available

carriers since the tag is not capable of constructing a dynamic Handover Select Message.

• Simple Secure Pairing is NOT supported due to the static nature of the tag. Pairing key should be regenerated every

time.

Static Handover

NFC Handover Types 27

Host

NFC

Reader

Alternative Carrier

WiFi

Alternative Carrier

Bluetooth Data Exchange over Bluetooth

Handover Select Bluetooth

Tag Read of available carriers

Host

NFC

Tag

Alternative Carrier

Bluetooth

28

• Used in cases where the Handover Responder device is an active NFC Device (e.g. Reader or Dynamic Tag)

• The device can selectively advertise available carriers. In the example below the Selector is power constrained. The

requestor asks for BLE and WiFi but the Selector only offers BLE in this case.

• Dynamic Handover can support optional secure pairing

Negotiated Handover

NFC Handover Types

Host

NFC

Reader

Alternative Carrier

WiFi

Alternative Carrier

BluetoothData Exchange over BLE

Handover Select (Bluetooth(off), WiFi(off))

Handover Request (Bluetooth & WiFi)

Handover Select (BLE)

Handover Request (BLE)

Host

NFC

Reader

Alternative Carrier

WiFi

Alternative Carrier

Bluetooth

29

• Exchange of NDEF messages between two NFC-enabled devices via a third NFC device (i.e. the Handover

Mediator). The mediator serves to get both devices to agree on one or several alternative carriers (e.g. a cell phone

used to commission a network of NFC-enabled wireless sensors)

• Can support optional secure pairing if both devices have active NFC transceivers, or one has a dynamic tag.

Mediated Handover – Static Tag Example

NFC Handover Types

Prepare to receive

connection request for

all available carriers

Handover MediatorDevice Tag

Handover Request (Carrier “Hm”)

Handover Mediation Response1st

Tap

2nd

Tap

Tag Read

Handover Select (Carrier “Hs”)

Prepare to receive

connection request for

all available carriersUser prompt to tap

handover device

Handover Request (Carrier “Hm”)

Handover Mediation Response

Handover Initiate Request

Handover Initiate Response

Initiate Alternative Carrier

3rd

Tap

Active and Passive NFC Communication

• Communication between two active NFC transceivers

• Uses NFC Peer-to-Peer mode over a LLCP (Logical Link Control Protocol) data link

• The first device to send a Handover Request will be the initiator/master. The other device will

default to the Handover Selector responder/slave.

• If a device receives a Handover Request after transmitting a Handover Request, a collision has

occurred. The initiator role is then resolved using the Collision Resolution Record: a random

number embedded in the NDEF message.

• If the Handover Request/Select record versions differ by a minor version, the selector will reply

with a handover message according to it’s version format. If the difference is a major version the

selector can either reply with an empty message with just its version number or a complete

message formatted in its supported version format with version number

• Communication between an active NFC transceiver and a dynamic or passive tag

• NFC transceiver operates in reader/writer mode and reads Type 1-5 tags according to their specific protocols

30

Active Responder Example

NFC Polling Loop 31

• In this loop, the reader switches

from a passive P2P listen mode to

an active tag read mode and then

back again. This allows for both

Initiator and Responder roles

• The length of the polling loop and

the tag types supported are

configurable.

• For an active Initiator the polling

time vs. listening time would be

inverted

Passive P2P (listening)

300 ms

Type A25 ms

Type F25 ms

Type 525 ms

Active P2P25 ms

LE Legacy Pairing

32

Phase 1: Pairing Feature Exchange

The devices identify which of the 4 methods of pairing are available, which also defines the Temporary Key (TK) used for authentication:

• Just Works: TK = 0. No security provided

• Passkey: TK = Six-digit PIN. Relatively easy to brute force attack due to the limited size of PIN

• OOB: TK = 128-bit random number. ← Strongest of any of the pairing methods

33

Dynamic Handover

OOB LE Legacy Pairing Process

Initiator

(Master)Responder

(Slave)

Check for confirm value match

Create MRANDSet TK

Create SRANDSet TK

Mconfirm = c1(TK, Mrand, Pairing Request command, Pairing

Response command, Init Device address type, Init Device

address, Resp Device address type, Resp Device address)





Pairing Confirm (Mconfirm)

Pairing Confirm (Sconfirm)

Pairing Random (Srand)

Pairing Random (Mrand)

OOB exchange of TK


Pairing Response (IO Capability, OOB Data Flag, Auth Req, Max Enc Key Size, Init Key Distribution, Resp Key Distribution)

STK = s1(TK, SRAND, MRAND) STK = s1(TK, SRAND, MRAND)

LTK, EDIV, RAND Generate RANDLTK = d1(ER, DIV, 0) or Rand#CSRK = d1(ER, DIV, 1)IRK = d1(IR, 1, 0) DHK = d1(IR, 3, 0)

IRK, CSRK

EDIV, RAND

Encrypt Link with STK

Dynamic Handover

OOB LE Legacy Pairing Process 34

Phase 2: Key Agreement

Step 1: Once OOB pairing is determined from Phase 1, the devices exchange their MAC IDs and the Temporary key using NFC. The Master and Slave also generate random numbers (MRAND and SRAND) used for mutual authentication.

Initiator

(Master)Responder

(Slave)


Create MRANDSet TK

Create SRANDSet TK












OOB exchange of TK





IRK, CSRK

EDIV, RAND


Dynamic Handover



Step 2: Both the master and slave mutually authenticate by generating “confirmations” using the random number generated in the previous step along with their MAC addresses, address types, pairing request and responses, and the TK).

Initiator

(Master)Responder

(Slave)


Create MRANDSet TK

Create SRANDSet TK












OOB exchange of TK





IRK, CSRK

EDIV, RAND


Dynamic Handover



Step 3: Over Bluetooth, the master and slave exchange their computed “commitments”. The master also transmits the random number used to generate its commitment to the slave. The slave recomputes the master’s commitment (which requires the secretly transmitted TK) to see if it gets the same result.

Initiator

(Master)Responder

(Slave)


Create MRANDSet TK

Create SRANDSet TK












OOB exchange of TK





IRK, CSRK

EDIV, RAND


Dynamic Handover



Step 4: If the master’s commitment is verified, the slave transmits the random number used to generate its commitment to the master. The master recomputesthe slave’s commitment (which requires the secretly transmitted TK) to see if it gets the same result. If it does then both devices compute a Short Term Key (STK) based on the TK, MRAND and SRAND and encrypt the link with it

Initiator

(Master)Responder

(Slave)


Create MRANDSet TK

Create SRANDSet TK












OOB exchange of TK





IRK, CSRK

EDIV, RAND


Dynamic Handover


Phase 3: Key Distribution

There are 2 methods for Long Term Key (LTK) generation: Database Lookup and Key Hierarchy.

Database Lookup stores randomly generated keys in a database and uses EDIV (Encrypted Diversification Number) to look them up.

Key Hierarchy uses a key generation function along with an Encryption Root (ER) and an Identity Root (IR)

Initiator

(Master)Responder

(Slave)


Create MRANDSet TK

Create SRANDSet TK












OOB exchange of TK





IRK, CSRK

EDIV, RAND


Dynamic Handover


Initiator

(Master)Responder

(Slave)


Create MRANDSet TK

Create SRANDSet TK












OOB exchange of TK





IRK, CSRK

EDIV, RAND


Both the master and slave devices can distribute these numbers, but BLE is designed to conserve energy, so the slave device is often resource constrained and does not have the database storage resources for holding LTKs. Therefore the slave will distribute LTK, EDIV, and Rand to the master device for storage. When a slave begins a new encrypted session with a previously linked master device, it will request distribution of EDIV and Rand and will regenerate LTK


LE Secure Pairing

40

Dynamic Handover

OOB LE Secure Pairing Process 41

Initiator A

(Master)Responder B

(Slave)



Set ra = Rand, Compute commitmentCa = f4(PKa, Pka, ra, 0)

Set rb = Rand, Compute commitmentCb = f4(PKb, PKb, rb, 0)

OOBa: Initiator Pairing Device AddressA, ra, Ca

OOBb: Responder Pairing Device AddressB, rb, Cb

Check for commitment value matchCheck for confirmation value match

Exchange Public Keys

Compute DHKey commitmentEa = f3(DHKey, Na, Nb, rb, IOcapA, AddrA, AddrB)

Random Nb

Random Na

Compute DHKey ConfirmEb = f3(DHKey, Nb, Na, ra, IOcapB, AddrB, AddrA)

Check for commitment value matchEa

Check for commitment value matchEb

Compute Link KeyLK = f2(DHKey, Na, Nb, btlk, AddrA, AddrB)


Phase 1: Pairing Feature Exchange

The devices identify which of the 4 methods of pairing are available

• Just Works:

• Passkey:

• Numerical Comparison

• OOB:

IRK, CSRK

Encrypt Link with LK

Dynamic Handover


Initiator A

(Master)Responder B

(Slave)










Random Nb

Random Na







Step 1: Both the master and slave generate “commitments” which is a Hash of a random number with the device’s public key used for key verification.

A commitment scheme allows you to commit to a certain value without revealing it until a later date.

IRK, CSRK


Dynamic Handover


Initiator A

(Master)Responder B

(Slave)










Random Nb

Random Na







Step 2: Using NFC, the master and slave exchange their “commitments” as well as the random number used to generate the commitment and their MAC Address.

This is also the point where the master and slave would exchange their public keys over Bluetooth if the pairing was NFC triggered

IRK, CSRK


Dynamic Handover


Initiator A

(Master)Responder B

(Slave)










Random Nb

Random Na







Step 3: The slave re-computes the master’s commitment and the master re-computes the slave’s commitment to see if they match.

If they do, the master and slave exchange random numbers that will be used to verify the Diffie Hellman Key.

IRK, CSRK


Dynamic Handover


Initiator A

(Master)Responder B

(Slave)










Random Nb

Random Na







Step 4: The master computes its DHKeycommitment and sends that to the slave.

The slave verifies the master’s DHKeycommitment and, if successful, the slave computes its commitment and forwards that to the master. The master then verifies the slave’s DHKeycommitment.

IRK, CSRK


Dynamic Handover


Initiator A

(Master)Responder B

(Slave)



IRK, CSRK








Random Nb

Random Na







Step 5: If the master and slave verifies each other’s DHKey commitment then they both compute the same Link Key used to symmetrically encrypt the link Encrypt Link with LK

Dynamic Handover


Initiator A

(Master)Responder B

(Slave)



IRK, CSRK








Random Nb

Random Na







Once the link is encrypted with the Link Key, the Identity Resolving and Connection Signature Resolving Key can be distributed Encrypt Link with LK

- OOB Data Length (LENGTH)

- Device Address (BD_ADDR)

- Class of Device

- Hash C

- Randomizer R

- Service Class UUID

- Bluetooth Local Name

Optio

nal

Bluetooth Carrier Configuration Record

(mime-type “application/vnd.Bluetooth.ep.oob”)

(Payload ID “0”)

48

Bluetooth BR/EDR

Handover Request Record

Handover Request Record(NFC WKT “Hr”)

- Version: 1.3

Collision Resolution Record

• Random Number

Alternative Carrier Record

• Carrier Power State: “active”• Carrier Data Reference: “0”

Bluetooth Device (MAC) Address

3-byte field for Service Class, Major Class, Minor Class, e.g.

Capturing:Imaging:Camera. Used to present an icon in a UI

Public key commitment using 128-bit hash and 128-bit randomizer

16-bit,32-bit, or 128-bit field for uniquely identifying the device and it’s

capabilities

User Friendly Name in UTF-8 format: e.g. “Headset DeluX”

Total length of configuration record, including the length field itself

- LE Device Address

- LE Role

- Security Manager TK Value

- Hash C

- Randomizer R

- Appearance

- Local Name

- Flags

Optional


(mime-type “application/vnd.Bluetooth.le.oob”)


49

Bluetooth LE

Handover Request Record

Handover Request Record(NFC WKT “Hr”)

- Version: 1.3

Collision Resolution Record

• Random Number



Broadcaster, Observer, Peripheral, Central

Public/Private MAC Address Length, Type and Value

Flags: Limited Discoverable, General Discoverable, EDR not supported,

BR/EDR + LE Controller, BR/EDR + LE Host

Mouse, Keyboard, etc. Used to present a particular icon for UI

User Friendly Name: “Headset DeluX”

Temporary Key for LE Legacy compatibility

Public key commitment using 128-bit hash and 128-bit randomizer

• A responder with a NFC transceiver is able

to actively negotiate a pairing with an

initiator. It can selectively advertise certain

capabilities (carriers) while hiding others.

• Mutual Authentication is supported by

exchanging Commitments and

Randomizers. These can also be changed

on every pairing to improve security.

• Role conflicts with the Initiator can be

resolved if the Selector changes it role.

• A dynamic tag (e.g. ST25DV) can support

negotiated handovers with NFC transceiver

in reader mode.

Negotiated Handover – NFC Transceiver

Handover Select Record 50

Handover Select Record(NFC WKT “Hs”)

- Version: 1.3





- Class of Device

- Simple Pairing Hash C

- Simple Pairing Randomizer R


- Bluetooth Local Name

Optio

nal





- Version: 1.3



- LE Device Address

- LE Role

- Temporary Key Value

- Hash C

- Randomizer R

- Appearance

- Local Name

Optio

nal




BR/EDR LE

51

Static Handover – NFC Tag

Handover Select Record

• The Handover Select Message stored on a

static NFC Forum Tag is a simplified version

of a Handover Select Message returned by

an active NFC Forum Device.

• All available carriers will be advertised since

the tag has no connection to the Bluetooth

radio

• Since data stored on an static tag cannot be

changed, the TK value, the Secure

Connections Randomizer and Confirmation

values are removed and a static private

address is used.


- Version: 1.3



- LE Device Address

- LE Role

- Appearance

- Local Name

Optio

nal




BR/EDR LE


- Version: 1.3





- Class of Device


- Bluetooth Local Name Optio

nal




ST25 products and demos

52

ST25R HF/NFC Frontends 53

ST25R95 ST25R3911B ST25R3912 ST25R3913 ST25R3916

Description Entry-Level NFC FrontendNFC Frontends

for Payment / Passport applicationsUltimate NFC Frontend

Reader/Writer modeISO14443A/B

ISO15693, Felica

ISO14443A/B

ISO15693, FeliCa

ISO14443A/B

ISO15693,FeliCa

ISO14443A/B

ISO15693,FeliCa

ISO14443A/B

ISO15693, FeliCa

Card emulation mode Yes (ST95HF) - - - Yes

P2P mode - Yes Yes Yes Yes

RF speed 848kbps 6.8Mbps (VHBR) 848kbps 848kbps 848kbps

Market certification -Payment (EMVCo, PBOC,

mini-pay)

Payment (EMVCo, PBOC,

mini-pay)

Payment (EMVCo, PBOC,

mini-pay)

Payment (EMVCo 3.0)

NFC Forum

Advanced features Ind wake-upAAT, DPO,

Cap & Ind wake-up

DPO,

Ind wake-up

AAT, DPO,

Ind wake-up

A²T, ANS, DSA, AWS, DPO

Cap & Ind wake-up

HW Interface SPI 2Mbps, UART SPI 6Mbps SPI 6Mbps SPI 6Mbps SPI 10Mbps

SW Interface Unified Software Library for Frontends

Power supply 2.7V - 5.5V 2.4V – 5.5V 2.4V – 5.5V 2.4V – 5.5V 2.4V – 5.5V

Output power 0.23W 1.4W 1.0W 1.0W 1.7W

Temperature range -25°C to +85°C -40°C to +125°C -40°C to +125°C -40°C to +125°C -40°C to +125°C

Package 32-pin QFN (5x5mm)32-pin QFN (5x5 mm)

Wafer

32-pin QFN (5x5 mm)

WLCSP32-pin QFN (5x5 mm)

32-pin QFN (5x5 mm)

WLCSP

VHBR: Very High Baud Rate

Cap & Ind wake-up: Capacitive & Inductive wake-up P2P: Peer to Peer mode

VHBR: Very High Baud Rate

AAT: Automatic Antenna TuningDPO: Dynamic Power Output

AWS: Active wave-shaping

ANS: Active Noise SuppressionDSA: Drive Slope Adjustment

ST25R Series Benefits

• The ST25R family is an integrated reader IC for contactless applications with several

benefits:

• Outstanding analog performance

• No external amplifier required to achieve high power and long range

• Automatic antenna tuning (3911B, 3913, 3916)

• Low power wakeup

• Excellent P2P interoperability

• Fast time to market

• EMVCo, NFC Forum, ISO, and MISRA-C:2012 compliant SW library

• Single SW library for all products

• Full integration into STM8 and STM32 eco system

• Proven solution

• Market proven solution in the consumer and automotive space

• Ensures best customer experience

54

NFC / RFID Tag Product Family 55

ST25TB512

ST25TB02K

ST25TB04K

ST25TA512B

ST25TA02KB

ST25TA02KB-D

ST25TA02KB-P

ST25TA16K

ST25TA64K

ST25TV512

ST25TV02K

ST25TV02K-AD ST25TV64K

Contactless Interface ISO14443BISO14443A

NFC Forum Type 4

ISO14443A

NFC Forum Type 4

ISO15693

NFC Forum Type 5

ISO15693

NFC Forum Type 5

RF rangeShort range

(up to 10cm)

Short range

(up to 10cm)

Short range

(up to 10cm)

Long range

(up to 100cm)

Long range

(up to 100cm)

RF speed 106kbps 106kbps 106kbps 26kbps (53kbps) 26kbps (53kbps)

Memory format EEPROM dataEEPROM

(preformatted NDEF)

EEPROM

(preformatted NDEF)

EEPROM

(preformatted NDEF)EEPROM data

Memory size 512-bit & 2k / 4k-bit 512-bit / 2k-bit 16k / 64k-bit 512-bit / 2k-bit 64k-bit

Data protection OTP bitsPassword 128-bit

Digital signaturePassword 128-bit

Password 64-bit

Digital signaturePassword 32-bit

Digital output NA

GPO Field detect

-P: CMOS_P

-D: Open-drain

NA Tamper Detect NA

Counter 32-bit (x2) 20-bit NA 16-bit NA

RF tuning capacitor 64pF 50pF 25pF 23.5pF & 97pF 28.5pF

Temperature range -40°C to +85°C -40°C to +85°C -40°C to +85°C -40°C to +85°C -40°C to +85°C

Package SBN12 *SBN12 * / SBN075 ² FPN5

(1.7x1.4mm)SBN12 * SBN12 * / SBN075 ² SBN12 *

* SBN12: Die form, sawn and Bumped wafer, 120µm thickness, inkless 8” wafer

² SBN075: Die form, sawn and Bumped wafer, 75µm thickness, inkless 8” wafer

Dynamic NFC / RFID Tags 56

M24SR series ST25DV-I2C series

Contactless InterfaceISO14443A

NFC Type 4

ISO15693

NFC Type 5

RF range Short range (up to 10cm) Long range (up to 1m)

RF speed 106kbps 26kbps

Serial Interface I2C @1MHz I2C @1MHz

Fast Transfer mode No Yes (256B buffer)

Energy Harvesting No Yes

Digital output Open-Drain GPO OD or CMOS GPO

Extra features RF Disable Low Power mode

Memory format EEPROM (preformatted NDEF) EEPROM data

Memory size 2k / 4k / 16k / 64k-bit 4k / 16k / 64k-bit

Data protection Password 128-bit Password 64-bit

Temperature range-40°C to +85°C

-40°C to +105°C (85°C RF)

-40°C to +85°C

-40°C to +125°C (105°C RF)

PackageSO8 / TSSOP8 /

FPN8 / SBN12 *

SO8 / TSSOP8 / FPN8 /

FPN12 / WLCSP10 / SBN12 ²

² SBN12: Die form, sawn and Bumped wafer, 120µm thickness, inkless 8” wafer

ST25DV-I2C Evaluation Boards 57

• ST25DV04K Dynamic NFC tag IC

• 40x24mm 10 turns antenna (ANT Class5)

• STM32F405 MCU• 2.4” TFT LCD Touch screen

• I2C & SWIP connectors

• Daughter board connector

ST25DV-I2C discovery kit

ST25DV-DISCOVERY X-NUCLEO-NFC04A1 ANT-1-6-ST25DV


• Ø54mm 8 turns single layer antenna etched

• Energy harvesting, Low Power mode, GPO• Compatible with STM32 Nucleo boards

• I2C interface to MCU & Powered through

Arduino™ connector

ST25DV-I2C Nucleo shield


• Ready-to-use PCB including:

• 45x75mm (ST25DV_Discovery_ANT_C1)

• 18x24 mm (ST25DV_Discovery_ANT_C6)

• Energy Harvesting output (Vout)

• Mates with ST25Dx_Discovery MBoard

ST25DV-I2C Antenna kit

For ST25DV-Discovery Board

Bluetooth Modules 58

BluNRG-M0

BT v4.2 Module

BluNRG-M2

BT v5.0 Module

https://www.st.com/content/st_com/en/products/wireless-transceivers-mcus-and-modules/bluetooth-bluetooth-low-energy/bluenrg-m0.html




CR95HF*/ST25R95 Evaluation Boards 59

M24LR-DISCOVERY KIT X-NUCLEO-NFC03A1

• CR95HF NFC multi-protocol reader IC

• 47x34 mm 2 turns double layer antenna

etched on PCB and associated tuning circuit• STM32F1 micro-controller

• USB & JTAG connectors

CR95HF demo board

• ST25R95 NFC multi-protocol reader IC

• 47x34mm 4 turns antenna etched on PCB

• SPI (Slave interface) or UART • Up to 528-byte command/reception buffer

• Optimized power management

• Powered through Arduino™ UNO R3

connector

ST25R95 Nucleo shield

* The ST25R95 and the CR95HF are equivalent

ST25R3911B Evaluation Boards 60

• ST25R3911B HF reader / NFC initiator IC

• 105x52mm 2 turns antenna and associated

VHBR tuning circuit• STM32L476RET6 32-bit MCU

• Micro-USB connector

• Additional UART / I²C Host interfaces, as

well as NFC SPI and JTAG/SWD points

ST25R3911B discovery kit

ST25R3911B-DISCO X-NUCLEO-NFC05A1 ST25R3911B-EMVCO


• 47x34mm 4 turns antenna

• Compatible with STM32 Nucleo boards• Equipped with Arduino™ UNO R3 connector

ST25R3911B Nucleo shield board


• 65x74mm 2 turns antenna etched on PCB

• STM32L476 32-bit MCU• Micro-USB connector

• Comprehensive Device Test Environment

(DTE) for EMVCo Level 1 FW control

• S-Touch controller

ST25R3911B EMVCo Demo kit

ST25R3911B discovery kit and Nucleo shield are also valid for ST25R3912, ST25R3913, ST25R3914 and ST25R3915

ST25 Software Development Kit 61

Create your own NFC JAVA application

Android app

(with tutorial)

PC SW app

(with tutorial)

ST25 lib

Javadoc files

st25sdk jar

Reader lib

javadoc files

reader jars reader dll/so

Data Brief

User Manual

dll: dynamic link library (for Windows)

so: shared object (dynamic library for Linux)

https://www.st.com/st25sdk

https://www.st.com/en/embedded-software/stsw-st25sdk001.html

Tag Info NDEF CC File System File Memory Contents

Android Tap App 62

iOS Tap App 63

ST25 Simply More Connected

Thank You!

Documents

Secure Bluetooth Pairing Made Easy Using NFC · 2019-12-30 · Secure Bluetooth Pairing Made Easy Using NFC RFID and Memory Division December 2019. What is NFC? 2. NFC Technology