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

Piratage du métro (cartes de voyage) + ALGORITHME DES TRANSFORMATIONS CRYPTOGRAPHIQUES CONFORMÉMENT À GOST 28147-89

Sur la page:


Pirater le métro (cartes de voyage)

Connaissez-vous le désir de résoudre toutes les énigmes et d'ouvrir toutes les défenses du métro de Moscou? Par exemple, faites-vous un «ticket éternel»? Mais après tout, les spécialistes du métro ont de plus en plus recours à des méthodes de protection de plus en plus sophistiquées. Les jetons en métal ont été remplacés par des en plastique, ceux-ci par des tickets magnétiques, et les cartes sans contact ont remplacé les magnétiques. De nombreux chercheurs ont laissé tomber leurs mains - il semble que le métro soit devenu une forteresse imprenable. Mais toute protection peut être contournée. Et souvent, il est souvent plus facile de l'ouvrir que de construire ...

Comment tout a commencé

L’intérêt pour les systèmes de métro m’est venu il y a longtemps, par exemple à l’école, alors qu’il y avait encore des billets avec une bande magnétique. Puis (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 ça marche. Mais à cette époque, je n’avais pas assez de compétences et il y avait peu d’informations publiques, en particulier sur ces technologies. J'ai dû repousser longtemps l'idée de recherche, mais je me suis promis d'y revenir définitivement ...

Il y a trois ans, j'ai de nouveau réveillé l'intérêt pour le sujet du métro. J'ai activement étudié les tickets magnétiques (il y avait beaucoup d'informations à ce sujet sur Internet) et j'ai même mis sur pied une petite machine permettant de dupliquer deux têtes à partir d'enregistreurs à bande et une petite quantité de poudre. Je n'ai pas oublié ma carte sociale (déjà étudiante). Mais après avoir étudié la documentation, il m'est apparu que le système était pratiquement inaccessible: la puce MF1S50 Mifare Classic 1K, sur la base de laquelle les cartes sociales sont créées, est protégée par deux clés de 48 bits. Au niveau matériel, le piratage si simplement ne fonctionnera pas, et vous pouvez trier les clés jusqu'à la fin du système solaire. Oui, et les détenteurs de cartes qui soutenaient Classic avaient à l'époque des coûts insupportables (je ne pensais pas du tout à Ebay, hélas). L’intérêt pour les tickets magnétiques a rapidement refroidi et la carte sociale a dû être remise à plus tard.

Rencontre: Ultralight

Les billets ultra-légers sont apparus récemment dans notre métro, mais ont immédiatement suscité un grand intérêt parmi le public. Ils ont commencé à marteler, à déchirer, à coller avec un fer à repasser et à appliquer d'autres méthodes de cryptanalyse thermorectale. Je dois admettre que la soif de connaissances m'a fait faire des folies pour un couple. À la suite de leurs études et de leurs recherches sur Internet, il a été établi - cela ne ressemble en rien à Mifare Ultralight, la version «légère» compatible de Mifare Classic. Un rapide coup d'œil à la documentation relative aux puces de cette norme montre clairement que ces cartes ne sont pas dotées de systèmes de sécurité intégrés. En plus de cela, j'ai attaqué un article décrivant le piratage réussi d'un système de transport similaire par des étudiants néerlandais. Tous ensemble m'ont poussé vers de nouvelles recherches.

Allons-y!

Pour commencer, bien sûr, il était juste nécessaire de se procurer un lecteur de carte sans fil compatible Ultralight. Il y avait deux options: soit l'assembler soi-même (ce qui prendrait beaucoup de temps), soit acheter un appareil prêt à l'emploi. Quand j'ai pensé à la deuxième option, soucieuse des prix il y a trois ans, j'ai eu la chair de poule. Mais j'ai quand même décidé de voir 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 ensemble de cartes filaires et sans fil à un prix attractif - 4 000 roubles.

Bien sûr, pas un peu, mais d’un autre côté, ce n’est pas 10 000; De plus, l’achat d’un lecteur prêt à l’emploi permettait de se concentrer immédiatement sur la recherche de billets, et non sur la conception et le débogage du fer, qui risquerait de s’éterniser indéfiniment. Avec un lecteur de la même société (ISBC), un SDK local original très pratique a été acheté. Il a de nouveau permis de ne pas perdre de temps et d’énergie à écrire un logiciel de bas niveau et de débogage avec le lecteur, mais à se concentrer directement sur les tickets. Ainsi, en quelques jours de codage sans hâte, un petit programme était né, avec lequel il était possible d'observer et d'éditer de manière pratique toute la structure interne d'Ultralight. Puis j'ai commencé à étudier les billets.

Mur blanc

En train d'étudier, beaucoup de billets ont été passés par mon lecteur. Certains je me suis retroussé les manches, je suis sorti de la poubelle, j'en ai acheté - j'ai regardé ce qui était écrit dessus, puis j'ai parcouru et regardé de nouveau. C'étaient des billets de presque tous les types, à l'exception peut-être du billet Ultralight pour 70 voyages. Après quelques semaines, j'ai accumulé une base de données volumineuse et triée de dumps de différents tickets et dans différents états. Il y avait des décharges prises sur le même ticket après chaque voyage et plusieurs tickets avec des numéros de métro allant dans une rangée. Ma collection a même reçu plusieurs dépôts de deux tickets sociaux unifiés temporaires différents (l'un était émis pour une période de 5 jours, l'autre 30), tournés après un certain intervalle de temps. Ces spécimens se sont avérés être des spécimens très intéressants et en même temps très rares (je les ai obtenus avec un retour immédiat, uniquement pour "lire").

En fait, il s’agit presque du seul type d’Ultralight qui fonctionne non seulement dans le métro, mais également dans les transports terrestres. De plus, seul ce type de billet ne limite pas le nombre de voyages. Par la suite, c’est eux qui m’ont rendu un excellent service. J’ai rassemblé tout ce zoo dans un seul but: déterminer clairement la structure et le format de l’enregistrement des données sur le ticket. Bien sûr, certains champs étaient immédiatement visibles à l'œil nu, mais d'autres non. Par exemple, je ne comprenais pas immédiatement où était inscrit le numéro du ticket de métro (le même que celui imprimé dessus). La prise de conscience est venue par accident. Le fait est que moi (comme je pense la plupart d’entre nous), en regardant l’hexagone, j’avais l’habitude d’aligner les informations pour moi-même et de penser, au moins, octets. Il s'est avéré que cette approche est incorrecte ici. En regardant un vidage de ticket, vous devez penser à des unités plus petites - des tétrades et parfois des bits. J'ai compris cela lorsque j'ai finalement «vu» le numéro du ticket: il s'est avéré être décalé de 4 bits par rapport au début de l'octet et les 4 bits restants des deux côtés du numéro étaient occupés par d'autres informations officielles. Après un certain temps, le format d'enregistrement des données sur les billets a été presque complètement compris.

