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

Hacken der U-Bahn (Reisekarten) + Algorithmus für kryptografische Transformationen gemäß GOST 28147-89

Auf der Seite:


Die U-Bahn hacken (Reisekarten)

Kennen Sie den Wunsch, alle Rätsel zu lösen und alle Verteidigungsanlagen der Moskauer U-Bahn zu öffnen? Machen Sie sich zum Beispiel ein "ewiges Ticket"? Schließlich finden U-Bahn-Spezialisten immer ausgefeiltere Schutzmethoden. Metallmarken wurden durch Plastikmarken ersetzt, diese wiederum durch Magnetkarten, und kontaktlose Karten ersetzten Magnetkarten. Viele Forscher ließen die Hände fallen - die Metro scheint zu einer uneinnehmbaren Festung geworden zu sein. Jeder Schutz kann jedoch umgangen werden. Und oft ist das Öffnen um ein Vielfaches einfacher als das Bauen ...

Wie alles begann

Das Interesse an U-Bahn-Systemen ist mir, so könnte man sagen, schon vor langer Zeit aus der Schule gekommen, als es noch Tickets mit Magnetstreifen gab. Dann (vor einem Dutzend Jahren) wurde eine kontaktlose Sozialkarte für Studenten in Umlauf gebracht. 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 für eine lange Zeit verschieben, aber ich habe mir selbst versprochen, dass ich auf jeden Fall darauf zurückkommen würde ...

