CVE-2019-9506

Executive Summary

CVE-2019-9506, also known as "KNOB" (Key Negotiation Of Bluetooth), is a specification-level vulnerability in the Bluetooth BR/EDR standard that allows an attacker to influence the encryption key length negotiation process during device pairing. The Bluetooth BR/EDR specification up to and including version 5.1 does not mandate a sufficiently high minimum encryption key length, and does not prevent an attacker from actively interfering with the key negotiation exchange. This enables an unauthenticated, remote attacker within radio range to force both paired/successfully paired devices to derive a short encryption key (as low as 1 byte, or 8 bits of entropy) that can be feasibly brute-forced in real time, allowing the attacker to decrypt intercepted traffic and inject arbitrary ciphertext into the ongoing connection without either device detecting the compromise. The vulnerability affects any device that implements the Bluetooth BR/EDR specification — including smartphones, laptops, IoT devices, headsets, and vehicles — and received a CVSS base score of 7.6 (High) reflecting high confidentiality and integrity impact. While the Bluetooth SIG issued an expedited errata correction, the patch is a specification-fix only; successful remediation requires both participating devices to implement the corrected specification.

Technical Analysis

The KNOB vulnerability is fundamentally a design flaw in the Bluetooth BR/EDR specification rather than an implementation bug in any particular vendor's Bluetooth stack. The vulnerability mechanism can be understood at three distinct levels: the key generation algorithm, the negotiation protocol, and the absence of security checks enforcing a minimum entropy threshold.

Key Generation Mechanism. The Bluetooth BR/EDR encryption key used to protect a connection is derived using the E0 stream cipher for legacy pairing or the SAFER+ block cipher for Secure Simple Pairing. The cipher produces an encryption key whose length, ℓ, is negotiated between the two devices during the pairing process. Crucially, the specification permitted the negotiated key length to be as low as 1 byte (8 bits), under the assumption that the cost of brute-forcing such short keys would be prohibitively high for real-time attackers. The E0 cipher operates in a mode where the key register is clocked with the negotiated key length; shorter keys result in a smaller effective state, dramatically reducing the keyspace that must be searched.

Negotiation Protocol Flaw. During the pairing process, the two devices exchange a series of "Encryption Key Size" commands to agree on the key length. Specifically, in the "Link Key" and "Encryption Setup" procedures, one device (typically the master) proposes a key length, and the other device (slave) responds. The KNOB vulnerability is that neither the specification nor the protocol mandates a floor on the smallest acceptable key length. An attacker who is able to intercept and modify the pairing traffic — which is feasible because the negotiation messages are exchanged over an unencrypted, unauthenticated channel before encryption is activated — can tamper with these messages to truncate the negotiated key length down to its minimum value of 8 bits. The attacker does not need to defeat any cryptographic primitives at this stage; they simply manipulate the plaintext negotiation messages (e.g., by jamming the original response and replaying a modified one) to force the devices to accept a weak key of their choosing.

Attack Feasibility. Because the E0 cipher compresses the effective key size to the negotiated ℓ bits, a brute-force attack on an 8-bit key requires at most 256 attempts, which is trivially feasible in real time with off-the-shelf hardware (e.g., a single FPGA or GPU can test millions of keys per second). Even at the next allowed size of 16 bits, the search space of 65,536 keys can be exhausted in seconds. Once the correct key is recovered, the attacker can decrypt all intercepted LE or BR/EDR encrypted packets and — because the E0 cipher operates in a stream-cipher mode where the keystream is XORed with the plaintext — the attacker can also flip arbitrary bits in the ciphertext to inject crafted payload data, all without the end devices detecting that their plaintext has been modified.

Attack Surface. The vulnerability is exploitable only when both devices have already completed the connection and pairing setup over the air; the attack is a Man-in-the-Middle (MitM) on the pairing exchange. The attacker must be within the Bluetooth radio range of both victim devices (typically 10–100 meters depending on class), and must be able to perform active packet injection and jamming to interfere with the negotiation. No prior authentication or knowledge of the devices' link keys is required, which makes the attack fully unauthenticated from the attacker's perspective.

Specification Coverage. The NVD description explicitly states the flaw affects the BR/EDR specification "up to and including version 5.1." The Bluetooth SIG issued an Expedited Errata Correction (EEC 11838) that updates the specification to mandate that the minimum negotiated key length be 7 bytes (56 bits) and requires both devices to reject any negotiation attempt that results in a shorter key. However, this errata only updates the paper specification; the actual security depends on whether device firmware implements the corrected constraints. As of the NVD data, no specific affected version ranges for individual vendors are listed, and the Workarounds field explicitly references the Bluetooth SIG errata, confirming that the primary fix is specification-level.

