Bluetooth ve Sürümleri, Saldırılar ve Güvenlik Duvarı Bluetooth and Its Versions, Attacks and Firewall Bluetooth und seine Versionen, Angriffe und Firewall

Bluetooth Güvenliği: Sürümler, Saldırılar ve Güvenlik Duvarı Gerçeği

Bluetooth çoğu kişi için “açıp kapattığımız bir düğme”. Güvenlik uzmanları için ise yirmi yıldır araştırılan, hâlâ yeni açıkların çıktığı geniş bir protokol ailesi. Ocak 2026'da ortaya çıkan Whisper Pair, Bluetooth’un kendisinin değil, onu uygulayan ürünlerin sorunlu olduğunu bir kez daha gösterdi. Bu yazıda sürümleri, saldırı sınıflarını ve çoğu kişinin yanlış bildiği güvenlik duvarı konusunu ele alıyoruz.

Temel Fikir: Güvenlik Üç Katmanda Çözülür

Bir Bluetooth bağlantısının güvenliği üç şeye bağlıdır:

Eşleştirme (pairing): İki cihazın birbirini tanıması ve ortak anahtar üretmesi. Anahtar anlaşması: Her bağlantıda kullanılacak oturum anahtarının belirlenmesi. Uygulama (implementation): Üreticinin yazdığı yazılımın standardı doğru uygulaması.

Saldırılar bu üç katmandan birini hedefler. Aşağıda göreceğiniz gibi, en çok sorun üçüncü katmanda, yani üretici hatalarında çıkıyor.

Bluetooth Sürümleri: Artılar ve Eksiler

Sürüm Artıları Eksileri 1.x – 2.0 (1999-2004) Basit, düşük maliyetli Eski PIN tabanlı “legacy” eşleştirme, zayıf. Geriye uyumluluk nedeniyle bugün hâlâ cihazlarda duruyor. 2.1 + EDR (2007) Secure Simple Pairing (SSP) getirdi, formal olarak doğrulandı “Just Works” modu aktif ortadaki adam saldırısına açık 4.0 (2010) Bluetooth Low Energy (BLE), düşük güç, AES-128 BLE’nin ilk eşleştirmesi (LE Legacy Pairing) temelden zayıf kabul ediliyor 4.1 / 4.2 (2013-14) 4.2'de LE Secure Connections (ECDH P-256), gelişmiş gizlilik Güvenli mod zorunlu değil, aşağı çekme saldırılarına açık 5.0 – 5.3 (2016-21) 4 kat menzil, 2 kat hız, LE Audio (5.2) Güvenlik modeli 4.2 ile aynı. Menzil arttıkça saldırgan için etki alanı da büyüyor. 5.4 (2023) Şifreli reklam verisi (EAD), PAwR Her cihaz bu özelliği desteklemiyor 6.0 – 6.2 (2024-25) Channel Sounding ile güvenli mesafe ölçümü, 6.1'de rastgeleleştirilmiş RPA, 6.2'de genlik saldırılarına dayanıklılık Özellikler opsiyonel, her “6.0” cihaz bunları içermez. Bazıları donanım gerektirir, yazılım güncellemesiyle eklenemez.

Burada çoğu kişinin bilmediği üç nokta var:

Sürüm numarası güvenlik garantisi değildir. Bluetooth SIG’nin kendi açıklamasına göre yeni sürümlerin özelliklerinin çoğu opsiyoneldir. Kutuda “Bluetooth 6.0” yazması, Channel Sounding desteği anlamına gelmez.

Bazı saldırılar sürüm fark etmez. Aşağıda anlatacağımız KNOB araştırması, aşağı çekmenin cihazın işletim sisteminden, yongasından, rolünden ve sürüm numarasından bağımsız çalıştığını gösterdi. Çünkü zayıflık, standardın anahtar anlaşması mantığında.

Yeni özellik yeni saldırı yüzeyi demektir. Channel Sounding, güvenli mesafe ölçümü için tasarlandı ama aynı hassasiyet, doğru yönetilmezse takip için de kullanılabilir. Bu nedenle 6.1'deki rastgeleleştirilmiş adres özelliği önemli.

Saldırı Sınıfları: Hangi Katmana Vuruluyor?

Aşağıdaki sınıfları mekanizma düzeyinde anlatıyorum.

1. Anahtar Anlaşması Zayıflatma (KNOB, BIAS, BLUFFS)

Daniele Antonioli’nin araştırmaları bu alanın en önemli çalışmalarıdır. KNOB, anahtar uzunluğu pazarlığının doğrulanmamasından yararlanır. Klasik Bluetooth’ta oturum anahtarının 1 bayta, BLE’de 7 bayta kadar düşürülebileceği gösterildi. Üstelik bu davranış standarda uygun. Yani üreticinin hatası değil, tasarımın sonucu.

