Miese.Ratte
Meister
- Registriert
- 20. Juli 2015
- Beiträge
- 992
- Reaktionspunkte
- 2.203
- Punkte
- 263
Kurzfassung
Controlwords (CWs) werden zur Entschlüsselung des Bezahlfernsehens verwendet. Diese sind bei DVB-CSA der ersten Version grundsätzlich 64 Bit lang. Diese Version wird nach wie vor eingesetzt. Von den 64 Bit der CWs waren aber nur 48 Bit tatsächlich (pseudo-)zufällig. Der Rest ließ sich errechnen.
Alte Hard- und Software schaute nur auf die zufälligen 48 Bit und berechnete des Rest ohne weitere Umschweife und setzte ihn ein. Bei OSCam nennt man das „CRC“. Na ja. Meinetwegen.
Bei „standardkonformen“ CWs tat das niemandem weh. Die ersetzten 16 Bit entsprachen den gesendeten. Alles schick! Bei CWs mit 64 Bit (Pseudo-)Zufall geht das Ersetzen allerdings komplett in die Hose. Das Ergebnis kennt ihr: Ruinierte CWs und folglich Dunkelheit.
Wenn man diese „CRC“-Funktion nicht abschalten kann, ist man verloren. Das ist bei Implementierungen in Hardware besonders bitter. Bei Modulen wie Deltacam, Unicam und ganz bestimmt auch dem ACL läuft diese Funktion in Hardware. Dagegen gibt es keinen Softwarefix! Solche Funktionsblöcke sind wie eine geschlossene Gesellschaft.
Ende im Gelände! Kacke aber nicht zu ändern. Nur eine angepasste Software oder eine neue (Modul-)Hardware kann es richten.
Aber was sollte der Quatsch mit 48 Bit überhaupt?
Dazu muss man wissen, dass DVB-CSA aus den 90ern stammt. Zu dieser Zeit gab es schon Organisationen die es gar nicht gab (No Such Agency). Die hatten viel Geld das es gar nicht gab. Davon kauften sie sich Rechenpower die es gar nicht gab.
Diese nicht existierenden Organisationen haben einen unstillbaren Wissensdrang. Der sollte von keiner Verschlüsselung gebremst werden. Das Mittel der 90er war eine Abschwächung der Krypto durch verkürzte Schlüssel (Keys, CWs).
Wer erinnert sich noch an den Netscape-Navigator in der „Export-Version“ mit „internationaler Verschlüsselung“? Jepp. Das war so ein Fall. Es gibt davon reichlich mehr Kandidaten, die wir z. T. bis heute mit uns herum schleppen.
DES mit 56 Bit Zufall und 8 „Paritätsbits“
A5/1 im GSM-Mobilfunk
und bis einschließlich Windows XP und dessen Serverversion:
zusätzliche LANMAN-Hashes für Windows-Passwörter
Es gibt noch viel mehr. Das Ganze nannte und nennt man „Crypto Wars“.
Die LANMAN Hashes waren z. B. richtig sexy. Passwörter wurden nur bis 12 Zeichen Länge verwendet. Der Rest wurde einfach weggeworfen. Als Zuckerguss kam noch die ausschließliche Verwendung von Großbuchstaben dazu. Es ging aber noch besser. Diese 12 Zeichen wurden in Häppchen zu zweimal 6 zerlegt und jeder Teil getrennt gehasht (eine Einwegverschlüsselung). Man brauchte folglich nur noch 6 Zeichen brute force durchprobieren bis der Hash passt.
Für die Hashcat auf Grafikkarten mit OpenCL ist das ein Witz. So schnell kann man kaum Kaffee holen. Das war es sicherlich auch schon in den 90ern für Organisationen die es gar nicht gab.
Mit LANMAN Hashes hatte man so etwas wie eine Gelinggarantie zum Passwörter knacken wenn man Windows-Hashes in die Pfoten bekam.
Ist das nicht nett von den Lieben? Natürlich wurden die Passwörter im Windows total sicher abgelegt. Ha ha!
Nun zu unseren 48 Bit CWs
DVB-CSA hatte sich bis heute keine großen Blößen gegeben. Wer erinnert sich noch an WEP fürs WLAN oder DVDCSS? Das waren auch proprietäre Verschlüsselungen wie DVB-CSA für die man nur noch ein Lächeln übrig hat. Letzteres ist aber absurd aufwändig (in Hardware) umzusetzen. Dieser Fakt hat dem Kram wohl bis heute den Hals gerettet.
48 Bit sind bei dem für DVB-CSA zu treibenden Aufwand schon ein ordentlicher Happen - jedenfalls für Hardware normalsterblicher Leute.
So sehen 48 Bit als dezimale Zahl aus: 281.474.976.710.656
So wurde das CW benutzt:
+--+--+--+--+--+--+--+--+
|b0|b1|b2|b3|b4|b5|b6|b7|
+--+--+--+--+--+--+--+--+
b0..b7 sind die 8 Byte des Controlwords (mal je 8 Bit = 64 Bit)
b0, b1, b2: (pseudo-)zufällig
b3 = b0 + b1 + b2 und anschließend auf 8 Bit verkürzt
b4, b5, b6: (pseudo-)zufällig
b7 = b4 + b5 + b6 und anschließend auf 8 Bit verkürzt
Ich kenne keine 48 Bit CWs, die nicht inklusive der „korrekt“ berechneten b3 und b7 gesendet wurden. Das nachträgliche Ausrechnen und Einsetzen von b3 und b7 war bei allem was ich kenne nicht erforderlich.
Nochmal zur Erinnerung:
Für die Entschlüsselung waren und sind stets die vollständigen 64 Bit erforderlich.
Es wurde eng
Im Jahr 2007 beglückte NVIDIA die Welt mit CUDA. Damit konnte man mit Hilfe deren Grafikkarten prima parallel programmieren. Es gibt wohl kaum ein Problem, das sich so kinderleicht parallelisieren lässt wie „Code knacken“ aka „brute force“.
Mit der Zeit wurde für einen echten Streamhack (brute force auf DVB-CSA) das Licht am Horizont immer deutlicher wahrnehmbar.
Zur Orientierung:
Man kann 48 Bit DVB-CSA mit OpenCL auf einer mittleren Grafikkarte innerhalb von zweieinhalb Tagen komplett durchprobieren. Das geht völlig ohne irgendwelche vorberechneten Tabellen (rainbow tables) wie sie das Tool von Colibri verwendete.
Ok, das ist für ein sich alle sieben Sekunden änderndes CW noch zu lange. Man ahnt aber schon das Licht am Horizont.
Was passiert nun bei der Erweiterung auf echte 64 zu erratende Bits?
Pro zusätzlichem Bit verdoppelt sich der Aufwand. Aus 2,5 Tagen werden 5 und dann 10 und dann für 16 zusätzliche Bits 65.536 x 2,5 Tage, also 163.840 Tage bzw. knappe 449 Jahre. Das gilt für ein CW wohlgemerkt!
Ok, dann suchen wir uns doch ein anderes Hobby.
Die Moral von der Geschichte
Die Umstellung auf echte 64 Bit war dringend angesagt. Man kann niemandem ausschließlich boshafte Absichten unterstellen, der diesen Schritt geht. Der Kollateralschaden bei den alternativen Modulen wird sicherlich gerne mitgenommen. Das war aber ganz bestimmt nicht das eigentliche Ziel.
...und was tun die Organisationen die es gar nicht gibt heute so?
Die greifen den Pseudo-Zufall an, bzw. bringen Hersteller dazu eine gewisse Berechenbarkeit in den PRNG (Generator für Pseudo-Zufall) einzubauen. Das kann man nicht so einfach erkennen wie verkürzte Schlüssel. Ein prominentes Beispiel war der unterwanderte RSA SecureID Token, wenn man ihn mit den Standardeinstellungen verwendete.
PRNGs sind notwendig, da man nicht schnell genug echten Zufall aus vertrauenswürdigen Quellen generieren kann.
Controlwords (CWs) werden zur Entschlüsselung des Bezahlfernsehens verwendet. Diese sind bei DVB-CSA der ersten Version grundsätzlich 64 Bit lang. Diese Version wird nach wie vor eingesetzt. Von den 64 Bit der CWs waren aber nur 48 Bit tatsächlich (pseudo-)zufällig. Der Rest ließ sich errechnen.
Alte Hard- und Software schaute nur auf die zufälligen 48 Bit und berechnete des Rest ohne weitere Umschweife und setzte ihn ein. Bei OSCam nennt man das „CRC“. Na ja. Meinetwegen.
Bei „standardkonformen“ CWs tat das niemandem weh. Die ersetzten 16 Bit entsprachen den gesendeten. Alles schick! Bei CWs mit 64 Bit (Pseudo-)Zufall geht das Ersetzen allerdings komplett in die Hose. Das Ergebnis kennt ihr: Ruinierte CWs und folglich Dunkelheit.
Wenn man diese „CRC“-Funktion nicht abschalten kann, ist man verloren. Das ist bei Implementierungen in Hardware besonders bitter. Bei Modulen wie Deltacam, Unicam und ganz bestimmt auch dem ACL läuft diese Funktion in Hardware. Dagegen gibt es keinen Softwarefix! Solche Funktionsblöcke sind wie eine geschlossene Gesellschaft.
Ende im Gelände! Kacke aber nicht zu ändern. Nur eine angepasste Software oder eine neue (Modul-)Hardware kann es richten.
Aber was sollte der Quatsch mit 48 Bit überhaupt?
Dazu muss man wissen, dass DVB-CSA aus den 90ern stammt. Zu dieser Zeit gab es schon Organisationen die es gar nicht gab (No Such Agency). Die hatten viel Geld das es gar nicht gab. Davon kauften sie sich Rechenpower die es gar nicht gab.
Diese nicht existierenden Organisationen haben einen unstillbaren Wissensdrang. Der sollte von keiner Verschlüsselung gebremst werden. Das Mittel der 90er war eine Abschwächung der Krypto durch verkürzte Schlüssel (Keys, CWs).
Wer erinnert sich noch an den Netscape-Navigator in der „Export-Version“ mit „internationaler Verschlüsselung“? Jepp. Das war so ein Fall. Es gibt davon reichlich mehr Kandidaten, die wir z. T. bis heute mit uns herum schleppen.
DES mit 56 Bit Zufall und 8 „Paritätsbits“
A5/1 im GSM-Mobilfunk
und bis einschließlich Windows XP und dessen Serverversion:
zusätzliche LANMAN-Hashes für Windows-Passwörter
Es gibt noch viel mehr. Das Ganze nannte und nennt man „Crypto Wars“.
Die LANMAN Hashes waren z. B. richtig sexy. Passwörter wurden nur bis 12 Zeichen Länge verwendet. Der Rest wurde einfach weggeworfen. Als Zuckerguss kam noch die ausschließliche Verwendung von Großbuchstaben dazu. Es ging aber noch besser. Diese 12 Zeichen wurden in Häppchen zu zweimal 6 zerlegt und jeder Teil getrennt gehasht (eine Einwegverschlüsselung). Man brauchte folglich nur noch 6 Zeichen brute force durchprobieren bis der Hash passt.
Für die Hashcat auf Grafikkarten mit OpenCL ist das ein Witz. So schnell kann man kaum Kaffee holen. Das war es sicherlich auch schon in den 90ern für Organisationen die es gar nicht gab.
Mit LANMAN Hashes hatte man so etwas wie eine Gelinggarantie zum Passwörter knacken wenn man Windows-Hashes in die Pfoten bekam.
Ist das nicht nett von den Lieben? Natürlich wurden die Passwörter im Windows total sicher abgelegt. Ha ha!
Nun zu unseren 48 Bit CWs
DVB-CSA hatte sich bis heute keine großen Blößen gegeben. Wer erinnert sich noch an WEP fürs WLAN oder DVDCSS? Das waren auch proprietäre Verschlüsselungen wie DVB-CSA für die man nur noch ein Lächeln übrig hat. Letzteres ist aber absurd aufwändig (in Hardware) umzusetzen. Dieser Fakt hat dem Kram wohl bis heute den Hals gerettet.
48 Bit sind bei dem für DVB-CSA zu treibenden Aufwand schon ein ordentlicher Happen - jedenfalls für Hardware normalsterblicher Leute.
So sehen 48 Bit als dezimale Zahl aus: 281.474.976.710.656
So wurde das CW benutzt:
+--+--+--+--+--+--+--+--+
|b0|b1|b2|b3|b4|b5|b6|b7|
+--+--+--+--+--+--+--+--+
b0..b7 sind die 8 Byte des Controlwords (mal je 8 Bit = 64 Bit)
b0, b1, b2: (pseudo-)zufällig
b3 = b0 + b1 + b2 und anschließend auf 8 Bit verkürzt
b4, b5, b6: (pseudo-)zufällig
b7 = b4 + b5 + b6 und anschließend auf 8 Bit verkürzt
Ich kenne keine 48 Bit CWs, die nicht inklusive der „korrekt“ berechneten b3 und b7 gesendet wurden. Das nachträgliche Ausrechnen und Einsetzen von b3 und b7 war bei allem was ich kenne nicht erforderlich.
Nochmal zur Erinnerung:
Für die Entschlüsselung waren und sind stets die vollständigen 64 Bit erforderlich.
Es wurde eng
Im Jahr 2007 beglückte NVIDIA die Welt mit CUDA. Damit konnte man mit Hilfe deren Grafikkarten prima parallel programmieren. Es gibt wohl kaum ein Problem, das sich so kinderleicht parallelisieren lässt wie „Code knacken“ aka „brute force“.
Mit der Zeit wurde für einen echten Streamhack (brute force auf DVB-CSA) das Licht am Horizont immer deutlicher wahrnehmbar.
Zur Orientierung:
Man kann 48 Bit DVB-CSA mit OpenCL auf einer mittleren Grafikkarte innerhalb von zweieinhalb Tagen komplett durchprobieren. Das geht völlig ohne irgendwelche vorberechneten Tabellen (rainbow tables) wie sie das Tool von Colibri verwendete.
Ok, das ist für ein sich alle sieben Sekunden änderndes CW noch zu lange. Man ahnt aber schon das Licht am Horizont.
Was passiert nun bei der Erweiterung auf echte 64 zu erratende Bits?
Pro zusätzlichem Bit verdoppelt sich der Aufwand. Aus 2,5 Tagen werden 5 und dann 10 und dann für 16 zusätzliche Bits 65.536 x 2,5 Tage, also 163.840 Tage bzw. knappe 449 Jahre. Das gilt für ein CW wohlgemerkt!
Ok, dann suchen wir uns doch ein anderes Hobby.
Die Moral von der Geschichte
Die Umstellung auf echte 64 Bit war dringend angesagt. Man kann niemandem ausschließlich boshafte Absichten unterstellen, der diesen Schritt geht. Der Kollateralschaden bei den alternativen Modulen wird sicherlich gerne mitgenommen. Das war aber ganz bestimmt nicht das eigentliche Ziel.
...und was tun die Organisationen die es gar nicht gibt heute so?
Die greifen den Pseudo-Zufall an, bzw. bringen Hersteller dazu eine gewisse Berechenbarkeit in den PRNG (Generator für Pseudo-Zufall) einzubauen. Das kann man nicht so einfach erkennen wie verkürzte Schlüssel. Ein prominentes Beispiel war der unterwanderte RSA SecureID Token, wenn man ihn mit den Standardeinstellungen verwendete.
PRNGs sind notwendig, da man nicht schnell genug echten Zufall aus vertrauenswürdigen Quellen generieren kann.
