DECT-sniffing - Revision history

Aureliano: /* Cassable-Kryptoanalyse */

2009-11-01T13:19:15Z

Cassable-Kryptoanalyse

← Older revision		Revision as of 13:19, 1 November 2009
Line 83:		Line 83:
	Das übergeordnete Ziel dieses Angriffs ist eine Fremdauthentifikation, um bspw. ein Handset zu imitieren. Die Aufgabe besteht in der Rückgewinnung des Session Keys KS oder des Authentication Keys UAK, mit dessen Hilfe sich der ganze Authentifizierungsprozess imitieren lässt. Voraussetzung für diesen Angriff ist die Aufzeichnung der offen übertragenen Eingangsparameter RS, RAND_X und RES zu Beginn einer Authentifikation.		Das übergeordnete Ziel dieses Angriffs ist eine Fremdauthentifikation, um bspw. ein Handset zu imitieren. Die Aufgabe besteht in der Rückgewinnung des Session Keys KS oder des Authentication Keys UAK, mit dessen Hilfe sich der ganze Authentifizierungsprozess imitieren lässt. Voraussetzung für diesen Angriff ist die Aufzeichnung der offen übertragenen Eingangsparameter RS, RAND_X und RES zu Beginn einer Authentifikation.

	Für die (differentielle) Kryptoanalyse setzten die Wissenschaftler voraus, dass der Angreifer zwei Klartextnachrichten verschlüsseln kann, die sich in jedem zweiten Byte gleichen, und im Besitzt von RS und RAND_X ist, welche durch passives Aufzeichnen ermittelbar sind. Sie fanden heraus, dass der Schlüssel mit etwas Glück und genügend Rechenaufwand ~~zurück gewonnen~~ werden kann.		Für die (differentielle) Kryptoanalyse setzten die Wissenschaftler voraus, dass der Angreifer zwei Klartextnachrichten verschlüsseln kann, die sich in jedem zweiten Byte gleichen, und im Besitzt von RS und RAND_X ist, welche durch passives Aufzeichnen ermittelbar sind. Sie fanden heraus, dass der Schlüssel mit etwas Glück und genügend Rechenaufwand zurückgewonnen werden kann.

	==== Klartext-Chiffretext-Angriff ====		==== Klartext-Chiffretext-Angriff ====

Aureliano: /* Fazit */

2009-11-01T13:16:57Z

Fazit

← Older revision		Revision as of 13:16, 1 November 2009
Line 103:		Line 103:
	Theoretisch bietet die DECT-Sicherheitsarchitektur einen guten Schutz. Doch gerade durch entsprechende Implementationsfehler singt die Sicherheit um einen erheblichen Faktor. Gespräche können abgehört werden, weil sie entweder gar nicht oder nur schlecht verschlüsselt sind oder eine einseitige Authentifizierung stattfindet; fremde Geräte können eingeschleust werden und führen zu Fremdkontrolle.		Theoretisch bietet die DECT-Sicherheitsarchitektur einen guten Schutz. Doch gerade durch entsprechende Implementationsfehler singt die Sicherheit um einen erheblichen Faktor. Gespräche können abgehört werden, weil sie entweder gar nicht oder nur schlecht verschlüsselt sind oder eine einseitige Authentifizierung stattfindet; fremde Geräte können eingeschleust werden und führen zu Fremdkontrolle.

	Das Fatale daran ist die Tatsache, dass es eine große Anzahl dieser Geräte auf dem Markt gibt und man sie weder patchen noch ~~zurück beordern~~ kann. Letzteres wäre schlichtweg zu kostspielig. Den Besitzern solcher Systeme bleibt nur die Möglichkeit, das System zu wechseln oder sich mit ihrem Hersteller in Verbindung zu setzen und nach Lösungen zu suchen.		Das Fatale daran ist die Tatsache, dass es eine große Anzahl dieser Geräte auf dem Markt gibt und man sie weder patchen noch zurückbeordern kann. Letzteres wäre schlichtweg zu kostspielig. Den Besitzern solcher Systeme bleibt nur die Möglichkeit, das System zu wechseln oder sich mit ihrem Hersteller in Verbindung zu setzen und nach Lösungen zu suchen.

	== Quellen ==		== Quellen ==

Aureliano at 20:44, 23 October 2009

2009-10-23T20:44:16Z

Aureliano: /* Quellen */

2009-10-23T18:03:27Z

Quellen