BIAS, daha önce eşleşmiş bir cihazı taklit etmeyi mümkün kılar. BLUFFS (CVE-2023-24023) ise bu ikisini birleştirir. Daha önceki ve sonraki oturumların gizliliğini (forward ve future secrecy) hedef alır ve Secure Connections’ı daha zayıf moda düşürebilir. Etkilediği aralık Bluetooth 4.2'den 5.4'e uzanır. Savunmada temel fikir, minimum anahtar uzunluğunu zorunlu kılmaktır. Espressif gibi üreticiler bunu yamalarında minimum 7 bayt olarak uyguladı. Ama araştırmacıya göre 7 bayt hâlâ ideal değil.

2. Eşleştirme Mantığı Hataları

“Just Works” modu kullanıcıya doğrulama sormaz ve aktif ortadaki adam saldırısına karşı koruma sunmaz. Out-of-Band yöntemi (örneğin NFC ile anahtar aktarımı) ise bu saldırılardan etkilenmez, çünkü anahtar Bluetooth dışında bir kanaldan geçer. Method Confusion araştırması da ilginç bir noktayı gösterdi: Passkey ve Numeric Comparison yöntemlerinde kullanıcı, iki cihazın farklı yöntemler kullandığını fark edemeyebilir.

Android’in BLE çerçevesi üzerine yapılan bir çalışma da, “Secure Connections Only” modunun tek taraflı olduğunu gösterdi. Standart, başlatan cihazın bu

modu desteklemesini zorunlu kılmıyor. Bu da karşı tarafın güvenli ayarlarını anlamsız kılabiliyor.

1. Uygulama Hataları: En Verimli Alan

2026'nın en çok konuşulan örneği Whisper Pair (CVE-2025-36911). KU Leuven araştırmacıları 16 üreticiden 25 ticari cihazı ve 17 farklı Bluetooth yongasını test etti. Google Fast Pair spesifikasyonu, aksesuarın eşleştirme modunda değilse istekleri yok saymasını şart koşar. Birçok üretici bu kontrolü uygulamamış. Sonuç olarak menzildeki bir cihaz, kullanıcı hiçbir şey yapmadan eşleştirmeyi tamamlayabiliyordu. Kritik nokta şu: Telefonunuzda Fast Pair’ı kapatmak işe yaramaz, çünkü açık aksesuarın yazılımında. Tek çözüm üretici güncellemesi. Google, sorunun kontrollü araştırma ortamı dışında kullanıldığını gözlemlemediğini açıkladı.

2025'te Airoha yongalarında bulunan CVE-2025-20700, -20701 ve -20702 de aynı sınıfa girer. Fabrikada kullanılan RACE hata ayıklama protokolü, üretim cihazlarında kimlik doğrulaması olmadan erişilebilir kalmıştı. Bellek okuma ve yazma yetkisi verdiği için bağlı telefonun taklidi bile mümkün hale geliyordu.

2026'da yayımlanan CVE-2026-5068 ise Zephyr Bluetooth yığınında, kimlik doğrulaması gerektirmeyen bir paket işleme (L2CAP yeniden birleştirme) hatasıdır. Bu tür paket ayrıştırma açıkları, şifrelemeyi kırmadan doğrudan cihaz yazılımını hedef alır. Blue Borne gibi geçmiş örnekler de aynı sınıftandı ve hiçbir kullanıcı etkileşimi gerektirmiyordu.

4. Gizlilik ve Takip

BLE cihazlar kendilerini reklam paketleriyle duyurur. Rastgele adres (RPA) bunu gizlemek için tasarlandı, ama BLE 4.0-5.2 spesifikasyonunda bu adresle cihazın tanınmasına izin veren bir bilgi sızıntısı kaydedildi. Bu yüzden 6.1'deki rastgeleleştirilmiş RPA bir ayrıntı değil, gerçek bir gizlilik iyileştirmesi.

Güvenlik Duvarı Bluetooth’u Korur mu?

Kısa cevap: Hayır. Klasik anlamda güvenlik duvarı, IP adreslerini, portları ve TCP/UDP trafiğini denetler. Bluetooth ise fiziksel ve bağlantı katmanında, ayrı bir radyo ortamında çalışır. Dolayısıyla bu trafik güvenlik duvarının, IPS’in, proxy’nin ve DLP sistemlerinin görüş alanına girmez. MITRE ATT&CK’in T1011.001 tekniği (Bluetooth üzerinden veri sızdırma) tam olarak bu körlüğü tanımlar. Güvenlik duvarı hiçbir şey kaydetmez.

Bundan çıkan sonuçlar:

