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

Durchbrechen der U-Bahn (Reisekarten) + CRYPTOGRAPHIC TRANSFORMATION ALGORITHMUS NACH GOST 28147-89

Auf der Seite:


Die U-Bahn durchbrechen (Reisekarten)

Kennst du den Wunsch, alle Rätsel zu lösen und alle Verteidigungen der Moskauer Metro aufzudecken? Zum Beispiel, um sich ein "ewiges Ticket" zu machen? Immerhin finden Metro-Experten immer raffiniertere Schutzmethoden. Metallplättchen wurden durch Plastikplättchen ersetzt, die wiederum magnetische Tickets waren, und kontaktlose Karten ersetzten die magnetischen. Viele Forscher haben ihre Hände fallen lassen - es scheint, dass die Metropolitan eine uneinnehmbare Festung geworden ist. Aber jeder Schutz kann umgangen werden. Und oft erweist es sich als viel einfacher zu öffnen als zu bauen ...

Wie alles begann

Ich hatte schon vor langer Zeit ein Interesse an U-Bahnen, man könnte sagen, von der Schule, als noch Fahrkarten mit einem Magnetstreifen im Einsatz waren. Zur gleichen Zeit (vor etwa einem Jahrzehnt) haben sie eine kontaktlose Sozialkarte für Studenten eingeführt. Ich wurde interessiert, was es ist und wie es funktioniert. Aber damals hatte ich nicht genug Fähigkeiten, und es gab wenig öffentliche Informationen, besonders zu diesen Technologien. Ich musste die Idee der Forschung auf Eis legen, aber ich versprach mir, dass ich auf jeden Fall zurückkommen würde ...

Vor etwa drei Jahren erwachte ich wieder für das Thema Metro. Ich habe aktiv Magnetkarten studiert (im Internet gab es viele Informationen zu diesem Thema) und sogar eine kleine Maschine zum Kopieren von zwei Köpfen von Bandrollenrecordern und einer kleinen Menge Lose gesammelt. Ich habe meine Sozialkarte (schon Student) nicht vergessen. Aber nach dem Studium der Dokumentation wurde mir klar, dass das System praktisch uneinnehmbar ist - der MF1S50 Mifare Classic 1K Chip, auf dessen Basis Social-Cards erstellt werden, wird durch zwei 48-Bit-Schlüssel geschützt. Auf der Hardware-Ebene wird Hacking so einfach nicht funktionieren, und Sie können die Tasten bis zum Ende des Sonnensystems berühren. Und für die Karteninhaber, die Classic unterstützen, waren sie zu der Zeit sehr viel Geld wert (ich habe nicht an Ebay gedacht). Das Interesse an Magnetkarten kühlte schnell ab, und die Sozialkarte musste wieder auf bessere Zeiten verschoben werden.

Treffen: "Ultraleicht"

Tickets "Ultralight" erschienen kürzlich in unserer U-Bahn, sorgten aber sofort für großes Interesse in der Öffentlichkeit. Sie fingen an zu töten, zu zerreißen, ein Eisen zu tragen und andere Methoden der thermorektalen Kryptoanalyse anzuwenden. Zugegeben, der Wissensdurst ließ mich ein Paar reißen. Als Ergebnis ihrer Studien und Recherchen im Internet wurde festgestellt, dass dies nichts weiter als Mifare Ultralight, die "leichte" kompatible Version von Mifare Classic ist. Ein kurzer Überblick über die Dokumentation der Chips dieses Standards machte deutlich, dass diese Karten keine eingebetteten Sicherheitssysteme haben. Außerdem griff ich einen Artikel an, in dem es um das erfolgreiche Hacken eines ähnlichen Transportsystems durch holländische Studenten ging. Alles zusammen hat mich zu neuen Forschungen getrieben.

Lass uns gehen!

Natürlich war es nur notwendig, einen kabellosen Kartenleser zu bekommen, der Ultralight unterstützt. Es gab zwei Möglichkeiten: entweder sich selbst zu sammeln (was viel Zeit in Anspruch nehmen würde) oder ein fertiges Gerät zu kaufen. Beim Gedanken an die zweite Option hatte ich angesichts der Preise von vor drei Jahren eine Gänsehaut. Aber ich habe mich immer noch für die aktuellen Preise entschieden. Und aus gutem Grund! Ich war angenehm überrascht zu erfahren, dass Sie ein voll funktionsfähiges Gerät (OmniKey CardMan 5321) kaufen können, das eine Reihe von kabelgebundenen und drahtlosen Karten zu einem attraktiven Preis - 4.000 Rubel - unterstützt.

Natürlich nicht ein bisschen, aber andererseits sind es nicht 10.000; Darüber hinaus ermöglichte es der Kauf eines vorgefertigten Lesers, sich sofort auf die Suche nach Tickets zu konzentrieren und nicht auf die Entwicklung und das Debugging von Hardware, die sich auf unbestimmte Zeit verzögern könnte. Zusammen mit dem Leser wurde ein sehr praktisches Original-SDK der lokalen Produktion von der gleichen Firma (ISBC) gekauft. Auch hier durfte er keine Zeit und Mühe verschwenden, Low-Level- und Debugging-Software mit dem Leser zu schreiben, sondern sich direkt auf die Tickets zu konzentrieren. So entstand für ein paar Tage des gemütlichen Codierens ein kleines Programm, mit dem man die gesamte innere Struktur der Ultralights bequem beobachten und bearbeiten konnte. Dann begann ich, Tickets zu studieren.

Leere Wand

Während des Studiums gingen viele Tickets durch meinen Leser. Einige, ich krempelte meine Ärmel hoch, holte "aus dem Mülleimer", einige kaufte ich - ich schaute auf, was ihnen geschrieben wurde, dann ging ich und schaute wieder. Dies waren fast alle Arten von Tickets, mit der möglichen Ausnahme des Ultralight Pass für 70 Fahrten. Nach ein paar Wochen hatte ich eine große und sortierte Datenbank von Depots verschiedener Tickets und in verschiedenen Staaten. Es wurden auch nach jeder Fahrt ein und dasselbe Ticket aus dem gleichen Ticket genommen, und mehrere Tickets mit in einer Reihe laufenden Metro-Nummern. Es gab sogar mehrere Depots von zwei verschiedenen zeitlich befristeten Unified Social Tickets (eines wurde für einen Zeitraum von 5 Tagen ausgestellt, das andere für 30), die nach einem bestimmten Zeitintervall in meiner Sammlung genommen wurden. Es stellte sich heraus, dass es sehr interessante Exemplare waren und gleichzeitig sehr selten (ich bekam sie aus erster Hand mit sofortiger Rückkehr, nur um "zu lesen").

