This page has been robot translated, sorry for typos if any. Original content here.

Brechen der U-Bahn (Reisekarten) + CRYPTOGRAPHIC TRANSFORM ALGORITHM GEMÄSS GOST 28147-89

Auf Seite:


U-bahn brechen (reisekarten)

Kennen Sie den Wunsch, alle Rätsel zu lösen und alle Verteidigungen der Moskauer U-Bahn aufzudecken? Zum Beispiel, um sich ein "ewiges Ticket" zu machen? Schließlich finden U-Bahn-Experten immer ausgefeiltere Schutzmethoden. Metallmarken wurden durch Plastikmarken ersetzt, die wiederum Magnetkarten waren, und kontaktlose Karten ersetzten Magnetkarten. Viele Forscher haben ihre Hände fallen lassen - es scheint, dass der Metropolitan eine uneinnehmbare Festung geworden ist. Jeder Schutz kann jedoch umgangen werden. Und oft ist es einfacher zu öffnen als zu bauen ...

Wie alles begann

Ich hatte vor langer Zeit, könnte man sagen, ein Interesse an U-Bahn-Systemen, als es noch Tickets mit einem Magnetstreifen gab. Gleichzeitig (vor ungefähr einem Jahrzehnt) führten sie eine kontaktlose Sozialkarte für Studenten ein. Ich interessierte mich dafür, was es ist und wie es funktioniert. Zu dieser Zeit verfügte ich jedoch nicht über ausreichende Kenntnisse und es gab nur wenige Informationen in der Öffentlichkeit, insbesondere zu diesen Technologien. Ich musste die Idee der Forschung über den Backburner aufschieben, aber ich habe mir selbst versprochen, dass ich definitiv darauf zurückkommen werde ...

Vor etwa drei Jahren ist mein Interesse am Thema U-Bahn wieder geweckt worden. Ich habe Magnetkarten aktiv studiert (es gab viele Informationen zu diesem Thema im Internet) und sogar eine kleine Maschine gesammelt, mit der Duplikate von zwei Köpfen von Tonbandgeräten auf Band und eine kleine Menge loser Karten hergestellt werden können. Ich habe meine Sozialkarte (bereits Student) nicht vergessen. Nach dem Studium der Dokumentation wurde mir jedoch klar, dass das System praktisch uneinnehmbar ist - der MF1S50 Mifare Classic 1K-Chip, auf dessen Basis Sozialkarten hergestellt werden, ist durch zwei 48-Bit-Schlüssel geschützt. Auf der Hardware-Ebene funktioniert das Hacken einfach nicht, und Sie können die Tasten bis zum Ende des Sonnensystems berühren. Und für die Karteninhaber, die Classic unterstützen, waren sie für diese Zeit sehr viel Geld wert (an Ebay habe ich leider nicht gedacht). Das Interesse an Magnetkarten ließ schnell nach und die Social Card musste wieder auf bessere Zeiten verschoben werden.

Treffen: "Ultralight"

Tickets "Ultralight" erschienen kürzlich in unserer U-Bahn, stießen aber sofort auf großes Interesse bei der Öffentlichkeit. Sie begannen zu töten, zu zerreißen, ein Eisen in Kauf zu nehmen und andere Methoden der thermorektalen Kryptoanalyse anzuwenden. Zugegeben, der Wissensdurst ließ mich ein paar zerreißen. Als Ergebnis ihrer Untersuchungen und Recherchen im Internet stellte sich heraus, dass dies nichts anderes als Mifare Ultralight ist, die "leichte" kompatible Version von Mifare Classic. Eine schnelle Durchsicht der Dokumentation auf den Chips dieses Standards ergab, dass diese Karten keine eingebetteten Sicherheitssysteme haben. Darüber hinaus habe ich einen Artikel über das erfolgreiche Hacken eines ähnlichen Transportsystems durch niederländische Studenten angegriffen. Alle zusammen haben mich zu neuen Forschungen getrieben.

Lass uns gehen!

Zunächst musste natürlich nur ein kabelloser Kartenleser angeschafft werden, der Ultralight unterstützt. Es gab zwei Möglichkeiten: entweder sich selbst zusammenzubauen (was viel Zeit in Anspruch nimmt) oder ein fertiges Gerät zu kaufen. Bei dem Gedanken an die zweite Option hatte ich angesichts der Preise von vor drei Jahren eine Gänsehaut. Trotzdem habe ich mich entschlossen, die aktuellen Preise zu betrachten. Und das aus gutem Grund! Ich war angenehm überrascht zu erfahren, dass Sie ein voll funktionsfähiges Gerät (OmniKey CardMan 5321) kaufen können, das eine Reihe von kabelgebundenen und kabellosen Karten zu einem attraktiven Preis unterstützt - 4.000 Rubel.

Natürlich nicht ein bisschen, aber auf der anderen Seite sind es nicht 10.000; Darüber hinaus ermöglichte der Kauf eines gebrauchsfertigen Lesegeräts die sofortige Konzentration auf die Recherche nach Tickets und nicht auf das Entwerfen und Debuggen von Eisen, was sich unbegrenzt verzögern könnte. Zusammen mit dem Reader wurde von derselben Firma (ISBC) ein sehr praktisches Original-SDK der lokalen Produktion gekauft. Auch hier durfte er keine Zeit und Mühe mit dem Schreiben von Low-Level- und Debugging-Software-Arbeiten mit dem Leser verschwenden, sondern sich direkt auf die Tickets konzentrieren. So entstand für ein paar Tage gemütlichen Programmierens ein kleines Programm, mit dem sich die gesamte interne Struktur der Ultralights bequem beobachten und bearbeiten ließ. Dann fing ich an, Tickets zu lernen.

Leere Wand

Während des Studiums gingen viele Tickets durch meinen Leser. Einige, ich krempelte die Ärmel hoch, holte "aus dem Müll" heraus, andere kaufte ich - ich schaute mir an, was auf sie geschrieben stand, dann ging ich und schaute noch einmal. Dies waren fast alle Arten von Tickets, mit der möglichen Ausnahme des Ultralight-Passes für 70 Fahrten. Nach ein paar Wochen hatte ich eine große und sortierte Datenbank mit Dumps verschiedener Tickets und in verschiedenen Staaten. Nach jeder Fahrt wurden Dumps von demselben Ticket genommen, und mehrere Tickets mit U-Bahn-Nummern liefen hintereinander. In meiner Sammlung bekamen sogar ein paar Dumps von zwei verschiedenen temporären einheitlichen Sozialtickets (eines wurde für einen Zeitraum von 5 Tagen ausgestellt, das andere für 30), die nach einer bestimmten Zeitspanne entnommen wurden. Es stellte sich heraus, dass es sich um sehr interessante und gleichzeitig sehr seltene Exemplare handelte (ich habe sie mit sofortiger Rückgabe aus erster Hand erhalten, nur zum „Lesen“).

In der Tat ist es fast die einzige Art von "Ultralight", die nicht nur in der U-Bahn, sondern auch im Bodentransport funktioniert. Darüber hinaus ist die Anzahl der Fahrten nur für diese Art von Tickets unbegrenzt. In der Folge haben sie mir einen großartigen Dienst erwiesen ... Ich habe diesen ganzen Zoo zu einem Zweck gesammelt - um die Struktur und das Format der Datenaufzeichnung auf dem Ticket klar zu definieren. Natürlich waren einige Felder sofort mit bloßem Auge sichtbar, andere jedoch nicht. Zum Beispiel habe ich nicht sofort verstanden, wo die U-Bahn-Ticket-Nummer steht (die aufgedruckte Nummer). Das Bewusstsein kam ganz zufällig. Tatsache ist, dass ich (wie ich denke, die meisten von uns) beim Betrachten des Hexadezimalzeichens verwendet habe, um die Informationen für sich selbst auf Bytes auszurichten und mindestens Bytes zu denken. Es stellte sich heraus, dass dieser Ansatz hier falsch ist. Betrachtet man den Ticket-Dump, muss man in kleineren Einheiten denken - Tetraden und manchmal Bits. Ich habe das verstanden, als ich endlich die Ticketnummer sah - sie wurde relativ zum Anfang des Bytes auf 4 Bits verschoben, und die verbleibenden 4 Bits von dieser und der anderen Seite der Nummer wurden von anderen Dienstinformationen belegt. Nach einiger Zeit wurde das Format für die Aufzeichnung von Daten auf Tickets fast vollständig klar.