Blue Borne gibi saldırılar, ağ cihazlarının kapsamı dışında olduğu için, hava boşluklu (air-gapped) ağlardaki cihazları bile hedef alabiliyordu. Bluetooth tethering ve PAN gibi IP taşıyan profillerde, trafik IP katmanına çıktıktan sonra cihazın kendi güvenlik duvarı devreye girebilir. Ama bu yalnızca o profili korur, eşleştirme ve protokol saldırılarını değil. Kurumsal ortamda “Bluetooth güvenlik duvarı” dediğimiz şey aslında cihaz kontrol politikasıdır: Radyoyu tamamen kapatmak, izinli cihaz listesi, dosya aktarımını engellemek. Bunun sınırı da net: Bazı endpoint ürünlerinde radyo engellendiğinde tek tek cihaz istisnası tanımlamak çalışmaz, çünkü engellenen şey Bluetooth alıcısının kendisidir. Akademik dünya gerçek bir Bluetooth güvenlik duvarını (ana bilgisayar yığınının üstünde profil ve bağlantı filtreleyen katman) uzun süredir öneriyor. Blue Shield ve BlueSWAT gibi araştırma çerçeveleri bu yönde, ama tüketici ürünü olarak yaygın değil.

Sonuç: Bluetooth’u güvenlik duvarıyla değil, yama, politika ve azaltılmış maruziyetle korursunuz.

Nasıl Korunuruz?

Kişisel kullanıcı için:

Aksesuar yazılımını güncelleyin. Whisper Pair ve Airoha örneklerinde tek gerçek çözüm buydu. Üreticinin uygulaması varsa bildirimleri açın. Telefonu ve bilgisayarı güncel tutun. Paket ayrıştırma açıkları işletim sistemi yamalarıyla kapanır. Kullanmadığınızda Bluetooth’u kapatın ve cihazı herkese görünür modda bırakmayın. Doğrulamalı eşleştirmeyi tercih edin. Ekranda sayı karşılaştırması ya da şifre soran yöntemler, “Just Works”ten güçlüdür. Eski eşleşmeleri silin. Kullanmadığınız her kayıtlı cihaz, taklit edilebilecek bir kimliktir. Eşleştirmeyi kalabalıkta yapmayın. Satın alırken üreticinin güncelleme geçmişine bakın. Sürüm numarasından çok yazılım desteği belirleyicidir.

Kurumsal ortam için:

Yönetilen cihazlarda Bluetooth’u varsayılan olarak kapatın, gerekene açın. MDM veya Intune ile eşleştirme, dosya aktarımı ve keşfedilebilirliği kısıtlayın. Onaylı aksesuar listesi tutun, düzenli gözden geçirin. RF görünürlüğü için Bluetooth izleme çözümlerini değerlendirin. IP odaklı araçlar bu alanı görmez. Çalışanları beklenmedik eşleştirme istemlerini reddetmeleri konusunda eğitin.

Geliştiriciler ve üreticiler için:

Minimum 16 bayta yakın anahtar uzunluğunu zorlayın, 7 baytı kabul etmeyin. Üretim yazılımından hata ayıklama protokollerini kaldırın. Eşleştirme modu kontrollerini spesifikasyondaki gibi uygulayın. Secure Connections Only modunu açın, “Just Works”ü yalnızca düşük riskli senaryolarda bırakın. Uzmanlar İçin Özet Notlar Bluetooth’ta sürüm yükseltmek tek başına güvenlik sağlamaz. Aynı yonga ailesinde ve aynı SDK’da bulunan hata, birçok markayı etkiler. Standart içi zayıflıklar (KNOB gibi) üretici yamasıyla ancak kısmen azaltılır. Opsiyonel özellikler “sürüm etiketi” ile “gerçek yetenek” arasında boşluk yaratır. Tüketici cihazlarında en çok tekrar eden sorun: Doğru yapılması gereken kontrolün atlanması. Spesifikasyon doğru, uygulama hatalı. Sonuç

Bluetooth’un en büyük zayıflığı çoğu zaman şifrelemesi değil, çevresindeki ekosistem: Atlanan kontroller, güncellenmeyen aksesuarlar ve “bağlantı kolay olsun” tasarım kararları. Güvenlik duvarı bu tabloda size yardımcı olmaz. İşe yarayan şey; güncel yazılım, doğrulamalı eşleştirme, kapalı tutulan radyo ve bilinçli cihaz seçimi.

Kaynaklar:

Bluetooth Core 6.0 feature overview, Bluetooth SIG

Bluetooth 6.2 vs 6.1, Argenox Overview: Bluetooth Security Features, Ezurio Happy MitM: Fun and Toys in Every Bluetooth Device (arXiv) On the (In)security of BLE One-Way Secure Connections Only Mode (arXiv) KNOB: Key Negotiation Downgrade Attacks, ACM BLUFFS slides, Antonioli Espressif BLUFFS advisory WhisperPair, BleepingComputer Fast Pair flaw, The Register Airoha açıkları, Cyber Security News Bluetooth LE Vulnerabilities, iTechGuides Exfiltration Over Bluetooth (T1011.001) Eavesdropping in Bluetooth networks, ResearchGate

Bluetooth Security: Versions, Attacks, and Firewall Truth

