abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du 
Aktuelle Eilmeldungen

TV: Kabelfernsehen wird Mietersache. Jetzt handeln!

 

Deine Störung ist nicht dabei? Dann nutz unseren Störungsfinder!

1

Frage

2

Antwort

3

Lösung

Vodafone Kabel: Verschlüsselung ist 3DES?!
Konichua1337
Forum-Checker
Forum-Checker

Hallo,

ich wollte mal fragen wie es um die Verschlüsselung des Docsis Mediums bestellt ist?
Ich habe auf meinem (eigenen) Modem mal ein bisschen geschaut und bin stutzig geworden, da scheinbar noch 3DES zum Einsatz kommt, was ja seit mindestens 7 Jahren als unsicher gilt.

Kann das sein, und wenn ja, warum kommt nicht mindestens AES zum Einsatz? Ich habe das mit dem RFC 4131 (BPI+) abgeglichen.

 

Konichua1337_1-1707566209641.png

 

Konichua1337_2-1707567420348.png

 

 

4 Antworten 4
J0hann
Moderator:in
Moderator:in

Hallo @Konichua1337,

 

über die Gründe für gewählte Verfahren kann ich leider keine Angaben machen.

 

LG J0hann 

Bewertet hilfreiche Beiträge mit Likes!
reneromann
SuperUser
SuperUser

Am Besten du liest dir mal die DOCSIS 3.1 Security Specification durch -- dann weißt du, warum dort Two-Key 3DES (noch immer) zum Einsatz kommt -- Einer der Hintergründe ist die Rückwärtskompatibilität bis hin zu DOCSIS1.1-Geräten, wobei zumindest DOCSIS2.0-Geräte z.T. noch immer im Kabelnetz unterwegs sind.

 

Davon abgesehen findet regeläßig auch eine Schlüsselrotation statt - du kannst also nicht die Werte von klassischem 3DES einfach so auf DOCSIS übertragen, ganz davon abgesehen, dass die Verschlüsselung auf der DOCSIS-Schnittstelle lediglich das Mitlesen der Nachrichten für die Nachbarn erschweren soll und keinen absolut sicheren Schutz darstellt, zumal die Sendeseite der Verbindung dir i.d.R. komplett fehlt. Wer eine gesicherte Übertragung hin zu einem Server im Internet will, sollte eh nur auf SSL-Verbindungen entsprechender Verschlüsselungstiefe zurückgreifen und nicht unverschlüsselt Daten übertragen.

Und gerade wenn das CM eine bessere Verschlüsselung anfragt und das CMTS diese auch unterstützt, werden bessere Verschlüsselungen auch für die Datenverbindung genutzt -- nur die initiale Aushandlung muss weiterhin per 3DES (aus Kompatibilitätsgründen) erfolgen.

 

Und RFCs helfen bei DOCSIS nicht weiter - DOCSIS ist ein Standard von CableLabs, da sollte man auch im Standard nachlesen und nicht in RFCs. Zumal: Nur weil etwas in den RFCs als Möglichkeit genannt wird, heißt es längst nicht, dass das auch noch aktiv im Einsatz ist. Diese Auflistungen müssen rückwärtskompatibel sein - es darf auf keinen Fall dazu kommen, dass ein bestimmter Wert bei einer neueren Revision der Spezifikation auf einmal eine andere Bedeutung hat.

Also ich sehe das schon deutlich kritischer. Hier mal ein paar Punkte:

 

"Davon abgesehen findet regeläßig auch eine Schlüsselrotation statt - du kannst also nicht die Werte von klassischem 3DES einfach so auf DOCSIS übertragen"

Was spielt das für eine Rolle, wenn der Angreifer in der Lage ist den gesamten Traffic mitzuschneiden? Im Zweifelsfall wiederholt er das knacken der Verschlüsselung für jede Rotationsperiode. Von Downgrade Attacken fangen wir mal gar nicht erst an, wenn selbst im Default Modus schon eine derartig schlechte Verschlüsselung gewählt wird.


" zumal die Sendeseite der Verbindung dir i.d.R. komplett fehlt"

 

Verstehe ich nicht. Mal angenommen man liest den Traffic mit Hilfe eines modifizierten DVB-C Receivers (oder gecrackte FritzBox, im besten Fall ein SDR) mit, dann habe ich doch den gesamten Traffic auf dem Segment. Up- wie Downstream Frames.

 

"Wer eine gesicherte Übertragung hin zu einem Server im Internet will, sollte eh nur auf SSL-Verbindungen entsprechender Verschlüsselungstiefe zurückgreifen und nicht unverschlüsselt Daten übertragen"

 