In der Tat ist es fast die einzige Art von "Ultralight", die nicht nur in der U-Bahn, sondern auch auf dem Landtransport funktioniert. Darüber hinaus hat nur diese Art von Tickets keine Begrenzung der Anzahl der Fahrten. Danach haben sie mir einen tollen Dienst erwiesen ... Ich habe den ganzen Zoo für einen bestimmten Zweck gesammelt - um die Struktur und das Format der Datenaufzeichnung auf dem Ticket klar zu definieren. Natürlich waren einige Felder sofort mit bloßem Auge sichtbar, andere jedoch nicht. Zum Beispiel habe ich nicht sofort verstanden, wo die U-Bahnticketnummer geschrieben ist (die, die darauf gedruckt ist). Das Bewusstsein kam ganz zufällig. Die Tatsache ist, dass ich (wie ich denke, die meisten von uns), auf das Feld schauen, verwendet, um die Informationen für sich selbst auf Bytes auszurichten und mindestens Bytes zu denken. Es stellte sich heraus, dass dieser Ansatz hier falsch ist. Wenn Sie auf den Ticket-Dump schauen, müssen Sie in kleineren Einheiten denken - Tetraden und manchmal Bits. Ich verstand das, als ich schließlich die Ticketnummer sah - sie wurde um 4 Bits relativ zum Anfang des Bytes verschoben, und die restlichen 4 Bits auf beiden Seiten der Nummer wurden von anderen Serviceinformationen belegt. Nach einiger Zeit 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, Identifikatoren gespeichert sind. Es blieben nur ein paar Felder, deren Zweck unklar war, einfach weil die Daten in ihnen von Speicher zu Speicher identisch waren. Aber das war das Ende all der Freude - es wäre töricht anzunehmen, solche Tickets könnten ungeschützt bleiben. Jeder Speicherauszug enthielt 32 Bits verschiedener Informationen, die nicht mit dem Rest des Inhalts korrelierten. Ich nahm an, es war eine Art Prüfsumme, ein "Hash" der auf dem Ticket aufgezeichneten Daten. Alle Versuche, diese 32 Bits zu schätzen oder zu berechnen, stellten sich als ein vollständiger Fehler heraus (insbesondere wurde angenommen, dass dies eine Art von CRC32 mit einem Nicht-Standard-Polynom und Startwert war).

Bei dem Versuch, mindestens eineinhalb Bits an Informationen innerhalb des Tickets zu ändern, blinkte das Terminal, das in der U-Bahn eincheckte, "BAD TICKET" und wog die letzten Nägel im Sarg mit einem schweren Wagenheber. Natürlich gab es Versuche, das System auf andere Weise zu umgehen, zum Beispiel um zu versuchen, ein Ticket auf eine leere Eins-zu-Eins-Karte zu kopieren (hier leider verhindert die Factory-Serial, die auch an der Generierung des Hash beteiligt war) oder die Lock-Bits zu setzen um zu verhindern, dass das Drehkreuz den Inhalt des Tickets ändert. Das Test-Terminal erkannte ein solches "ewiges" Ticket, weigerte sich aber, das Drehkreuz zu lassen ... So rannte ich in die Wand. In der großen, starken Betonmauer, auf der viele die Gewohnheit haben, sich zu töten. Da ich keine Informationen in den Foren und Foren fand, entschied ich, dass meine Forschung damit abgeschlossen war - es gab keine Wege mehr, und ich habe einen fetten Punkt angeführt. Wie sich herausstellte, nichts ...

Seltsame Bekanntschaft

Der Septemberabend unterschied sich nicht von anderen. Die Nacht war fast da, draußen war es kühl und feucht. Ich saß vor dem Bildschirm, trank einen warmen, leicht süßlichen grünen Tee und teilte friedlich eine Gebühr für mein nächstes Handwerk. DipTarce, ein bisschen Bashorga, ICQ ... Jemand hat Skype angerufen - ablenkend! Wieder ICQ, wieder DipTrace - alles ist wie immer. Wieder einmal fiel das ICQ-Fenster in den Vordergrund - jemand, der mir unbekannt ist, schrieb "Hallo". Ich antwortete ohne Zweifel dasselbe. Die folgende Nachricht war ein Wendepunkt in der ganzen Geschichte: "Du interessierst dich für die U-Bahn, ich habe ein paar Sachen hier. Wenn Sie interessiert sind, lassen Sie uns treffen, ich werde es dir sagen. " Zuerst war ich ein wenig peinlich berührt und alarmiert (vielleicht eine Scheidung oder ein Setup, oder vielleicht wurden die "speziellen Dienste" interessiert - die Paranoia fordert ihren Tribut), aber dann dachte ich: warum nicht?

Die Geheimdienste hätten sich kaum für mich interessiert und es scheint keinen Grund für eine Scheidung und noch mehr für das Setup zu geben. Nach einer kurzen Unterhaltung vereinbarten wir, uns am Nachmittag in der Mitte der Halle einer der Stationen der Moskauer U-Bahn zu treffen. Der Fremde war ein großer junger Mann mit Brille und einer großen schwarzen Plastiktüte in den Händen. Wir begrüßten uns, dann reichte er mir ein Paket mit den Worten: "Auf, halt. Es funktionierte immer noch nicht für mich, es könnte für dich nützlich sein. " Als ich nach innen schaute, sah ich zwei U-Bahn-Terminals, die von Zeitungen verschoben wurden, ein paar zufällig verstreute weiße Plastikkarten und eine leere Schachtel. Als ich fragte, wie viel ich dafür schulde, schüttelte der Typ den Kopf, lächelte und sagte: "Warum, niemandem ist irgendwer etwas schuldig, tu es ... Also muss ich schon rennen, mein Zug ist wie Zeit! Komm schon, tschüss! "

Mit diesen Worten rannte er davon, sprang in die bereits schließenden Türen des Wagens und ging. Und ich, ich gestehe, ich bin ein wenig in neponyatka nach Hause gegangen. Ich löschte den Kontakt von ICQ nur für den Fall, gleichzeitig die Kontaktliste auf dem Server zu säubern und die Protokolle aufzuräumen (hallo wieder, Paranoia). Schreib am Ende noch einmal, wenn das so ist. Aber je mehr schrieb er mir nie ...

Das Phänomen der Software für die Menschen