Es wurde deutlich, wo und wie alle Daten, Zähler, Kennungen gespeichert sind. Es blieben nur ein paar Felder übrig, deren Zweck unklar war, weil die Daten in ihnen von Dump zu Dump gleich waren. Aber das war das Ende aller Freude - es wäre töricht anzunehmen, dass solche Tickets ungeschützt bleiben könnten. Jeder Speicherauszug enthielt 32 Bits unterschiedlicher Informationen, die nicht mit dem Rest des Inhalts korrelierten. Ich nahm an, dass es eine Art Prüfsumme war, ein „Hash“ der auf dem Ticket aufgezeichneten Daten. Alle Versuche, diese 32 Bits zu schätzen oder zu berechnen, stellten sich als völliger Fehler heraus (insbesondere wurde angenommen, dass es sich um eine Art CRC32 mit einem nicht standardmäßigen Polynom und Startwert handelte).

Bei dem Versuch, mindestens anderthalb Bits an Informationen im Ticket zu ändern, zeigte das Kassenterminal in der U-Bahn das „SCHLECHTE TICKET“ an und wog die letzten Nägel mit einem schweren Wagenheber in den Sarg. Natürlich gab es Versuche, das System auf andere Weise zu umgehen, zum Beispiel, um zu versuchen, ein Ticket auf eine leere Eins-zu-Eins-Karte zu kopieren (hier verhinderte leider die Fabrikserie, die, wie sich herausstellte, auch an der Erzeugung des Hash beteiligt war) oder die Sperrbits als um zu verhindern, dass das Drehkreuz den Inhalt des Tickets ändert. Das Testterminal erkannte ein solches "ewiges" Ticket, weigerte sich jedoch, das Drehkreuz loszulassen ... Also rannte ich gegen die Wand. In der großen, starken Betonmauer, an der viele die Angewohnheit haben, abzutöten. Da ich in den Foren und Foren keine Informationen fand, entschied ich, dass meine Recherche hiermit abgeschlossen war - es gab keine weiteren Möglichkeiten, und ich traf die Entscheidung. Wie sich herausstellte, nichts ...

Seltsame Bekanntschaft

Der Septemberabend war nicht anders als die anderen. Die Nacht war fast da, es war kühl und feucht draußen. Ich saß vor dem Monitorbildschirm und trank einen warmen, leicht süßlichen grünen Tee und teilte friedlich eine Gebühr für mein nächstes Handwerk. DipTarce, ein bisschen bashorga, ICQ ... Jemand hat Skype angerufen - ablenkend! Wieder ICQ, wieder DipTrace - im Allgemeinen ist alles wie gewohnt. Wieder einmal trat das ICQ-Fenster in den Vordergrund - jemand, den ich nicht kannte, schrieb „Hallo“. Zweifellos habe ich das Gleiche geantwortet. Die folgende Nachricht war ein Wendepunkt in der ganzen Geschichte: „Sie interessieren sich für die U-Bahn, ich habe einige Sachen hier. Wenn Sie interessiert sind, treffen wir uns, ich sage es Ihnen. " Zuerst war ich ein wenig verlegen und alarmiert (vielleicht wurde eine Scheidung oder eine Einstellung oder vielleicht wurden die „besonderen Dienste“ interessiert - die Paranoia fordert ihren Tribut), aber dann dachte ich: Warum nicht?

Geheimdienste hätten sich kaum für mich interessiert, und es scheint keinen Grund für eine Scheidung zu geben, und noch mehr für das Setup. Nach einem kurzen Gespräch einigten wir uns darauf, uns am Nachmittag in der Mitte der Halle einer der Stationen der Moskauer U-Bahn zu treffen. Der Fremde war ein großer junger Mann mit Brille und einer großen schwarzen Plastiktüte in den Händen. Wir begrüßten uns, dann reichte er mir ein Päckchen mit den Worten: „Moment mal. Es hat immer noch nicht funktioniert, es könnte für dich nützlich sein. " Als ich nach innen schaute, sah ich zwei U-Bahn-Terminals, die von Zeitungen verschoben wurden, ein paar willkürlich verstreute weiße Plastikkarten und einen leeren Karton in einer Schachtel. Auf meine Frage, wie viel ich (Geld) dafür schulde, schüttelte der Typ den Kopf, lächelte und sagte: „Warum, niemand schuldet irgendjemandem etwas, mach es ... Also, ich muss schon laufen, mein Zug ist wie Zeit! Komm schon, tschüss! "

Mit diesen Worten rannte er weg, sprang in die bereits schließenden Türen des Wagens und ging. Und ich, ich gestehe, ging ein wenig in neponyatka nach Hause. Ich habe den Kontakt für alle Fälle von ICQ gelöscht, gleichzeitig die Kontaktliste auf dem Server bereinigt und die Protokolle aufgeräumt (hallo nochmal, Paranoia). Am Ende werde ich nochmal schreiben, wenn das so ist. Aber umso mehr hat er mir nie geschrieben ...

Das Phänomen der Software für die Menschen

Nach Hause gekommen, zerlegte ich das Paket. Das zweite Terminal erwies sich als Busprüfer (schwer, verdammt!); Die Karten waren Mifare Classic 1K (sauber), und auf der Festplatte befand sich ein einzelnes Archiv. Nach einem kurzen Kennenlernen der Inhalte stellte sich heraus, dass dies die Software ist, die an den Kassen der U-Bahn verwendet wird. Nachdem ich das Terminal und den Validator beiseite gelegt hatte, beschloss ich, mich mit dem Studium interessanter Software auseinanderzusetzen. Ungefähr eine Stunde nach dem Auspacken gelang es mir, dieses Programm auf meinem Computer zu erstellen und auszuführen. Es dauerte eine weitere Stunde, um die Struktur zu klären. Nachdem ich alle ini-Dateien (mit Kommentaren, die freundlicherweise vom Entwickler hinterlassen wurden) gekämmt hatte, hatte ich bereits eine vollständige Vorstellung davon, was es ist, wie es funktioniert und womit es isst. Wie sich herausstellte, konnte die Software in Abwesenheit des Lesegeräts Parsec PR-P08 nicht in Aktion getestet werden.

Der Entwickler war Smartek, ein Großauftragnehmer der Regierung, der Systeme dieser Art entwickelte (weitere Informationen finden Sie auf deren Website). Das Programm wurde in Delphi mit runtime-bpl'ok geschrieben. Darüber hinaus war die Software modular aufgebaut und alle Unterprogramme, Klassen und Komponenten befanden sich in separaten DLLs oder bpls mit sprechenden Namen (dies war die wichtigste Entwicklungsdatei der Entwickler). Nach einer kurzen Analyse der internen Software stellte ich fest, dass zum einen Informationen zu allen ausgegebenen Tickets in eine zentralisierte Datenbank übertragen werden (übrigens handelt es sich um Oracle), und zum anderen verwendet das Programm eine Art Schlüsselmechanismus. Das Programm konnte nicht nur in Echtzeit mit der Datenbank kommunizieren. Wir ziehen Schlussfolgerungen: Alle Operationen im System können mit einer gewissen Verzögerung erfolgen. Theoretisch verschafft es uns einen Vorsprung.

Aber zuallererst interessierte mich der Schlüsselmechanismus (ich begann bereits zu erraten, warum er benötigt werden könnte). Also nahm ich den Zerleger und machte mich an die Arbeit. Der Mechanismus bestand aus zwei Dateien - CryptKeyRef.dll und keys.d (die einzige "knifflige" Datei im gesamten Programm, die mit Ausnahme der Datei mit den Schlüsseln nichts mehr zu suchen hat). Und genoss all diese gute Laufzeit-bpl'ina SmLayout.bpl. Diese Bibliothek war nur ein Glücksfall für meine Recherche - sie enthielt Klassen zum internen Ausfüllen von Tickets. Da dies runtime-bpl ist, reichte es aus, nur auf die Exporttabelle zu schauen, um zu 60 Prozent zu verstehen, was passierte. Eine genauere Analyse hat alles in Ordnung gebracht. Erinnern Sie sich, am Anfang des Artikels sagte ich, dass es in der Struktur des "Ultralight" noch einige Felder gab, deren Zweck nicht klar war?

