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

Hacking der U-Bahn (Reisen, Karten) + Algorithmus der kristallographischen Transformationen nach GOST 28147-89

Auf der Seite:


Hacking der U-Bahn (Reisen, Karten)

Kennst du den Wunsch, alle Rätsel zu lösen und alle Schutzmaßnahmen der Moskauer Metro aufzudecken? Sich zum Beispiel ein "ewiges Ticket" machen? Aber die Metro-Spezialisten finden immer anspruchsvollere Möglichkeiten, sich zu schützen. Metallmarken wurden durch Plastikkarten ersetzt, jene wiederum durch Magnetkarten, und Magnetkarten wurden durch kontaktlose Karten ersetzt. Viele Forscher ließen ihre Hände fallen - es scheint, dass der Metropolitan eine uneinnehmbare Festung geworden ist. Aber jeder Schutz kann umgangen werden. Und oft ist es viel einfacher, es zu öffnen, als es zu bauen ...

Wie alles begann

Das Interesse an U-Bahn-Systemen schien lange Zeit zu bestehen, ich kann sagen, von einer Schulbank aus, als noch Fahrkarten mit einem Magnetstreifen im Kurs waren. Zur gleichen Zeit (vor einem Dutzend Jahren) wurde eine kontaktlose Sozialkarte für Studenten in Umlauf gebracht. Ich habe mich dafür interessiert, was es ist und wie es funktioniert. Aber damals hatte ich nicht genug Fähigkeiten, und es waren nicht viele Informationen verfügbar, insbesondere über diese Technologien. Ich musste die Idee der Forschung in eine lange Kiste verschieben, aber ich versprach mir, dass ich definitiv zurückkehren würde ...

Vor etwa drei Jahren habe ich wieder Interesse am U-Bahn-Thema geweckt. Ich habe aktiv magnetische Tickets studiert (es gab eine Menge Informationen über das Thema im Internet) und sogar eine kleine Maschine zusammengebaut, um Duplikate von zwei Köpfen von Tonbandgeräten und einer kleinen Menge Rassypuhi zu machen. Ich habe meine Sozialkarte (schon Studentenausweis) nicht vergessen. Doch nach dem Studium der Dokumentation wurde mir klar, dass das System nahezu uneinnehmbar ist - der MF1S50 Mifare Classic 1K-Chip, auf dessen Grundlage Social-Cards erstellt werden, ist durch zwei 48-Bit-Schlüssel geschützt. Auf Hardwareebene kann es nicht so einfach gehackt werden, und Schlüssel können bis ans Ende des Sonnensystems aussortiert werden. Ja, und die Karteninhaber, die den Klassiker unterstützen, waren damals etwas mehr Geld wert (über Ebay habe ich irgendwie nicht nachgedacht, leider). Das Interesse an magnetischen Tickets kühlte sich schnell ab, und die Sozialkarte musste wieder auf bessere Zeiten verschoben werden.

Treffpunkt: "Ultraleicht"

Tickets "Ultralight" erschienen kürzlich in unserer U-Bahn, stießen aber sofort auf großes Interesse in der Öffentlichkeit. Sie begannen zu hühnern, zu reißen, ein Eisen zu kleben und andere Methoden der thermischen rektalen Kryptanalyse anzuwenden. Ich muss zugeben, der Durst nach Wissen hat mich und raskurochit Paar gemacht. Als Ergebnis ihrer Studien und Recherchen im Internet wurde etabliert - es ist nichts weiter als Mifare Ultralight, eine "leichte" kompatible Version von Mifare Classic. Ein kurzer Überblick über die Dokumentation auf den Chips dieser Norm machte deutlich, dass es keine eingebauten Sicherheitssysteme für diese Karten gibt. Ansonsten griff ich einen Artikel an, in dem der erfolgreiche Bruch eines ähnlichen Transportsystems durch niederländische Studenten beschrieben wurde. Alles zusammen brachte mich zu neuen Forschungen.

Lass uns gehen!

Um zu beginnen, war es natürlich nur notwendig, irgendwo einen Wireless-Kartenleser zu bekommen, der "Ultralight" unterstützt. Es gab zwei Möglichkeiten: entweder sich selbst zusammenzustellen (was sehr viel Zeit in Anspruch nehmen würde) oder ein fertiges Gerät zu kaufen. Bei dem Gedanken an die zweite Option, vor den Preisen vor drei Jahren, bekam ich Gänsehaut. Aber ich habe mich trotzdem entschieden, mir die aktuellen Preise anzuschauen. Und nicht umsonst! Ich war angenehm überrascht zu erfahren, dass Sie ein voll funktionsfähiges Gerät (OmniKey CardMan 5321) kaufen können, das eine Reihe von drahtgebundenen und drahtlosen Karten zu einem attraktiven Preis - 4000 Rubel unterstützt.

Natürlich nicht ein bisschen, aber auf der anderen Seite ist es nicht 10000; Darüber hinaus ermöglichte es der Kauf eines fertigen Readers, sich sofort auf die Recherche von Tickets zu konzentrieren und nicht auf das Design und das Debuggen von Eisen, was sich auf unbestimmte Zeit verzögern ließ. Zusammen mit dem Leser von der gleichen Firma (ISBC) wurde ein sehr bequemes Original-SDK der lokalen Produktion erworben. Er wiederum erlaubte es, keine Energie und Zeit zu verschwenden, um Low-Level zu schreiben und die Arbeit der Software mit dem Leser zu debuggen und sich direkt auf die Tickets zu konzentrieren. So wurde für ein paar Tage der gemütlichen Codierung ein kleines Programm geboren, mit dessen Hilfe es möglich war, die gesamte interne Struktur von "Ultralights" in einer bequemen Form zu beobachten und zu kontrollieren. Dann begann ich Karten zu studieren.

Taube Wand

Im Prozess des Studierens durch meinen Leser hat viele Eintrittskarten übergeben. Einige krempelten meine Ärmel hoch, stiegen aus dem Müll, kauften mir ein paar - schauten zu, was sie aufgeschrieben hatten, dann kamen sie vorbei und schauten wieder. Es waren Tickets fast aller Art, mit Ausnahme der Reise "Ultralight" für 70 Fahrten. In ein paar Wochen habe ich eine große und sortierte Datenbank von Dumps von verschiedenen Tickets und in verschiedenen Staaten gesammelt. Es gab nach jeder Fahrt Dumps vom gleichen Ticket und mehrere Tickets mit aufeinander folgenden U-Bahn-Nummern. In meiner Sammlung wurden sogar ein paar Abbilder von zwei verschiedenen zeitlich befristeten Einzeltickets (eines für 5 Tage, das andere für 30) in einem bestimmten Zeitintervall aufgenommen. Es stellte sich heraus, dass es sehr interessante Exemplare waren und gleichzeitig sehr selten (ich bekam sie aus erster Hand mit einer sofortigen Rückkehr, nur für "gelesen").

In der Tat ist dies fast die einzige Art von "Ultralights", die nicht nur in der Metro, sondern auch im Landverkehr funktioniert. Darüber hinaus ist für diese Art von Tickets keine Beschränkung der Anzahl der Fahrten vorhanden. Danach haben sie mir sehr gut gedient ... All diesen Zoo habe ich für einen Zweck gesammelt - um die Struktur und das Format der Aufzeichnungsdaten auf dem Ticket klar zu definieren. Natürlich waren einige Felder mit bloßem Auge auf einmal sichtbar, andere jedoch nicht. Zum Beispiel habe ich nicht sofort verstanden, wo die Metro-Ticketnummer aufgezeichnet wurde (die, die darauf gedruckt ist). Bewusstsein kam völlig zufällig. Tatsache ist, dass ich (und, wie ich denke, die meisten von uns) beim Betrachten des Hexes dazu benutzt werden, Informationen für Bytes auszurichten und zumindest Bytes zu denken. Es stellte sich heraus, dass dieser Ansatz falsch ist. Wenn Sie sich den Ticket-Dump ansehen, müssen Sie in kleineren Einheiten denken - Tetraden und manchmal Bits. Ich erkannte, dass, als ich schließlich die Ticketnummer sah, sie um 4 Bits in Bezug auf den Anfang des Bytes verschoben wurde und die verbleibenden 4 Bits von der anderen Seite der Nummer mit anderen offiziellen Informationen besetzt wurden. Nach einer Weile wurde das Format für die Aufzeichnung von Daten auf Tickets fast vollständig klar.