Als ich nach Hause kam, zerlegte ich das Paket. Das zweite Terminal erwies sich als Bus-Validator (schwer, verdammt!); Die Karten waren Mifare Classic 1K (sauber), und auf der Festplatte befand sich ein einziges Archiv. Nach einer kurzen Bekanntschaft mit dem Inhalt stellte sich heraus, dass es sich um die Software handelt, die an den Fahrkartenschaltern der Metro verwendet wird. Ich legte das Terminal und den Validator beiseite und beschloss, mich mit dem Studium interessanter Software zu beschäftigen. In ungefähr einer Stunde von der Unordnung, die ausgepackt wurde, konnte ich dieses Programm auf meinem Computer aufbauen und ausführen. Es dauerte eine weitere Stunde, um seine Struktur herauszufinden. Nachdem ich alle Ini-Dateien durchgekämmt hatte (mit Kommentaren, die freundlicherweise vom Entwickler hinterlassen wurden), hatte ich bereits eine vollständige Vorstellung davon, was es ist, wie es funktioniert und was es isst. Essen, wie sich herausstellte, mit dem Leser Parsec PR-P08, deshalb, in Abwesenheit davon, war es nicht möglich, die Software in der Handlung zu versuchen.

Der Entwickler war Smartek, ein bedeutender Auftragnehmer der Regierung, der Systeme dieser Art entwickelt (weitere Informationen finden Sie auf deren Website). Das Programm wurde in Delphi mit Laufzeit-bpl'ok geschrieben. Darüber hinaus war die Software modular aufgebaut und alle Subroutinen, Klassen und Komponenten befanden sich in separaten DLLs oder BPLs mit sprechenden Namen (dies war die wichtigste Entwicklungsdatei). Nach einer kursorischen Analyse der internen Software fand ich heraus, dass zum einen Informationen über alle ausgestellten Tickets in eine zentrale Datenbank übertragen werden (übrigens ist das Oracle) und zum anderen nutzt das Programm eine Art Schlüsselmechanismus. Das Programm könnte nicht nur in Echtzeit mit der Datenbank kommunizieren. Wir ziehen Schlussfolgerungen: Alle Operationen im System können mit einer gewissen Verzögerung auftreten. Theoretisch gibt es uns einen Vorsprung.

Aber zuerst war ich an dem Schlüsselmechanismus interessiert (ich habe schon angefangen zu erraten, warum das nötig sein könnte). Also nahm ich den Disassembler 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, abgesehen von der Datei mit den Schlüsseln, nicht mehr wie alles aussieht). Und genossen all diese guten Laufzeit-bpl'ina SmLayout.bpl. Diese Bibliothek war nur ein Glücksfall für meine Recherchen - sie enthielt Klassen für das interne Ausfüllen von Tickets. Da es sich um Runtime-Bpl handelt, reichte es aus, nur auf seine Exporttabelle zu schauen, so dass bei 60 Prozent klar wäre, was passiert. Eine detailliertere Analyse bringt alles an seinen Platz. Erinnern Sie sich, am Anfang des Artikels habe ich gesagt, dass in der Struktur des "Ultralight" noch einige Felder waren, deren Zweck nicht klar war?

Eines dieser Felder ist die sogenannte "Layout-Kennung". Alle Metro Tickets bestehen aus einem festen Header und einem variablen Teil der Daten. Also, dieses "Layout" -Feld in der Kopfzeile hat gerade definiert, wie und welche Daten im Rest des Tickets liegen. Es gibt mehrere solche Layouts (jeweils für ihren eigenen Tickettyp), und in SmLayout.bpl hatte jeder von ihnen seine eigene Klasse (plus eine gemeinsame Elternklasse, die Methoden zum Arbeiten mit dem Header-Teil hatte). Daher war es leicht herauszufinden, für welche Felder in welchem ​​Layout sie zuständig sind (selbst mit den Namen der Methoden beim Export!). Nachdem ich das gesamte Layout 8 (das im "Ultralight" verwendet wurde) fertiggestellt hatte und nach der Überprüfung, ob ich die richtigen Ideen für alle Felder in der Ticketstruktur hatte, nahm ich den Schlüsselmechanismus auf. In der Tat war er verantwortlich für die Generierung des Hash. Wie der Mechanismus funktioniert, wurde nach dem Studium der Arbeit der Methode, die für die Berechnung des "Hash" verantwortlich ist, völlig klar. Zuerst wird der richtige Schlüssel aus der Schlüsseldatei (keys.d) ausgewählt.

Das System ist so konzipiert, dass jeder Tickettyp seine eigene Kennung hat (es gab eine vollständige Tabelle mit Bezeichnern und Ticketnamen in Form einer Textdatei mit durch Komma getrennten Werten). Es besteht aus einer Zonen-ID (Anwendung) und einem Kartentyp-Identifikator. Basierend auf diesen Nummern wird der Schlüsselring in der Schlüsseldatei ausgewählt, in der möglicherweise bereits mehrere Schlüssel vorhanden sind (falls ein neuer Schlüssel eingegeben wird und die alten Tickets noch verwendet werden). Das neue Ticket wird mit dem ersten Ticket erfasst und die Gültigkeitsprüfung erfolgt mit allen Schlüsseln im Schlüsselbund. Als nächstes wird der ausgewählte Schlüssel mit CryptKeyRef.dll entschlüsselt (warum sind sie verschlüsselt gespeichert, ich werde mich nicht daran binden). Danach werden der entschlüsselte Schlüssel und fast alle Ticketdaten sowie seine Seriennummer und Nummer der Hardware (die "Hash" -Erzeugungsmethode, die für die Eingabe von keys.d angegeben wurde) an die ckCalcHashCode-Funktion übertragen, die sich in derselben CryptKeyRef.dll befindet. Am Ausgang bekommen wir den Wert, an dem ich einmal "klebte" - der gleiche "Hash". Natürlich habe ich ein kleines Programm geschrieben, das mit diesen Funktionen aus CryptKeyRef.dll und der Datei keys.d den Hash in jedem Dump überprüfen und in diesem Fall neu zählen kann. Ich habe alles auf mehreren Müllkippen nachgeprüft, und, ein positives Ergebnis erhalten, bin zufrieden gegangen, um zu schlafen.

Faule Schlüssel

