20
DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport Stream (TS) Vollverschlüsselung, bei der nicht nur Teile wie Video und Audio, sondern alle PIDs (PAT, NIT, PMT, …) verschlüsselt werden, geknackt. Ein vollverschlüsselter TS wird über eine einzelne Data-PID über einen normalen TS getunnelt. 16.12.2011 (Version 1.00) aktuelle Version auf http://colibri.net63.net bzw. http://colibri-dvb.info Colibri <[email protected]> Einige Screenshots der geknackten Programme

DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport Stream (TS) Vollverschlüsselung, bei der nicht nur Teile wie Video und Audio, sondern alle PIDs (PAT, NIT, PMT, …) verschlüsselt werden, geknackt. Ein vollverschlüsselter TS wird über eine einzelne Data-PID über einen normalen TS getunnelt. 16.12.2011 (Version 1.00) aktuelle Version auf http://colibri.net63.net bzw. http://colibri-dvb.info Colibri <[email protected]>

Einige Screenshots der geknackten Programme

Page 2: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 2

Inhalt Einleitung ................................................................................................................................................. 2

Getunnelter TS ........................................................................................................................................ 3

Normaler ungetunnelter TS ................................................................................................................... 19

Performance .......................................................................................................................................... 20

Empfehlungen ....................................................................................................................................... 20

Literatur ................................................................................................................................................. 20

DVB TS Vollverschlüsselung geknackt

Einleitung Programme die mit einem festen Schlüssel dem Control Word (CW) verschlüsselt über Satelliten

übertragen werden, wurden ja bereits vor geraumer Zeit geknackt. Man macht sich hier zunutze,

dass der Schlüsselraum mit nur 248 verschiedenen Möglichkeiten zu klein ist, um mit der heutigen

gigantischen Rechenleistung von Grafikkarten mithalten zu können. Der Anfang (MPEG-Header) von

einem entschlüsselten Video und Audio Paket ist immer bekannt (Bytefolge „00 00 01“). So kann

einfach mit Brute-Force jeder mögliche Schlüssel ausprobiert werden. Der Anfang von solch einem

Paket, wird mit dem Payload Unit Start Indicator (PUSI)-Bit, im immer unverschlüsselten TS-Header,

signalisiert. Somit kann man, je nach Grafikkarte, das CW innerhalb von ein paar Wochen knacken.

Deshalb nutzen auch die meisten Anbieter nicht Constant CW oder Basic Interoperable Scrambling

System (BISS), sondern CA-Systeme wie z.B. Nagravision, Cryptoworks, CONAX oder Viaccess bei

denen alle paar Sekunden ein neues CW zum Verschlüsseln verwendet wird.

Im Gegensatz zur reinen Verschlüsselung von Video und Audio kommt seit Jahren auch die TS

Vollverschlüsselung zum Einsatz. Hier wird ein kompletter TS mit seinen vielen Programmen und den

ganzen Verwaltungsinfos PAT, NIT, SDT, EIT, PMT zu einer einzigen Data-PID gemultiplext. Diese

Data-PID wird dann mit BISS verschlüsselt.

Im Internet habe ich dazu folgendes gefunden:

Für Leute in Spanien, die DVB-T nicht empfangen können, gibt es einen Sat Receiver Televes 5110 um

diese Programme direkt über den Hispasat Satelliten (30°W) empfangen zu können. Einen solchen

Receiver kann man nicht einfach kaufen, sondern ein zugelassender Händler, der für Abertis Telecom

arbeitet, muss zuerst sicherstellen, dass wirklich kein DVB-T Empfang möglich ist. Erst dann werden

die Schüssel und der Receiver durch ihn eingerichtet.

Das Problem der Hacker war, dass sie nicht mehr wussten wo innerhalb der Data-PID, die den

gesamten TS enthält, die Video oder Audio Pakete anfangen. Ohne diesen Anhaltspunkt für den

Known-Plaintext scheitert auch der Brute-Force.

Hier wird erläutert wie es mir trotzdem gelungen ist das System zu knacken. Ein Highlight ist auch die

erstmals zum Einsatz gekommene Common-Scrambling-Algorithmus (CSA)-Rainbow Table. Nie zuvor

Page 3: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 3

wurden CWs mit einer CSA-Rainbow Table geknackt. Zwar dauert das einmalige Erstellen der Table

auch sehr lange, aber damit habe ich dann mehrere verschiedene CWs in Minuten geknackt.

Im nächsten Kapitel wird nur auf die Spanischen DVB-T Programme, die über den Hispasat Satelliten

(30°W) übertragen werden, eingegangen. Ich bin an Feedback interessiert ob es auch noch andere

Systeme gibt, die einen ganzen TS über eine einzelne Data-PID getunnelt übertragen.

Die gefundenen CWs sind hier nicht enthalten.

Getunnelter TS Zur Analyse habe ich mir so eine verschlüsselte PID, über die ein ganzer TS getunnelt wird, mal

aufgezeichnet. Die relevanten Frequenzen und PIDs habe ich weiter unten im Dokument aufgeführt.

Ich habe dann das Binary-File in HEX konvertiert und alle 188 Bytes, das ist die genormte Paketlänge,

einen Zeilenumbuch einfügen lassen. Im Spaltenmodus habe ich dann die den TS Paket Header (4

Bytes) entfernt. Anschliessend habe ich die Zeilen sortiert, um besser Muster erkennen zu können.

Byte 0 1 1 1 1 2 3 3 3

Bit 7..0 7 6 5 4..0 7..0 7..6 5..4 3..0

Sync byte 47h

Transport error indicator

Payload unit start indicator

Transport priority

PID Transport scrambling control

Adaptation field control

Continuity counter

Tabelle 1:TS Paket Header

Das Ergebnis war überraschend. Zwischen den meisten Zeilen, die wie erwartet nur ein einziges Mal

vorkamen, waren doch tatsächlich immer wieder Blöcke mit identischen Zeilen zu sehen.

Doch wie war das möglich? MPEG ist ein sehr effizientes Format und selbst wenn die da ein Standbild

übertragen, sind ähnlich wie in einem komprimierten File, keine sich wiederholenden Daten zu

erwarten.

Zwar gibt es neben Audio und Video auch noch andere Pakettypen wie z.B. PAT, CAT, NIT, SDT oder

PMT die mehr oder weniger statisch sind. Doch diese haben im Verhältnis zu den Video Paketen

einen viel zu geringen Anteil im TS und können die vielen Blöcke mit gleichem Inhalt eigentlich nicht

verursachen.

Also ging ich einen Schritt zurück und sah mir nicht nur eine verschlüsselte PID vom TS an, sondern

die Statistik vom gesamten TS.

Da waren PAT, CAT, NIT, TDT, EMMs, PMTs, einige verschlüsselte PIDs und PIDs mit der ID 0x1FFF.

Die PIDs mit der ID 0x1FFF sind Füllpakete die übertragen werden um von einer variablen Bitrate, die

z.B. durch die MPEG Video Pakete verursacht wird, auf die fixe Bitrate die ein Transponder hat zu

kommen.