Exploitation Scenarios

No public PoC exploit code is available for CVE-2019-9506 as of the current data; the exploitation chain below is inferred from the vulnerability class and the academic presentation of the KNOB attack. The attack chain follows a classic MitM pattern over the Bluetooth radio channel.

Step 1: Reconnaissance and Target Identification. The attacker must first identify two devices that are about to initiate a BR/EDR pairing or are re-pairing (e.g., a user connecting a new headset to a smartphone, or a smart speaker joining a Wi-Fi/BT network). Using a Bluetooth-enabled radio (e.g., a USB dongle with firmware capable of packet injection and promiscuous mode), the attacker scans for the inquiry/connectivity packets. The attacker can also force a re-pairing event by conducting a deauthentication or jamming attack against an existing connection to cause both devices to renegotiate the link key, which is a common automated retry behavior.

Step 2: Triggering the Flaw (Key Length Negotiation Interference). Once the victim devices begin the pairing process, the attacker positions itself as a MitM by spoofing the identity of the master device to the slave and vice versa. The negotiation of the encryption key size occurs through the exchange of LMP (Link Manager Protocol) messages — specifically, the "LMP_encryption_key_size_req" and "LMP_encryption_key_size_res" commands. Because these messages are transmitted in the clear before encryption is applied, the attacker intercepts the legitimate response from the slave (which may propose a 16-byte / 128-bit default key) and replaces it with a forged response that requests the minimum key length allowed by the specification (e.g., ℓ = 1 byte). Both devices are compliant with the specification, so they accept the truncated key length without checks, since neither is aware of the attacker's tampering. This step is the core of the KNOB exploit: a direct manipulation of the plaintext negotiation data.

Step 3: Payload Execution and Key Recovery. After the devices derive the short encryption key, the attacker passively captures the first few frames of encrypted traffic. Because the E0 stream cipher uses the derived key directly, the attacker can exhaustively search the 256 (or 65,536) possible keys off-line. Upon recovering the correct key, the attacker now possesses the session encryption key. In the context of the attack, the "payload" is not a typical executable trojan; rather, it is arbitrary data injection. Since E0 is a synchronous stream cipher, the attacker can XOR specific bit patterns into the ciphertext stream to alter plaintext in transit (e.g., injecting an unexpected command, changing a URL, or sending a malicious SMS content to an IoT device). The attacker can also record decrypted traffic passively to exfiltrate sensitive data such as keystrokes, authentication tokens, or files transferred over the BR/EDR channel.

Step 4: Post-Exploitation Impact. The immediate post-exploitation effect is dual: confidentiality loss (the attacker has continuous visibility of all decrypted payloads) and integrity loss (the attacker can inject arbitrary ciphertext that the receiving device will accept as authentic). This persists for the duration of the encrypted session. Since the negotiated key is fixed for the session, the attacker maintains access until the pairing is torn down. The attack does not yield persistent control or code execution, but it is practically "blinding" — devices never detect the integrity breach because no message authentication or integrity checking is performed over the E0-encrypted payloads in BR/EDR (the integrity protections exist only at higher protocol layers, which may or may not be implemented on the target device). If the attacker can chain this into hijacking a higher-level session (e.g., an HID keyboard connection), they may be able to inject keystrokes that trigger arbitrary command execution on a connected computer or IoT hub.

Impact Assessment

The business impact of CVE-2019-9506 is significant despite the attack requiring physical proximity and active radio interference. The CVSS base score of 7.6 (with a vector of AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) reflects the following metrics: Attack Vector is Adjacent (AV:A — the attacker must be in the same broadcast domain, i.e., within Bluetooth range), Attack Complexity is High (AC:H — requires successful manipulation of live radio traffic and timing), Privileges Required is None (PR:N), User Interaction is None (UI:N), Scope is Unchanged (S:U), Confidentiality impact is High (C:H), Integrity impact is High (I:H), and Availability impact is None (A:N). This translates to a High severity rating.

The blast radius is broad because BR/EDR is present in virtually every modern laptop, smartphone, tablet, wearable, vehicle telematics unit, and a vast ecosystem of IoT peripherals, audio devices, and industrial equipment. The affected version range is a specification-level statement ("up to and including 5.1"), meaning that no vendor-specific version filters apply; every device that does not implement the EEC 11838 correction is vulnerable. Especially at risk are environments that rely on Bluetooth for sensitive data transfer without additional layer-7 encryption (e.g., medical device telemetry, point-of-sale terminals using BR/EDR for terminal-to-base communication, or legacy industrial control systems with Bluetooth commissioning links).