Trotz des theoretischen Erfolgs wollte ich sozusagen "im Kampf" alles überprüfen. Am nächsten Tag, als ich von der Arbeit zurückkam, kaufte ich bewusst ein neues "Ultralight" für eine Reise, um zu sehen, ob meine Schlüssel gültig waren oder nicht (anscheinend waren sie alt). Man könnte natürlich sofort versuchen, das "fabrizierte" "Ultralight" aufzuschreiben und nachsehen, aber zu dieser Zeit waren mir die leeren Karten ausgegangen, und sogar ein bisschen gruselig, um "zufällig" zu gehen - was wäre, wenn? Als ich nach Hause kam, eilte das erste, was ich tat, ohne mir die Hände zu waschen, eifrig nach dem frischen Ticket mit meinen eigenen Schlüsseln. Und dann wartete ich auf eine große Enttäuschung - der im Ticket aufgezeichnete "Hash" passierte keinen der Schlüssel. Daher sind die Schlüssel wirklich verfault und sie wurden durch neue ersetzt. Das hat alle meine Arbeiten völlig durchkreuzt. Ich war ein wenig traurig. Ich habe grünen Tee gebraut, ein bisschen Klavier gespielt (ja) und mich hingesetzt, um meine unvollendete Gebühr zu erhöhen ...

Alles ist nicht verloren

Die Idee kam mir unerwartet, als ich aus irgendeinem Grund noch einmal mit den Schlüsseln in die Datei schaute. Ich habe bemerkt, dass es im "running" Schlüsselring (der zur Berechnung von 1-, 2-, 5-train und anderen "Ultralights" verwendet wird) zwei Schlüssel gab - einen neuen (damals natürlich) und anscheinend einen alten. Aber es gab auch einen Schlüsselring, in dem nur ein Schlüssel war. Zuvor habe ich nicht auf ihn geachtet und mich auf das "Laufen" konzentriert. Um zu berechnen, welche Tickets dieser Schlüssel verwendet wird, wusste ich nicht. Als ich mir ansah, welche Art von Ticket an den Schlüsselbund gebunden ist, hatte ich einen kleinen Funken Hoffnung. Tatsache ist, dass diese Art von Ticket war - WESB. Ja, diese seltene Art von Ticket ist ein temporäres Ticket für alle Arten von Transport. Ich dachte mir, dass der Schlüssel, wenn das Ticket einzeln ist, nicht nur in der U-Bahn, sondern auch im Bodentransport verwendet werden sollte, wo es sehr schwierig und lang ist, es durch ein neues zu ersetzen.

Außerdem ist der Schlüssel im Schlüsselring nur einer, der meine Vermutung indirekt bestätigt. Alles andere erinnerte ich mich daran, dass, als ich das U-Bahn-Programm von verschiedenen "Müll" säuberte, etwas ähnlich einem Archiv alter Schlüsseldateien war. Nachdem ich das Originalarchiv ausgegraben und geöffnet hatte, sah ich, dass dies tatsächlich der Fall war. Und am wichtigsten, nachdem ich alle alten Schlüsseldateien überprüft hatte, entdeckte ich, dass dieser Schlüssel unverändert geblieben war! Schon ohne einen einzigen Zweifel hatte ich meinen eigenen VESB genietet (glücklicherweise hatte ich Dumps dieser Art, die die Aufgabe manchmal vereinfachten - ich habe gerade Daten und Zahlen in Dumps geändert) und den Hash mit diesem Schlüssel berechnet. Also, es ist Zeit zu überprüfen (vor allem, da ich gerade mehr sauberes Plastik gekauft habe). In der Lobby angekommen, habe ich zuerst mein "Ticket" an das Test-Terminal angeschlossen. Das Display zeigte den Gültigkeitszeitraum des Tickets an, den ich anzeigte, und die grüne LED ging an. So funktioniert es. Nachdem ich eine Grimasse einfacher gemacht hatte und den weißen Plastik in einem Ärmel verbarg, ging ich zum Drehkreuz, legte meine Hand zum Validator und ... ging ruhig zum grün-grünen Licht-emittierenden Feuer weiter. Dies markierte den endgültigen Sieg.

Und was als nächstes?

Und dann begannen die Experimente, bei denen viele interessante Dinge entdeckt wurden. Zum Beispiel, auf einer solchen "linken" VESB kann nur zwei oder drei Tage gehen. Tatsache ist, dass die Zahl, die ich "von der Glatze" innerhalb des Tickets anzeige, mit jedem Durchlauf im Speicher des Kopfes des Drehkreuzes gespeichert wird und nach einiger Zeit zusammen mit den anderen zum Datenzentrum gesendet wird. Dort findet das System kein wirklich ausgestelltes Ticket mit dieser Nummer und legt es in die Stoppliste, die dann an alle Drehkreuze der Metro gesendet wird. Und dies sollte bei allen Arten von Tickets der Fall sein, nicht nur bei VESB - neben dem "Hash" und häufig wechselnden Schlüsseln ist dies ein sehr guter Schutz. Aus offensichtlichen Gründen ist dies nicht möglich.

Es wurde auch angemerkt, dass das Setzen oder Nicht-Setzen der Sperrbits nicht wichtig ist, ob das Ticket funktioniert oder nicht. Die einzige Ausnahme ist das Sperrbit der OTP-Zone, das das Drehkreuz scheinbar immer überprüft, obwohl es nicht in das OTP schreiben wird. Später nahm ich die U-Bahn- und Busterminals, ordnete sie an, studierte und startete auf dem Stand. Um die nächste Schätzung zu überprüfen, war es nun nicht mehr nötig, mit dem neu gebackenen Mutantenticket in der U-Bahn zu fahren, und es wurde möglich, sie zu überprüfen, "ohne von der Fahrkartenstelle abzuweichen". Außerdem entpuppte sich das U-Bahn-Terminal als gleich alt (alles andere ist fehlerhaft), genau wie meine Schlüssel. Also könnte ich "bei der Arbeit" und andere Arten von "Ultralight" -Tickets versuchen - etwas, was ich niemals "live" in der U-Bahn machen kann. Parallel zu diesen Experimenten habe ich mich weiterhin mit Software beschäftigt.

Da es viele Kontroversen darüber gab, welche Art von Algorithmus bei der Berechnung des "Hash" verwendet wird, beschloss ich, ihn vollständig wiederherzustellen, indem ich den Algorithmus in der "menschlichen" Programmiersprache von Grund auf neu schrieb und dabei hoffte, zu verstehen, um was für einen Algorithmus es sich handelt. etwas weithin Bekanntes oder eine eigene, interne Entwicklung. Auf dem Weg wurde ich von vielen verschiedenen Gedanken (einschließlich, dass es AES sein könnte) besucht, aber wenn ich den bereits funktionierenden Code im Detail studierte, ohne die Smart Library Bibliotheken zu verwenden, stellte sich heraus, dass dieser Algorithmus "nur" GOST ist - ein nationaler Verschlüsselungsstandard (alle notwendigen Informationen über ihn kannst du leicht im Web finden). Insbesondere wurde ein 16-W-Zyklus verwendet, um den Hash zu berechnen. "Hash" ist tatsächlich nichts anderes als eine Imitation von GOST.