Eines dieser Felder ist der sogenannte „Layout Identifier“. Tatsächlich bestehen alle Metrotickets aus einem festen Header und einem variablen Teil der Daten. In diesem Feld „Layout“ in der Kopfzeile wurde festgelegt, wie und welche Daten sich im Rest des Tickets befinden. Es gibt mehrere solcher Layouts (jedes für seinen eigenen Tickettyp) und in SmLayout.bpl hatte jedes eine eigene Klasse (plus die allgemeine übergeordnete Klasse, die Methoden zum Arbeiten mit dem Header-Teil enthielt). Daher war es einfach herauszufinden, für welche Felder in jedem Layout sie verantwortlich sind (auch mit den Namen der exportierten Methoden!). Nachdem ich das gesamte Layout 8 (das in den „Ultralights“ verwendet wird) fertiggestellt und überprüft hatte, ob ich die richtige Vorstellung von allen Feldern in der Ticketstruktur hatte, griff ich den Schlüsselmechanismus auf. In der Tat war er für die Generierung des Hash verantwortlich. Wie der Mechanismus funktioniert, wurde völlig klar, nachdem man die Arbeit der Methode studiert hatte, die für die Berechnung des "Hash" verantwortlich ist. Zunächst wird der richtige Schlüssel aus der Schlüsseldatei (keys.d) ausgewählt.

Das System ist so konzipiert, dass jeder Tickettyp eine eigene Kennung hat (es gab eine vollständige Tabelle mit Kennungen und Ticketnamen in Form einer Textdatei mit durch Kommas getrennten Werten). Es besteht aus einer Zonen-ID (Anwendung) und einer Kartentyp-ID. Ausgehend von diesen Zahlen wird der Schlüsselbund in der Schlüsseldatei ausgewählt, in der sich möglicherweise bereits mehrere Schlüssel befinden (falls ein neuer Schlüssel eingegeben wird und die alten Tickets noch verwendet werden). Das neue Ticket wird mit dem ersten Ticket erfasst, und die Gültigkeitsprüfung wird mit allen Schlüsseln im Schlüsselbund durchgeführt. Als nächstes wird der ausgewählte Schlüssel mit CryptKeyRef.dll entschlüsselt (warum sie verschlüsselt gespeichert werden, kann ich nichts dagegen tun). Danach werden der entschlüsselte Schlüssel und fast alle Ticketdaten sowie seine Hardware-Seriennummer und -Nummer (die für die Eingabe von keys.d festgelegte Hash-Generierungsmethode) an die Funktion ckCalcHashCode übertragen, die sich in derselben CryptKeyRef.dll befindet. Am Ausgang bekommen wir den Wert, auf den ich einmal "geklebt" habe - den gleichen "Hash". Natürlich habe ich ein kleines Programm geschrieben, das unter Verwendung dieser Funktionen aus CryptKeyRef.dll und der Datei keys.d den "Hash" in jedem Dump überprüfen und neu berechnen konnte. Ich überprüfte alles noch einmal auf mehreren Müllhalden und ließ mich, nachdem ich ein positives Ergebnis erhalten hatte, zufrieden schlafen.

Faule Schlüssel

Trotz des theoretischen Erfolgs wollte ich sozusagen alles "im Kampf" überprüfen. Am nächsten Tag, als ich von der Arbeit zurückkam, kaufte ich absichtlich ein neues „Ultralight“ für eine Fahrt, um zu sehen, ob meine Schlüssel gültig waren oder nicht (anscheinend waren sie alt). Sie könnten natürlich sofort versuchen, das "fabrizierte" "Ultralight" aufzuschreiben und es zu überprüfen, aber zu diesem Zeitpunkt waren mir die leeren Karten ausgegangen, und es war ein bisschen beängstigend, "zufällig" zu gehen - was wäre, wenn? Als ich nach Hause kam, beeilte ich mich, ohne mir die Hände zu waschen, als erstes, das frische Ticket mit meinen eigenen Schlüsseln zu überprüfen. Und dann wartete ich auf eine große Enttäuschung - der auf dem Ticket vermerkte „Hash“ ging durch keinen der Schlüssel. Daher sind die Schlüssel wirklich faul und sie wurden durch neue ersetzt. Dies hat alle meine Bemühungen vollständig gekreuzt. Ich war ein bisschen traurig. Ich kochte grünen Tee, spielte ein wenig Klavier (ja) und setzte mich, um meine unvollendete Gebühr zu erhöhen ...

Es ist nicht alles verloren

Die Idee kam mir unerwartet, als ich aus irgendeinem Grund noch einmal in die Akte mit den Schlüsseln schaute. Mir ist aufgefallen, dass sich im "laufenden" Schlüsselring (der zur Berechnung von 1-, 2-, 5-Zug- und anderen "Ultralights" verwendet wird) zwei Schlüssel befanden - ein neuer (zu dieser Zeit natürlich) und anscheinend ein alter. Es gab aber auch einen Schlüsselbund, in dem es nur einen Schlüssel gab. Zuvor habe ich nicht auf ihn geachtet und mich auf das "Laufen" konzentriert. Um zu berechnen, welche Tickets dieser Schlüssel verwendet, wusste ich nicht. Als ich nachschaute, welche Art von Ticket mit dem Schlüsselbund verbunden ist, hatte ich einen kleinen Hoffnungsschimmer. Die Tatsache, dass diese Art von Ticket war - WESB. Ja, diese seltene Art von Fahrkarten ist eine vorübergehende Fahrkarte für alle Arten von Transport. Ich dachte, wenn das Ticket einfach ist, sollte dieser Schlüssel nicht nur in der U-Bahn, sondern auch im Landverkehr verwendet werden, wo es sehr schwierig und lang ist, ihn durch einen neuen zu ersetzen.

Außerdem ist der Schlüssel im Schlüsselbund nur einer, was meine Vermutung indirekt bestätigt. Außerdem erinnerte ich mich, dass es bei der Bereinigung des U-Bahn-Programms von diversem „Müll“ etwas Ähnliches gab wie ein Archiv alter Schlüsseldateien. Nachdem ich das ursprüngliche Archiv ausgegraben und geöffnet hatte, sah ich, dass dies tatsächlich der Fall war. Und am wichtigsten ist, dass ich nach Durchsicht aller alten Schlüsseldateien festgestellt habe, dass dieser Schlüssel unverändert geblieben ist! Bereits ohne einen einzigen Zweifel habe ich meinen eigenen VESB genietet (zum Glück hatte ich Speicherauszüge dieses Typs, was die Aufgabe manchmal vereinfachte - ich habe nur die Daten und die Nummer in den Speicherauszügen geändert) und den Hash mit diesem Schlüssel berechnet. Also ist es Zeit zu überprüfen (zumal ich gerade etwas saubereres Plastik gekauft habe). Als ich die Lobby betrat, habe ich zuerst mein „Ticket“ an das Testterminal angehängt. Das Display zeigte die Gültigkeit des von mir angezeigten Tickets an und die grüne LED ging an. So funktioniert es. Nachdem ich eine Grimasse einfacher gemacht und das weiße Plastik im Ärmel versteckt hatte, ging ich zum Drehkreuz, legte meine Hand zum Prüfer und ... ging ruhig weiter zum grüngrünen Licht emittierenden Feuer. Dies war der letzte Sieg.

Und wie geht es weiter?

Und dann begannen die Experimente, bei denen viele interessante Dinge entdeckt wurden. Zum Beispiel kann ein solcher "linker" VESB nur zwei oder drei Tage laufen. Tatsache ist, dass die Nummer, die ich im Ticket als „von der Glatze“ bezeichne, bei jedem Durchgang im Speicher des Kopfes des Drehkreuzes gespeichert und nach einiger Zeit zusammen mit den anderen an das Rechenzentrum gesendet wird. Dort findet das System das tatsächlich ausgestellte Ticket mit einer solchen Nummer nicht und stellt es in die Stoppliste, die dann an alle Drehkreuze der U-Bahn gesendet wird. Und dies sollte bei allen Arten von Tickets der Fall sein, nicht nur bei VESB - zusätzlich zu dem „Hash“ und den häufig wechselnden Schlüsseln ist dies ein sehr guter Schutz. Eine Umgehung ist aus offensichtlichen Gründen nicht möglich.

