Schlüsselerzeugung und -austausch bei der Kommunikation über Bluetooth sind das Thema dieser Folge. Den Anfang macht die Authentisierung. Im Sicherheitsmodus 3 (siehe About Security #118) ist beim Verbindungsaufbau eine gegenseitige Authentisierung der Geräte zwingend erforderlich. Diese wird auf Verbindungsebene (Link Level) durch ein Challenge-Response-Verfahren realisiert und läuft in zwei Schritten ab: Zuerst wird in der Initialisierungsphase der Link Key ausgehandelt, danach damit das Challenge-Response-Verfahren durchgeführt.

Initialisierungsphase

Die Initialisierungsphase besteht aus drei Schritten:

1. Generierung des Init Keys
2. Generierung bzw. Auswahl eines Link Keys
3. Austausch des Link Keys

Der Master (hier auch als Verifier bezeichnet) leitet die Generierung des Init Keys ein und erzeugt dazu den Zufallswert IN_RAND, der dann an den Slave (hier auch als Claiment bezeichnet) gesendet wird. Beide können danach mit dem Algorithmus E22 aus IN_RAND, der Geräteadresse BD_ADDR des Slave, der PIN und der PIN-Länge den Init Key berechnen.

Entsprechend den Fähigkeiten der beteiligten Geräte wird danach ein Unit Key, Combination Key oder Master Key als Link Key bestimmt und, geschützt durch den Init Key, ausgetauscht.

• Kann ein Gerät keine weiteren Schlüssel speichern, wird dessen Unit Key als Link Key verwendet.
• Der Combination Key wird von den beteiligten Geräten für jede Session neu berechnet. Dazu erzeugen zuerst beide Geräte eine Zufallszahl. Danach wird mit dem Algorithmus E21 aus der jeweiligen Zufallszahl und Geräteadresse ein Teilschlüssel berechnet. Die Zufallszahlen werden mit dem Init Key verschlüsselt und ausgetauscht. Danach erzeugen beide Geräte den jeweils anderen Teilschlüssel. Der gemeinsame Combination Key wird dann durch XOR-Verknüpfung der beiden Teilschlüssel gebildet.
• Der Master Key wird verwendet, um Punkt-zu-Mehrpunkt-Verbindungen zu schützen. Dazu werden die jeweiligen Link Keys temporär durch den vom Master mit dem Algorithmus E22 erzeugten Master Key ersetzt. Als Eingabeparameter für E22 dienen dabei zwei vom Master erzeugte Zufallszahlen und als 'PIN-Länge' 16. Außerdem erzeugt der Master einen weiteren Zufallswert RAND, der an den Slave gesendet wird. Master und Slave berechnen aus dem aktuellen Link Key, RAND und der 'PIN-Länge' 16 einen temporären Verschlüsselungsschlüssel (Overlay, OVL), mit dem der Master den Master Key durch XOR-Verknüpfung verschlüsselt.

Der gewählte Link Key wird danach als Authentisierungsschlüssel verwendet. Nach erfolgreicher Authentisierung kann der Link Key jederzeit geändert werden, wobei der aktuelle Link Key als Initialisierungsschlüssel dient.

Authentisierungsprotokoll

Die Authentisierung erfolgt durch ein Challenge-Response-Verfahren mit dem Link Key als symmetrischem Schlüssel. Der Master sendet die von ihm erzeugte Zufallszahl AU_RAND als Challenge an den Client. Der Client berechnet mit dem Algorithmus E1 aus AU_RAND, seiner Geräteadresse BD_ADDR und dem Link Key die 32 Bit lange Signed Response SRES, die dann an den Master gesendet wird. Der Master vergleich den empfangenen Wert mit dem Ergebnis seiner eigenen Berechnung. Stimmen beide Werte überein, ist der Client authentisiert. Danach wird das Protokoll ggf. vom Slave gestartet, um den Master zu authentisieren.

Der Rest des 128 Bit langen Ergebnisses von E1 wird als Authenticated Ciphering Offset (ACO) bezeichnet und geht später als Ciphering Offset Number (COF) in die Berechnung des Encryption Keys ein.

Um Brute-Force- und Denial-of-Service-Angriffe zu erschweren, kann die Authentisierung nach einem Fehlschlag erst nach einer Wartezeit erneut gestartet werden, die mit jedem weiteren Fehlschlag exponentiell vergrößert wird.

Verschlüsselung

Zum Schutz der Vertraulichkeit der Datenübertragung steht im Sicherheitsmodus 2 und 3 eine Verschlüsselung auf der Verbindungsebene zur Verfügung. Die Verschlüsselung setzt eine erfolgreiche Authentifizierung voraus und wird vom Master eingeleitet. Der Slave muss den Wunsch nach Verschlüsselung bestätigen, anschließend wird die Länge des Encryption Keys ausgehandelt, die zwischen 1 und 16 Bytes liegt. Jede Anwendung legt eine Mindestschlüssellänge Lmin fest, jedes Bluetooth-Gerät besitzt eine fest vorgegebene maximale Schlüssellänge Lmax. Als gemeinsame Schlüssellänge wird das Maximum der Schnittmenge von {Lmin, .., 16} und {1, .., Lmax} verwendet.

Für die Auswahl sendet der Master die maximale Schlüssellänge an den Slave. Akzeptiert der Slave diese Schlüssellänge nicht, wird so lange die jeweils nächstkleinere Schlüssellänge gesendet, bis der Slave sie akzeptiert oder die Mindestschlüssellänge erreicht ist. Akzeptiert der Slave auch die Mindestschlüssellänge nicht, wird keine Verbindung aufgebaut. Dadurch wird verhindert, dass eine unsicherere Verbindung als von der Anwendung gefordert aufgebaut wird.

Nach der Festlegung der Schlüssellänge wird der Encryption Key berechnet. Dazu erzeugt der Master die Zufallszahl EN_RAND. Der 128 Bit lange Encryption Key wird mit dem Algorithmus E3 aus EN_RAND, dem Link Key und der 96 Bit langen Ciphering Offset Number COF berechnet und ggf. auf die ausgehandelte Länge gekürzt.

In der nächsten Folge wird die Sicherheit der Schutzfunktionen betrachtet.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Mobile Security – Bluetooth"

• About Security #118: Mobile Security – Bluetooth-Grundlagen
• About Security #119: Mobile Security – Bluetooth-Schlüssel
• About Security #120: Mobile Security – Bluetooth-Authentisierung
• About Security #121: Mobile Security – Bluetooth-Schwachstellen
• About Security #122: Mobile Security – Bluetooth-Angriffe