Die Struktur der auf dem Ticket "Ultralight" aufgezeichneten Informationen

Was ist die Seite, wo und wie sind die Hardware-Seriennummer, die Lock-Bits und die OTP-Zone, können Sie die Original-Dokumentation lesen (eine PDF-Datei mit einer vollständigen Beschreibung des Chips befindet sich auf der Festplatte). Ich empfehle, daraus zu lernen. Ich werde die Struktur des Ortes der Daten beschreiben, die von den Metrosystemen im Benutzerbereich erzeugt werden, der zum Lesen und Umschreiben verfügbar ist (natürlich ohne Sperren). Der gesamte Inhalt des Tickets kann in den Header-Teil und die zwei vollständig duplizierten Teile der Daten unterteilt werden (dies geschieht zum Zweck der Reservierung und des Schutzes vor Fehlern). Der Überschriftsteil der Tickets "Ultralight" beginnt auf Seite 4. Ein Teil davon ist in allen Tickets und Identifiern des Metropolitan Systems und MosGoTrans in der Struktur identisch. Die ersten 10 Bits sind die Anwendungskennung; Die nächsten 10 Bits sind die Kennung des Kartentyps (Sie können darüber lesen, welche Kennungen sich zu diesem Zweck in einer anderen speziellen Box befinden). Nach dem Identifikator ist die Seriennummer des Tickets (es ist auf der Rückseite des Tickets gestempelt, verwechseln Sie es nicht mit der Hardware - das sind zwei verschiedene Dinge!) 32 Bits in der Größe. Die letzten 4 Bits sind das Feld Layout, das dem System mitteilt, wie die nachfolgenden Daten zu interpretieren sind (etwa ein Dateiformat).

Bei Ultralight-Tickets ist der Layout-Wert 0x08. Gleichzeitig endet der Titel. Ferner zeigt das Ticket "Ultralight" das Datum an, an dem das Formular gültig ist (16 Bits). Alle Daten im System sind im Format der Anzahl der Tage seit dem 1. Januar 1992 angegeben. Hier endet der Header-Teil des Ultralight-Tickets (in Tickets mit einem anderen Layout können noch diverse Zusatzinformationen aufgenommen werden). Der erste Datenbereich beginnt auf Seite 8. Zunächst werden 16 Bits des Ticketausgabedatums aufgezeichnet. Danach wird die Gültigkeitsdauer des Tickets in Tagen (ab dem Zeitpunkt der Ausgabe) angegeben - 8 Bits. Die ersten 16 Bits von Seite 9 sind der Auslösezähler. Es kann entweder auf Null (in allen Tickets mit einer begrenzten Anzahl von Fahrten) oder auf Null (in VESB-Fahrkarten, ohne die Anzahl der Fahrten einzuschränken) sein. Nach dem Zähler im Rest der Seite gibt das Drehkreuz bei jedem Durchlauf seine eindeutige Kennung ein. Offensichtlich wird dies verwendet, um einen erneuten Zugang zu verhindern, ohne auf ein VESB-Ticket zu warten (Drehkreuze in der Lobby sind mit dem Netzwerk verbunden und verhören sich gegenseitig), sowie um zu sehen, welches Drehkreuz passiert 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 (von 12 bis 15) repliziert. Es stellt sich heraus, dass diese beiden Bereiche im Normalbetrieb immer die gleichen Daten enthalten. Unabhängig davon sollte die Nutzung der OTP-Zone durch das System erwähnt werden. Es wird für das allmähliche "Ausbrennen" eines Tickets mit jeder Fahrt verwendet (dies gilt nicht für VESB-Tickets). Die zwei untersten Bits werden gesetzt, wenn das Ticket storniert oder storniert wird (durch Stoppliste). Ein storniertes Ticket kann nicht wiederhergestellt werden. Nur 30 Bits sind zum Ausbrennen übrig. Diese Zone wird vom System als 100% der Fahrten dargestellt. Bei jeder neuen Fahrt wird eine bestimmte Anzahl von Bits gesetzt (von den jüngsten bis zu den ältesten), entsprechend der prozentualen Anzahl, die eine Fahrt benötigt. Zum Beispiel wird für eine 5-Bahn-Fahrkarte jede neue Fahrt um 6 Bits "ausgebrannt", und für eine 60-Zug-Fahrkarte ein halbes (aufgerundet). Es ist erwähnenswert, dass die Wiederverwendung von Ultralight-Tickets nicht nur wegen des OTP-Ausbruchs unmöglich ist, sondern auch aufgrund der Tatsache, dass an der Kasse beim Ausstellen eines Tickets (und vielleicht sogar wenn es gemacht wird) fast alle Seiten für das Neuschreiben gesperrt sind . Weder "neu laden" noch den Typ des Tickets zu einem anderen ändern wird nicht funktionieren.

Beispiele für verwendete Metro-Ticket-IDs

Alle Zahlen sind in Dezimalschreibweise!

Anwendungs-IDs:

  • 262 - Moskauer Metro-Ticket.
  • 264 - Moskauer Landtransportticket.
  • 266 - Vereintes Soziales von Moskau und der Moskauer Region.
  • 270 - Einfaches Metroticket.

Identifikatoren der Art der Tickets "Ultralight":

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

Mifare Klassiker

Ich habe die unglückselige Mifare Classic 1K nicht in meiner Forschung ignoriert. Wie du verstehst, waren die Hauptschlüssel der "Klassiker" die Hardwareschlüssel A und B. Glücklicherweise lagen diese Schlüssel in einem der Module des Programms in offener Form (den Entwicklern vorgelegen!) Und es war nicht schwer für mich, ein kleines Programm zu schreiben arbeiten Sie mit den Inhalten dieser Karten mit den erhaltenen Schlüsseln. Im Verlauf der Experimente wurden einige interessante Merkmale aufgedeckt, wie zum Beispiel: die U-Bahn zum Speichern des Tickets verwendet den ersten Sektor der Karte, und der Bodentransport den vierten; kein Schutz außer den Hardware-Schlüsseln (die in dieser Form höchstwahrscheinlich seit der Inbetriebnahme des Systems überhaupt nicht verändert wurden) existiert auf diesen Tickets nicht.

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