Es wurde auch festgestellt, dass das Setzen oder Nichtsetzen der Sperrbits keine Rolle spielt, ob das Ticket funktioniert oder nicht. Die einzige Ausnahme ist das Sperrbit der OTP-Zone, das das Drehkreuz anscheinend immer überprüft, obwohl es nicht in die OTP schreibt. Später nahm ich die U-Bahn- und Bus-Terminals, ordnete sie, studierte und startete am Stand. Um die nächste Vermutung zu überprüfen, war es nun nicht mehr erforderlich, mit dem neu gebackenen Mutanten-Ticket in der U-Bahn zu rennen, und es wurde möglich, sie zu überprüfen, "ohne die Kasse zu verlassen". Außerdem war das U-Bahn-Terminal genauso alt (alles andere ist fehlerhaft) wie meine Schlüssel. So konnte ich "in Arbeit" und andere Arten von "Ultralight" -Tickets ausprobieren - etwas, das ich in der U-Bahn niemals "live" machen kann. Parallel zu diesen Experimenten beschäftigte ich mich weiterhin mit Software.

Da es viele Kontroversen darüber gab, welche Art von Algorithmus für die Berechnung des „Hash“ verwendet wird, habe ich mich entschlossen, ihn vollständig wiederherzustellen, indem ich den Algorithmus in der „menschlichen“ Programmiersprache von Grund auf neu geschrieben habe. Ich hatte nur gehofft zu verstehen, um welche Art von Algorithmus es sich handelt. etwas Bekanntes oder eine Art eigene, innere Entwicklung. Auf dem Weg wurde ich von vielen verschiedenen Gedanken aufgesucht (einschließlich, dass es sich um AES handeln könnte), aber als ich den bereits funktionierenden Code ohne Verwendung von Smart Library-Bibliotheken im Detail studierte, stellte sich heraus, dass dieser Algorithmus „nur“ GOST ist - ein inländischer Verschlüsselungsstandard (alle erforderlichen Informationen) über ihn kann man leicht im web finden). Insbesondere wurde der 16-W-Zyklus verwendet, um den Hash zu berechnen. "Hash" ist in der Tat nichts anderes als eine Imitation von GOST.

Die Struktur der auf dem Ticket "Ultralight" aufgezeichneten Informationen

Auf welcher Seite, wo und wie befinden sich die Hardware-Seriennummer, die Sperrbits und die OTP-Zone? Lesen Sie die Originaldokumentation (eine PDF-Spezifikationsdatei mit einer vollständigen Chipbeschreibung befindet sich auf der Festplatte). Ich empfehle, daraus zu lernen. Ich werde die Struktur des Speicherorts der von den U-Bahn-Systemen generierten Daten im Benutzerbereich beschreiben, der zum Lesen und Umschreiben zur Verfügung steht (natürlich ohne Sperren). Der gesamte Inhalt des Tickets kann in den Header-Teil und die beiden vollständig duplizierten Teile der Daten unterteilt werden (dies dient der Reservierung und dem Schutz vor Fehlern). Der Titelteil der Tickets "Ultralight" beginnt auf Seite 4. Ein Teil davon ist in allen Tickets und Kennungen des Metropolitan-Systems und von MosGoTrans gleich aufgebaut. Die ersten 10 Bits sind die Anwendungskennung. Die nächsten 10 Bits sind die Kartentyp-ID (welche IDs dies sein können, können Sie zu diesem Zweck in einer anderen speziellen Box lesen). Nachdem die Kennung gefunden wurde, erscheint die Seriennummer des Tickets (sie ist auf der Rückseite des Tickets abgestempelt, verwechseln Sie sie nicht mit der Hardware - das sind zwei verschiedene Dinge!) Mit einer Größe von 32 Bit. Die letzten 4 Bits sind das Feld Layout, in dem das System die Interpretation der nachfolgenden Daten festlegt (so etwas wie ein Dateiformat).

Für Ultralight-Tickets beträgt der Layout-Wert 0x08. Gleichzeitig endet der Titelteil. Außerdem gibt das Ticket "Ultralight" das Datum an, an dem das Formular gültig ist (16 Bit). Alle Daten im System werden im Format der Anzahl der Tage seit dem 1. Januar 1992 angegeben. Hier endet der Kopfteil des „Ultralight“ -Tickets (bei Tickets mit einem anderen Layout können noch verschiedene Zusatzinformationen erfasst werden). Der erste Datenbereich beginnt auf Seite 8. Zunächst werden 16 Bit des Ticketausstellungsdatums aufgezeichnet. Danach wird die Gültigkeitsdauer des Tickets in Tagen (ab dem Zeitpunkt der Ausstellung) angegeben - 8 Bit Die ersten 16 Bits von Seite 9 sind der Auslösezähler. Sie kann entweder auf null (bei allen Tickets mit einer begrenzten Anzahl von Fahrten) oder von null (bei VESB-Tickets ohne Begrenzung der Anzahl von Fahrten) abnehmen. Nach dem Zähler im Rest der Seite gibt das Drehkreuz bei jedem Durchgang seine eindeutige Kennung ein. Anscheinend wird dies verwendet, um ein erneutes Betreten zu verhindern, ohne auf das VESB-Ticket zu warten (Drehkreuze in der Lobby sind mit dem Netzwerk verbunden und fragen sich gegenseitig ab), und auch um zu sehen, welches Drehkreuz durchlaufen wurde (zum Beispiel im Falle eines Fehlers oder für Statistiken) ). Seite 10 ist vollständig mit einem 32-Bit-Hash belegt.

Seite 11 ist leer. Dieser Datenbereich wird vollständig auf die verbleibenden 4 Seiten (von 12 bis 15) repliziert. Es zeigt sich, dass diese beiden Bereiche im Normalbetrieb immer die gleichen Daten enthalten. Unabhängig davon sollte über die Verwendung der OTP-Zone durch das System gesprochen werden. Es wird für das schrittweise „Ausbrennen“ eines Tickets bei jeder Fahrt verwendet (dies ist bei VESB-Tickets nicht der Fall). Die zwei niedrigsten Bits werden gesetzt, wenn das Ticket storniert oder storniert wird (über die Stoppliste). Ein storniertes Ticket kann nicht wiederhergestellt werden. Es bleiben nur 30 Bits zum Ausbrennen. Diese Zone wird vom System als 100% der Fahrten dargestellt. Bei jeder neuen Fahrt wird eine bestimmte Anzahl von Bits festgelegt (von der jüngsten zur ältesten), die der Anzahl der prozentualen Fahrten entspricht. Zum Beispiel wird für eine Fahrkarte mit 5 Zügen jede neue Fahrt um 6 Bits „ausgebrannt“ und für eine Fahrkarte mit 60 Zügen um ein halbes Bit (aufgerundet). Es ist erwähnenswert, dass die Wiederverwendung von Ultralight-Tickets nicht nur aufgrund des Ausbrennens des OTP unmöglich ist, sondern auch aufgrund der Tatsache, dass an der Kasse beim Ausstellen eines Tickets (und vielleicht sogar wenn es gemacht wird) fast alle Seiten für das Umschreiben gesperrt sind. . Daher funktioniert weder das „Nachladen“ noch das Ändern des Tickettyps durch einen anderen nicht.

Beispiele für verwendete Metroticket-IDs

Alle Zahlen sind in Dezimalschreibweise!

Anwendungs-IDs:

  • 262 - Moskauer U-Bahn-Ticket.
  • 264 - Moskauer Bodentransportticket.
  • 266 - Einheitliches Soziales von Moskau und der Region Moskau.
  • 270 - Ticket "Einfache Metro".

Kennungen der Ticketart "Ultralight":

  • 120 - Eine Fahrt.
  • 121 - Zwei Reisen.
  • 126 - Fünf Reisen.
  • 127 - Zehn Fahrten.
  • 128 - Zwanzig Fahrten.
  • 129 - Sechzig Reisen.
  • 130 - Gepäck + Passage.
  • 131 - Nur Gepäck.
  • 149 - Single "Ultralight" (70 Fahrten).
  • 150 - VESB.

Mifare Klassiker

Ich habe den unglückseligen Mifare Classic 1K bei meinen Nachforschungen nicht ignoriert. Wie Sie verstehen, waren die Hauptschlüssel der „Klassiker“ die Hardwareschlüssel A und B. Glücklicherweise befanden sich diese Schlüssel in einem der Module des Programms in offener Form (den Entwicklern vorgezogen!), Und es fiel mir nicht schwer, ein kleines Programm für dieses zu schreiben Arbeiten Sie mit dem Inhalt dieser Karten mit den erhaltenen Schlüsseln. Im Verlauf der Experimente wurden einige interessante Merkmale aufgedeckt, wie zum Beispiel: Die U-Bahn zum Speichern des Tickets verwendet den ersten Sektor der Karte und den Bodentransport - den vierten; Auf diesen Tickets gibt es keinen Schutz, mit Ausnahme von Hardwareschlüsseln (die in Software in dieser Form aufgezeichnet wurden und sich wahrscheinlich seit der Inbetriebnahme des Systems nie geändert haben).