Vor drei Jahren habe ich wieder Interesse am Thema U-Bahn geweckt. Ich habe Magnetkarten aktiv studiert (es gab viele Informationen zu diesem Thema im Internet) und sogar eine kleine Maschine zusammengestellt, mit der Duplikate von zwei Köpfen aus Tonbandgeräten und einer kleinen Menge losem Pulver 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 unzugänglich 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 Schlüssel bis zum Ende des Sonnensystems sortieren. Ja, und die Karteninhaber, die Classic unterstützen, kosteten damals etwas unerträgliches Geld (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: Ultraleicht

Ultraleichtflugscheine tauchten kürzlich in unserer U-Bahn auf, erregten jedoch sofort großes Interesse in der Öffentlichkeit. Sie begannen zu hämmern, zu reißen, sich an einem Eisen festzuhalten und andere Methoden der thermorektalen Kryptoanalyse anzuwenden. Ich muss zugeben, ein Wissensdurst hat mich dazu gebracht, ein Paar zu verwöhnen. Als Ergebnis ihrer Untersuchungen und Recherchen im Internet wurde festgestellt, dass dies nichts mit Mifare Ultralight zu tun hat, der "Lite" -kompatiblen Version von Mifare Classic. Ein kurzer Blick auf die Dokumentation der Chips dieses Standards machte deutlich, dass diese Karten keine eingebauten 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!

Für den Anfang war es natürlich nur notwendig, irgendwo einen kabellosen Kartenleser zu bekommen, der Ultralight unterstützt. Es gab zwei Möglichkeiten: entweder selbst zusammenbauen (was viel Zeit in Anspruch nimmt) oder ein fertiges Gerät kaufen. Als ich vor drei Jahren unter Berücksichtigung der Preise über die zweite Option nachdachte, bekam ich eine Gänsehaut. Trotzdem habe ich mich entschlossen, die aktuellen Preise zu sehen. 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 kabelgebundenen und kabellosen Karten zu einem attraktiven Preis unterstützt - 4000 Rubel.

Natürlich nicht wenig, aber andererseits sind es nicht 10.000; Darüber hinaus ermöglichte der Kauf eines gebrauchsfertigen Lesegeräts, sich sofort auf die Ticketrecherche zu konzentrieren und nicht auf die Entwicklung und das Debugging von Eisen, das sich auf unbestimmte Zeit hinziehen könnte. Zusammen mit einem Lesegerät der gleichen Firma (ISBC) wurde ein sehr praktisches lokales SDK gekauft. Er erlaubte es wiederum, keine Zeit und Energie für das Schreiben einer Low-Level- und Debugging-Software mit dem Leser zu verschwenden, sondern sich direkt auf Tickets zu konzentrieren. So entstand in wenigen Tagen ohne Eile ein kleines Programm, mit dessen Hilfe die gesamte interne Struktur von Ultralight komfortabel beobachtet und bearbeitet werden konnte. Dann fing ich an, Tickets zu lernen.

Leere Wand

Während des Studiums gingen viele Tickets durch meinen Leser. Einige habe ich mir die Ärmel hochgekrempelt, aus dem Müll geholt, andere gekauft - ich habe mir angeschaut, was darauf steht, dann habe ich durchgesehen und noch einmal nachgesehen. Das waren fast alle Arten von Tickets, mit der möglichen Ausnahme des Ultralight-Tickets für 70 Fahrten. Nach ein paar Wochen sammelte 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 gingen hintereinander. Meine Sammlung hat sogar mehrere Dumps mit zwei verschiedenen temporären Tickets für soziale Zwecke erhalten (eines wurde für einen Zeitraum von 5 Tagen ausgestellt, das andere 30), die nach einem bestimmten Zeitintervall erschossen wurden. Es stellte sich heraus, dass es sich um sehr interessante und gleichzeitig sehr seltene Exemplare handelte (ich bekam sie mit sofortiger Rückgabe aus erster Hand, nur zum "Lesen").

Tatsächlich ist dies fast die einzige Art von Ultraleichtflugzeugen, die nicht nur in der U-Bahn, sondern auch im Landverkehr eingesetzt werden kann. 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 Service geboten ... Ich habe diesen ganzen Zoo zu einem Zweck gesammelt - um die Struktur und das Format der Datenerfassung auf dem Ticket eindeutig zu bestimmen. Natürlich waren einige Felder sofort mit bloßem Auge sichtbar, andere jedoch nicht. Zum Beispiel habe ich nicht sofort verstanden, wo die Nummer des Metrotickets aufgezeichnet ist (die gleiche, die darauf gedruckt ist). Das Bewusstsein kam zufällig. Tatsache ist, dass ich (wie ich denke, die meisten von uns) beim Betrachten des Hexadezimalzeichens Informationen für mich selbst ausrichte und zumindest Bytes denke. Es stellte sich heraus, dass dieser Ansatz hier falsch ist. Bei einem Ticket-Dump müssen Sie in kleineren Einheiten denken - Tetraden und manchmal auch Bits. Das habe ich verstanden, als ich endlich die Ticketnummer „gesehen“ habe - es stellte sich heraus, dass sie sich um 4 Bits relativ zum Anfang des Bytes verschoben hat und die verbleibenden 4 Bits von beiden Seiten der Nummer mit anderen offiziellen Informationen belegt waren. Nach einiger Zeit wurde das Format für die Aufzeichnung von Daten auf Tickets fast vollständig verstanden.

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 damit endete alle Freude - es wäre töricht anzunehmen, dass solche Tickets ungeschützt bleiben könnten. Jeder Speicherauszug enthielt 32 Bits verschiedener Informationen, die nicht mit dem Rest des Inhalts korrelierten. Ich schlug vor, dass dies eine Art Prüfsumme ist, ein „Hash“ der auf dem Ticket aufgezeichneten Daten. Alle Versuche, diese 32 Bits zu schätzen oder zu berechnen, erwiesen sich als vollständiger Fehler (insbesondere wurde angenommen, dass dies eine Art CRC32 mit einem nicht standardmäßigen Polynom und einem Startwert ist).

Bei dem Versuch, mindestens eineinhalb Bits der Informationen im Ticket zu ändern, markierte das Kontrollterminal in der U-Bahn „BAD TICKET“ und stieß mit einem schweren Wagenheber die letzten Nägel in den Sargdeckel. Natürlich gab es Versuche, das System auf andere Weise zu umgehen, zum Beispiel zu versuchen, ein Ticket eins zu eins auf eine leere Karte zu kopieren (hier wurde leider die Fabrikserie verhindert, die, wie sich herausstellte, auch an der Erzeugung des "Hash" beteiligt war) oder die Sperrbits so zu setzen um zu verhindern, dass das Drehkreuz den Inhalt des Tickets ändert. Das Kassenterminal erkannte ein solches "ewiges" Ticket, weigerte sich jedoch, das Drehkreuz zu starten ... Also rannte ich gegen die Wand. In dieser großen, starken Betonmauer, über die viele die Angewohnheit haben, sich mit einem rennenden Start umzubringen. Nachdem ich in den Foren und Foren keine Informationen gefunden hatte, entschied ich, dass meine Recherche hiermit abgeschlossen war - es gab keine weiteren Möglichkeiten mehr und steckte eine Kugel hinein. Wie sich herausstellte, vergebens ...

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 Monitorbildschirm und hob friedlich ein Brett für meine nächste Arbeit, während ich warmen, leicht süßlichen grünen Tee trank. DipTarce, ein bisschen bashorg, ICQ ... Jemand hat Skype angerufen - lenken Sie ab! Wieder ICQ, wieder DipTrace - im Allgemeinen ist alles wie gewohnt. Wieder trat ein ICQ-Fenster in den Vordergrund - jemand, den ich bisher nicht kannte, schrieb "Hallo". Ich antwortete, ohne zu zögern, dasselbe. Die folgende Nachricht war ein Wendepunkt in der ganzen Geschichte: „Sie scheinen an der U-Bahn interessiert zu sein, ich habe hier einen kleinen Müll. Wenn Sie interessiert sind, treffen wir uns, ich sage es Ihnen. " Anfangs war ich ein wenig verlegen und aufmerksam (vielleicht wurde eine Scheidung oder ein Betrug oder die „besonderen Dienste“ interessierten mich - Paranoia fordert ihren Tribut), aber dann dachte ich: Warum nicht?

Es war unwahrscheinlich, dass sich die speziellen Dienste für mich interessierten, aber es schien keinen Grund für eine Scheidung zu geben, und noch mehr für ein Setup. Nach einem kurzen Gespräch einigten wir uns darauf, uns am Nachmittag im Zentrum der Halle einer der Moskauer U-Bahn-Stationen zu treffen. Es stellte sich heraus, dass der Fremde ein großer junger Mann mit Brille und einer großen schwarzen Plastiktüte in den Händen war. Wir begrüßten uns, dann reichte er mir ein Päckchen mit den Worten: „On, hold on. Es hat mir immer noch nicht geholfen, vielleicht ist es für dich nützlich. " Als ich hineinschaute, sah ich zwei U-Bahn-Terminals mit Zeitungen, mehrere zufällig verteilte weiße Plastikkarten und einen leeren Karton in einer Schachtel. Auf meine Frage, wie viel ich (Geld) dafür verdanke, schüttelte der Typ den Kopf, lächelte und sagte: "Warum, du schuldest niemandem etwas, tu es ... Also, ich muss schon rennen, da ist mein Zug einmal! Komm schon, tschüss! "

Mit diesen Worten rannte er weg, sprang in die bereits schließenden Autotüren und fuhr los. Und ich gebe zu, ich bin ein bisschen unerklärlich nach Hause gegangen. Nur für den Fall, dass ich den Kontakt von ICQ gelöscht habe, gleichzeitig die Kontaktliste auf dem Server bereinigt und die Protokolle aufgeräumt habe (hallo nochmal, Paranoia). Am Ende wird er nochmal schreiben, wenn das so ist. Aber er hat mir nie wieder geschrieben ...

Das Phänomen der Software für die Menschen

Zuhause angekommen, nahm ich das Paket auseinander. Das zweite der Terminals erwies sich als Busvalidierer (schwer, verdammt!); Die Karten waren Mifare Classic 1K (leer), und auf der CD befand sich ein einziges Archiv. Nach kurzem Kennenlernen der Inhalte stellte sich heraus, dass es sich um eine Software handelt, die an der Abendkasse eingesetzt wird. Ich legte das Terminal und den Validator beiseite und beschloss, mich mit dem Studium interessanter Software auseinanderzusetzen. In etwa einer Stunde gelang es mir, dieses Programm aus dem entpackten Chaos auf meinem Computer zu erstellen und auszuführen. Es dauerte eine weitere Stunde, um seine Struktur herauszufinden. Nachdem ich alle ini-Dateien (mit freundlicherweise vom Entwickler hinterlassenen Kommentaren) gekämmt hatte, hatte ich bereits eine vollständige Vorstellung davon, was es ist, wie es funktioniert und womit es gegessen wird. Wie sich herausstellte, wird mit dem Parsec PR-P08-Lesegerät gefressen, weshalb es mangels Software nicht möglich war, die Software in Aktion zu testen.

Der Entwickler war Smartek, ein großer staatlicher Auftragnehmer, der solche Systeme entwickelt (weitere Details finden Sie auf der 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 Entwicklerdatei). Nach einer kurzen Analyse der Interna der Software stellte ich fest, dass zum einen Informationen zu allen ausgegebenen Tickets in eine zentralisierte Datenbank übertragen werden (dies ist übrigens Oracle) und zum anderen verwendet das Programm einen bestimmten 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. Dies verschafft uns theoretisch einen Vorsprung.

Zuallererst interessierte ich mich jedoch für den Schlüsselmechanismus (ich hatte bereits geraten, 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 Schlüsseln wie nichts anderes aussieht). Und ich habe all diese Güte von Runtime-bpl'in SmLayout.bpl verwendet. Diese Bibliothek war nur ein Glücksfall für meine Recherche - sie enthielt Klassen für die Arbeit mit dem internen Inhalt von Tickets. Da dies runtime-bpl ist, genügte es, nur auf die Exporttabelle zu schauen, um bereits zu 60 Prozent zu verstehen, was was war. Eine detailliertere Analyse hat alles in Ordnung gebracht. Erinnern Sie sich, am Anfang des Artikels habe ich über die Tatsache gesprochen, dass es in der Struktur von Ultralight mehrere weitere Felder gab, deren Zweck nicht klar war?

Eines dieser Felder ist der sogenannte „Layout Identifier“. Tatsächlich bestehen alle Metrotickets aus einer festen Überschrift und einem Teil mit variablen Daten. Dieses Feld "Layout" im Titel hat also nur bestimmt, 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 entsprach jedes einer eigenen Klasse (plus einer gemeinsamen übergeordneten Klasse, in der es Methoden zum Arbeiten mit dem Header-Teil gab). Daher war es einfach herauszufinden, welche Felder in jedem Layout wofür verantwortlich sind (mit sprechenden Methodennamen im Export!). Nachdem ich das gesamte Layout 8 (das in Ultralight verwendet wird) vollständig ausgefüllt und überprüft hatte, ob ich eine korrekte Vorstellung von allen Feldern in der Ticketstruktur hatte, griff ich auf den Schlüsselmechanismus zurück. In der Tat war er dafür verantwortlich, den "Hash" zu generieren. Wie der Mechanismus funktioniert, wurde nach dem Studium der Funktionsweise der für die Berechnung des "Hash" verantwortlichen Methode völlig klar. Zunächst wird der richtige Schlüssel aus der Datei mit den Schlüsseln (keys.d) ausgewählt.

Das System ist so konzipiert, dass jeder Tickettyp eine eigene Kennung hat (der vollständige Satz enthielt eine vollständige Tabelle mit Ticketkennungen und -namen in Form einer Textdatei mit durch Komma getrennten Werten). Es besteht aus einer Zonen-ID (Anwendung) und einer Kartentyp-ID. Ausgehend von diesen Zahlen wird in der Schlüsseldatei eine Schlüsseleingabe ausgewählt, in der sich möglicherweise bereits mehrere Schlüssel befinden (falls der neue Schlüssel eingegeben wurde und die alten Tickets noch verwendet werden). Das neue Ticket wird mit dem allerersten Ticket erfasst, und die Gültigkeitsprüfung wird mit allen Schlüsseln in der Codierung durchgeführt. Als nächstes wird der ausgewählte Schlüssel mit CryptKeyRef.dll entschlüsselt (warum sie verschlüsselt gespeichert werden, kann ich mir nicht vorstellen). 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 angegebene "Hash" -Generierungsmethode) an die Funktion ckCalcHashCode übertragen, die sich in derselben CryptKeyRef.dll befindet. Am Ausgang erhalten wir den Wert, auf dem ich einmal "festgefahren" war - das gleiche "Hash". Natürlich habe ich ein kleines Programm geschrieben, das mit Hilfe dieser Funktionen aus CryptKeyRef.dll und der Datei keys.d den "Hash" in jedem Dump überprüfen und neu berechnen konnte. Ich überprüfte noch einmal alles auf ein paar Müllhalden und ging, nachdem ich ein positives Ergebnis erhalten hatte, zufrieden in den Schlaf.