Aber wie sich herausstellte, speichert das Stop-List-System das Klonen perfekt - ein solches Ticket kann maximal zwei Tage lang benutzt werden, dann wird es abgebrochen (obwohl die Classic-Karte im Gegensatz zu Ultralight nach der Stornierung wieder hergestellt werden kann, aber aus der Stop-Liste) es wird nicht gespeichert). Da auf Classic-Karten kein Schutz verwendet wurde, wurden sie für mich schnell uninteressant und ich beschloss, mich auf die Erforschung von Ultralight zu konzentrieren.

Das Ende oder die Summe

Metro-Systeme und insbesondere die neuen Ultralight-Tickets erwiesen sich entgegen Meinungen und Vermutungen als gut geschützt. Sehr erfreut, dass die Entwickler bewährte und bewährte GOST verwendet haben und das Rad nicht neu erfunden haben. Mit einem solchen Schutz ist es einfach unmöglich, das Ultralight-Ticket zu fälschen, ohne Zugang zu vertraulichen Daten (Schlüsselinformationen) zu haben. Das Schlüsselsystem und der Sperrlistenmechanismus sind ebenfalls gut durchdacht. Natürlich nicht ohne Fehler und Fehler. Die größte von ihnen ist Software, die überhaupt nicht geschützt ist.

Es war genug, um die Verwendung von Runtime-bpl aufzugeben, und dies würde die Analyse zehn mal schwieriger machen! Alternativ würde die Verarbeitung von besonders wichtigen Teilen des Programms durch AsProtect oder ExeCryptor, gefolgt von dem Packen aller Dateien mit MoleBox, die Möglichkeit der Analyse auf fast Null reduzieren. Das Toolkit ist preiswert. Und die Verwendung eines guten (vorzugsweise wenig bekannten oder maßgeschneiderten) Schutzes dieser Art, aber mit Hardware-Schlüsseln würde die Analyse des Programms vollständig unmöglich machen. Natürlich ist die Metropolitan ein Regime-Unternehmen, aber man sollte den Faktor Mensch nicht vergessen. Schließlich hat Kevin Mitnick auch gesagt (und nicht nur gesprochen, sondern auch mit gutem Beispiel gezeigt, wofür er saß), dass es manchmal einfacher und effektiver ist, "Social Engineering" zu verwenden, um das Ziel zu erreichen als die undurchdringliche Verteidigung zu durchbrechen. Nun, in diesem Sinne werde ich meine Geschichte beenden. Und Sie, der Leser, wünschen Ihnen mehr interessante und erfolgreiche Recherchen!








Beschreibung des kryptographischen Transformationsalgorithmus nach GOST 28147-89

Dieser Standard etabliert einen einheitlichen Algorithmus für die kryptographische Transformation für informationsverarbeitende Systeme in Netzwerken von elektronischen Computern (Computern), einzelnen Computerkomplexen und Computern, der die Regeln für die Datenverschlüsselung und die Erzeugung von Imitationen bestimmt.

Der kryptographische Transformationsalgorithmus ist für eine Hardware- oder Software-Implementierung ausgelegt, erfüllt die kryptografischen Anforderungen und stellt in seinen Fähigkeiten keine Beschränkungen für den Geheimhaltungsgrad der geschützten Informationen bereit.

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

Strukturschema der kryptographischen Transformation

Das Blockdiagramm des kryptographischen Transformationsalgorithmus (Kryptoschema), das in 1 gezeigt ist, enthält:

  • - Schlüsselspeichervorrichtung (256 Bits) für 256 Bits, 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 С 2 , 1 1 Füllkonstanten, die in ihnen aufgezeichnet sind;
  • - zwei 32-Bit-Addierer modulo 2 32 (CM 1 , CM 3 );
  • - 32-Bit-Addierer für bitweise Summe Modulo 2 (CM 2 );
  • - 32-Bit-Moduloaddierer (2 32 -1) (CM 4 );
  • - Addierer Modulo 2 (CM 5 ), die Grenze für die Breite des Addierers CM 5 wird nicht auferlegt;
  • - Substitutionseinheit (K);
  • - das zyklische Schieberegister für elf Schritte in Richtung der Senior-Ziffer (R).

Abbildung 1.

Der Substitutionsblock K besteht aus acht Ersatzknoten K1, K2, K3, K4, K5, K6, K7, K8 mit je 64 Bit Speicher. Der am Substitutionsblock eintreffende 32-Bit-Vektor wird in acht aufeinanderfolgende 4-Bit-Vektoren unterteilt, von denen jeder durch den entsprechenden Ersatzknoten, der eine Tabelle von 16 Zeilen mit vier Füllbits in einer Zeile ist, in einen 4-Bit-Vektor umgewandelt wird. Der Eingabevektor bestimmt die Adresse der Zeile in der Tabelle, das Füllen dieser Zeile ist der abgehende Vektor. Dann werden die 4-Bit-Ausgangsvektoren sequentiell zu einem 32-Bit-Vektor kombiniert.

Mit der Hinzufügung und zyklischen Verschiebung von binären Vektoren werden die höchstwertigen Stellen als Bits von Antrieben mit großen Zahlen betrachtet.

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

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

Der Wert der konstanten Füllung mit 1 (Konstant) Antrieb N 6 ist in Tabelle 1 angegeben.

Tabelle 1

Antriebsentladung N 6

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Antriebsentladung N 6

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

Der Wert der konstanten Füllung mit 2 (Konstant) Antrieb N 5 ist in Tabelle 2 angegeben.

Tabelle 2

Antriebsentladung N 5

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Antriebsentladung N 5

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Wert der Entladung

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

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

Das Füllen der Tabellen des Substitutionsblocks K 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 verwenden, im einfachen Ersetzungsmodus Schlüssel zu erzeugen (KZU auszufüllen) und sie im einfachen Ersetzungsmodus zu verschlüsseln, indem ein Nachahmungsschutz für die Übertragung über Kommunikationskanäle oder die Speicherung im Computerspeicher vorgesehen wird.

Es gibt vier Arten von Arbeiten im Kryptosystem:

  • - Verschlüsselung (Entschlüsselung) von Daten im einfachen Ersetzungsmodus;
  • - Verschlüsselung (Entschlüsselung) von Daten im Gamming-Modus;
  • - Verschlüsselung (Entschlüsselung) von Daten im Gammating-Modus mit Rückmeldung;
  • - Art der Produktion

