Bundesamt für Sicherheit in der Informationstechnik

G 4.80 Unzureichende oder fehlende Bluetooth-Sicherheitsmechanismen

Die in den Bluetooth-Spezifikationen beschriebenen und von Herstellern entsprechend implementierten Sicherheitsmechanismen weisenverschiedene prinzipielle Schwächen auf. Einige von diesen werden im Folgenden kurz benannt.

Verschlüsselung nicht vorgeschrieben

Unabhängig vom verwendeten Sicherheitsmodus ist die Verschlüsselung der mit Bluetooth zu übertragenden Daten optional und muss von den Anwendungen explizit beantragt werden.

Unsichere Voreinstellungen

Die Voreinstellungen sind von Seiten der Hersteller oft unsicher konfiguriert. Sicherheitsfunktionen wie Authentisierung und Verschlüsselung sind häufig abgeschaltet und Passwörter bzw. PINs auf Standardwerte ("0000", "1234" usw. ) eingestellt. Wenn Geräte keine Eingabemöglichkeit besitzen ( z. B. Headsets), ist eine Änderung der voreingestellten Werte gar nicht oder nur umständlich möglich.

Erraten schwacher PINs bei Bluetooth ohne Secure Simple Pairing (SSP)

Beim Pairing zweier Bluetooth-Geräte wird ein Verbindungsschlüssel erzeugt und dauerhaft in beiden Geräten gespeichert. Dessen Erzeugung basiert unter anderem auf den Geräteadressen und einer PIN. Mit dem Verfahren Secure Simple Pairing (SSP) wird beim Verbindungsaufbau ein sicherer Kanal aufgebaut, ohne SSP werden die Authentisierungsinformationen unverschlüsselt übertragen.

Wird bei der Gerätepaarung eine schwache PIN verwendet, kann ein Angreifer die PIN erraten und damit den aus der Paarung resultierenden Verbindungsschlüssel berechnen. Dazu muss der Angreifer nur die Paarung und die folgende Authentisierung abhören. Ohne SSP kann der Angreifer anhand der Aufzeichnungen der abgehörten Protokolle überprüfen, ob die PIN von ihm korrekt geraten wurde.

Als sicherheitskritisch anzusehen ist, dass die PIN bei Bluetooth ohne SSP als einziger geheimer Parameter in die Erzeugung des Verbindungsschlüssels einfließt. Erfahrungsgemäß lassen sich weit verbreitete Nutzer- bzw. Herstellergewohnheiten zu schwachen Sicherheitseinstellungen nur schwer durchbrechen. In der Tat gibt es kaum Bluetooth-Geräte, die den Benutzern eine Mindestlänge und Komplexität für die PIN vorgeben. Es bleibt im Allgemeinen den Benutzern überlassen, welche PIN sie wählen.

Re-Initialisierung semipermanenter Verbindungen bei Bluetooth ohne SSP

Die Bluetooth-Spezifikation sieht die Möglichkeit vor, dass eine erneute Authentisierung durchgeführt werden kann, beispielsweise wenn festgestellt wird, dass der Verbindungsschlüssel in einem der Geräte verloren gegangen ist. Dies bietet einem Angreifer die Möglichkeit, im passenden Moment ein entsprechendes Paket mit der Aufforderung der Reinitalisierung der Verbindung in die laufende Kommunikation zweier Geräte einzubringen. Hierdurch wird eine erneute Paarung provoziert, die dann abgehört werden kann.

Keine verbindliche Vorgabe einer ausreichenden Schlüssellänge

Neben Länge und Komplexität der bei der Authentisierung (bei Bluetooth ohne SSP) verwendeten PIN spielt auch die Länge der für die Verschlüsselung der übertragenen Daten verwendeten Schlüssel eine Rolle für die Sicherheit. Während die Bluetooth-Spezifikation für Schlüssel, die zur Authentisierung benutzt werden, eine Schlüssellänge von 128 Bit fest vorschreibt, kann die Länge des für die Verschlüsselung der weiteren Paketinhalte verwendeten Schlüssels variieren. Beide Geräte handeln im Rahmen des Verbindungsaufbaus die tatsächlich genutzte Schlüssellänge aus. Die Bluetooth-Spezifikation sieht hier eine Spannweite von 8 bis 128 Bit vor, d. h. es könnte eine minimale Schlüssellänge von 8 Bit verwendet werden, ohne gegen die Spezifikation zu verstoßen.

In der Spezifikation wird sogar ausdrücklich ausgeschlossen, dass die minimale Schlüssellänge durch den Anwender verändert werden kann. Diese kann nur über die Werkseinstellung des Herstellers definiert werden. Die Güte der erreichbaren Verschlüsselung ist damit allein abhängig von der Herstellerentscheidung.

Schwache Integritätssicherung

Zur Integritätssicherung wird ein Cyclic Redundancy Check (CRC, Verfahren zur Erkennung von Übertragungsfehlern anhand einer Prüfsumme) verwendet. Dadurch werden zwar mit hoher Wahrscheinlichkeit zufällige Störungen bei der Übertragung von Datenpaketen erkannt, aber gegen eine absichtliche Manipulation von Datenpaketen bieten CRC-Verfahren keinen Schutz.

Qualität des Zufallsgenerators

Zur Zufallserzeugung sehen die Bluetooth-Spezifikationen 1.x und 2.0 + EDR die Verwendung eines sogenannten Pseudozufallszahlen-Generators vor. Es wird jedoch keine Vorgabe für dessen Implementierung gemacht. Es ist daher nicht auszuschließen, dass die verwendeten Zufallszahlen-Generatoren Schwächen aufweisen, die sich für das Überwinden der kryptographischen Verfahren ausnutzen lassen. In der Bluetooth-Spezifikation ab 2.1 + EDR wird hingegen die Verwendung eines Zufallszahlen-Generators gemäß der Norm FIPS 140-2 gefordert.

Verkürzter Initialisierungsvektor

Jedes übertragene Datenpaket wird unter Verwendung eines neuen Initialisierungsvektors verschlüsselt. Dieser errechnet sich unter anderem aus dem Zeittakt des Masters. Es wird allerdings das höchstwertige Bit des Zeittaktes "vergessen". Durch diese Schwäche lassen sich selbst bei eingesetzter Verschlüsselung Man-in-the-Middle-Angriffe durchführen, da es immer zwei unterschiedliche Offsets in der Sprungsequenz zu einem Initialisierungsvektor gibt. Ein Man-in-the-Middle-Angriff auf eine verschlüsselte Verbindung erlaubt jedoch nur, den Datenstrom zu manipulieren, nicht jedoch, diesen zu entschlüsseln.

Manipulation von verschlüsselten Daten

Aufgrund der Eigenschaften von Stromchiffren im Zusammenwirken mit dem zur Integritätssicherung eingesetzten CRC ist es möglich, Änderungen am Chiffrat vorzunehmen, so dass der Empfänger das Paket nach wie vor als gültig erkennt. So ist es beispielsweise bei Bluetooth ohne SSP im Rahmen eines Man-in-the-Middle-Angriffs möglich, IP -Header gezielt zu manipulieren.

Stand: 12. EL Stand 2011