Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenloses 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 Bereiche, welche für Gäste verwehrt bleiben

Ein paar Überlegungen zu den 90er Nanos der NDS-EMMs

Wie wir wissen, werden bei SkyDE Aktivierungen und Verlängerungen über den verschlüsselten Inhalt der unique EMMs gesteuert. Das sind die sogenannten 90er Nanos.

In diesem Beispiel wurde die 90er Nano abgetrennt.
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Die 1F ist die Gesamtlänge. Die 90 steht als Marker (Nano) für die Art des Inhaltes. Die 1D ist die Länge des Inhaltes. An "Länge + 90 + Länge-2" erkennt man sie hervorragend. Dummerweise kann man da nicht rein schauen.

Vielleicht entwickeln wir zusammen eine Idee, wie man das ändern kann. Die Chancen sind gering. Wer aber nichts probiert wird auch nichts erfahren.

Besonders gut zur Untersuchung eignen sich Verlängerer. In die kann man indirekt rein schauen. Man schreibt sie auf die Karte und bewundert anschließend den zurückgegebenen Code (9081 bei Änderung übernommen oder 9080 für keine Änderung) und natürlich die Entitlements.

Da immer der zuletzt geschriebene Verlängerer wirkt, kann man mit ihnen Ping Pong spielen. Man kann sie also abwechselnd im Kreis auf die Karte schreiben. Damit sind sie ideal zum Spielen.


0. Richtige Verschlüsselung

Für alle die da nicht so drin stecken:
  • Bei einer Verschlüsselung darf vereinfacht gesagt keine wesentliche Information nach außen dringen. Dazu gehören sämtliche Informationen zum Klartext und zum eingesetzten Schlüssel (Key).
  • Sie muss gegen Wiederholung gesichert werden (Replay Attack).
  • Sie muss unautorisierte Veränderungen von außen bemerken (MAC bzw. HMAC).
Wir legen fest, dass die NDS-Jungs ihr Handwerk verstehen und das (fast) alles berücksichtigt haben.


1. Nonce - Gegen Rückschlüsse auf den Klartext

Es gilt als Todsünde, mit dem selben Key verschiedene Klartexte zu verschlüsseln. Durch lustige XOR-Operationen bekommt man sonst einen guten Ansatz zur Erforschung des Inhaltes.

Aus diesem Grund wird ein Nonce (number used only once) verwendet. Das ist eine (Pseudo-)Zufallszahl. Die wird i. d. R. vor den Klartext gestellt. Danach wird erst verschlüsselt.

Macht NDS das? Es sieht danach aus.

Bei Kartenaktivierungen und sonstiger Randale mit Hilfe der Hotline bekommt man den gleichen Verlängerer unterschiedlich codiert.

Das sieht z. B. so aus:
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Bis zum 4402 sind sie identisch. Danach bleibt kein Bit mehr auf dem anderen. Dass diese Verlängerer intern identisch sind, beweist das abwechselnde Schreiben im Kreis mit einem dritten Abweichenden. Bei Aktivierungen bekommt man z. B. ganz zum Anfang einen "Entilöscher". Das ist ein sehr kurzer Verlängerer mit nur zwei (für uns nutzlosen) Entitlements. Dieser "Entilöscher" ist als Dritter gut geeignet.

Mit dessen Hilfe belegt man, dass beide (hier) 34er ein Verlängerer sind. Sie tragen nach dem "Entilöscher" die Entitlements wieder ein. Wenn man die (hier) 34er nacheinander schreibt, bekommt man die Antwort 9080 aka keine Änderung. Sie tragen also einen identischen Inhalt.

Es muss also ein Nonce drin stecken.


2. Komprimierung

Zu guten alten Zeiten gab es beim Kartenstart die schönen Verlängerertreppen. Das waren Gruppen von Verlängerern, bei denen der Folgende immer exakt ein Entitlement mehr beinhaltete als dessen Vorgänger.

Beispiel (Auszug):
Code:
Du musst dich Anmelden oder Registrieren um den Inhalt der Codes zu sehen!