For most people, Bluetooth is “a switch we turn on and off”. For security experts, it is a large protocol family that has been researched for twenty years and new vulnerabilities are still emerging. Whisper Pair, which appeared in January 2026, showed once again that it is not Bluetooth itself that is problematic, but the products that implement it. In this article, we discuss the versions, attack classes, and the firewall issue, which is misunderstood by most people.

Key Idea: Security Resolves in Three Layers

The security of a Bluetooth connection depends on three things:

Pairing: Two devices recognize each other and produce a common key. Key agreement: Determining the session key to be used on each connection. Implementation: Correct implementation of the standard by the software written by the manufacturer.

Attacks target one of these three layers. As you'll see below, the most problems occur at the third layer: manufacturer errors.

Bluetooth Versions: Pros and Cons

Version Pros Cons 1.x – 2.0 (1999-2004) Simple, low cost Legacy PIN based “legacy” matching, poor. It's still on devices today due to backwards compatibility. 2.1 + EDR (2007) introduced Secure Simple Pairing (SSP), formally verified “Just Works” mode active vulnerable to man-in-the-middle attack 4.0 (2010) Bluetooth Low Energy (BLE), low power, AES-128 Initial pairing of BLE (LE Legacy Pairing) considered fundamentally weak 4.1 / 4.2 (2013-14) LE Secure in 4.2 Connections (ECDH P-256), enhanced privacy Secure mode not required, vulnerable to pulldown attacks 5.0 – 5.3 (2016-21) 4x range, 2x speed, LE Audio (5.2) Security model same as 4.2. As the range increases, the area of ​​effect for the attacker also increases. 5.4 (2023) Encrypted advertising data (EAD), PAwR Not every device supports this feature 6.0 – 6.2 (2024-25) Secure distance measurement with Channel Sounding, randomized RPA in 6.1, amplitude attack resistance in 6.2 Features optional, not every “6.0” device includes them. Some require hardware and cannot be added via software update.

There are three points here that most people don't know:

The version number is not a guarantee of security. According to the Bluetooth SIG's own statement, most of the features of the new versions are optional. Just because it says “Bluetooth 6.0” on the box does not mean Channel Sounding support.

Some attacks do not matter version. KNOB research, which we will describe below, showed that pulldown works independently of the device's operating system, chip, role and version number. Because the weakness is in the key agreement logic of the standard.

New feature means new attack surface. Channel Sounding is designed for safe distance measurement, but the same sensitivity can also be used for tracking if not managed correctly. That's why the randomized address feature in 6.1 is important.

Attack Classes: Which Layer Is Hit?

I explain the following classes at the mechanism level.

1. Key Agreement Attenuation (KNOB, BIAS, BLUFFS)

Daniele Antonioli's research is the most important work in this field. KNOB exploits the lack of verification of key length negotiation. It has been shown that the session key can be reduced to 1 byte in classic Bluetooth and 7 bytes in BLE. Moreover, this behavior complies with the standard. So it's not the manufacturer's fault, it's the result of the design.

BIAS makes it possible to emulate a previously paired device. BLUFFS (CVE-2023-24023) combines these two. It targets forward and future secrecy of previous and subsequent sessions and may reduce Secure Connections to a weaker mode. The range it affects extends from Bluetooth 4.2 to 5.4. In defense, the basic idea is to enforce the minimum key length. Manufacturers like Espressif implemented this as a 7 byte minimum in their patches. But according to the researcher, 7 bytes is still not ideal.

2. Matching Logic Errors

“Just Works” mode does not prompt the user for verification and does not protect against active man-in-the-middle attacks. The Out-of-Band method (for example, key transfer via NFC) is not affected by these attacks, because the key passes through a channel other than Bluetooth. Method Confusion research also showed an interesting point: In Passkey and Numeric Comparison methods, the user may not realize that the two devices use different methods.

A study on Android's BLE framework also showed that the "Secure Connections Only" mode is one-sided. The standard is that the initiating device

It does not require it to support the mod. This can make the other party's secure settings meaningless.

1. Application Errors: The Most Efficient Area

The most talked about example of 2026 is Whisper Pair (CVE-2025-36911). KU Leuven researchers tested 25 commercial devices and 17 different Bluetooth chips from 16 manufacturers. The Google Fast Pair specification requires the accessory to ignore requests if it is not in pairing mode. Many manufacturers have not implemented this control. As a result, a device within range could complete pairing without the user doing anything. Here's the critical point: Turning off Fast Pair on your phone won't work, because it's in the accessory's software. The only solution is a manufacturer update. Google clarified that it had not observed the question being used outside of a controlled research environment.

CVE-2025-20700, -20701, and -20702, found in Airoha chips in 2025, also fall into the same class. The RACE debug protocol used in the factory remained accessible without authentication on production devices. Since it authorized reading and writing memory, it even became possible to imitate the connected phone.

CVE-2026-5068, released in 2026, is a packet processing (L2CAP reassembly) bug in the Zephyr Bluetooth stack that does not require authentication. These types of packet parsing vulnerabilities directly target the device software without breaking encryption. Past examples such as Blue Borne were in the same class and required no user interaction.