Faule Schlüssel

Trotz des theoretischen Erfolgs wollte ich sozusagen alles "im Kampf" überprüfen. Als ich am nächsten Tag von der Arbeit zurückkam, kaufte ich speziell ein neues Ultralight, um zu sehen, ob meine Schlüssel funktionieren oder nicht (anscheinend waren sie alt). Sie könnten natürlich sofort versuchen, das "fabrizierte" Ultraleichtflugzeug aufzunehmen und zu überprüfen, aber in diesem Moment sind mir die leeren Karten ausgegangen, und es ist ein wenig beängstigend, "zufällig" zu gehen - plötzlich was? Als ich zu Hause ankam, beeilte ich mich als erstes, ohne mir die Hände zu waschen, ungeduldig, das frische Ticket mit meinen Schlüsseln zu überprüfen. Und dann wartete ein großer Mist auf mich - der auf dem Ticket aufgezeichnete „Hash“ ging durch keinen der Schlüssel. Folglich sind die Schlüssel wirklich schon faul und werden durch neue ersetzt. Das hat meine ganze Arbeit komplett durchgestrichen. Ich war ein bisschen traurig. Ich kochte grünen Tee, spielte ein wenig Klavier (ja) und setzte mich, um mein unvollendetes Brett zu züchten ...

Es ist nicht alles verloren

Die Idee kam mir unerwartet, als ich aus irgendeinem Grund noch einmal in die Datei mit den Schlüsseln schaute. Mir ist aufgefallen, dass es bei der „laufenden“ Tastung (die zur Berechnung von 1-, 2-, 5-Trip- und anderen Ultraleichtflugzeugen verwendet wird) zwei Tasten gab - eine neue (zu dieser Zeit natürlich) und anscheinend eine alte. Es gab aber auch Keying, bei dem nur ein Schlüssel lag. Bisher habe ich nicht auf ihn geachtet, sondern mich auf das "Laufen" konzentriert. Um zu berechnen, welche Tickets dieser Schlüssel verwendet, wusste ich nicht. Als ich mir anschaute, welche Art von Ticket mit der Fürsorge verbunden war, schoss ein kleiner Hoffnungsschimmer aus mir heraus. Tatsache ist, dass diese Art von Ticket VESB war. 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 gibt es nur einen Schlüssel für das Keying, was meine Vermutung indirekt bestätigt. An alles andere erinnerte ich mich, dass es etwas Ähnliches gab wie ein Archiv alter Schlüsseldateien, als ich das U-Bahn-Programm von verschiedenen "Müll" befreite. Als ich das Originalarchiv ausgrub und öffnete, sah ich, dass dies tatsächlich so ist. Und am wichtigsten, als ich mir alle alten Schlüsseldateien ansah, stellte ich fest, dass dieser spezielle Schlüssel unverändert blieb! Bereits ohne einen einzigen Zweifel habe ich meinen eigenen VESB genietet (zum Glück hatte ich Speicherauszüge dieses Typs, die die Aufgabe erheblich vereinfachten - ich habe nur die Daten und die Nummer in den Speicherauszügen geändert) und den "Hash" mit diesem Schlüssel berechnet. Es ist also an der Zeit, dies zu überprüfen (zumal ich mir gerade etwas saubereres Plastik gekauft habe). Als ich die Lobby betrat, habe ich zuerst mein Ticket an der Kasse angebracht. Das von mir angegebene Ablaufdatum des Tickets wurde auf der Tafel angezeigt und die grüne LED leuchtete auf. So funktioniert es. Ich zog eine einfache Grimasse und versteckte das schneeweiße Plastik in meinem Ärmel, ging zum Drehkreuz, legte meine Hand zum Prüfer und ... ging ruhig auf dem funkelnden Grün. Dies war der letzte Sieg.