Das kann man ja immer behaupten. Es entbindet den Provider trotzdem nicht von seiner Sorgfaltspflicht mMn. Andere Point to Multipoint Technologien machen es ja auch besser, etwa GPON (und da ist die Chance eines Auslesens nochmal deutlich geringer, da passiv kaum möglich). Wenn das mit Kosten verbunden ist, muss der ISP halt in die Tasche greifen und alte Modems tauschen.

 

"Und gerade wenn das CM eine bessere Verschlüsselung anfragt und das CMTS diese auch unterstützt, werden bessere Verschlüsselungen auch für die Datenverbindung genutzt "

Das liest sich aber in deiner verlinkten Spezifikation ganz anders:

 


As part of their authorization exchange, the CM provides the CMTS with a list of supported cryptographic suites.
The CMTS selects from this list a single suite to use with the CM's Primary SA. In the Authorization Reply, the
CMTS includes a Primary SA descriptor that identifies the cryptographic suite selected by the CMTS. A CMTS
MUST reject the Authorization Request if none of the offered cryptographic suites is permitted by local policy.
The Authorization Reply may contain a list of Static SA descriptors; each Static SA descriptor identifies the
cryptographic suite employed by that SA. The selection of a static SA's cryptographic suite is independent of the
requesting CM's cryptographic capabilities. A CMTS MAY include in its Authorization Reply Static SA descriptors
identifying cryptographic suites unsupported by the CM. The CM MUST NOT start TEK state machines for SAs
whose cryptographic suites the CM does not support.

 

"dass ein bestimmter Wert bei einer neueren Revision der Spezifikation auf einmal eine andere Bedeutung hat"

 

Gerade dann macht es ja Sinn auf das RFC zu bauen und als Ground Truth zu 100% zu implementieren.

Insgesamt empfinde ich den DOCSIS Standard als extrem "legacy like" und potentiell unsicher. Das beginnt bei den CM Certs mit RSA 1024 Bit, über die Tatsache dass MIC und CMTS-MIC umgangen werden können und auch nur auf MD5 beruhen, Downgrade Attacken sind möglich, SNMP kann modemseitig abgeschaltet oder gespooft werden (wer überwacht dann eigentlich das Modem bei seinen Entscheidungen?), Nachrichten müssen nicht zwangsweise signiert (keine authentifizierte Verschlüsselung) werden auf dem DOCSIS Medium, bis hin zu dieser 3DES Geschichte. Zusätzlich ist mir aufgefallen dass ja auch die VOIP Gespräche scheinbar nicht gesondert z. B. durch SRTP geschützt werden. Das wirft alles echt kein gutes Bild.

Bleibt zu hoffen dass bald DOCSIS 4.0 Einzug hält, oder die Fiber Technologie übernimmt (was wohl wahrscheinlicher ist, wenn ich lese dass 3.1 noch "Jahre" reichen soll in Deutschland). Denn wer nicht mit der Zeit geht, muss mit der Zeit gehen, wie man so schön sagt.


@Konichua1337  schrieb:

Also ich sehe das schon deutlich kritischer. Hier mal ein paar Punkte:

 

"Davon abgesehen findet regeläßig auch eine Schlüsselrotation statt - du kannst also nicht die Werte von klassischem 3DES einfach so auf DOCSIS übertragen"

Was spielt das für eine Rolle, wenn der Angreifer in der Lage ist den gesamten Traffic mitzuschneiden? Im Zweifelsfall wiederholt er das knacken der Verschlüsselung für jede Rotationsperiode. Von Downgrade Attacken fangen wir mal gar nicht erst an, wenn selbst im Default Modus schon eine derartig schlechte Verschlüsselung gewählt wird.


Wenn die Schlüsselrotation oft genug stattfindet, so dass du nicht innerhalb der gewählten Schlüsselrotationsperiode den Schlüssel knacken kannst, hilft dir der Mitschnitt nichts. Und wie willst du eine "Downgrade Attacke" fahren, wenn du nicht als MITM agieren kannst?

 


@Konichua1337  schrieb:

" zumal die Sendeseite der Verbindung dir i.d.R. komplett fehlt"

Verstehe ich nicht.


Weil du nicht verstanden hast, wie der Aufbau des BK-Netzes und seiner Komponenten funktioniert.

 


@Konichua1337  schrieb:

Mal angenommen man liest den Traffic mit Hilfe eines modifizierten DVB-C Receivers (oder gecrackte FritzBox, im besten Fall ein SDR) mit, dann habe ich doch den gesamten Traffic auf dem Segment. Up- wie Downstream Frames.