From a threat modeling perspective, the EPSS score of 0.02691 (84.5% percentile of exploited CVEs) places this vulnerability in the category of CVEs with a relatively high likelihood of being exploited in the wild, even though CISA KEV currently marks it as not included, meaning it is not yet known to be leveraged in major attacks. The practical attack cost is low (off-the-shelf Bluetooth adapters + open-source software), making it an attractive target for targeted surveillance or espionage against high-value individuals (journalists, executives) in public venues such as cafés, airports, or conference rooms. There is no evidence of nation-state actor campaigns specifically leveraging this CVE at the time of reporting, but the technique has been demonstrated in academic research (the KNOB paper) and is well-documented in public threat intelligence, making it a likely candidate for adoption by APT groups seeking covert MitM capabilities on Bluetooth-dependent environments.

Detection Guidance

The following detection rules are reference implementations for logging and alerting on suspicious Bluetooth activity. Because KNOB is a radio-layer attack, detection is challenging at the network/endpoint level; these rules focus on observable operational events (e.g., pairing anomalies, short-key negotiation logs, or Bluetooth stack error messages).

Sigma Rule

title: Bluetooth BR/EDR Key Length Negotiation Below 56 Bits (KNOB)
id: 4a2f2e7c-9d5e-4c99-b84e-8b9d09d41c3e
status: experimental
description: Detects Bluetooth devices logging an encryption key length negotiation that results in a key shorter than the post-errata minimum (7 bytes / 56 bits).
author: valtersit.com Threat Intel
logsource:
    category: application
    product: bluetooth
    service: stack
detection:
    selection:
        EventID:
            - 'LMP_encryption_key_size_req'
            - 'LMP_encryption_key_size_res'
            - 'HCI_Encryption_Change_Event'
        key_length_bytes:
            - '1'
            - '2'
            - '3'
            - '4'
            - '5'
            - '6'
    condition: selection
falsepositives:
    - Legacy devices with intentionally short keys (pre-2019 firmware).
level: high

YARA Rule

rule KNOB_Bluetooth_Key_Negotiation_ShortKeyAlert
{
    meta:
        author = "valtersit.com Threat Intel"
        description = "Detects Bluetooth BER/EDR connector logs or pcap markers indicating a negotiated encryption key of 8-48 bits."
        cve = "CVE-2019-9506"
    strings:
        $s1 = "LMP_encryption_key_size_res" ascii wide
        $s2 = "key_length=1" ascii wide
        $s3 = "key_length=2" ascii wide
        $s4 = "encryption_key_size=1" ascii wide
        $s5 = "encryption_key_size=2" ascii wide
        $s6 = "NEGOTIATED_KEY_LENGTH_" ascii wide
    condition:
        (any of ($s1*)) and (any of ($s2*,$s3*,$s4*,$s5*,$s6*))
}

Suricata IDS Rule

alert ip any any -> any any (msg:"BLE/BR-EDR KNOB key-negotiation packet with short key size"; content:"1"; content:"LMP_encryption_key_size"; sid:10000001; rev:1; classtype:attempted-user; priority:1;)

Note: Suricata does not natively parse LMP; this rule is a placeholder heuristic targeting clear-text LMP packet payloads that may be observed in a metered Bluetooth-to-Ethernet bridging scenario. In practice, deploy a Bluetooth sniffer (Ubertooth) feeding Zeek or Suricata with a custom LMP parser.

Elastic Detection

sequence by host.hostname
  [ any where event.action == "pairing_event" and
      bluetooth.pairing.key_size_bytes <= 6 ]
  [ any where event.action == "connection_established" and
      bluetooth.connection.channel == "BR/EDR" ]

Splunk SPL Query

index=bluetooth_logs sourcetype="bluetooth:stack"
| where 'LMP_encryption_key_size_res' OR event_code = "hci_encryption_change"
| eval key_bits = coalesce(key_length_bits, key_length_bytes * 8)
| where key_bits < 56
| stats count by src_device, dest_device, key_bits, _time
| table _time, src_device, dest_device, key_bits, count

Wazuh OSSEC Rule