Und was dann?

Und dann begannen Experimente, bei denen viele interessante Dinge herausgefunden wurden. Auf einem solchen "linken" VESB können Sie beispielsweise nur zwei oder drei Tage laufen. Tatsache ist, dass die Nummer, die ich im Ticket „vom Bulldozer“ angebe, bei jedem Durchgang im Kopf des Drehkreuzes gespeichert und nach einiger Zeit zusammen mit dem Rest an das Rechenzentrum gesendet wird. Dort findet das System kein wirklich ausgestelltes Ticket mit einer solchen Nummer und gibt es in eine Stoppliste ein, die dann an alle U-Bahn-Drehkreuze gesendet wird. Und das sollte bei allen Arten von Tickets passieren, nicht nur bei VESB - zusätzlich zum „Hash“ und den häufig wechselnden Schlüsseln ist dies ein sehr guter Schutz. Aus offensichtlichen Gründen ist es nicht möglich, sich darum zu kümmern.

Es wurde auch bemerkt, dass das Setzen oder Nichtsetzen der Sperrbits keine Rolle spielt, ob das Ticket funktioniert oder nicht. Die Ausnahme ist nur das OTP-Zonensperrbit, das das Drehkreuz anscheinend immer überprüft, obwohl es nicht in OTP schreiben wird. Zukünftig habe ich die U-Bahn- und Bus-Terminals in Betrieb genommen, in Ordnung gebracht, studiert und am Stand eingeführt. Um nun eine andere Vermutung zu überprüfen, musste man nicht mehr mit einem frisch gebackenen Mutanten-Ticket in der U-Bahn davonlaufen, sondern konnte sie „ohne das Ticketbüro zu verlassen“ überprüfen. Außerdem erwies sich das U-Bahn-Terminal als genauso alt (alles andere und Buggy) wie meine Schlüssel. So konnte ich „bei der Arbeit“ und andere Arten von Ultralight-Tickets ausprobieren - etwas, das ich niemals „live“ in der U-Bahn machen konnte. Parallel zu diesen Experimenten beschäftigte ich mich weiter mit Software.

Da viel darüber diskutiert wurde, welche Art von Algorithmus zur Berechnung des "Hash" verwendet wird, habe ich beschlossen, ihn vollständig wiederherzustellen, indem ich den Algorithmus von Grund auf in der "menschlichen" Programmiersprache neu geschrieben habe, und dabei nur gehofft zu verstehen, um welche Art von Algorithmus es sich handelt - um welche Art von Algorithmus 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 Smartek-Bibliotheken im Detail studierte, stellte sich heraus, dass dieser Algorithmus „nur“ GOST war - der inländische Verschlüsselungsstandard (alle erforderlichen Informationen) über ihn kann man leicht im web finden). Insbesondere wurde ein 16-H-Zyklus verwendet, um den "Hash" zu berechnen. "Hash" ist in der Tat nichts anderes als eine GOST-Imitation.

Die Struktur der auf dem Ticket "Ultralight" aufgezeichneten Informationen

