Symmetry Blue BLE Detailed Security

Introduction

The Symmetry Blue mobile application uses Bluetooth Low Energy to communicate with compatible
access readers. The app makes use of the BLE APIs provided by mobile operating systems to transmit a
UID stored on the device. This UID is generated per application install and is enrolled within the Symmetry system.

Once enrolled in the system, a mobile device holder can authenticate with readers using the Symmetry
Blue mobile application as if it were an NFC card. While running, the application works both in the
foreground and background until explicitly terminated by the user.

Entities

Mobile Device

A mobile phone equipped with a BLE radio capable of communicating with readers. The Symmetry Blue
mobile application makes use of the BLE APIs provided by its respective operating system.

The Mobile device takes on the BLE central role or “client” in the transaction, meaning it initiates all
connections with readers and negotiates communication parameters. All BLE operations are dictated by
the Symmetry Blue mobile application and isolated from the specific BLE hardware used by the mobile
device.

Reader

A Symmetry Blue reader which provides a specific BLE profile for communication with mobile devices.

The reader takes on the BLE peripheral role or “server” in the transaction. The reader periodically
advertises its presence to nearby mobile devices, which use the advertisements to initiate a connection.
These advertisements contain data about the reader including its name, supported capabilities, address,
and signal strength. Once a connection is established, the reader controls the operations a mobile device
can perform and may terminate the connection at any time.

UID Assignment

Each mobile application is assigned a UID upon installation. This UID is stored until the app is removed by
the user. Symmetry Blue uses a 32 bit UID for each device, with a maximum of 9 decimal digits. The
assignment of a UID to a device forms a mapping between the UID and the base identifier of the device.
Depending on the device’s operating system, the base identifier is retrieved in the following ways:

iOS

https://developer.apple.com/reference/uikit/uidevice/1620059-identifierforvendor

Android

https://developers.google.com/instance-id/guides/android-implementation

Session Key Generation

Session key generation takes place using a standardized ECDH exchange between the mobile app and
reader. A new public/private keyset is generated by both entities for each transaction in order to guard
against the possibility of a replay attack.

After the two entities exchange public keys, they both calculate a shared secret. This shared secret is then
passed through a key derivation function in order to generate the session key for the transaction. The
following explains this process in detail:

Diffie-Hellman Exchange

1. Both entities generate their ECDH parameters using the secp256r1 curve for one time use during the
    transaction.
            a. Public Key: 64 bytes
            b. Private Key: 32 bytes
2. Entities exchange their compressed public keys.
            a. Compressed Public Key: 33 bytes
3. Entities calculate their ECDH shared secret using their private key, and the other’s public key.
            a. Shared Secret: 32 bytes

Deriving the Session Key

1. Both entities pass the calculated shared secret as input material into an HKDF using a SHA-256
    hashing function.
2. The outputted value is used as the session key for the transaction.
            a. Session Key: 16 bytes

Encryption

All BLE communication between the mobile application and reader is secured via AES 128 encryption with
CBC using a fixed IV. The 128 bit key is generated per transaction and is derived using the previously
outlined method, allowing the two devices to agree upon a shared secret for each connection while
guarding against MITM attacks. This method also avoids the storage of any sensitive information on mobile devices, which are extremely vulnerable to malicious entities.

All encryption is handled by the mobile application and is separate from any BLE communication protocol
or built in security implemented by the BLE stack. This is because the standard BLE pairing and bonding
procedures are susceptible to MITM attacks, especially for this use case, where transactions are initiated
with many readers out in the open.

Transaction

The following is a high level overview of a typical transaction between a Mobile Application and Reader.
Specifics on the BLE protocol can be found at:

https://www.bluetooth.com/specifications/bluetooth-core-specification

Identification

1. App begins by performing a BLE scan for reader advertisements. Readers are identified by their name
    and supported BLE capabilities.
2. App keeps track of all nearby readers and only initiates a connection when it receives a reader
    advertisement with a signal strength above a threshold value. This equates to a distance in the range
    of 6-12 inches. The app will not attempt to authenticate with readers outside this vicinity.

Connection

3. Once a reader advertisement is discovered within connection range, the app attempts to open a
    connection with the reader based on the parameters provided in its advertisement.
4. App negotiates BLE connection parameters with the reader and discovers its BLE
    services/characteristics. Once this is complete, the two entities can now communicate.

Key Generation

5. Both entities generate a new ECDH public/private keyset using the secp256r1 curve.
6. App sends the reader its compressed 33 byte public key.
7. Reader replies with its own public key.
8. Both entities calculate the shared secret.
9. Both entities then pass the shared secret through an HKDF using SHA-256. The 128 bit output value
    is used as the session key for the transaction.

Data Transfer

10. App sends the reader its stored UID encrypted with the derived session key. This is done using AES
     128 with CBC and a fixed IV.
11. Once all data has been received and verified by the reader, it can transmit the UID.

Disconnection

12. App terminates the BLE connection once the transmission is complete.
13. Both entities forget the generated session key.

Additional Security Measures

In addition to securing the actual packets which are transmitted, the reader also limits interactions with
mobile devices. A time limit is placed on all connections, which are terminated if they exceed the allowable limit. This eliminates the possibility for DNS attacks where a malicious entity could hold a connection indefinitely, blocking all others from authenticating with the reader. If any mobile device attempts to pair, bond, or send invalid packets to the reader, the connection is also immediately terminated, blocking any attempts to “probe” the reader’s BLE implementation.

Abbreviations used in this document

Abbreviation	Definition
BLE	Bluetooth Low Energy
AES	Advanced Encryption Standard
CBC	Cipher Block Chaining
MITM	Man in the Middle
DNS	Denial of Service
ECDH	Elliptical Curve Diffie-Hellman
UID	Universal Identifier
IV	Initialization Vector