Il est devenu évident où et comment toutes les dates, compteurs et identifiants sont stockés. Il ne restait que quelques champs dont le but n'était pas clair simplement parce que les données qu'ils contenaient étaient les mêmes d'un dump à l'autre. Mais là-dessus, toute la joie a pris fin - il serait insensé de supposer que de tels billets pourraient rester sans protection. Chaque vidage contenait 32 bits d'informations diverses qui ne correspondaient pas au reste du contenu. J'ai suggéré qu'il s'agissait d'une sorte de somme de contrôle, d'un «hachage» des données enregistrées sur le ticket. Toutes les tentatives d'estimation ou de calcul de ces 32 bits se sont avérées être un échec complet (en particulier, il était supposé qu'il s'agissait d'une sorte de CRC32, avec un polynôme non standard et une valeur de départ).

En essayant de modifier au moins un bit et demi d'informations à l'intérieur du ticket, le terminal de contrôle dans le métro a mis en évidence «BAD TICKET», enfonçant les derniers clous dans le couvercle du cercueil avec un gros vérin. Bien sûr, il y a eu des tentatives pour contourner le système par d'autres moyens, par exemple, pour essayer de copier un ticket sur une carte vierge (ici, hélas, le numéro de série de l'usine a été empêché, ce qui a également contribué à la génération du "hachage") ou a défini les verrous de cette manière. pour empêcher le tourniquet de changer le contenu du ticket. Le terminal de caisse a reconnu un tel billet «éternel», mais a refusé de démarrer le tourniquet… Ainsi, je me suis heurté au mur. Dans ce grand mur de béton solide, sur lequel beaucoup ont l’habitude de se tuer en courant. N'ayant trouvé aucune information sur les forums et les forums, j'ai décidé que mes recherches étaient terminées à ce sujet - il n'y avait plus aucun moyen, et j'ai mis une balle dedans. 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. Je me suis assis devant l'écran du moniteur et, tout en buvant du thé vert légèrement sucré chaud, j'ai soulevé paisiblement une planche pour mon prochain travail. DipTarce, un peu bashorg, ICQ ... Quelqu'un a appelé sur Skype - distraire! Encore une fois, ICQ, encore une fois DipTrace - en général, tout est comme d'habitude. Une fois de plus, une fenêtre ICQ est tombée au premier plan - quelqu'un, jusqu'alors inconnu de moi, a écrit «Bonjour». Sans hésiter, j'ai répondu de la même manière. Le message suivant a marqué un tournant dans toute l'histoire: «Vous semblez être intéressé par le métro, j'ai un petit bric-à-brac ici. Si cela vous intéresse, rencontrons-nous, je vous le dirai. Au début, j'étais un peu gêné et alerte (peut-être un divorce ou une fraude, ou peut-être que les «services spéciaux» ont commencé à intéresser - la paranoïa a des conséquences néfastes), mais j'ai alors pensé: pourquoi pas?

Il était peu probable que les services spéciaux s’intéressent à moi, mais il ne semblait pas y avoir de motif de divorce, et plus encore de montage. Après une courte conversation, nous avons convenu de nous retrouver dans l'après-midi, au centre du hall d'une des stations de métro de Moscou. L’étranger s’est avéré être un grand jeune homme vêtu de lunettes et tenant un grand sac en plastique noir à la main. Nous nous sommes salués, puis il m'a tendu un paquet avec les mots: «Attends, attends. Cela n’a toujours pas été utile pour moi, peut-être que cela vous sera utile. En regardant à l'intérieur, j'ai vu deux terminaux de métro arrangés avec des journaux, plusieurs cartes en plastique blanches dispersées au hasard et un blanc dans une boîte. A ma question sur combien je dois (argent) pour cela, le gars secoua la tête, sourit et dit: "Pourquoi, vous ne devez rien à personne, faites-le ... Alors, je dois déjà courir, voilà mon train une fois! Allez, au revoir!

Avec ces mots, il s’enfuit, sauta par la portière déjà fermée et s’en alla. Et j'avoue que je suis rentré chez moi un peu inexplicablement. Juste au cas où, j'ai supprimé le contact d'ICQ, tout en nettoyant la liste de contacts sur le serveur et en rangeant les journaux (bonjour encore une fois, paranoïa). En fin de compte, il écrira encore, si ça. Mais il ne m'a plus jamais écrit ...

Le phénomène du logiciel au peuple

En arrivant à la maison, j'ai démonté le colis. Le deuxième des terminaux s’est avéré être un validateur de bus (lourd, bon sang!); les cartes étaient Mifare Classic 1K (vierge) et il n'y avait qu'une seule archive sur le disque. Après une rapide connaissance du contenu, il s’est avéré qu’il s’agissait d’un logiciel utilisé au guichet. Mettant de côté le terminal et le validateur, j'ai décidé de me lancer dans l'étude de logiciels intéressants. Au bout d’une heure environ, j’ai réussi à créer et à exécuter ce programme sur mon ordinateur à partir du désordre décompressé. Il a fallu une autre heure pour comprendre sa structure. Après avoir passé au peigne fin tous les fichiers ini (avec les commentaires aimablement laissés par le développeur), j'avais déjà une idée complète de ce que c'est, de son fonctionnement et de ce avec quoi il est mangé. En fait, ils mangent avec le lecteur Parsec PR-P08. Par conséquent, faute d’un lecteur, il n’a pas été possible d’essayer le logiciel en action.

Le développeur était Smartek, un important contractant public chargé de développer de tels systèmes (plus de détails à ce sujet sur leur site web). Le programme a été écrit en Delphi avec runtime-bpl'ok. De plus, le logiciel avait une structure modulaire et tous les sous-programmes, classes et composants étaient situés dans des DLL ou des bpl distincts avec des noms parlants (il s’agissait du fichier le plus important des développeurs). Après une analyse rapide des composants internes du logiciel, j'ai découvert que, d'une part, les informations sur tous les tickets émis sont transférées dans une base de données centralisée (à propos, il s'agit d'Oracle) et, d'autre part, le programme utilise un certain mécanisme de 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 du système peuvent avoir lieu avec un certain retard. Théoriquement, cela nous donne une longueur d'avance.

Mais tout d’abord, j’ai été intéressé par le mécanisme clé (j’avais déjà commencé à deviner pourquoi il pourrait être nécessaire). Alors, j'ai pris le désassembleur et je me suis mis au travail. Le mécanisme consistait en deux fichiers - CryptKeyRef.dll et keys.d (le seul fichier "compliqué" de tout le programme qui, à l'exception du fichier avec les clés, ne ressemble à rien d'autre). Et j'ai utilisé toute cette bonté de runtime-bpl'in SmLayout.bpl. Cette bibliothèque était juste une aubaine pour mes recherches - elle contenait des cours pour travailler avec le contenu interne des tickets. Comme il s'agit de runtime-bpl, il suffisait simplement de regarder son tableau des exportations pour comprendre déjà à 60% ce qui était quoi. Une analyse plus détaillée a tout mis à sa place. Rappelez-vous qu'au début de l'article, je parlais du fait que dans la structure d'Ultralight, il y avait plusieurs autres champs dont le but n'était pas clair?