Einfache Ersatzverschlüsselung

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

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


Abbildung 2

Offene Daten, die verschlüsselt werden sollen, sind in Blöcke von jeweils 64 Bits unterteilt. 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äre Information in Die Antriebe N 1 und N 2 werden so erzeugt, dass der Wert von 1 (0) in die erste Ziffer von N 1 eingegeben wird, der Wert von a 2 (0) in die zweite Ziffer von N 1 eingegeben wird, usw., der Wert von a 32 ( 0) wird in der 32. Kategorie von N 1 eingetragen ; der Wert von b 1 (0) wird in die erste Ziffer von N 2 eingegeben, der Wert von b 2 (0) wird in die zweite Ziffer von N 2 eingegeben, usw., der Wert von b 32 (0) wird in die 32. Ziffer von N 2 eingegeben. Das Ergebnis ist der Zustand (a 32 (0), a 31 (0), ..., a 2 (0), 1 (0)) Antrieb N 1 und der Zustand (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) des Antriebs N 2 .

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

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

Der 64-Bit-Open-Data-Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus besteht aus 32 Zyklen.

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

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

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

In den letzten acht Zyklen von der 25. bis zur 32. Leserichtung sind die Füllungen der KZU umgekehrt: X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Daher wird beim Verschlüsseln in 32 Zyklen die folgende Reihenfolge zum Auswählen von Füllungen von Laufwerken durchgefü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, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X.

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

Nach dem 32. Zyklus des Verschlüsselns der Füllung der Laufwerke N 1 und N 2 wird ein Block verschlüsselter Daten erhalten, die einem Block offener Daten entsprechen.

Verschlüsselte Daten im einfachen Ersetzungsmodus entschlüsseln

Ein Verschlüsselungsschema, das einen Entschlüsselungsalgorithmus im einfachen Ersetzungsmodus implementiert, hat die gleiche Form (siehe 2) wie beim Verschlüsseln. In der KZU geben Sie 256 Bits des gleichen Schlüssels ein, auf dem die Verschlüsselung ausgeführt wurde. Die zu entschlüsselnden verschlüsselten Daten sind in Blöcke von jeweils 64 Bits unterteilt. Geben Sie einen beliebigen Block T W = (a 1 (32) und 2 (32), ... und 32 (32), b 1 (32), b 2 (32), ..., b 32 (32)) in die Laufwerke N ein 1 und N 2 wird so gemacht, dass der Wert von 1 (32) in die erste Ziffer von N 1 eingegeben wird, der Wert von a 2 (32) in die zweite Ziffer von N 1 eingegeben wird, usw., der Wert von a 32 (32) ist in der 32. Kategorie von N 1 eingetragen ; der Wert von b 1 (32) wird in die erste Ziffer von N 2 eingegeben, der Wert von b 2 (32) wird in die zweite Ziffer von N 2 usw. eingegeben, der Wert von b 32 (32) wird in die 32. Ziffer von N 2 eingegeben.

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

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

Erhalten nach 32 Arbeitszyklen füllt die Antriebe N 1 und N 2 einen offenen Datenblock.

T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)), entsprechend einem Block verschlüsselter Daten, der Wert von 1 (0) von Block T 0 entspricht dem Inhalt der ersten Ziffer N 1 , der Wert von a 2 (0) entspricht dem Inhalt der zweiten Ziffer N 1 usw., der Wert a 32 (0) entspricht dem Inhalt 32 n Entladungsnummer 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 der 32. Ziffer N 2 .

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

Gamma-Modus

Verschlüsseln Sie offene Daten im Gamming-Modus

Das Verschlüsselungsschema, das den Verschlüsselungsalgorithmus im Gamming-Modus implementiert, sollte die in 3 gezeigte Form haben.


Abbildung 3

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

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

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

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

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

Die Erstbefüllung der Antriebe N 1 und N 2 (Synchrophase S) wird im einfachen Ersetzungsmodus gemäß den Anforderungen des Absatzes 1.3.1 verschlüsselt. Das Ergebnis der Verschlüsselung wird in 32-Bit-Laufwerken N3 und N4 neu geschrieben, so dass das Füllen von N1 in N3 neu geschrieben wird und das Füllen von N2 in N4 umgeschrieben wird.

Das Füllen des N 4 -Laufwerks wird in dem CM 4 -Addierer mit der 32-Bit-Konstanten C 1 von dem N 6 -Antrieb modulo (2 32 -1) summiert, das Ergebnis wird in N 4 geschrieben .

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

Das Füllen von N3 wird zu N1 umgeschrieben, und das Füllen von N4 wird zu N2 umgeschrieben, während das Füllen von N3, N4 beibehalten wird.

Die Füllung N 1 und N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Absatz 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 , N 2 bildet den ersten 64-Bit-Block des Chiffriercodes G W(1) , der bitweise modulo 2 im Addierer CM 5 mit dem ersten offenen 64-Bit-Datenblock T 0(1) = (t 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) = (& tgr; 1(1) , & tgr; 2(1) , ..., & tgr; 63(1) , & tgr;64(1) ).

Der Wert τ 1(1) des Blocks T ш(1) ist das Ergebnis der Summe modulo 2 in CM 5 des Wertes t 1(1) des Blocks T 0(1) mit dem Wert der ersten Ziffer N 1 , dem Wert τ 2(1) des Blocks T W(1) ist das Ergebnis der Summe modulo 2 in CM 5 t 2(1) aus Block T 0(1) mit dem Wert der zweiten Kategorie N 1 usw., der Wert τ 64(1) des Blocks T w(1) ist das Ergebnis des Addierens von Modulo 2 in CM 5 t 64(1) von Block T 0(1) mit dem Wert der 32. Stelle N 2 .

Für den nächsten 64-Bit-Gammablock der Chiffre G w(2) wird die Füllung von N 4 im Addierer CM 4 mit der Konstanten 1 1 von N 6 modulo (2 32 -1) summiert, die Füllung N 3 wird im Addierer CM 3 zu Modulo 2 32 summiert mit einer konstanten C 2 von N 5 . Die neue Füllung von N 3 wird zu N 1 umgeschrieben, und die neue Füllung von N 4 wird zu N 2 umgeschrieben, während die Füllung von N 3 und N 4 beibehalten wird.

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

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

Entschlüsselung verschlüsselter Daten im Gamming-Modus