Stattdessen wird CRC-16 am Ende jedes Blocks angezeigt, um Daten einfach vor Beschädigung zu schützen. Zusätzlich werden auf Social Cards neben Tickets auch viele verschiedene und interessante Informationen aufgezeichnet. Beispielsweise werden im 13. und 14. Sektor der Sozialkarten der Name, der Name und das Patronym des Inhabers angegeben. Diese (und einige andere) Daten können mit dem öffentlichen Schlüssel 0xA0A1A2A3A4A5 gelesen werden. Während der Experimente war es möglich, das Studenten-SCM sowie mehrere Tickets für die Net Classic-Karten vollständig zu klonen.

Aber wie sich herausstellte, spart das Stopplistensystem das Klonen perfekt - ein solches Ticket kann nicht länger als zwei Tage verwendet werden, dann wird es storniert (obwohl die Classic-Karte im Gegensatz zu Ultralit nach der Stornierung wiederhergestellt werden kann, aber von der Stoppliste es wird nicht gespeichert). Da für Classic-Karten kein Schutz verwendet wurde, wurden sie für mich schnell uninteressant, und ich beschloss, mich auf die Erforschung von Ultralight zu konzentrieren.

Das Ende, oder um es zusammenzufassen

Die U-Bahn-Systeme und insbesondere die neuen Ultralight-Tickets erwiesen sich entgegen Meinungen und Vermutungen als gut geschützt. Sehr erfreut, dass die Entwickler zuverlässiges und erprobtes GOST verwendet haben und das Rad nicht neu erfunden haben. Mit einem solchen Schutz ist es einfach unmöglich, das Ultralight-Ticket zu fälschen, ohne Zugang zu vertraulichen Daten (Schlüsselinformationen) zu haben. Das Schlüsselsystem und der Stopplistenmechanismus sind ebenfalls gut durchdacht. Natürlich nicht ohne Mängel und Irrtümer. Die größte davon ist Software, die überhaupt nicht geschützt ist.

Es reichte aus, auf die Verwendung von Runtime-BPL zu verzichten, und dies würde die Analyse Dutzende Male erschweren! Alternativ würde die Verarbeitung besonders wichtiger Programmteile durch AsProtect oder ExeCryptor, gefolgt vom Packen aller Dateien mit MoleBox, die Analysemöglichkeit auf nahezu Null reduzieren. Das Toolkit ist kostengünstig. Und die Verwendung eines guten (vorzugsweise wenig bekannten oder auf Bestellung hergestellten) Schutzes dieser Art, jedoch mit Hardwareschlüsseln, würde die Analyse des Programms vollständig unmöglich machen. Natürlich ist der Metropolitan ein Regime-Unternehmen, aber man sollte den menschlichen Faktor nicht vergessen. Immerhin sagte Kevin Mitnick (und sprach nicht nur, sondern demonstrierte auch am Beispiel, für das er gesessen hat), dass es manchmal einfacher und effektiver ist, „Social Engineering“ zu verwenden, um das Ziel zu erreichen, als zu versuchen, die undurchdringliche Verteidigung zu durchbrechen. In diesem Sinne werde ich meine Geschichte beenden. Und Ihnen, dem Leser, wünsche ich weitere interessante und erfolgreiche Recherchen!








Beschreibung des kryptographischen Transformationsalgorithmus nach GOST 28147-89

Diese Norm legt einen einheitlichen Algorithmus für die kryptographische Transformation von Informationsverarbeitungssystemen in Netzwerken von elektronischen Computern (Computern), einzelnen Computerkomplexen und Computern fest, der die Regeln für die Datenverschlüsselung und die Generierung von Imitationen festlegt.

Der Algorithmus der kryptografischen Transformation ist für die Hardware- oder Softwareimplementierung vorgesehen, erfüllt die kryptografischen Anforderungen und unterliegt in seinen Funktionen keinen Einschränkungen hinsichtlich des Geheimhaltungsgrades der geschützten Informationen.

Der Standard ist verpflichtend für Organisationen, Unternehmen und Institutionen, die den kryptografischen Schutz von Daten verwenden, die in Computernetzwerken, in separaten Computersystemen oder in Computern gespeichert und übertragen werden.

Strukturschema der kryptographischen Transformation

Das Blockdiagramm des in Abbildung 1 gezeigten Algorithmus zur kryptografischen Transformation (Kryptoschema) enthält:

  • - Schlüsselspeicher (256 Bit), bestehend aus acht 32-Bit-Laufwerken (X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 );
  • - vier 32-Bit-Laufwerke (N 1 , N 2 , N 3 , N 4 );
  • - zwei 32-Bit-Laufwerke (N 5 , N 6 ) mit darin aufgezeichneten Füllkonstanten С 2 , С 1 ;
  • - zwei 32-Bit-Addierer modulo 2 32 (CM 1 , CM 3 );
  • - 32-Bit-Addierer von bitweisem Summenmodul 2 (CM 2 );
  • - 32-Bit-Modulo-Addierer (2 32 -1) (CM 4 );
  • - Addierer Modulo 2 (CM 5 ), die Begrenzung der Breite des Addierers CM 5 wird nicht auferlegt;
  • - Substitutionseinheit (K);
  • - das zyklische Schieberegister für elf Schritte in Richtung der übergeordneten Ziffer (R).

Abbildung 1.

Der Ersetzungsblock K besteht aus acht Ersetzungsknoten K 1 , K 2 , K 3 , K 4 , K 5 , K 6 , K 7 , K 8 mit jeweils 64-Bit-Speicher. Der am Substitutionsblock ankommende 32-Bit-Vektor wird in acht aufeinanderfolgende 4-Bit-Vektoren unterteilt, von denen jeder durch den entsprechenden Ersetzungsknoten in einen 4-Bit-Vektor umgewandelt wird, der eine Tabelle von sechzehn Zeilen ist, die vier Füllbits in einer Zeile enthält. Der Eingabevektor bestimmt die Adresse der Zeile in der Tabelle, das Ausfüllen dieser Zeile ist der ausgehende Vektor. Dann werden die 4-Bit-Ausgangsvektoren sequentiell zu einem 32-Bit-Vektor kombiniert.

Bei der Addition und zyklischen Verschiebung von Binärvektoren werden die höchsten Stellen als Bits von Laufwerken mit großen Zahlen betrachtet.

Beim Schreiben des Schlüssels (W 1 , W 2 , ..., W 256 ), W q ≤ {0,1}, q = i ≤ 256, KZU wird der Wert von W 1 in das erste Bit von Laufwerk X 0 eingegeben, und der Wert von W 2 wird eingegeben in der 2. Stelle des Laufwerks X 0 , ... wird der Wert W 32 in die 32. Stelle des Laufwerks X 0 eingetragen ; der Wert von W 33 wird in die 1. Stelle von Laufwerk X 1 eingegeben, der Wert von W 34 wird in die 2. Stelle von Laufwerk X 1 eingegeben, ... der Wert von W 64 wird in die 32. Stelle von Laufwerk X 1 eingegeben; der Wert von W 65 wird in das 1. Bit des Laufwerks X 2 usw. eingegeben, der Wert von W 256 wird in das 32. Bit des Laufwerks X 7 eingegeben.

Beim Überschreiben von Informationen wird der Inhalt der p-ten Ziffer eines Laufwerks (Addierers) in die p-te Ziffer eines anderen Laufwerks (Addierers) überschrieben.

Die Werte für die konstante Befüllung mit 1 (konstantem) Antrieb N 6 sind in Tabelle 1 angegeben.

Tabelle 1

Antriebsentladung N 6

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Antriebsentladung N 6

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

Die Werte für die konstante Befüllung mit 2 (konstantem) Antrieb N 5 sind in Tabelle 2 angegeben.

Tabelle 2

Antriebsentladung N 5

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Antriebsentladung N 5

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Die Schlüssel, die die Belegung der CZU- und K-Substitutionsblocktabellen bestimmen, sind geheime Elemente und werden auf die vorgeschriebene Weise geliefert.

Das Füllen der Tabellen des K-Substitutionsblocks ist ein langfristiges Schlüsselelement, das dem Computernetzwerk gemeinsam ist.