Es wurde offensichtlich, wo und wie alle Daten, Zähler, Bezeichner gespeichert sind. Es gab nur ein paar Felder, deren Zweck unklar war, nur weil die Daten in ihnen vom Dump zum Dump gleich waren. Aber darüber die ganze Freude und endete - es wäre töricht, anzunehmen, dass solche Tickets ungeschützt bleiben können. In jedem Dump gab es 32 Bits mit verschiedenen Informationen, die nicht mit dem Rest des Inhalts korrelierten. Ich nahm an, dass dies eine Art Prüfsumme ist, ein "Hash" von Daten, die auf das Ticket geschrieben wurden. Alle Versuche, diese 32 Bits zu schätzen oder zu berechnen, stellten sich als Totalausfall heraus (insbesondere wurde angenommen, dass dies eine Art von CRC32 ist, mit einem Nichtstandardpolynom und Startwert).

Wenn Sie versuchen, mindestens eineinhalb Bits an Informationen innerhalb des Tickets zu ändern, blinkt das Kassenterminal in der U-Bahn mit einem kräftigen Wagenheber "BAD TICKET" und nagelt die letzten Nägel in den Sargdeckel. Natürlich gab es Versuche, das System auf andere Weise zu umgehen, zum Beispiel, indem man versuchte, das Ticket auf eine saubere Eins-zu-eins-Karte zu kopieren (hier leider die Werkserien, die, wie sich herausstellte, auch an der Hash-Erzeugung beteiligt war) oder die um zu verhindern, dass das Drehkreuz den Inhalt des Tickets ändert. Das Verifikationsterminal hat dieses "ewige" Ticket erkannt, aber das Drehkreuz verweigert ... Also habe ich mich an die Wand gelehnt. In dieser großen, starken Betonmauer, über die viele die Angewohnheit haben, von einem Absprung getötet zu werden. Ich habe keine Informationen in den Foren und Foren gefunden, ich habe beschlossen, dass hier mein Studium beendet ist - es gibt keine Wege mehr, und einen fetten Punkt. Wie sich herausstellte, vergeblich ...

Seltsame Bekanntschaft

Der Septemberabend war nicht anders als die anderen. Es war fast Nacht, die Straße war kühl und feucht. Ich saß vor dem Monitor und nippte an einem warmen, leicht süßen grünen Tee. Ich züchtete friedlich ein Brett für mein nächstes Schiff. DipTarce, ein kleiner Bastard, ICQ ... Jemand rief Skype an - abgelenkt! Wieder ICQ, wieder DipTrace - in der Regel ist alles wie gewohnt. Wieder einmal kam das Fenster von ICQ in den Vordergrund - jemand, der mir bisher unbekannt war, schrieb "Hallo". Ich, in keiner Weise zögernd, beantwortete das gleiche. Die folgende Botschaft war ein Wendepunkt in der ganzen Geschichte: "Sie interessieren sich für die U-Bahn, ich habe dort Müll. Wenn ich interessiert bin, lass uns uns treffen, ich werde es dir sagen. " Zuerst war ich etwas verwirrt und beunruhigt (vielleicht eine Scheidung oder ein Setup, und vielleicht wurden sogar "spezielle Dienste" interessiert - Paranoia fordert ihren Tribut), aber dann dachte ich: Warum nicht?

Spezielle Dienste, an denen ich nicht interessiert wäre, und der Boden für die Scheidung, und noch mehr, für die Einrichtung scheint es keine zu geben. Nach einem kurzen Gespräch einigten wir uns darauf, uns am Nachmittag in der Mitte der Halle einer der Moskauer Metrostationen zu treffen. Der Fremde war ein großer, junger Mann mit einer 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: "Auf, halte. Es war sowieso nicht praktisch, vielleicht wird es dir nützlich sein. " Ich sah hinein und sah zwei von Zeitungen übersetzte U-Bahn-Terminals, mehrere chaotisch verstreute weiße Plastikkarten und ein Schwein in der Schachtel. Auf meine Frage, wie viel ich das verdanke (Geld), schüttelte der Mann den Kopf, lächelte und sagte: "Nicht wahr, niemand sollte irgendjemandem irgendetwas antun ... Also, ich muss schon laufen, und mein Zug ist wie mal! Komm, tschüss! ".

Mit diesen Worten floh er, sprang in die bereits geschlossenen Türen des Autos und ging. Und ich, ich gestehe, ging ein wenig in neponyatkah nach Hause. Kontakt von ICQ ich nur für den Fall gelöscht, zur gleichen Zeit Reinigung der Kontaktperson auf dem Server und Reinigung Protokolle (wieder Hallo, Paranoia). Schreiben Sie am Ende noch einmal. Aber er hat mir nie wieder geschrieben ...

Das Phänomen der Software-Leute

Als ich nach Hause kam, zerlegte ich das Paket. Das zweite der Terminals war ein Busvalidator (schwer, Pfannkuchen!); Die Karten waren Mifare Classic 1K (sauber), und die Disc hatte ein einziges Archiv. Nach einer flüchtigen Prüfung des Inhalts stellte sich heraus, dass es sich um eine Software handelt, die an den Kassen der Metro verwendet wird. Nachdem ich das Terminal und den Validator beiseite gelegt hatte, beschloss ich, mich mit interessanter Software auseinanderzusetzen. Ungefähr eine Stunde von dem Chaos, das entpackt wurde, konnte ich dieses Programm auf meinem Computer erstellen und ausführen. Eine weitere Stunde war erforderlich, um seine Struktur zu verstehen. Nach dem Kämmen aller Ini-Dateien (mit freundlicherweise vom Entwickler hinterlassenen Kommentaren) hatte ich bereits eine vollständige Vorstellung davon, was es ist, wie es funktioniert und was es isst. Essen Sie, wie sich herausstellte, mit dem Leser Parsec PR-P08, also, aus Mangel daran, versuchen Sie die Software in Aktion fehlgeschlagen.

Der Entwickler war die Firma "Smartek" - ein bedeutender staatlicher Auftragnehmer, der Systeme dieser Art entwickelt (mehr Details können auf ihrer Website gelesen werden). Das Programm wurde in Delphi unter Verwendung von runtime-bpl'ok geschrieben. Darüber hinaus hatte die Software eine modulare Struktur, und alle Unterprogramme, Klassen und Komponenten befanden sich in separaten DLLs oder bpl'ks mit sprechenden Namen (das war die wichtigste Entwicklerdatei). Nach einer oberflächlichen Analyse der Innenräume der Software habe ich festgestellt, dass erstens Informationen über alle ausgestellten Tickets in eine zentralisierte Datenbank übertragen werden (übrigens Oracle) und zweitens ein bestimmtes Schlüsselverfahren verwendet wird. Das Programm könnte nicht nur in Echtzeit mit der Datenbank kommunizieren. Wir ziehen Schlüsse: Alle Operationen im System können mit einer gewissen Verzögerung stattfinden. Theoretisch gibt uns das einen Vorsprung.

Aber zuerst interessierte ich mich für den Mechanismus der Schlüssel (ich hatte bereits angefangen zu erraten, warum es nötig sein könnte). Also nahm ich den Disassembler auf und machte mich an die Arbeit. Der Mechanismus bestand aus zwei Dateien - CryptKeyRef.dll und keys.d (die einzige "heikle" Datei im gesamten Programm, die im Gegensatz zur Datei mit den Schlüsseln nicht mehr so ​​ähnlich ist). Und ich habe all diese guten Run-bpl'in SmLayout.bpl verwendet. Diese Bibliothek war nur ein Glücksfall für meine Recherche - sie enthielt Klassen für die Arbeit mit der internen Besetzung von Tickets. Da es sich um runtime-bpl handelt, reicht es aus, nur die Exporttabelle zu betrachten, um 60 Prozent davon zu verstehen. Eine genauere Analyse setzt alles an seine Stelle. Erinnern Sie sich, am Anfang des Artikels habe ich gesagt, dass es in der Struktur von "Ultralight" noch ein paar Felder gab, deren Zweck unbegreiflich war?