L’un de ces champs est ce que l’on appelle «identifiant de mise en page». En fait, tous les tickets de métro sont construits à partir d’un en-tête fixe et d’une partie à données variables. Ainsi, ce champ «Disposition» dans le titre vient de déterminer comment et quelles données se trouvent dans le reste du ticket. Il existe plusieurs schémas de ce type (chacun pour son propre type de ticket) et, dans SmLayout.bpl, chacun correspond à sa propre classe (plus une classe parent commune, dans laquelle il existait des méthodes pour travailler avec la partie en-tête). Par conséquent, il était facile de déterminer quels champs de chaque mise en page sont responsables de quoi (ce serait le cas, avec des noms de méthodes parlants dans l'exportation!). Ayant complètement terminé le Layout 8 (qui est utilisé dans Ultralight) et après avoir vérifié si j'avais une idée exacte de tous les champs de la structure du ticket, j'ai repris le mécanisme de clé. En effet, il était responsable de la génération du "hash". Le fonctionnement de ce mécanisme est devenu parfaitement clair après avoir étudié le fonctionnement de la méthode responsable du calcul du "hachage". Tout d'abord, la clé correcte est sélectionnée dans le fichier avec les clés (keys.d).

Le système est conçu pour que chaque type de ticket ait son propre identifiant (l'ensemble complet comprend un tableau complet avec les identifiants et les noms de ticket, sous la forme d'un fichier texte avec des valeurs séparées par une virgule). Il se compose d'un identifiant de zone (application) et d'un identifiant de type de carte. Ainsi, en fonction de ces numéros, la saisie est sélectionnée dans le fichier de clés, dans lequel il peut déjà y avoir plusieurs clés (si la nouvelle clé a été entrée et les anciens tickets sont encore utilisés). Le nouveau ticket est enregistré à l'aide du tout premier et le contrôle de validité est effectué à l'aide de toutes les clés de la saisie. Ensuite, la clé sélectionnée est déchiffrée à l’aide de CryptKeyRef.dll (je ne peux pas imaginer pourquoi ils sont stockés chiffrés). Ensuite, la clé déchiffrée et presque toutes les données du ticket, ainsi que son numéro de série et son matériel (la méthode de génération "hash", spécifiée pour la saisie dans keys.d), sont transférés à la fonction ckCalcHashCode située dans le même fichier CryptKeyRef.dll. A la sortie, nous obtenons la valeur sur laquelle jadis j'étais «bloqué» - le même «hash». Bien sûr, j’ai écrit un petit programme qui, en utilisant ces fonctions de CryptKeyRef.dll et le fichier keys.d, pourrait vérifier et, dans ce cas, recalculer le "hachage" à l’intérieur de tout cliché. J'ai tout revérifié sur quelques dépotoirs et, après avoir obtenu un résultat positif, suis parti, satisfait, pour dormir.

Clés pourries

Malgré le succès théorique, je voulais tout contrôler, pour ainsi dire, «au combat». Le lendemain, en rentrant du travail, j'ai spécifiquement acheté un Ultralight neuf pour un voyage afin de voir si mes clés fonctionnaient ou non (apparemment, elles étaient vieilles). Vous pouvez, bien sûr, immédiatement essayer d’enregistrer l’Ultralight «fabriqué» et aller vérifier, mais à ce moment-là, j’ai manqué de cartes vides et c’est un peu effrayant d’aller «au hasard» - du coup quoi? À mon retour à la maison, la première chose que j'ai faite, sans même me laver les mains, s'est empressée de vérifier le nouveau billet avec mes clés. Et puis une grosse déception m'attendait - le «hash» enregistré sur le ticket ne passait par aucune des clés. Par conséquent, les clés sont vraiment déjà pourries et remplacées par de nouvelles. Ceci a complètement biffé tout mon travail. J'étais un peu triste. J'ai fait du thé vert, joué d'un petit piano (oui) et me suis assis pour élever ma planche inachevée ...

Tout n'est pas encore perdu

L'idée m'est venue à l'improviste, quand encore une fois pour une raison quelconque, j'ai regardé à l'intérieur du fichier avec les clés. J'ai remarqué que dans la saisie «courante» (utilisée pour calculer les ultralégers à 1, 2, 5 trajets et autres), il y avait deux clés: une nouvelle (à ce moment-là, bien sûr) et, apparemment, une ancienne. Mais il y avait aussi la saisie, dans laquelle reposait une seule clé. Auparavant, je ne faisais pas attention à lui, mais me concentrais sur le "running". Pour calculer quels tickets cette clé est utilisée, je ne le savais pas. Quand j'ai regardé quel type de ticket était attaché aux soins, une petite étincelle d'espoir a jailli de moi. Le fait est que ce type de billet était VESB. Oui, ce type de billet rare est un billet temporaire pour tous les types de transport. Je pensais que si le billet était simple, alors cette clé devrait être utilisée non seulement dans le métro, mais aussi dans les transports terrestres, où il est très difficile et long de le remplacer par un nouveau.

De plus, il n’existe qu’une clé dans la saisie, ce qui a indirectement confirmé mon hypothèse. Pour tout le reste, je me suis rappelé que lorsque j'ai nettoyé le programme de métro de diverses "ordures", il y avait quelque chose de similaire à une archive d'anciens fichiers de clés. En creusant et en ouvrant les archives originales, j'ai vu que c'était bien le cas. Et plus important encore, en regardant tous les anciens fichiers de clés, j'ai trouvé que cette clé particulière restait inchangée! Déjà, sans la moindre hésitation, je rivetais avec mon propre VESB (heureusement, j'avais des décharges de ce type qui facilitaient grandement la tâche - je venais de changer les dates et le nombre dans les décharges) et calculais le «hachage» à l'aide de cette clé. Le moment est donc venu de procéder à une vérification (surtout depuis que je viens d'acheter du plastique plus propre). En entrant dans le hall d'entrée, j'ai d'abord attaché mon «ticket» au terminal de paiement. La date d'expiration du ticket, que j'ai indiquée, était affichée sur le tableau et le voyant vert s'allumait. Donc ça marche. Faisant une simple grimace et cachant le plastique blanc de neige dans ma manche, je me dirigeai vers le tourniquet, posai la main au validateur et ... marchai calmement sur le vert amusement éclairé. Cela a marqué la victoire finale.

Et puis quoi?

