Digital Eliteboard - Das Digitale Technik Forum
Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben
Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben
V13 cwe Key
- Ersteller BigDaddy2198
- Erstellt am
-
- Schlagworte
- boxid cardreader hashcat karte key oscam v13 videoguard2
-
Thread is read by:
i303
Ist oft hier
@DarkStarXxX :
Wie sind denn "Mining Rigs" so ausgestattet, was nimmt man denn da ? Auf diesem Gebiet kenne ich mich leider nicht gut aus... Nur was Nvidia GPUs betrifft, da konnte ich jetzt einiges an Erfahrung sammeln.... Nur soviel, eine T4 und V100 sind für den Fall rausgeschmissenes Geld (habe ich u.a.).... Mieten kann man, zumindest bei Google + AWS auch vergessen, viel zu teuer für das, was es da gibt.
Wie sind denn "Mining Rigs" so ausgestattet, was nimmt man denn da ? Auf diesem Gebiet kenne ich mich leider nicht gut aus... Nur was Nvidia GPUs betrifft, da konnte ich jetzt einiges an Erfahrung sammeln.... Nur soviel, eine T4 und V100 sind für den Fall rausgeschmissenes Geld (habe ich u.a.).... Mieten kann man, zumindest bei Google + AWS auch vergessen, viel zu teuer für das, was es da gibt.
Ich habe eine V14 ungepairt mit F0 mit korrekter Boxid, EMM und Ins7e. Auch auf die Gefahr hin das ich mich lächerlich mache...Ich glaube nicht das in China wo die CI+ Module gefertigt werden, der Key eingetragen wird...das wird sich Sky bestimmt nicht aus den Händen nehmen lassen...ich denke die Zuordnung Karte + HW passiert in der DB von Sky...jeder bekommt eine Karte von der Halde und HW von der Halde...der Key wird bei Sky generiert und dann über die Karte in der HW eingetragen... mit der Freischaltung kam für die Boxid neben dem 38C1 auch der 52C1 mit und es gibt in dem 52C1 zwischen der 02 und 00 exakt eine 16Byte lange Kette die bei denen die ich bekommen habe exakt gleich sind....kann sich das mal jemand ansehen der mehr Ahnung hat als ich...der Ins7e kam ja auch über den 38C1
i303
Ist oft hier
@tf_master : Wieso denn lächerlich machen? Witzbold! ;-) Also, ich sehe das - im Prinzip - genau so, der K1 wird bei Sky generiert und bei der Zuordnung auf die Karte geschrieben (ich vermute dahinter die 07er), zumindest ändert sich auch die Antwort vom ins7423 (hier vermute ich den EK1), wenn ich die Karte mit einer früheren Zuordnung zu einem Receiver beglücke. Nur bringt (mich) das halt aktuell auch nicht (schneller) weiter.... vielleicht schaffe ich es ja irgendwann mal, meinen K1 zu finden und kann mich dann auf die Suche nach dem K2 machen... ;-) ... vermutlich mache ich mich aber auch lächerlich. PS: Evtl. mal @rgmviper fragen.
PPS: Und was der 52C1 genau macht, würde mich auch interessieren, da konnte ich im Rahmen meiner Experimente leider noch gar keine Vermutung aufstellen.
PPS: Und was der 52C1 genau macht, würde mich auch interessieren, da konnte ich im Rahmen meiner Experimente leider noch gar keine Vermutung aufstellen.
Zuletzt bearbeitet:
Hallo,
hatte bisher eine Solokarte V14 und habe nach der Umstellung ein Sky Modul bestellt.
nach Lieferung sind
2 verschiedene 38c1
2 veschiedene 52c1 gekommen.
wobei die 16 Byte lange zeichenkette zwischen 02 und 00 gleich sind.
und danch folgt eine gleiche 8 byte folge zwischen 00 und 02 die nachfolgene byts sind dann wieder unterschiedlich.
vlt. hilfts
caveman99
Spezialist
- Registriert
- 14. November 2009
- Beiträge
- 656
- Reaktionspunkte
- 954
- Punkte
- 163
So, ich hab mich jetzt mal etwas quergelesen. Man braucht in der Tat etwas mathematischen Background. Alles was ich jetzt schreibe, ist unter der Voraussetzung, das Sky sich an die ETSI-Keyladder-Spec hält.
Das Controlword der Karte an die Box wird mit K1 verschlüsslt. K1 hat 128bit also 16 byte. Algorithmus ist entweder AES128 (passt so) oder Triple DES im Verfahren mit 2 Keys a 56 bit+Parity. In der Spec steht, bei DVB-CSA wird immer TripleDES verwendet, da das Control Word auch nur 64 (bis Frühjahr 2019 48) bit hat. Ansonsten würde selbiges mit Nullen verlängert.
Ich geh mal davon aus, daß wir von Triple-DES sprechen. Bei AES128 bräuchten wir nicht weiter zu denken.
K1 (128 bit) wird jetzt in der Mitte halbiert, so dass wir 2 64bit Werte bekommen (ich nenne diese beiden Hälften in Folge SK1 und SK2). DES ist ein Symmetrisches Verfahren, und ist für Verwendung mit 2key so spezifiziert:
Plain CW -> DES ENC mit SK1 -> DES DEC mit SK2 -> DES ENC mit SK1 -> Crypt CW
und natürlich auch wieder zurück:
Crypt CW -> DES ENC mit SK1 -> DES DEC mit SK2 -> DES ENC mit SK1 -> Plain CW
Es wird also erst mit der ersten Hälfte VERschlüsselt, dann mit der zweiten ENTschlüsselt und wieder mit der dritten VERschlüsselt.
Die Fachliteratur geht jetzt davon aus, daß man durch sogenannte Meet-in-the-Middle Angriffe nicht den vollen 112 bit (+ parity) Keyspace bei 3DES2Key bruteforcen muss, sondern der Aufwand etwa einem 80bit key entspricht. MITM zu erklären würde jetzt zu weit gehen, aber nur so viel: es hat was mit Symmetrien in DES und 3DES zu tun. Ein neueres Paper zu Attacken auf kontaktlose und Chip-Zahlkarten, die auch TDES verwenden, reduziert diesen Aufwand unter bestimmten Bedingungen sogar noch weiter in Richtung 60bit.
Kommen wir jetzt zum UNterschied zwischen V13 und V14/15. Hier fängt die Spekulation an und man möge mich korrigieren, wenn ich falsch Mutmaße. Bzw. wenn mir jemand bestätigen könnte, das das alles so ist, lohnt es sich, hier weiter zu machen.
Bei der V14 sind die beiden Halbkeys unterschiedlich, wir haben also die vollen 112bit bei 3DES. Bei V13 sind sie entweder gleich, oder einer der beiden Halbkeys ist konstant und bekannt.
Sind SK1 udn SK2 gleich, haben wir eine einfache Verschlüsselung mit DES (56bit). Licht an -> aus -> an ist eben das gleiche wie Licht an ;-) Ist entweder SK1 oder SK2 bekannt weil konstant, reduziert sich der Aufwand ebenfalls auf das einfache DES mit 56 bit.
Ein Brute-Forcen von einfachem DES dauert mit heue üblichen ASICs ein paar (30+) Tage. Hilfreiche Software dazu findet man im Internet, diese unterstützt GPU's, ASICs und verteiltes Rechnen. Je mehr Power, desto schneller. Selbst 3DES2Key ist unter den oben genannten Voraussetzungen in ca. einem Jahr machbar, die nötige Power vorausgesetzt, aber immer noch um ein vielfaches schwerer als 56bit. Beide Ansätze werden unterstützt, wenn man möglichst viele Paare von Ciphertext und Plaintext hat. Und das haben wir ja glücklicherweise. Wir haben Karten, die im Mode 83 das Crypt CW ausspucken, und Karten, die auf bestimmten Sendern noch Plain CW produzieren (oder Karten, deren K1 bereits bekannt ist, und uns dieses Plain CW bereitstellt).
Das Plain CW ist dabei natürlich immer gleich, sonst würde der Sender nicht entschlüsselt.
Also: ein paar Stunden das gleiche Programm mitloggen, einmal die PlainCW, einmal die CryptCW. Bruteforce starten und warten. Sollte K1 rausfallen, entweder GBOX verwenden (und hoffen, daß die NDS config so auch akzeptiert wird) oder oscam so patchen, daß er im Fall von Mode 83 das CW entschlüsselt bevor er es in die DVBAPI steckt.
Das Controlword der Karte an die Box wird mit K1 verschlüsslt. K1 hat 128bit also 16 byte. Algorithmus ist entweder AES128 (passt so) oder Triple DES im Verfahren mit 2 Keys a 56 bit+Parity. In der Spec steht, bei DVB-CSA wird immer TripleDES verwendet, da das Control Word auch nur 64 (bis Frühjahr 2019 48) bit hat. Ansonsten würde selbiges mit Nullen verlängert.
Ich geh mal davon aus, daß wir von Triple-DES sprechen. Bei AES128 bräuchten wir nicht weiter zu denken.
K1 (128 bit) wird jetzt in der Mitte halbiert, so dass wir 2 64bit Werte bekommen (ich nenne diese beiden Hälften in Folge SK1 und SK2). DES ist ein Symmetrisches Verfahren, und ist für Verwendung mit 2key so spezifiziert:
Plain CW -> DES ENC mit SK1 -> DES DEC mit SK2 -> DES ENC mit SK1 -> Crypt CW
und natürlich auch wieder zurück:
Crypt CW -> DES ENC mit SK1 -> DES DEC mit SK2 -> DES ENC mit SK1 -> Plain CW
Es wird also erst mit der ersten Hälfte VERschlüsselt, dann mit der zweiten ENTschlüsselt und wieder mit der dritten VERschlüsselt.
Die Fachliteratur geht jetzt davon aus, daß man durch sogenannte Meet-in-the-Middle Angriffe nicht den vollen 112 bit (+ parity) Keyspace bei 3DES2Key bruteforcen muss, sondern der Aufwand etwa einem 80bit key entspricht. MITM zu erklären würde jetzt zu weit gehen, aber nur so viel: es hat was mit Symmetrien in DES und 3DES zu tun. Ein neueres Paper zu Attacken auf kontaktlose und Chip-Zahlkarten, die auch TDES verwenden, reduziert diesen Aufwand unter bestimmten Bedingungen sogar noch weiter in Richtung 60bit.
Kommen wir jetzt zum UNterschied zwischen V13 und V14/15. Hier fängt die Spekulation an und man möge mich korrigieren, wenn ich falsch Mutmaße. Bzw. wenn mir jemand bestätigen könnte, das das alles so ist, lohnt es sich, hier weiter zu machen.
Bei der V14 sind die beiden Halbkeys unterschiedlich, wir haben also die vollen 112bit bei 3DES. Bei V13 sind sie entweder gleich, oder einer der beiden Halbkeys ist konstant und bekannt.
Sind SK1 udn SK2 gleich, haben wir eine einfache Verschlüsselung mit DES (56bit). Licht an -> aus -> an ist eben das gleiche wie Licht an ;-) Ist entweder SK1 oder SK2 bekannt weil konstant, reduziert sich der Aufwand ebenfalls auf das einfache DES mit 56 bit.
Ein Brute-Forcen von einfachem DES dauert mit heue üblichen ASICs ein paar (30+) Tage. Hilfreiche Software dazu findet man im Internet, diese unterstützt GPU's, ASICs und verteiltes Rechnen. Je mehr Power, desto schneller. Selbst 3DES2Key ist unter den oben genannten Voraussetzungen in ca. einem Jahr machbar, die nötige Power vorausgesetzt, aber immer noch um ein vielfaches schwerer als 56bit. Beide Ansätze werden unterstützt, wenn man möglichst viele Paare von Ciphertext und Plaintext hat. Und das haben wir ja glücklicherweise. Wir haben Karten, die im Mode 83 das Crypt CW ausspucken, und Karten, die auf bestimmten Sendern noch Plain CW produzieren (oder Karten, deren K1 bereits bekannt ist, und uns dieses Plain CW bereitstellt).
Das Plain CW ist dabei natürlich immer gleich, sonst würde der Sender nicht entschlüsselt.
Also: ein paar Stunden das gleiche Programm mitloggen, einmal die PlainCW, einmal die CryptCW. Bruteforce starten und warten. Sollte K1 rausfallen, entweder GBOX verwenden (und hoffen, daß die NDS config so auch akzeptiert wird) oder oscam so patchen, daß er im Fall von Mode 83 das CW entschlüsselt bevor er es in die DVBAPI steckt.
Zuletzt bearbeitet:
G
Gelöschtes Mitglied 488570
Guest
Wenn es 2x der Gleiche Key ist ist der Aufwand der selbe wie für 56Bit da er sich ja im ersten und zweiten Teil analog ändert.
……………………
Bei 56Bit und bekannten ECW und DCW halbiert sich zwar die Zeit da nicht mehr alle durchprobiert werden müssen aber so alt wird man trotzdem nicht.
Hier hat sich wohl der Fehlerteufel eingeschlichen oder ich sehe nicht mehr durch bei der ganzen Sache..
und natürlich auch wieder zurück müsste doch so aussehen ...
Crypt CW -> DES DEC mit SK1 -> DES ENC mit SK2 -> DES DEC mit SK1 -> Plain CW
Zuletzt bearbeitet von einem Moderator:
- Registriert
- 30. Dezember 2009
- Beiträge
- 18.782
- Lösungen
- 11
- Reaktionspunkte
- 22.677
- Punkte
- 1.103
Du wirst also keine 3-7 Tage mehr alt? Weil länger dauerts nicht für eine V13 wenn man das an die entsprechenden Stellen im Netz weiterleitet.
i303
Ist oft hier
caveman99
Spezialist
- Registriert
- 14. November 2009
- Beiträge
- 656
- Reaktionspunkte
- 954
- Punkte
- 163
@i303 - dein Google ist kaputt ;-) - Natürlich geht das.
"A Known-Plaintext Attack on Two-Key Triple Encryption" -- Paul C. van Oorschot and Michael J. Wiener (1990)
und das Dokument, was das Ganze dann auch in umsetzbares Fahrwasser bringt:
"On the security of 2-key triple DES" -- Chris J. Mitchell, Information Security Group, Royal Holloway, University of London
jetzt ihr wieder...
"A Known-Plaintext Attack on Two-Key Triple Encryption" -- Paul C. van Oorschot and Michael J. Wiener (1990)
und das Dokument, was das Ganze dann auch in umsetzbares Fahrwasser bringt:
"On the security of 2-key triple DES" -- Chris J. Mitchell, Information Security Group, Royal Holloway, University of London
jetzt ihr wieder...
Zuletzt bearbeitet:
i303
Ist oft hier
Ok, wenn Du meinst...
i303
Ist oft hier
Ah, ja, der wird wohl grundsätzlich gehen, vermute ich, und auf den setze ich auch, wenn auch abgewandelt, leider habe ich ja nicht den ganzen Speicher der Welt und selbst das dürfte knapp werden.... ;-)
Aber das ist doch nicht der "klassische" MITM, wie er bei der zweifach-Verschlüsselung, also zwei Keys, zweimal nacheinander verschlüsseln, möglich ist oder? Habe mich aber - zugegeben - mit den möglichen Attacken bei den anderen Verschlüsselungsvarianten nicht tiefer beschäftigt, aber daß man den "Orschot/Wiener" einen MITM nennt, lese ich zum ersten Mal, und auch wenn ich nicht Mathe studiert habe und Kryptographie nicht gerade mein Fachgebiet ist, so erscheint mir das (also, kein MITM) sogar etwas logisch, .... das abwechselnde Decrypt/Encrypt macht Dir doch je nach Keylage jede "Symmetrie" kaputt, ... vermute ich, herleiten kann ich es natürlich vermutlich nicht.
Aber, @caveman99, jetzt bitte nicht falsch verstehen, den Orschot/Wiener halte ich jedenfalls grundsätzlich für richtig und funktional.... so schwer ist das ja auch nicht...
Aber das ist doch nicht der "klassische" MITM, wie er bei der zweifach-Verschlüsselung, also zwei Keys, zweimal nacheinander verschlüsseln, möglich ist oder? Habe mich aber - zugegeben - mit den möglichen Attacken bei den anderen Verschlüsselungsvarianten nicht tiefer beschäftigt, aber daß man den "Orschot/Wiener" einen MITM nennt, lese ich zum ersten Mal, und auch wenn ich nicht Mathe studiert habe und Kryptographie nicht gerade mein Fachgebiet ist, so erscheint mir das (also, kein MITM) sogar etwas logisch, .... das abwechselnde Decrypt/Encrypt macht Dir doch je nach Keylage jede "Symmetrie" kaputt, ... vermute ich, herleiten kann ich es natürlich vermutlich nicht.
Aber, @caveman99, jetzt bitte nicht falsch verstehen, den Orschot/Wiener halte ich jedenfalls grundsätzlich für richtig und funktional.... so schwer ist das ja auch nicht...
caveman99
Spezialist
- Registriert
- 14. November 2009
- Beiträge
- 656
- Reaktionspunkte
- 954
- Punkte
- 163
bei 3DES hast du normalerweise 3x56bit Keys, hier haben wir die Spezialität, dass 2 dieser 3 Keys (V14/15) oder mutmaßlich alle 3 Keys (V13) identisch sind. Das reduziert den Aufwand enorm und schwächt die verwendeten Verfahren. die Herangehensweise ist immer noch entfernt mit der von MITM identisch, weil man sich der Gleichung immer noch aus 2 Richtungen nähert, und sowieso in den Zwischentabellen alle invertierten Lagen weglassen kann. Das 3DES der V13 ist nicht wirklich eine herausforderung, und mit Mitchell rückt auch das V14/V15 Verfahren in greifbare Nähe. In letzterem paper sollte man nur die Teile überlesen, die mit partially known plaintext zu tun haben, das trifft hier nicht zu. Die Hardware dafür dürfte trotzdem kaum einer zu Hause rumstehen haben.
Ähnliche Themen
- Gelöst