Eines dieser Felder ist die sogenannte "Layout-Kennung". Tatsächlich sind alle Metro-Tickets aus einem festen Kopfteil und einem variablen Datenstück aufgebaut. Also, dieses Feld "Layout" in der Kopfzeile bestimmt nur, wie und welche Daten sich im Rest des Tickets befinden. Es gibt mehrere solche Layouts (jedes für seinen eigenen Tickettyp) und in SmLayout.bpl entsprach jedes seiner eigenen Klasse (plus der gemeinsamen Elternklasse, die Methoden zum Arbeiten mit dem Header-Teil hatte). Um zu verstehen, welche Felder in jedem Layout dafür verantwortlich sind, war es einfach (selbst wenn man mit den Namen der Methoden im Export sprach!). Nachdem ich das gesamte Layout 8 (das in "Ultralights" verwendet wurde) und die erneute Überprüfung vollständig erhalten habe, hatte ich die richtige Vorstellung über alle Felder in der Ticketstruktur, ich nahm den Schlüsselmechanismus auf. Tatsächlich war er für die Erzeugung des Hashs verantwortlich. Wie der Mechanismus funktioniert, wurde nach dem Studium der Arbeit der Methode, die für die Berechnung des Hashs verantwortlich ist, völlig klar. Zuerst wird der richtige Schlüssel aus der Schlüsseldatei (keys.d) ausgewählt.

Das System ist so angeordnet, dass jeder Tickettyp seine eigene Kennung hat (komplett mit einer Tabelle mit Ticketkennungen und Namen, als Textdatei mit Werten, die durch ein Komma getrennt sind). Sie besteht aus der Kennung der Zone (Anwendung) und der Kennung des Kartentyps. Auf der Grundlage dieser Zahlen wird die Schlüsselung in der Schlüsseldatei ausgewählt, innerhalb derer es möglicherweise bereits mehrere Schlüssel gibt (falls ein neuer Schlüssel eingegeben wurde und alte Karten noch verwendet werden). Das neue Ticket wird mit dem allerersten Ticket aufgezeichnet, und die Validierung erfolgt unter Verwendung aller Schlüssel in der Codierung. Außerdem wird der ausgewählte Schlüssel mit CryptKeyRef.dll entschlüsselt (warum sie verschlüsselt gespeichert werden, werde ich mir nicht merken). Danach werden der entschlüsselte Schlüssel und fast alle Ticketdaten sowie dessen Hardware-Seriennummer und -Nummer (die Methode zum Erzeugen eines "Hashs", der zum Eintasten von keys.d angegeben ist) an die Funktion ckCalcHashCode übergeben, die sich in derselben CryptKeyRef.dll befindet. Am Ausgang erhalten wir einen Wert, auf den ich in meiner Zeit und "stecken geblieben" bin - derselbe "Hash". Natürlich habe ich ein kleines Programm geschrieben, das mit Hilfe dieser Funktionen aus CryptKeyRef.dll und file keys.d das "Hash" in jedem Dump überprüfen und neu berechnen kann. Ich überprüfte alles auf mehreren Deponien und ging, nachdem ich ein positives Ergebnis erhalten hatte, zufrieden in den Schlaf.

Faulschlüssel

Trotz des theoretischen Erfolgs wollte ich alles sozusagen "im Gefecht" überprüfen. Am nächsten Tag, als ich von der Arbeit zurückkam, kaufte ich speziell einen frischen "Ultralight" für eine Reise, um zu sehen, ob meine Schlüssel funktionieren oder nicht (anscheinend waren sie alt). Sie können natürlich sofort versuchen, "fabriziert" "Ultralight" zu schreiben und zu überprüfen, aber zu dieser Zeit sind mir leere Karten ausgegangen, und ein bisschen unheimlich, "zufällig" zu gehen - ganz plötzlich was? Als ich nach Hause kam, eilte ich zuerst, ohne auch nur meine Hände zu waschen, mit Ungeduld, um das frische Ticket mit meinen Schlüsseln zu überprüfen. Und dann habe ich auf einen großen Scheißer gewartet - "Hash", in der Karte notiert hat keinen der Schlüssel passieren. Also, die Schlüssel sind wirklich schon faul und werden durch neue ersetzt. Das hat alle meine Werke vollständig durchgestrichen. Ich war ein bisschen traurig. Ich habe grünen Tee gebraut, ein wenig auf dem Klavier gespielt (ja-ja) und habe mich hingesetzt, um meine unvollendete Gebühr zu züchten ...

Noch ist nicht alles verloren

Die Idee kam unerwartet, als ich aus irgendeinem Grund noch einmal mit den Schlüsseln in die Akte schaute. Ich habe bemerkt, dass es bei der "laufenden" Eingabe (die verwendet wird, um 1-, 2-, 5-Wege- und andere "Ultralights" zu berechnen) zwei Schlüssel gab - einen neuen (zu diesem Zeitpunkt natürlich) und anscheinend einen alten. Es gab aber auch ein Keying, bei dem es nur einen Schlüssel gab. Vorher habe ich nicht darauf geachtet und mich auf das "Laufen" konzentriert. Um zu berechnen, für welche Tickets dieser Schlüssel verwendet wird, wusste ich es nicht. Als ich nachgeschaut habe, welche Art von Ticket an das Gehäuse gebunden ist, blitze ich einen kleinen Funken Hoffnung. Die Sache ist, dass diese Art von Ticket war - VESB. Ja, es ist diese seltene Art von Fahrschein - eine befristete Fahrkarte für alle Beförderungsarten. Ich habe mir gedacht, dass, wenn das Ticket Single ist, dieser Schlüssel nicht nur in der Metro, sondern auch im Landverkehr verwendet werden sollte, wo es sehr schwierig und lang ist, es durch ein neues zu ersetzen.

Darüber hinaus gibt es nur einen Schlüssel in Keiring, der indirekt meine Vermutung bestätigte. An alles andere erinnerte ich mich, dass, als ich das Metro-Programm von verschiedenen "Müll" bereinigte, es etwas Ähnliches zum Archiv alter Schlüsseldateien gab. Nachdem ich das Originalarchiv gegraben und geöffnet hatte, sah ich, dass es wirklich so war. Und am wichtigsten: Nachdem ich alle alten Schlüsseldateien durchgesehen habe, habe ich festgestellt, dass dieser Schlüssel unverändert geblieben ist! Schon ohne einen einzigen Zweifel habe ich mein eigenes VESB genietet (gut, ich hatte Dumps vom Typ, der die Aufgabe manchmal vereinfachte - ich habe einfach Datum und Nummer in den Dumps geändert) und den "Hash" mit diesem Schlüssel berechnet. Also, es ist Zeit zu überprüfen (vor allem, kaufte ich einfach mehr sauberes Plastik). Beim Betreten der Lobby stecke ich zuerst mein "Ticket" in das Verifizierungsterminal. Die Anzeigetafel zeigte das Ablaufdatum des Tickets, das ich anzeigte, und das grüne LED-Licht war an. So funktioniert es. Ich machte eine Grimasse leichter und versteckte schneeweißen Plastik im Ärmel, ging zum Drehkreuz, legte meine Hand auf den Validator und ... ging ruhig auf das fröhlich leuchtende Grün zu. Dies war der endgültige Sieg.

Und was kommt als nächstes?

Und dann begannen Experimente, bei denen viele interessante Dinge entdeckt wurden. Zum Beispiel kann man für ein solches "linkes" VESB nur zwei oder drei Tage laufen. Tatsache ist, dass die Nummer, die ich im Ticket "von der Glatze" anzeige, bei jedem Durchgang im Speicher des Drehkreuzes gespeichert ist und nach einiger Zeit mit dem Rest an das Rechenzentrum weitergeleitet wird. Dort findet das System kein wirklich ausgestelltes Ticket mit einer solchen Nummer und fügt es der Stoppliste hinzu, die dann an alle Drehkreuze der Metro gesendet wird. Und das sollte bei allen Arten von Tickets passieren, nicht nur beim VEBB - neben dem "Hash" und häufig wechselnden Schlüsseln ist dies eine sehr gute Verteidigung. Aus offensichtlichen Gründen ist es nicht möglich, dies zu umgehen.

