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

Piratage de métro (voyage, cartes) + ALGORITHME DE TRANSFORMATIONS CRYPTOGRAPHIQUES CONFORMÉMENT AU GOST 28147-89

Sur la page:


Pirater le métro (voyage, cartes)

Connaissez-vous le désir de résoudre toutes les énigmes et de révéler toutes les protections du métro de Moscou? Faire, par exemple, à soi-même un "billet éternel"? Mais les spécialistes du métro trouvent constamment des moyens de plus en plus sophistiqués de se protéger. Les jetons métalliques ont été remplacés par des jetons en plastique, ceux-ci, à leur tour, par des tickets magnétiques, et les cartes magnétiques ont été remplacées par des cartes sans contact. De nombreux chercheurs ont laissé tomber leurs mains - il semble que le Metropolitan est devenu une forteresse imprenable. Mais toute protection peut être contournée. Et souvent, il est beaucoup plus facile de l'ouvrir que de le construire ...

Comment tout a commencé

L'intérêt pour les systèmes de métro est apparu depuis longtemps, je peux dire, à partir d'un banc d'école, quand il y avait encore des billets avec une bande magnétique dans le cours. En même temps (il y a une douzaine d'années), une carte sociale sans contact pour les étudiants a été mise en circulation. Je suis devenu intéressé par ce que c'est et comment cela fonctionne. Mais à cette époque, je n'avais pas assez de compétences, et il n'y avait pas beaucoup d'informations disponibles, en particulier sur ces technologies. J'ai dû reporter l'idée de la recherche dans une longue boîte, mais je me suis promis que j'y retournerais certainement ...

Il y a environ trois ans, je me suis à nouveau intéressé au thème du métro. J'ai activement étudié les billets magnétiques (il y avait beaucoup d'informations sur le sujet sur Internet) et même assemblé une petite machine pour faire des doublons de deux têtes à partir de magnétophones à bobines et une petite quantité de rassypuhi. Je n'ai pas oublié ma carte sociale (déjà carte d'étudiant). Mais après avoir étudié la documentation, il est devenu clair pour moi que le système est presque imprenable - la puce MF1S50 Mifare Classic 1K, sur la base de laquelle les cartes sociales sont faites, est protégée par deux clés de 48 bits. Au niveau du matériel, il ne peut pas être piraté aussi facilement, et les clés peuvent être triées jusqu'à la fin du système solaire. Oui, et les titulaires de cartes qui soutiennent le Classic, valaient à ce moment-là de l'argent supplémentaire (sur Ebay, je ne pensais pas, hélas). L'intérêt pour les tickets magnétiques s'est rapidement refroidi et la carte sociale a dû être remise à plus tard.

Rencontre: "Ultralight"

Les billets "Ultralight" sont apparus récemment dans notre métro, mais ont immédiatement suscité un grand intérêt parmi le public. Ils ont commencé à poulet, déchirer, coller un fer et appliquer d'autres méthodes de cryptanalyse rectale thermique. Je dois admettre que la soif de connaissance a fait de moi et du couple raskurochit. À la suite de leur étude et des recherches sur Internet a été établie - ce n'est rien de plus que Mifare Ultralight, une version "légère" compatible de Mifare Classic. Un examen rapide de la documentation sur les puces de cette norme a montré qu'il n'y a pas de système de sécurité intégré pour ces cartes. Pour tout le reste, j'ai attaqué un article détaillant la rupture réussie d'un système de transport similaire par des étudiants néerlandais. Tous ensemble, cela m'a poussé à de nouvelles recherches.

Allons-y!

Pour commencer, bien sûr, il était juste nécessaire d'obtenir un lecteur de carte sans fil supportant "Ultralight" quelque part. Il y avait deux options: soit vous assembler (ce qui prendrait beaucoup de temps), ou acheter un appareil prêt à l'emploi. À la pensée de la deuxième option, conscient des prix il y a trois ans, j'ai eu la chair de poule. Mais j'ai quand même décidé de regarder les prix actuels. Et pas en vain! J'ai été agréablement surpris d'apprendre que vous pouvez acheter un appareil entièrement fonctionnel (OmniKey CardMan 5321), qui prend en charge un tas de cartes filaires et sans fil à un prix attractif - 4000 roubles.

Bien sûr, pas un peu, mais d'un autre côté, ce n'est pas 10000; De plus, l'achat d'un lecteur prêt permettait immédiatement de se concentrer sur la recherche de tickets, et non sur la conception et le débogage du fer, ce qui pourrait être retardé indéfiniment. En collaboration avec le lecteur de la même entreprise (ISBC) a été acheté un SDK original très pratique de la production locale. Il a, une fois de plus, permis de ne pas gaspiller d'énergie et de temps pour écrire de bas niveau et déboguer le travail du logiciel avec le lecteur, et se concentrer directement sur les tickets. Ainsi, pour quelques jours de codage sans hâte, un petit programme est né, à l'aide duquel il était possible d'observer et de contrôler toute la structure interne des «Ultralights» sous une forme pratique. Puis j'ai commencé à étudier les billets.

Mur sourd

Dans le processus d'étude à travers mon lecteur passé beaucoup de billets. Certains ont retroussé mes manches, sont sortis des poubelles, en ont acheté - regardé ce qu'ils ont écrit, puis sont passés et ont regardé à nouveau. Il s'agissait de billets de presque tous les types, à l'exception, peut-être, du voyage "Ultralight" pour 70 voyages. En quelques semaines, j'ai accumulé une base de données volumineuse et triée des décharges de différents tickets et dans différents états. Il y avait des décharges du même billet après chaque voyage, et plusieurs billets avec des numéros de métro en cours d'exécution. Dans ma collection, même quelques décharges de deux tickets sociaux individuels temporaires différents (l'un a été émis pour une période de 5 jours, l'autre pour 30), pris sur un certain intervalle de temps. Il s'est avéré être des spécimens très intéressants, et en même temps très rares (je les ai eu de première main avec un retour immédiat, seulement pour "lire").

En fait, c'est presque le seul type de "Ultralight", qui fonctionne non seulement dans le métro, mais aussi sur le transport terrestre. De plus, seul ce type de billet n'a pas de limite sur le nombre de voyages. Par la suite, ils m'ont très bien servi ... Tout ce zoo que j'ai rassemblé dans un but - pour définir clairement la structure et le format d'enregistrement des données sur le billet. Bien sûr, certains champs étaient visibles à la fois, à l'œil nu, mais certains ne le sont pas. Par exemple, je n'ai pas compris immédiatement où le numéro de ticket de métro a été enregistré (celui qui est imprimé dessus). La conscience est venue complètement par accident. Le fait est que je (ainsi que, je pense, la plupart d'entre nous), en regardant l'hexagone, est utilisé pour aligner l'information pour les octets et penser, au moins, octets. Il s'est avéré que cette approche est fausse. En regardant la décharge de billet, vous devez penser en plus petites unités - tetrads, et parfois des morceaux. Je me suis rendu compte que lorsque j'ai finalement vu le numéro de ticket, il a été déplacé de 4 bits par rapport au début de l'octet, et les 4 bits restants de l'autre côté du numéro étaient occupés par d'autres informations officielles. Après un moment, le format d'enregistrement des données sur les tickets est devenu presque complètement clair.