In der Statistik war auch die Anzahl der Pakete pro PID zu sehen. Das war sehr aufschlussreich, denn

die Counter waren für alle verschlüsselten PIDs identisch. Das bedeutet die verschüsselten PIDs

hatten bereits eine fixe Bitrate und sie mussten somit auch Füllpakete enthalten. Das heisst die

vielen identischen Zeilen im Textfile waren verschlüsselte Füllpakete und das war entscheident für

den Hack. Denn der Inhalt der Füllpakete ist in der Regel statisch, manchmal eine aufsteigende

Page 4: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 4

Bytefolge aber meist einfach lauter Nullbytes. Bei bekannten Plaintext des Füllpakets ist es möglich

einmalig eine Rainbow Table für diesen Plaintext zu erzeugen. Anschliessend kann man innerhalb von

Minuten an Hand des verschlüsselten Füllblocks, der an den vielen identischen verschlüsselten

Paketen erkennbar ist, sich das CW mit der Rainbow Table berechnen lassen.

Aber warum gibt es nicht nur einen einzigen Zeileninhalt (das verschlüsselte Füllpaket) der öfters

vorkommt, sondern 47 Zeileninhalte die mehrmals vorhanden sind?

Das hängt mit dem Multiplexen (Tunneln) eines TS über eine einzige PID zusammen. Ein TS Paket, mit

seinen 188 Bytes, besteht immer aus 4 Header Bytes + 184 Bytes Payload.

Als Payload der verschlüsselten PID stehen aber nur 184 Bytes zur Verfügung um den TS

aufzunehmen, aber nicht die nötigen 188 Bytes. Die letzten 4 übrigen Bytes des ersten Pakets

wandern an den Anfang es zweiten Pakets und die dann übrigen 8 Bytes des zweiten Pakets kommen

an den Anfang des dritten Pakets.

OuterPkt1 Header InnerPkt1 Header 4 Byte InnerPkt1 Payload 180 Byte

OuterPkt2 Header InnerPkt1 Payload 4 Byte InnerPkt2 Header 4 Byte InnerPkt2 Payload 176 Byte

OuterPkt3 Header InnerPkt2 Payload 8 Byte InnerPkt3 Header 4 Byte InnerPkt3 Payload 172 Byte

OuterPkt4 Header InnerPkt3 Payload 12 Byte

InnerPkt4 Header 4 Byte InnerPkt4 Payload 168 Byte

OuterPkt44 Header InnerPkt43 Payload 172 Byte

InnerPkt44 Header 4 Byte

InnerPkt44 Payload 8 Byte

OuterPkt45 Header InnerPkt44 Payload 176 Byte

InnerPkt45 Header 4 Byte

InnerPkt45 Payload 4 Byte

OuterPkt46 Header InnerPkt45 Payload 180 Byte

InnerPkt46 Header 4 Byte

OuterPkt47 Header InnerPkt46 Payload 184 Byte

Um 46 Paketen zu tunneln benötigt man also 47 Pakete.

Entschlüsselt sehen die 47 verschiedenen Füllpakete wie folgt aus:

47 1F FF 10 00 00 00 00 <168 weitere Bytes> 00 00 00 00 00 00 00 00

00 00 00 00 47 1F FF 10 <168 weitere Bytes> 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 <168 weitere Bytes> 47 1F FF 10 00 00 00 00

00 00 00 00 00 00 00 00 <168 weitere Bytes> 00 00 00 00 47 1F FF 10

00 00 00 00 00 00 00 00 <168 weitere Bytes> 00 00 00 00 00 00 00 00

Basierend auf welchen bekannten Plaintext man die Rainbow Table aufbaut kann man sich

aussuchen. Ich habe für meine Experimente den letzen mit 184 Nullbytes genommen. Das hat den

Vorteil, dass man von Headeränderungen unabhängig ist. Header für die Füllpakete gibt’s nämlich in

zwei Varianten einmal statisch 47 1F FF 10 und einmal mit hochzählenden continuity counter 47 1F

FF 10, 47 1F FF 11, 47 1F FF 12, …, 47 1F FF 1F. Beim hochzählenden continuity counter ergeben sich

Page 5: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 5

dann mehr als die 47 Varianten, jedoch kommt dann eine Variante sehr viel häufiger vor. Das ist dann

Die mit den verschlüsselten 184 Nullbytes.

Doch welches, der etwa gleichhäufigen vorkommenden verschlüsselten Pakete, nimmt man bei

einem feststehen continuity counter um mit der Rainbow Table das CW zu berechnen?

Man könnte es natürlich mit allen 47 verschiedenen Paketen probieren, was aber die Zeit zum

Berechnen des CWs um diesen Faktor verlängert.

Zur Lösung dieses Problems müssen wir uns mit dem Adaptation Field (AF) befassen.

Im TS Header gibt es ein zwei Bit langes „Adaptation field control“ das angibt ob vor der eigentlichen

Payload noch ein AF vorhanden ist. Die Bits haben folgende Bedeutung:

00 Reserviert

01 Kein AF, nur Payload

10 Nur AF, keine Payload

11 AF und Payload vorhanden

Sehen wir uns mal ein Beispielpaket mit AF und Payload an:

47 08 37 F2

13 12 5F 2D 60 2E 81 00 0B B5 80 96 B0 F8 52 00 00 00 00 00

AF 61 50 13 <156 weitere Bytes> 10 05 32 06

Die erste Zeile ist der TS Header. Im Hi-Nibble (F) des letzen Byte sind alle Bits gesetzt (1111). Die

ersten beiden Bits gehören zum Transport scrambling control Feld und 11 bedeutet dass die Payload

mit dem Odd-CW verschlüsselt ist (10 wäre Even-CW, 00 wäre unverschlüsselt und 01 ist reserviert).

Die letzten zwei 11 Bits bedeuten das AF und Payload vorhanden sind.

In der zweiten Zeile ist das AF zu sehen. Das erste Byte (13h) gibt die Länge des restlichen AF Feldes

an. Insgesamt (1 Längenbyte + 13h Folgende) ist es 14h = 20 Bytes lang.

In der dritten Zeile ist die verschlüsselte Payload abgebildet. Zieht man von den 184 zur Verfügung

stehenden Bytes die die Länge des AF mit seinen 20 Bytes ab, dann bleiben 164 Bytes für die Payload

übrig.

Ein AF wird immer unverschlüsselt übertragen. Es kann z.B. Zeitstempel (PCR) und Provider

spezifische Daten enthalten. Der Inhalt ist für den Hack nicht relevant. Aber dass es ab und zu

vorhanden ist und bei diesem Provider immer eine Länge von 20 Bytes hat ist entscheidend. Es

bewirkt somit, dass die verschlüsselte Payload nicht mehr ein Vielfaches von 8 ist.

Ohne AF hat die Payload immer 184 Bytes bestehend aus 23 Blöcken zu je 8 Bytes.

Mit 20 Byte AF hat die Payload immer 164 Bytes bestehend aus 20 Blöcken zu je 8 Bytes und einen

Rest von 4 Bytes.

Doch warum hilft es uns, wenn die Payload Länge nicht ein Vielfaches von 8 ist, bei unserem Hack?