Wie man sieht, werden die Verlängerer systematisch länger. Das passiert aber nicht immer, obwohl nachgewiesen werden konnte, dass die Entitlements mit jedem Schritt zunahmen. Dafür kann nur eine Komprimierung (wie in ZIP-Dateien) verantwortlich sein. Im DVB setzt man üblicherweise auf die ZLIB. Vermutlich ist das auch hier der Fall.

Man darf sich nach dem Decodieren also nicht vom augenscheinlichem Bitmüll abschrecken lassen. Zuerst steht ein Test auf eine ZLIB-Komprimierung an.


3. Replay

Man nimmt eine alte Nachricht und sendet die einfach auf doof nochmal. Man darf sich die Augen reiben, wie oft das funktioniert.

Gegen die "Replay Attack" hilft ein Zähler. Man merkt sich den letzten Stand und akzeptiert nur neuere Nachrichten.

Macht NDS etwas gegen Replay? Nö! Sie verlassen sich scheinbar nur auf die ohnehin vorhandenen Zeitstempel.


4. MAC

Da die MAC bei korrekter Anwendung bereits vor der Verschlüsselung an die Nachricht gehängt wird, wird man dazu erst ganz zum Schluss dazu eine Aussage bekommen können.

Der Einsatz von MACs ist aber seit eh und je üblich. Wer die im PayTV weg lässt, muss nochmal zur Schule gehen und darf solange nicht mehr ohne Aufsicht eines Erwachsenen programmieren. Wir legen fest, dass die selbstverständlich vorhanden ist.


5. Schlüssel

Es wird das Gerücht kolportiert, dass jede Karte für 4401, 4402 bzw. 4403 in der 90er Nano einen eigenen Schlüssel verwendet. Glauben wir das einfach mal.

Außer 4401, 4402 bzw. 4403 gibt es noch 4001, 4002 bzw. 4003 und 6001, 6002 bzw. 6003. Die findet man vorrangig in globalen EMMs. Hier handelt es sich ganz offensichtlich um den gleichen Schlüssel für mehrere bzw. alle Karten.

Die berühmte globale A0 EMM ist so ein Vertreter. Sie kommt mit 600x.

Die Länge des Schlüssels dürfte 128 Bit betragen. Das gilt zzt. als ausreichend. Weniger wäre unverantwortlich oder gar nicht einsetzbar (z. B. bei AES). Mehr ist zzt. nicht nötig. Mehr zieht einen erhöhten Rechenaufwand beim Verschlüsseln/Entschlüsseln nach sich. Ohne Nutzen lässt man das.

Wer eine Idee zur Unterstützung bzw. Widerlegung dieser These hat, immer her damit!


6. Art der Verschlüsselung

Man liest überall, dass die 90er Nano eine AES-Chiffre sei. Wer hat sich das nur ausgedacht? Warum schreibt das jeder ab?

Eine Block-Chiffre arbeitet, wie es der Name bereits sagt, blockweise. Die Blocklänge beträgt für AES mit 128 Bit Schlüssel ebenfalls 128 Bit aka 16 Byte. Weniger gibt es bei AES gar nicht.

Die 90er Nanos gibt es hingegen in allen möglichen Längen. Bei "Verlängerertreppen" wachsen sie in einer Schritten. Also nix AES! Da kann nur eine Stream-Chiffre drin stecken.


Noch was:
Das hier ist alles nur zu Forschungszwecken. Alle hier gezeigten EMMs wurden wahllos vom Transponder gelesen. Die Besitzer der Karten haben hiermit nichts zu tun.
 
Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!
ob das wirklich komprimierung ist, oder ob z.b. jeweils 2 bestimmte entitlements immer in einer festen anzahl an bytes (die von der anzahl her identisch ist zu der wie eines der beiden verbrauchen würde) zusammengefasst werden, wird schwierig sein herauszufinden... letztlich ist das zweite ja auch eine art komprimierung ;)
 
Guter Einwand!

Ich hätte die "Verlängerertreppe" nicht kürzen sollen. Hier ist sie nochmal komplett. Von jedem Verlängerer zum nächsten wächst exakt ein Entitlement an.


Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Am Anfang wird die EMM Schritt für Schritt länger. Die Entitlements werden immer mehr. Nach einer Weile kommen die Fälle, wo das Längenwachstum aussetzt. So verhalten sich komprimierte Daten.