Nein, hast du eben nicht. Selbst mit einem FBC-Tuner von 0..862 MHz und einer entsprechend breiten FFT würde dir das nicht weiterhelfen - denn die Diplexer in den einzelnen Dosen und Abzweigern im Netz, spätestens aber die Frequenzweichen in allen Verstärkern würden dir das Signal der anderen Teilnehmer "wegfiltern". Um den vollen Upstream mitlesen zu können (und auch um als CMTS agieren zu können) müsstest du schon direkt am CMTS oder am Remote-PHY sitzen -- wo du aber nicht hin kommst.

 

Du würdest also bestenfalls, wenn du dich direkt am HÜP anklemmst, das Upload-Signal deines eigenen Hauses sehen - mehr nicht. Alle anderen Modems sind in Senderichtung für dich aufgrund der Netzkomponenten unsichtbar.

 


@Konichua1337  schrieb:

"Wer eine gesicherte Übertragung hin zu einem Server im Internet will, sollte eh nur auf SSL-Verbindungen entsprechender Verschlüsselungstiefe zurückgreifen und nicht unverschlüsselt Daten übertragen"

 

Das kann man ja immer behaupten. Es entbindet den Provider trotzdem nicht von seiner Sorgfaltspflicht mMn.


Das hat nichts mit "Behaupten" zu tun, sondern ist einfach die bittere Realität.

Wer meint, dass seine Anschlussleitung sicher ist, dem ist nicht zu helfen.

 


@Konichua1337  schrieb:

Andere Point to Multipoint Technologien machen es ja auch besser, etwa GPON (und da ist die Chance eines Auslesens nochmal deutlich geringer, da passiv kaum möglich). Wenn das mit Kosten verbunden ist, muss der ISP halt in die Tasche greifen und alte Modems tauschen.


GPON hat die gleichen Probleme wie DOCSIS auch - wenn du schon meinst, dass du bei DOCSIS alles mitlesen kannst, kannst du es bei GPON ebenfalls -- denn die Technik in der passiven Verteilung verhält sich für Glas wie für Koax nahezu identisch.

Und wie die DOCSIS-Norm schon schreibt: 3DES wird für einige Teile genutzt -- für andere Teile kann auch AES zum Einsatz kommen, wenn es beide Seiten nutzen können und wollen.

 


@Konichua1337  schrieb:

"Und gerade wenn das CM eine bessere Verschlüsselung anfragt und das CMTS diese auch unterstützt, werden bessere Verschlüsselungen auch für die Datenverbindung genutzt "

Das liest sich aber in deiner verlinkten Spezifikation ganz anders:

 


As part of their authorization exchange, the CM provides the CMTS with a list of supported cryptographic suites.
The CMTS selects from this list a single suite to use with the CM's Primary SA. In the Authorization Reply, the
CMTS includes a Primary SA descriptor that identifies the cryptographic suite selected by the CMTS. A CMTS
MUST reject the Authorization Request if none of the offered cryptographic suites is permitted by local policy.
The Authorization Reply may contain a list of Static SA descriptors; each Static SA descriptor identifies the
cryptographic suite employed by that SA. The selection of a static SA's cryptographic suite is independent of the
requesting CM's cryptographic capabilities. A CMTS MAY include in its Authorization Reply Static SA descriptors
identifying cryptographic suites unsupported by the CM. The CM MUST NOT start TEK state machines for SAs
whose cryptographic suites the CM does not support.

Nein, das liest sich da nicht anders - offenbar hast du keine Ahnung, wie du Spezifikationen lesen musst.

Nur um das klar zu machen: CM ist DEIN Endgerät, CMTS ist die Gegenstelle - wenn DEIN Gerät keine starke Kryptographie kann -UND- das CMTS so konfiguriert wurde, dass es schwache Kryptographie zulässt, dann wird schwache Kryptographie genutzt. Andernfalls wird die Verbindung abgelehnt, wenn die stärkste kryptographische Funktion des CM nicht den Mindestanforderungen des CMTS entspricht.

 


@Konichua1337  schrieb:

"dass ein bestimmter Wert bei einer neueren Revision der Spezifikation auf einmal eine andere Bedeutung hat"

Gerade dann macht es ja Sinn auf das RFC zu bauen und als Ground Truth zu 100% zu implementieren.