Sie können lesen, was die Seite ist, wo und wie sich die Hardware-Seriennummer, die Sperrbits und die OTP-Zone in der Originaldokumentation befinden (die Spezifikationsdatei im PDF-Format mit einer vollständigen Beschreibung des Chips befindet sich auf der Festplatte). Ich empfehle, das Studium mit ihr zu beginnen. Ich werde die Struktur der Datenanordnung beschreiben, die von U-Bahn-Systemen im Benutzerbereich gebildet wird, die zum Lesen und Umschreiben zugänglich sind (natürlich ohne Sperren). Der gesamte Inhalt des Tickets kann bedingt in den Kopfteil und zwei sich gegenseitig vervielfältigende Datenteile aufgeteilt werden (dies diente der Reservierung und dem Schutz vor Fehlern). Der Titelteil von Ultralight-Tickets beginnt auf Seite 4. Ein Teil davon ist identisch aufgebaut mit allen Tickets und Kennungen des Metropolitan-Systems und von MosGorTrans. Die ersten 10 Bits sind die Anwendungskennung. Die nächsten 10 Bits sind eine Kennung des Kartentyps (Sie können nachlesen, welche Kennungen sich in einer anderen speziell dafür ausgewählten Box befinden). Nach dem Identifier steht die Seriennummer des Tickets (sie ist auf der Rückseite des Tickets abgestempelt, nicht mit der Hardware verwechseln - das sind verschiedene Dinge!) 32 Bit groß. 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. Dies beendet den gleichen Teil des Headers. Als nächstes zeigt das Ultralight-Ticket das Datum an, 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 vergangen sind. Hier endet der Titelteil 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ültigkeit des Tickets in Tagen (ab Ausstellungsdatum) angezeigt - 8 Bit. Die ersten 16 Bits von Seite 9 sind ein 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 ein VESB-Ticket zu warten (die Drehkreuze in der Lobby sind miteinander vernetzt und fragen sich gegenseitig ab) und um zu sehen, durch welches Drehkreuz die Passage gemacht wurde (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 (12 bis 15) repliziert. Es zeigt sich, dass diese beiden Bereiche im Normalbetrieb immer die gleichen Daten enthalten. Unabhängig davon ist die Verwendung der OTP-Zone durch das System zu erwähnen. Es wird verwendet, um ein Ticket bei jeder Fahrt schrittweise „auszubrennen“ (dies gilt nicht für VESB-Tickets). Die zwei niedrigstwertigen Bits werden gesetzt, wenn ein Ticket storniert oder storniert wird (über die Stoppliste). Ein storniertes Ticket wird nicht erstattet. Es sind nur noch 30 Bits zum Brennen übrig. Dieser Bereich wird vom System als 100% der Fahrten dargestellt. Bei jeder neuen Auslösung wird eine bestimmte Anzahl von Bits (von niedrig nach hoch) festgelegt, die der Anzahl der prozentualen Auslösungen entspricht. Beispielsweise werden für ein Ticket mit 5 Fahrten mit jeder neuen Fahrt 6 Bits „ausgebrannt“ und für ein Ticket mit 60 Fahrten „halbes Bit“ (aufgerundet). Es ist erwähnenswert, dass die Wiederverwendung von Ultralight-Tickets nicht nur aufgrund des „Ausbrennens“ von OTP unmöglich ist, sondern auch, weil an der Kasse beim Ausstellen eines Tickets (und möglicherweise sogar während seiner Herstellung) fast alle Seiten für das Umschreiben gesperrt sind . Somit wird weder ein "Aufladen" noch ein Wechsel der Ticketart zu einer anderen fehlschlagen.

Beispiele für verwendete Kennungen von Metrotickets

Alle Zahlen sind in Dezimalschreibweise!

Anwendungs-IDs:

  • 262 - Moskauer U-Bahn-Ticket.
  • 264 - Ticket für den Moskauer Bodentransport.
  • 266 - Einheitliches Soziales von Moskau und der Region Moskau.
  • 270 - Ticket "Einfache U-Bahn."

Identifikatoren für Ultraleichtflugscheintypen:

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

Mifare Klassiker

Ich habe den unglückseligen Mifare Classic 1K bei meinen Nachforschungen nicht ignoriert. Wie Sie wissen, waren die Hardwareschlüssel A und B das Haupthindernis für die "Klassiker". Diese Schlüssel befanden sich glücklicherweise in einem der Programmmodule im Klartext (vorerst bei den Entwicklern!), 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. Während der Experimente wurden einige interessante Merkmale aufgedeckt, wie zum Beispiel: Die U-Bahn verwendet den ersten Abschnitt der Karte, um ein Ticket zu speichern, und der Bodentransport verwendet den vierten; Auf diesen Tickets gibt es keinen anderen Schutz als Hardwareschlüssel (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 angegeben, um die Daten einfach vor Beschädigung zu schützen. Zusätzlich zu den Eintrittskarten werden auf sozialen Karten 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, Studenten-SCM sowie mehrere Tickets für leere Classic-Karten vollständig zu klonen.

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

Das Ende, oder um es zusammenzufassen

U-Bahn-Systeme und insbesondere die neuen Ultralight-Tickets waren entgegen Meinungen und Spekulationen gut geschützt. Es ist sehr erfreulich, dass die Entwickler einen zuverlässigen und bewährten GOST verwendet haben und nicht damit begonnen haben, das Rad neu zu erfinden. Mit diesem Schutz ist das Fälschen eines Ultralight-Tickets ohne Zugriff auf vertrauliche Daten (Schlüsselinformationen) einfach unmöglich. Durchdacht sind auch das Wechselschlüsselsystem und der Stopplistenmechanismus. Natürlich gab es einige Mängel und Fehler. Die größte davon ist Software, die in keiner Weise geschützt ist.

Es reichte aus, auf die Verwendung von runtime-bpl zu verzichten, was die Analyse zehnmal schwieriger machen würde! Optional würde die Verarbeitung besonders wichtiger Programmteile durch AsProtect oder ExeCryptor, gefolgt vom Packen aller Dateien mit MoleBox, die Analyse auf nahezu Null reduzieren. Das Toolkit ist kostengünstig. Und die Verwendung eines guten (vorzugsweise wenig bekannten oder maßgeschneiderten) Schutzes dieser Art, jedoch mit Hardwareschlüsseln, würde eine Analyse des Programms vollständig unmöglich machen. Natürlich ist der Metropolitan ein sensibles Unternehmen, aber vergessen Sie nicht den menschlichen Faktor. Immerhin sagte Kevin Mitnik (und sprach nicht nur, sondern demonstrierte durch sein eigenes Beispiel, für das er sich setzte, gee), dass es manchmal einfacher und effizienter ist, "Social Engineering" zu verwenden, um das Ziel zu erreichen, als zu versuchen, undurchdringliche Verteidigung abzubauen. In diesem Sinne werde ich meine Geschichte beenden. Und Sie, Leser, ich wünsche Ihnen weitere interessante und erfolgreiche Recherchen!








Beschreibung des kryptographischen Transformationsalgorithmus nach GOST 28147-89

Diese Norm legt einen einheitlichen Algorithmus für die kryptografische Konvertierung von Informationsverarbeitungssystemen in elektronischen Computernetzen (Computern), einzelnen Computerkomplexen und Computern fest, der die Regeln für die Datenverschlüsselung und die Entwicklung einer Beilage definiert.

Der Verschlüsselungskonvertierungsalgorithmus ist für die Hardware- oder Softwareimplementierung vorgesehen, erfüllt die Verschlüsselungsanforderungen und unterliegt aufgrund seiner 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 anwenden, die in Computernetzwerken, in separaten Computerkomplexen oder in Computern gespeichert und übertragen werden.

Blockdiagramm des kryptografischen Umwandlungsalgorithmus

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

  • - 256-Bit-Schlüsselspeichervorrichtung (RAM), 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 der darin aufgezeichneten Füllkonstante C 2 , C 1 ;
  • - zwei 32-Bit-Addierer modulo 2 32 (SM 1 , SM 3 );
  • - 32-Bit-Addierer des bitweisen Summationsmoduls 2 (SM 2 );
  • - 32-Bit-Addierermodul (2 32 -1) (CM 4 );
  • - Addierer Modulo 2 (CM 5 ), die Beschränkung der Kapazität des Addierers CM 5 wird nicht auferlegt;
  • - Substitutionsblock (K);
  • - Register der zyklischen Verschiebung um elf Schritte in Richtung der älteren Entladung (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 einem Speicher von jeweils 64 Bits. Der am Ersetzungsblock 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 pro Zeile enthält. Der Eingabevektor bestimmt die Adresse der Zeile in der Tabelle, wobei diese Zeile den ausgehenden Vektor ausfüllt. Dann werden 4-Bit-Ausgangsvektoren sequentiell zu einem 32-Bit-Vektor kombiniert.

Beim Addieren und zyklischen Verschieben von Binärvektoren sind die höchstwertigen Bits die Bits von Laufwerken mit großen Zahlen.

Beim Schreiben eines Schlüssels (W 1 , W 2 , ..., W 256 ), W q ≤ {0,1}, q = i ≤ 256, RAM wird der Wert von W 1 in das 1. Bit des Laufwerks X 0 eingegeben, der Wert von W 2 wird eingegeben im 2. Bit des Laufwerks X 0 , ... wird der Wert von W 32 in das 32. Bit des Laufwerks X 0 eingetragen ; der Wert von W 33 wird in die erste Entladung von Laufwerk X 1 eingegeben, der Wert von W 34 wird in die zweite Entladung von Laufwerk X 1 eingegeben, ... der Wert von W 64 wird in die 32. Entladung 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 Entladung eines Laufwerks (Addierers) in die p-te Entladung 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

Die Kategorie des Laufwerks N 6

32

31

30

29.

28

27

26

25

24

23

22

21

20

19

18

17

Entladewert

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Die Kategorie des Laufwerks N 6

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Entladewert

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

Entladung von Antrieb N 5

32

31

30

29.

28

27

26

25

24

23

22

21

20

19

18

17

Entladewert

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Entladung von Antrieb N 5

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Entladewert

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Die Schlüssel, die das Füllen des RAM und der Tabellen des Substitutionsblocks K bestimmen, sind geheime Elemente und werden auf die vorgeschriebene Weise geliefert.

Das Ausfüllen der Tabellen des Substitutionsblocks K ist ein langfristiges Schlüsselelement, das einem Computernetzwerk gemeinsam ist.

Die Organisation verschiedener Kommunikationsarten wird durch den Aufbau eines geeigneten Schlüsselsystems erreicht. In diesem Fall kann die Möglichkeit genutzt werden, Schlüssel im einfachen Ersetzungsmodus zu generieren (RAM ausfüllen) und im einfachen Ersetzungsmodus mit einem Imitationsschutz für die Übertragung über Kommunikationskanäle zu verschlüsseln oder im Computerspeicher zu speichern.

Das Kryptoschema bietet vier Arten von Arbeit:

  • - 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 Gamma-Modus mit Rückmeldung;
  • - Art der Entwicklung eines Imitationseinsatzes.

Einfache Ersatzverschlüsselung

Verschlüsselung offener Daten im einfachen Ersetzungsmodus

Das kryptografische Schema, das den 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. Eingabe irgendeines Blocks T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) binäre Information in Antriebe N 1 und N 2 sind so ausgeführt, dass der Wert a 1 (0) in die 1. Ziffer N 1 , der Wert a 2 (0) in die 2. Ziffer N 1 usw., der Wert a 32 ( 0) wird in die 32. Ziffer N 1 eingefügt; 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)) von Laufwerk N 1 und der Zustand (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) des Laufwerks N 2 .