Die Organisation verschiedener Kommunikationsarten wird durch den Aufbau eines geeigneten Schlüsselsystems erreicht. In diesem Fall ist es möglich, die Möglichkeit zu nutzen, Schlüssel im einfachen Ersetzungsmodus zu generieren (eine KZU auszufüllen) und sie im einfachen Ersetzungsmodus zu verschlüsseln, um einen Imitationsschutz für die Übertragung über Kommunikationskanäle oder die Speicherung im Computerspeicher bereitzustellen.

Das Kryptoschema bietet vier Arten von Arbeit:

  • - Verschlüsselung (Entschlüsselung) von Daten im einfachen Ersetzungsmodus;
  • - Verschlüsselung (Entschlüsselung) von Daten im Gamming-Modus;
  • - Verschlüsselung (Entschlüsselung) von Daten beim Spielen mit Rückmeldung;
  • - Produktionsweise

Einfache Ersatzverschlüsselung

Verschlüsseln Sie offene Daten im Easy-Swap-Modus

Ein kryptografisches Schema, das einen Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus implementiert, sollte die in Abbildung 2 gezeigte Form haben.


Abbildung 2

Offene Daten, die verschlüsselt werden sollen, werden in Blöcke von jeweils 64 Bit unterteilt. Geben Sie einen beliebigen Block T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) ein Die Laufwerke N 1 und N 2 werden so erzeugt, dass der Wert von a 1 (0) in die erste Ziffer von N 1 , der Wert von a 2 (0) in die zweite Ziffer von N 1 usw., der Wert von a 32 ( 0) wird in die 32. Kategorie von N 1 eingetragen ; Der Wert von b 1 (0) wird in die erste Ziffer von N 2 eingegeben, der Wert von b 2 (0) wird in die zweite Ziffer von N 2 eingegeben, usw. Der Wert von b 32 (0) wird in die 32. Ziffer von N 2 eingegeben. Das Ergebnis ist der Zustand (a 32 (0), a 31 (0), ..., a 2 (0), a 1 (0)) Laufwerk N 1 und der Zustand (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) des Laufwerks N 2 .

In der KZU geben Sie 256 Bit des Schlüssels ein. Der Inhalt von acht 32-Bit-Laufwerken X 0 , X 1 , ..., X 7 hat die Form:

  • X 0 = (W 32 , W 31 , ..., W 2 , W 1 )
  • X 1 = (W 64 , W 63 , ..., W 34 , W 33 )
  • . . . . . . . . . . . . .
  • X 7 = (W 256 , W 255 , ..., W 226 , W 225 )

Der 64-Bit-Verschlüsselungsalgorithmus für offene Daten im einfachen Ersetzungsmodus besteht aus 32 Zyklen.

Im ersten Zyklus wird die Anfangsfüllung des Akkumulators N 1 mit der Füllung des Akkumulators X 0 modulo 2 32 im Addierer CM 1 aufsummiert, während die Füllung des Akkumulators N 1 erhalten bleibt.

Das Ergebnis der Summation wird im Substitutionsblock K transformiert und der resultierende Vektor dem Eingang des Registers R zugeführt, wo er sich zyklisch um elf Schritte in Richtung der höheren Stellen verschiebt. Das Ergebnis der Verschiebung wird im CM 2 -Addierer mit 32-Bit-Füllung des N 2 -Akkumulators bitweise modulo 2 summiert. Das in CM 2 erhaltene Ergebnis wird in N 1 aufgezeichnet, während der alte Wert von N 1 in N 2 umgeschrieben wird. Der erste Zyklus endet.

Nachfolgende Zyklen werden ähnlich ausgeführt, während im zweiten Zyklus die Füllung von X 1 aus dem CPC gelesen wird, im dritten Zyklus die Füllung von X 2 aus dem CPC gelesen wird und im achten Zyklus die Füllung von X 7 aus dem CPC gelesen wird. In den Zyklen vom 9. bis zum 16. sowie in den Zyklen vom 17. bis zum 24. wird der CPC in der gleichen Reihenfolge gelesen: X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 .

In den letzten acht Zyklen vom 25. bis zum 32. Lesereihenfolge werden die Füllungen der KZU umgekehrt: X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Daher wird beim Verschlüsseln in 32 Zyklen die folgende Reihenfolge zum Auswählen von Laufwerksfüllungen ausgeführt:

  • X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 , X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 ,
  • X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 , X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Im 32. Zyklus wird das Ergebnis des Addierers CM 2 in den Akkumulator N 2 eingegeben, und im Akkumulator N 1 bleibt die alte Füllung erhalten.

Nach dem 32. Verschlüsselungszyklus des Füllens der Laufwerke N1 und N2 wird ein Block verschlüsselter Daten erhalten, der einem Block offener Daten entspricht.

Entschlüsseln verschlüsselter Daten im einfachen Ersetzungsmodus

Ein kryptografisches Schema, das einen Entschlüsselungsalgorithmus im einfachen Ersetzungsmodus implementiert, hat dieselbe Form (siehe Abbildung 2) wie während der Verschlüsselung. Geben Sie in der KZU 256 Bits desselben Schlüssels ein, mit dem die Verschlüsselung durchgeführt wurde. Die zu entschlüsselnden verschlüsselten Daten werden in Blöcke von jeweils 64 Bit aufgeteilt. Geben Sie einen beliebigen Block T W = (a 1 (32) und 2 (32), ... und 32 (32), b 1 (32), b 2 (32), ..., b 32 (32)) in Laufwerke N ein 1 und N 2 wird so gemacht, dass der Wert von a 1 (32) in die erste Ziffer von N 1 , der Wert von a 2 (32) in die zweite Ziffer von N 1 usw., der Wert von a 32 (32) eingegeben wird. ist in der 32. Kategorie von N 1 eingetragen ; Der Wert von b 1 (32) wird in die erste Ziffer von N 2 eingegeben, der Wert von b 2 (32) wird in die zweite Ziffer von N 2 eingegeben, usw. Der Wert von b 32 (32) wird in die 32. Ziffer von N 2 eingegeben.

Die Entschlüsselung erfolgt nach demselben Algorithmus wie die Verschlüsselung offener Daten, mit der Änderung, dass die Füllungen der Laufwerke X 0 , X 1 , ..., X 7 in den Entschlüsselungszyklen in der folgenden Reihenfolge aus dem Speicher gelesen werden:

  • X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 , X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 ,
  • X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 , X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Erhalten nach 32 Arbeitszyklen des Befüllens bilden die Laufwerke N 1 und N 2 einen Block offener Daten.

T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)), entsprechend einem Block verschlüsselter Daten, der Wert von a 1 (0) des Blocks T 0 entspricht dem Inhalt der ersten Ziffer N 1 , der Wert von a 2 (0) entspricht dem Inhalt der zweiten Ziffer N 1 usw., der Wert von a 32 (0) entspricht dem Inhalt 32 n Entladungsnummer 1 ; der Wert von b 1 (0) entspricht dem Inhalt der ersten Ziffer von N 2 , der Wert von b 2 (0) entspricht dem Inhalt der zweiten Ziffer von N 2 usw., der Wert von b 32 (0) entspricht dem Inhalt der 32. Ziffer von N 2 .

In ähnlicher Weise werden die verbleibenden Blöcke verschlüsselter Daten entschlüsselt.

Gamma-Modus

Verschlüsseln Sie offene Daten im Gamming-Modus

Das Kryptoschema, das den Verschlüsselungsalgorithmus für den Spielmodus implementiert, sollte die in Abbildung 3 gezeigte Form haben.


Abbildung 3

Offene Daten, die in 64-Bit-Blöcke T 0(1) , T 0(2) , ..., T 0(M - 1) , T 0(M) unterteilt sind , werden im Gamma-Modus durch bitweises Modulieren im CM-Addierer verschlüsselt 5 mit dem Gamut der Chiffre Г ш , die in Blöcken von 64 Bits erzeugt wird, d.h.

Г ш = (Г ш(1) , Г ш(2) , ..., Г ш(М-1) , Г ш(М) ),

wobei M - durch die Menge der verschlüsselten Daten bestimmt wird.

Г ш(i) ist der i-te 64-Bit-Block, i = 1 ÷ Ì, die Anzahl der Binärziffern im T 0(M) -Block kann kleiner als 64 sein, während der Teil der Chiffre aus dem G-Block (M) nicht für die Verschlüsselung verwendet wird verworfen.

