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

Hacking der U-Bahn (Reisen, Karten) + ALGORITHMUS DER KRYPTOGRAPHISCHEN TRANSFORMATIONEN GEMÄSS GOST 28147-89

Auf der Seite:


Hacken der U-Bahn (Reisen, Karten)

Kennen Sie den Wunsch, alle Rätsel zu lösen und alle Schutzmaßnahmen der Moskauer Metro aufzudecken? Zum Beispiel sich selbst ein "ewiges Ticket" zu machen? Aber die Metro-Spezialisten finden immer raffiniertere Möglichkeiten, sich zu schützen. Metallplättchen wurden durch Plastikplättchen ersetzt, diese wiederum durch Magnetkarten und Magnetkarten durch Nichtkontaktkarten. Viele Forscher ließen ihre Hände fallen - es scheint, dass die Metropolitan eine uneinnehmbare Festung geworden ist. Aber jeder Schutz kann umgangen werden. Und oft ist es viel einfacher, es zu öffnen als es zu bauen ...

Wie alles begann

Das Interesse an U-Bahn-Systemen war lange Zeit auf einer Schulbank, als noch Karten mit einem Magnetstreifen im Kurs waren. Zur gleichen Zeit (seit einem Dutzend Jahren) wurde eine kontaktlose Sozialkarte für Studenten in Umlauf gebracht. Ich wurde interessiert, was es ist und wie es funktioniert. Aber zu dieser Zeit hatte ich nicht genug Fähigkeiten, und es gab nicht viele Informationen, besonders zu diesen Technologien. Ich musste die Idee der Forschung in einer langen Box verschieben, aber ich versprach mir, dass ich definitiv zurückkommen würde ...

Vor etwa drei Jahren weckte ich wieder Interesse am Thema U-Bahn. Ich studierte aktiv magnetische Tickets (im Internet gab es viele Informationen zu diesem Thema) und baute sogar eine kleine Maschine für die Herstellung von Duplikaten von zwei Köpfen aus Tonbandgeräten und einer kleinen Menge von rassypuhi zusammen. Ich habe meine Sozialkarte (bereits Student Card) nicht vergessen. Aber nach dem Studium der Dokumentation wurde mir klar, dass das System nahezu 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 kann es nicht so leicht gehackt werden, und Schlüssel können bis zum Ende des Sonnensystems aussortiert werden. Ja, und die Karteninhaber, die den Classic unterstützen, waren damals etwas mehr Geld wert (über Ebay habe ich irgendwie nicht gedacht, ach). Das Interesse an Magnetkarten kühlte sich rasch ab, und die Sozialkarte musste wieder auf bessere Zeiten verschoben werden.

Treffen: "Ultraleicht"

Tickets "Ultralight" erschienen kürzlich in unserer Metro, stießen aber sofort auf großes Interesse in der Öffentlichkeit. Sie begannen zu häkeln, zu reißen, ein Eisen zu kleistern und andere Methoden der thermischen rektalen Kryptoanalyse anzuwenden. Ich muss zugeben, der Wissensdurst hat mich und raskurochit Paar gemacht. Als Ergebnis ihrer Studie und Recherchen im Internet wurde festgestellt - es ist nichts anderes als Mifare Ultralight, eine "leichte" kompatible Version von Mifare Classic. Ein kurzer Blick auf die Dokumentation der Chips dieses Standards machte deutlich, dass es für diese Karten keine eingebauten Sicherheitssysteme gibt. Zu allem anderen griff ich einen Artikel an, der den erfolgreichen Abbruch eines ähnlichen Transportsystems durch holländische Studenten beschreibt. Alles in allem hat es mich zu neuen Forschungen getrieben.

Lass uns gehen!

Um zu starten, war es natürlich nur notwendig, einen kabellosen Kartenleser zu bekommen, der "Ultralight" irgendwo unterstützt. Es gab zwei Möglichkeiten: entweder selbst zusammenzusetzen (was viel Zeit in Anspruch nehmen würde) oder ein vorgefertigtes Gerät zu kaufen. Beim Gedanken an die zweite Option, die vor drei Jahren auf die Preise geachtet hat, bekam ich eine Gänsehaut. Aber ich habe mich immer noch entschieden, 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 drahtlosen Karten zu einem attraktiven Preis - 4000 Rubel - unterstützt.

Natürlich, nicht ein bisschen, aber andererseits ist es nicht 10000; Darüber hinaus ermöglichte es der Kauf eines fertigen Lesers, sich sofort auf die Suche nach Tickets zu konzentrieren, und nicht auf das Design und das Debugging von Eisen, das auf unbestimmte Zeit verschoben werden konnte. Zusammen mit dem Leser von der gleichen Firma (ISBC) wurde eine sehr bequeme originale SDK der lokalen Produktion gekauft. Er wiederum erlaubte es nicht, Energie und Zeit zu verschwenden, um Low-Level zu schreiben und die Arbeit der Software mit dem Leser zu debuggen und sich direkt auf die Tickets zu konzentrieren. So wurde für ein paar Tage langweiliger Programmierung ein kleines Programm geboren, mit dessen Hilfe man die gesamte innere Struktur von "Ultralights" in einer bequemen Form beobachten und kontrollieren konnte. Dann begann ich, Tickets zu studieren.

Gehörlose Mauer

Im Laufe des Studiums durch meinen Leser viele Tickets bestanden. Einige habe ich die Ärmel hochgekrempelt, bin aus dem Müll gestiegen, habe einige gekauft - habe beobachtet, was sie niedergeschrieben haben, dann ist gegangen und hat wieder geschaut. Es waren Tickets für fast alle Arten, mit Ausnahme der Reise "Ultralight" für 70 Fahrten. In ein paar Wochen habe ich eine große und sortierte Datenbank von Depots verschiedener Tickets und in verschiedenen Staaten gesammelt. Es gab nach jeder Fahrt ein und dasselbe Ticket und mehrere Tickets mit Metro-Nummern, die hintereinander liefen. In meiner Sammlung wurden sogar ein paar Depots von zwei verschiedenen temporären Einzel-Sozialtickets (eines für die Dauer von 5 Tagen, das andere für 30 Tage) über ein bestimmtes Zeitintervall verteilt. Es stellte sich heraus, dass es sehr interessante Exemplare waren und gleichzeitig sehr selten (ich bekam sie aus erster Hand mit einer sofortigen Rückgabe, nur zum "Lesen").