Il est devenu évident où et comment toutes les dates, les compteurs, les identifiants sont stockés. Il n'y avait que quelques champs, dont le but n'était pas clair simplement parce que les données qu'ils contenaient étaient identiques de la décharge à la décharge. Mais sur toute la joie et la fin - il serait stupide de supposer que de tels billets peuvent laisser non protégés. Dans chaque décharge il y avait 32 bits de diverses informations qui ne correspondaient pas avec le reste du contenu. J'ai supposé que c'était une sorte de somme de contrôle, un "hachage" de données écrites sur le ticket. Toutes les tentatives d'estimation ou de calcul de ces 32 bits s'avèrent être un échec total (en particulier, il a été supposé qu'il s'agit d'une sorte de CRC32, avec un polynôme non standard et une valeur de départ).

Lorsque vous essayez de modifier au moins un bit et demi d'informations à l'intérieur du ticket, le terminal de paiement dans le métro a clignoté "BAD TICKET" avec un gros jack, clouer les derniers clous dans le couvercle du cercueil. Bien sûr, il y a eu d'autres tentatives pour contourner le système, par exemple en copiant le ticket sur une carte propre (ici, hélas, la série de l'usine, qui a également participé à la génération du hachage), ou empêcher le tourniquet de changer le contenu du ticket. Le terminal de vérification a reconnu ce billet "éternel", mais a refusé d'autoriser le tourniquet ... Je me suis donc reposé contre le mur. Dans ce grand mur de béton solide, dont beaucoup ont l'habitude d'être tués par un décollage. Je n'ai trouvé aucune information sur les forums et les forums, j'ai décidé que c'est là que mes études sont terminées - il n'y a plus de façons, et mettre un gros point. Comme il s'est avéré, en vain ...

Étrange connaissance

La soirée de septembre n'était pas différente des autres. Il faisait presque nuit, la rue était fraîche et humide. J'étais assis devant l'écran et, en sirotant un thé vert chaud et légèrement sucré, je préparais paisiblement une planche pour mon prochain métier. DipTarce, un petit bastor, ICQ ... Quelqu'un a appelé sur Skype - distrait! Encore une fois ICQ, encore DipTrace - en général, tout est comme d'habitude. Une fois de plus, la fenêtre d'ICQ est apparue au premier plan - quelqu'un, jusqu'alors inconnu, a écrit "Bonjour". Je n'ai nullement hésité à répondre de la même manière. Le message suivant a été un tournant dans toute l'histoire: «Vous êtes intéressé par le métro, j'ai des ordures là-bas. Si cela vous intéresse, rencontrons-nous, je vais vous le dire. " Au début, j'étais un peu confus et alarmé (peut-être un divorce ou une installation, et peut-être même des «services spéciaux» sont devenus intéressés - la paranoïa fait des ravages), mais j'ai alors pensé: pourquoi pas?

Des services spéciaux ne m'intéressent pas, et le sol pour le divorce, et plus encore, pour l'établissement il semble y avoir non. Après une courte conversation, nous avons convenu de nous rencontrer dans l'après-midi, au centre du hall de l'une des stations de métro de Moscou. L'étranger était un grand jeune homme, portant des lunettes, avec un grand sac en plastique noir dans ses mains. Nous nous sommes salués, puis il m'a tendu un paquet avec les mots: "On, hold. Ça n'a pas été utile de toute façon, peut-être que ça vous sera utile. En regardant à l'intérieur, j'ai vu deux terminaux de métro, traduits par des journaux, plusieurs cartes en plastique blanc dispersées de façon chaotique et un cochon dans la boîte. À ma question de combien je dois cet argent, le gars a secoué la tête, a souri et a dit: «Ne faites-vous pas, personne ne devrait faire quoi que ce soit à quelqu'un ... Donc, je dois déjà courir, et mon train est comme fois! Allez, au revoir! "

Avec ces mots, il a fui, a sauté dans les portes déjà fermées de la voiture et est parti. Et moi, je l'avoue, je suis rentré chez moi un peu à Neponyatkah. Contact d'ICQ Je suis juste en cas de suppression, tout en nettoyant le contacté sur le serveur et en nettoyant les logs (encore bonjour, paranoïa). À la fin, écrivez encore, si cela. Mais il ne m'a plus jamais écrit ...

Le phénomène des gens de logiciel

Arrivé à la maison, j'ai démonté le colis. Le deuxième des terminaux était un validateur de bus (lourd, pancake!); les cartes étaient Mifare Classic 1K (propre), et le disque avait une seule archive. Après un examen sommaire du contenu, il s'est avéré que c'est un logiciel qui est utilisé dans les billetteries du métro. Mettant de côté le terminal et le validateur, j'ai décidé d'entreprendre l'étude de logiciels intéressants. Environ une heure après le désordre qui a été déballé, j'ai réussi à construire et exécuter ce programme sur mon ordinateur. Une autre heure était nécessaire pour comprendre sa structure. Après avoir peigné tous les fichiers ini (avec des commentaires aimablement laissés par le développeur), j'ai déjà eu une idée complète de ce que c'est, comment ça marche et ce qu'il mange. Mangez, comme il s'est avéré, avec le lecteur Parsec PR-P08, donc, faute de quoi, essayez le logiciel en action a échoué.