Page 6: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 6

Dazu müssen wir und genauer ansehen wie die Payload mit dem Common-Scrambling-Algorithmus

(CSA) verschlüsselt wird.

Für die Verschlüsselung wird der Plaintext von vorne nach hinten in 8 Blöcke aufgeteilt und der Rest

(Plain Residue) erst mal beiseitegelassen.

Der letzte 8 Byte Block wird mit dem IV, der beim DVB-CSA immer Null ist, XOR verknüpft und dann

mit dem Block cipher mit dem CW verschlüsselt. Das Ergebnis ist ein Intermediate Block (IB). Er wird

mit dem vorletzen Plaintext XOR verknüpft und dann wieder mit dem Block cipher mit dem CW

verschlüsselt. Das Ergebnis ist dann der vorletzte Intermediate Block. Hat man dann alle IBs

berechnet, dann wird der Stream cipher mit dem CW und mit dem Inhalt des ersten IBs initialisiert.

Der erste IB ist gleichzeitig auch der erste verschlüsselte Block. Die restlichen IBs werden mit dem

Output des Stream ciphers XOR verknüpft und ergeben die restlichen verschlüsselten jeweils 8 Byte

langen Blöcke. Jetzt kommt der erst mal beiseitegelassener Plain Residue zum Einsatz. Er wird mit

dem Output des Stream cipher XOR verknüpft und ergibt den verschlüsselten Rest.

CB: Cipher Block SB: Stream Cipher Block CR: Crypt Residue IB: Intermediate Block CW: Control Word (Key) PR: Plain Residue PB: Plain Block IV: Initialization Vector

Abbildung 1: CSA Verschlüsselung

Header CB0 CB1

CB2

CB3 … CBn-1

CR

IB0

IB1

IB2

IB3

… IBn-1

PB0

111101

PB1

PB2

… PBn-2

PBn-1

PR

SB1

SB2

SB3

SBn-1

SB0

Stream

cipher

init

Block

cipher

encr.

CW

Block

cipher

encr.

CW

Block

cipher

encr.

CW

Block

cipher

encr.

CW

Block

cipher

encr.

CW

IV

CW

Page 7: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 7

Bei der Entschlüsselung funktioniert es dann umgekehrt, wie aus folgendem Bild zu entnehmen ist:

Das Besondere bei der Verschlüsselung von unseren letzten 4 Bytes der Payload ist also, dass sie gar

nicht von dem Block cipher, sondern nur von dem Stream cipher verschlüsselt wird.

Aber warum hilft uns das, die Eine der 47 Varianten zu ermitteln, die nur aus verschlüsselten Nullen

besteht? Das CW ist uns ja noch nicht bekannt und wir können doch somit eigentlich nicht wissen wie

die 4, nur mit dem Stream cipher verschlüsselten Bytes, entschlüsselt aussehen.

Wenn wir allerdings wüssten, dass die entschlüsselten Bytes den Wert 47 1F FF 10 haben, dann wäre

unser Problem gelöst, da dieser Header mit der PID 1FFF das Füllpaket mit seinen 184 Nullbytes

einleitet. Wir könnten also mit der Payload des folgenden Pakets und der Rainbow Table das CW

berechnen.

Verschlüsselt man zwei Pakete mit dem CSA, bei dem innerhalb der ersten 180 Bytes nur ein einziges

Bit unterschiedlich ist, dann unterscheiden sich die verschlüsselten Pakete total. Selbst die letzten 4

Bytes wären total unterschiedlich, weil der erste Intermediate Block, der zum Initialisieren des

Stream ciphers verwendet wird, anders wäre und somit auch der Keystream der die letzten 4

verschlüsselten Bytes.

Anders ist es allerdings, wenn eine Änderung nicht in den ersten 180 Bytes, sondern nur in den letzen

4 Bytes stattfindet. Dann sind die ersten 180 verschlüsselten Bytes identisch und nur die restlichen 4

Bytes sind unterschiedlich. Unterscheidet sich der Plaintext der letzten 4 Bytes nur in einem einzigen

Bit, dann unterscheiden sich auch die beiden verschlüsselten 4 Bytes nur an genau dieser Bitposition

und der Rest ist identisch.

Sehen wir uns mal die letzten Beiden der 47 Varianten (ohne AF) von oben an:

CB: Cipher Block SB: Stream Cipher Block CR: Crypt Residue IB: Intermediate Block CW: Control Word (Key) PR: Plain Residue PB: Plain Block IV: Initialization Vector

Abbildung 2: CSA Entschlüsselung

Header CB0 CB1

CB2

CB3 … CBn-1

CR

IB0

IB1

IB2

IB3

… IBn-1

PB0

111101

PB1

PB2

… PBn-2

PBn-1

PR

SB1

SB2

SB3

SBn-1

SB0

Stream

cipher

init

Block

cipher

decr.

CW

Block

cipher

decr.

CW

Block

cipher

decr.

CW

Block

cipher

decr.

CW

Block

cipher

decr.

CW

IV

CW

Page 8: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 8

00 00 00 00 00 00 00 00 <168 weitere Bytes> 00 00 00 00 47 1F FF 10

00 00 00 00 00 00 00 00 <168 weitere Bytes> 00 00 00 00 00 00 00 00

Auch in den Paketen mit AF wird es folgende um 20 Byte kürzere Payload geben.

00 00 00 00 00 00 00 00 <148 weitere Bytes> 00 00 00 00 47 1F FF 10

00 00 00 00 00 00 00 00 <148 weitere Bytes> 00 00 00 00 00 00 00 00

Auch verschlüsselt sind diese beiden Payloads zu erkennen. Dazu filtert man aus dem TS nur die

Pakete die ein AF haben, schreibt dann nur die Payload jeweils ein eine Zeile und sortiert das Textfile

anschliessend. Jetzt wird man verschlüsselte Blöcke finden, die zwar innerhalb der ersten 160 Bytes

identisch sind, sich aber innerhalb der letzen 4 Bytes unterscheiden.

Da die ersten 160 Bytes identisch sind, ist auch der Keystream des Stream ciphers identisch.

Beim Stream cipher gilt:

Plain XOR Key = Crypt

Crypt XOR Key = Plain

Plain1 XOR Plain2 XOR Key1 XOR Key2 = Crypt1 XOR Crypt2

Da Key1 und Key2 identisch sind, kann man sie wegkürzen:

Plain1 XOR Plain2 = Crypt1 XOR Crypt2

Jetzt setzt man die Werte ein:

47 1F FF 10 XOR 00 00 00 00 = Crypt1 XOR Crypt2

47 1F FF 10 = Crypt1 XOR Crypt2

Folgender Mitschnitt der zeigt wie vier Payloads enden:

128 mal: … 66 8B 84 01 ED A4 49 C2 1A 51 7F 94 (= 00 00 00 00)

8 mal: … 66 8B 84 01 ED A4 49 C2 5D 4E 80 84 (= 47 1F FF 10)

2 mal: … 66 8B 84 01 ED A4 49 C2 5D 54 A2 84 (= 47 05 DD 10)

3 mal: … 66 8B 84 01 ED A4 49 C2 5D 54 A2 8B (= 47 05 DD 1F)