In der Tat ist dies fast die einzige Art von "Ultralights", die nicht nur in der U-Bahn, sondern auch im Landverkehr funktioniert. Darüber hinaus hat nur diese Art von Ticket keine Begrenzung der Anzahl der Fahrten. Danach haben sie mir sehr gut gedient ... All diesen Zoo habe ich zu einem bestimmten Zweck gesammelt - um die Struktur und das Format der Aufnahme von Daten auf dem Ticket klar zu definieren. Natürlich waren einige Felder mit bloßem Auge gleichzeitig sichtbar, andere jedoch nicht. Zum Beispiel habe ich nicht sofort verstanden, wo die U-Bahn-Ticketnummer aufgezeichnet wurde (die, die darauf gedruckt ist). Das Bewusstsein kam völlig zufällig. Tatsache ist, dass ich (genau wie ich denke, die meisten von uns), wenn wir auf das Feld schauen, Informationen für Bytes ausrichten und zumindest Bytes denken. Es stellte sich heraus, dass dieser Ansatz falsch ist. Wenn Sie auf den Ticket-Dump schauen, müssen Sie in kleineren Einheiten denken - Tetraden und manchmal Bits. Ich erkannte, dass, als ich schließlich die Ticketnummer sah, um 4 Bits in Bezug auf den Anfang des Bytes verschoben wurde, und die restlichen 4 Bits von der anderen Seite der Nummer wurde durch andere offizielle Information besetzt. Nach einer Weile wurde das Format für die Aufzeichnung von Daten auf Tickets fast vollständig klar.

Es wurde offensichtlich, wo und wie alle Daten, Zähler, Identifikatoren gespeichert sind. Es gab nur ein paar Felder, deren Zweck unklar war, einfach weil die darin enthaltenen Daten vom Speicherabzug zum Speicherabzug identisch waren. Aber damit ist die ganze Freude beendet und es wäre töricht anzunehmen, dass solche Tickets ungeschützt bleiben können. In jedem Speicherabzug gab es 32 Bits verschiedener Informationen, die nicht mit dem Rest des Inhalts korrelierten. Ich nahm an, dass dies eine Art Prüfsumme ist, ein "Hash" von Daten, die auf dem Ticket geschrieben sind. Alle Versuche, diese 32 Bits zu schätzen oder zu berechnen, stellten sich als totaler Fehler heraus (insbesondere wurde angenommen, dass dies eine Art von CRC32 ist, mit einem Nicht-Standardpolynom und Startwert).

Wenn Sie versuchen, mindestens eineinhalb Bits an Informationen innerhalb des Tickets zu ändern, blitzte das Kassenterminal in der U-Bahn "BAD TICKET" mit einem kräftigen Wagenheber auf und nagelte die letzten Nägel in den Sargdeckel. Natürlich gab es Versuche, das System auf andere Weise zu umgehen, zum Beispiel das Ticket auf eine saubere Eins-zu-Eins-Karte zu kopieren (hier leider die Factory-Serial, die sich auch an der Generierung des Hashes beteiligt hat), oder die Lock-Bits setzen verbieten, dass das Drehkreuz den Inhalt des Tickets ändert. Das Verifikations-Terminal hat dieses "ewige" Ticket erkannt, weigerte sich aber, das Drehkreuz zuzulassen ... Also lehnte ich mich an die Wand. In dieser großen, starken Betonmauer, über die viele die Gewohnheit haben, von einem Start getötet zu werden. Ich habe keine Informationen in den Foren und Foren gefunden, ich habe entschieden, dass hier meine Studien beendet sind - es gibt keine Wege mehr und einen fetten Punkt. Wie sich herausstellte, vergeblich ...

Seltsame Bekanntschaft

Der Septemberabend unterschied sich nicht von den anderen. Es war fast Nacht, die Straße war kühl und feucht. Ich saß vor dem Monitor und trank einen warmen, leicht süßlichen grünen Tee, um friedlich ein Brett für mein nächstes Fahrzeug zu züchten. DipTarce, ein kleiner Bastor, ICQ ... Jemand hat Skype angerufen - abgelenkt! Wieder ICQ, wieder DipTrace - alles ist wie immer. Wieder einmal tauchte das Fenster von ICQ in den Vordergrund - jemand, der mir bisher unbekannt war, schrieb "Hallo". Ich zögerte nicht, antwortete gleich. Die folgende Nachricht war ein Wendepunkt in der ganzen Geschichte: "Sie interessieren sich für die U-Bahn, ich habe dort etwas Müll. Wenn Sie interessiert sind, lassen Sie uns treffen, ich werde es Ihnen sagen. " Zuerst war ich ein wenig verwirrt und alarmiert (vielleicht wurde eine Scheidung oder ein Set-up, und vielleicht sogar "spezielle Dienste" interessiert - Paranoia fordert ihren Tribut), aber dann dachte ich: warum nicht?

Spezialdienste, an denen ich nicht interessiert wäre, und der Boden für die Scheidung, und noch mehr, für das Establishment scheint es keine zu geben. Nach einer kurzen Unterhaltung vereinbarten wir, uns am Nachmittag in der Mitte der Halle einer der Moskauer Metrostationen zu treffen. Der Fremde war ein großer junger Mann mit Brille und einer großen schwarzen Plastiktüte in den Händen. Wir begrüßten uns, dann reichte er mir ein Päckchen mit den Worten: "Auf, halt. Es war sowieso nicht praktisch, vielleicht wird es für dich nützlich sein. " Als ich hineinschaute, sah ich zwei U-Bahn-Terminals, übersetzt von Zeitungen, mehrere chaotisch verstreute weiße Plastikkarten und ein Schwein in der Schachtel. Auf meine Frage, wie viel ich das schulde (Geld), schüttelte der Typ den Kopf, lächelte und sagte: "Tust du nicht, niemandem sollte irgendjemand etwas antun ... Also muss ich schon rennen, und mein Zug ist wie mal! Komm schon, tschüss! ".