4. Privacy and Tracking

BLE devices announce themselves with advertising packets. The random address (RPA) was designed to hide this, but an information leak was recorded in the BLE 4.0-5.2 specification that allowed the device to be identified with this address. So randomized RPA in 6.1 isn't a detail, it's a real privacy improvement.

Does a Firewall Protect Bluetooth?

Short answer: No. In the classical sense, a firewall controls IP addresses, ports and TCP/UDP traffic. Bluetooth, on the other hand, operates at the physical and connection layer, in a separate radio environment. Therefore, this traffic does not enter the field of view of the firewall, IPS, proxy and DLP systems. MITER ATT&CK's T1011.001 technique (data exfiltration via Bluetooth) describes exactly this blindness. The firewall doesn't log anything.

The results from this are:

Because attacks like Blue Borne were beyond the scope of network devices, they could even target devices on air-gapped networks. In IP-bearing profiles such as Bluetooth tethering and PAN, the device's own firewall may activate after the traffic reaches the IP layer. But this only protects that profile, not matching and protocol attacks. What we call “Bluetooth firewall” in the corporate environment is actually a device control policy: completely turning off the radio, allowed device list, blocking file transfer. The limit of this is clear: In some endpoint products, it does not work to define individual device exceptions when the radio is blocked, because what is blocked is the Bluetooth receiver itself. The academic world has long recommended a true Bluetooth firewall (the profile and connection filtering layer on top of the host stack). Research frameworks such as Blue Shield and BlueSWAT are trending in this direction, but they are not widely available as consumer products.

Bottom line: You protect Bluetooth with patching, policies, and reduced exposure, not with a firewall.

How to Protect Us?

For personal user:

Update accessory software. In the cases of Whisper Pair and Airoha, this was the only real solution. Turn on notifications if the manufacturer has an app. Keep phone and computer updated. Packet parsing vulnerabilities are closed with operating system patches. Turn off Bluetooth when not in use and do not leave the device in public mode. Prefer verified matching. Methods that compare numbers on the screen or ask for a password are stronger than “Just Works”. Delete old matches. Every registered device you don't use is an identity that can be spoofed. Don't do the matching in a crowd. Check the manufacturer's update history when purchasing. Software support is more decisive than the version number.

For corporate environment:

Turn Bluetooth off by default on managed devices, turn it on as needed. Restrict pairing, file transfers, and discoverability with MDM or Intune. Keep an approved accessory list and review it regularly. Consider Bluetooth monitoring solutions for RF visibility. IP-oriented tools do not see this area. Train employees to reject unexpected matching requests.

For developers and manufacturers:

Force key length close to minimum 16 bytes, do not accept 7 bytes. Remove debug protocols from production software. Apply pairing mode controls as in specification. Turn on Secure Connections Only mode, leave “Just Works” only in low-risk scenarios. Summary Notes for Experts Upgrading Bluetooth alone does not provide security. The bug, found in the same chip family and the same SDK, affects many brands. In-standard vulnerabilities (such as KNOB) are only partially mitigated by the vendor patch. Optional features create a gap between “release label” and “real capability”. The most recurring problem in consumer devices: Missing the correct check. The specification is correct, the implementation is flawed. Conclusion

Bluetooth's biggest weakness is often not its encryption, but the ecosystem around it: Missed controls, unupdated accessories, and "make connecting easy" design decisions. Firewall won't help you with this chart. What works is; up-to-date software, authenticated pairing, radio turned off and informed device selection.

Sources:

Bluetooth Core 6.0 feature overview, Bluetooth SIG

Bluetooth 6.2 vs 6.1, Argenox Overview: Bluetooth Security Features, Ezurio Happy MitM: Fun and Toys in Every Bluetooth Device (arXiv) On the (In)security of BLE One-Way Secure Connections Only Mode (arXiv) KNOB: Key Negotiation Downgrade Attacks, ACM BLUFFS slides, Antonioli Espressif BLUFFS advisory WhisperPair, BleepingComputer Fast Pair flaw, The Register Airoha vulnerabilities, Cyber Security News Bluetooth LE Vulnerabilities, iTechGuides Exfiltration Over Bluetooth (T1011.001) Eavesdropping in Bluetooth networks, ResearchGate

Bluetooth-Sicherheit: Versionen, Angriffe und Firewall-Wahrheit

Für die meisten Menschen ist Bluetooth „ein Schalter, den wir ein- und ausschalten“. Für Sicherheitsexperten handelt es sich um eine große Protokollfamilie, die seit zwanzig Jahren erforscht wird und immer noch neue Schwachstellen auftauchen. WhisperPair, das im Januar 2026 erschien, zeigte einmal mehr, dass nicht Bluetooth selbst problematisch ist, sondern die Produkte, die es implementieren. In diesem Artikel besprechen wir die Versionen, Angriffsklassen und das Firewall-Problem, das von den meisten Menschen missverstanden wird.