Bis auf die letzten 4 Bytes ist der vordere Payloadteil identisch.

1A 51 7F 94 (Crypt1) XOR 5D 4E 80 84 (Crypt2) = 47 1F FF 10 (Plain1

XOR Plain2)

Also entweder entspricht 1A 51 7F 94 dem Plaintext 00 00 00 00 und 5D 4E 80 84 entspricht 47 1F FF

10 oder 1A 51 7F 94 entspricht dem Plaintext 47 1F FF 10 und 5D 4E 80 84 entspricht dem Plaintext

00 00 00 00.

Nur wenn man in diesem Fall für 1A 51 7F 94 den Plaintext 00 00 00 00 annimmt ergeben sich für die

restlichen zwei Zeilen sinnvolle Werte (fangen mit Sync-Byte = 47h an). Wenn man nur zwei Zeilen

hat, kann man davon ausgehen das die Zeile die Häufiger vorkommt dem Plaintext 00 00 00 00

Page 9: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 9

entspricht. Kommen beide Zeilen etwa gleich häufig vor, muss man halt den Knackversuch zweimal

durchführen, aber das ist immer noch besser als es mit allen 47 Varianten zu tun.

Man sucht jetzt das dem Plaintext … 47 1F FF 10 entsprechendes Paket mit der Bytefolge … 66 8B 84

01 ED A4 49 C2 5D 4E 80 84 im original TS der auf die verschlüsselte PID gefiltert wurde, überspringt

dann die nächsten 4 Header Bytes und hat eine 184 Byte lange verschlüsselte Nullbytefolge vor sich

mit der man sich aus der Rainbow Table das CW berechnen lassen kann.

Doch es gibt nicht nur die Variante bei der der Header genau 4 Byte vor Ende der Payload beginnt:

00 00 00 00 00 00 00 00 <148 weitere Bytes> 00 00 00 00 47 1F FF 10

Es gibt noch folgende drei weitere Varianten:

00 00 00 00 00 00 00 00 <148 weitere Bytes> 00 00 00 00 00 47 1F FF

00 00 00 00 00 00 00 00 <148 weitere Bytes> 00 00 00 00 00 00 47 1F

00 00 00 00 00 00 00 00 <148 weitere Bytes> 00 00 00 00 00 00 00 47

Der Multiplexer, der mit dem TS gefüttert wird und dann eine verschlüsselte PID erzeugt,

synchronisiert nämlich nicht die Header so dass sie 4 Byte aligned sind. Das ist für eine einwandfreie

Funktion auch nicht nötig. Ich habe mal so eine Aktuelle mit einer älteren Aufzeichnung verglichen

und da waren die Sync Bytes an unterschiedlichen stellen. Eine zeitgleiche Aufzeichnung von einem

anderen Transponder zeigte, dass sich hier die Position des Sync Bytes nicht verändert hatte.

Vielleicht ändert sich die Position des Sync Bytes immer dann, wenn der Multiplexer mal bootet oder

mal kurz der Kontakt zur Quelle, die den Multiplexer speist, abbricht.

Ich hatte sogar noch eine Aufzeichnung vor einem Jahr. Damals hatten die zusätzlich noch auf 9° Ost

gesendet. Die verwendeten CWs sind jetzt immer noch identisch auf 30° West im Einsatz. Vermutlich

hatten die die CWs noch nie geändert. Allerdings kommt nicht nur ein einziges CW für die

verschlüsselten PIDs zum Einsatz. Ist in der folgenden Tabelle die CW Nr. bei zwei verschiedenen PIDs

gleich, dann wurden sie auch mit einem identischen CW verschlüsselt:

Freq. PID (hex.)

Prg. Nr.

CW Nr.

TV , Radio oder Data\ Provider\ Programm

TSID Org. NetID

11222H SR:30000ks

(08.12.2011)

7DA 3010 8

7E4 3020 8

7E5 3021 8

7E6 3022 8

7E7 2023 8

7E8 3024 8

11262H SR:30000ks

(08.12.2011)

848 3120 4 TV\RTVE\La 2

TV\RTVE\24h

TV\RTVE\Clan

041A 22D4

849 3121 4 TV\RTVE\La 1 R\RNE\Radio Nacional R\RNE\Radio 5 Todo Noticias

0455 22D4

84A 3122 4 TV\RTVE\La 1 R\RNE\Radio Nacional

03F3 22D4

Page 10: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 10

R\RNE\Radio 5 Todo Noticias

84B 3123 4 TV\RTVE\La 1 R\RNE\Radio Nacional R\RNE\Radio 5 Todo Noticias

03F5 22D4

84C 3124 4 TV\RTVE\La 1 R\RNE\Radio Nacional R\RNE\Radio 5 Todo Noticias

03F6 22D4

84D 3125 10

84E 3126 4 TV\RTVE\La 1 R\RNE\Radio Nacional R\RNE\Radio 5 Todo Noticias

044D 22D4

84F 3127 10

11302H SR:30000ks

(08.12.2011)

89D 3205 9

89E 3206 9

89F 3207 9

8A0 3208 9

8A2 3210 9

8AC 3220 9

8AD 3221 9

8AE 3222 9

8AF 3223 9

11653H SR:19680ks

(08.12.2011)

12D 1301 5

12F 1303 5

11677H SR:19684ks

(08.12.2011)

191 1401 5

192 1402 5

12523V SR:10400ks

(08.12.2011)

582 2410 7

12548V SR:29600ks

(08.12.2011)

2BD 1701 2 TV\La Sexta\laSexta2

TV\La Sexta\laSexta3

TV\La Sexta\laSexta HD TV\SOGECABLE\CANAL+ Dos R\SOGECABLE\SER R\SOGECABLE\40 PRINCIPALES R\SOGECABLE\CADENA DIAL TV\TELECINCO\CUATRO

000E 22D4

2BE 1702 2 TV\Tele5\Boing

TV\Tele5\Telecinco HD

TV\TELSON\MTV

TV\La 10\La 10 R\La 10\ABC Punto Radio

000F 22D4

2BF 1703 2 TV\ANTENA3 TELEVISION\NITRO TV\ANTENA3 TELEVISION\Antena3 HD

R\ANTENA3 TELEVISION\ONDA CERO R\ANTENA3 TELEVISION\EUROPA FM R\ANTENA3 TELEVISION\ONDA

0010 22D4

Page 11: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 11

MELODIA TV\MARCA TV\MARCA TV

TV\VEOTV\13 TV

TV\VEOTV\MundoInteractivo R\COPE\COPE R\Radio Maria\Radio Maria

12631V SR:30000ks

(08.12.2011)

1F41 1001 11

1F42 1002 3 TV\RTVE\TVE-HD Pruebas

TV\RTVE\TDP R\RNE\Radio Clasica HQ R\RNE\Radio 3 Data\RTVE\Canal Ingenieria

9C40 22D4

1F43 1003 12 TV\La Sexta\laSexta TV\La Sexta\GOL TELEVISION

TV\La Sexta\laSexta3 TV\TELECINCO\CUATRO

TV\TELECINCO\DIVINITY