Mit diesen Worten floh er, sprang in die bereits verschlossenen Türen des Autos und ging. Und ich, ich gestehe, ging in Neponyatkah ein wenig nach Hause. Kontakt von ICQ Ich habe nur für den Fall gelöscht, gleichzeitig den Kontakt auf dem Server zu säubern und Logs zu putzen (nochmal Hallo, Paranoia). Schreib am Ende noch einmal, wenn das so ist. Aber er hat mir nie wieder geschrieben ...

Das Phänomen der Software-Leute

Nach Hause angekommen, zerlegte ich das Paket. Das zweite der Terminals war ein Bus-Validator (schwer, Pfannkuchen!); Die Karten waren Mifare Classic 1K (sauber) und die Disc hatte ein einziges Archiv. Nach einer oberflächlichen Betrachtung der Inhalte stellte sich heraus, dass es sich um eine Software handelt, die an den Fahrkartenschaltern der Metro zum Einsatz kommt. Ich legte das Terminal und den Validator beiseite und beschloss, das Studium interessanter Software aufzunehmen. Ungefähr eine Stunde von dem Chaos, das ausgepackt wurde, konnte ich dieses Programm auf meinem Computer erstellen und ausführen. Eine weitere Stunde war erforderlich, um seine Struktur zu verstehen. Nachdem ich alle Ini-Dateien (mit Kommentaren, die freundlicherweise vom Entwickler hinterlassen wurden) durchkämmt hatte, hatte ich bereits eine genaue Vorstellung davon, was es ist, wie es funktioniert und was es isst. Essen Sie, wie sich herausstellte, mit dem Leser Parsec PR-P08, so, aus Mangel daran, versuchen Sie die Software in der Handlung fehlgeschlagen.

Der Entwickler war die Firma "Smartek" - ein großer staatlicher Auftragnehmer, der solche Systeme entwickelt (mehr Details können auf ihrer Website gelesen werden). Das Programm wurde in Delphi mit Laufzeit-bpl'ok geschrieben. Außerdem war die Software modular aufgebaut und alle Subroutinen, Klassen und Komponenten befanden sich in separaten DLLs oder bpl'ks mit sprechenden Namen (das war die wichtigste Entwicklerdatei). Nach einer kursorischen Analyse des Inneren der Software fand ich heraus, dass zum einen Informationen über alle ausgestellten Tickets in eine zentralisierte Datenbank übertragen werden (übrigens ist dies Oracle) und zum anderen nutzt das Programm einen bestimmten 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 uns das einen Vorsprung.

Aber zuerst interessierte mich der Mechanismus der Schlüssel (ich hatte schon angefangen zu erraten, warum es nötig sein könnte). Also nahm ich den Disassembler auf und machte mich an die Arbeit. Der Mechanismus bestand aus zwei Dateien - CryptKeyRef.dll und keys.d (die einzige "knifflige" Datei im gesamten Programm, die im Gegensatz zur Datei mit den Schlüsseln nichts mehr ähnelt). Und ich habe all diese guten Run-bpl'in SmLayout.bpl benutzt. Diese Bibliothek war nur ein Glücksfall für meine Recherchen - sie enthielt Klassen für das interne Ausfüllen von Tickets. Da es Laufzeit-bpl ist, war es genug, nur um seine Export-Tabelle zu betrachten, um 60 Prozent dessen zu verstehen, was was ist. Eine detailliertere Analyse bringt alles an seinen Platz. Erinnern Sie sich, am Anfang des Artikels, ich sagte, dass in der Struktur von "Ultralight" gab es noch einige Felder, deren Zweck unverständlich war?

Eines dieser Felder ist die sogenannte "Layout-Kennung". Tatsächlich bestehen alle Metro-Tickets aus einem festen Kopfteil und einem variablen Datenelement. Dieses "Layout" -Feld in der Kopfzeile hat lediglich bestimmt, wie und welche Daten sich im Rest des Tickets befinden. Es gibt mehrere solche Layouts (jeweils für einen eigenen Tickettyp), und in SmLayout.bpl entsprach jeder von ihnen seiner eigenen Klasse (plus der gemeinsamen Elternklasse, die Methoden zum Arbeiten mit dem Header-Teil hatte). Um zu verstehen, welche Felder in jedem Layout verantwortlich sind, war es einfach (auch wenn man mit den Namen der Methoden beim Export spricht!). Nachdem ich das gesamte Layout 8 (welches in "Ultralights" verwendet wurde) komplett neu erstellt hatte, hatte ich die richtige Idee über alle Felder in der Ticketstruktur, ich nahm den Schlüsselmechanismus auf. Tatsächlich war er verantwortlich für die Erzeugung des Hashes. Wie der Mechanismus funktioniert, wurde nach dem Studium der Arbeit der Methode, die für die Berechnung des Hashes verantwortlich ist, völlig klar. Zuerst wird der richtige Schlüssel aus der Schlüsseldatei (keys.d) ausgewählt.