Trotzdem ist natürlich nicht auszuschließen, dass sich bestimmte Entitlements einen Platz in den Daten teilen. Dann würde es sich auch so verhalten. Ich würde dann aber erwarten, dass die Antwort auf INS70 auch so ein Verhalten an den Tag legt. Dort gibt es zwar gepackte Bits, aber keine speziellen Gruppierungen.

Wenn es nicht komprimiert sein sollte, erkennt man es nach einer erfolgreichen Entschlüsselung sicherlich sofort. Zumindest das geübte Auge schlägt in solchen Fällen sofort Alarm. :)
 
Zuletzt bearbeitet von einem Moderator:
Problem dabei ist, das in solchen Konstellationen zuerst komprimiert und dann verschlüsselt wird. Heisst, wir werden vermutlich nur schwer rausfinden, ob die Daten zlib komprimiert sind. Grund dafür ist, daß die Entropie von verschlüsselten Daten (wenn der Implementierer wußte was er tat) ungleich höher als von Plaintext ist und damit schlechter komprimierbar.

So doof, einen zlib header mit zu verschlüsseln (known plainetxt) dürften die nicht sein.

Aber mal andersrum. Von Videoguard Gen1 (in UK) gibt es eine recht gute Analyse von warscheinlichen Plaintext-Inhalten der Nanos, da diese seinerzeit noch nicht verschlüsselt waren, sondern nur mit Prüfsummen gesichert. Die Struktur des Systems wird sich vermutlich nur in Details geändert haben, so dass für das neure System Plaintext-Schnipsel bekannt sein müssten. Wenn man jetzt von Stream Ciphern ausgeht, deren Schlüssel wieder mit AES gesichert sind, solltee man mit einer (umfangreichen) statistischen Auswertung oder gar der Anwendung von TensorFlow Muster erkennen können. Dem ganzen entgegen spricht wieder die mutmaßliche Verwendung von Nonces, die das Auffinden von Mustern ungleich schwerer machen werden.
 
Die Firmware älterer UK-Kisten hat mal jemand gepostet. Hat da schon jemand Binwalk drauf los gelassen? ;-)
 
Was gepostet wurde, weiß ich nicht. Vom Transponder hatte ich mal irgend solche Amstrad-Kisten gezogen. Binwalk entblättert daraus ein wunderschönes Linux-Dateisystem.

Da die Jungs auch hin und wieder auch in Foren mitlesen, werden die wohl kaum noch Kekse darin haben.

Die 90er Nanos werden nach meinem Wissen von den Boxen eh nur an die Karten durch gereicht. Deshalb erhoffe ich mir über diesen Weg keine Erkenntnisse.
 
Ein Blockschaltbild wäre sicher mal hilfreich. Ich geh mal schwer davon aus, daß die eigentliche Entschlüsselung und die Keys nicht in der normalen Firmware drin sind, sondern ein eigener security processor dafür on board ist. Halt ein fest eingebautes CI Modul. Trotzdem könnte die Firmware Aufschlüsse darüber geben, wie das angebunden ist, weil ja z.B. OSD-Fehlermeldungen ausgegeben werden müssen. Ich hab hier irgendwo noch ne Firmware von einem Pace 865 rumfliegen, der angeblich bei Sky DE im Einsatz war. Hab ich mal runtergeladen, bin aber nie zum reinschauen gekommen.

Und dann gibt es ja noch Nanos die an den Receiver gehen. Auch wenn das jetzt nicht unsere 90er sind, ich glaub nicht, daß die groß anders verschlüsselt werden. Oder gehen die zuerst an dei Karte und die gibt dann decrypted payload an den Receiver zurück?
 
Alles was an Receiver als ging C1-EMM ging, sieht extrem verdächtig nach Klartext aus. Darin stecken Teile für die Karten mit den 90er Nanos. Die werden aber sicherlich nur durch gereicht.

Offensichtlich kryptografischen Kram gibt es in den viel zitierten 38C1-EMMs. Da hängen hinten Keys oder was auch immer dran. Das Zeug sieht komplett zufällig aus und wiederholt sich auch nicht. Es hat aber nicht die Struktur einer Nano mit den beiden Längenbytes.
 
Zurück
Oben