Et ensuite, des expériences ont commencé, au cours desquelles de nombreuses choses intéressantes ont été découvertes. Par exemple, sur un tel VESB "gauche", vous ne pouvez marcher que deux ou trois jours. Le fait est que le numéro que j’indique «du bulldozer» à l’intérieur du ticket est stocké dans la mémoire de la tête du tourniquet à chaque passage et qu’il est envoyé au bout d’un certain temps au centre de données avec le reste. Là, le système ne trouve pas de ticket réellement émis avec un tel numéro et le saisit dans une liste d’arrêt, qui est ensuite envoyée à tous les tourniquets de métro. Et cela devrait se produire avec tous les types de billets, pas seulement avec VESB - en plus du «hash» et des changements fréquents de clés, il s'agit d'une très bonne protection. Pour des raisons évidentes, il n'est pas possible de se déplacer.

Il a également été remarqué que l'activation ou non des bits de verrouillage ne joue aucun rôle dans le fait que le ticket fonctionne ou non. L'exception concerne uniquement le bit de blocage de la zone OTP, que le tourniquet vérifie apparemment toujours, même s'il ne va pas écrire sur OTP. À l'avenir, j'ai pris les terminaux de métro et de bus, je les ai mis en ordre, étudiés et lancés sur le stand. Maintenant, afin de vérifier une autre conjecture, il n'était plus nécessaire de s'enfuir avec un ticket de mutant fraîchement sorti du four dans le métro, mais il devenait possible de le vérifier «sans quitter la billetterie». De plus, le terminal de métro s’est avéré être aussi vieux (tout le reste et bogué), comme mes clés. Donc, je pourrais essayer «au travail» et tout autre type de billets Ultralight - quelque chose que je ne pourrais jamais faire «vivre» dans le métro. Parallèlement à ces expériences, j'ai continué à m'engager dans des logiciels.

Comme il y avait beaucoup de débats sur le type d'algorithme utilisé pour calculer le "hachage", j'ai décidé de le restaurer complètement en le réécrivant à partir de zéro dans le langage de programmation "humain". J'espérais juste comprendre de quel type d'algorithme il s'agissait. quelque chose de connu ou une sorte de leur propre développement interne. En cours de route, de nombreuses idées différentes m'ont visité (y compris le fait qu'il s'agisse d'AES), mais lorsque j'ai étudié en détail le code qui fonctionnait déjà sans utiliser les bibliothèques Smartek, il s'est avéré que cet algorithme n'était «que» GOST - la norme de cryptage domestique (toutes les informations nécessaires). sur lui, vous pouvez facilement le trouver sur le Web). Plus précisément, un cycle de 16 heures a été utilisé pour calculer le "hash". "Hash", en fait, n'est rien de plus qu'une imitation GOST.

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

Vous pouvez lire quelle est la page, où et comment se trouvent le numéro de série du matériel, les bits de verrouillage et la zone OTP dans la documentation d'origine (le fichier de spécification au format PDF avec une description complète de la puce se trouve sur le disque). Je recommande de commencer l'étude avec elle. Je décrirai la structure de la structure de données formée par les systèmes de métro dans la zone utilisateur, accessible en lecture et en réécriture (en l’absence de verrouillage, bien sûr). L'intégralité du contenu du ticket peut être conditionnellement divisée en une partie d'en-tête et deux parties de données se dupliquant complètement l'une l'autre (ceci a été fait dans le but de réserver et d'éviter les erreurs). La partie du titre dans Ultralight Tickets commence à la page 4. Une partie de celle-ci est identique à celle de tous les tickets et identifiants du système métropolitain et de MosGorTrans. Les 10 premiers bits sont l'identifiant de l'application; les 10 bits suivants sont un identifiant du type de carte (vous pouvez savoir quels identifiants se trouvent dans une autre boîte spécialement sélectionnée à cet effet). Après les identifiants est le numéro de série du ticket (il est marqué à l'arrière du ticket, ne le confondez pas avec le matériel - ce sont des choses différentes!) D'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 (un peu comme un format de fichier).

Pour les tickets Ultralight, la valeur de Layout est 0x08. Ceci termine la même partie de l'en-tête. Ensuite, le ticket Ultralight indique la date à laquelle le formulaire est valide (16 bits). Toutes les dates du système sont indiquées dans le format du nombre de jours écoulés depuis le 01/01/1992. Ici se termine la partie titre du ticket Ultralight (dans les tickets avec un autre Layout, diverses informations supplémentaires peuvent encore être enregistrées). La première zone de données commence à la page 8. Premièrement, 16 bits de la date d'émission du ticket sont enregistrés. Ensuite, la validité du ticket en jours (à partir de la date d’émission) est indiquée - 8 bits. Les 16 premiers bits de la page 9 constituent un compteur de déclenchement. Il peut être réduit à zéro (pour tous les billets avec un nombre limité de voyages) ou augmenter de zéro (dans les billets VESB, sans limiter le nombre de voyages). Après le compteur dans le reste de la page, le tourniquet entre son identifiant unique à chaque passage. Apparemment, ceci est utilisé pour empêcher la rentrée sans attendre un ticket VESB (les tourniquets dans le hall sont en réseau et s’interrogent), ainsi que pour voir à travers quel tourniquet le passage a été effectué (par exemple, en cas d’erreur ou pour des statistiques ) La page 10 est complètement occupée par un hachage 32 bits.

La page 11 est vide. Cette zone de données est entièrement répliquée sur les 4 pages restantes (12 à 15). Il se trouve que lors du fonctionnement normal, ces deux zones contiennent toujours les mêmes données. Séparément, il convient de mentionner l'utilisation de la zone OTP par le système. Il est utilisé pour “épuiser” progressivement un ticket à chaque voyage (cela ne s'applique pas aux tickets VESB). Les deux bits les moins significatifs sont définis lors de l’annulation ou de l’annulation d’un ticket (par liste d’arrêt). Un billet annulé n'est pas remboursable. Il ne reste que 30 bits à graver. Le système représente 100% des déplacements. A chaque nouveau voyage, un certain nombre de bits (du plus bas au plus élevé) est défini, correspondant au nombre de pour cent d'un voyage. Par exemple, pour un billet de 5 voyages avec chaque nouveau voyage, 6 bits seront «épuisés» et pour un billet de 60 voyages, ce sera «demi-bit» (arrondi). Il est à noter que la réutilisation des billets Ultralight est impossible non seulement en raison de la «destruction totale» d'OTP, mais aussi parce qu'au bureau de la billetterie, lors de l'émission d'un billet (et éventuellement même lors de sa fabrication), la quasi-totalité des pages est bloquée pour la réécriture. . Ainsi, ni "recharger" ni changer le type de ticket en un autre échouera.

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

Tous les nombres sont en notation décimale!

Identifiants d'application:

  • 262 - Ticket de métro de Moscou.
  • 264 - Billet de transport terrestre à Moscou.
  • 266 - Social unifié de Moscou et de sa région.
  • 270 - Ticket "Métro facile".

Identificateurs de type de ticket ultra-léger:

  • 120 - Un voyage.
  • 121 - Deux manèges.
  • 126 - Cinq manèges.
  • 127 - Dix manèges.
  • 128 - Vingt voyages.
  • 129 - Soixante voyages.
  • 130 - Bagages + pass.
  • 131 - Seuls les bagages.
  • 149 - Single Ultralight (70 voyages).
  • 150 - WESB.

