Mittwoch, 10. November 2010


Topthema

Mittwoch, 29. August 2007 | Topthema

About Security #120: Mobile Security — Bluetooth-Authentisierung

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/037814)

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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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.

About Security: Die komplette Serie

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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Mobile Security � Bluetooth"

Kommentare

Folgende Links könnten Sie auch interessieren

  • C++  [28.11.2005]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,472,.html]
  • C++  [13.10.2006]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,565,.html]
  • New Master of Flash Volume 3  [16.03.2005]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,354,.html]
  • SOA goes real  [18.06.2008]
    [http://entwickler.de/zonen/portale/psecom,id,102,buch,750,.html]
  • JavaSpaces und ihr Platz im Enterprise Java Universum  [09.01.2004]
    [http://entwickler.de/zonen/portale/psecom,id,101,online,489,.html]