Das System ist so eingerichtet, dass jeder Tickettyp seine eigene Kennung hat (komplett mit einer Tabelle mit Ticket-IDs und Namen, als Textdatei mit Werten, die durch ein Komma getrennt sind). Es besteht aus der Kennung der Zone (Anwendung) und der Kennung des Typs der Karte. Basierend auf diesen Zahlen wird die Schlüsselung in der Schlüsseldatei ausgewählt, in der sich mehrere Schlüssel befinden können (falls der neue Schlüssel eingegeben wurde und alte Tickets noch verwendet werden). Das neue Ticket wird mit dem allerersten Ticket erfasst und die Validierung erfolgt mit allen Schlüsseln in der Eingabe. Dann wird der ausgewählte Schlüssel mit CryptKeyRef.dll entschlüsselt (warum werden sie verschlüsselt gespeichert, ich werde mich nicht damit beschäftigen). Danach werden der entschlüsselte Schlüssel und fast alle Tickettendaten sowie seine Hardware-Seriennummer und -Nummer (die Methode zum Erzeugen eines "Hash", der für die Eingabe von keys.d spezifiziert wird) an die Funktion ckCalcHashCode übergeben, die sich in derselben CryptKeyRef.dll befindet. Am Ausgang bekommen wir einen Wert, auf den ich in meiner Zeit und "klebte" - der gleiche "Hash". Natürlich habe ich ein kleines Programm geschrieben, das mit diesen Funktionen aus CryptKeyRef.dll und Datei keys.d den "Hash" innerhalb eines Dumps überprüfen und in diesem Fall neu berechnen kann. Ich überprüfte alles auf mehreren Mülldeponien und ging, nachdem ich ein positives Ergebnis erhalten hatte, zufrieden in den Schlaf.

Foul 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 mir extra ein neues "Ultralight" für eine Reise, um zu sehen, ob meine Schlüssel funktionieren oder nicht (anscheinend waren sie alt). Du kannst natürlich sofort versuchen, "fabriziertes" "Ultralight" zu schreiben und nachsehen, aber zu dieser Zeit waren mir die leeren Karten ausgegangen, und ein bisschen gruselig, um "zufällig" zu gehen - auf einmal was? Als ich nach Hause kam, beeilte ich mich, ohne meine Hände zu waschen, ungeduldig, um das frische Ticket mit meinen Schlüsseln zu überprüfen. Und dann wartete ich auf eine große Enttäuschung - "Hasch", in dem Ticket aufgezeichnet, passierte keinen der Schlüssel. Also, die Schlüssel sind wirklich schon faul und werden durch neue ersetzt. Das hat alle meine Arbeiten komplett durchgestrichen. Ich war ein bisschen traurig. Ich habe grünen Tee gebraut, ein wenig am Klavier gespielt (ja-ja) und mich hingesetzt, um meine unvollendete Gebühr zu züchten ...

Noch ist nicht alles verloren

Die Idee kam mir unerwartet, als ich aus irgendeinem Grund noch einmal mit den Schlüsseln in die Datei schaute. Mir ist aufgefallen, dass es in der "running" -Taste (die zur Berechnung von 1-, 2-, 5-Wege- und anderen "Ultralights" verwendet wird) zwei Schlüssel gab - einen neuen (zu dieser Zeit natürlich) und anscheinend einen alten. Aber es gab auch einen Schlüssel, in dem es nur einen Schlüssel gab. Vorher habe ich darauf nicht geachtet und mich auf das "Laufen" konzentriert. Um zu berechnen, für welche Tickets dieser Schlüssel verwendet wird, wusste ich nicht. Als ich sah, welche Art von Ticket an das Gehäuse gebunden ist, habe ich einen kleinen Hoffnungsschimmer geblasen. Die Sache ist, dass diese Art von Ticket war - VESB. Ja, es ist diese seltene Art von Ticket - eine temporäre Reisekarte für alle Arten von Transport. Ich dachte, dass, wenn das Ticket einzeln ist, dieser Schlüssel nicht nur in der U-Bahn, sondern auch im Landverkehr verwendet werden sollte, wo es sehr schwierig und lang ist, ihn durch ein neues zu ersetzen.

Außerdem gibt es nur einen Schlüssel, der indirekt meine Vermutung bestätigt. Zu allem anderen erinnerte ich mich daran, dass, als ich das Metro-Programm von verschiedenen "Müll" säuberte, etwas Ähnliches wie das Archiv alter Schlüsseldateien war. Nach dem Graben und Öffnen des Originalarchivs sah ich, dass es wirklich so war. Und am wichtigsten, nachdem ich alle alten Schlüsseldateien durchgesehen habe, habe ich festgestellt, dass dieser Schlüssel unverändert geblieben ist! Schon ohne einen einzigen Zweifel, habe ich meinen eigenen VESB genietet (gut, ich hatte Dumps von der Art, die die Aufgabe manchmal vereinfacht haben - ich habe gerade das Datum und die Nummer in den Dumps geändert) und den mit dieser Taste berechneten "Hash". Also, es ist Zeit zu überprüfen (vor allem, ich habe gerade mehr sauberes Plastik gekauft). Als ich in die Lobby kam, legte ich zuerst mein "Ticket" zum Verifikationsterminal. Die Anzeigetafel zeigte das Ablaufdatum des Tickets, das ich anzeigte, und die grüne LED leuchtete auf. So funktioniert es. Er machte eine Grimasse leichter und verbarg schneeweißen Plastik im Ärmel. Ich ging zum Drehkreuz, legte meine Hand zum Validator und ... ging ruhig zu dem fröhlich leuchtenden Grün. Dies markierte den endgültigen Sieg.

Und was kommt als nächstes?

Und dann begannen Experimente, bei denen viele interessante Dinge entdeckt wurden. Zum Beispiel können Sie für einen solchen "linken" VESB nur zwei oder drei Tage laufen. Tatsache ist, dass die Nummer, die ich in dem Ticket "von der Glatze" anzeige, mit jeder Passage im Gedächtnis des Kopfes des Drehkreuzes gespeichert wird, und nach einiger Zeit mit dem Rest zum Datenzentrum geschickt wird. Dort findet das System kein wirklich ausgestelltes Ticket mit einer solchen Nummer und fügt es der Stoppliste hinzu, die dann an alle Drehkreuze der Metro gesendet wird. Und das sollte bei allen Arten von Tickets passieren, nicht nur beim VEBB - neben dem "Hash" und häufig wechselnden Schlüsseln ist das eine sehr gute Verteidigung. Aus offensichtlichen Gründen ist das nicht möglich.