Schlüsselidee: Sicherheit wird in drei Ebenen gelöst

Die Sicherheit einer Bluetooth-Verbindung hängt von drei Dingen ab:

Pairing: Zwei Geräte erkennen sich gegenseitig und erzeugen einen gemeinsamen Schlüssel. Schlüsselvereinbarung: Bestimmen des Sitzungsschlüssels, der für jede Verbindung verwendet werden soll. Umsetzung: Korrekte Umsetzung des Standards durch die vom Hersteller geschriebene Software.

Angriffe zielen auf eine dieser drei Schichten. Wie Sie weiter unten sehen werden, treten die meisten Probleme auf der dritten Ebene auf: Herstellerfehler.

Bluetooth-Versionen: Vor- und Nachteile Version Vorteile Nachteile 1.x – 2.0 (1999–2004) Einfache, kostengünstige Legacy-PIN-basierte „Legacy“-Kopplung, schlecht. Aufgrund der Abwärtskompatibilität ist es auch heute noch auf Geräten verfügbar. 2.1 + EDR (2007) führte Secure Simple Pairing (SSP) ein, offiziell verifizierter „Just Works“-Modus, aktiv, anfällig für Man-in-the-Middle-Angriffe 4.0 (2010) Bluetooth Low Energy (BLE), geringer Stromverbrauch, AES-128 Anfängliches Pairing von BLE (LE Legacy Pairing) gilt als grundsätzlich schwach 4.1 / 4.2 (2013-14) LE Secure in 4.2 Connections (ECDH P-256), erweiterte Privatsphäre. Sicherer Modus nicht erforderlich, anfällig für Pulldown-Angriffe 5.0 – 5.3 (2016–21) 4-fache Reichweite, 2-fache Geschwindigkeit, LE Audio (5.2). Sicherheitsmodell wie 4.2. Mit zunehmender Reichweite vergrößert sich auch der Wirkungsbereich für den Angreifer. 5.4 (2023) Verschlüsselte Werbedaten (EAD), PAwR Nicht jedes Gerät unterstützt diese Funktion 6.0 – 6.2 (2024-25) Sichere Distanzmessung mit Channel Sounding, randomisiertem RPA in 6.1, Amplitudenangriffsresistenz in 6.2 Funktionen optional, nicht jedes „6.0“-Gerät enthält sie. Einige erfordern Hardware und können nicht per Software-Update hinzugefügt werden.

Hier gibt es drei Punkte, die die meisten Menschen nicht kennen:

Die Versionsnummer ist keine Garantie für die Sicherheit. Laut eigener Aussage der Bluetooth SIG sind die meisten Features der neuen Versionen optional. Nur weil auf der Verpackung „Bluetooth 6.0“ steht, heißt das nicht, dass Channel Sounding unterstützt wird.

Einige Angriffe spielen keine Rolle. Untersuchungen von KNOB, die wir weiter unten beschreiben werden, haben gezeigt, dass Pulldown unabhängig vom Betriebssystem, Chip, Rolle und Versionsnummer des Geräts funktioniert. Denn die Schwäche liegt in der zentralen Vereinbarungslogik des Standards.

Neue Funktion bedeutet neue Angriffsfläche. Channel Sounding ist für die sichere Entfernungsmessung konzipiert, aber die gleiche Empfindlichkeit kann auch für die Ortung verwendet werden, wenn es nicht richtig gehandhabt wird. Aus diesem Grund ist die Funktion „Randomized Address“ in 6.1 wichtig.

Angriffsklassen: Welche Ebene wird getroffen?

Ich erkläre die folgenden Klassen auf Mechanismusebene.

1. Schwächung wichtiger Vereinbarungen (KNOB, BIAS, BLUFFS)

Die Forschung von Daniele Antonioli ist die wichtigste Arbeit auf diesem Gebiet. KNOB nutzt die mangelnde Verifizierung der Schlüssellängenaushandlung aus. Es hat sich gezeigt, dass der Sitzungsschlüssel bei klassischem Bluetooth auf 1 Byte und bei BLE auf 7 Byte reduziert werden kann. Darüber hinaus entspricht dieses Verhalten der Norm. Es ist also nicht die Schuld des Herstellers, sondern das Ergebnis des Designs.

BIAS ermöglicht die Emulation eines zuvor gekoppelten Geräts. BLUFFS (CVE-2023-24023) kombiniert diese beiden. Es zielt auf die Vorwärts- und Zukunftsgeheimhaltung früherer und nachfolgender Sitzungen ab und reduziert möglicherweise sichere Verbindungen auf einen schwächeren Modus. Der betroffene Bereich reicht von Bluetooth 4.2 bis 5.4. Bei der Verteidigung besteht die Grundidee darin, die Mindestschlüssellänge durchzusetzen. Hersteller wie Espressif haben dies in ihren Patches als mindestens 7 Byte implementiert. Doch laut dem Forscher sind 7 Byte immer noch nicht ideal.