Es wurde auch beobachtet, dass das Installieren oder Nicht-Installieren von Sperrbits keine Rolle dabei spielt, ob das Ticket funktioniert oder nicht. Die einzige Ausnahme ist das OTP-Zone-Blocking-Bit, das das Drehkreuz scheinbar immer überprüft, obwohl es nicht beabsichtigt, in OTP zu schreiben. Später nahm ich die U-Bahn- und Busterminals, brachte sie in Ordnung, studierte sie und brachte sie auf den Stand. Nun, um die nächste Vermutung zu überprüfen, war es nicht mehr notwendig, mit einem frisch gebackenen Mutanten-Ticket in der Metro zu laufen, aber es wurde möglich, sie zu kontrollieren, "ohne vom Ticketschalter abzugehen." Darüber hinaus stellte sich heraus, dass der U-Bahn-Terminal genauso alt war (alles andere und fehlerhaft), wie meine Schlüssel. So könnte ich "bei der Arbeit" und alle anderen Arten von Tickets "Ultralight" versuchen - etwas, das ich nie in der U-Bahn "live" machen kann. Parallel zu diesen Experimenten arbeitete ich weiter an Software.

Da es viele Diskussionen darüber gab, welcher Algorithmus zur Berechnung des "Hashs" verwendet wird, habe ich mich entschieden, ihn vollständig neu zu schreiben, indem ich den Algorithmus von Grund auf in der "menschlichen" Programmiersprache umgeschrieben habe, und dabei hoffte ich zu verstehen, was für ein Algorithmus es war. etwas weithin bekanntes oder irgendeine Art von eigener innerer Entwicklung. Auf dem Weg wurde ich von vielen verschiedenen Gedanken besucht (einschließlich, dass es AES sein könnte), aber mit einer ausführlichen Studie des bereits funktionierenden Codes ohne die Verwendung von Smartekov Bibliotheken wurde klar, dass dieser Algorithmus "nur" ist GOST - der nationale Verschlüsselungsstandard (alle notwendigen Informationen Sie können es leicht im Internet finden). Insbesondere wurde eine 16-Z-Schleife verwendet, um den Hash zu berechnen. "Hash", in der Tat ist es nichts wie eine Nachahmung GOST.

Die Struktur der Informationen auf dem Ticket "Ultralight"

Auf welcher Seite, wo und wie sich die Hardware-Seriennummer, Lock-Bits und OTP-Zone befinden, können Sie in der Originaldokumentation nachlesen (die Dateispezifikation im PDF-Format mit vollständiger Beschreibung des Chips befindet sich auf der Platte). Ich empfehle, die Studie mit ihr zu beginnen. Ich beschreibe die Datenstrukturstruktur, die durch U-Bahn-Systeme im Benutzerbereich gebildet wird, die zum Lesen und Neuschreiben zugänglich ist (natürlich ohne Sperren). Alle Inhalte des Tickets können bedingt in den Kopfteil und zwei vollständig duplizierende Teile der Daten unterteilt werden (dies geschieht aus Gründen der Redundanz und des Fehlerschutzes). Der Kopfteil in den Tickets "Ultralight" beginnt ab Seite 4. Ein Teil davon ist in allen Tickets und Bezeichnern des Systems von Underground und MosGorTrans identisch aufgebaut. Die ersten 10 Bits sind der Anwendungsidentifikator; die nächsten 10 Bits - der Bezeichner des Typs der Karte (darüber, welche Art von Bezeichnern es gibt, können Sie in einem anderen speziell für diesen Rahmen ausgewählten) lesen. Nach den Bezeichnern befindet sich die Seriennummer des Tickets (es ist auf der Rückseite des Tickets ausgeknockt, verwechseln Sie es nicht mit der Hardware - das sind verschiedene Dinge!) In der Größe 32 Bit. Die letzten 4 Bits sind das Layout-Feld, das dem System mitteilt, wie die nachfolgenden Daten zu interpretieren sind (etwa das Dateiformat).

Für Ultralight-Tickets lautet der Layoutwert 0x08. Dies beendet den gleichen Teil des Titels. Weiter ist im Ticket "Ultralight" das Datum angegeben, an dem das Formular gültig ist (16 Bit). Alle Daten im System werden im Format der Anzahl der Tage angezeigt, die seit dem 01.01.1992 verstrichen sind. Hier endet der Kopfteil des Tickets "Ultralight" (Tickets mit einem anderen Layout können noch verschiedene Zusatzinformationen enthalten). Der erste Datenbereich beginnt auf Seite 8. Zunächst werden 16 Bit des Ticketausgabedatums geschrieben. Danach beträgt die Gültigkeitsdauer des Tickets in Tagen (ab dem Zeitpunkt der Ausgabe) 8 Bit. Die ersten 16 Bit der Seite 9 sind der Trip-Zähler. Sie kann entweder auf Null (bei allen Tickets mit einer Beschränkung der Anzahl der Fahrten) oder auf Null (bei WESC-Tickets, ohne die Anzahl der Fahrten zu begrenzen) verringert werden. Nach dem Zähler gibt das Drehkreuz im Rest der Seite bei jedem Durchgang seine eindeutige Kennung ein. Anscheinend wird dies verwendet, um einen erneuten Durchgang zu verhindern, ohne auf ein Ticket durch die WESB zu warten (Drehkreuze in der Lobby sind mit dem Netzwerk verbunden und befragen einander) und auch zu sehen, durch welches Drehkreuz der Durchgang erfolgte (zum Beispiel im Falle eines Fehlers oder für Statistiken). ). Seite 10 ist vollständig von 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 stellt sich heraus, dass diese beiden Regionen im Normalbetrieb immer dieselben Daten enthalten. Getrennt muss man über die Nutzung des OTP-Zonensystems sagen. Es wird für das allmähliche "Ausbrennen" des Tickets bei jeder Reise verwendet (VESB-Tickets gelten nicht). Die beiden niedrigstwertigen Bits werden ausgegeben, wenn das Ticket storniert oder abgebrochen wird (auf dem Stoppblatt). Das stornierte Ticket unterliegt nicht der Wiederherstellung. Es verbleiben 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 (von Junior bis Senior) gesetzt, die dem entspricht, wie viel ein Prozent von einer Reise belegt ist. Zum Beispiel für ein 5-Passagierticket mit jeder neuen Reise, wird es bei 6 Bits ausgebrannt, und für ein 60-Weg-Ticket - ein halbes bisschen (aufgerundet). Es ist erwähnenswert, dass die Wiederverwendung von Tickets "Ultralight" nicht nur wegen des "Ausbrennens" von OTP unmöglich ist, sondern auch weil beim Ausstellen, beim Ausstellen eines Tickets (und vielleicht sogar wenn es gemacht wird), fast alle Seiten zum Überschreiben gesperrt sind. .. Daher wird weder das "Aufladen" noch das Ändern des Tickettyps zu einem anderen funktionieren.

Beispiele für gebrauchte U-Bahn-Ticketkennzeichen

Alle Zahlen sind in Dezimalschreibweise angegeben!

Anwendungs-IDs:

  • 262 - Ticket für die Moskauer Metro.
  • 264 - Ticket für den Landverkehr in Moskau.
  • 266 - Das einzelne soziale von Moskau und das Verteidigungsministerium.
  • 270 - Ticket "Light Metro".

Identifikatoren der Art der Tickets "Ultralight":

  • 120 - Eine Reise.
  • 121 - Zwei Reisen.
  • 126 - Fünf Reisen.
  • "Zehn Ausflüge."
  • "Zwanzig Reisen."
  • 129 Sechzig Reisen.
  • 130 - Gepäck + Durchgang.
  • 131 - Nur Gepäck.
  • 149 - Single "Ultralight" (70 Fahrten).
  • 150 - WESB.

Mifare Classic