Mifare classique

Je n'ai pas ignoré le malheur Mifare Classic 1K dans mes recherches. Comme vous le savez, le principal obstacle aux "classiques" était les clés matérielles A et B. Heureusement, ces clés se trouvaient dans l'un des modules du programme en clair (avant les développeurs!). Et il n'a pas été difficile pour moi d'écrire un petit programme 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 utilise le premier secteur de la carte pour stocker un ticket et le transport terrestre utilise le quatrième; il n'y a pas de protection autre que les clés matérielles (qui, étant enregistrées dans un logiciel sous cette forme, n'ont probablement jamais changé depuis la mise en service du système) sur ces tickets.

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

Mais à partir du clonage, le système de liste d'arrêt enregistre parfaitement - un tel ticket ne peut être utilisé pendant plus de deux jours, puis il est annulé (bien que, contrairement à Ultralight, la carte Classic puisse être restaurée après l'annulation, mais à partir de la liste de contrôle ça ne sauvera pas). Étant donné qu'aucune protection n'était utilisée sur les cartes classiques, celles-ci sont rapidement devenues inintéressantes pour moi et j'ai décidé de me concentrer sur la recherche Ultralight.

La fin, ou pour résumer

Les systèmes de métro, et en particulier les nouveaux tickets Ultralight, contrairement aux opinions et aux spéculations, étaient bien protégés. Il est très plaisant que les développeurs utilisent un GOST fiable et éprouvé, sans pour autant réinventer la roue. Avec une telle protection, il est tout simplement impossible de forger un ticket Ultralight sans accès à des données confidentielles (informations clés). Le système de clé interchangeable et le mécanisme de liste d’arrêts sont également bien conçus. Bien sûr, il y avait des lacunes et des erreurs. Le plus important d'entre eux est un logiciel qui n'est en aucun cas protégé.

Il suffisait d'abandonner l'utilisation de runtime-bpl, ce qui rendrait l'analyse dix fois plus difficile! En option, le traitement de parties particulièrement importantes du programme par AsProtect ou ExeCryptor, suivi de la compression de tous les fichiers avec MoleBox, réduirait presque à zéro l'analyse. La boîte à outils est peu coûteuse. Et l’utilisation d’une telle protection (de préférence peu connue ou sur mesure), mais avec des clés matérielles, rendrait l’analyse du programme totalement impossible. Bien sûr, le métropolitain est une entreprise sensible, mais n'oubliez pas le facteur humain. Après tout, Kevin Mitnik a déclaré (et non seulement parlé, mais également démontré par son propre exemple, pour lequel il s’était assis) qu’il était parfois plus facile et plus efficace d’utiliser «l’ingénierie sociale» pour atteindre l’objectif que d’essayer de briser une défense impénétrable. Eh bien, sur cette note, je vais terminer mon histoire. Et vous, lecteur, je vous 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 unifié de conversion cryptographique pour les systèmes de traitement de l'information dans les réseaux informatiques électroniques (ordinateurs), les complexes informatiques individuels et les ordinateurs, qui définit les règles de cryptage des données et de développement d'un insert.

L'algorithme de conversion cryptographique est destiné à la mise en œuvre matérielle ou logicielle, répond aux exigences de la cryptographie et, par ses capacités, n'impose aucune restriction quant au degré de confidentialité des informations protégées.

La norme est obligatoire pour les organisations, entreprises et institutions appliquant une protection cryptographique des données stockées et transmises sur des réseaux informatiques, dans des complexes informatiques distincts ou dans des ordinateurs.

Schéma fonctionnel de l'algorithme de conversion cryptographique

Le schéma fonctionnel de l'algorithme de transformation cryptographique (schéma de chiffrement) présenté à la figure 1 contient:

  • - Mémoire à clé (RAM) de 256 bits, composée de huit unités de disque 32 bits (X 0 , X 1 , X 2 , X 3 , X 4 , X 5 , X 6 , X 7 );
  • - quatre lecteurs 32 bits (N 1 , N 2 , N 3 , N 4 );
  • - deux lecteurs 32 bits (N 5 , N 6 ) avec la constante de remplissage C 2 , C 1 enregistrée dans ceux-ci;
  • - deux additionneurs 32 bits modulo 2 32 (SM 1 , SM 3 );
  • - additionneur 32 bits de sommation binaire modulo 2 (SM 2 );
  • - additionneur 32 bits modulo (2 32 -1) (CM 4 );
  • - additionneur modulo 2 (CM 5 ), la limitation de la capacité de l'additionneur CM 5 n'est pas imposée;
  • - bloc de substitution (K);
  • - enregistrement du décalage cyclique de onze pas en direction de la sortie principale (R).

Figure 1

Le bloc de substitution K est constitué de huit noeuds de remplacement K 1 , K 2 , K 3 , K 4 , K 5 , K 6 , K 7 , K 8 avec une mémoire de 64 bits chacun. Le vecteur de 32 bits qui arrive au bloc de substitution est divisé en huit vecteurs consécutifs de 4 bits, chacun d'eux é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, cette ligne est remplie par le vecteur sortant. Ensuite, les vecteurs de sortie à 4 bits sont combinés séquentiellement en un vecteur à 32 bits.

Lors de l'ajout et du décalage cyclique des vecteurs binaires, les bits les plus significatifs sont les bits des lecteurs avec de grands nombres.

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

Lors du remplacement des informations, le contenu de la cinquième décharge d'un lecteur (additionneur) est écrasé dans la troisième décharge d'un autre lecteur (additionneur).

Le tableau 1 indique la valeur du remplissage constant avec 1 entraînement (constant) N 6 .

Tableau 1

La catégorie de lecteur N 6

32

31

30

29ème

28

27

26

25

24

23

22

21

20

19

18

17

Valeur de décharge

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

La catégorie de lecteur N 6

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Valeur de décharge

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

La valeur du remplissage constant avec 2 (constant) entraînement N 5 est indiquée dans le tableau 2.

Tableau 2

Décharge du lecteur N 5

32

31

30

29ème

28

27

26

25

24

23

22

21

20

19

18

17

Valeur de décharge

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Décharge du lecteur N 5

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

Valeur de décharge

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Les clés qui déterminent le remplissage de la RAM et les tables du bloc de substitution K sont des éléments secrets et sont livrées de la manière prescrite.

Remplir les tables du bloc de substitution K est un élément clé à long terme commun à un réseau informatique.

L'organisation de divers types de communication est réalisée en construisant un système de clé approprié. Dans ce cas, la possibilité de générer des clés (remplissage de la RAM) en mode de remplacement simple et de les chiffrer en mode de remplacement simple en fournissant une protection contre les imitations pour la transmission sur des canaux de communication ou le stockage dans la mémoire de l'ordinateur peut être utilisée.