1. Passende Logikfehler

Der „Just Works“-Modus fordert den Benutzer nicht zur Verifizierung auf und bietet keinen Schutz vor aktiven Man-in-the-Middle-Angriffen. Das Out-of-Band-Verfahren (z. B. Schlüsselübertragung per NFC) ist von diesen Angriffen nicht betroffen, da der Schlüssel über einen anderen Kanal als Bluetooth übertragen wird. Untersuchungen zur Methodenverwirrung haben auch einen interessanten Punkt ergeben: Bei Passkey- und Numeric-Vergleichsmethoden erkennt der Benutzer möglicherweise nicht, dass die beiden Geräte unterschiedliche Methoden verwenden.

Eine Studie zum BLE-Framework von Android ergab außerdem, dass der Modus „Nur sichere Verbindungen“ einseitig ist. Der Standard ist das auslösende Gerät

Es ist nicht erforderlich, dass es den Mod unterstützt. Dadurch können die Sicherheitseinstellungen der anderen Partei bedeutungslos werden.

1. Anwendungsfehler: Der effizienteste Bereich

Das am meisten diskutierte Beispiel für 2026 ist WhisperPair (CVE-2025-36911). Forscher der KU Leuven testeten 25 kommerzielle Geräte und 17 verschiedene Bluetooth-Chips von 16 Herstellern. Die Google Fast Pair-Spezifikation erfordert, dass das Zubehör Anfragen ignoriert, wenn es sich nicht im Pairing-Modus befindet. Viele Hersteller haben diese Kontrolle nicht implementiert. Dadurch kann ein Gerät in Reichweite die Kopplung abschließen, ohne dass der Benutzer etwas unternehmen muss. Hier ist der entscheidende Punkt: Das Ausschalten von Fast Pair auf Ihrem Telefon funktioniert nicht, da es in der Software des Zubehörs enthalten ist. Die einzige Lösung ist ein Hersteller-Update. Google stellte klar, dass es nicht beobachtet hatte, dass die Frage außerhalb einer kontrollierten Forschungsumgebung verwendet wurde.

CVE-2025-20700, -20701 und -20702, die 2025 in Airoha-Chips gefunden wurden, fallen ebenfalls in dieselbe Klasse. Das im Werk verwendete RACE-Debug-Protokoll blieb auf Produktionsgeräten ohne Authentifizierung zugänglich. Da es das Lesen und Schreiben des Speichers ermöglichte, war es sogar möglich, das angeschlossene Telefon nachzuahmen.

CVE-2026-5068, veröffentlicht im Jahr 2026, ist ein Fehler bei der Paketverarbeitung (L2CAP-Neuzusammenstellung) im Zephyr-Bluetooth-Stack, der keine Authentifizierung erfordert. Diese Arten von Sicherheitslücken bei der Paketanalyse zielen direkt auf die Gerätesoftware ab, ohne die Verschlüsselung zu unterbrechen. Frühere Beispiele wie BlueBorne gehörten zur gleichen Klasse und erforderten keine Benutzerinteraktion.

1. Datenschutz und Tracking

BLE-Geräte kündigen sich mit Werbepaketen an. Die Zufallsadresse (RPA) sollte dies verbergen, es wurde jedoch ein Informationsleck in der BLE 4.0-5.2-Spezifikation aufgezeichnet, das die Identifizierung des Geräts mit dieser Adresse ermöglichte. Randomisiertes RPA in 6.1 ist also kein Detail, sondern eine echte Verbesserung der Privatsphäre.

Schützt eine Firewall Bluetooth?

Kurze Antwort: Nein. Im klassischen Sinne kontrolliert eine Firewall IP-Adressen, Ports und TCP/UDP-Verkehr. Bluetooth hingegen arbeitet auf der physikalischen und Verbindungsebene in einer separaten Funkumgebung. Daher gelangt dieser Datenverkehr nicht in das Sichtfeld der Firewall-, IPS-, Proxy- und DLP-Systeme. Die T1011.001-Technik (Datenexfiltration über Bluetooth) von MITRE ATT&CK beschreibt genau diese Blindheit. Die Firewall protokolliert nichts.

Die Ergebnisse daraus sind:

Angriffe wie BlueBorne könnten sogar Geräte in Air-Gap-Netzwerken zum Ziel haben, da diese außerhalb der Reichweite von Netzwerkgeräten liegen. Bei IP-tragenden Profilen wie Bluetooth-Tethering und PAN kann die eigene Firewall des Geräts aktiviert werden, nachdem der Datenverkehr die IP-Schicht erreicht. Dies schützt jedoch nur dieses Profil, keine Matching- und Protokollangriffe. Was wir im Unternehmensumfeld als „Bluetooth-Firewall“ bezeichnen, ist eigentlich eine Gerätekontrollrichtlinie: Komplettes Ausschalten des Funks, Liste zugelassener Geräte, Blockieren der Dateiübertragung. Die Grenze hierfür liegt klar auf der Hand: Bei manchen Endpoint-Produkten funktioniert es nicht, einzelne Geräteausnahmen zu definieren, wenn das Funkgerät blockiert ist, da blockiert wird der Bluetooth-Empfänger selbst. Die akademische Welt empfiehlt seit langem eine echte Bluetooth-Firewall (die Profil- und Verbindungsfilterschicht oben auf dem Host-Stack). Forschungsrahmen wie BlueShield und BlueSWAT weisen in diese Richtung, sind als Verbraucherprodukte jedoch nicht weit verbreitet.