Es wurde auch beobachtet, dass das Installieren oder Nicht-Installieren von Verriegelungsbits keine Rolle spielt, ob das Ticket funktioniert oder nicht. Die einzige Ausnahme ist das OTP-Zonenblockierungsbit, das das Drehkreuz scheinbar immer überprüft, obwohl es nicht beabsichtigt, in OTP zu schreiben. Später nahm ich die Metro- und Busterminals auf, brachte sie in Ordnung, studierte und startete sie auf dem Stand. Um die nächste Schätzung zu überprüfen, war es nun nicht mehr nötig, mit einem frisch gebackenen Mutantenticket in der U-Bahn zu fahren, aber es wurde möglich, sie zu überprüfen, "ohne vom Ticketbüro abzuweichen". Außerdem entpuppte sich das U-Bahn-Terminal als ebenso alt (zu allem anderen und fehlerhaft), wie meine Schlüssel. Also könnte ich "bei der Arbeit" und alle anderen Arten von Tickets "Ultralight" ausprobieren - etwas, was ich niemals "live" in der U-Bahn machen kann. Parallel zu diesen Experimenten arbeitete ich weiter an Software.

Da viel darüber debattiert wurde, welche Art von Algorithmus zur Berechnung des "Hash" verwendet wird, entschied ich mich für eine vollständige Wiederherstellung, indem ich den Algorithmus in der "menschlichen" Programmiersprache von Grund auf neu schrieb und dabei hoffte zu verstehen, was für ein Algorithmus das war etwas weithin Bekanntes oder eine Art eigene interne Entwicklung. Auf dem Weg wurde ich von vielen verschiedenen Gedanken (einschließlich, dass es AES sein könnte) besucht, aber mit einer detaillierten Studie des bereits funktionierenden Codes ohne den Einsatz von Smartekov Bibliotheken wurde klar, dass dieser Algorithmus "nur" GOST ist - der nationale Verschlüsselungsstandard (alle notwendigen Informationen Sie können es leicht im Internet finden). Insbesondere wurde eine 16-Z-Schleife verwendet, um den Hash zu berechnen. "Hash", in der Tat, es ist nichts wie eine Nachahmung GOST.

Die Struktur der auf dem Ticket "Ultralight" aufgezeichneten Informationen

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

Bei Ultralight-Tickets ist der Layout-Wert 0x08. Damit endet der gleiche Teil des Titels. Weiter ist im Ticket "Ultralight" das Datum angegeben, an dem das Formular gültig ist (16 Bit). Alle Daten im System werden im Format der Anzahl der seit dem 01.01.1992 verstrichenen Tage angezeigt. Hier endet der Kopfteil des Tickets "Ultralight" (Tickets mit einem anderen Layout können noch verschiedene Zusatzinformationen enthalten). Der erste Datenbereich beginnt auf Seite 8. Zunächst werden 16 Bits des Ticketausgabedatums geschrieben. Danach beträgt die Gültigkeitsdauer des Tickets in Tagen (ab dem Zeitpunkt der Ausgabe) 8 Bit. Die ersten 16 Bits von Seite 9 sind der Auslösezähler. Er kann entweder auf Null (auf alle Tickets mit einer Beschränkung der Anzahl der Fahrten) oder auf Null (auf WESC-Fahrkarten ohne Einschränkung der Anzahl der Fahrten) sinken. Nach dem Zähler schreibt das Drehkreuz im Rest der Seite bei jedem Durchgang seine eindeutige Kennung ein. Offensichtlich wird dies verwendet, um eine Wiederholung zu verhindern, ohne auf ein VEB-Ticket zu warten (die Drehkreuze in der Lobby sind mit dem Netzwerk verbunden und fragen sich gegenseitig), und auch zu sehen, welches Drehkreuz der Pass gemacht hat (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 ist es notwendig, über die Verwendung des OTP-Zonensystems zu sprechen. Es wird für das allmähliche "Ausbrennen" des Tickets bei jeder Fahrt verwendet (VESB-Tickets gelten nicht). Die zwei untersten Bits werden ausgegeben, wenn das Ticket storniert oder storniert wird (auf dem Stoppblatt). Das stornierte Ticket unterliegt keiner Wiederherstellung. Zum Ausbrennen bleiben nur 30 Bits übrig. Diese Zone wird vom System als 100% der Fahrten dargestellt. Mit jeder neuen Reise wird eine bestimmte Anzahl von Bits (von Junior zu Senior) eingestellt, entsprechend wie viel Prozent von einer Reise belegt ist. Zum Beispiel, für ein 5-Passagier-Ticket mit jeder neuen Reise, wird es bei 6 Bits ausgebrannt, und für ein 60-Wege-Ticket - ein halbes (aufgerundet). Es ist erwähnenswert, dass die Wiederverwendung von Tickets "Ultralight" nicht nur wegen des "Ausbrennens" von OTP unmöglich ist, sondern auch, weil an der Kasse, beim Ausstellen des Tickets (und vielleicht sogar wenn es gemacht wird) fast alle Seiten zum Überschreiben blockiert sind . Daher funktioniert weder das "Aufladen" noch das Ändern des Tickettyps in einen anderen.

Beispiele für benutzte U-Bahnticket-Identifikatoren

Alle Zahlen sind in Dezimalschreibweise!

Anwendungs-IDs:

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

Identifikatoren der Art der Tickets "Ultralight":

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

Mifare Klassiker

Bei meiner Recherche habe ich auch auf den unglückseligen Mifare Classic 1K geachtet. Wie du verstehst, war das wichtigste Hindernis auf dem Weg zum "Classic" die Hardwareschlüssel A und B. Durch einen glücklichen Zufall befanden sich diese Schlüssel in einem der Module des Programms in einer offenen Form (für die Entwickler!) Und ich hatte kein Problem, ein kleines Programm zu schreiben Arbeite mit dem Inhalt dieser Karten, benutze die empfangenen Schlüssel. Im Verlauf der Experimente wurden einige interessante Merkmale aufgedeckt, wie zum Beispiel: die U-Bahn nutzte den ersten Sektor der Karte, um das Ticket zu speichern, und der Bodentransport benutzte den vierten; kein Schutz, außer für Hardware-Schlüssel (die, in dieser Form in die Software geschrieben, höchstwahrscheinlich nie geändert wurden, als das System in Betrieb genommen wurde), existiert nicht.

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

Aber das Klonsystem wird, wie sich herausstellte, durch das Stop-Loss-System bemerkenswert gerettet - dieses Ticket kann maximal zwei Tage benutzt werden, dann wird es abgebrochen (im Gegensatz zum "Ultralight" kann die "Classic" -Karte nach der Stornierung wieder hergestellt werden, aber aus der Stop-Liste) es wird nicht gespeichert). Da auf den Classic-Karten kein Schutz verwendet wurde, wurden sie für mich schnell uninteressant und ich beschloss, mich auf die Ultralight-Studie zu konzentrieren.

