louisabricot/writeup-cve-2019-19194A writeup and theoretical Proof-of-Concept for CVE-2019-19194
This is a writeup and theoretical Proof-of-Concept of CVE-2019-19194.
⚠️ This CVE was found by https://asset-group.github.io/disclosures/sweyntooth/
This report describes how the Zero LTK Initialisation vulnerability (CVE-2019-19194) allows an attacker full communication control over Bluetooth Low Energy (BLE) application by bypassing the Secure Connections pairing procedure.
This vulnerability affects products using the Telink SMP implementations that support the Secure Connections pairing procedure.
BLE is a low-consumption, short-range radio communication system. It consists in a set of standardized protocols that provide remote connectivity and security between two devices.
The BLE stack is distributed across two architectural blocks: Host and Controller.
The stack distribution allows to implement each block in physically separate components.
A standard logical interface named the Host Controller Interface (HCI) allows communication between the two blocks.
On top of the Host block sits the BLE application.
The physical layer operates in the Industrial, Scientific and Medial (ISM) radio band, across the 2.4GHz spectrum. It uses 40 channels: 3 advertising channels and 37 data channels.
The link layer (LL) has many responsibilities which will not be described here. It is governed by a state machine which defines important roles and states:
The logical link control and adaptation protocol acts as a protocol multiplexing layer. It handles fragmentation and recombination of packets between the layers below and above.
The Generic Access Profile concerns device discovery and connection. In other words, GAP defines procedures for the transmission of advertising packets and their reception through scanning.
Once a connection between two BLE devices has been established, GATT uses a client/server model to exchange data between the two devices. And both client and server use the Attribute Protocole (ATT).
The SM supports security-related procedures such as pairing, bonding and key distribution. Device pairing is considered as the foundation of Bluetooth security: once paired, the two devices can encrypt their communication, authenticate each other, ...
Among the different protocols involved in BLE communication, the zero LTK installation CVE happens during the pairing procedure, in the Secure Connections mode.
The Secure Connections pairing mode is the "more secure approach" and was developed to solve the weaknesses of Legacy mode. However, the zero LTK installation CVE found that bad implementations of SC pairing allow to bypass security.
The central device sends a pairing request and both devices exchange on their security capabilities and requirements. This phase defines the pairing mode.
Public Key exchange: An exchange of public keys is initiated by the Central device. Both peripheral and central verify that their received key is on the P-256 curve.
Calculating the DHKey: Each device uses its own private key (SK) and the public key of the other device (PK) to calculate their Diffie-Hellman key (DHKey). This way both device posess the same DHKey value.
Central: DHKey = p256(SKc, PKp)
Peripheral: DHKey = p256(SKp, PKc)
If MITM protection was requested, an interactive procedure takes place to confirm the authenticity of the pairing devices.
Calculating the Long Term Key (LTK) and mutual confirmation: The devices authenticate each other and calculate a LTK key. A session key is derived from the LTK in order to encrypt the link before Phase 3.
Through the encrypted link, the devices can distribute keys.
The root cause of zero LTK installation is that there is no check of the state in which the two devices are in the pairing procedure. As such, an attacking central device can skip the key generation and authentication step. This results in a LTK key set at 0 in the peripheral device, and as such, an easily derivable session key.
⚠️ This is a fully theoretical Proof-of-Concept as I was not able to get a pcap of BLE discovery, advertisement or pairing procedures, nor did I have a BLE device with Telink SMP implementation.