256 Bits des Schlüssels werden in den RAM eingegeben. Der Inhalt von acht 32-Bit-Laufwerken X 0 , X 1 , ..., X 7 ist:

  • 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 offenen 64-Bit-Datenblocks im einfachen Ersetzungsmodus besteht aus 32 Zyklen.

Im ersten Zyklus wird die Erstbefüllung des Antriebs N 1 mit der Befüllung des Antriebs X 0 modulo 2 32 in den Addierer CM 1 addiert, während die Befüllung des Antriebs N 1 gespeichert wird.

Das Ergebnis der Summierung wird im Substitutionsblock K umgesetzt und der resultierende Vektor dem Eingang des Registers R zugeführt, wo er sich zyklisch um elf Schritte zu den höheren Stellen verschiebt. Das Verschiebungsergebnis wird im Addierer CM 2 mit 32-Bit-Füllantrieb N 2 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 auf die gleiche Weise ausgeführt, während im zweiten Zyklus die Füllung X 1 aus dem RAM gelesen wird, im dritten Zyklus die Füllung X 2 aus dem ROM usw., im achten Zyklus die Füllung X 7 aus dem RAM gelesen wird. In den Zyklen vom 9. bis zum 16. sowie in den Zyklen vom 17. bis zum 24. werden die Füllungen aus dem Speicher 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 von der 25. bis zur 32. Reihenfolge des Lesens der Füllungen des RAM ist die umgekehrte Reihenfolge: X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Daher wird beim Verschlüsseln in 32 Zyklen das folgende Verfahren 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 die alte Füllung im Akkumulator N 1 gespeichert.

Die Füllungen der Laufwerke N 1 und N 2, die nach dem 32. Verschlüsselungszyklus erhalten werden, sind ein verschlüsselter Datenblock, der einem offenen Datenblock entspricht.

Entschlüsselung verschlüsselter Daten im einfachen Ersetzungsmodus

Das kryptografische Schema, das den Entschlüsselungsalgorithmus im einfachen Ersetzungsmodus implementiert, hat dieselbe Form (siehe Abbildung 2) wie bei der Verschlüsselung. 256 Bits desselben Schlüssels, mit dem verschlüsselt wurde, werden in den RAM eingegeben. Die zu entschlüsselnden verschlüsselten Daten werden in Blöcke von jeweils 64 Bit aufgeteilt. Eingabe eines beliebigen Blocks T w = (a 1 (32), a 2 (32), ..., a 32 (32), b 1 (32), b 2 (32), ..., b 32 (32)) in Laufwerke N 1 und N 2 wird so gemacht, dass der Wert von a 1 (32) in die 1. Ziffer N 1 , der Wert von a 2 (32) in die 2. Ziffer N 1 usw., der Wert von a 32 (32) eingegeben wird. eingeführt in der 32. Ziffer N 1 ; Der Wert von b 1 (32) wird in die erste Entladung N 2 eingegeben, der Wert von b 2 (32) wird in die zweite Entladung N 2 eingegeben, usw. Der Wert von b 32 (32) wird in die 32. Entladung N 2 eingegeben.

Die Entschlüsselung erfolgt nach dem gleichen Algorithmus wie die Verschlüsselung offener Daten mit der Änderung, dass die Füllung der Laufwerke X 0 , X 1 , ..., X 7 in Entschlüsselungszyklen in der folgenden Reihenfolge aus dem RAM gelesen wird:

  • 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 .

Nach 32 Betriebszyklen erhalten, umfassen die Fülllaufwerke 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 dem Block verschlüsselter Daten, der Wert von a 1 (0) des T 0 -Blocks entspricht dem Inhalt der 1. Entladung N 1 , der Wert von a 2 (0) entspricht dem Inhalt der 2. Entladung N 1 usw., der Wert von a 32 (0) entspricht dem Inhalt von 32- te Entladung N 1 ; der Wert von b 1 (0) entspricht dem Inhalt der ersten Entladung N 2 , der Wert von b 2 (0) entspricht dem Inhalt der zweiten Entladung N 2 usw., der Wert von b 32 (0) entspricht dem Inhalt der 32. Entladung N 2 .

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

Gamma-Modus

Gamma-Verschlüsselung offener Daten

Das kryptografische Schema, das den Verschlüsselungsalgorithmus im Gamma-Modus 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 Gammamodus durch bitweise Summation Modulo 2 im Addierer CM verschlüsselt 5 mit dem Gamma der Chiffre G w , die in Blöcken von 64 Bits erzeugt wird, d.h.

G W = (G W(1) , G W(2) , ..., G W(M - 1) , G W(M) ),

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

G w(i) - i-ter 64-Bit-Block, i = 1 ≤ ≤, die Anzahl der Binärbits im Block T 0(M) kann kleiner als 64 sein, während ein Teil des Chiffrier-Gammas aus dem Block G w(M) nicht zur Verschlüsselung verwendet wird verworfen.

256 Bits des Schlüssels werden in den RAM eingegeben. Eine 64-Bit-Binärsequenz (Synchronisationspaket) S = (S 1 , S 2 , ..., S 64 ) wird in die Laufwerke N 1 , N 2 eingeführt , was das anfängliche Füllen dieser Laufwerke für die nachfolgende Erzeugung von M Chiffrier-Gammablöcken ist. Das Uhrenpaket wird in N 1 und 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 usw., der Wert von S 32 in die 32. Stelle eingegeben wird N 1 ; Der Wert von S33 wird in die erste Entladung N2 eingegeben, der Wert von S34 wird in die zweite Entladung N2 eingegeben, usw. Der Wert von S64 wird in die 32. Entladung N2 eingegeben.