Das Ende oder die Zusammenfassung

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

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








Beschreibung des kryptographischen Transformationsalgorithmus gemäß GOST 28147-89

Dieser Standard legt einen einzigen kryptographischen Transformationsalgorithmus für informationsverarbeitende Systeme in Netzwerken von elektronischen Computern (Computern), einzelnen Computerkomplexen und Computern fest, der die Regeln für die Datenverschlüsselung und die Entwicklung von imitovki bestimmt.

Der kryptografische Transformationsalgorithmus ist für eine Hardware- oder Software-Implementierung vorgesehen, erfüllt kryptographische Anforderungen und erlegt dem Grad der Geheimhaltung der geschützten Information keine Beschränkungen auf.

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

Strukturdiagramm des kryptographischen Transformationsalgorithmus

Das Blockdiagramm des Algorithmus der kryptographischen Transformation (Kryptosystem), der in Fig. 1 gezeigt ist, enthält:

  • - 256-Bit-Schlüsselspeichervorrichtung, 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-Speichervorrichtungen (N 1 , N 2 , N 3 , N 4 );
  • - zwei 32-Bit Speichergeräte (N 5 , N 6 ) mit den darin aufgezeichneten Füllkonstanten C 2 , C 1 ;
  • - zwei 32-Bit-Addierer Modulo 2 32 (CM 1 , CM 3 );
  • - 32-Bit Addierer der bitweisen Summierung Modulo 2 (CM 2 );
  • - 32-Bit-Addierer modulo (2 32 -1) (SM 4 );
  • - Addierer Modulo 2 (CM 5 ), die Beschränkung der Kapazität des Addierers CM 5 wird nicht überlagert;
  • - Substitutionseinheit (K);
  • - das Register der zyklischen Verschiebung um elf Schritte zur höchsten Entladung (R).

Abbildung 1.

Der K-Substitutionsblock besteht aus acht Ersatzknoten K1, K2, K3, K4, K5, K6, K7, K8 mit je einem Speicher von 64 Bit. 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 pro Zeile darstellt, in einen 4-Bit-Vektor umgewandelt wird. Der Eingabevektor definiert die Adresse der Zeile in der Tabelle, das Füllen dieser Zeile ist ein ausgehender Vektor. Die 4-Bit-Ausgangsvektoren werden dann sequentiell zu einem 32-Bit-Vektor kombiniert.

Wenn die Binärvektoren addiert und zyklisch verschoben werden, sind die oberen Bits Bits mit großen Zahlen.

Beim Schreiben eines Schlüssels (W 1 , W 2 , ..., W 256 ), W q ∈ {0,1}, q = i ÷ 256, â wird der Wert W 1 in die 1. Stelle des Akkumulators X 0 eingegeben, der Wert W 2 wird eingegeben in der 2. Stelle des Akkumulators X 0 , ... wird der Wert W 32 in die 32. Stelle des Akkumulators X 0 eingegeben; der Wert W33 wird in die erste Ziffer des Akkumulators X1 eingegeben, der Wert W34 wird in die zweite Ziffer des Akkumulators X1 eingegeben, ..., der Wert W64 wird in das 32. Bit des Akkumulators X1 eingegeben; der Wert W 65 wird in die erste Ziffer des Akkumulators X 2 usw. eingegeben, der Wert von W 256 wird in das 32. Bit des Akkumulators X 7 eingegeben.

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

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

Tabelle 1

Entladung des Akkumulators N 6

32

31

30

29

28

27.

26.

25

24

23

22

21

20

19

18.

17.

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Entladung des Akkumulators N 6

16

15.

14.

13.

12.

11.

10

9.

8.

7.

6.

5

4

3

2

1

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

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

Tabelle 2

Entladung des Akkumulators N 5

32

31

30

29

28

27.

26.

25

24

23

22

21

20

19

18.

17.

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Entladung des Akkumulators N 5

16

15.

14.

13.

12.

11.

10

9.

8.

7.

6.

5

4

3

2

1

Der Wert der Ziffer

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

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

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

Die Organisation verschiedener Arten von Kommunikation wird durch den Aufbau eines geeigneten Schlüsselsystems erreicht. In diesem Fall ist es möglich, die Möglichkeit der Erzeugung von Schlüsseln (Auffüllen des RAM) im einfachen Ersetzungsmodus und deren Verschlüsselung in einem einfachen Ersetzungsmodus zu verwenden, was einen Nachahmungsschutz für die Übertragung über Kommunikationskanäle oder die Speicherung im Computerspeicher bietet.

In der kryptografischen Schaltung gibt es 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 Gummierungsmodus mit Rückmeldung;
  • - Art der Entwicklung der Nachahmung.

Verschlüsselung im einfachen Ersetzungsmodus

Verschlüsselung von offenen Daten im einfachen Ersetzungsmodus

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


Abbildung 2

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

256 Bits des Schlüssels sind in der CMU eingetragen. Der Inhalt der acht 32-Bit-Laufwerke X 0 , X 1 , ..., X 7 sind:

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