Nein, gerade daher macht es Sinn, einen Standard zu erarbeiten, der mit DOCSIS festgelegt wurde. Dieser Standard ist zu 100% zu implementieren und neuere Versionen des Standards geben vor, ob sie "breaking changes" sind oder ob sie weiterhin auf den alten Standards aufsetzen wollen.

 


@Konichua1337  schrieb:

Insgesamt empfinde ich den DOCSIS Standard als extrem "legacy like" und potentiell unsicher. Das beginnt bei den CM Certs mit RSA 1024 Bit, über die Tatsache dass MIC und CMTS-MIC umgangen werden können und auch nur auf MD5 beruhen, Downgrade Attacken sind möglich, SNMP kann modemseitig abgeschaltet oder gespooft werden (wer überwacht dann eigentlich das Modem bei seinen Entscheidungen?), Nachrichten müssen nicht zwangsweise signiert (keine authentifizierte Verschlüsselung) werden auf dem DOCSIS Medium, bis hin zu dieser 3DES Geschichte. Zusätzlich ist mir aufgefallen dass ja auch die VOIP Gespräche scheinbar nicht gesondert z. B. durch SRTP geschützt werden. Das wirft alles echt kein gutes Bild.


Tja, alles Angriffsvektoren die du aber nicht durchführen kannst, wenn du kein eigenes CMTS hast...

Und davon abgesehen weißt du ja auch nicht, was VF da in den Richtlinien konfiguriert hat -- denn nur weil der Standard schwache Kryptographie (noch) erlaubt, heißt das ja längst nicht, dass VF diese noch aktiv hat und nicht per Regel deaktiviert wurde.

Bei den Zertifikaten gilt Ähnliches - was hilft dir ein Zertifikat, wenn es nicht von der richtigen CA stammt? Sowohl die Client- als auch die CMTS-Zertifikate sind allesamt im Ursprung von CableLabs ausgestellt -- und als AVM da mal geschlampt hat, wurde das AVM-Herstellerzertifikat kurzerhand per CRL weltweit gesperrt. Da ging dann mit FritzBoxen gar nichts mehr, bis sie ein Update erhalten haben...

 

SIP ist übrigens kein Part des DOCSIS-Standards, sondern sitzt immer "on top" -- im Kabelnetz kommt historisch begründet eher Packet Cable zum Einsatz.

 


@Konichua1337  schrieb:

Bleibt zu hoffen dass bald DOCSIS 4.0 Einzug hält, oder die Fiber Technologie übernimmt (was wohl wahrscheinlicher ist, wenn ich lese dass 3.1 noch "Jahre" reichen soll in Deutschland).


DOCSIS 4 wird auf absehbare Zeit nich und wahrscheinlich sogar nie kommen - weil DOCSIS 4 kostenmäßig im Vergleich zu remote-PHY und FTTH keinen Sinn macht. Wenn man die Segmente schon so klein macht, dass sie de facto bis in den Keller der Häuser gehen und erst dort von Faser per µNode auf Koax gewandelt werden, braucht es kein DOCSIS 4 mehr, um die notwendigen Bandbreiten zu übertragen.

 

Das ist ungefähr der gleiche Grund, warum auch die Umstellung des Uploads auf 204 MHz zwar schon seit Jahren versprochen wird, aber noch nie vollzogen wurde -- weil dies einen Austausch von vielen Netzkomponenten (insbesondere in den Hausnetzen) erfordert und die entsprechenden Kosten kaum im Verhältnis zum Nutzen stehen. Splittet man die Segmente in zwei oder drei Teile (oder geht mit FTTB bis in den Keller), braucht es 204 MHz nicht mehr [oder man bekommt die 204 MHz dann quasi frei Haus]).

 


@Konichua1337  schrieb:

Denn wer nicht mit der Zeit geht, muss mit der Zeit gehen, wie man so schön sagt.


Das Problem ist eher, dass du anscheinend noch ganz grün hinter den Ohren bist und dich weder damit auskennst, wie man Standards lesen muss (RFCs gehören dazu), noch wie das HFC-Netz aufgebaut ist und schon gar keine betriebswirtschaftlichen Betrachtungen bei deinen Forderungen machst.

 

Das hat schon Gründe, warum Standards abwärtskompatibel (und aufwärtskompatibel) gehalten werden - z.B. ein DOCSIS1.1-Modem sich noch immer mit einem DOCSIS3.1-CMTS unterhalten kann. Oder willst du wirklich bei mehreren Millionen Kunden funktionierende Hardware austauschen und deinen Aktionären erklären müssen, warum du da Kosten in Milliardenhöhe verursacht hast, um effektiv nichts zu erreichen...