TV\TELECINCO\LA TIENDA EN CASA

0002 22D4

12671V SR:30000ks

(08.12.2011)

1F44 1004 13

1F45 1005 14

1F46 1006 12 TV\RTVE\La 1

TV\RTVE\La 2

TV\RTVE\24h

TV\RTVE\Clan R\RNE\ Radio Nacional R\RNE\ Radio 5 Todo Noticias

03F0 22D4

Tabelle 2: Sendetabelle

Normalerweise bräuchte man für die 4 möglichen Sync Byte Positionen auch 4 Rainbow Tables, die

auf 4 verschiedenen Klartexten basieren, um alle PIDs knacken zu können. Die Sync Byte Positionen

der verschiedenen PIDs sind ja kunterbunt gemischt.

Da aber mehrere PIDs, die unterschiedliche Sync Byte Positionen haben, mit dem gleichen CW

verschlüsselt wurden, genügt es dass eine einzige Sync Byte Position mit der eigenen Rainbow Table

übereinstimmt. Hat man das CW dann berechnet, kann man mit dem CW auch die anderen PIDs

entschlüsseln. Ist die eigene Sync Byte Position nicht dabei und will man keine weiteren Rainbow

Tables erstellen, dann kann man ja in ein paar Wochen mal wieder nachsehen ob sich die Sync Byte

Positionen geändert haben.

Ich habe mir für diesen Hack nur eine vollständige Rainbow Table für eine einzige Sync Byte

Positionen, die die 184 Nullbytes knacken kann, erstellt. Darum hat die obige Tabelle auch noch

einige Lücken. Ist kein Programname angegeben ist auch das CW noch nicht bekannt.

Wenn in dem Paket mit dem AF die letzten 4 verschlüsselten Bytes, die den Wert 00 00 00 00

repräsentieren, bei verschiedenen PIDs identisch war, dann habe ich in der Tabelle die gleiche CW

Nr. vergeben. Somit weiss man auch bei den noch nicht gefundenen CWs wie viele es noch sind.

Page 12: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 12

Eine Unsitte die ich bei neueren Aufzeichnungen feststellen konnte ist, dass die Füllpakete jetzt bei

einigen Transpondern dynamische Zusatzdaten enthalten und somit leider nicht mehr für Rainbow

Tables geeignet sind.

Die ersten 8 Byte des Füllpakets enthalten dann Zusatzdaten, die Restlichen sind Null.

Das erste Byte ist anscheinend immer 01h wenn Zusatzdaten vorhanden sind.

Das zweite Byte ist 00h.

Das dritte und das vierte Byte ist ein zwei Byte Counter der um eins hochzählt wenn der Multiplexer

ein Füllpaket oder auch ein Nutzpaket entgegen nimmt. So kann man leicht erkennen ob es einen

Paketverlust auf der Übertragungsstrecke gab und sogar ob es nur ein Paket war oder gleich 20.

Das fünfte und sechste Byte ist statisch.

Das siebte und achte Byte ist die TSID.

Eine Sicherheitsmassnahme ist das Ganze anscheinend nicht. Es wird ja nur teilweise verwendet.

Auch ist der 16 Bit Counter viel zu klein für eine Sicherheismassnahme. Alle 65536 Pakete wäre das

Füllpaket wieder identisch und kann somit für das Erstellen einer Rainbow Table verwendet werden.

Das brachte mich auf die Idee, als Plaintext zum Erstellen der Rainbow Table nicht den Inhalt der

Füllpakete heranzuziehen. Ein positiver Nebeneffekt ist auch, dass man sich nicht mehr mit der Sync

Byte Position herumschlagen muss, sondern nur Eine und nicht gleich vier Rainbow Tables benötigt.

Doch welche statische Daten gibt es noch im TS?

Es gibt Tabellen wie z.B. PAT, CAT, NIT, TDT oder PMT die regelmässig ausgestrahlt werden. Die

Tabellen benutzen oft nicht die ganze Payload. Der Rest der Payload wird immer mit 0xFF Bytes

aufgefüllt. Die Time and Date Table (TDT) z.B. enthält ja nur das Datum und Zeit. Das macht ja nur ein

paar Bytes aus. Selbst bei in der Regel grossen Paketen wie einer Network Information Table (NIT) die

sich über mehrere Pakete erstrecken kann, ist es doch möglich das sie zwei komplette Pakete

benötigt und vom dritten Paket nur ein paar Bytes. Dann sind auch im dritten Paket jede Menge 0xFF

Bytes. Selbst in der Video PID gibt’s immer wieder Pakete die nur ein AF aber keine Payload haben.

Im AF ist dann nur die Program Clock Reference (PCR) enthalten, der ganze Rest ist mit 0xFF Bytes

aufgefüllt.

Als Plaintext jetzt einfach 184 * FFh (statt 184 * 00h) herzunehmen wird aber nicht zum Erfolg

führen. So viele FFh Bytes am Stück werden wir nicht finden, da sie ja nur zum Auffüllen verwendet

werden. Der Trick ist bei der verschlüsselten PID nicht die Pakete zu verwenden die nur eine Payload

von 184 Bytes haben, sondern nur die Pakete mit AF und Payload. Da das AF bei diesem Provider

immer 20 Bytes hat, hat die Payload nur noch 164 Bytes. Da wir für das Erzeugen der Rainbow Table

nur den Block cipher verwenden und nicht den Stream cipher, fallen auch noch die letzten 4 Byte

weg. Wir benötigen also jetzt nur noch 160 Bytes mit dem Wert FFh und das ist jetzt kein Problem

mehr.

Doch wie erkennt man verschlüsselte FFh Bytes?

Page 13: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 13

Filtern wir einfach mal aus den TS nur die Pakete die neben der Payload auch ein AF (mit 20 Bytes)

haben. Die Payload mit den 164 Bytes lassen wir in eine Textdatei schreiben. Dann sortieren wir die

Textdatei, damit die Pakete mit den gleichen Anfang haben beieinander sind. Wir interessieren uns

nur für die Zeilen bei denen jeweils die ersten 160 Bytes identisch sind. Hier ein Beispiel aus der

Praxis:

17 mal … 91 B8 04 49 71 8D 04 51 F4 7D 87 8E (= …00 00 00 00 47 1F)

18 mal … 91 B8 04 49 71 8D 04 51 F4 7D 87 91 (= …00 00 00 00 47 00)

4 mal … 91 B8 04 49 71 8D 04 51 F4 7D 87 92 (= …00 00 00 00 47 03)

7 mal … 91 B8 04 49 71 8D 04 51 F4 7D 87 94 (= …00 00 00 00 47 05)

201 mal … 91 B8 04 49 71 8D 04 51 F4 7D C0 91 (= …00 00 00 00 00 00)

13 mal … 27 AD F5 03 5B 04 F1 23 2C B5 37 09 (= …FF FF FF FF FF FF)

2 mal … 27 AD F5 03 5B 04 F1 23 2C B5 8F F6 (= …FF FF FF FF 47 00)

Es wurden zwei verschiedene Blöcke gefunden die öfters vorkommen und innerhalb der ersten 160