Der Verschlüsselungsalgorithmus eines 64-Bit-Blocks offener Daten im einfachen Ersetzungsmodus besteht aus 32 Zyklen.

In dem 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 Speicherung des Akkumulators N 1 beibehalten wird.

Das Ergebnis der Summierung wird in den Substitutionsblock K transformiert und der resultierende Vektor wird dem Eingang des Registers R zugeführt, wo er zyklisch um elf Schritte zu den Bits höherer Ordnung hin verschoben wird. Das Ergebnis der Verschiebung wird bitweise modulo 2 in dem CM 2 -Addierer mit einer 32-Bit-Füllung des N 2 -Speicherrings summiert. Das in CM2 erhaltene Ergebnis wird in N1 geschrieben, 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 die Füllung X1 von der FEC gelesen wird, im dritten Zyklus die Füllung X2 von der FEC gelesen wird usw., die Füllung X7 wird von der CCD im achten Zyklus gelesen. In den Zyklen vom 9. bis zum 16. sowie in den Zyklen vom 17. bis zum 24. werden die Füllungen von der QCD in der gleichen Reihenfolge gelesen: X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 .

In den letzten acht Zyklen vom 25. bis zum 32. ist die Reihenfolge des Lesens der Füllungen der CCD 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 verwendet, um den Inhalt der Laufwerke auszuwählen:

  • 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 CM 2 Addierers in den N 2 Akkumulator eingefügt, und die alte Füllung wird in dem Speicher N 1 gespeichert.

Die Verschlüsselung der N 1 - und N 2 -Akkumulatoren, die nach dem 32. Verschlüsselungszyklus empfangen werden, ist ein Block von verschlüsselten Daten, die dem offenen Datenblock entsprechen.

Verschlüsselte Daten in einem einfachen Ersetzungsmodus entschlüsseln

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

Die Entschlüsselung erfolgt nach dem gleichen Algorithmus wie die Verschlüsselung der offenen Daten, mit der Änderung, dass das Ausfüllen der Speichereinheiten X 0 , X 1 , ..., X 7 in den Entschlüsselungszyklen in folgender Reihenfolge aus der CPU ausgelesen 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, X, X, X, X, X, X, X, X, X, X, X, X, X, X.

Nach 32 Betriebszyklen empfangen, besteht die Füllung der Akkumulatoren N 1 und N 2 aus einem offenen Datenblock.

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 1 (0) des Blocks T 0 entspricht dem Inhalt der ersten Ziffer N 1 , der Wert a 2 (0) entspricht dem Inhalt der zweiten Ziffer N 1 usw., der Wert a 32 (0) entspricht dem Inhalt der 32- die Ziffer N 1 ; der Wert b 1 (0) entspricht dem Inhalt der ersten Ziffer N 2 , der Wert b 2 (0) entspricht dem Inhalt der zweiten Ziffer N 2 usw. Der Wert b 32 (0) entspricht dem Inhalt des 32. Bits N 2 .

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

Gamma-Modus

Verschlüsselung von offenen Daten im Gamma-Modus

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


Abbildung 3

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

(1) , Γω(Σ) , ..., Γ, (Μ-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 Bits im Block T 0(M) kann kleiner als 64 sein, während der Teil der Chiffrierskala aus dem Block F m(M) für die Verschlüsselung unbenutzt ist, verworfen.

256 Bits des Schlüssels sind in der CMU eingetragen. In den Antrieben N1, N2 wird eine 64-Bit-Binärsequenz (synchrones Senden) S = (S1, S2, ..., S64 ) eingeführt, die die anfängliche Füllung dieser Laufwerke für die nachfolgende Generierung von M Blöcken des Chiffre-Gamma darstellt. Die Synchronisation wird in N1 und N2 eingeführt, so dass der Wert von S1 in das erste Bit N1 eingegeben wird, der Wert S2 in das zweite Bit N1 eingegeben wird usw. Der Wert von S32 wird in das 32-Bit eingegeben N 1 ; der Wert S33 wird in das erste Bit N2 eingegeben, der Wert S34 wird in das zweite Bit N2 usw. eingegeben, der Wert S64 wird in das 32-Bit N2 eingegeben.

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

Das Auffüllen des Akkumulators N 4 wird im Addierer SM 4 mit der 32-Bit-Konstanten 1 1 aus dem Akkumulator N 6 modulo (2 32 -1) summiert, das Ergebnis wird in N 4 geschrieben .

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

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

Die Füllung N 1 und N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die als Ergebnis der Verschlüsselung erhaltene Füllung N 1 , N 2 bildet den ersten 64-Bit-Block der Chiffrierskala G w(1) , der 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 von τ 1(1) des Blocks T w(1) ist das Ergebnis der Summation modulo 2 im CM 5 des Wertes t 1(1) aus dem Block T 0(1) mit dem Wert der ersten Ziffer N 1 , dem Wert τ 2(1) des Blocks Tm(1) ist das Ergebnis der Summierung von Modulo 2 in CM 5 der Wert t 2(1) von dem Block T 0(1) mit dem Wert der zweiten Ziffer N 1 , usw., der Wert von & tgr;64(1) des Blocks T w(1) ist das Ergebnis der Summation modulo 2 in CM 5 des Wertes t 64(1) aus dem Block T 0(1) mit dem Wert der 32. Stelle N 2 .

Um den nächsten 64-Bit Block der Chiffrierskala G w(2) zu erhalten, wird die Füllung N 4 im Addierer SM 4 mit der Konstanten C 1 von N 6 modulo (2 32 -1) summiert, die Füllung N 3 wird im CM 3 Addierer summiert modulo 2 32 mit einer konstanten C 2 von N 5 . Die neue Füllung N3 wird in N1 umgeschrieben, und die neue Füllung N4 wird in N2 umgeschrieben, während die Füllung von N3 und N4 erhalten bleibt.

Die Füllung N 1 und N 2 wird im einfachen Ersetzungsmodus gemäß den Anforderungen von Abschnitt 3.1 verschlüsselt. Die durch die Verschlüsselung erhaltene Füllung N 1 , N 2 bildet den zweiten 64-Bit-Block des Chiffriergammas Gw (2) , der im Addierer CM 5 mit dem zweiten Block der offenen Daten T 0(2) digital modulo 2 summiert wird. Ebenso werden die Blöcke der Chiffrierskala erzeugt, und die Blöcke der offenen Daten 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, wird nur die entsprechende Anzahl von Bits der Chiffrierskala vom letzten M-ten Block des Chiffriergammas Gm (M) verwendet , die restlichen Bits werden verworfen.

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

Entschlüsselung verschlüsselter Daten im Gamma-Modus

Bei der Entschlüsselung hat die kryptografische Schaltung die gleiche Form wie bei der Verschlüsselung (siehe Abbildung 3). 256 Bits des Schlüssels werden in die CMU eingegeben, mit deren Hilfe die Daten T 0(1) , T 0(2) ..., T 0(M) verschlüsselt wurden und T 0(M) weniger als 64 Bits enthalten kann.

Gamming mit Feedback-Modus

Verschlüsselung von offenen Daten im Gummierungsmodus mit Rückmeldung

Ein Kryptogramm, das eine Art von Gummierung mit Feedback realisiert, muss die Form haben, in 4 gezeigt.


Abbildung 4

Die offenen Daten, unterteilt in 64-Bit-Blöcke T 0(1) , ..., T 0(M) , werden im Gummierungsmodus mit Rückkopplung durch bitweise Summierung modulo 2 im Addierer CM 5 mit der Chiffrierskala G r verschlüsselt, die durch Blöcke an erzeugt wird 64 Bits, d.h. (M) ), wobei M durch das Volumen der verschlüsselten Daten bestimmt ist und r (i) der i-te 64-Bit-Block ist, i = 1 ÷ Ì. Die Anzahl der Bits in dem Block T 0(M) kann kleiner als 64 sein.