Das anfängliche Befüllen der Laufwerke N 1 und N 2 (Synchronisationspaket S) wird in einem einfachen Austauschmodus gemäß den Anforderungen in Absatz 1.3.1 verschlüsselt. Das Verschlüsselungsergebnis wird auf die 32-Bit-Laufwerke N3 und N4 kopiert, so dass das Pad N1 auf N3 und das Pad N2 auf N4 kopiert wird.

Das Füllen von Laufwerk N 4 wird im Addierer CM 4 mit einer 32-Bit-Konstante C 1 von Laufwerk N 6 modulo (2 32 -1) summiert, das Ergebnis wird in N 4 geschrieben .

Das Füllen von Laufwerk N 3 wird im Addierer CM 3 mit einer 32-Bit-Konstante C 2 von Laufwerk N 5 modulo 2 32 aufsummiert, das Ergebnis wird nach N 3 geschrieben .

Die Füllung N3 wird nach N1 kopiert, und die Füllung N4 wird nach N2 kopiert, während die Füllung N3, N4 gespeichert wird.

Das Füllen von N 1 und N 2 wird in einem einfachen Ersetzungsmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die durch Verschlüsselung erhaltene Füllung N 1 , N 2 bildet den ersten 64-Bit-Block des Chiffrier-Gammas 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 von τ 1(1) des Blocks T W(1) ist das Ergebnis der Modulo 2-Summierung in CM 5 des Werts von t 1(1) aus dem Block T 0(1) mit dem Wert der 1. Ziffer N 1 , dem Wert von τ 2(1) des Blocks TW(1) ist das Ergebnis einer Modulo-2-Summation in CM5 des Wertes von T2 (1) aus dem Block T0 (1) mit dem Wert der zweiten Ziffer N1 usw. des Wertes von T64 (1) des Blocks TW(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 .

Um den nächsten 64-Bit-Block des Chiffrierumfangs Гш (2) zu erhalten, wird die Füllung N 4 im Addierer СМ 4 mit der Konstante С 1 aus N 6 modulo (2 32 -1) summiert, die Füllung N 3 wird im Addierer СМ 3 modulo 2 32 summiert mit konstantem C 2 von N 5 . Die neue Füllung N3 wird nach N1 kopiert, und die neue Füllung N4 wird nach N2 kopiert, während die Füllung von N3 und N4 gespeichert wird.

Das Füllen von N 1 und N 2 wird in einem einfachen Ersetzungsmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die durch Verschlüsselung erhaltene Füllung N 1 , N 2 bildet einen zweiten 64-Bit-Block des Gammas der Chiffre G w(2) , der im Addierer CM 5 mit dem zweiten offenen Datenblock T 0(2) bitweise modulo 2 summiert wird. Die Verschlüsselungs-Gammablöcke G w(3) , G w(4) ..., G w(M) werden auf ähnliche Weise 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, dann wird vom letzten M-ten Block des Chiffrier-Gammas G w(M) nur die entsprechende Anzahl von Bits des Chiffrier-Gammas zur Verschlüsselung verwendet, die verbleibenden Bits werden verworfen.

Das synchrone Paket S und die Blöcke der verschlüsselten Daten TSH(1) , TSH(2) ..., TSH(M) werden an den Kommunikationskanal oder den Computerspeicher übertragen.

Entschlüsselung verschlüsselter Daten im Gamma-Modus

Beim Entschlüsseln hat das Kryptoschema dieselbe Form wie beim Verschlüsseln (siehe Abbildung 3). 256 Bits des Schlüssels werden in den RAM eingegeben, mit dessen Hilfe die Daten T 0(1) , T 0(2) ..., T 0(M) verschlüsselt wurden, während T 0(M) weniger als 64 Bits enthalten kann.

Feedback-Gamma-Modus

Verschlüsselung offener Daten im Gamma-Modus mit Rückmeldung

Das kryptografische Schema, das den Gamming-Modus mit Rückmeldung implementiert, sollte die Form haben in Abbildung 4 angegeben.


Abbildung 4

Offene Daten, die in 64-Bit-Blöcke T 0(1) , ..., T 0(M) unterteilt sind , werden in einem Gammamodus mit Rückkopplung durch bitweises Summieren modulo 2 im Addierer CM 5 mit einem Verschlüsselungs-Gamma G w verschlüsselt, das durch Blöcke von erzeugt wird 64 Bits, d.h. Gsh = ( Gsh(1) , Gsh(2) , ..., Gsh(M) ), wobei M durch die zu verschlüsselnde Datenmenge bestimmt wird, Gsh(i) der i-te 64-Bit-Block ist, i = 1 ÷ ÷. Die Anzahl der Binärbits im Block T 0(M) kann kleiner als 64 sein.

256 Bits des Schlüssels werden in den RAM eingegeben. Eine 64-Bit-Binärsequenz (Synchronisationspaket) S = (S 1 , S 2 , ..., S 64 ) wird in die Laufwerke N 1 , N 2 eingeführt . Das Uhrenpaket wird in N 1 und 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 usw., der Wert von S 32 in die 32. Stelle eingegeben wird N 1 ; Der Wert von S33 wird in die erste Entladung N2 eingegeben, der Wert von S34 wird in die zweite Entladung N2 eingegeben, usw. Der Wert von S64 wird in die 32. Entladung N2 eingegeben.

Das anfängliche Befüllen der Laufwerke N 1 und N 2 wird in einem einfachen Austauschmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die durch Verschlüsselung erhaltene Füllung N 1 und N 2 bildet den ersten 64-Bit-Block des Chiffrier-Gammas 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 verschlüsselte Datenblock T w(1) ist gleichzeitig auch der Ausgangszustand N 1 , N 2 zur Erzeugung des zweiten Blocks des Chiffrierumfangs G w(2) und wird durch Rückmeldung auf die angegebenen Laufwerke geschrieben. In diesem Fall wird der Wert von & tgr; 1(1) in die erste Entladung N 1 eingegeben, der Wert von & tgr; 2(1) wird in die zweite Entladung N 1 eingegeben, usw. der Wert von & tgr; 32(1) wird in die 32. Entladung N eingegeben 1 ; Der Wert von & tgr; 33(1) wird in die erste Entladung N 2 eingegeben, der Wert von & tgr;34(1) wird in die zweite Entladung N 2 eingegeben, usw. Der Wert von & tgr;64(1) wird in die 32. Entladung N 2 eingegeben.

Das Füllen von N 1 , N 2 wird in einem einfachen Ersetzungsmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die durch Verschlüsselung erhaltene Füllung N 1 , N 2 bildet einen zweiten 64-Bit-Block des Gammas der Chiffre 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 des Gamuts der Chiffre G w(i) und die Verschlüsselung der entsprechenden Blöcke offener Daten T 0(i) (i = 3 ≤ ≤) wird auf ähnliche Weise durchgeführt. Wenn die Länge des letzten M-ten Blocks offener Daten T 0(M) kleiner als 64 Bits ist, dann wird nur die entsprechende Anzahl von Bits des Chiffrier-Gammas von G w(M) verwendet , die verbleibenden Bits werden verworfen.

Das synchrone Paket S und die Blöcke der verschlüsselten Daten TSH(1) , TSH(2) ..., TSH(M) werden an den Kommunikationskanal oder den Computerspeicher übertragen.

Entschlüsselung von verschlüsselten Daten im Gamma-Modus mit Rückmeldung

Beim Entschlüsseln hat das Kryptoschema dieselbe Form wie beim Verschlüsseln (siehe Abbildung 4). 256 Bits desselben Schlüssels werden in den RAM eingegeben, in dem T 0(1) , T 0(2) ..., T 0(M) verschlüsselt wurde. Das Uhrenpaket wird in N 1 , N 2 eingegeben, so dass der Wert von S 1 in die 1. Stelle von N 1 eingegeben wird, der Wert von S 2 in die 2. 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 Entladung N2 eingegeben, der Wert von S34 wird in die zweite Entladung N2 eingegeben, usw. Der Wert von S64 wird in die 32. Entladung N2 eingegeben.

Das anfängliche Befüllen der Laufwerke N 1 und N 2 (Synchronisationspaket S) wird in einem einfachen Austauschmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die durch die Verschlüsselung erhaltene Füllung N 1 , N 2 bildet den ersten 64-Bit-Block des Gammas der Chiffre Г ш(1) , der im Addierer СМ 5 mit dem Block der verschlüsselten Daten Т ш(1) bitweise modulo 2 summiert wird. Das Ergebnis ist der erste Block offener Daten T 0(1) .

Der verschlüsselte Datenblock T w(1) ist die anfängliche Füllung N 1 , N 2 , um den zweiten Block des Verschlüsselungsumfangs G w(2) zu erzeugen. Der Block TW(1) wird in N & sub1 ;, N & sub2; geschrieben. In diesem Fall wird der Wert von & tgr; 1(1) in die erste Entladung N 1 eingegeben, der Wert von & tgr; 2(1) wird in die zweite Entladung N 1 eingegeben, usw. der Wert von & tgr; 32(1) wird in die 32. Entladung N eingegeben 1 ; Der Wert von & tgr; 33(1) wird in die erste Entladung N 2 eingegeben, der Wert von & tgr;34(1) wird in die zweite Entladung N 2 eingegeben, usw. Der Wert von & tgr;64(1) wird in die 32. Entladung N 2 eingegeben. Die resultierende Füllung N 1 , N 2 wird in einem einfachen Ersetzungsmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt, der resultierende Block G w(2) wird im Addierer CM 5 bitweise modulo 2 mit dem zweiten Block verschlüsselter Daten T w(2) summiert. Das Ergebnis ist ein Block offener Daten T 0(2) .

In ähnlicher Weise werden in N & sub1 ;, N & sub2 ; die Blöcke verschlüsselter Daten sequentiell in TW(2) , TW(3) , TW(M-1) geschrieben , aus denen in einem einfachen Ersetzungsmodus Chiffrier-Gammablöcke GW (3) , G erzeugt werden w(4) , ..., G w(M) . Die Cipher-Gamma-Blöcke werden im CM 5- Addierer bitweise modulo 2 mit verschlüsselten Datenblöcken T w(3) , T w(4) ..., T w(M) summiert, wodurch offene Datenblöcke 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.

Imitation Einfügemodus

Um den Nachahmungsschutz offener Daten zu gewährleisten, 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 (Einfügen und 1). Das Generieren eines Inserts ist für alle Verschlüsselungsmodi einheitlich.

Der erste Block offener Daten ist 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 die Laufwerke N 1 und N 2 geschrieben wird , der Wert von t 1(1) = a 1(1) (0) wird in die erste Ziffer N 1 eingefügt, der Wert von t 2(1) = a 2(1) (0) wird in die zweite Ziffer N 1 eingefügt, usw. wird der Wert t 32(1) = a 32(1) (0) in die 32. Ziffer N 1 eingeführt ; 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 im einfachen Ersetzungsmodus gemäß den Anforderungen von Absatz 3.1 einer Umwandlung unterzogen, die den ersten 16 Zyklen des Verschlüsselungsalgorithmus entspricht. Gleichzeitig befindet sich in der KZU derselbe Schlüssel, mit dem die offenen Datenblöcke T 0(1) , T 0(2) , ..., T 0(M) in die entsprechenden Blöcke verschlüsselter Daten T w(1) , T w(2) verschlüsselt werden. ..., TW(M) .

Die nach 16 Betriebszyklen erhaltene Füllung 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)) wird 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 eingegeben und im einfachen Ersetzungsmodus entsprechend den ersten 16 Zyklen des Verschlüsselungsalgorithmus konvertiert.