Bytes jeweils identisch sind.

Wir schauen uns jetzt vom ersten Block jeweils die letzen 4 Bytes, die nur mit den Stream cipher

verschlüsselt worden sind, an.

Jeweils das erste (F4h) der vier letzen Bytes ist identisch und deshalb überspringen wir es.

Jeweils das zweite Byte (7Dh) ist auch identisch und wir überspringen es wieder.

Das dritte Byte ist öffters 87h, aber nur einmal C0h. Einer dieser Werte sollte entschlüsselt das Sync

Byte 47h sein.

Doch Welchen Wert hat das andere Plainbyte?

Wir kennen die Vorgehensweise ja schon von weiter oben.

Crypt1 XOR Crypt2 = Plain1 XOR Plain2

Aber auch:

Crypt1 XOR Crypt2 XOR Plain1 = Plain2

87h XOR C0h XOR 47h = 00h

Das C0h entspricht entschlüsselt anscheinend 00h, weil es mit 201 mal öfters vorkommt.

Also der erste Block ist anscheinend mit seinen Nullen nicht der gesuchte Block, denn wir suchen ja

nach FFh Bytes.

Wenden wir und also den zweiten verbleibenden Block zu.

Auch hier ist der erste Unterschied im dritten der letzten vier Bytes auszumachen.

37h XOR 8F XOR 47h = FFh

Das sieht jetzt besser aus. Die letzen 4 Byte brauchen wird zum Berechnen des CW mit der Rainbow

Table nicht. Die ersten 160 Bytes (… 04 F1 23) reichen. Sie entsprechen 160 mal dem Byte FFh.

Page 14: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 14

Aus Zeitgründen habe ich nicht eine vollständige Rainbow Table erzeugt mit 160 mal FFh, sondern

nur so viel, dass ich eines der noch unbekannten CW berechnen konnte. Mir gings hier nur ums

Prinzip, ob das auch in der Praxis so funktioniert.

Wir haben also bis jetzt gesehen welchen Plaintexte man für das Erzeugen seiner Rainbow Table

verwenden kann und welche Vor- und Nachteile die verschiedenen Plaintexte haben. Auch wissen

wir wie wir zu dem passenen Ciphertext kommen um mit der Rainbow Table das CW berechnen zu

können.

Doch wie erzeugen wir die Rainbow Table und wie genau berechnen wir mit ihr später das CW?

Zuerst sollte man sich [1] duchlesen um das Prinzip der Rainbow Tables zu verstehen.

Das CW hat zwar eine Länge von 8 Bytes und somit wären 264 verschiedene Schlüssel möglich, aber

die Anzahl der verschiedenen Schlüssel wird bei allen Receivern immer künstlich auf 248 begrenzt.

Vermutlich haben sich die die 216 in Reserve gehalten um im Falle eines Knacken des Systems (z.B.

über Rainbow Tables) es sofort durch nutzen der vollen 264 Schlüssel über ein Firmware update

wieder sicher zu machen. Dann bleibt hoffentlich noch genug Zeit sich einen Nachfolger für den CSA-

Algo zu überlegen der eine höhere Schlüssellänge unterstützt (z.B. AES). Es müssen dann natürlich

neue Receiver produziert werden die beide Varianten (z.B. CSA und AES) unterstützen. Wenn die

Endkunden dann die neuen Receiver haben, könnten die schlagartig auf neue Verschlüsselung

umstellen, bevor auch die 264 Schlüssel sich mit Rainbow Tables in der Praxis knacken lassen.

Innerhalb der Rainbow Table kann man also derzeit noch mit 6 Bytes für den Schlüssel arbeiten.

Diesen Schlüssel kann man dann für Verschlüsselungen mit CSA wie folgt von 6 auf 8 Bytes erweitern:

Cw8[0] = Cw6[0];

Cw8[1] = Cw6[1];

Cw8[2] = Cw6[2];

Cw8[3] = Cw6[0] + Cw6[1] + Cw6[2];

Cw8[4] = Cw6[3];

Cw8[5] = Cw6[4];

Cw8[6] = Cw6[5];

Cw8[7] = Cw6[3] + Cw6[4] + Cw6[4];

Die Grösse der Rainbow Table kann man ja über die Kettenlänge selbt beeinflussen. Je grösser die Rainbow Table ist, desto schneller kann später ein CW gefunden werden, aber desto mehr Plattenplatz wird dann auch benötigt. Ich habe mich für 10000h (216) als Kettenlänge entschieden. Die Rainbow Table muss somit nur noch

die verbleibenden 248-16 = 232 Paare aus Start- und Endwert enthalten und kann dennoch das CW

relativ schnell berechnen.

Der Startwert und der Endwert stellen das CW dar, benötigen also jeweils 6 Bytes innerhalb der

Rainbow Table.

Die Grösse der Rainbow Table berechnet sich wie folgt:

(6+6) * 232 = 48 GByte

Page 15: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 15

Die Rahmenparameter sind gesteckt und man kann mit dem Erzeugen anfangen.

Man wählt ein 6 Byte CW als Startwert. Vom Ersten bis zum letzen Startwert wird immer um eins

hochgezählt. Wählt man 0 als Startwert dann ergibt sich folgender Bereich:

00 00 00 00 00 00 … 00 00 FF FF FF FF

Dieser Startwert ist aber sehr ungünstig. Jemand anders aus der Community könnte auch bei 0

Anfangen und die resultierenden 48 GByte wären absolut identisch. So eine Rainbow Table deckt

keinesfalls 100% ab, sondern beim CSA wie ich glaube etwa 66%. Wärend der Verkettung der jeweils

10000h Elemente muss nämlich ständig die Entropie von 264 (Crypt Block) auf 248 (CW Länge)

reduziert werden. Dadurch mergen unweigerlich jede Menge der Ketten und ergeben den gleichen

Endwert. Ziel ist es deshalb gleich mehrere verschiedene Rainbow Tables zu mit unterschiedlichen

Startwerten zu haben, damit man möglichst nahe an der 100%igen Abdeckung ist. Die ersten beiden

Bytes des Startwerts sollten absolut zufällig sein, die restlichen 4 Bytes sollten 0 haben. Z.B.:

C3 E9 00 00 00 00 … C3 E9 FF FF FF FF

Um den Endwert aus dem Startwert zu berechnen kann man in etwa wie folgt vorgehen:

for(RoundNr=0; RoundNr<0x10000; RoundNr++)

{

//Verschlüsseln

//input 8 Byte: Cw

//output 8 Byte: data

//inside the fctn: 184 or 160 Byte fixed plaintext

BlockCipherEncryptPlain(Cw, data);

//Reduzierung der Daten von 8 Bytes auf 6 Bytes

//in dem data[6] und data[7] nicht verwendet werden

//XOR-Verknüpfen der RoundNr mit den Daten

data[2] ^= ((RoundNr >> 24) & 0xFF);

data[3] ^= ((RoundNr >> 16) & 0xFF);

data[4] ^= ((RoundNr >> 8) & 0xFF);

data[5] ^= (RoundNr & 0xFF);

//6 Byte Daten in 8 Byte CW konvertieren

Cw[0] = data[0];

Cw[1] = data[1];

Cw[2] = data[2];

Cw[3] = data[0] + data[1] + data[2];

Cw[4] = data[3];

Cw[5] = data[4];

Cw[6] = data[5];

Cw[7] = data[3] + data[4] + data[5];

}