← Older revision		Revision as of 18:03, 23 October 2009
Line 107:		Line 107:
	== Quellen ==		== Quellen ==

	* ETSI (2005~~-09~~): ~~DECT --~~ Part 7: Security features, Identifier: ETSI EN 300 175-7 V1.9.1.		* ETSI (2005): ''Part 7: Security features''. Identifier: ETSI EN 300 175-7 V1.9.1.
	* Lucks, Stefan; Schuler, Andreas; Tews, Eric; Weinmann, Ralf-Philipp; Wenzel, Matthias (Jahr unbekannt): Attacks on the DECT authentication mechanisms. Internet: http://www.dedected.org.		* Lucks, Stefan; Schuler, Andreas; Tews, Eric; Weinmann, Ralf-Philipp; Wenzel, Matthias (Jahr unbekannt): ''Attacks on the DECT authentication mechanisms''. Internet: http://www.dedected.org.
	* Mengele, Alexandra (2009): Diplomarbeit: Security of Digital Enhanced Cordless Telecommunication (DECT) devices for residential use. Darmstadt.		* Mengele, Alexandra (2009): ''Diplomarbeit: Security of Digital Enhanced Cordless Telecommunication (DECT) devices for residential use''. Darmstadt.

	== Weiterführende Links ==		== Weiterführende Links ==

Aureliano: /* Quellen */

2009-10-23T18:01:42Z

Quellen