Le développeur était la société "Smartek" - un important entrepreneur public développant des systèmes de ce type (plus de détails peuvent être lus sur leur site web). Le programme a été écrit en Delphi en utilisant runtime-bpl'ok. De plus, le logiciel avait une structure modulaire, et tous les sous-routines, classes et composants étaient situés dans des DLL séparées ou bpl'ks avec des noms parlants (c'était le fichier le plus important des développeurs). Après une analyse rapide des intérieurs du logiciel, j'ai découvert que, premièrement, les informations sur tous les tickets émis sont transférées vers une base de données centralisée (d'ailleurs, c'est Oracle) et, deuxièmement, le programme utilise un certain mécanisme clé. Le programme pourrait communiquer avec la base de données non seulement en temps réel. Nous tirons des conclusions: toutes les opérations dans le système peuvent se produire avec un certain retard. Théoriquement, cela nous donne une longueur d'avance.

Mais tout d'abord je m'intéressais au mécanisme des clés (j'avais déjà commencé à deviner pourquoi cela pourrait être nécessaire). Donc, j'ai pris le désassembleur et je me suis mis au travail. Le mécanisme se composait de deux fichiers - CryptKeyRef.dll et keys.d (le seul fichier "difficile" dans le programme entier, qui, contrairement au fichier avec les clés, ne ressemble plus à rien). Et j'ai utilisé tout ce bon run-bpl'in SmLayout.bpl. Cette bibliothèque était juste une aubaine pour ma recherche - il contenait des classes pour travailler avec le remplissage interne des billets. Comme il s'agit de runtime-bpl, il suffisait de regarder sa table d'exportation pour comprendre 60% de quoi. Une analyse plus détaillée met tout à sa place. Rappelez-vous, au début de l'article, j'ai dit que dans la structure de "Ultralight" il y avait encore quelques champs, dont le but était incompréhensible?

L'un de ces champs est ce que l'on appelle "l'identificateur de disposition". En fait, tous les tickets Metro sont construits à partir d'une partie d'en-tête fixe et d'une partie variable de données. Ainsi, ce champ "Layout" dans l'en-tête vient de déterminer comment et quelles données se trouvent dans le reste du ticket. Il y en a plusieurs (chacun pour son propre type de ticket), et dans SmLayout.bpl chacun correspond à sa propre classe (plus la classe parent commune, qui avait des méthodes pour travailler avec la partie en-tête). Par conséquent, pour comprendre quels champs dans chaque mise en page sont responsables, c'était facile (même si parlant avec les noms des méthodes dans l'exportation!). Ayant complètement récupéré tout le Layout 8 (qui est utilisé dans "Ultralights") et revérifié, j'ai eu la bonne idée de tous les champs de la structure du ticket, j'ai pris le mécanisme de la clé. En effet, il était responsable de la génération du hachage. Comment le mécanisme fonctionne, il est devenu complètement clair après avoir étudié le travail de la méthode responsable du calcul du hash. Tout d'abord, la clé correcte est sélectionnée dans le fichier de clé (keys.d).

Le système est agencé pour que chaque type de ticket ait son propre identifiant (complet avec une table avec des identifiants et des noms de tickets, sous la forme d'un fichier texte avec des valeurs séparées par une virgule). Il se compose de l'identifiant de la zone (application) et de l'identifiant du type de la carte. Ainsi, en fonction de ces chiffres, la saisie est sélectionnée dans le fichier clé, à l'intérieur duquel il peut déjà y avoir plusieurs clés (au cas où une nouvelle clé a été entrée, et les anciens tickets sont toujours utilisés). Le nouveau ticket est enregistré en utilisant le tout premier ticket, et la validation est effectuée en utilisant toutes les clés de la saisie. Ensuite, la clé sélectionnée est décryptée avec CryptKeyRef.dll (pourquoi ils sont stockés cryptés, je ne vais pas y penser). Après cela, la clé décryptée et presque toutes les données de ticket, ainsi que son numéro de série et son numéro de série (la méthode de génération d'un "hash") est passée à la fonction ckCalcHashCode, située dans le même fichier CryptKeyRef.dll. À la sortie, nous obtenons une valeur sur laquelle je dans mon temps et "coincé" - le même "hash". Bien sûr, j'ai écrit un petit programme qui, en utilisant ces fonctions de CryptKeyRef.dll et fichier keys.d, pourrait vérifier et, dans ce cas, recalculer le "hachage" à l'intérieur de n'importe quel dump. J'ai revérifié tout sur plusieurs décharges, et, ayant reçu un résultat positif, je me suis contenté de dormir.

Touches de mauvais goût

Malgré le succès théorique, je voulais tout vérifier, pour ainsi dire, "au combat". Le jour suivant, revenant du travail, j'ai spécifiquement acheté un "Ultralight" frais pour un voyage pour voir si mes clés fonctionnent ou pas (apparemment elles étaient vieilles). Vous pouvez, bien sûr, immédiatement essayer d'écrire "fabriqué" "Ultralight" et aller vérifier, mais à ce moment-là, j'ai manqué de cartes vierges, et un peu effrayant d'aller "au hasard" - tout d'un coup quoi? Quand je suis rentré chez moi, je me suis tout d'abord précipité, sans même me laver les mains, à vérifier le ticket frais avec mes clés. Et puis j'ai attendu une grosse déception - "hash", enregistré dans le ticket ne passait par aucune des clés. Donc, les clés sont vraiment déjà fausses et remplacées par de nouvelles. Cela a complètement barré tous mes travaux. J'étais un peu triste. J'ai préparé du thé vert, j'ai joué un peu au piano (oui-oui) et je me suis assis pour planter mes frais inachevés ...

Tout n'est pas encore perdu

L'idée m'est venue à l'improviste, quand j'ai encore une fois regardé à l'intérieur du fichier avec les touches. J'ai remarqué que dans le "running" keiring (qui est utilisé pour calculer 1, 2, 5 voies et autres "Ultralights") il y avait deux clés - une nouvelle (à ce moment, bien sûr) et, apparemment, une ancienne. Mais il y avait aussi une saisie, dans laquelle il n'y avait qu'une seule clé. Avant, je n'y faisais pas attention, et je me concentrais sur le "courant". Pour calculer à quels tickets cette clé est utilisée, je ne savais pas. Quand j'ai regardé, quel genre de billet est attaché à l'enveloppe, alors j'ai flashé une petite étincelle d'espoir. Le fait est que ce type de billet était - VESB. Oui, c'est ce type de billet rare - une carte de voyage temporaire pour tous les types de transport. J'ai pensé que si le billet est unique, cette clé devrait être utilisée non seulement dans le métro, mais aussi sur le transport terrestre, où il est très difficile et long de le remplacer par un nouveau.

En outre, il n'y a qu'une seule clé en keiring, ce qui indirectement confirmé ma conjecture. Pour tout le reste, je me suis souvenu que lorsque je nettoyais le programme de métro à partir de différents "déchets", il y avait quelque chose de similaire à l'archive des anciens fichiers de clés. Après avoir creusé et ouvert l'archive originale, j'ai vu que c'était vraiment le cas. Et le plus important, après avoir parcouru tous les anciens fichiers clés, j'ai trouvé que cette clé est restée inchangée! Déjà sans un seul doute, j'ai rivé mon propre VESB (bon, j'avais des dumps du type qui simplifiait parfois la tâche - j'ai juste changé la date et le nombre dans les dumps), et le "hash" calculé en utilisant cette clé. Donc, il est temps de vérifier (surtout, je viens d'acheter un peu plus de plastique propre). En entrant dans le hall, j'ai d'abord mis mon "ticket" au terminal de vérification. Le tableau de bord indiquait la date d'expiration du billet, que j'ai indiqué, et la DEL verte s'allumait. Donc ça marche. Faisant une grimace plus facile et cachant du plastique blanc comme neige dans la manche, je me dirigeai vers le tourniquet, posai ma main sur le validateur et ... marcha calmement vers le vert joyeusement rougeoyant. Cela a marqué la victoire finale.

Et quelle est la prochaine?

Et puis les expériences ont commencé, au cours de laquelle beaucoup de choses intéressantes ont été découvertes. Par exemple, pour une telle VESB «gauche», vous ne pouvez marcher que deux ou trois jours. Le fait est que le numéro que j'indique dans le ticket "du chauve", avec chaque passe est stocké dans la mémoire de la tête du tourniquet, et après un certain temps est envoyé avec le reste au centre de données. Là, le système ne trouve pas un ticket vraiment émis avec un tel numéro et l'ajoute à la liste d'arrêt, qui est ensuite envoyée à tous les tourniquets du métro. Et cela devrait arriver avec tous les types de billets, non seulement avec le VEBB - en plus du "hash" et des touches qui changent fréquemment, c'est une très bonne défense. Le contourner, pour des raisons évidentes, n'est pas possible.

Il a également été observé que l'installation ou la non-installation de bits de verrouillage ne joue aucun rôle dans le fonctionnement ou non du ticket. La seule exception est le bit de blocage de la zone OTP, que le tourniquet vérifie apparemment toujours, même s'il n'a pas l'intention d'écrire dans OTP. Plus tard, j'ai pris les terminaux de métro et de bus, les ai mis en ordre, les ai étudiés et les ai lancés sur le stand. Maintenant, pour vérifier la prochaine estimation, il n'était plus nécessaire de courir avec un ticket de mutant fraîchement cuit dans le métro, mais il est devenu possible de les vérifier "sans quitter la billetterie." De plus, le terminal du métro s'est avéré tout aussi vieux (à tous les autres et buggy), comme mes clés. Donc, je pourrais essayer "au travail" et tous les autres types de billets "Ultralight" - quelque chose que je ne peux jamais faire "vivre" dans le métro. Parallèlement à ces expériences, j'ai continué à travailler sur des logiciels.

Comme il y avait beaucoup de débat sur le type d'algorithme utilisé pour calculer le "hachage", j'ai décidé de le restaurer complètement en réécrivant l'algorithme de zéro dans le langage de programmation "humain", et j'espérais juste comprendre quel type d'algorithme - quelque chose de largement connu ou une sorte de développement interne propre. En cours de route, j'ai été visité par de nombreuses pensées (y compris AES), mais avec une étude détaillée du code qui fonctionnait déjà sans l'utilisation des librairies Smartekov, il est apparu que cet algorithme était "seulement" GOST - le standard national de cryptage vous pouvez facilement le trouver sur le web). Plus précisément, une boucle 16-Z a été utilisée pour calculer le hachage. "Hash", en fait, ce n'est rien comme une imitation GOST.

La structure de l'information enregistrée sur le billet "Ultralight"

Quelle est la page, où et comment le numéro de série du matériel, bits de verrouillage et la zone OTP sont situés, vous pouvez lire dans la documentation d'origine (la spécification de fichier au format PDF avec une description complète de la puce est sur le disque). Je recommande de commencer l'étude avec elle. Je vais décrire la structure de la structure de données formée par les systèmes de métro dans la zone de l'utilisateur, qui est accessible pour la lecture et la réécriture (en l'absence de verrous, bien sûr). Tous les contenus du ticket peuvent être divisés de manière conditionnelle dans la partie d'en-tête et deux parties de données complètement dupliquées (ceci est fait pour la redondance et la protection contre les erreurs). La partie d'en-tête dans les tickets "Ultralight" commence à partir de la page 4. Une partie de la structure est identique dans tous les tickets et identifiants du système de Underground et MosGorTrans. Les 10 premiers bits sont l'identifiant de l'application; les 10 bits suivants - l'identifiant du type de carte (à propos de quel type d'identificateur il y a, vous pouvez lire dans un autre cadre spécialement sélectionné pour cela). Après les identifiants, le numéro de série du ticket est localisé (il est assommé au dos du ticket, ne le confondez pas avec le matériel - ce sont des choses différentes!) Avec une taille de 32 bits. Les 4 derniers bits sont le champ Layout, qui indique au système comment interpréter les données suivantes (quelque chose comme le format de fichier).

Pour les tickets Ultralight, la valeur de mise en page est 0x08. Ceci termine la même partie du titre. Plus loin dans le billet "Ultralight" est indiqué la date à laquelle le formulaire est valide (16 bits). Toutes les dates dans le système sont indiquées dans le format du nombre de jours écoulés à partir du 01/01/1992. Ici, la partie en-tête du ticket "Ultralight" se termine (les tickets avec un autre Layout peuvent encore contenir diverses informations supplémentaires). La première zone de données commence à la page 8. D'abord, 16 bits de la date d'émission du ticket sont écrits. Après cela, la période de validité du ticket en jours (à partir du moment de l'émission) est de 8 bits. Les 16 premiers bits de la page 9 sont le compteur de déclenchement. Il peut être soit décroissant à zéro (sur tous les tickets avec une limitation du nombre de trajets), soit augmenter à partir de zéro (sur les tickets WESC, sans limiter le nombre de trajets). Après le compteur, dans le reste de la page, le tourniquet inscrit son identifiant unique à chaque passage. Apparemment, ceci est utilisé pour éviter le re-passage sans attendre un ticket par le WESB (les tourniquets du lobby sont connectés au réseau et s'interrogent mutuellement), et aussi pour voir à quel tourniquet la passe a été faite (par exemple, en cas d'erreur ou de statistiques ). La page 10 est complètement occupée par un hachage de 32 bits.

La page 11 est vide. Cette zone de données est entièrement répliquée sur les 4 pages restantes (de 12 à 15). Il s'avère que, en fonctionnement normal, ces deux régions contiennent toujours les mêmes données. Séparément, il est nécessaire de dire à propos de l'utilisation du système de zone OTP. Il est utilisé pour le "burn out" progressif du ticket à chaque voyage (les tickets VESB ne s'appliquent pas). Les deux bits de poids le plus bas sont émis lorsque le ticket est annulé ou annulé (sur le stop-sheet). Le billet annulé n'est pas sujet à récupération. Il ne reste que 30 bits à brûler. Cette zone est représentée par le système comme 100% des trajets. A chaque nouveau voyage, un certain nombre de bits sont définis (du junior au senior), ce qui correspond à la quantité par trajet. Par exemple, pour un billet de 5 passagers avec chaque nouveau voyage, il sera épuisé à 6 bits, et pour un billet à 60 - un demi-bit (arrondi). Il est à noter que la réutilisation des tickets "Ultralight" est impossible non seulement à cause du "burn out" d'OTP, mais aussi parce que lors de la sortie du ticket (et peut-être même quand il est fait) presque toutes les pages sont bloquées . Ainsi, ni "recharger" ni changer le type de ticket à un autre ne fonctionnera pas.

Exemples d'identifiants de ticket de métro utilisés

Tous les nombres sont en notation décimale!

Identifiants d'application:

  • 262 - Billet pour le métro de Moscou.
  • 264 - Billet pour le transport terrestre à Moscou.
  • 266 - L'unique social de Moscou et le ministère de la Défense.
  • 270 - Billet "métro léger".

Identifiants du type de tickets "Ultralight":

  • 120 - Un voyage.
  • 121 - Deux voyages.
  • 126 - Cinq voyages.
  • "Dix voyages."
  • "Vingt voyages."
  • 129 Soixante voyages.
  • 130 - Bagages + passage.
  • 131 - Seuls les bagages.
  • 149 - Single "Ultralight" (70 voyages).
  • 150 - WESB.

Mifare Classique

J'ai également prêté attention à l'infortuné Mifare Classic 1K dans mes recherches. Comme vous le savez, l'obstacle le plus important sur le chemin de la "Classic" était les clés matérielles A et B. Heureusement, ces clés étaient dans l'un des modules du programme sous une forme ouverte (aux développeurs!) Et je n'ai pas eu de problème Travailler avec le contenu de ces cartes, en utilisant les clés reçues. Au cours des expériences, certaines caractéristiques intéressantes ont été révélées, telles que: le métro a utilisé le premier secteur de la carte pour stocker le ticket, et le transport terrestre a utilisé le quatrième; pas de protection, sauf pour les clés matérielles (qui, écrites dans le logiciel sous cette forme, très probablement, n'ont jamais changé du tout au moment de mettre le système en service) sur ces tickets n'existent pas.

Au lieu de cela, à la fin de chaque bloc, le CRC-16 est indiqué, juste pour protéger les données de la corruption. En outre, sur les cartes sociales, en plus des tickets, de nombreuses informations plus variées et intéressantes sont enregistrées. Par exemple, dans les 13e et 14e secteurs de cartes sociales, le nom, le nom et le patronyme du propriétaire sont indiqués. Ces données (et d'autres) peuvent être lues à l'aide de la clé publique 0xA0A1A2A3A4A5. Au cours des expériences, il a été possible de cloner complètement SCM étudiant, ainsi que plusieurs billets pour les cartes classiques pur.

Mais le système de clonage est remarquablement sauvegardé par le système stop-loss - ce ticket ne peut être utilisé que pendant deux jours, puis annulé (contrairement à l'Ultralight, la carte «Classic» peut être restaurée après l'annulation, mais à partir de la liste d'arrêt ça ne sauvera pas). Comme aucune protection sur les cartes Classic n'a été utilisée, elles sont rapidement devenues sans intérêt pour moi, et j'ai décidé de me concentrer sur l'étude Ultralight.

La fin, ou résumer

Les systèmes de métro, en particulier, les nouveaux billets "Ultralight", contrairement aux opinions et aux suppositions, étaient bien protégés. Très heureux que les développeurs aient utilisé un GOST fiable et éprouvé, et n'aient pas réinventé la roue. Avec une telle protection, forger un ticket "Ultralight", sans avoir accès à des données confidentielles (informations clés), c'est tout simplement impossible. Remarquablement pensé et le système de clés de remplacement, et le mécanisme de feuilles d'arrêt. Bien sûr, il y avait des lacunes et des erreurs. Le plus gros d'entre eux est un logiciel qui n'est protégé d'aucune façon.

Il suffisait d'abandonner l'utilisation de runtime-bpl, et cela compliquerait l'analyse des dizaines de fois! En option, - le traitement des parties critiques du programme AsProtect'om ou ExeCryptor'om, suivi par zakkovkoy tous les fichiers MoleBox'om réduirait la possibilité d'analyse presque à zéro. Toolkit quelque chose de peu coûteux. Et l'utilisation d'une bonne protection (de préférence, peu connue ou sur mesure) de ce type, mais avec des clés matérielles rendrait l'analyse du programme complètement impossible. Bien sûr, le Metropolitan est une entreprise de régime, mais n'oublie pas le facteur humain. Après tout, Kevin Mitnick a dit (et non seulement dit, mais aussi démontré par son propre exemple, pour lequel il s'est assis) que parfois pour atteindre l'objectif il est plus facile et plus efficace d'utiliser l'ingénierie sociale plutôt que d'essayer de briser la défense impénétrable. Eh bien, sur cette note, je vais finir mon récit. Et à vous, le lecteur, je souhaite des recherches plus intéressantes et plus réussies!








Description de l'algorithme de transformation cryptographique selon GOST 28147-89

Cette norme établit un algorithme de transformation cryptographique unique pour les systèmes de traitement de l'information dans les réseaux d'ordinateurs électroniques (ordinateurs), les complexes informatiques individuels et les ordinateurs, qui détermine les règles pour le cryptage des données et le développement d'imitovki.

L'algorithme de transformation cryptographique est destiné à l'implémentation matérielle ou logicielle, satisfait aux exigences cryptographiques et n'impose aucune restriction sur le degré de secret de l'information protégée.

La norme est obligatoire pour les organisations, les entreprises et les institutions qui appliquent la protection cryptographique des données stockées et transmises dans des réseaux informatiques, dans des systèmes informatiques séparés ou dans des ordinateurs.

Diagramme structurel de l'algorithme de transformation cryptographique

Le diagramme de l'algorithme de transformation cryptographique (cryptosystem), illustré à la figure 1, contient:

  • - un dispositif de stockage de clés de 256 bits composé de huit unités de 32 bits (X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 );
  • - quatre dispositifs de stockage 32 bits (N 1 , N 2 , N 3 , N 4 );
  • - deux dispositifs de stockage 32 bits (N 5 , N 6 ) avec les constantes de remplissage C 2 , C 1 enregistrées dans ceux-ci;
  • - deux additionneurs 32 bits modulo 2 32 (CM 1 , CM 3 );
  • - additionneur 32 bits de sommation bit à bit modulo 2 (CM 2 );
  • - additionneur 32 bits modulo (2 32 -1) (SM 4 );
  • - additionneur modulo 2 (CM 5 ), la restriction sur la capacité de l'additionneur CM 5 n'est pas superposée;
  • - unité de substitution (K);
  • - le registre du décalage cyclique par onze pas vers le débit le plus élevé (R).

Figure 1.

Le bloc de substitution K est constitué de huit noeuds de remplacement K1, K2, K3, K4, K5, K6, K7, K8 avec une mémoire de 64 bits chacun. Le vecteur de 32 bits arrivant au bloc de substitution est divisé en huit vecteurs consécutifs de 4 bits, chacun étant converti en un vecteur de 4 bits par le nœud de remplacement correspondant, qui est une table de seize lignes contenant quatre bits de remplissage par ligne. Le vecteur d'entrée détermine l'adresse de la ligne dans la table, le remplissage de cette ligne est un vecteur sortant. Les vecteurs de sortie à 4 bits sont ensuite séquentiellement combinés en un vecteur à 32 bits.

Lorsque les vecteurs binaires sont ajoutés et que le cycle est décalé, les bits supérieurs sont des bits de grands nombres.

Lors de l'écriture d'une clé (W 1 , W 2 , ..., W 256 ), W q Є {0,1}, q = i ÷ 256, â, la valeur W 1 est entrée dans le 1er chiffre de l'accumulateur X 0 , la valeur W 2 est entrée dans le deuxième chiffre de l'accumulateur X 0 , ..., la valeur W 32 est entrée dans le 32ème chiffre de l'accumulateur X 0 ; la valeur W 33 est entrée dans le 1er chiffre de l'accumulateur X 1 , la valeur W 34 est entrée dans le 2ème chiffre de l'accumulateur X 1 , ..., la valeur W 64 est entrée dans le 32ème bit de l'accumulateur X 1 ; la valeur W 65 est entrée dans le 1er chiffre de l'accumulateur X 2 , etc., la valeur de W 256 est entrée dans le 32ème bit de l'accumulateur X 7 .

Lors de l'écrasement d'informations, le contenu du p- ième chiffre d'un accumulateur (additionneur) est réécrit au p- ième chiffre d'un autre accumulateur (additionneur).

La valeur de la constante de remplissage C 1 (constante) de l'accumulateur N 6 est donnée dans le tableau 1.

Tableau 1

Décharge de l'accumulateur N 6

32

31

30

29

28

27ème

26ème

25

24

23

22

21

20

19

18ème

17ème

La valeur du chiffre

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Décharge de l'accumulateur N 6

16

15ème

14ème

13ème

12ème

11ème

10

9ème

8ème

7th

6th

5

4

3

2

1

La valeur du chiffre

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

La valeur de la constante de remplissage C 2 (constante) de l'accumulateur N 5 est donnée dans le tableau 2.

Tableau 2

Décharge de l'accumulateur N 5

32

31

30

29

28

27ème

26ème

25

24

23

22

21

20

19

18ème

17ème

La valeur du chiffre

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Décharge de l'accumulateur N 5

16

15ème

14ème

13ème

12ème

11ème

10

9ème

8ème

7th

6th

5

4

3

2

1

La valeur du chiffre

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Les clés qui définissent le remplissage de la CMU et les tables de la case de substitution K sont des éléments secrets et sont livrées dans l'ordre établi.

Le remplissage des tableaux de la case de substitution K est un élément clé à long terme commun au réseau informatique.

L'organisation de différents types de communication est réalisée en construisant un système de clés approprié. Dans ce cas, il est possible d'utiliser la possibilité de générer des clés (remplissage de la RAM) dans un mode de remplacement simple et de les crypter dans un mode de remplacement simple, offrant une protection imitatrice pour la transmission via des canaux de communication.

Il y a quatre types de travail dans le circuit cryptographique:

  • - cryptage (décryptage) des données dans un mode de remplacement simple;
  • - cryptage (décryptage) des données en mode gamma;
  • - Cryptage (décryptage) des données dans le mode de gommage avec rétroaction;
  • - Mode de développement de l'imitation.

Chiffrement en mode de remplacement simple

Cryptage des données ouvertes en mode de remplacement simple

Un cryptogramme qui implémente l'algorithme de cryptage dans le mode de remplacement simple devrait avoir la forme illustrée à la figure 2.


Figure 2

Les données publiques à chiffrer sont divisées en blocs de 64 bits chacun. L'entrée de tout bloc T 0 = (a 1 (0), a 2 (0), ..., 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) de l'information binaire dans les accumulateurs N 1 et N 2 étant réalisés de sorte que la valeur a 1 (0) soit introduite dans le premier bit N 1 , la valeur a 2 (0) soit introduite dans le deuxième bit N 1 , etc., la valeur a 32 ( 0) est introduit dans le 32-ème bit N 1 ; la valeur b 1 (0) est entrée dans le 1er bit N 2 , la valeur b 2 (0) est entrée dans le 2ème bit N 2 , etc., la valeur b 32 (0) est entrée dans le 32 ème bit N 2 . En conséquence, l'état (un 32 (0), un 31 (0), ..., un 2 (0), un 1 (0)) de l'anneau de stockage N 1 et l'état (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) de l'anneau de stockage N 2 .

256 bits de la clé sont entrés dans le CMU. Le contenu des huit lecteurs 32 bits X 0 , X 1 , ..., X 7 est:

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

L'algorithme de cryptage d'un bloc de 64 bits de données ouvertes dans le mode de remplacement simple est constitué de 32 cycles.

Dans le premier cycle, le remplissage initial de l'accumulateur N 1 est sommé modulo 2 32 dans l'additionneur CM 1 avec le remplissage de l'accumulateur X 0 , tandis que le stockage de l'accumulateur N 1 est retenu.

Le résultat de la sommation est transformé dans le bloc de substitution K et le vecteur résultant est appliqué à l'entrée du registre R, où il est décalé cycliquement de onze pas vers les bits de poids fort. Le résultat du décalage est sommé bit à bit modulo 2 dans l'additionneur CM 2 avec un remplissage de 32 bits de l'anneau de stockage N 2 . Le résultat obtenu dans CM 2 est écrit en N 1 , tandis que l'ancienne valeur de N 1 est réécrite en N 2 . Le premier cycle se termine.

Les cycles suivants sont effectués de la même manière, tandis que dans le 2ème cycle, le remplissage X1 est lu dans la FEC, dans le 3ème cycle, le remplissage X2 est lu dans la FEC, etc., le remplissage X7 est lu dans le CCD dans le 8ème cycle. Dans les cycles du 9 au 16, ainsi que dans les cycles du 17 au 24, les plombages de la CDQ sont lus dans le même ordre: X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 .

Dans les huit derniers cycles du 25 au 32, l'ordre de lecture des plombages du CCD est inversé: X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Ainsi, lors du cryptage en 32 cycles, l'ordre suivant est utilisé pour sélectionner le contenu des lecteurs:

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

Dans le 32ème cycle, le résultat de l'additionneur CM 2 est inséré dans l'accumulateur N 2 , et l'ancien remplissage est stocké dans le stockage N 1 .

Le cryptage des accumulateurs N1 et N2 reçus après le 32ème cycle de cryptage est un bloc de données cryptées correspondant au bloc de données ouvert.

Décryptage des données chiffrées dans un mode de remplacement simple

Un cryptogramme qui implémente l'algorithme de décryptage dans le mode de remplacement simple a la même forme (voir Figure 2) que dans le cas du cryptage. Dans la ROM, 256 bits de la même clé sur laquelle le cryptage a été effectué sont entrés. Les données cryptées à déchiffrer sont divisées en blocs de 64 bits chacun. L'entrée de tout bloc est T = (a 1 (32), et 2 (32), ..., et 32 (32), b 1 (32), b 2 (32), ..., b 32 (32) 1 et N 2 est fait de sorte que la valeur d'un 1 (32) soit entrée dans le 1er bit N 1 , la valeur d'un 2 (32) est entrée dans le 2ème bit N 1 , etc., la valeur d'un 32 (32) est introduit dans le 32-ème bit N 1 ; la valeur b 1 (32) est introduite dans le 1er bit N 2 , la valeur b 2 (32) est introduite dans le 2ème bit N 2 , etc., la valeur b 32 (32) est entrée dans le 32 ème bit N 2 .

Le décryptage est effectué selon le même algorithme que le cryptage des données ouvertes, avec le changement que le remplissage des unités de stockage X 0 , X 1 , ..., X 7 est extrait de la CPU dans les cycles de décryptage dans l'ordre suivant:

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

Reçu après 32 cycles de fonctionnement, le remplissage des accumulateurs N 1 et N 2 est constitué d'un bloc de données ouvert.

T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) correspondant au bloc de données cryptées, la valeur d'un 1 (0) du bloc T 0 correspond au contenu du 1er chiffre N 1 , la valeur a 2 (0) correspond au contenu du 2ème chiffre N 1 , etc., la valeur a 32 (0) correspond au contenu du 32 ... le chiffre N 1 ; la valeur b 1 (0) correspond au contenu du 1er chiffre N 2 , la valeur b 2 (0) correspond au contenu du 2ème chiffre N 2 , etc., la valeur b 32 (0) correspond au contenu du 32ème bit N 2 .

De même, les blocs restants de données cryptées sont déchiffrés.

Mode Gamma

Cryptage des données ouvertes en mode gamma

Un cryptogramme qui implémente l'algorithme de cryptage en mode gamma doit avoir la forme illustrée à la figure 3.


Figure 3

Les données ouvertes, divisées en blocs de 64 bits T 0(1) , T 0(2) , ..., T 0(M-1) , T 0(M) , sont cryptées en mode gamma par sommation binaire modulo 2 dans l'additionneur CM 5 avec un gamma du chiffre G, qui est produit par des blocs de 64 bits, c.-à-d.

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

où M est déterminé par la quantité de données chiffrées.

(I) est le i-ième bloc de 64 bits, i = 1 ÷ Ì, le nombre de bits dans le bloc T 0(M) peut être inférieur à 64, tandis que la partie de l'échelle de chiffrement du bloc F m(M) inutilisée pour le cryptage, mis au rebut.

256 bits de la clé sont entrés dans le CMU. Dans les entraînements N 1 , N 2, une séquence binaire de 64 bits (synchronisation) S = (S 1 , S 2 , ..., S 64 ) est introduite, qui est le remplissage initial de ces entraînements pour la génération subséquente de M blocs du chiffrement gamma. La synchronisation est introduite dans N1 et N2 de sorte que la valeur de S1 est entrée dans le premier bit N1, la valeur S2 est entrée dans le second bit N1, etc., la valeur de S32 est entrée dans le 32 bits N 1 ; la valeur S 33 est entrée dans le premier bit N 2 , la valeur S 34 est entrée dans le deuxième bit N 2 , etc., la valeur S 64 est entrée dans le N 2 32 bits.

Le remplissage initial des entraînements N 1 et N 2 (envoi synchrone S) est crypté dans le mode de remplacement simple conformément aux exigences du paragraphe 1.3.1. Le résultat du cryptage est réécrit dans des accumulateurs 32 bits N 3 et N 4 de sorte que le remplissage N 1 est réécrit dans N 3 , et le remplissage N 2 est réécrit dans N 4 .

Le remplissage de l'accumulateur N 4 est sommé modulo (2 32 -1) dans l'additionneur SM 4 avec une constante de 32 bits С 1 de l'accumulateur N 6 , le résultat est écrit en N 4 .

Le remplissage de l'accumulateur N 3 est sommé modulo 2 32 dans l'additionneur SM 3 avec une constante de 32 bits C 2 provenant de l'accumulateur N 5 , le résultat est écrit en N 3 .

Le remplissage de N 3 est réécrit en N 1 et le remplissage de N 4 est réécrit en N 2 , tandis que le remplissage de N 3 , N 4 est conservé.

Le remplissage N 1 et N 2 est crypté dans le mode de remplacement simple conformément aux exigences de la clause 3.1. Le remplissage N 1 , N 2 obtenu par chiffrement forme le premier bloc 64 bits de l'échelle chiffrée G w(1) , sommé bit à bit modulo 2 dans l'additionneur CM 5 avec le premier bloc de données ouvert 64 bits T 0(1) = (t 1(1) , t 2(1) , ..., t 63(1) , t 64(1) ). En résultat de la sommation, un bloc de 64 bits de données cryptées est obtenu: T w(1) = (τ 1(1) , τ 2(1) , ..., τ 63(1) , τ 64(1) ).

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

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

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

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

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

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

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

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

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


Рисунок 4

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

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

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

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

Le bloc de données cryptées Tm(1) est également simultanément l'état initial N 1 , N 2 pour générer le second bloc de l'échelle de chiffrement G r (2) et est réécrit par retour sur les entraînements spécifiés. Dans ce cas, la valeur de τ 1(1) est introduite dans le premier bit N 1 , la valeur de τ 2(1) est introduite dans le deuxième bit N 1 , etc., la valeur de τ 32(1) est introduite dans le 32ème bit N 1 ; La valeur de τ 33(1) est introduite dans le 1er bit N 2 , la valeur de τ 34(1) est introduite dans le 2ème bit N 2 , etc., la valeur de τ 64(1) est introduite dans le 32 ème bit N 2 .

Le remplissage N 1 , N 2 est crypté dans le mode de remplacement simple conformément aux exigences de la clause 3.1. Le remplissage N1, N2 obtenu à la suite du cryptage forme le second bloc de 64 bits du chiffre gamma Gw (2) , qui est additionné numériquement modulo 2 dans l'additionneur CM 5 avec le deuxième bloc de données ouvertes T 0(2) .

La génération des blocs suivants de l'échelle chiffrée Gw(i) et le chiffrement des blocs correspondants de données ouvertes T 0(i) (i = 3 ÷ Ì) sont effectués de façon analogue. Si la longueur du dernier Mième bloc de données ouvertes T 0(M) est inférieure à 64 bits, alors seul le nombre correspondant de chiffres de la plage de chiffrement est utilisé à partir de G r (M) , les bits restants sont rejetés.

La synchronisation S et les blocs de données cryptées Т ш(1) , Т ш(2) ..., Т ш(М) sont transmis au canal de communication ou à la mémoire de l'ordinateur.

Décryptage de données cryptées dans un mode gommant avec rétroaction

Lors du décryptage, le circuit cryptographique a la même forme que lorsqu'il est crypté (voir Figure 4). Dans la CMU, 256 bits de la même clé sont entrés, sur lesquels T 0(1) , T 0(2) ..., T 0(M) ont été cryptés. La synchronisation est introduite dans N1, N2 de telle sorte que la valeur de S1 est introduite dans le premier bit N1, la valeur S2 est entrée dans le second bit N1, etc., la valeur de S32 est entrée dans le 32ème bit N 1 ; la valeur S 33 est entrée dans le premier bit N 2 , la valeur S 34 est entrée dans le deuxième bit N 2 , etc., la valeur S 64 est entrée dans le N 2 32 bits.

Le remplissage initial des entraînements N 1 et N 2 (synchronisation S) est crypté dans le mode de remplacement simple conformément aux exigences de la clause 3.1. Le remplissage résultant N 1 , N 2 forme le premier bloc de 64 bits du chiffre gamma Gw (1) , qui est additionné numériquement modulo 2 dans l'additionneur CM 5 avec le bloc de données crypté T w(1) . Il en résulte que le premier bloc de données ouvertes T 0(1) est obtenu.

Le bloc de données cryptées Т ш(1) est le remplissage initial N 1 , N 2 pour générer le second bloc de l'échelle de chiffrement Гш (2) . Le bloc T w(1) est écrit en N 1 , N 2 . Dans ce cas, la valeur de τ 1(1) est introduite dans le premier bit N 1 , la valeur de τ 2(1) est introduite dans le deuxième bit N 1 , etc., la valeur de τ 32(1) est introduite dans le 32ème bit N 1 ; La valeur de τ 33(1) est introduite dans le 1er bit N 2 , la valeur de τ 34(1) est introduite dans le 2ème bit N 2 , etc., la valeur de τ 64(1) est introduite dans le 32 ème bit N 2 . Le remplissage reçu N 1 , N 2 est crypté en mode de remplacement simple conformément aux exigences de la clause 3.1, le bloc résultant G r (2) est sommé bit par bit modulo 2 dans l'additionneur CM 5 avec le deuxième bloc de données cryptées T w(2) . Par conséquent, un bloc de données ouvert T 0(2) est obtenu.

De même, dans N 1 , N 2 blocs des données cryptées T w(2) , T w(3) ..., T w(M-1) sont séquentiellement enregistrés, (4) , ..., Γω(Μ) . Les blocs de l'échelle chiffrée sont additionnés numériquement modulo 2 dans l'additionneur CM 5 avec des blocs de données chiffrées T w(3) , T w(4) ..., T w(M) , résultant en blocs de données ouvertes T 0(3) , T 0( 4) , ..., T 0(M) , alors que la longueur du dernier bloc de données ouvertes T 0(M) peut contenir moins de 64 bits.

Mode de simulation

Pour fournir une protection d'imitation des données ouvertes constituées de M blocs de 64 bits T 0(1) , T 0(2) , ..., T 0(M) , M≥2, un bloc supplémentaire de 1 bits est créé (imitation I l ). Le processus de simulation est uniforme pour tous les modes de cryptage.

Le premier bloc de données ouvertes est 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)) est écrit dans les anneaux de stockage N 1 et N 2 , la valeur t 1(1) = a 1(1) (0) est introduite dans le premier bit N 1 , la valeur t 2(1) = a 2(1) (0) est introduite dans le deuxième bit N 1 , etc., la valeur de t 32(1) = 32(1) (0) est entrée dans le 32ème bit N 1 ; La valeur de t 33(1) = b 1(1) (0) est entrée dans le 1er bit N 2 , etc., la valeur t 34(1) = b 32(1) (0) est introduite dans le 32ème chiffre N 2 .

Le remplissage N 1 et N 2 subit une transformation correspondant aux 16 premiers cycles de l'algorithme de cryptage dans le mode de remplacement simple, conformément aux exigences de la clause 3.1. Dans la CMU, la même clé est utilisée pour chiffrer les blocs de données ouvertes T 0(1) , T 0(2) , ..., T 0(M) dans les blocs correspondants des données chiffrées T w(1) , T w(2) , ..., Tm(M) .

Le remplissage de N 1 et N 2 obtenu après 16 cycles de travail, ayant la forme ( 1 1(1) (16), a 2(1) (16), ..., a 32(1) (16), b 1(1) ( 16), b2 (1) (16), ..., b32 (1) (16)) est additionné dans CM 5 modulo 2 avec le deuxième bloc T 0(2) = (t 1(2) , t 2( 2) , ..., t 64(2) ). Le résultat de sommation est enregistré dans N 1 et N 2 et est soumis à une transformation correspondant aux 16 premiers cycles de l'algorithme de chiffrement dans le mode de remplacement simple.

Le remplissage résultant N 1 et N 2 est sommé dans CM 5 modulo 2 avec le troisième bloc T 0(3) , etc., le dernier bloc T 0(M) = (t 1(M) , t 2(M) , ... , t 64(M) ), éventuellement complétée à zéro avec un bloc de 64 bits, est sommée dans CM 5 modulo 2 avec le remplissage N 1 , et 1(M-1) (16), et 2(M-1) ( 16), ..., 32(M-1) (16), b 1(M-1) (16), b 2(M-1 ) . Le résultat de sommation est stocké dans N 1 , N 2 et est crypté dans le mode de remplacement simple pour les 16 premiers cycles de l'opération d'algorithme. A partir du remplissage obtenu des anneaux de stockage N 1 et N 2, on choisit le segment I l = [a 32l + 1(M) (16), et 32l + 1(M) (16), ..., a 32(M) (16 )].

Imitovlyavka ET l est transmis via le canal de communication ou à la mémoire de l'ordinateur à la fin des données cryptées, c'est-à-dire. Tm(1) , Tm(2) , ..., Tm(M) et l .

Les données cryptées reçues T w(1) , T w(2) , ..., T w(M) sont déchiffrées, une imitation est générée à partir des blocs obtenus de données ouvertes T 0(1) , T 0(2) , ..., T 0(M) Et 'l , qui est ensuite comparée à l'imitation I1, obtenue avec les données cryptées à partir du canal de communication ou de la mémoire de l'ordinateur. En cas de non-concordance des imitations, les blocs obtenus des données ouvertes T 0(1) , T 0(2) , ..., T 0(M) sont considérés comme faux.

La valeur du paramètre l (le nombre de bits dans l'imitatif) est déterminée par les exigences cryptographiques actuelles, en tenant compte du fait que la probabilité d'imposer de fausses données est de 2 - l .