Die resultierende Füllung N 1 und N 2 wird in CM 5 modulo 2 mit dem dritten Block T 0(3) usw. aufsummiert, wobei der letzte Block T 0(M) = (t 1(M) , t 2(M) , ... , t 64(M) ), optional aufgefüllt auf den vollständigen 64-Bit-Block mit Nullen, wird in CM 5 modulo 2 summiert, wobei 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 aufgezeichnet und in einem einfachen Ersetzungsmodus gemäß den ersten 16 Zyklen des Algorithmus verschlüsselt. Aus der resultierenden Füllung der Laufwerke N 1 und N 2 wählen wir das Segment And l = [a 32 - l +1(M) (16), a 32 - l +1(M) (16), ..., a 32(M) (16) )].

Die Einfügung And l wird über den Kommunikationskanal oder an den Computerspeicher am Ende der verschlüsselten Daten übertragen, d.h. TW(1) , TW(2) , ..., TW(M) und l .

Die empfangenen verschlüsselten Daten T sh(1) , T sh(2) , ..., T sh(M) werden entschlüsselt, aus den empfangenen Blöcken offener Daten T 0(1) , T 0(2) , ..., T 0(M) wird eine Einfügung erzeugt Und 'l , die dann mit einem simulierten Einsatz verglichen wird und l , zusammen mit verschlüsselten Daten von einem Kommunikationskanal oder einem Computerspeicher empfangen wird. Im Falle einer Nichtübereinstimmung der Einfügungen werden die empfangenen 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 in der Einfügung) wird durch die aktuellen kryptografischen Anforderungen bestimmt, wobei berücksichtigt wird, dass die Wahrscheinlichkeit, falsche Daten aufzuerlegen, 2 bis 1 beträgt.