256 Bits des Schlüssels sind in der CMU eingetragen. In den Antrieben N 1 , N 2 wird eine 64-Bit-Binärsequenz (Synchronisation) eingegeben S = (S 1 , S 2 , ..., S 64 ). Die Synchronisation wird in N1 und N2 eingeführt, so dass der Wert von S1 in das erste Bit N1 eingegeben wird, der Wert S2 in das zweite Bit N1 eingegeben wird usw. Der Wert von S32 wird in das 32-Bit eingegeben N 1 ; der Wert S33 wird in das erste Bit N2 eingegeben, der Wert S34 wird in das zweite Bit N2 usw. eingegeben, der Wert S64 wird in das 32-Bit N2 eingegeben.

Die Erstbefüllung der Laufwerke N1 und N2 erfolgt im einfachen Ersatzmodus entsprechend den Anforderungen des Abschnitts 3.1 verschlüsselt. Die resultierende Füllung von N 1 und N 2 bildet den ersten 64-Bit-Chiffre-Gamut der Chiffre G r (1) , der 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 verschlüsselter Daten Tm(1) ist gleichzeitig auch der Anfangszustand N 1 , N 2 zum Erzeugen des zweiten Blocks der Chiffrierskala G r (2) und wird durch Rückkopplung auf die spezifizierten Laufwerke zurückgeschrieben. In diesem Fall wird der Wert von τ 1(1) in das erste Bit N 1 eingeführt , der Wert von τ 2(1) wird in das zweite Bit N 1 usw. eingeführt, der Wert von τ 32(1) wird in das 32-te Bit N eingeführt 1 ; Der Wert von & tgr; 33(1) wird in das erste Bit N2 eingeführt, der Wert von & tgr;34(1) wird in das zweite Bit N2 usw. eingeführt, der Wert von & tgr;64(1) wird in das 32-te Bit N2 eingeführt.

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

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

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

Entschlüsselung verschlüsselter Daten im Gummierungsmodus mit Rückmeldung

Bei der Entschlüsselung hat die kryptografische Schaltung die gleiche Form wie bei der Verschlüsselung (siehe Abbildung 4). In der CMU sind 256 Bits des gleichen Schlüssels eingetragen, auf denen T 0(1) , T 0(2) ..., T 0(M) verschlüsselt waren. Die Synchronisation wird in N 1 , N 2 eingeführt, so dass der Wert von S 1 in das erste Bit N 1 eingeführt wird , der Wert S 2 in das zweite Bit N 1 eingegeben wird usw. Der Wert von S 32 wird in das 32-te Bit eingegeben N 1 ; der Wert S33 wird in das erste Bit N2 eingegeben, der Wert S34 wird in das zweite Bit N2 usw. eingegeben, der Wert S64 wird in das 32-Bit N2 eingegeben.

Die Erstbefüllung der Laufwerke N1 und N2 (Synchronisation S) wird im einfachen Ersetzungsmodus entsprechend den Anforderungen von Abschnitt 3.1 verschlüsselt. Die resultierende Füllung N 1 , N 2 bildet den ersten 64-Bit-Block des Chiffriergammas Gw (1) , der im Addierer CM 5 bitweise mit dem verschlüsselten Datenblock T w(1) modulo 2 summiert wird. Als ein Ergebnis wird der erste Block von offenen Daten T 0(1) erhalten.

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

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

Simulationsmodus

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

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

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

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

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

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

Die empfangenen verschlüsselten Daten T w(1) , T w(2) , ..., T w(M) werden entschlüsselt, eine Imitation wird aus den erhaltenen Blöcken von offenen Daten T 0(1) , T 0(2) , ..., T 0(M) erzeugt. Und 'l , die dann mit Nachahmung I1 verglichen wird, erhält man zusammen mit den verschlüsselten Daten aus dem Kommunikationskanal oder Computerspeicher. Im Falle einer Fehlanpassung von Nachahmungen werden die erhaltenen Blöcke offener Daten T & sub0; (1) , T & sub0; (2) , ..., T &sub0; (M) als falsch betrachtet.

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