Le schéma de chiffrement fournit quatre types de travail:

  • - cryptage (décryptage) des données en mode de remplacement simple;
  • - cryptage (décryptage) des données en mode gamma;
  • - chiffrement (déchiffrement) des données en mode gamma avec retour;
  • - mode de développement d'un insert d'imitation.

Cryptage de remplacement facile

Cryptage des données ouvertes en mode de remplacement simple

Le schéma cryptographique qui implémente l'algorithme de cryptage dans le mode de remplacement simple doit avoir la forme indiquée à la figure 2.


Figure 2

Les données ouvertes à chiffrer sont divisées en blocs de 64 bits chacun. Saisie d’un bloc quelconque T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) informations binaires dans les lecteurs N 1 et N 2 sont faits de sorte que la valeur a 1 (0) soit entrée dans le premier chiffre N 1 , la valeur a 2 (0) dans le deuxième chiffre N 1 , etc., la valeur a 32 ( 0) est introduit au 32ème chiffre N 1 ; la valeur de b 1 (0) est entrée dans le 1er chiffre de N 2 , la valeur de b 2 (0) est entrée dans le deuxième chiffre de N 2 , etc., la valeur de b 32 (0) est entrée dans le 32e chiffre de N 2 . Le résultat est l’état (a 32 (0), a 31 (0), ..., a 2 (0), a 1 (0)) du lecteur N 1 et de l’état (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) du lecteur N 2 .

256 bits de la clé sont entrés dans la RAM. Le contenu de 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 chiffrement d'un bloc de données ouvert de 64 bits en mode de remplacement simple comprend 32 cycles.

Au premier cycle, le remplissage initial du lecteur N 1 est ajouté modulo 2 32 dans l'additionneur CM 1 avec le remplissage du lecteur X 0 , tandis que le remplissage du lecteur N 1 est enregistré.

Le résultat de la somme est converti dans le bloc de substitution K et le vecteur résultant est envoyé à l'entrée du registre R, où il se déplace de manière cyclique de onze pas vers les chiffres les plus élevés. Le résultat de décalage est additionné bit par bit modulo 2 dans l'additionneur CM 2 avec la commande de remplissage 32 bits N 2 . Le résultat obtenu dans CM 2 est enregistré dans N 1 , tandis que l'ancienne valeur de N 1 est réécrite dans N 2 . Le premier cycle se termine.

Les cycles suivants sont effectués de la même manière, alors que dans le deuxième cycle, le remplissage X 1 est lu dans la RAM, dans le troisième cycle, le remplissage X 2 est lu dans la ROM, etc., dans le huitième cycle, le remplissage X 7 est lu dans la RAM. Les cycles du 9 au 16, ainsi que les cycles du 17 au 24, sont lus dans la même mémoire 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ème au 32ème ordre de lecture des remplissages de la RAM, l’ordre inverse est le suivant: X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Ainsi, lors du chiffrement sur 32 cycles, la procédure suivante pour sélectionner les remplissages de lecteur est effectuée:

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

Au 32e cycle, le résultat de l'additionneur CM 2 est entré dans l'accumulateur N 2 et l'ancien remplissage est stocké dans l'accumulateur N 1 .

Les remplissages des lecteurs N 1 et N 2 obtenus après le 32ème cycle de cryptage constituent un bloc de données crypté correspondant à un bloc de données ouvert.

Décryptage des données cryptées en mode de remplacement simple

Le schéma cryptographique qui implémente l'algorithme de déchiffrement dans le mode de remplacement simple a la même forme (voir la figure 2) que le chiffrement. 256 bits de la même clé, sur laquelle le cryptage a été effectué, sont entrés dans la RAM. Les données chiffrées à déchiffrer sont divisées en blocs de 64 bits chacun. Entrée d'un bloc T w = (a 1 (32), a 2 (32), ..., a 32 (32), b 1 (32), b 2 (32), ..., b 32 (32)) dans les lecteurs N 1 et N 2 sont faits de sorte que la valeur de 1 (32) soit entrée dans le 1er chiffre N 1 , la valeur de 2 (32) soit entrée dans le 2e chiffre N 1 , etc., la valeur de 32 (32). introduit au 32ème chiffre N 1 ; la valeur de b 1 (32) est entrée dans la 1ère décharge N 2 , la valeur de b 2 (32) est entrée dans la 2ème décharge N 2 , etc., la valeur de b 32 (32) est entrée dans la 32ème décharge N 2 .

Le déchiffrement est effectué selon le même algorithme que le chiffrement des données ouvertes, mais le remplissage des lecteurs X 0 , X 1 , ..., X 7 est lu dans la RAM par cycles de déchiffrement, 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 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 , X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Obtenus après 32 cycles de fonctionnement, les commandes de remplissage N 1 et N 2 comprennent un bloc de données ouvertes.

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 de la 1ère décharge N 1 , la valeur d'un 2 (0) correspond au contenu de la 2e décharge N 1 , etc., la valeur d'un 32 (0) correspond au contenu de 32- décharge N 1 ; la valeur de b 1 (0) correspond au contenu de la 1ère décharge N 2 , la valeur de b 2 (0) correspond au contenu de la 2ème décharge N 2 , etc., la valeur de b 32 (0) correspond au contenu de la 32ème décharge N 2. .

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

Mode gamma

Cryptage gamma des données ouvertes

Le schéma cryptographique qui implémente l'algorithme de chiffrement en mode gamma doit avoir la forme indiqué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 le gamma du chiffre G w , qui est produit en blocs de 64 bits, c.-à-d.

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

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

G w(i) - ième bloc 64 bits, i = 1 Ì, le nombre de bits binaires dans le bloc T 0(M) peut être inférieur à 64, alors qu'une partie du gamma de chiffrement du bloc G w(M) n'est pas utilisée pour le cryptage jeté.

256 bits de la clé sont entrés dans la RAM. Une séquence binaire de 64 bits (paquet de synchronisation) S = (S 1 , S 2 , ..., S 64 ) est introduite dans les lecteurs N 1 , N 2 , qui est le remplissage initial de ces lecteurs pour la génération suivante de M blocs de chiffrement de chiffrement. Le paquet d’horloges est entré dans N 1 et N 2 de sorte que la valeur de S 1 soit entrée dans le premier chiffre de N 1 , la valeur de S 2 dans le deuxième chiffre de N 1 , etc., la valeur de S 32 dans le 32e chiffre N 1 ; la valeur de S 33 est entrée dans la 1ère décharge N2, la valeur de S34 est entrée dans la 2ème décharge N2, etc., la valeur de S 64 est entrée dans la 32e décharge N2.

Le remplissage initial des lecteurs N 1 et N 2 (paquet de synchronisation S) est crypté selon un mode de remplacement simple, conformément aux exigences du paragraphe 1.3.1. Le résultat du chiffrement est copié sur les lecteurs N 3 et N 4 à 32 bits, de sorte que le pad N 1 soit copié sur N 3 et que le pad N 2 soit copié sur N 4 .