In der KZU geben Sie 256 Bit des Schlüssels ein. In die Akkumulatoren N 1 , N 2 wird eine 64-Bit-Binärsequenz (Synchro-Send) S = (S 1 , S 2 , ..., S 64 ) eingeführt, die das anfängliche Füllen dieser Laufwerke für die nachfolgende Erzeugung von M Chiffrier-Gammablöcken darstellt. Das Synchronsenden wird in N 1 und N 2 eingegeben, so dass der Wert von S 1 in die erste Ziffer von N 1 eingegeben wird, der Wert von S 2 in die zweite Ziffer von N 1 eingegeben wird usw., der Wert von S 32 wird in die 32. Ziffer eingegeben N 1 ; Der Wert von S33 wird in die erste Ziffer von N2 eingegeben, der Wert von S34 wird in die zweite Ziffer von N2 eingegeben, usw. Der Wert von S64 wird in die 32. Ziffer von N2 eingegeben.

Das anfängliche Befüllen der Laufwerke N 1 und N 2 (Synchrophase S) wird im einfachen Austauschmodus gemäß den Anforderungen in Absatz 1.3.1 verschlüsselt. Das Ergebnis der Verschlüsselung wird in den 32-Bit-Laufwerken N3 und N4 neu geschrieben, so dass die Füllung N1 in N3 und die Füllung N2 in N4 neu geschrieben wird.

Die Füllung des N 4 -Akkumulators wird im CM 4 -Addierer modulo (2 32 -1) mit der 32-Bit-Konstante С 1 aus dem N 6 -Akkumulator aufsummiert, das Ergebnis wird in N 4 geschrieben .

Die Füllung des Antriebs N 3 wird im CM 3 -Addierer modulo 2 32 mit der 32-Bit-Konstante С 2 aus dem Antrieb N 5 aufsummiert, das Ergebnis wird in N 3 geschrieben .

Das Füllen von N 3 wird in N 1 umgeschrieben, und das Füllen von N 4 wird in N 2 umgeschrieben, während das Füllen von N 3 , N 4 beibehalten wird.

Das Füllen von N 1 und N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 , N 2 bildet den ersten 64-Bit-Block des Chiffriercodes G W(1) , der im Addierer CM 5 mit dem ersten offenen 64-Bit-Datenblock T 0(1) = (t bitweise modulo 2 summiert wird 1(1) , t 2(1) , ..., t 63(1) , t 64(1) ). Als Ergebnis der Summierung wird ein 64-Bit-Block verschlüsselter Daten erhalten: T w(1) = (& tgr; 1(1) , & tgr; 2(1) , ..., & tgr; 63(1) , & tgr;64(1) ).

Der Wert τ 1(1) des Blocks T ш(1) ist das Ergebnis der Addition von Modulo 2 in CM 5 des Werts von t 1(1) aus dem Block T 0(1) mit dem Wert der ersten Ziffer N 1 , dem Wert τ 2(1) des Blocks TW(1) ist das Ergebnis der Summe modulo 2 in CM 5 t 2(1) aus Block T 0(1) mit dem Wert der 2. Kategorie N 1 usw., dem Wert τ 64(1) aus Block T w(1) ist das Ergebnis einer Modulo-2-Summation in CM 5 des Wertes von t 64(1) aus dem Block T 0(1) mit dem Wert der 32. Ziffer N 2 .

Für den nächsten 64-Bit-Gamma-Block der Chiffre G w(2) wird die Füllung von N 4 im Addierer CM 4 mit der Konstante C 1 von N 6 modulo (2 32 -1) summiert, die Füllung in N 3 wird im Addierer CM 3 modulo 2 32 summiert mit einer Konstante C 2 von N 5 . Die neue Füllung von N 3 wird in N 1 umgeschrieben, und die neue Füllung von N 4 wird in N 2 umgeschrieben, während die Füllung von N 3 und N 4 erhalten bleibt.

Das Füllen von N 1 und N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 , N 2 bildet den zweiten 64-Bit-Block des Chiffriercodes G W(2) , der im Addierer CM 5 mit dem zweiten offenen Datenblock T 0(2) bitweise modulo 2 summiert wird. In ähnlicher Weise werden Blöcke der Gamma-Chiffre Gw(3) , Gw(4) ..., Gw(M) erzeugt und die offenen Datenblöcke T 0(3) , T 0(4) ..., T 0(M) werden verschlüsselt. Wenn die Länge des letzten M-ten Blocks offener Daten T 0(M) kleiner als 64 Bits ist, werden von dem letzten M-ten Block der Gamma-Chiffre G W(M) nur die entsprechende Anzahl von Gamma-Chiffre-Bits zur Verschlüsselung verwendet, die verbleibenden Bits werden verworfen.

Synchrones Senden S und Blöcke verschlüsselter Daten TW(1) , TW(2) ..., TW(M) werden an den Kommunikationskanal oder den Computerspeicher übertragen.

Entschlüsseln Sie verschlüsselte Daten im Gamming-Modus

Beim Entschlüsseln ist ein Kryptoschema dasselbe wie beim Verschlüsseln (siehe Abbildung 3). In der KZU sind 256 Bit des Schlüssels eingetragen, mit denen die Daten T 0(1) , T 0(2) ..., T 0(M) verschlüsselt wurden, während T 0(M) weniger als 64 Bit enthalten kann.

Gammamodus mit Rückmeldung

Verschlüsselung offener Daten beim Spielen mit Rückmeldung

Ein Kryptoschema, das den Gamming-Modus mit Rückmeldung implementiert, sollte die Form haben in Abbildung 4 gezeigt.


Abbildung 4

Offene Daten, die in 64-Bit-Blöcke T 0(1) , ..., T 0(M) unterteilt sind , werden im Gamming-Modus mit Rückkopplung durch ein bitweises Modulationsmodul 2 im CM 5- Addierer mit einer Skala von Chiffren G W verschlüsselt, die in Blöcken von erzeugt wird 64 Bits, d.h. Г ш = (Г ш(1) , Г ш(2) , ..., Г ш(М) ), wobei M - durch die Menge der verschlüsselten Daten bestimmt wird, Г ш(i) der i-te 64-Bit-Block ist, i = 1 ÷ ÷. Die Anzahl der Binärziffern im Block T 0(M) kann kleiner als 64 sein.

In der KZU geben Sie 256 Bit des Schlüssels ein. In die Akkumulatoren N 1 , N 2 wird eine 64-Bit-Binärsequenz (Synchro-Send) S = (S 1 , S 2 , ..., S 64 ) eingegeben. Das Synchronsenden wird in N 1 und N 2 eingegeben, so dass der Wert von S 1 in die erste Ziffer von N 1 eingegeben wird, der Wert von S 2 in die zweite Ziffer von N 1 eingegeben wird usw., der Wert von S 32 wird in die 32. Ziffer eingegeben N 1 ; Der Wert von S33 wird in die erste Ziffer von N2 eingegeben, der Wert von S34 wird in die zweite Ziffer von N2 eingegeben, usw. Der Wert von S64 wird in die 32. Ziffer von N2 eingegeben.

Die ursprüngliche Befüllung der Laufwerke N 1 und N 2 wird im einfachen Austauschmodus gemäß den Anforderungen in Abschnitt 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 und N 2 bildet den ersten 64-Bit-Block der Gamma-Chiffre G W(1) , der im Addierer CM 5 mit dem ersten offenen 64-Bit-Datenblock T 0(1) = (t bitweise modulo 2 summiert wird 1(1) , t 2(1) , ..., t 63(1) , t 64(1) ).

Als Ergebnis der Summierung wird ein 64-Bit-Block verschlüsselter Daten erhalten: T w(1) = (& tgr; 1(1) , & tgr; 2(1) , ..., & tgr; 63(1) , & tgr;64(1) ).

Der Block der verschlüsselten Daten T b(1) ist auch der Anfangszustand N 1 , N 2 zum Erzeugen des zweiten Blocks der Chiffre G (2) und wird durch Rückkopplung auf die angegebenen Laufwerke geschrieben. Der Wert & tgr; 1(1) wird in die erste Ziffer N 1 eingegeben, der Wert & tgr; 2(1) wird in die zweite Ziffer N 1 eingegeben usw., der Wert & tgr; 32(1) wird in die 32. Ziffer N eingegeben 1 ; Der Wert von & tgr; 33(1) wird in die erste Stelle von N 2 eingegeben, der Wert von & tgr; 34(1) wird in die zweite Stelle von N 2 eingegeben, usw. Der Wert von & tgr;64(1) wird in die 32. Stelle von N 2 eingegeben.