← Older revision		Revision as of 18:01, 23 October 2009
Line 106:		Line 106:

	== Quellen ==		== Quellen ==

			* ETSI (2005-09): DECT -- Part 7: Security features, Identifier: ETSI EN 300 175-7 V1.9.1.
			* Lucks, Stefan; Schuler, Andreas; Tews, Eric; Weinmann, Ralf-Philipp; Wenzel, Matthias (Jahr unbekannt): Attacks on the DECT authentication mechanisms. Internet: http://www.dedected.org.
			* Mengele, Alexandra (2009): Diplomarbeit: Security of Digital Enhanced Cordless Telecommunication (DECT) devices for residential use. Darmstadt.

			== Weiterführende Links ==
			* [http://www.dedected.org dedected.org]: Offizielle Webseite der Forschungsgruppe.
			* [http://chaosradio.ccc.de/archive/chaosradio_express_102.mp3 Chaosradio Express] im Interview mit den o. g. Wissenschaftlern zum Thema DECT.
			* [http://ftp.ccc.de/congress/25c3/video_h264_720x576/25c3-2937-en-dect.mp4 CCC-Konferenz-Video] zum Thema DECT.

Aureliano: /* PCMCI-Card patchen zur Imitierung einer Basistation */

2009-10-23T17:33:03Z

PCMCI-Card patchen zur Imitierung einer Basistation

← Older revision		Revision as of 17:33, 23 October 2009
Line 97:		Line 97:
	==== PCMCI-Card patchen zur Imitierung einer Basistation ====		==== PCMCI-Card patchen zur Imitierung einer Basistation ====

	Die besagten Wissenschaftler haben ebenfalls gezeigt, dass mit Hilfe der RFPI einer anderen Basisstation der eigene Computer mit PCMCI-Card zum Konkurrenten wird. Dazu zeichnet man im ersten Schritt die RFPI auf und patcht die PCMCI-Card mit diesem Code. Mit speziell geschriebenen Treibern im Broadcasting-~~Mode~~ ist es nun möglich, einem Headset eine ~~falsche~~ Identität mitzuteilen (Spoofing) und gegebenenfalls eine Kommunikation aufzubauen. Dies ist jedoch nur möglich aufgrund weiterer Defizite in der Implementation. So muss die Basisstation dem Headset nur mitteilen, dass es keine Verschlüsselung kann, um eine verschlüsselte Kommunikation zu vermeiden. Ebenso ist bei den meisten Telefonen eine Authentifizierung der Basisstation nicht vorgesehen.		Die besagten Wissenschaftler haben ebenfalls gezeigt, dass mit Hilfe der RFPI einer anderen Basisstation der eigene Computer mit PCMCI-Card zum Konkurrenten wird. Dazu zeichnet man im ersten Schritt die RFPI auf und patcht die PCMCI-Card mit diesem Code. Mit speziell geschriebenen Treibern im Broadcasting-Modus ist es nun möglich, einem Headset eine "richtige" Identität mitzuteilen (Spoofing) und gegebenenfalls eine Kommunikation aufzubauen. Dies ist jedoch nur möglich aufgrund weiterer Defizite in der Implementation. So muss die Basisstation dem Headset nur mitteilen, dass es keine Verschlüsselung kann, um eine verschlüsselte Kommunikation zu vermeiden. Ebenso ist bei den meisten Telefonen eine Authentifizierung der Basisstation nicht vorgesehen.

	== Fazit ==		== Fazit ==

Aureliano: /* Schwache Pseudo-Zufallszahlen-Generatoren */

2009-10-23T17:30:57Z

Schwache Pseudo-Zufallszahlen-Generatoren

← Older revision		Revision as of 17:30, 23 October 2009
Line 91:		Line 91:
	==== Schwache Pseudo-Zufallszahlen-Generatoren ====		==== Schwache Pseudo-Zufallszahlen-Generatoren ====

	Es hat sich herausgestellt, dass viele Hersteller schwache Pseudo-Zufallszahlen-Generatoren (PZZG) implementiert haben. Bei einigen Basisstationen wurde festgestellt, dass der 64-Bit-Zufallswert nur eine Entropie von 24 Bits besaß. Die Entropie lässt sich jedoch einigermaßen leicht ermitteln. Da der Authentication Key immer gleich bleibt, verändern sich bei der Authentifizierung immer nur die Zufallszahlen RS und RAND_X. RES ist wiederum abhängig von AK, RS und RAND_X. Dadurch, dass sich ~~also~~ nur RS und RAND_X verändern, lässt sich die Entropie feststellen.		Es hat sich herausgestellt, dass viele Hersteller schwache Pseudo-Zufallszahlen-Generatoren (PZZG) implementiert haben. Bei einigen Basisstationen wurde festgestellt, dass der 64-Bit-Zufallswert nur eine Entropie von 24 Bits besaß. Die Entropie lässt sich jedoch einigermaßen leicht ermitteln. Da der Authentication Key immer gleich bleibt, verändern sich bei der Authentifizierung immer nur die Zufallszahlen RS und RAND_X. RES ist wiederum abhängig von AK, RS und RAND_X. Dadurch, dass sich nur RS und RAND_X verändern, lässt sich die Entropie feststellen.

	Wird für den AK nur ein 4-~~stelligen~~ PIN benutzt, steigt die Wahrscheinlichkeit noch mehr, dass sowohl Zufallszahlen und PIN durch Brute-Force-Angriffe herausgefunden werden können und eine illegitime Authentifizierung möglich ist.		Wird für den AK nur ein 4-stelliger PIN benutzt, steigt die Wahrscheinlichkeit noch mehr, dass sowohl Zufallszahlen und PIN durch Brute-Force-Angriffe herausgefunden werden können und eine illegitime Authentifizierung möglich ist.

	==== PCMCI-Card patchen zur Imitierung einer Basistation ====		==== PCMCI-Card patchen zur Imitierung einer Basistation ====

Aureliano: /* Cassable-Kryptoanalyse */

2009-10-23T17:27:44Z

Cassable-Kryptoanalyse

← Older revision		Revision as of 17:27, 23 October 2009
Line 83:		Line 83:
	Das übergeordnete Ziel dieses Angriffs ist eine Fremdauthentifikation, um bspw. ein Headset zu imitieren. Die Aufgabe besteht in der Rückgewinnung des Session Keys KS oder des Authentication Keys UAK, mit dessen Hilfe sich der ganze Authentifizierungsprozess imitieren lässt. Voraussetzung für diesen Angriff ist die Aufzeichnung der offen übertragenen Eingangsparameter RS, RAND_X und RES zu Beginn einer Authentifikation.		Das übergeordnete Ziel dieses Angriffs ist eine Fremdauthentifikation, um bspw. ein Headset zu imitieren. Die Aufgabe besteht in der Rückgewinnung des Session Keys KS oder des Authentication Keys UAK, mit dessen Hilfe sich der ganze Authentifizierungsprozess imitieren lässt. Voraussetzung für diesen Angriff ist die Aufzeichnung der offen übertragenen Eingangsparameter RS, RAND_X und RES zu Beginn einer Authentifikation.

	Für die (differentielle) Kryptoanalyse setzten die Wissenschaftler voraus, dass der Angreifer zwei Klartextnachrichten verschlüsseln kann, die sich in jedem zweiten Byte gleichen, und im Besitzt von RS und RAND_X ~~sind~~, welche durch passives Aufzeichnen ermittelbar sind. Sie fanden heraus, dass der Schlüssel mit etwas Glück und genügend Rechenaufwand zurück gewonnen werden kann.		Für die (differentielle) Kryptoanalyse setzten die Wissenschaftler voraus, dass der Angreifer zwei Klartextnachrichten verschlüsseln kann, die sich in jedem zweiten Byte gleichen, und im Besitzt von RS und RAND_X ist, welche durch passives Aufzeichnen ermittelbar sind. Sie fanden heraus, dass der Schlüssel mit etwas Glück und genügend Rechenaufwand zurück gewonnen werden kann.

	==== Klartext-Chiffretext-Angriff ====		==== Klartext-Chiffretext-Angriff ====

Aureliano: /* Chiffren */

2009-10-23T17:25:02Z

Chiffren

← Older revision		Revision as of 17:25, 23 October 2009
Line 71:		Line 71:
	=== Chiffren ===		=== Chiffren ===

	* DECT-Standard-Authentication-~~AlgorithmDer~~ DSAA ist in den Boxen A11, A12, A21 und A22 implementiert. Er besteht aus vier Blockchiffren, die von den Kryptoanalytikern als Cassable-Blockchiffren bezeichnet werden. DSAA erhält als Eingabeparameter die beiden Zufallszahlen RS, RAND_X und den Authentication-Key AK. Als Ausgabe produziert er dann je nach A-Box die Werte KS, RES oder DCK.		* '''DECT-Standard-Authentication-Algorithm''': Der DSAA ist in den Boxen A11, A12, A21 und A22 implementiert. Er besteht aus vier Blockchiffren, die von den Kryptoanalytikern als Cassable-Blockchiffren bezeichnet werden. DSAA erhält als Eingabeparameter die beiden Zufallszahlen RS, RAND_X und den Authentication-Key AK. Als Ausgabe produziert er dann je nach A-Box die Werte KS, RES oder DCK.

	* DECT-Stardard-~~CipherDer~~ DSC besteht aus einen Schlüsselgenerator, der einen kontinuierlichen Schlüsselstrom erzeugt. Dieser wird mit dem Datenstrom XOR-verknüpft. Sein Aufbau ähnelt stark dem A5-Algorithmus, welcher bei GSM-Netzen eingesetzt wird. Als Eingangsparameter erhält er entweder den aus dem DSAA abgeleiteten Schlüssel DCK oder einen statischen Schlüssel SK.		* '''DECT-Stardard-Cipher''': Der DSC besteht aus einen Schlüsselgenerator, der einen kontinuierlichen Schlüsselstrom erzeugt. Dieser wird mit dem Datenstrom XOR-verknüpft. Sein Aufbau ähnelt stark dem A5-Algorithmus, welcher bei GSM-Netzen eingesetzt wird. Als Eingangsparameter erhält er entweder den aus dem DSAA abgeleiteten Schlüssel DCK oder einen statischen Schlüssel SK.

	=== Angriffe ===		=== Angriffe ===

Aureliano: /* Sicherheitsarchitektur */

2009-10-23T17:17:04Z

Sicherheitsarchitektur

← Older revision		Revision as of 17:17, 23 October 2009
Line 25:		Line 25:
	== Sicherheitsarchitektur ==		== Sicherheitsarchitektur ==

	[[Image:arch.jpg]]		[[Image:arch.jpg\|650px]]

	Die Sicherheitsarchitektur ist der einzige Bestandteil des DECT-Standards, der unter Verschluss gehalten wird. Der Einsatz dieser Sicherheit ist für Hersteller von schnurloser Technik nur über einen speziellen Vertrag gestattet, der zur Verschwiegenheit verpflichtet und keine weitergehenden Patentierungen erlaubt. Wissenschaftler und Mitglieder des Chaos Computer Clubs ist es jedoch gelungen, die DECT-Sicherheitsarchitektur durch Reverse-Engeneering und unter zur Hilfenahme eines Alcatell-Patents offen zu legen.		Die Sicherheitsarchitektur ist der einzige Bestandteil des DECT-Standards, der unter Verschluss gehalten wird. Der Einsatz dieser Sicherheit ist für Hersteller von schnurloser Technik nur über einen speziellen Vertrag gestattet, der zur Verschwiegenheit verpflichtet und keine weitergehenden Patentierungen erlaubt. Wissenschaftler und Mitglieder des Chaos Computer Clubs ist es jedoch gelungen, die DECT-Sicherheitsarchitektur durch Reverse-Engeneering und unter zur Hilfenahme eines Alcatell-Patents offen zu legen.

← Older revision		Revision as of 20:44, 23 October 2009
Line 15:		Line 15:
	==== Logische Kommunikation ====		==== Logische Kommunikation ====

	Grundsätzlich hat die Basisstation eine Meldepflicht gegenüber dem ~~Headset~~. Dies bedeutet, dass es durch kontinuierliches Senden von kleinen Informationspaketen (engl.: Beacons) auf sich aufmerksam macht. Dieses Paket enthält Informationen zu seiner Identität (Radio Fixed Part Identity, RFPI), System-Eigenschaften, seinem Status und einige Paging-Informationen für eingehende Anrufe. Das ~~Headset~~ verhält sich die meiste Zeit über passiv, solange es nicht zu einem Kommunikationsversuch kommt.		Grundsätzlich hat die Basisstation eine Meldepflicht gegenüber dem Handset. Dies bedeutet, dass es durch kontinuierliches Senden von kleinen Informationspaketen (engl.: Beacons) auf sich aufmerksam macht. Dieses Paket enthält Informationen zu seiner Identität (Radio Fixed Part Identity, RFPI), System-Eigenschaften, seinem Status und einige Paging-Informationen für eingehende Anrufe. Das Handset verhält sich die meiste Zeit über passiv, solange es nicht zu einem Kommunikationsversuch kommt.

	Für eingehende Anrufe initiiert die Basisstation die Kommunikation, indem es ein sogenanntes CC-Setup-Paket (Calling-Control) sendet. Die Informationen in diesem Paket enthalten u. a. die Identität des ~~Headsets~~ und die Anrufernummer. Im nächsten Schritt bestimmt das ~~Headset~~ über ein CC-Connect-Paket, auf welchem Kanal die Kommunikation stattfinden soll (dynamische Kanalwahl). Ist dies vollbracht, kann die Authentifizierung, Chiffre-Auswahl und die eigentliche Kommunikation stattfinden.		Für eingehende Anrufe initiiert die Basisstation die Kommunikation, indem es ein sogenanntes CC-Setup-Paket (Calling-Control) sendet. Die Informationen in diesem Paket enthalten u. a. die Identität des Handsets und die Anrufernummer. Im nächsten Schritt bestimmt das Handset über ein CC-Connect-Paket, auf welchem Kanal die Kommunikation stattfinden soll (dynamische Kanalwahl). Ist dies vollbracht, kann die Authentifizierung, Chiffre-Auswahl und die eigentliche Kommunikation stattfinden.

	Für ausgehende Anrufe sendet diesmal das ~~Headset~~ ein CC-Setup-Paket. Auch hier bestimmt das ~~Headset~~, auf welchem Kanal kommuniziert werden soll. Die Basisstation antwortet mit einem CC-Connect-Paket.		Für ausgehende Anrufe sendet diesmal das Handset ein CC-Setup-Paket. Auch hier bestimmt das Handset, auf welchem Kanal kommuniziert werden soll. Die Basisstation antwortet mit einem CC-Connect-Paket.

	Die Kanalwahl erfolgt nach physikalischen Kriterien. Wenig Interferenz bedeutet eine höhere Güte. Aus Effizienzgründen erzeugt das ~~Headset~~ mindestens alle 30 Sekunden eine interne RSSI-Liste (Radio-Signal-Strength-Indication) mit allen idealen Kanälen, auf die sie später bei der dynamischen Kanalwahl zurückgreift. Auch bei zwischenzeitlichen Störungen ist ein dynamischer Kanalwechsel möglich.		Die Kanalwahl erfolgt nach physikalischen Kriterien. Wenig Interferenz bedeutet eine höhere Güte. Aus Effizienzgründen erzeugt das Handset mindestens alle 30 Sekunden eine interne RSSI-Liste (Radio-Signal-Strength-Indication) mit allen idealen Kanälen, auf die sie später bei der dynamischen Kanalwahl zurückgreift. Auch bei zwischenzeitlichen Störungen ist ein dynamischer Kanalwechsel möglich.

	== Sicherheitsarchitektur ==		== Sicherheitsarchitektur ==
Line 29:		Line 29:
	Die Sicherheitsarchitektur ist der einzige Bestandteil des DECT-Standards, der unter Verschluss gehalten wird. Der Einsatz dieser Sicherheit ist für Hersteller von schnurloser Technik nur über einen speziellen Vertrag gestattet, der zur Verschwiegenheit verpflichtet und keine weitergehenden Patentierungen erlaubt. Wissenschaftler und Mitglieder des Chaos Computer Clubs ist es jedoch gelungen, die DECT-Sicherheitsarchitektur durch Reverse-Engeneering und unter zur Hilfenahme eines Alcatell-Patents offen zu legen.		Die Sicherheitsarchitektur ist der einzige Bestandteil des DECT-Standards, der unter Verschluss gehalten wird. Der Einsatz dieser Sicherheit ist für Hersteller von schnurloser Technik nur über einen speziellen Vertrag gestattet, der zur Verschwiegenheit verpflichtet und keine weitergehenden Patentierungen erlaubt. Wissenschaftler und Mitglieder des Chaos Computer Clubs ist es jedoch gelungen, die DECT-Sicherheitsarchitektur durch Reverse-Engeneering und unter zur Hilfenahme eines Alcatell-Patents offen zu legen.

	Die Architektur sieht an verschiedenen Stellen Schlüssel vor, die erstens für die Schlüsselallokation, zweitens für die Authentifizierung und drittens für die Verschlüsselung verwendet werden. Die Schlüsselallokation markiert in der Realität einen einmaligen Vorgang im Stadium der Montage, kann jedoch theoretisch beliebig wiederholt werden. Die Authentifizierung ist ein Sicherheitsmerkmal, dass jederzeit von beiden Geräten optional eingesetzt werden kann, sofern es vom Hersteller eingebaut wurde. Der Standard sieht jedoch mindestens eine Authentifizierung des ~~Headsets~~ bei der Basisstation vor. Auch die Verschlüsselung ist ein optionales Merkmal, dass in der Realität nicht durchgängig eingesetzt wird.		Die Architektur sieht an verschiedenen Stellen Schlüssel vor, die erstens für die Schlüsselallokation, zweitens für die Authentifizierung und drittens für die Verschlüsselung verwendet werden. Die Schlüsselallokation markiert in der Realität einen einmaligen Vorgang im Stadium der Montage, kann jedoch theoretisch beliebig wiederholt werden. Die Authentifizierung ist ein Sicherheitsmerkmal, dass jederzeit von beiden Geräten optional eingesetzt werden kann, sofern es vom Hersteller eingebaut wurde. Der Standard sieht jedoch mindestens eine Authentifizierung des Handsets bei der Basisstation vor. Auch die Verschlüsselung ist ein optionales Merkmal, dass in der Realität nicht durchgängig eingesetzt wird.

	Das Bild zeigt die komplette Architektur, so wie sie in Basisstation und ~~Headset~~ verbaut sind. Trotzdem gibt es Bereiche, die aus logischer Sicht jeweils einem der beiden Geräte zugeordent sind. Der dunkelgrüne Bereiche dient der Basisstation (FP) zur Authentifizierung des ~~Headsets~~ (PP). Der hellgrüne Bereich dient der Authentifizierung der Basisstation beim ~~Headset~~. Diese logische Aufteilung ist sowohl durch die übermittelten Parameter des jeweiligen Partners als auch durch verschiedene Chiffre-Algorithmen zu begründen, die sich im hellgrünen und dunkelgrünen Bereich befinden.		Das Bild zeigt die komplette Architektur, so wie sie in Basisstation und Handset verbaut sind. Trotzdem gibt es Bereiche, die aus logischer Sicht jeweils einem der beiden Geräte zugeordent sind. Der dunkelgrüne Bereiche dient der Basisstation (FP) zur Authentifizierung des Handsets (PP). Der hellgrüne Bereich dient der Authentifizierung der Basisstation beim Handset. Diese logische Aufteilung ist sowohl durch die übermittelten Parameter des jeweiligen Partners als auch durch verschiedene Chiffre-Algorithmen zu begründen, die sich im hellgrünen und dunkelgrünen Bereich befinden.

	=== Schlüsselallokation ===		=== Schlüsselallokation ===
Line 45:		Line 45:
	=== Authentifizierung ===		=== Authentifizierung ===

	Die für die Authentifizierung benutzte Algorithmus firmiert unter dem Namen DECT-Standard-Authentication-Algorithm (kurz: DSAA). Die Authentifizierung verfährt nach dem Challenge-Response-Mechanismus. Im ersten Schritt berechnet die Basisstation zwei Zufallszahlen RS und RAND_FP, aus denen es mit Hilfe von AK einen Wert RES1 errechnet. In einem zweiten Schritt (Challenge) sendet die Basisstation die Zufallswerte RS und RAND_FP in einer {Key-Allocate}-Nachricht an das ~~Headset~~. Das ~~Headset~~ berechnet nun aus den beiden Werten und dem AK ebenfalls einen Wert RES2 und sendet (Response) diesen Wert an die Basisstation. In einem letzten Schritt überprüft die Basisstation die beiden Werte RES1 und RES2 auf Gleichheit. Anzumerken ist, dass während dieses Prozesses ein intermediärer Schlüssel SAK als auch ein Chiffre-Schlüssel namens Derived Cipher Key (kurz: DCK) entstanden sind.		Die für die Authentifizierung benutzte Algorithmus firmiert unter dem Namen DECT-Standard-Authentication-Algorithm (kurz: DSAA). Die Authentifizierung verfährt nach dem Challenge-Response-Mechanismus. Im ersten Schritt berechnet die Basisstation zwei Zufallszahlen RS und RAND_FP, aus denen es mit Hilfe von AK einen Wert RES1 errechnet. In einem zweiten Schritt (Challenge) sendet die Basisstation die Zufallswerte RS und RAND_FP in einer {Key-Allocate}-Nachricht an das Handset. Das Handset berechnet nun aus den beiden Werten und dem AK ebenfalls einen Wert RES2 und sendet (Response) diesen Wert an die Basisstation. In einem letzten Schritt überprüft die Basisstation die beiden Werte RES1 und RES2 auf Gleichheit. Anzumerken ist, dass während dieses Prozesses ein intermediärer Schlüssel SAK als auch ein Chiffre-Schlüssel namens Derived Cipher Key (kurz: DCK) entstanden sind.

	Der soeben beschriebene Prozess bezeichnet nur eine einseitige Authentifizierung des ~~Headset~~ bei der Basistation und kann umgekehrt auch verwendet werden, nur das dabei kein DCK entsteht. Die Realität zeigt jedoch, dass eine Authentifizierung der Basisstation beim ~~Headset~~ nicht stattfindet und so Angriffe möglich sind.		Der soeben beschriebene Prozess bezeichnet nur eine einseitige Authentifizierung des Handset bei der Basistation und kann umgekehrt auch verwendet werden, nur das dabei kein DCK entsteht. Die Realität zeigt jedoch, dass eine Authentifizierung der Basisstation beim Handset nicht stattfindet und so Angriffe möglich sind.

	=== Verschlüsselung ===		=== Verschlüsselung ===
Line 59:		Line 59:
	=== Motivation für Angriffe ===		=== Motivation für Angriffe ===

	* '''Imitieren eines Teilnehmer-~~Headsets~~''': Der Knackpunkt an diesem Angriff ist die Authentifizierung. Sollte es dem Angreifer gelingen sich mit seinem eigenen ~~Headset~~ bei einer fremden Basisstation zu authentifizieren, könnte er damit beispielsweise den Telefondienst kostenfrei in Anspruch nehmen.		* '''Imitieren eines Teilnehmer-Handsets''': Der Knackpunkt an diesem Angriff ist die Authentifizierung. Sollte es dem Angreifer gelingen sich mit seinem eigenen Handset bei einer fremden Basisstation zu authentifizieren, könnte er damit beispielsweise den Telefondienst kostenfrei in Anspruch nehmen.

	* '''Illegale Benutzung von ~~Headsets~~''': Hier handelt es sich um eine eher formale Angelegenheit. Hersteller wollen verhindern, dass ihre Systeme mit Fremdgeräten benutzt werden. Der Nutzen für den Anwender könnte sein, dass ein anderes ~~Headset~~ beispielsweise einen weiteren Funktionsumfang hat.		* '''Illegale Benutzung von Handsets''': Hier handelt es sich um eine eher formale Angelegenheit. Hersteller wollen verhindern, dass ihre Systeme mit Fremdgeräten benutzt werden. Der Nutzen für den Anwender könnte sein, dass ein anderes Handset beispielsweise einen weiteren Funktionsumfang hat.

	* '''Illegale Benutzung von Basisstationen''': Eine Motivation hinter diesem Angriff könnte die Umgehung der Netzwerktechnik sein. Die bestehenden Basisstationen könnten so konfiguriert sein, dass sie nur einen eingeschränkten Zugang zulassen (z. B. eingeschränkte Rufnummernlisten oder Anrufzeiten). Dies ließe sich mit einer eigenen, an das Telefonnetz verbunden Basisstation umgehen.		* '''Illegale Benutzung von Basisstationen''': Eine Motivation hinter diesem Angriff könnte die Umgehung der Netzwerktechnik sein. Die bestehenden Basisstationen könnten so konfiguriert sein, dass sie nur einen eingeschränkten Zugang zulassen (z. B. eingeschränkte Rufnummernlisten oder Anrufzeiten). Dies ließe sich mit einer eigenen, an das Telefonnetz verbunden Basisstation umgehen.

	* '''Imitieren einer Basisstation''': Diese Methode ermöglicht sowohl passive als auch aktive Angriffe. Der Angreifer übernimmt eine spezielle RFPI einer umliegenden Basisstation in sein System, dass auch Basisstation-Funktionalitäten besitzt (z. B. PCMCI-Card). Ohne es zu merken wählt sich ein ~~Headset~~ bei dem Angreifer-System ein, in dem Glauben, es handele sich um die originale Basisstation. Der Angreifer ist jetzt frei, die Daten mitzuschneiden, Manipulationen vorzunehmen oder sogar die Kommunikation zu unterbrechen.		* '''Imitieren einer Basisstation''': Diese Methode ermöglicht sowohl passive als auch aktive Angriffe. Der Angreifer übernimmt eine spezielle RFPI einer umliegenden Basisstation in sein System, dass auch Basisstation-Funktionalitäten besitzt (z. B. PCMCI-Card). Ohne es zu merken wählt sich ein Handset bei dem Angreifer-System ein, in dem Glauben, es handele sich um die originale Basisstation. Der Angreifer ist jetzt frei, die Daten mitzuschneiden, Manipulationen vorzunehmen oder sogar die Kommunikation zu unterbrechen.

	* '''Mitschneiden von Daten''': Bei diesem passiven Angriff werden über ein spezielles Abhörgerät die Daten aus der Luft aufgezeichnet.		* '''Mitschneiden von Daten''': Bei diesem passiven Angriff werden über ein spezielles Abhörgerät die Daten aus der Luft aufgezeichnet.
Line 81:		Line 81:
	==== Cassable-Kryptoanalyse ====		==== Cassable-Kryptoanalyse ====

	Das übergeordnete Ziel dieses Angriffs ist eine Fremdauthentifikation, um bspw. ein ~~Headset~~ zu imitieren. Die Aufgabe besteht in der Rückgewinnung des Session Keys KS oder des Authentication Keys UAK, mit dessen Hilfe sich der ganze Authentifizierungsprozess imitieren lässt. Voraussetzung für diesen Angriff ist die Aufzeichnung der offen übertragenen Eingangsparameter RS, RAND_X und RES zu Beginn einer Authentifikation.		Das übergeordnete Ziel dieses Angriffs ist eine Fremdauthentifikation, um bspw. ein Handset zu imitieren. Die Aufgabe besteht in der Rückgewinnung des Session Keys KS oder des Authentication Keys UAK, mit dessen Hilfe sich der ganze Authentifizierungsprozess imitieren lässt. Voraussetzung für diesen Angriff ist die Aufzeichnung der offen übertragenen Eingangsparameter RS, RAND_X und RES zu Beginn einer Authentifikation.

	Für die (differentielle) Kryptoanalyse setzten die Wissenschaftler voraus, dass der Angreifer zwei Klartextnachrichten verschlüsseln kann, die sich in jedem zweiten Byte gleichen, und im Besitzt von RS und RAND_X ist, welche durch passives Aufzeichnen ermittelbar sind. Sie fanden heraus, dass der Schlüssel mit etwas Glück und genügend Rechenaufwand zurück gewonnen werden kann.		Für die (differentielle) Kryptoanalyse setzten die Wissenschaftler voraus, dass der Angreifer zwei Klartextnachrichten verschlüsseln kann, die sich in jedem zweiten Byte gleichen, und im Besitzt von RS und RAND_X ist, welche durch passives Aufzeichnen ermittelbar sind. Sie fanden heraus, dass der Schlüssel mit etwas Glück und genügend Rechenaufwand zurück gewonnen werden kann.
Line 97:		Line 97:
	==== PCMCI-Card patchen zur Imitierung einer Basistation ====		==== PCMCI-Card patchen zur Imitierung einer Basistation ====

	Die besagten Wissenschaftler haben ebenfalls gezeigt, dass mit Hilfe der RFPI einer anderen Basisstation der eigene Computer mit PCMCI-Card zum Konkurrenten wird. Dazu zeichnet man im ersten Schritt die RFPI auf und patcht die PCMCI-Card mit diesem Code. Mit speziell geschriebenen Treibern im Broadcasting-Modus ist es nun möglich, einem ~~Headset~~ eine "richtige" Identität mitzuteilen (Spoofing) und gegebenenfalls eine Kommunikation aufzubauen. Dies ist jedoch nur möglich aufgrund weiterer Defizite in der Implementation. So muss die Basisstation dem ~~Headset~~ nur mitteilen, dass es keine Verschlüsselung kann, um eine verschlüsselte Kommunikation zu vermeiden. Ebenso ist bei den meisten Telefonen eine Authentifizierung der Basisstation nicht vorgesehen.		Die besagten Wissenschaftler haben ebenfalls gezeigt, dass mit Hilfe der RFPI einer anderen Basisstation der eigene Computer mit PCMCI-Card zum Konkurrenten wird. Dazu zeichnet man im ersten Schritt die RFPI auf und patcht die PCMCI-Card mit diesem Code. Mit speziell geschriebenen Treibern im Broadcasting-Modus ist es nun möglich, einem Handset eine "richtige" Identität mitzuteilen (Spoofing) und gegebenenfalls eine Kommunikation aufzubauen. Dies ist jedoch nur möglich aufgrund weiterer Defizite in der Implementation. So muss die Basisstation dem Handset nur mitteilen, dass es keine Verschlüsselung kann, um eine verschlüsselte Kommunikation zu vermeiden. Ebenso ist bei den meisten Telefonen eine Authentifizierung der Basisstation nicht vorgesehen.

	== Fazit ==		== Fazit ==