Le remplissage du lecteur N 4 est additionné modulo (2 32 -1) dans l'additionneur CM 4 avec une constante C 1 à 32 bits provenant du lecteur N 6 , le résultat est écrit dans N 4 .

Le remplissage du lecteur N 3 est additionné modulo 2 32 dans l'additionneur CM 3 avec une constante C 2 à 32 bits provenant du lecteur N 5 , le résultat est écrit dans N 3 .

Le remplissage de N 3 est copié sur N 1 et le remplissage de N 4 est copié sur N 2 , tandis que le remplissage de N 3 , N 4 est enregistré.

Le remplissage des N 1 et N 2 est crypté selon un mode de remplacement simple, conformément aux exigences du paragraphe 3.1. Le remplissage N 1 , N 2 obtenu à la suite du cryptage constitue le premier bloc de 64 bits du gamma de chiffrement G w(1) , qui est additionné modulo au niveau du bit 2 dans l'additionneur CM 5 avec le premier bloc de données ouvert à 64 bits T 0(1) = 1(1) , t 2(1) , ..., t 63(1) , t 64(1 ). À la suite de la somme, un bloc de données cryptées de 64 bits est obtenu T w(1) = (τ 1(1) , τ 2(1) , ..., τ 63(1) , τ 64(1) ).

La valeur de τ 1(1) du bloc T W(1) est le résultat de la somme modulo 2 dans CM 5 de la valeur de t 1(1) du bloc T 0(1) avec la valeur du 1er chiffre N 1 , la valeur de τ 2(1) du bloc T w(1) est le résultat de la somme modulo 2 dans CM 5 de la valeur de t 2(1) du bloc T 0(1) avec la valeur du deuxième chiffre N 1 , etc., la valeur de τ 64(1) du bloc T w(1) est le résultat de la somme modulo 2 dans CM 5 de la valeur de t 64(1) du bloc T 0(1) avec la valeur du 32ème chiffre N 2 .

Pour obtenir le prochain bloc de 64 bits de la gamme du chiffre G W(2),on additionne le remplissage N 4 modulo (2 32 -1) dans l'additionneur СМ 4 avec la constante С 1 de N 6 , le remplissage N 3 est additionné du modulo 2 32 dans l'additionneur СМ 3 avec constante C 2 de N 5 . Le nouveau remplissage N 3 est copié sur N 1 et le nouveau remplissage N 4 est copié sur N 2 , tandis que le remplissage de N 3 et N 4 est enregistré.

Le remplissage des N 1 et N 2 est crypté selon un mode de remplacement simple, conformément aux exigences du paragraphe 3.1. Le remplissage N 1 , N 2 obtenu grâce au cryptage forme un deuxième bloc de 64 bits de la gamme du chiffre G w(2) , qui est additionné modulo 2 au bit dans l'additionneur CM 5 avec le deuxième bloc de données ouvert T 0(2) . Les blocs gamma chiffrés G w(3) , G w(4) ..., G w(M) sont générés de manière similaire et les blocs de données ouverts T 0(3) , T 0(4) ..., T 0(M) sont cryptés. Si la longueur du dernier Mème bloc de données ouvertes T 0(M) est inférieure à 64 bits, alors à partir du dernier Mème bloc du gamma de chiffrement G w(M), seul le nombre correspondant de bits du gamma de chiffrement est utilisé pour le chiffrement, les bits restants sont ignorés.

Le paquet synchrone S et les blocs de données cryptées Tsh(1) , Tsh(2) ..., Tsh(M) sont transmis au canal de communication ou à la mémoire de l'ordinateur.

Décryptage des données cryptées en mode gamma

Lors du décryptage, le schéma de cryptage a la même forme que lors du cryptage (voir Figure 3). 256 bits de la clé sont entrés dans la RAM, à l'aide desquels les données ont été cryptées T 0(1) , T 0(2) ..., T 0(M), tandis que T 0(M) peut contenir moins de 64 bits.

Feedback Gamma Mode

Cryptage des données ouvertes en mode gamma avec feedback

Le schéma cryptographique qui implémente le mode de jeu avec retour doit avoir la forme suivante: donné à la figure 4.


Figure 4

Les données ouvertes, divisées en blocs de 64 bits T 0(1) , ..., T 0(M) , sont cryptées en mode gamma avec rétroaction par sommation binaire modulo 2 dans l'additionneur CM 5 avec un gamma de chiffrement G w , généré par des blocs de 64 bits, c'est-à-dire G sh = (G sh(1) , G sh(2) , ..., G sh(M) ), où M est déterminé par la quantité de données à chiffrer, G sh(i) est le ième bloc de 64 bits, i = 1 Ì. Le nombre de bits dans le bloc T 0(M) peut être inférieur à 64.

256 bits de la clé sont entrés dans la RAM. Une séquence binaire de 64 bits (paquet de synchronisation) S = (S 1 , S 2 , ..., S 64 ) est introduite dans les lecteurs N 1 , N 2 . Le paquet d’horloges est entré dans N 1 et N 2 de sorte que la valeur de S 1 soit entrée dans le premier chiffre de N 1 , la valeur de S 2 dans le deuxième chiffre de N 1 , etc., la valeur de S 32 dans le 32e chiffre N 1 ; la valeur de S 33 est entrée dans la 1ère décharge N2, la valeur de S34 est entrée dans la 2ème décharge N2, etc., la valeur de S 64 est entrée dans la 32e décharge N2.

Le remplissage initial des lecteurs N 1 et N 2 est crypté selon un mode de remplacement simple conformément aux exigences du paragraphe 3.1. Les valeurs de remplissage N 1 et N 2 obtenues grâce au cryptage constituent le premier bloc de 64 bits du gamma de chiffrement G w(1) , qui est additionné modulo au niveau du bit 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 ).

À la suite de la somme, un bloc de données cryptées de 64 bits est obtenu T w(1) = (τ 1(1) , τ 2(1) , ..., τ 63(1) , τ 64(1) ).

Le bloc de données crypté T w(1) est en même temps également l'état initial N 1 , N 2 pour générer le deuxième bloc de la gamme de chiffrement G w(2) et est écrit sur les lecteurs indiqués par rétroaction. Dans ce cas, la valeur de τ 1(1) est entrée dans la 1ère décharge N 1 , la valeur de τ 2(1) est introduite dans la 2ème décharge N 1 , etc., la valeur de τ 32(1) est introduite dans la 32ème décharge N 1 ; la valeur de τ 33(1) est entrée dans la 1ère décharge N 2 , la valeur de τ 34(1) est entrée dans la 2ème décharge N 2 , etc., la valeur de τ 64(1) est entrée dans la 32ème décharge N 2 .