Das Füllen von N 1 , N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 , N 2 bildet den zweiten 64-Bit-Block des Chiffriercodes G W(2) , der im Addierer CM 5 mit dem zweiten offenen Datenblock T 0(2) bitweise modulo 2 summiert wird.

Die Entwicklung nachfolgender Blöcke der Gamma-Chiffre G W(i) und die Verschlüsselung der entsprechenden offenen Datenblöcke T 0(i) (i = 3 ÷) ist ähnlich. Wenn die Länge des letzten M-ten Blocks offener Daten T 0(M) kleiner als 64 Bits ist, dann wird von G число(M) nur die entsprechende Anzahl von Bits des Chiffrier-Gammas verwendet, die verbleibenden Bits werden verworfen.

Synchrones Senden S und Blöcke verschlüsselter Daten TW(1) , TW(2) ..., TW(M) werden an den Kommunikationskanal oder den Computerspeicher übertragen.

Entschlüsselung verschlüsselter Daten im Gamming-Modus mit Rückmeldung

Beim Entschlüsseln ist das Kryptoschema dasselbe wie beim Verschlüsseln (siehe Abbildung 4). In der KZU sind 256 Bits desselben Schlüssels eingetragen, auf denen T 0(1) , T 0(2) ..., T 0(M) verschlüsselt wurden. Das Synchronsenden wird in N 1 , N 2 eingegeben, so dass der Wert von S 1 in die erste Stelle von N 1 eingegeben wird, der Wert von S 2 in die zweite Stelle von N 1 eingegeben wird usw., der Wert von S 32 wird in die 32. Stelle eingegeben N 1 ; Der Wert von S33 wird in die erste Ziffer von N2 eingegeben, der Wert von S34 wird in die zweite Ziffer von N2 eingegeben, usw. Der Wert von S64 wird in die 32. Ziffer von N2 eingegeben.

Das anfängliche Befüllen der Laufwerke N 1 und N 2 (Synchrophase S) wird im einfachen Austauschmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die aus der Verschlüsselung resultierende N 1 , N 2 -Codierung bildet den ersten 64-Bit-Block des Chiffriercodes G W(1) , der im CM 5- Addierer mit dem verschlüsselten Datenblock T W(1) bitweise modulo 2 summiert wird. Das Ergebnis ist der erste Block offener Daten T 0(1) .

Der Block von verschlüsselten Daten T (1) ist das anfängliche Füllen von N 1 , N 2 , um den zweiten Block der Gamma-Chiffre G 3 (2) zu erzeugen. Der Block TW(1) ist in N & sub1 ;, N & sub2; geschrieben. Der Wert & tgr; 1(1) wird in die erste Ziffer N 1 eingegeben, der Wert & tgr; 2(1) wird in die zweite Ziffer N 1 eingegeben usw., der Wert & tgr; 32(1) wird in die 32. Ziffer N eingegeben 1 ; Der Wert von & tgr; 33(1) wird in die erste Stelle von N 2 eingegeben, der Wert von & tgr; 34(1) wird in die zweite Stelle von N 2 eingegeben, usw. Der Wert von & tgr;64(1) wird in die 32. Stelle von N 2 eingegeben. Die resultierende Füllung N 1 , N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt, der resultierende Block G W(2) wird im CM 5- Addierer mit dem zweiten Block verschlüsselter Daten T W(2) bitweise modulo 2 summiert. Das Ergebnis ist ein Block offener Daten T 0(2) .

In ähnlicher Weise werden in N 1 , N 2 die Blöcke der verschlüsselten Daten T ((2) , T ((3) ..., T (M-1) sequentiell aufgezeichnet, aus denen im einfachen Ersetzungsmodus Gammablöcke der Chiffre G ((3) , D erzeugt werden w(4) , ..., G w(M) . Die Cipher-Gamma-Blöcke werden im CM 5- Addierer bitweise modulo 2 mit den verschlüsselten Datenblöcken T m(3) , T m(4) ..., T m(M) summiert, was zu offenen Datenblöcken T 0(3) , T 0( 4) , ..., T 0(M) , während die Länge des letzten Blocks offener Daten T 0(M) weniger als 64 Bits enthalten kann.

Produktionsweise

Um einen Nachahmungsschutz für offene Daten bereitzustellen, die aus M 64-Bit-Blöcken T 0(1) , T 0(2) , ..., T 0(M) , M ≥ 2 bestehen, wird ein zusätzlicher Block von 1 Bits erzeugt ( und die Einfügung I 1). Das Generieren einer Imitation ist für alle Verschlüsselungsmodi einheitlich.

Der erste Block offener Daten T 0(1) = (t 1(1) , t 2(1) , ..., t 64(1) ) = (a 1(1) (0), a 2(1) (0) a 32(1) (0), b 1(1) (0), b 2(1) (0), ..., b 32(1) (0) in den Laufwerken N 1 und N 2 aufgezeichnet ist, der Wert von t 1(1) = a 1(1) (0) wird in die erste Ziffer von N 1 eingegeben, der Wert von t 2(1) = a 2(1) (0) wird in die zweite Ziffer von N 1 eingegeben, usw. wird der Wert t 32(1) = a 32(1) (0) in die 32. Stelle von N 1 eingegeben; Der Wert von t 33(1) = b 1(1) (0) wird in die erste Ziffer von N 2 usw. eingegeben, der Wert von t 34(1) = b 32(1) (0) wird in die 32. Ziffer eingegeben N 2 .

Das Füllen von N 1 und N 2 wird gemäß den Anforderungen von Abschnitt 3.1 einer Transformation unterzogen, die den ersten 16 Zyklen des Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus entspricht. Gleichzeitig gibt es in der KZU den gleichen Schlüssel, mit dem die offenen Datenblöcke T 0(1) , T 0(2) , ..., T 0(M) in die entsprechenden Blöcke der verschlüsselten Daten T ш(1) , T ш(2) verschlüsselt werden. ..., Tw(M) .

Die nach 16 Betriebszyklen erhaltene Füllung mit N 1 und N 2 hat die Form (a 1(1) (16), a 2(1) (16), ..., a 32(1) (16), b 1(1) ( 16), b 2(1) (16), ..., b 32(1) (16)), summiert in CM 5 modulo 2 mit dem zweiten Block T 0(2) = (t 1(2) , t 2( 2) , ..., t 64(2) ). Das Ergebnis der Summierung wird in N 1 und N 2 eingetragen und entsprechend den ersten 16 Zyklen des Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus transformiert.

Die resultierende Füllung von N 1 und N 2 wird in CM 5 modulo 2 mit dem dritten Block T 0(3) usw. summiert, wobei der letzte Block T 0(M) = (t 1(M) , t 2(M) , ... t 64(M) ), gegebenenfalls ergänzt zu einem vollständigen 64-Bit-Block mit Nullen, wird in CM 5 modulo 2 mit der Füllung N 1 , a 1(M-1) (16), a 2(M-1) ( 16), ..., a 32(M-1) (16), b 1(M-1) (16), b 2(M-1) (16), ..., b 32(M-1) (16) . Das Ergebnis der Summierung wird in N 1 , N 2 eingegeben und im einfachen Ersetzungsmodus durch die ersten 16 Zyklen des Algorithmus verschlüsselt. Aus der erhaltenen Füllung der Akkumulatoren N 1 und N 2 wählen wir das Segment AND 1 = [a 32 - 1 +1(M) (16), a 32 - 1 +1(M) (16), ..., a 32(M) (16) )].

Imitovta AND 1 wird über einen Kommunikationskanal oder in den Computerspeicher am Ende der verschlüsselten Daten übertragen, d.h. TW(1) , TW(2) , ..., TW(M) und l .

Empfangene verschlüsselte Daten T w(1) , T w(2) , ..., T w(M) werden entschlüsselt, aus den empfangenen offenen Datenblöcken T 0(1) , T 0(2) , ..., T 0(M) wird die Ausgabe erzeugt Und, das dann mit der Nachahmung UND verglichen wird, wird zusammen mit den verschlüsselten Daten aus dem Kommunikationskanal oder dem Computerspeicher erhalten. Im Falle einer Nichtübereinstimmung der Imitter werden die resultierenden offenen Datenblöcke T 0(1) , T 0(2) , ..., T 0(M) als falsch betrachtet.

Der Wert des Parameters l (die Anzahl der Binärziffern im Simulator) wird durch die gültigen kryptografischen Anforderungen bestimmt, wobei berücksichtigt wird, dass die Wahrscheinlichkeit, falsche Daten aufzuerlegen, 2 - 1 beträgt.