memcpy(Endwert, data, 6);//die ersten 6 Bytes als Endwert übernehmen

Page 16: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 16

Hier als Beispiel ein paar Zwischenergebnisse während der Berechnung der Kette für den Plaintext

184 * 00h. Abgespeichert wird später nur der Start- und Endwert. Man kann damit die eigene

Implementation überprüfen (aber anschliessend den Startwert ändern!):

Cw6: 00 00 00 00 00 00 <= Startwert

Crypt: BF 8A 91 00 77 6F 7D A5

XOR RoundNr: 0h

Cw6: BF 8A 91 00 77 6F

Crypt: 1A 83 E3 00 58 84 B0 C6

XOR RoundNr: 1h

Cw6: 1A 83 E3 00 58 85

Crypt: 76 93 55 40 35 8B 2E AE

XOR RoundNr: 2h

Cw6: 76 93 55 40 35 89

Crypt: FC 8D 87 4C CF 75 9D 62

XOR RoundNr: 3h

Cw6: FC 8D 87 4C CF 76

Cw6: 86 48 D2 8E 21 BF

Crypt: DA C4 02 09 51 9E C0 DB

XOR RoundNr: FFFCh

Cw6: DA C4 02 09 AE 62

Crypt: 54 05 79 9D 95 F0 0E A9

XOR RoundNr: FFFDh

Cw6: 54 05 79 9D 6A 0D

Crypt: AA 28 CA FD B7 5D 50 9E

XOR RoundNr: FFFEh

Cw6: AA 28 CA FD 48 A3

Crypt: 3A 39 2A E6 42 61 D9 4B

XOR RoundNr: FFFFh

Cw6: 3A 39 2A E6 BD 9E <= Endwert

Der Anfang und das Ende meiner 48 GByte Rainbow Table für den Plaintext 184 * 00h. Man sieht den

6 Byte langen Startwert und dann den 6 Byte langen Endwert.

00 00 00 00 00 00 3A 39 2A E6 BD 9E

00 00 00 00 00 01 E4 63 9C 23 DE 8C

00 00 00 00 00 02 BE 2F FF 98 7F 10

00 00 00 00 00 03 29 E3 9D 3B AD 99

00 00 00 00 00 04 A2 AA AA D0 C6 C6

00 00 00 00 00 05 A6 EE 31 57 49 E0

00 00 00 00 00 06 55 93 42 66 48 DC

00 00 00 00 00 07 67 59 5C D2 79 82

00 00 00 00 00 08 B1 78 C9 8F 49 30

00 00 00 00 00 09 47 A8 37 2B 13 0B

00 00 FF FF FF F6 7F 3E EA 6E FE D7

00 00 FF FF FF F7 69 B7 A1 4A 96 D4

00 00 FF FF FF F8 A3 AA 14 3F 3C EB

00 00 FF FF FF F9 4B 91 99 AA C8 02

00 00 FF FF FF FA D4 24 2F C6 57 A1

00 00 FF FF FF FB 6A 06 C0 6A C1 FA

00 00 FF FF FF FC 6D B4 5E 46 A2 87

00 00 FF FF FF FD 3C 24 CD 0B 73 09

Page 17: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 17

00 00 FF FF FF FE 1B 15 4B 20 BE 61

00 00 FF FF FF FF 57 10 46 C9 5D 70

Nach dem Erstellen der Rainbow Table, die ja nach aufsteigenden Startwerten sortiert ist, muss man

sie jetzt nach aufsteigenden Endwerten umsortieren (ermöglicht später eine effiziente binäre Suche),

da beim Berechnen eines CW mit der Rainbow Table nach speziellen Endwerten gesucht wird. Hat

man sie dann gefunden wird der zugehörige Startwert zum Weiterrechnen ausgelesen:

00 00 11 6F 08 DB 00 00 00 02 47 07

00 00 86 27 08 E3 00 00 00 04 A6 18

00 00 6F 17 6A 22 00 00 00 04 A6 18

00 00 C5 69 2A 71 00 00 00 05 41 D4

00 00 99 53 B3 A0 00 00 00 05 41 D4

00 00 17 53 49 1A 00 00 00 05 41 D4

00 00 50 B1 62 86 00 00 00 06 73 BB

00 00 E4 EA 92 74 00 00 00 09 1F F2

00 00 A1 90 32 B8 00 00 00 09 1F F2

00 00 CB E4 99 8D 00 00 00 0F 06 A9

00 00 FD E3 71 39 FF FF FF F5 71 22

00 00 42 46 50 39 FF FF FF F6 7D 46

00 00 73 E6 2D 18 FF FF FF F6 CB 2F

00 00 94 E8 5C B5 FF FF FF F7 26 85

00 00 DF B4 C9 CA FF FF FF FA 69 33

00 00 36 9C 8D 69 FF FF FF FA BB 30

00 00 1E 4D FD C8 FF FF FF FA BB 30

00 00 50 F0 61 D0 FF FF FF FB 0E 88

00 00 F0 90 82 23 FF FF FF FB 89 A3

00 00 10 FD 97 EA FF FF FF FF 5B D4

Man kann jetzt auch gut das vorher geschilderte mergen sehen, das zu gleichen Endwerten führt.

Wir haben jetzt unsere Rainbow Table, aber wie ermittelt man mit ihr und einem ciphertext das CW?

Klären wir das gleich an Hand unseres Beispiels mit der obigen abgebildeten Kette mit Startwert 0.

Wir wir haben ein verschlüsseltes Paket gefunden das dem Plaintext 184 * 00h entspricht. Also

nehem wir den ersten 8 Byte Block vom Anfang er Payload AA 28 CA FD B7 5D 50 9E um das CW mit

der Rainbow Table herauszufinden.

Wir kürzen AA 28 CA FD B7 5D 50 9E auf 6 Bytes und führen eine XOR Verknüpfung mit der letzten

RoundNr FFFFh durch. Die 6 Byte vergleichen wir mit allen Endwerten der Rainbow Table. Es gibt

keine übereinstimmung.

Wir kürzen AA 28 CA FD B7 5D 50 9E auf 6 Bytes und führen eine XOR Verknüpfung mit der

vorletzten RoundNr FFFEh durch. Das Cw6: AA 28 CA FD 48 A3 konvertieren wir auf Cw8 und

verschlüsseln wir wieder unseren Plaintext 184 * 00h. Es ergibt sich der Ciphertext 3A 39 2A E6 42 61

D9 4B. Dann noch XOR mit der RoundNr FFFFh. Die 6 Bytes 3A 39 2A E6 BD 9E vergleichen wir mit

allen Endwerten der Rainbow Table. Jetzt gibt es eine Übereinstimmung. Falls dieser Endwert

mehrmals in der Rainbow Table vorkommt, muss man das Folgende für jeden zugehörigen Startwert