Le remplissage de N 1 , N 2 est crypté selon un mode de remplacement simple, conformément aux exigences du paragraphe 3.1. Le remplissage N 1 , N 2 obtenu grâce au cryptage forme un deuxième bloc de 64 bits de la gamme du chiffre G w(2) , qui est additionné modulo 2 au bit dans l'additionneur CM 5 avec le deuxième bloc de données ouvert T 0(2) .

Le développement de blocs ultérieurs de la gamme du chiffre G w(i) et le chiffrement des blocs de données ouvertes T 0(i) correspondants (i = 3 ÷) sont effectués de manière similaire. 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 bits du gamma de chiffrement de G w(M) est utilisé, les bits restants sont ignorés.

Le paquet synchrone S et les blocs de données cryptées Tsh(1) , Tsh(2) ..., Tsh(M) sont transmis au canal de communication ou à la mémoire de l'ordinateur.

Décryptage des données cryptées en mode gamma avec retour

Lors du décryptage, le schéma de cryptage a la même forme que lors du cryptage (voir Figure 4). 256 bits de la même clé sont entrés dans la RAM sur laquelle T 0(1) , T 0(2) ..., T 0(M) a été crypté. Le paquet d’horloges est entré dans N 1 , N 2 de sorte que la valeur de S 1 soit entrée dans le premier chiffre de N 1 , la valeur de S 2 dans le deuxième chiffre de N 1 , etc., la valeur de S 32 dans le 32e chiffre N 1 ; la valeur de S 33 est entrée dans la 1ère décharge N2, la valeur de S34 est entrée dans la 2ème décharge N2, etc., la valeur de S 64 est entrée dans la 32e décharge N2.

Le remplissage initial des lecteurs N 1 et N 2 (paquet de synchronisation S) est crypté selon un mode de remplacement simple, conformément aux exigences du paragraphe 3.1. Le remplissage N 1 , N 2 obtenu à la suite du chiffrement constitue le premier bloc de 64 bits du gamma du chiffrement G w(1) , qui est additionné modulo 2 par bit dans l'additionneur CM 5 avec le bloc de données chiffrées T w(1) . Le résultat est le premier bloc de données ouvertes T 0(1) .

Le bloc de données crypté T w(1) est le remplissage initial N 1 , N 2 pour générer le deuxième bloc de la gamme de chiffrement G w(2) . Le bloc T W(1) est écrit en N 1 , N 2 . Dans ce cas, la valeur de τ 1(1) est entrée dans la 1ère décharge N 1 , la valeur de τ 2(1) est introduite dans la 2ème décharge N 1 , etc., la valeur de τ 32(1) est introduite dans la 32ème décharge N 1 ; la valeur de τ 33(1) est entrée dans la 1ère décharge N 2 , la valeur de τ 34(1) est entrée dans la 2ème décharge N 2 , etc., la valeur de τ 64(1) est entrée dans la 32ème décharge N 2 . Le remplissage résultant N 1 , N 2 est crypté dans un mode de remplacement simple conformément aux exigences de l'article 3.1, le bloc résultant G w(2) est additionné modulo au niveau du bit 2 dans l'additionneur CM 5 avec le deuxième bloc de données cryptées T w(2) . Le résultat est un bloc de données ouvertes T 0(2) .

De même, dans N 1 , N 2 , les blocs de données cryptées sont écrits séquentiellement T W(2) , T W(3) ..., T W(M-1) , à partir desquels des blocs gamma de chiffrement G W(3) , G w(4) , ..., G w(M) . Les blocs gamma chiffrés sont additionnés bit par bit modulo 2 dans l'additionneur CM 5 avec les blocs de données chiffrés Tw(3) , TW(4) ..., TW(M) , en conséquence, les blocs de données ouverts T0 (3) , T0 ( 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 d'insertion d'imitation

Pour assurer la protection contre les imitations de données ouvertes, consistant en M blocs de 64 bits T 0(1) , T 0(2) , ..., T 0(M) , M≥2, un bloc supplémentaire de l bits est généré (insérer And l ). Le processus de génération d'un insert 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) , ..., a 32(1) (0), b 1(1) (0), b 2(1) (0), ..., b 32(1) (0)) est écrit sur les lecteurs N 1 et N 2 , la valeur de t 1(1) = a 1(1) (0) est introduite dans le 1er chiffre N 1 , la valeur de t 2(1) = a 2(1) (0) est introduite dans le deuxième chiffre N 1 , etc., la valeur t 32(1) = a 32(1) (0) est introduite dans le 32ème chiffre N 1 ; la valeur de t 33(1) = b 1(1) (0) est entrée dans le 1er chiffre de N 2 , etc., la valeur de t 34(1) = b 32(1) (0) est introduite dans le 32e chiffre N 2 .

Le remplissage des N 1 et N 2 subit une conversion correspondant aux 16 premiers cycles de l’algorithme de chiffrement en mode de remplacement simple, conformément aux prescriptions du paragraphe 3.1. En même temps, on trouve la même clé dans la KZU avec laquelle les blocs de données ouverts T 0(1) , T 0(2) , ..., T 0(M) sont cryptés dans les blocs correspondants de données cryptées T w(1) , Tw(2) , ..., T W(M) .

Le remplissage N 1 et N 2 obtenu après 16 cycles de fonctionnement, ayant la forme (a 1(1) (16), a 2(1) (16), ..., a 32(1) (16), b 1(1) ( 16), b 2(1) (16), ..., b 32(1) (16)), est additionnée 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 la sommation est entré dans N 1 et N 2 et subit une conversion correspondant aux 16 premiers cycles de l'algorithme de cryptage en mode de remplacement simple.

Le remplissage résultant N 1 et N 2 est résumé 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é avec des zéros dans le bloc complet de 64 bits, est ajouté au CM 5 modulo 2 avec le remplissage en N 1 , un 1(M-1) (16), un 2(M-1) ( 16), ..., a 32(M-1) (16), b 1(M-1) (16), b 2(M-1) (16), ..., b 32(M-1) (16) . Le résultat de la sommation est enregistré dans N 1 , N 2 et est crypté selon un mode de remplacement simple, conformément aux 16 premiers cycles de l'algorithme. À partir du remplissage résultant des disques N 1 et N 2, nous sélectionnons le segment Et l = [a 32 - l +1(M) (16), un 32 - l +1(M) (16), ..., un 32(M) (16 )].

L'insert And l est transmis sur le canal de communication ou dans la mémoire de l'ordinateur à la fin des données cryptées, c'est-à-dire T W(1) , T W(2) , ..., T W(M) , et l .

Les données chiffrées reçues Tsh(1) , Tsh(2) , ..., Tsh(M) sont déchiffrées à partir des blocs de données ouvertes reçues T 0(1) , T 0(2) , ..., T 0(M) , un insert est généré. And 'l , qui est ensuite comparé à un insert simulé And l , reçu avec des données cryptées provenant d'un canal de communication ou d'une mémoire d'ordinateur. En cas de non concordance des insertions, les blocs de données ouvertes reçus T 0(1) , T 0(2) , ..., T 0(M) sont considérés comme faux.

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