Beim Entschlüsseln ist das Kryptoschema das gleiche wie beim Verschlüsseln (siehe Abbildung 3). In der KZU werden 256 Bits des Schlüssels eingegeben, mit denen 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.

Gamma-Modus mit Feedback

Verschlüsselung von offenen Daten in gamming mit Feedback

Ein Krypto-Schema, das den Gamming-Modus mit Feedback implementiert, sollte die Form haben in 4 gezeigt.


Abbildung 4

Offene Daten, unterteilt in 64-Bit-Blöcke T 0(1) , ..., T 0(M) , werden im Gamming-Modus mit Rückkopplung durch eine bitweise Modulation modulo 2 im CM 5 -Addierer mit dem Gamut der Chiffre G W verschlüsselt, der in Blöcken von 64 Bits, d.h. Ä = ( Ä(1) , Ä(2) , ..., Ä( M ) ), wobei M - durch die Menge der verschlüsselten Daten bestimmt wird, Ä(i) ist der i-te 64-Bit-Block, i = 1 ÷ Ì. Die Anzahl der Binärstellen im Block T 0(M) darf weniger als 64 betragen.

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

Die Erstbefüllung der Laufwerke N1 und N2 wird im einfachen Ersatzmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 und N 2 bildet den ersten 64-Bit-Block des Gamma-Chiffre G W(1) , der bitweise Modulo 2 im Addierer CM 5 mit dem ersten offenen 64-Bit-Datenblock T 0(1) = (t 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) = (& tgr; 1(1) , & tgr; 2(1) , ..., & tgr; 63(1) , & tgr;64(1) ).

Der Block von verschlüsselten Daten T b(1) ist auch der Anfangszustand N 1 , N 2 zum Erzeugen des zweiten Blocks der Chiffre Gamma G (2) und wird durch Rückkopplung zu den spezifizierten Antrieben zurückgeschrieben. Der Wert τ 1(1) wird in die erste Ziffer N 1 eingegeben, der Wert τ 2(1) wird in die zweite Ziffer N 1 usw. eingegeben, der Wert τ 32(1) wird in die 32. Ziffer N eingegeben 1 ; der Wert τ 33(1) wird in die erste Ziffer von N 2 eingegeben, der Wert τ 34(1) wird in die zweite Ziffer von N 2 usw. eingegeben, der Wert von τ 64(1) wird in die 32. Ziffer von N 2 eingegeben.

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

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

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

Entschlüsselung verschlüsselter Daten im Gamming-Modus mit Feedback

Beim Entschlüsseln ist das Kryptoschema dasselbe wie bei der Verschlüsselung (siehe Abbildung 4). In der KZU werden 256 Bits des gleichen Schlüssels eingegeben, auf denen T 0(1) , T 0(2) ..., T 0(M) verschlüsselt waren. Synchro-Send wird in N1, N2 eingegeben, so dass der Wert von S1 in die erste Ziffer von N1 eingegeben wird, der Wert von S2 in die zweite Ziffer von N1 eingegeben wird, usw., der Wert von S32 wird in die 32. Ziffer eingegeben N 1 ; der Wert von S33 wird in die erste Ziffer von N2 eingegeben, der Wert von S34 wird in die zweite Ziffer von N2 eingegeben usw. Der Wert von S64 wird in die 32. Ziffer von N2 eingegeben.

Die Erstbefüllung der Antriebe N 1 und N 2 (Synchrophase S) wird im einfachen Ersatzmodus entsprechend den Anforderungen von Abschnitt 3.1 verschlüsselt. Die resultierende Verschlüsselungsfüllung N 1 , N 2 bildet den ersten 64-Bit-Block des Gamma-Chiffre G W(1) , der im Addierer CM 5 mit dem verschlüsselten Datenblock T W(1) bitweise modulo 2 summiert wird. Das Ergebnis ist der erste offene Datenblock T 0(1) .

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

In ähnlicher Weise werden in N 1 , N 2 die Blöcke von verschlüsselten Daten T ((2) , T ((3) ..., T ((M-1)) sequentiell aufgezeichnet, aus denen im einfachen Ersetzungsmodus Gamma-Blöcke der Chiffre G ((3) , D erzeugt werden) w(4) , ..., G w(M) . Die Chiffriergammablöcke werden im CM 5 -Addierer mit den verschlüsselten Datenblöcken von T m(3) , T m(4) ..., T m(M) bitweise modulo 2 summiert, was zu offenen Datenblöcken 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 Bits enthalten kann.

Art der Produktion

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

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

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

Die nach 16 Betriebszyklen erhaltene Füllung von N 1 und N 2 mit der Form (a 1(1) (16), a 2(1) (16), ..., a 32(1) (16), b 1(1) ( 16), b 2(1) (16), ..., b 32(1) (16)), summiert in CM 5 modulo 2 mit dem zweiten Block T 0(2) = (t 1(2) , t 2( 2) , ..., t 64(2) ). Das Ergebnis der Summierung wird in N1 und N2 eingegeben und erfährt eine Transformation, die den ersten 16 Zyklen des Verschlüsselungsalgorithmus im einfachen Ersetzungsmodus entspricht.

Die resultierende Füllung von N 1 und N 2 wird in CM 5 modulo 2 mit dem dritten Block T 0(3) usw. aufsummiert, der letzte Block T 0(M) = (t 1(M) , t 2(M) , ... , t 64(M) ), gegebenenfalls ergänzt um einen vollen 64-Bit-Block mit Nullen, wird in CM 5 modulo 2 mit Füllung von 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 N1, N2 eingegeben und im einfachen Ersetzungsmodus durch die ersten 16 Zyklen des Algorithmus verschlüsselt. Aus der erhaltenen Füllung der Akkumulatoren N 1 und N 2 wählen wir das Segment AND 1 = [a 32 - l + 1(M) (16), a 32 - l + 1(M) (16), ..., a 32(M) (16 )].

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

Empfangene verschlüsselte Daten T w(1) , T w(2) , ..., T w(M) werden entschlüsselt, aus den empfangenen offenen Datenblöcken T 0(1) , T 0(2) , ..., T 0(M) wird die Ausgabe erzeugt Und 'l , die dann mit der Imitation AND 1 verglichen wird, erhält man zusammen mit den verschlüsselten Daten aus dem Kommunikationskanal oder Computerspeicher. Im Fall einer Fehlanpassung der Imitatoren 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 im Simulator) wird durch die gültigen kryptografischen Anforderungen bestimmt, wobei zu berücksichtigen ist, dass die Wahrscheinlichkeit, falsche Daten aufzuprägen, 2 - 1 ist .