wiederholen. Wir holen uns den zum Endwert passenden Startwert 00 00 00 00 00 00 aus der

Rainbow Table. Dann berechnen wir wieder wie wir es schon beim Erzeugen der Rainbow Table

gemacht haben eine Kette und zwar die mit unseren gefunden Startwert 00 00 00 00 00 00. Dabei

Page 18: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 18

prüfen wir nach jeder Verschlüsselung ob das Ergebnis mit unseren Ciphertext AA 28 CA FD B7 5D 50

übereinstimmt. Falls ja, dann nehmen wir das Cw6 54 05 79 9D 6A 0D das diesen Ciphertext

ergeben hat, konvertieren es in ein Cw8 und fertig. Ansonsten wiederholen wird das Ganze bis wir

bei Runde 0 angekommen sind.

Cw6: 00 00 00 00 00 00 <= Startwert

Crypt: BF 8A 91 00 77 6F 7D A5

XOR RoundNr: 0h

Cw6: BF 8A 91 00 77 6F

Crypt: 1A 83 E3 00 58 84 B0 C6

XOR RoundNr: 1h

Crypt: 54 05 79 9D 95 F0 0E A9

XOR RoundNr: FFFDh

Cw6: 54 05 79 9D 6A 0D

Crypt: AA 28 CA FD B7 5D 50 9E

XOR RoundNr: FFFEh

Cw6: AA 28 CA FD 48 A3

Crypt: 3A 39 2A E6 42 61 D9 4B

XOR RoundNr: FFFFh

Cw6: 3A 39 2A E6 BD 9E <= Endwert

Page 19: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 19

Normaler ungetunnelter TS Bisher ging’s ja nur um getunnelte TS, doch wie sieht’s bei herkömmlichen ungetunnelten TS mit den

Berechnen von CWs mit Rainbow Tables aus?

Da hier nur Video und Audio verschlüsselt wird, entfallen hier sehr viele bekannte Klartexte. Ich habe

mir deswegen mal die Video-PID von einem unverschlüsselten Sender im HEX-Editor angesehen. Das

Interessante war, dass ich mehre unterschiedlich grosse Blöcke von Nullen gesehen habe. Sie waren

immer am Ende von einem MPEG Paket. Aber nicht jedes MPEG Paket hat Nullen am Ende. Wenn der

letzte Rest eines MPEG Pakets nicht exakt in ein TS Paket mit 184 Byte Payload passt, dann wird im

letzten TS Paket auch ein AF untergebracht. Das AF ist so gross, dass das Ende von MPEG Paket exakt

mit dem Ende der Payload vom TS Paket übereinstimmt. Das folgende TS Paket hat dann das Payload

Unit Start Indicator (PUSI)-Bit gesetzt und enthält den Anfang des

nächsten MPEG Pakets.

Wie erkennt man aber, ob bei einer konkreten verschlüsselten Video-PID,

auch solch praktische Nullen mit verschlüsselt wurden?

Man vergleicht die Payload der Pakete die auch ein AF haben. Wenn zwei

Identische vorkommen, dann sind es höchstwahrscheinlich verschlüsselte

Nullen.

Um das zu Testen habe ich mir einen Bruchteil einer Rainbow Table

erzeugt, die auf den Plaintext von 8 Nullbytes aufgebaut ist.

Hat eine Payload nur 0-7 Bytes, dann werden sie auch bei einem als

verschlüsselt markierten Paktet immer als Klartext übertragen. Der CSA-

Algo kann erst ab 8 Bytes verschlüsseln, bei weniger Bytes wird immer

transparent durchgereicht.

Eine Rainbow Table die auf 8 Nullbytes basiert, kann Payloads knacken die

zwischen 8 und 15 Bytes lang sind und bei denen die ersten 8 Bytes

verschlüsselte Nullen sind. Die restlichen bis zu 7 Bytes gehen nur durch

den Stream cipher und nicht durch den Block chipher. Deren Wert ist

somit irrelevant.

Ich habe mir ein paar Sender genommen, die mit Mediaguard 3,

Nagravision 3, Viaccess 3 und VideoGuard verschlüsselt sind. Es wird also

kein festes CW wie bei BISS verwendet, sondern ein etwa alle 10

Sekunden Wechselndes. Natürlich konnte ich mit dem Fragment meiner

Rainbow Table nur jeweils eins der CWs berechnen, also nur eine

Cryptoperiode entschlüsseln. Für ein paar Screenshots (siehe rechts) hat

aber gereicht.

Abbildung 3: 30W 11731H PID 1651h "FX Portugal"

Abbildung 4: 30W 11731H PID 1671h "Fox HD Spain & Portugal"

Abbildung 5: 13E 10796V PID AAh "Orange sport Polska"

Abbildung 6: 13E 12731H PID A7h "Int101_1"

Abbildung 7: 13E 12731H PID A8h "Int101_2"

Page 20: DVB TS Vollverschlüsselung geknacktcolibri.bplaced.net/DVB_TS_Vollverschluesselung_geknackt.pdf · 2013-06-10 · DVB TS Vollverschlüsselung geknackt Erstmals wurde die DVB Transport

DVB TS Vollverschlüsselung geknackt

Seite 20

Performance Mit meiner 12% Over Clocked NVIDIA GeForce GTX 470 (GV-N470SO-13I) komme ich auf folgende

Performance:

Plaintext Länge CWs pro Sekunde Erzeugezeit Durchschn. Zeit zum Ermitteln eines CWs

184 Bytes 30 Million 109 Tage 170 sek.

160 Bytes 33 Million 99 Tage

8 Bytes 71 Million 45 Tage

Die CWs pro Sekunde sind gemessen, die Erzeugezeit hochgerechnet. Ich habe ja nur die eine

Rainbow Table mit den 184 Bytes komplett erzeugt und selbst da habe ich den Rechner nicht an

einem Stück durchlaufen lassen.

Das Erzeugen der Rundenschlüssel für den Blockcipher frisst viel Zeit, ist aber nur einmal pro CW

nötig. Das Verschlüsseln pro 8 Byte Block geht viel schneller und fällt weniger ins Gewicht. Daduch ist

die Geschwindigkeit in der obigen Tabelle nicht gleichmässig im Verhältnis zu den 8 Byte Blöcken.

Evtl. kann ein CUDA [2] Profi noch mehr aus der Karte rausholen.

Empfehlungen Ganz klar ist die in der Praxis verwendete Schlüssellänge von nur 48 Bits zu gering, um gegen

Rainbow Tables standhalten zu können. Ein Firmwareupdate, das die Vollen vom CSA-Chip

unterstützen 64 Bits nutzt, ist notwendig um erst mal vor den Rainbow Table Angriffen geschützt zu

sein. Da dieser Schutz nicht ewig halten wird, muss sofort mit Entwicklung eines CSA Nachfolgers

begonnen werden. Dafür kann z.B. der schon fertige AES-Algo verwendet werden.

Literatur [1] Karsten Nohl, Kunterbuntes Schlüsselraten, http://www.heise.de/security/artikel/Von-

Woerterbuechern-und-Regenboegen-270088.html

[2] http://www.nvidia.de/object/what_is_cuda_new_de.html