Ich habe in meiner Forschung auch auf das unglückselige Mifare Classic 1K geachtet. Wie Sie verstehen, war das wichtigste Hindernis auf dem Weg zum "Classic" die Hardwareschlüssel A und B. Glücklicherweise waren diese Schlüssel in einem der Module des Programms in einer offenen Form (für die Entwickler!) Und ich hatte keine Probleme, ein kleines Programm zu schreiben. Arbeiten Sie mit den Inhalten dieser Karten, indem Sie die empfangenen Schlüssel verwenden. Im Laufe der Experimente wurden einige interessante Merkmale enthüllt, wie: Die U-Bahn benutzte den ersten Sektor der Karte zum Speichern des Tickets, und der Bodentransport verwendete den vierten; kein Schutz, außer für Hardwareschlüssel (die, nachdem sie in dieser Form in die Software geschrieben worden sind, höchstwahrscheinlich von dem Moment an, zu dem das System in Betrieb genommen wurde, überhaupt nicht geändert wurden) auf diesen Tickets existiert nicht.

Stattdessen wird am Ende jedes Blocks der CRC-16 angezeigt, nur um die Daten vor Beschädigung zu schützen. Darüber hinaus werden auf sozialen Karten neben Tickets auch viele weitere und interessante Informationen aufgezeichnet. Zum Beispiel werden im 13. und 14. Sektor der sozialen Karten der Nachname, der Name und das Patronym des Besitzers angegeben. Diese (und einige andere) Daten können mit dem öffentlichen Schlüssel 0xA0A1A2A3A4A5 gelesen werden. Während der Experimente war es möglich, Schüler-SCM vollständig zu klonen, sowie mehrere Karten für reine Classic-Karten.

Aber das Klonierungssystem, wie sich herausstellte, wird merklich durch das Stop-Loss-System gerettet - dieses Ticket kann für nicht mehr als zwei Tage genutzt werden, dann wird es storniert (anders als das "Ultralight" kann die "Classic" -Karte nach der Kündigung wiederhergestellt werden, aber aus der Stop-Liste es wird nicht gespeichert). Da auf den Classic-Karten kein Schutz verwendet wurde, wurden sie für mich schnell uninteressant und ich entschied mich, mich auf die Ultralight-Studie zu konzentrieren.

Das Ende oder Zusammenfassen

Metro-Systeme, insbesondere neue Tickets "Ultralight", waren im Gegensatz zu den Meinungen und Vermutungen gut geschützt. Sehr erfreut darüber, dass die Entwickler eine zuverlässige und bewährte GOST verwendet haben und das Rad nicht neu erfunden haben. Mit solch einem Schutz, um ein Ticket "Ultralight" zu fälschen, ohne Zugang zu vertraulichen Daten (Schlüsselinformationen) zu haben, ist es einfach unmöglich. Bemerkenswert durchdacht und das System der Ersatzschlüssel und der Mechanismus der Blenden. Natürlich gab es Mängel und Fehler. Die größte von ihnen ist Software, die in keiner Weise geschützt ist.

Es war genug, um die Verwendung von Runtime-bpl aufzugeben, und dies würde die Analyse Dutzende Male komplizieren! Als eine Option, - Verarbeitung von kritischen Teilen des Programms AsProtect'om oder ExeCryptor'om, gefolgt von zakkovkoy alle Dateien MoleBox'om würde die Möglichkeit der Analyse fast auf Null reduzieren. Toolkit etwas preiswert. Und die Verwendung eines guten (vorzugsweise wenig bekannten oder maßgeschneiderten) Schutzes dieser Art, aber mit Hardwareschlüsseln würde das Parsen des Programms vollständig unmöglich machen. Natürlich ist der Metropolitan ein Regimeunternehmen, aber vergiss den menschlichen Faktor nicht. Schließlich sagte Kevin Mitnick (und sagte nicht nur, sondern demonstrierte auch durch sein eigenes Beispiel, für das er sich setzte), dass es manchmal einfacher und effektiver ist, "Social Engineering" zu verwenden, als die undurchdringliche Verteidigung zu durchbrechen, um das Ziel zu erreichen. Nun, in diesem Sinne werde ich meine Erzählung beenden. Und zu Ihnen, dem Leser, wünsche ich mehr interessante und erfolgreiche Forschung!








Beschreibung des kryptographischen Transformationsalgorithmus gemäß GOST 28147-89

Diese Norm legt einen einzelnen kryptographischen Transformationsalgorithmus für Informationsverarbeitungssysteme in Netzwerken von elektronischen Computern (Computern), individuellen Computerkomplexen und Computern fest, der die Regeln für die Datenverschlüsselung und die Entwicklung von Imitovki bestimmt.

Der Algorithmus der kryptographischen Transformation ist für die Hardware- oder Softwareimplementierung vorgesehen, erfüllt kryptographische Anforderungen und schreibt dem Geheimhaltungsgrad der geschützten Informationen keine Beschränkungen auf.

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

Strukturdiagramm des kryptografischen Transformationsalgorithmus

Das Blockdiagramm des kryptographischen Transformation (Kryptosystem) -Algorithmus, gezeigt in 1, enthält:

  • - 256-Bit-Schlüsselspeichergerät, 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-Speichergeräte (N 1 , N 2 , N 3 , N 4 );
  • - zwei 32-Bit-Speicher (N5, N6) mit den Füllungskonstanten C2, C1, die in ihnen aufgezeichnet sind;
  • - zwei 32-Bit-Addierer Modulo 2 32 (CM 1 , CM 3 );
  • - 32-Bit-Addierer der bitweisen Summation Modulo 2 (CM 2 );
  • - 32-Bit-Addierer Modulo (2 32 -1) (SM 4 );
  • - Addierer Modulo 2 (CM 5 ), die Beschränkung der Kapazität des Addierers CM 5 wird nicht überlagert;
  • - Substitutionseinheit (K);
  • - das Register der zyklischen Verschiebung um elf Schritte in Richtung der höchsten Entladung (R).

Abbildung 1.

Der K-Substitutionsblock besteht aus acht Ersatzknoten K1, K2, K3, K4, K5, K6, K7, K8 mit jeweils einem Speicher von 64 Bit. Der an dem 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 mit vier Füllbits pro Zeile ist. Der Eingabevektor bestimmt die Adresse der Zeile in der Tabelle, die Füllung dieser Zeile ist ein abgehender Vektor. Die 4-Bit-Ausgangsvektoren werden dann sequentiell zu einem 32-Bit-Vektor kombiniert.

Wenn die binären Vektoren addiert und zyklisch verschoben werden, sind die oberen Bits Bits großer Zahlen.

Beim Schreiben eines Schlüssels (W 1 , W 2 , ..., W 256 ), W q Є {0,1}, q = i ÷ 256, wird der Wert W 1 in die 1. Stelle des Akkumulators X 0 eingetragen , der Wert W 2 wird eingetragen in der zweiten Stelle des Akkumulators X 0 , ... wird der Wert W 32 in die 32. Stelle des Akkumulators X 0 eingegeben; der Wert W 33 wird in die erste Stelle des Akkumulators X 1 eingegeben, der Wert W 34 wird in die zweite Stelle des Akkumulators X 1 eingegeben, ..., der Wert W 64 wird in das 32-te Bit des Akkumulators X 1 eingegeben; Wenn der Wert W 65 in die erste Stelle des Akkumulators X 2 usw. eingegeben wird, wird der Wert von W 256 in das 32. Bit des Akkumulators X 7 eingegeben.

Beim Überschreiben von Informationen wird der Inhalt der p- ten Stelle eines Akkumulators (Addierers) in die p- te Stelle eines anderen Akkumulators (Addierers) umgeschrieben.

Der Wert der Füllkonstante C 1 (konstant) des Akkumulators N 6 ist in Tabelle 1 angegeben.

Tabelle 1

Entladung des Akkumulators N 6

32

31

30

29

28

27.

26.

25

24

23

22

21

20

19

18.

17.

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Entladung des Akkumulators N 6

16

15.

14.

13.

12.

11.

10

9.

8.

7.

6.

5

4

3

2

1

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

Der Wert der Füllkonstante C2 (konstant) des Akkumulators N5 ist in Tabelle 2 angegeben.

Tabelle 2

Entladung des Akkumulators N 5

32

31

30

29

28

27.

26.

25