<group name="bluetooth_knob,">
    <rule id="120010" level="15">
        <if_sid>500</if_sid>
        <match>key_length_negotiated|key_length_bytes|LMP_encryption_key_size_res</match>
        <regex>key_length_bytes\s*[=:]\s*[1-6]\b</regex>
        <description>Bluetooth BR/EDR key negotiation below 56 bits detected (KNOB, CVE-2019-9506)</description>
        <mitre>\ 
            <id>T1457</id>\ 
            <tactic>Collection</tactic>\ 
        </mitre>\ 
    </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY). Two independent sources (the CNA and Debian) confirm the availability of a fix, but implementation must occur at the device-firmware level; no single remote patch resolves this for arbitrary deployed hardware.

Immediate Mitigations (within 24–72 hours):

1. Disable BR/EDR where not required. For enterprise fleets, configure hardware to use Bluetooth Low Energy (BLE) solely, or disable Bluetooth entirely on devices that do not need it.
2. Force re-pairing with key length validation. In environments with managed endpoints (e.g., MDM), push profiles that set a policy requiring a minimum encryption key length of 56 bits; some Bluetooth stacks exposed via OS APIs allow a min_enc_key_size policy (e.g., Android's setOutOfBandData or Linux's hciconfig lpkey parameter can enforce this only if supported).
3. Enforce additional layer-7 encryption. For sensitive data transfer over BR/EDR, leverage application-level TLS/DTLS or similar, so that even if the Bluetooth link key is brute-forced, the payload remains encrypted.
4. Monitor pairing logs. Apply the Sigma/Splunk rules above to detect any log entry indicating a short key negotiation on managed devices; treat any such event as a potential KNOB compromise.

Patch/Upgrade Steps:

1. Update Bluetooth firmware/driver. Apply vendor-published firmware updates that implement Bluetooth SIG EEC 11838. This includes updates for major OSes (iOS 13+ / Android 10+ for most devices, Linux BlueZ >= 5.50 with backported patches, Windows 10 1903+ cumulative updates). Confirm the device's Bluetooth stack version against the vendor's advisory table.
2. Apply OS/distribution patches. Debian and Ubuntu have applied fixes to the bluez package; ensure bluez version is > 5.50. For Android, verify that the SoC vendor (Qualcomm, Broadcom, etc.) has shipped the relevant kernel driver patch.
3. Re-pair all devices after patching. After updating firmware, erase existing paired profiles and force a fresh pairing session, so that new keys are generated under the corrected minimum-length constraint.

Long-Term Hardening:

1. Adopt Bluetooth 5.2+ hardware. The Bluetooth 5.2 core specification incorporates the KNOB fix; plan hardware refresh cycles accordingly.
2. Segment Bluetooth access. In enterprise offices, place Bluetooth-augmented infrastructure in controlled zones and consider RF shielding or dense spectrum monitoring in high-risk areas.
3. Use Secure Simple Pairing (SSP) with numeric comparison. Where possible, enable SSP in "Just Works" mode with Numeric Comparison, which adds a user-verifiable out-of-band confirmation step, making MitM negotiation tampering more detectable.
4. Conduct periodic Bluetooth security audits. Perform passive RF sniffing with tools like Ubertooth or a software-defined radio to detect devices negotiating sub-56-bit keys on the perimeter.

References

1. NVD Entry (CVE-2019-9506): https://nvd.nist.gov/vuln/detail/CVE-2019-9506
2. Bluetooth SIG Security Advisory (EEC 11838): https://www.bluetooth.com/learn-about-bluetooth/key-attributes/bluetooth-security/ (direct link to the KNOB erratum)
3. Original KNOB Research Paper (Antonioli, Tippenhauer, Rasmussen): "The KNOB is Broken: Exploiting Low Entropy in the Encryption Key Negotiation of Bluetooth BR/EDR" — USENIX Security 2020. https://www.usenix.org/conference/usenixsecurity20/presentation/antonioli
4. CISA Known Exploited Vulnerabilities Catalog (CVE-2019-9506): https://www.cisa.gov/known-exploited-vulnerabilities-catalog (listed as NOT in KEV as of last check)
5. Debian Security Tracker for CVE-2019-9506: https://security-tracker.debian.org/tracker/CVE-2019-9506

Threat Activity Notes: No specific threat actor has been publicly attributed to exploiting CVE-2019-9506 in the wild as of the last query against the CISA KEV list, which reports this CVE as NOT included. Public exploit code is not known; the only demonstration is in the academic KNOB research, published with limited tooling (a Python-based proof-of-concept was demonstrated in the paper, but not released publicly). EPSS at 0.02691 (84.5th percentile) suggests that while not currently actively exploited, the vulnerability is in the upper percentile of predicted exploitability and should be treated as high-priority for patching in Bluetooth-heavy environments.