Fazit: Sie schützen Bluetooth durch Patching, Richtlinien und reduzierte Gefährdung, nicht durch eine Firewall.

Wie schützen wir uns?

Für Privatanwender:

Zubehörsoftware aktualisieren. In den Beispielen WhisperPair und Airoha war dies die einzige wirkliche Lösung. Aktivieren Sie Benachrichtigungen, wenn der Hersteller eine App hat. Halten Sie Telefon und Computer auf dem neuesten Stand. Schwachstellen beim Parsen von Paketen werden mit Betriebssystem-Patches geschlossen. Schalten Sie Bluetooth aus, wenn Sie es nicht verwenden, und lassen Sie das Gerät nicht im öffentlichen Modus. Bevorzugen Sie verifizierte Übereinstimmungen. Methoden, die Zahlen auf dem Bildschirm vergleichen oder nach einem Passwort fragen, sind stärker als „Just Works“. Alte Übereinstimmungen löschen. Jedes registrierte Gerät, das Sie nicht nutzen, ist eine Identität, die gefälscht werden kann. Führen Sie das Matching nicht in einer Menschenmenge durch. Überprüfen Sie beim Kauf den Update-Verlauf des Herstellers. Entscheidender als die Versionsnummer ist der Software-Support.

Für das Unternehmensumfeld:

Schalten Sie Bluetooth auf verwalteten Geräten standardmäßig aus und aktivieren Sie es bei Bedarf. Beschränken Sie Kopplung, Dateiübertragungen und Erkennbarkeit mit MDM oder Intune. Führen Sie eine Liste genehmigter Zubehörteile und überprüfen Sie diese regelmäßig. Erwägen Sie Bluetooth-Überwachungslösungen für die RF-Sichtbarkeit. IP-orientierte Tools sehen diesen Bereich nicht. Schulen Sie Ihre Mitarbeiter darin, unerwartete Matching-Anfragen abzulehnen.

Für Entwickler und Hersteller:

Erzwingen Sie eine Schlüssellänge von mindestens 16 Byte, akzeptieren Sie keine 7 Byte. Entfernen Sie Debug-Protokolle aus der Produktionssoftware. Wenden Sie die Kopplungsmodussteuerungen gemäß der Spezifikation an. Aktivieren Sie den Modus „Nur sichere Verbindungen“ und belassen Sie „Just Works“ nur in Szenarien mit geringem Risiko. Zusammenfassende Hinweise für Experten Ein Upgrade von Bluetooth allein bietet keine Sicherheit. Der Fehler, der in derselben Chipfamilie und demselben SDK auftritt, betrifft viele Marken. Standardmäßige Schwachstellen (z. B. KNOB) werden durch den Hersteller-Patch nur teilweise behoben. Optionale Funktionen schaffen eine Lücke zwischen „Release-Label“ und „echter Leistungsfähigkeit“. Das am häufigsten auftretende Problem bei Consumer-Geräten: Das Fehlen der richtigen Prüfung. Die Spezifikation ist korrekt, die Implementierung fehlerhaft. Abschluss

Die größte Schwäche von Bluetooth ist oft nicht seine Verschlüsselung, sondern das Ökosystem um es herum: fehlende Bedienelemente, nicht aktualisiertes Zubehör und Designentscheidungen, die die Verbindung „einfach machen“. Firewall wird Ihnen bei dieser Tabelle nicht weiterhelfen. Was funktioniert, ist; Aktuelle Software, authentifiziertes Pairing, ausgeschaltetes Radio und fundierte Geräteauswahl.

Quellen:

Bluetooth Core 6.0-Funktionsübersicht, Bluetooth SIG Bluetooth 6.2 vs 6.1, Argenox-Übersicht: Bluetooth-Sicherheitsfunktionen, Ezurio Happy MitM: Spaß und Spielzeug in jedem Bluetooth-Gerät (arXiv) Zur (Un-)Sicherheit des BLE One-Way Secure Connections Only Mode (arXiv) KNOPF: Key Negotiation Downgrade Attacks, ACM BLUFFS-Folien, Antonioli Espressif BLUFFS-Beratung WhisperPair, BleepingComputer Fast Pair Fehler, The Register Airoha-Schwachstellen, Cyber Security News Bluetooth LE-Schwachstellen, iTechGuides Exfiltration Over Bluetooth (T1011.001) Abhören in Bluetooth-Netzwerken, ResearchGate