24

23

22

21

20

19

18.

17.

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Entladung des Akkumulators N 5

16

15.

14.

13.

12.

11.

10

9.

8.

7.

6.

5

4

3

2

1

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Die Schlüssel, die das Füllen der CMU definieren, und die Tabellen der K-Substitutionsbox sind geheime Elemente und werden in der festgelegten Reihenfolge geliefert.

Das Ausfüllen der Tabellen der K-Substitutionsbox ist ein langfristiges Schlüsselelement, das dem Computernetzwerk gemeinsam ist.

Die Organisation verschiedener Arten von Kommunikation wird durch den Aufbau eines geeigneten Schlüsselsystems erreicht. In diesem Fall ist es möglich, die Möglichkeit zu nutzen, Schlüssel in einem einfachen Ersetzungsmodus zu erzeugen und in einem einfachen Ersetzungsmodus zu verschlüsseln, wodurch ein Nachahmungsschutz für die Übertragung über Kommunikationskanäle oder Speicherung im Computerspeicher bereitgestellt wird.

Es gibt vier Arten von Arbeit in der kryptografischen Schaltung:

  • - Verschlüsselung (Entschlüsselung) von Daten in einem einfachen Ersetzungsmodus;
  • - Verschlüsselung (Entschlüsselung) von Daten im Gamma-Modus;
  • - Verschlüsselung (Entschlüsselung) von Daten im Modus der Gummierung mit Rückkopplung;
  • - Entwicklungsmodus der Nachahmung.

Verschlüsselung im einfachen Austauschmodus

Verschlüsselung offener Daten im einfachen Austauschmodus

Ein Kryptogramm, das den Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus implementiert, sollte die in Abbildung 2 gezeigte Form haben.


Abbildung 2

Die zu verschlüsselnden öffentlichen Daten sind in Blöcke von jeweils 64 Bit unterteilt. Die Eingabe eines beliebigen Blocks T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) binärer Information in die Akkumulatoren N & sub1; und N & sub2; werden so hergestellt, daß der Wert a & sub1; (0) in das erste Bit N & sub1; eingeführt wird, der Wert a & sub2; (0) in das zweite Bit N & sub1 ; 0) wird in das 32. Bit N 1 eingeführt ; der Wert b 1 (0) wird in das erste Bit N 2 eingegeben, der Wert b 2 (0) wird in das zweite Bit N 2 eingegeben usw., der Wert b 32 (0) wird in das 32-te Bit N 2 eingegeben. Infolgedessen ist der Zustand (a 32 (0), a 31 (0), ..., a 2 (0), a 1 (0)) des Speicherrings N 1 und der Zustand (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) des Speicherrings N 2 .

256 Bits des Schlüssels werden in die CMU eingegeben. Die Inhalte der acht 32-Bit-Laufwerke X 0 , X 1 , ..., X 7 sind:

  • 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 Verschlüsselungsalgorithmus eines 64-Bit-Blocks von offenen Daten im einfachen Ersetzungsmodus besteht aus 32 Zyklen.

Im ersten Zyklus wird die erste Füllung des Akkumulators N 1 modulo 2 32 im Addierer CM 1 mit der Füllung des Akkumulators X 0 summiert, während die Speicherung des Akkumulators N 1 beibehalten wird.

Das Ergebnis der Summation wird in den Substitutionsblock K transformiert und der resultierende Vektor wird dem Eingang des Registers R zugeführt, wo er zyklisch um elf Schritte in Richtung der höherwertigen Bits verschoben wird. Das Ergebnis der Verschiebung wird in dem CM 2 -Addierer mit einer 32-Bit-Füllung des N 2 -Speicherrings bitweise modulo 2 aufsummiert. Das in CM 2 erhaltene Ergebnis wird in N 1 geschrieben , während der alte Wert von N 1 in N 2 umgeschrieben wird. Der erste Zyklus endet.

Die nachfolgenden Zyklen werden auf die gleiche Weise ausgeführt, während im zweiten Zyklus die Füllung X 1 aus dem FEC ausgelesen wird, im dritten Zyklus die Füllung X 2 aus dem FEC ausgelesen wird usw. Im achten Zyklus wird die Füllung X 7 aus der CCD ausgelesen. In den Zyklen vom 9. bis zum 16. sowie in den Zyklen vom 17. bis zum 24. werden die Füllungen aus der QCD in der gleichen Reihenfolge gelesen: X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X6, X7.

In den letzten acht Zyklen vom 25. bis zum 32. ist die Reihenfolge des Lesens der Füllungen der CCD umgekehrt: X7, X6, X5, X4, X3, X2, X1, X0 .

Wenn Sie also in 32 Zyklen verschlüsseln, wird die folgende Reihenfolge verwendet, um den Inhalt der Laufwerke auszuwählen:

  • X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X,
  • X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X.

Im 32. Zyklus wird das Ergebnis vom CM 2 -Addierer in den N 2 -Akku eingesetzt, und die alte Füllung wird im Speicher N 1 gespeichert.

Die Verschlüsselung der nach dem 32. Verschlüsselungszyklus empfangenen N 1 - und N 2 -Akkumulatoren ist ein Block von verschlüsselten Daten entsprechend dem offenen Datenblock.

Verschlüsselte Daten in einem einfachen Ersetzungsmodus entschlüsseln

Ein Kryptogramm, das den Entschlüsselungsalgorithmus im einfachen Ersetzungsmodus implementiert, hat die gleiche Form (siehe 2) wie im Fall der Verschlüsselung. In dem ROM sind 256 Bits des gleichen Schlüssels eingegeben, auf dem die Verschlüsselung durchgeführt wurde. Die zu entschlüsselnden verschlüsselten Daten werden in Blöcke von jeweils 64 Bit aufgeteilt. Die Eingabe eines beliebigen Blocks T w = (a 1 (32) und 2 (32), ... und 32 (32), b 1 (32), b 2 (32), ..., b 32 (32)) in Speicherringen N 1 und N 2 wird so ausgeführt, dass der Wert von a 1 (32) in das erste Bit N 1 eingegeben wird, der Wert von a 2 (32) in das zweite Bit N 1 eingegeben wird usw., der Wert von a 32 (32) wird in das 32. Bit N 1 eingeführt ; der Wert b 1 (32) wird in das erste Bit N 2 eingeführt , der Wert b 2 (32) wird in das zweite Bit N 2 eingeführt usw., der Wert b 32 (32) wird in das 32-te Bit N 2 eingegeben.

Die Entschlüsselung wird durch denselben Algorithmus wie die Verschlüsselung der offenen Daten ausgeführt, mit der Änderung, dass das Füllen der Speichereinheiten X 0 , X 1 , ..., X 7 in den folgenden Zyklen in der folgenden Reihenfolge aus der CPU ausgelesen wird:

  • X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X,
  • X, X, X, X, X, X, X, X, X, X, X, X, X, X, X.

Nach 32 Betriebszyklen wird das Füllen der Akkumulatoren N & sub1; und N & sub2; aus einem offenen Datenblock gebildet.

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

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

Gamma-Modus

Verschlüsselung offener Daten im Gamma-Modus

Ein Kryptogramm, das den Verschlüsselungsalgorithmus im Gamma-Modus implementiert, muss die in Abbildung 3 gezeigte Form haben.


Abbildung 3

Offene Daten, aufgeteilt in 64-Bit-Blöcke T 0(1) , T 0(2) , ..., T 0(M-1) , T 0(M) , werden im Gamma-Modus durch bitweise Summation modulo 2 im CM-Addierer verschlüsselt 5 mit Gamma des Chiffren G, das durch Blöcke von 64 Bit erzeugt wird, d.h.

(1) , Γω(Σ) , ..., Γ, (Μ-1) , Γω(Μ) ),

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

(I) ist der i-te 64-Bit-Block, i = 1 ÷ the, die Anzahl der Bits im Block T 0(M) kann kleiner als 64 sein, während der Teil der Chiffrierskala vom Block F m(M) nicht zur Verschlüsselung verwendet wird. verworfen.

256 Bits des Schlüssels werden in die CMU eingegeben. In den Laufwerken N & sub1 ;, N & sub2 ; wird eine 64-Bit-Binärfolge (synchrones Senden) S = (S & sub1 ;, S & sub2 ;, ..., S & sub6; & sub4;) eingeführt, die die anfängliche Füllung dieser Laufwerke für die nachfolgende Erzeugung von M Blöcken des Chiffriergammas ist. Die Synchronisation wird in N 1 und N 2 eingeführt, so dass der Wert von S 1 in das erste Bit N 1 eingegeben wird, der Wert S 2 in das zweite Bit N 1 eingegeben wird usw. Der Wert von S 32 wird in das 32-Bit eingegeben. N 1 ; der Wert S 33 wird in das erste Bit N 2 eingegeben, der Wert S 34 wird in das zweite Bit N 2 eingegeben usw., der Wert S 64 wird in das 32-Bit N 2 eingegeben.

Die Erstbefüllung der Antriebe N1 und N2 (synchrones Senden S) wird im einfachen Austauschmodus gemäß den Anforderungen des Absatzes 1.3.1 verschlüsselt. Das Ergebnis der Verschlüsselung wird in 32-Bit-Akkumulatoren N & sub3; und N & sub4; umgeschrieben, so daß die Füllung N & sub1; in N & sub3 ; umgeschrieben wird und die Füllung N & sub2; in N & sub4 ; neu geschrieben wird.

Das Füllen des Akkumulators N4 wird im Addierer SM4 mit 32-Bit-Konstante С1 aus dem Akkumulator N6 modulo (2 32 -1) aufsummiert, das Ergebnis wird in N 4 geschrieben .

Das Füllen des Akkumulators N 3 wird im Addierer SM 3 mit einer 32-Bit-Konstanten C 2 aus dem Akkumulator N 5 modulo 2 32 aufsummiert, das Ergebnis wird in N 3 geschrieben .

Die Füllung von N 3 wird in N 1 umgeschrieben, und die Füllung von N 4 wird in N 2 umgeschrieben, während die Füllung von N 3 , N 4 erhalten bleibt.

Die Füllung N 1 und N 2 wird im einfachen Austauschmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die als Ergebnis der Verschlüsselung erhaltene Füllung N 1 , N 2 bildet den ersten 64-Bit-Block der Chiffrierskala G w(1) , der im Addierer CM 5 mit dem ersten 64-Bit-Datenblock T 0(1) = (t ) bitweise modulo 2 aufsummiert wird. 1(1) , t 2(1) , ..., t 63(1) , t 64(1) ). Als Ergebnis der Summierung wird ein 64-Bit-Block von verschlüsselten Daten erhalten: T w(1) = (τ 1(1) , τ 2(1) , ..., τ 63(1) , τ 64(1) ).

Значение τ 1(1) блока Т ш(1) является результатом суммирования по модулю 2 в СМ 5 значения t 1(1) из блока Т 0(1) со значением 1-го разряда N 1 , значение τ 2(1) блока Т ш(1) является результатом суммирования по модулю 2 в СМ 5 значения t 2(1) из блока Т 0(1) со значением 2-го разряда N 1 и т.д., значение τ 64(1) блока Т ш(1) является результатом суммирования по модулю 2 в СМ 5 значения t 64(1) из блока Т 0(1) со значением 32-го разряда N 2 .

Для получения следующего 64-разрядного блока гаммы шифра Г ш(2) заполнение N 4 суммируется по модулю (2 32 -1) в сумматоре СМ 4 с константой С 1 из N 6 , заполнение N 3 суммируется по модулю 2 32 в сумматоре СМ 3 с константой С 2 из N 5 . Новое заполнение N 3 переписывается в N 1 , а новое заполнение N 4 переписывается в N 2 , при этом заполнение N 3 и N 4 сохраняется.

Заполнение N 1 и N 2 зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N 1 , N 2 образует второй 64-разрядный блок гаммы шифра Г ш(2) , который суммируется поразрядно по модулю 2 в сумматоре СМ 5 со вторым блоком открытых данных Т 0(2) . Аналогично вырабатываются блоки гаммы шифра Г ш(3) , Г ш(4) …, Г ш(М) и зашифровываются блоки открытых данных Т 0(3) , Т 0(4) …, Т 0(М) . Если длина последнего М-го блока открытых данных Т 0(М) меньше 64 бит, то из последнего М-го блока гаммы шифра Г ш(М) для зашифрования используется только соответствующее число разрядов гаммы шифра, остальные разряды отбрасываются.

В канал связи или память ЭВМ передаются синхропосылка S и блоки зашифрованных данных Т ш(1) , Т ш(2) …, Т ш(М) .

Расшифрование зашифрованных данных в режиме гаммирования

При расшифровании криптосхема имеет тот же вид, что и при зашифровании (см. рисунок 3). В КЗУ вводятся 256 бит ключа, с помощью которого осуществлялось зашифрование данных Т 0(1) , Т 0(2) …, Т 0(М) при этом Т 0(М) может содержать меньше 64 разрядов.

Режим гаммирования с обратной связью

Зашифрование открытых данных в режиме гаммирования с обратной связью

Криптосхема, реализующая режим гаммирования с обратной связью, должна иметь вид, приведенный на рисунке 4.


Рисунок 4

Открытые данные, разбитые на 64-разрядные блоки Т 0(1) , …, Т 0(М) , зашифровываются в режиме гаммирования с обратной связью путем поразрядного суммирования по модулю 2 в сумматоре СМ 5 с гаммой шифра Г ш , которая вырабатывается блоками по 64 бита, т.е. Г ш =(Г ш(1) , Г ш(2) , …, Г ш(М) ), где М – определяется объемом шифруемых данных, Г ш(i) – i-й 64-разрядный блок, i=1÷Ì. Число двоичных разрядов в блоке Т 0(М) может быть меньше 64.

В КЗУ вводятся 256 бит ключа. В накопители N 1 , N 2 вводится 64-разрядная двоичная последовательность (синхропосылка) S=(S 1 , S 2 , …, S 64 ). Синхропосылка вводится в N 1 и N 2 так, что значение S 1 вводится в 1-й разряд N 1 , значение S 2 вводится во 2-й разряд N 1 , и т.д., значение S 32 вводится в 32-й разряд N 1 ; значение S 33 вводится в 1-й разряд N 2 , значение S 34 вводится во 2-й разряд N 2 и т.д., значение S 64 вводится в 32-й разряд N 2 .

Исходное заполнение накопителей N 1 и N 2 зашифровывается в режиме простой замены в соответствии с требованиями пункта 3.1. Полученное в результате зашифрования заполнение N 1 и N 2 образует первый 64-разрядный блок гаммы шифра Г ш(1) , который суммируется поразрядно по модулю 2 в сумматоре СМ 5 с первым 64-разрядным блоком открытых данных Т 0(1) =(t 1(1) , t 2(1) , …, t 63(1) , t 64(1) ).

В результате суммирования получается 64-разрядный блок зашифрованных данных Т ш(1) =(τ 1(1) , τ 2(1) , …, τ 63(1) , τ 64(1) ).

Der Block verschlüsselter Daten Tm(1) ist gleichzeitig auch der Anfangszustand N1, N2 zum Erzeugen des zweiten Blocks der Chiffrierskala Gr (2) und wird durch Rückkopplung auf die angegebenen Antriebe zurückgeschrieben. In diesem Fall wird der Wert von & tgr; 1(1) in das erste Bit N 1 eingeführt , der Wert von & tgr; 2(1) in das zweite Bit N 1 usw., der Wert von & tgr; 32(1) wird in das 32-te Bit N eingeführt. 1 ; Der Wert von τ 33(1) wird in das erste Bit N 2 eingeführt , der Wert von τ 34(1) wird in das zweite Bit N 2 eingeführt usw., der Wert von τ 64(1) wird in das 32-te Bit N 2 eingeführt .

Die Füllung N 1 , N 2 wird im einfachen Austauschmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die als Ergebnis der Verschlüsselung erhaltene Füllung N 1 , N 2 bildet den zweiten 64-Bit-Block des Chiffriergamms Gw (2) , der im Addierer CM 5 mit dem zweiten Block der offenen Daten T 0(2) digital modulo 2 summiert wird.

Die Erzeugung von nachfolgenden Blöcken der Chiffrierskala G w(i) und die Verschlüsselung der entsprechenden Blöcke von offenen Daten T 0(i) (i = 3 ÷) wird analog durchgeführt. Wenn die Länge des letzten M-ten Blocks von offenen Daten T 0(M) kleiner als 64 Bit ist, wird nur die entsprechende Anzahl von Ziffern des Chiffrierbereichs von G r (M) verwendet , die verbleibenden Bits werden verworfen.

Die Synchronisation S und die Blöcke der verschlüsselten Daten Т ш(1) , Т ш(2) ..., Т ш(М) werden zum Kommunikationskanal oder Computerspeicher übertragen.

Entschlüsselung von verschlüsselten Daten in einem Gummierungsmodus mit Rückmeldung

Beim Entschlüsseln hat die kryptographische Schaltung die gleiche Form wie bei der Verschlüsselung (siehe Fig. 4). In der CMU sind 256 Bits des gleichen Schlüssels eingetragen, auf denen T 0(1) , T 0(2) ..., T 0(M) verschlüsselt wurden. Die Synchronisation wird in N 1 , N 2 eingeführt, so dass der Wert von S 1 in das erste Bit N 1 eingeführt wird , der Wert S 2 in das zweite Bit N 1 eingegeben wird usw. Der Wert von S 32 wird in das 32-te Bit eingegeben. N 1 ; der Wert S 33 wird in das erste Bit N 2 eingegeben, der Wert S 34 wird in das zweite Bit N 2 eingegeben usw., der Wert S 64 wird in das 32-Bit N 2 eingegeben.

Die Erstbefüllung der Antriebe N 1 und N 2 (Synchronisation S) wird im einfachen Ersatzmodus gemäß den Anforderungen in Abschnitt 3.1 verschlüsselt. Die resultierende Füllung N 1 , N 2 bildet den ersten 64-Bit-Block des Chiffriergammas Gw (1) , der im Addierer CM 5 mit dem verschlüsselten Datenblock T w(1) digital modulo 2 aufsummiert wird. Als Ergebnis wird der erste Block von offenen Daten T 0(1) erhalten.

Der Block der verschlüsselten Daten Т ш(1) ist die Anfangsfüllung N 1 , N 2 zum Erzeugen des zweiten Blocks der Chiffrierskala Гш (2) . Der Block T w(1) ist in N 1 , N 2 geschrieben . In diesem Fall wird der Wert von & tgr; 1(1) in das erste Bit N 1 eingeführt , der Wert von & tgr; 2(1) in das zweite Bit N 1 usw., der Wert von & tgr; 32(1) wird in das 32-te Bit N eingeführt. 1 ; Der Wert von τ 33(1) wird in das erste Bit N 2 eingeführt , der Wert von τ 34(1) wird in das zweite Bit N 2 eingeführt usw., der Wert von τ 64(1) wird in das 32-te Bit N 2 eingeführt . Die empfangene Füllung N & sub1 ;, N & sub2; wird in dem einfachen Ersetzungsmodus gemäß den Anforderungen von Klausel 3.1 verschlüsselt, der resultierende Block Gr (2) wird bitweise in dem Addierer CM5 mit dem zweiten Block verschlüsselter Daten Tw(2) modulo 2 aufsummiert. Als Ergebnis wird ein offener Datenblock T 0(2) erhalten.

In ähnlicher Weise werden in den Blöcken N & sub1; , N & sub2 ; Blöcke von verschlüsselten Daten T & sub1;(2) , Ts(3) ..., Ts(M-1) sequentiell aufgezeichnet, von denen in dem einfachen Ersetzungsmodus Gamma-Codes der Chiffre Fm(3)(4) , ..., Γω(Μ) . Die Blöcke der Chiffrierskala werden digital modulo 2 in dem Addierer CM 5 mit Blöcken von verschlüsselten Daten T w(3) , T w(4) ..., T w(M) summiert, was zu Blöcken von offenen Daten T 0(3) , T 0( 4) , ..., T 0(M) , während die Länge des letzten Blocks von offenen Daten T 0(M) weniger als 64 Bit enthalten kann.

Simulationsmodus

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 (Imitation I 1). Der Simulationsprozess ist für alle Verschlüsselungsmodi einheitlich.

Der erste Block von offenen Daten ist T 0(1) = (t 1(1) , t 2(1) , ..., t 64(1) ) = (a 1(1) (0), a 2(1) (0) (0), b 2(1) (0), ..., b 32(1) (0)) wird in die Speicherringe N 1 und N 2 geschrieben , der Wert t 1(1) = a 1(1) (0) wird in das erste Bit N 1 eingeführt , der Wert t 2(1) = a 2(1) (0) wird in das zweite Bit N 1 eingeführt , usw., der Wert von t 32(1) = a 32(1) (0) wird in das 32-te Bit N 1 eingegeben; Der Wert von t 33(1) = b 1(1) (0) wird in das erste Bit N 2 usw. eingegeben, der Wert t 34(1) = b 32(1) (0) wird in die 32ste Stelle eingeführt. N 2 .

Die Füllung N & sub1; und N & sub2; erfährt eine Transformation, die den ersten 16 Zyklen des Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus entspricht, gemäß den Anforderungen von Abschnitt 3.1. In der CMU wird derselbe Schlüssel verwendet, um die Blöcke der offenen Daten T 0(1) , T 0(2) , ..., T 0(M) in die entsprechenden Blöcke der verschlüsselten Daten T w(1) , T w(2) zu verschlüsseln. ..., Tm(M) .

Die nach 16 Arbeitszyklen erhaltene Füllung von N 1 und N 2 in der Form ( 1 1(1) (16), a 2(1) (16), ..., a 32(1) (16), b 1(1) ( 16), b2 (1) (16), ..., b32 (1) (16)) wird in CM 5 modulo 2 mit dem zweiten Block T 0(2) = (t 1(2) , t 2( 2) , ..., t 64(2) ). Das Summenergebnis wird in N 1 und N 2 aufgezeichnet und wird einer Transformation unterzogen, die den ersten 16 Zyklen des Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus entspricht.

Die resultierende Füllung N 1 und N 2 wird in CM 5 modulo 2 mit dem dritten Block T 0(3) usw. summiert, der letzte Block T 0(M) = (t 1(M) , t 2(M) , ... , t 64(M) ), die optional mit einem 64-Bit-Block auf Null aufgefüllt werden, wird in CM 5 modulo 2 mit der Füllung N 1 , a 1(M-1) (16) und 2(M-1) ( 16), ..., 32(M-1) (16), b 1(M-1) (16), b 2(M-1 ) .. Das Summenergebnis wird in N 1 , N 2 gespeichert und im einfachen Ersetzungsmodus für die ersten 16 Zyklen der Algorithmusoperation verschlüsselt. Aus der erhaltenen Füllung der Speicherringe N 1 und N 2 wählen wir das Segment I 1 = [a 32 -1 + 1(M) (16) und 32 -1 + 1(M) (16), ..., a 32(M) (16) )].

Imitavtavka AND l wird am Ende der verschlüsselten Daten auf dem Kommunikationskanal oder im Speicher des Computers übertragen, d.h. Tm(1) , Tm(2) , ..., Tm(M) und l .

Die empfangenen verschlüsselten Daten T w(1) , T w(2) , ..., T w(M) werden entschlüsselt, eine Imitation wird aus den erhaltenen Blöcken von offenen Daten T 0(1) , T 0(2) , ..., T 0(M) erzeugt. Und l ' , das dann mit der Nachbildung I1 verglichen wird, wird zusammen mit den verschlüsselten Daten von dem Kommunikationskanal oder dem Computerspeicher erhalten. Im Falle einer Nichtübereinstimmung von Imitationen werden die erhaltenen Blöcke von offenen Daten T 0(1) , T 0(2) , ..., T 0(M) als falsch angesehen.

Der Wert des Parameters 1 (die Anzahl der Bits in der Imitation) wird durch die aktuellen kryptographischen Anforderungen bestimmt, wobei berücksichtigt wird, dass die Wahrscheinlichkeit der Auferlegung falscher Daten 2 - 1 ist .