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

Rompre le métro (cartes de voyage) + ALGORITHME DE TRANSFORMATION CRYPTOGRAPHIQUE SELON GOST 28147-89

Sur la page:


Briser le métro (cartes de voyage)

Êtes-vous familier avec le désir de résoudre toutes les énigmes et de révéler toutes les défenses du métro de Moscou? Par exemple, pour vous faire un "ticket perpétuel"? Mais après tout, les experts du métro trouvent de plus en plus de méthodes de protection de plus en plus sophistiquées. Les jetons en métal ont été remplacés par des en plastique, qui étaient à leur tour des tickets magnétiques, et des cartes sans contact ont remplacé les magnétiques. De nombreux chercheurs ont baissé les bras - il semble que le métropolitain soit devenu une forteresse imprenable. Mais toute protection peut être contournée. Et souvent, il s'avère beaucoup plus facile à ouvrir qu'à construire ...

Comment tout a commencé

Je m'intéressais il y a longtemps aux systèmes de métro, par exemple à l'école, alors qu'il y avait encore des tickets avec une bande magnétique en cours d'utilisation. Au même moment (il y a une dizaine d'années), ils ont introduit une carte sociale sans contact pour les étudiants. 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 le public était peu informé, en particulier sur ces technologies. J'ai dû remettre à plus tard l'idée de recherches sur le brûleur arrière, mais je me suis promis d'y retourner définitivement ...

Il y a environ trois ans, mon intérêt pour le sujet du métro s'est réveillé. J'ai activement étudié les tickets magnétiques (il y avait beaucoup d'informations à ce sujet sur Internet) et j'ai même rassemblé une petite machine pour faire des copies de deux têtes à partir d'enregistreurs à bande et d'une petite quantité de pièces détachées. 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 imprenable - 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 pourrez appuyer sur les touches jusqu’à la fin du système solaire. Et pour les titulaires de carte qui soutiennent Classic, ils valaient de très grosses sommes d’argent à l’époque (je ne pensais pas à 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 "Ultralight" sont apparus dans notre métro récemment, mais ont immédiatement suscité un vif intérêt auprès du public. Ils ont commencé à tuer, à déchirer, à supporter un fer à repasser et à utiliser d'autres méthodes de cryptanalyse thermorectale. Certes, la soif de connaissances m'a fait déchirer un couple. À la suite de leurs études et de leurs recherches sur Internet, il a été établi qu’il ne s’agissait que de Mifare Ultralight, la version «légère» compatible de Mifare Classic. Un rapide examen de la documentation sur les puces de cette norme a montré que ces cartes ne sont pas dotées de systèmes de sécurité intégrés. En outre, 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 simplement nécessaire de se procurer un lecteur de carte sans fil compatible Ultralight. Il y avait deux options: soit se monter soi-même (ce qui prendrait beaucoup de temps), soit acheter un appareil prêt à l'emploi. À l’idée de la deuxième option, compte tenu des prix d’il ya trois ans, j’avais la chair de poule. Mais j'ai quand même décidé de regarder les prix actuels. Et pour cause! 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 tickets, et non sur la conception et le débogage de matériel informatique, car celui-ci pouvait être retardé indéfiniment. Avec le lecteur, un SDK original très pratique de production locale a été acheté auprès de la même société (ISBC). Encore une fois, il a permis de ne pas perdre de temps et d’efforts pour écrire avec le lecteur des logiciels de bas niveau et de débogage, mais de se concentrer directement sur les tickets. Ainsi, pendant quelques jours de codage tranquille, un petit programme était né, avec lequel il était possible d’observer et d’éditer toute la structure interne des Ultralights sous une forme commode. Puis j'ai commencé à étudier les billets.

Mur blanc

En train d'étudier beaucoup de billets sont passés par mon lecteur. Certains, j'ai retroussé mes manches, sorti «de la poubelle», d'autres que j'ai achetés - j'ai regardé ce qui leur était écrit, puis je suis retourné. C'étaient presque tous les types de billets, à l'exception peut-être du laissez-passer Ultralight pour 70 voyages. Après quelques semaines, je disposais d'une base de données volumineuse et bien triée sur les vidages de différents tickets et dans différents états. Il y avait aussi des décharges prises sur le même ticket après chaque voyage, et plusieurs tickets avec des numéros de métro en ligne. Il y avait même 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 de 30 jours), pris après un certain intervalle de temps, dans ma collection. Il s’est avéré qu’il s’agissait de spécimens très intéressants et en même temps très rares (je les ai obtenus directement avec retour immédiat, juste 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 billets 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éfinir clairement la structure et le format de l’enregistrement des données sur le ticket. Bien sûr, certains champs étaient visibles immédiatement, à 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 (celui qui y était imprimé). La prise de conscience est venue tout à fait par accident. Le fait est que j’ai (comme la plupart d’entre nous, je pense) jeté un coup d’œil sur l’hex, alignait les informations pour eux-mêmes sur des octets et pensait au moins. Il s'est avéré que cette approche est fausse ici. En regardant le vidage des billets, 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 de ticket: celui-ci était 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 de service. Après un certain temps, 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, 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 ce fut la fin de toute la joie - il serait stupide de supposer que de tels billets pourraient être laissés sans protection. Chaque vidage contenait 32 bits d'informations différentes qui ne correspondaient pas au reste du contenu. J'ai supposé que c'était une sorte de somme de contrôle, un «hash» 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 total (en particulier, il était supposé qu'il s'agissait d'une sorte de CRC32, avec un polynôme et une valeur de départ non standard).

En essayant de modifier au moins un bit et demi d'informations à l'intérieur du ticket, le terminal qui vérifiait dans le métro clignotait "BAD TICKET", pesant les derniers clous dans le cercueil avec une lourde prise. Bien sûr, des tentatives ont été faites pour contourner le système, par exemple pour copier un ticket sur une carte vierge vierge (ici, hélas, empêchait le numéro de série de l'usine, qui participait également à la génération du hachage) ou définissait les verrous comme pour empêcher le tourniquet de modifier le contenu du ticket. Le terminal de test a reconnu un tel ticket "éternel", mais a refusé de laisser le tourniquet ... J'ai donc heurté le mur. Dans le grand et fort mur de béton, sur lequel beaucoup ont l’habitude de tuer. Ne trouvant 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 moyen, et j'ai mis un gros point. En fin de compte, rien ...

Étrange connaissance

La soirée de septembre n'était pas différente des autres. La nuit était presque arrivée, il faisait frais et humide dehors. Je me suis assis devant l'écran du moniteur et, en buvant du thé vert chaud et légèrement sucré, j'ai échangé paisiblement des frais pour mon prochain bricolage. DipTarce, un peu un bashorga, ICQ ... Quelqu'un a appelé sur Skype - distrayant! Encore une fois ICQ, encore une fois DipTrace - en général, tout est comme d'habitude. Une fois encore, la fenêtre ICQ est tombée au premier plan - une personne inconnue de moi, a écrit «Bonjour». J'ai, sans aucun doute, répondu la même chose. Le message suivant a marqué un tournant dans toute l'histoire: «Vous êtes intéressé par le métro, j'ai des choses ici. Si cela vous intéresse, rencontrons-nous, je vous le dirai. Au début, j'étais un peu gêné et alerté (peut-être un divorce ou un arrangement, 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?

Les agences de renseignement ne s’intéresseraient guère à moi et il ne semble 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 de l'une des stations de métro de Moscou. L’étranger était 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 colis avec les mots: «Allons-y, tiens. Cela ne fonctionnait toujours pas pour moi, cela pourrait vous être utile. " En regardant à l'intérieur, j'ai vu deux terminaux de métro déplacés par des journaux, quelques cartes en plastique blanc dispersées au hasard et un blanc dans une boîte. Quand j'ai demandé combien d'argent je devais (l'argent), le gars a secoué la tête, a souri et a dit: "Pourquoi, personne ne doit rien à personne, faites-le ... Alors, je dois déjà courir, mon train est comme le temps! Allez, au revoir!

Avec ces mots, il s’enfuit, sauta par les portes déjà fermées de la voiture et partit. Et moi, je l'avoue, je suis rentré chez moi un peu en neponyatka. J'ai supprimé le contact d'ICQ au cas où, en même temps, je nettoyais la liste de contacts sur le serveur et rangeais les journaux (bonjour à nouveau, paranoïa). En fin de compte, écrivez à nouveau, si cela. Mais plus il ne m'a jamais écrit ...

Le phénomène du logiciel au peuple

A mon retour à la maison, j'ai démonté le colis. Le deuxième terminal s’est avéré être un validateur de bus (lourd, bon sang!); les cartes étaient Mifare Classic 1K (propre) et il y avait une seule archive sur le disque. Après une rapide connaissance du contenu, il s’est avéré que c’est le logiciel utilisé aux guichets du métro. Mettant de côté le terminal et le validateur, j'ai décidé de me lancer dans l'étude de logiciels intéressants. À environ une heure du désordre décompressé, j'ai réussi à créer et à exécuter ce programme sur mon ordinateur. Il a fallu encore une 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 qu'il mange. Manger, comme il s’est avéré, avec le lecteur Parsec PR-P08, par conséquent, en l’absence de cela, il n’était pas possible d’essayer le logiciel en action.

Le développeur était Smartek, un important fournisseur gouvernemental développant de tels systèmes (de plus amples informations sont disponibles sur son 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 bpl séparés avec des noms parlants (c'était le fichier de développement le plus important). Après une analyse sommaire du logiciel interne, j'ai découvert que, d'une part, les informations sur tous les tickets émis sont transférées vers une base de données centralisée (Oracle, en passant) et que le programme utilise une sorte de 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 dans le système peuvent avoir lieu avec un certain délai. Théoriquement, cela nous donne une longueur d'avance.

Mais tout d’abord, je me suis intéressé au mécanisme de la clé (j’avais déjà commencé à deviner pourquoi on en aurait peut-être besoin). 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 plus à rien). Et apprécié tout ce bon runtime-bpl'ina SmLayout.bpl. Cette bibliothèque était juste une aubaine pour mes recherches - elle contenait des cours pour travailler avec le remplissage interne de tickets. Comme il s'agit de runtime-bpl, il suffisait de regarder son tableau des exportations pour afficher à 60% ce qui se passait. Une analyse plus détaillée a tout mis à sa place. Rappelez-vous qu'au début de l'article, je disais que dans la structure de "l'Ultralight", il restait quelques 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 variable des données. Ainsi, ce champ «Disposition» dans l'en-tête vient de définir comment et quelles données se trouvent dans le reste du ticket. Il existe plusieurs dispositions de ce type (chacune correspondant à son propre type de ticket) et, dans SmLayout.bpl, chacune d’elles avait sa propre classe (plus une classe parente commune, qui comportait des méthodes de travail avec la partie en-tête). Par conséquent, il était facile de déterminer les champs de chaque mise en page dont ils sont responsables (même avec les noms des méthodes exportées!). Ayant terminé l'ensemble de la mise en page 8 (utilisée dans «Ultralight») et après avoir vérifié si j'avais la bonne idée de tous les champs de la structure de ticket, j'ai repris le mécanisme de clé. En effet, il était responsable de la génération du hachage. Le fonctionnement du mécanisme est devenu parfaitement 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és (keys.d).

Le système est conçu pour que chaque type de ticket ait son propre identifiant (il y avait une table complète avec identifiants et noms de tickets, 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, sur la base de ces numéros, un trousseau de clés est sélectionné dans le fichier de clés, dans lequel il peut déjà y avoir plusieurs clés (au cas où une nouvelle clé est entrée et que les anciens tickets sont toujours 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 du trousseau. Ensuite, la clé sélectionnée est déchiffrée à l’aide de CryptKeyRef.dll (pourquoi ils sont stockés chiffrés, je ne vais pas y attacher mon esprit). Après cela, la clé déchiffrée et presque toutes les données de ticket, ainsi que son numéro de série et son matériel (la méthode de génération de «hachage» 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. À la sortie, nous obtenons la valeur sur laquelle je me suis «collé» une fois - le même «hachage». Bien sûr, j’ai écrit un petit programme qui, à l’aide des fonctions de CryptKeyRef.dll et du fichier keys.d, pourrait vérifier et, dans ce cas, recompter le hachage contenu dans un cliché. J'ai tout revérifié sur plusieurs dépotoirs et, après avoir obtenu un résultat positif, je suis parti, satisfait, pour dormir.

Clés pourries

Malgré le succès théorique, je voulais tout vérifier, pour ainsi dire, «au combat». Le lendemain, en rentrant du travail, j'ai délibérément acheté un «Ultralight» neuf pour un voyage afin de vérifier si mes clés étaient valides ou non (apparemment, elles étaient anciennes). Vous pouvez, bien sûr, immédiatement essayer d’écrire le «fabrique» «Ultralight» et aller vérifier, mais à ce moment-là, j’ai manqué de cartes vides et même un peu effrayant d’aller «au hasard» - et si? Quand je suis rentré chez moi, la première chose que j'ai faite, sans même me laver les mains, s'est empressé de vérifier le nouveau billet avec mes propres clés. Et puis j'attendais une grosse défaite: le «hash» enregistré dans le ticket ne passait par aucune des clés. Par conséquent, les clés sont vraiment pourries et elles ont été remplacées par de nouvelles. Cela a complètement traversé tous mes travaux. Je me sentais un peu triste. J'ai brassé du thé vert, joué un peu du piano (oui) et me suis assis pour élever mes honoraires inachevés ...

Tout n'est pas perdu

L'idée m'est venue à l'improviste lorsque, pour une raison quelconque, j'ai de nouveau examiné le fichier avec les clés. J'ai remarqué que dans le trousseau de clés "en cours d'exécution" (utilisé pour calculer les "Ultralights" à 1, 2, 5 trains 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 un trousseau de clés dans lequel il n'y avait qu'une seule clé. Auparavant, je ne faisais pas attention à lui et me concentrais sur le "jogging". Pour calculer quels tickets cette clé est utilisée, je ne le savais pas. Quand j'ai regardé quel type de ticket est lié au trousseau de clés, j'ai eu une petite étincelle d'espoir. Le fait est que ce type de billet était - WESB. 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, la clé dans le trousseau de clés est une seule, ce qui a indirectement confirmé mon hypothèse. 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. Après avoir fouillé et ouvert les archives originales, j'ai vu que c'était effectivement le cas. Et plus important encore, après avoir examiné tous les anciens fichiers de clé, j'ai découvert que c'était cette clé qui restait inchangée! Déjà, sans la moindre hésitation, je rivetais avec mon propre VESB (heureusement, j'avais des dumps de ce type, ce qui simplifiait parfois la tâche - je changeais simplement les dates et les nombres dans les dumps), et calculais le hachage en utilisant cette clé. Il est donc temps de vérifier (d’autant plus que je viens d’acheter du plastique plus propre). En entrant dans le hall, j'ai d'abord attaché mon «ticket» au terminal de test. L’affichage indiquait la période de validité du ticket, que j’avais indiquée, et le voyant vert s’allumait. Donc ça marche. Ayant fait une grimace plus simple et caché le plastique blanc dans une manche, je suis allé au tourniquet, j'ai tendu la main au validateur et ... j'ai calmement passé au feu vert émettant de la lumière. Cela a marqué la victoire finale.

Et ensuite?

Et ensuite, les expériences ont commencé, au cours desquelles de nombreuses choses intéressantes ont été découvertes. Par exemple, sur une telle "gauche" VESB ne peut marcher que deux ou trois jours. Le fait est que le numéro que j’indique «du chauve» à l’intérieur du ticket est stocké dans la mémoire de la tête du tourniquet à chaque passage, puis, après un certain temps, il est envoyé avec les autres au centre de données. Là, le système ne trouve pas de ticket réellement émis avec ce numéro et le place dans la liste des arrêts, qui est ensuite envoyée à tous les tourniquets du métro. Et cela devrait être le cas 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. Le contourner, pour des raisons évidentes, n'est pas possible.

Il a également été noté que la définition ou non des bits de verrouillage importait peu que le ticket fonctionne ou non. La seule exception est 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. Plus tard, j'ai pris les terminaux de métro et de bus, je les ai mis en ordre, j'ai étudié et lancé sur le stand. Maintenant, afin de vérifier la prochaine estimation, il n'était plus nécessaire de courir dans le métro avec le ticket mutant nouvellement cuit et il devenait possible de le vérifier "sans quitter la billetterie". De plus, le terminal de métro s’est avéré être le même (tout le reste est bogué), tout comme mes clés. Je pourrais donc essayer «au travail» et tout autre type de billets «Ultralight» - quelque chose que je ne pourrai jamais «vivre» dans le métro. Parallèlement à ces expériences, j'ai continué à m'engager dans des logiciels.

Puisqu'il y avait beaucoup de controverse 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 en comprendre le type - quelque chose de largement connu ou une sorte de son propre développement interne. En cours de route, beaucoup de pensées m'ont visité (y compris le fait qu'il s'agisse d'AES), mais lorsque j'ai étudié le code qui fonctionnait déjà en détail sans utiliser les bibliothèques Smart Library, il s'est avéré que cet algorithme est "uniquement" GOST - une norme de cryptage domestique (toutes les informations nécessaires on peut facilement le trouver sur le Web). Plus précisément, un cycle de 16 W a été utilisé pour calculer le hachage. "Hash" n'est en réalité qu'une imitation de GOST.

La structure des informations enregistrées sur le ticket "Ultralight"

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, vous pouvez lire la documentation d'origine (un fichier PDF avec une description complète de la puce se trouve sur le disque). Je recommande de commencer à apprendre. Je décrirai la structure de l'emplacement des données générées par les systèmes de métro dans la zone utilisateur disponible pour la lecture et la réécriture (en l'absence de verrouillage, bien sûr). L'intégralité du contenu du ticket peut être divisée en une partie d'en-tête et en deux parties complètement dupliquées des données (ceci est effectué dans un but de réservation et de protection contre les erreurs). Le titre "Ultralight" des tickets commence à la page 4. Une partie de la structure est identique dans tous les tickets et identifiants du système métropolitain et de MosGoTrans. Les 10 premiers bits sont l'identifiant de l'application; les 10 bits suivants sont l'identifiant du type de carte (vous pouvez savoir quels identifiants se trouvent dans une autre boîte spéciale à cet effet). Une fois que les identificateurs ont été localisés, le numéro de série du ticket (il est marqué au dos du ticket, ne le confondez pas avec le matériel - ce sont deux choses différentes!) D'une taille de 32 bits. Les 4 derniers bits sont le champ Mise en page, qui indique au système comment interpréter les données suivantes (quelque chose comme un format de fichier).

Pour les tickets Ultralight, la valeur de Layout est 0x08. À la même partie du titre se termine. De plus, 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 1er janvier 1992. Ici se termine la partie en-tête 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. Après cela, la période de validité du ticket est indiquée en jours (à partir du moment de l'émission) - 8 bits. Les 16 premiers bits de la page 9 constituent le compteur de déclenchement. Il peut être réduit à zéro (pour tous les billets avec un nombre de voyages limité) 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 à chaque passage entre son identifiant unique. Apparemment, ceci est utilisé pour empêcher la rentrée sans attendre un ticket VESB (les tourniquets dans le hall sont connectés au réseau et s’interroger), ainsi que pour voir quel tourniquet a été passé (par exemple, en cas d’erreur ou pour des statistiques ). La page 10 est entièrement 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 (de 12 à 15). Il se trouve qu'en fonctionnement normal, ces deux zones contiennent toujours les mêmes données. Séparément, il faut dire à propos de l'utilisation de la zone système OTP Il est utilisé pour “épuiser” progressivement un ticket à chaque voyage (cela ne s'applique pas aux tickets VESB). Les deux bits les plus bas sont définis lorsque le ticket est annulé ou annulé (par liste d'arrêt). Un billet annulé ne peut pas être restauré. Il ne reste que 30 bits pour l'épuisement. Cette zone est représentée par le système comme 100% des trajets. A chaque nouveau voyage, un certain nombre de bits est défini (du plus jeune au plus ancien), correspondant au nombre de pour cent d'un voyage. Par exemple, pour un billet de 5 trains, chaque nouveau voyage sera «grillé» de 6 bits, et pour un billet de 60 trains, un demi-bit (arrondi). Il est à noter que la réutilisation des billets Ultralight est impossible, non seulement à cause de la destruction de l'OTP, mais également du fait qu'au comptoir des billets émettant un billet (et peut-être même lorsqu'il est fait), la quasi-totalité des pages est bloquée pour la réécriture. . Ainsi, ni “recharger” ni changer le type de ticket en un autre ne fonctionnera pas.

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

Tous les nombres sont en notation décimale!

ID d'application:

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

Identificateurs du type de billets "Ultralight":

  • 120 - Un tour.
  • 121 - Deux voyages.
  • 126 - Cinq voyages.
  • 127 - Dix manèges.
  • 128 - Vingt manèges.
  • 129 - Soixante voyages.
  • 130 - Bagages + Passage.
  • 131 - Bagages uniquement.
  • 149 - Single "Lightlight" (70 voyages).
  • 150 - VESB.

Mifare classique

Je n'ai pas ignoré le malheur Mifare Classic 1K dans mes recherches. Comme vous le comprenez, les clés principales des «classiques» étaient les clés matérielles A et B. Par chance, ces clés se trouvaient dans l’un des modules du programme sous forme ouverte (réservé aux 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 obtenues. Au cours des expériences, certaines caractéristiques intéressantes ont été révélées, telles que: le métro pour stocker le ticket utilise le premier secteur de la carte et le transport terrestre le quatrième; aucune protection, à l'exception des clés matérielles (qui, étant enregistré dans un logiciel sous cette forme, n'ont probablement jamais changé depuis la mise en service du système) n'existe pas sur ces tickets.

Le CRC-16 est plutôt indiqué à la fin de chaque bloc, simplement pour protéger les données contre les dommages. De plus, sur les cartes sociales, en plus des billets, de nombreuses informations diverses et intéressantes sont également enregistrées. Par exemple, dans les 13e et 14e secteurs de la carte sociale, on donne le nom de famille, le nom et le patronyme du propriétaire. 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 SCM étudiant, ainsi que plusieurs tickets pour les cartes Classic net.

Mais comme il s’est avéré que le système de liste d’arrêt enregistre parfaitement le clonage - un tel ticket ne peut être utilisé que pendant deux jours, puis il est annulé (bien que, contrairement à Ultralight, la carte Classic puisse être restaurée après annulation, mais à partir de la liste des stop cela 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 sur Ultralight.

La fin ou résumer

Les systèmes de métro, et en particulier les nouveaux tickets Ultralight, se sont avérés bien protégés, contrairement aux idées reçues et aux conjectures. Très heureux que les développeurs aient utilisé GOST, un logiciel fiable et éprouvé, sans réinventer la roue. Avec une telle protection, il est tout simplement impossible de falsifier le ticket Ultralight sans avoir accès à des données confidentielles (informations clés). Le système de clé et le mécanisme de liste d'arrêt sont également bien pensés. Bien sûr, pas sans défauts et erreurs. Le plus important d'entre eux est un logiciel qui n'est pas du tout protégé.

Il suffisait d'abandonner l'utilisation de runtime-bpl, ce qui rendrait l'analyse dix fois plus difficile! Sinon, le traitement de parties particulièrement importantes du programme par AsProtect ou ExeCryptor, suivi de la compilation de tous les fichiers avec MoleBox, réduirait les possibilités d'analyse à presque zéro. La boîte à outils est peu coûteuse. Et l’utilisation d’une bonne protection (de préférence peu connue ou sur commande) de ce type, mais avec des clés matérielles rendrait l’analyse du programme totalement impossible. Bien sûr, le métropolitain est une entreprise du régime, mais il ne faut pas oublier le facteur humain. Après tout, Kevin Mitnick a également déclaré (et a non seulement parlé, mais également montré à titre d'exemple, ce pour quoi il s'est assis), qu'il est parfois plus facile et plus efficace d'utiliser «l'ingénierie sociale» pour atteindre l'objectif que d'essayer de casser la défense impénétrable. Eh bien, sur cette note, je vais terminer mon histoire. Et vous, lecteurs, vous souhaitons 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é pour la transformation cryptographique des systèmes de traitement de l'information dans les réseaux d'ordinateurs électroniques (ordinateurs), de complexes informatiques individuels et d'ordinateurs, qui détermine les règles de cryptage des données et de génération d'imitations.

L'algorithme de transformation cryptographique est conçu pour une implémentation matérielle ou logicielle, répond aux exigences de la cryptographie et, dans la mesure du possible, n'impose aucune restriction quant au degré de confidentialité des informations protégées.

La norme est obligatoire pour les organisations, entreprises et institutions qui utilisent une protection cryptographique des données stockées et transférées dans des réseaux informatiques, dans des systèmes informatiques distincts ou dans des ordinateurs.

Schéma structurel de la transformation cryptographique

Le schéma fonctionnel de l'algorithme de transformation cryptographique (schéma de cryptage) illustré à la figure 1 contient:

  • - clé de mémoire (256 bits) pour 256 bits, composée de huit lecteurs 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 les constantes de remplissage С 2 , С 1 enregistrées dans ceux-ci;
  • - deux additionneurs 32 bits modulo 2 32 (CM 1 , CM 3 );
  • - additionneur 32 bits pour la somme au bit modulo 2 (CM 2 );
  • - additionneur modulo 32 bits (2 32 -1) (CM 4 );
  • - additionneur modulo 2 (CM 5 ), la limite de largeur de l'additionneur CM 5 n'est pas imposée;
  • - unité de substitution (K);
  • - le registre à décalage cyclique de onze pas dans la direction du chiffre supérieur (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 successifs de 4 bits, chacun d'eux étant converti en un vecteur de 4 bits par le nœud de remplacement correspondant, qui est un tableau de seize lignes contenant quatre bits de remplissage dans une ligne. Le vecteur d'entrée détermine l'adresse de la ligne dans la table, le remplissage de cette ligne est le vecteur sortant. Ensuite, les vecteurs de sortie à 4 bits sont combinés séquentiellement en un vecteur à 32 bits.

Avec l'addition et le décalage cyclique de vecteurs binaires, les chiffres les plus significatifs sont considérés comme des bits de lecteurs comportant de grands nombres.

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

Lors du remplacement d'informations, le contenu du pième chiffre d'un lecteur (additionneur) est réécrit dans le pième chiffre d'un autre lecteur (additionneur).

Les valeurs du remplissage constant avec 1 (constant) entraînement N 6 sont données dans le tableau 1.

Tableau 1

Entraînement décharge N 6

32

31

30

29

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

Entraînement décharge 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 donnée dans le tableau 2.

Tableau 2

Entraînement décharge N 5

32

31

30

29

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

Entraînement décharge 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 l'occupation des tables de blocs de substitution CZU et K sont des éléments secrets et sont livrées de la manière prescrite.

Le remplissage des tables du bloc de substitution K est un élément clé à long terme commun au 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, il est possible d’utiliser la possibilité de générer des clés (en remplissant une KZU) 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.

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

  • - cryptage (décryptage) des données en mode de remplacement simple;
  • - cryptage (décryptage) des données en mode de jeu;
  • - cryptage (décryptage) des données en mode gamming avec feedback;
  • - mode de production

Chiffrement de remplacement simple

Cryptez les données ouvertes en mode swap facile

Un schéma cryptographique qui implémente un algorithme de chiffrement dans le mode de remplacement simple devrait avoir la forme indiquée à la figure 2.


Figure 2

Les données ouvertes à chiffrer sont divisées en blocs de 64 bits chacun. Entrée d'un bloc quelconque T 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) information binaire dans les lecteurs N 1 et N 2 sont produits de sorte que la valeur de 1 (0) soit entrée dans le premier chiffre de N 1 , la valeur de 2 (0) soit entrée dans le deuxième chiffre de N 1 , etc., la valeur de 32 ( 0) est inscrit dans la 32ème catégorie de 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 2e 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 (un 32 (0), un 31 (0), ..., un 2 (0), un 1 (0)) lecteur N 1 et l'état (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) du lecteur N 2 .

Dans le KZU, entrez 256 bits de la clé. Le contenu de huit lecteurs 32 bits X 0 , X 1 , ..., X 7 a la forme suivante:

  • 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 de données ouvert 64 bits en mode de remplacement simple comprend 32 cycles.

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

Le résultat de la sommation est transformé 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 du décalage est additionné modulo 2 au bit dans l'additionneur CM 2 avec remplissage à 32 bits de l'accumulateur 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, tandis que dans le deuxième cycle, le remplissage de X 1 est lu dans le CPC, dans le troisième cycle, le remplissage de X 2 est lu dans le CPC et dans le huitième cycle, le remplissage de X 7 est lu dans le CPC. Du 9 au 16, ainsi que du 17 au 24, les lectures du CPC sont lues 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 32e ordre de lecture, les remplissages du KZU sont inversés: X 7 , X 6 , X 5 , X 4 , X 3 , X 2 , X 1 , X 0 .

Ainsi, lors du chiffrement sur 32 cycles, l'ordre de sélection des remplissages de lecteurs est exécuté:

  • 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 enregistré dans l'accumulateur N 1 .

Obtenus après le 32ème cycle de cryptage, le remplissage des lecteurs N 1 et N 2 constitue un bloc de données cryptées correspondant à un bloc de données ouvertes.

Déchiffrement des données cryptées en mode de remplacement facile

Un schéma cryptographique qui implémente un algorithme de déchiffrement dans le mode de remplacement simple a la même forme (voir la figure 2) que lors du chiffrement. Dans le KZU, entrez 256 bits de la même clé sur laquelle le cryptage a été effectué. Les données chiffrées à déchiffrer sont divisées en blocs de 64 bits chacun. Entrez n'importe quel bloc T W = (a 1 (32), et 2 (32), ... et 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 premier chiffre de N 1 , la valeur de 2 (32) soit entrée dans le deuxième chiffre de N 1 , etc., la valeur de 32 (32). est inscrit dans la 32ème catégorie de N 1 ; la valeur de b 1 (32) est entrée dans le 1er chiffre de N 2 , la valeur de b 2 (32) est entrée dans le deuxième chiffre de N 2 , etc., la valeur de b 32 (32) est entrée dans le 32e chiffre de N 2 .

Le déchiffrement est effectué selon le même algorithme que le chiffrement des données ouvertes, avec le changement suivant: les remplissages des lecteurs X 0 , X 1 , ..., X 7 sont lus dans la mémoire dans les 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 .

Obtenu après 32 cycles de travail, le remplissage des lecteurs N 1 et N 2 constitue 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 à un bloc de données cryptées, la valeur de 1 (0) du bloc T 0 correspond au contenu du 1er chiffre N 1 , la valeur de 2 (0) correspond au contenu du deuxième chiffre N 1 , etc., la valeur a 32 (0) correspond au contenu 32 n numéro de décharge 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 chiffre N 2. .

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

Mode gamma

Crypter les données ouvertes en mode de jeu

Le schéma cryptographique qui implémente l'algorithme de cryptage en mode de jeu devrait 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 modulation binaire dans l'additionneur CM. 5 avec la gamme de chiffrement G w , qui est produite en blocs de 64 bits, c.-à-d.

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

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

Г ш(i) est le i-ème bloc de 64 bits, i = 1 ÷, le nombre de chiffres binaires dans le bloc T 0(M) peut être inférieur à 64, tandis que la partie du chiffrement du bloc G (M) non utilisé pour le cryptage jeté.

Dans le KZU, entrez 256 bits de la clé. Une séquence binaire de 64 bits (envoi synchro) 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 du gamma de chiffrement. L’envoi synchro 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 le premier chiffre de N 2 , la valeur de S 34 dans le deuxième chiffre de N 2 , etc., la valeur de S 64 est entrée dans le 32e chiffre de N 2 .

Le remplissage initial des lecteurs N 1 et N 2 (synchrophase S) est crypté en mode de remplacement simple conformément aux exigences du paragraphe 1.3.1. Le résultat du cryptage est réécrit dans les lecteurs N 3 et N 4 de 32 bits de sorte que le remplissage de N 1 soit réécrit dans N 3 et que le remplissage de N 2 soit réécrit dans N 4 .

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

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

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

Le remplissage des N 1 et N 2 est crypté en mode de remplacement simple conformément aux exigences du paragraphe 3.1. Le remplissage de chiffrement résultant N 1 , N 2 constitue le premier bloc de 64 bits du code de chiffrement G W(1) , qui est additionné modulo 2 bits dans l'additionneur CM 5 avec le premier bloc de données ouvert de 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 chiffrées de 64 bits est obtenu: T w(1) = (τ 1(1) , τ 2(1) , ..., τ 63(1) , τ 64(1) ).

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

Pour le prochain bloc gamma de 64 bits du chiffre G w(2), le remplissage de N 4 est additionné modulo (2 32 -1) dans l'additionneur CM 4 avec la constante С 1 de N 6 , le remplissage dans N 3 est additionné de modulo 2 32 dans l'additionneur CM 3 avec une constante C 2 de N 5 . Le nouveau remplissage de N 3 est réécrit sur N 1 et le nouveau remplissage de N 4 est réécrit sur N 2 , tandis que le remplissage de N 3 et N 4 est conservé.

Le remplissage des N 1 et N 2 est crypté en mode de remplacement simple conformément aux exigences du paragraphe 3.1. Le chiffrement résultant, qui remplit N 1 , N 2, constitue le deuxième bloc de 64 bits du code de chiffrement G W(2) , qui est additionné bit par bit modulo 2 dans l'additionneur CM 5 avec le deuxième bloc de données ouvert T 0(2) . De même, des blocs de chiffrement gamma de Gw (3) , Gw(4) ..., Gw(M) sont produits et des blocs de données ouverts T 0(3) , T 0(4) ..., T 0(M) sont cryptés. Si la longueur du dernier m ième bloc de données ouvertes T 0(M) est inférieure à 64 bits, à partir du dernier m ième bloc du chiffrement gamma G W(M) , seul le nombre correspondant de bits de chiffrement gamma est utilisé pour le cryptage, les bits restants sont ignorés.

L'envoi synchrone S et les blocs de données cryptées T ш(1) , T ((2) ..., Tw(M) sont transmis au canal de communication ou à la mémoire de l'ordinateur.

Décryptage des données cryptées en mode de jeu

Lors du décryptage, le schéma de cryptage est identique à celui du cryptage (voir Figure 3). Dans la KZU, 256 bits de la clé sont entrés, avec lesquels les données T 0(1) , T 0(2) ..., T 0(M) ont été cryptées, alors que T 0(M) peut contenir moins de 64 bits.

Mode gamma avec retour

Cryptage des données ouvertes dans les jeux avec feedback

Un schéma de chiffrement qui implémente le mode de jeu avec des commentaires devrait avoir la forme suivante: montré à 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 dans le mode de jeu avec rétroaction par une modulation au niveau du bit modulo 2 dans l'additionneur CM 5 avec la gamme du chiffrement G 64 bits, c'est-à-dire Г ш = (Г ш(1) , Г ш(2) , ..., Г ш(М) ), où M - est déterminé par la quantité de données cryptées, Г ш(i) est le i-ème bloc de 64 bits, i = 1 Ì. Le nombre de chiffres binaires dans le bloc T 0(M) peut être inférieur à 64.

Dans le KZU, entrez 256 bits de la clé. Une séquence binaire de 64 bits (envoi synchronisé) S = (S 1 , S 2 , ..., S 64 ) est entrée dans les accumulateurs N 1 , N 2 . L’envoi synchro 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 le premier chiffre de N 2 , la valeur de S 34 dans le deuxième chiffre de N 2 , etc., la valeur de S 64 est entrée dans le 32e chiffre de 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) ).

Блок зашифрованных данных Т ш(1) одновременно является также исходным состоянием N 1 , N 2 для выработки второго блока гаммы шифра Г ш(2) и по обратной связи записывается в указанные накопители. При этом значение τ 1(1) вводится в 1-й разряд N 1 , значение τ 2(1) вводится во 2-й разряд N 1 и т.д., значение τ 32(1) вводится в 32-й разряд N 1 ; значение τ 33(1) вводится в 1-й разряд N 2 , значение τ 34(1) вводится во 2-й разряд N 2 и т.д., значение τ 64(1) вводится в 32-й разряд N 2 .

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

Выработка последующих блоков гаммы шифра Г ш(i) и зашифрование соответствующих блоков открытых данных Т 0(i) (i=3÷Ì) производится аналогично. Если длина последнего М-го блока открытых данных Т 0(М) меньше 64 разрядов, то из Г ш(М) используется только соответствующее число разрядов гаммы шифра, остальные разряды отбрасываются.

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

Décryptage des données cryptées en mode de jeu avec feedback

Lors du déchiffrement, le schéma de chiffrement est le même que lors du chiffrement (voir Figure 4). Dans la KZU, 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. L’envoi synchronisé 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 le premier chiffre de N 2 , la valeur de S 34 dans le deuxième chiffre de N 2 , etc., la valeur de S 64 est entrée dans le 32e chiffre de N 2 .

Le remplissage initial des lecteurs N 1 et N 2 (synchrophase S) est crypté en mode de remplacement simple conformément aux exigences de la clause 3.1. Le chiffrement résultant, remplissant N 1 , N 2, constitue le premier bloc de 64 bits du chiffrement gamma G W(1) , qui est additionné bit par bit modulo 2 dans l'additionneur CM 5 avec le bloc de données chiffré TW(1) . Le résultat est le premier bloc de données ouvert T 0(1) .

Le bloc de données cryptées T b(1) est le remplissage initial de N 1 , N 2 pour générer le deuxième bloc du chiffre gamma G 3 (2) . Le bloc T W(1) est écrit en N 1 , N 2 . La valeur τ 1(1) est entrée dans le premier chiffre N 1 , la valeur τ 2(1) dans le deuxième chiffre N 1 , etc., la valeur τ 32(1) dans le 32e chiffre N 1 ; la valeur τ 33(1) est entrée dans le premier chiffre de N 2 , la valeur τ 34(1) dans le deuxième chiffre de N 2 , etc., la valeur de τ 64(1) est entrée dans le 32e chiffre de N 2 . Le remplissage résultant N 1 , N 2 est crypté dans le mode de remplacement simple conformément aux exigences de l'article 3.1, le bloc résultant G W(2) est additionné modulo 2 par bit dans l'additionneur CM 5 avec le deuxième bloc de données cryptées TW(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 T ((2) , T ((3) ..., T ((M-1)) sont enregistrés séquentiellement, dont, dans le mode de remplacement simple, les blocs gamma du chiffrement G ((3) , D 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 de T m(3) , T m(4) ..., T m(M) , donnant ainsi lieu à des blocs de données ouverts 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 production

Pour fournir une protection imitation de 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 produit ( et l'insertion I 1 ). Le processus de génération d'une imitation est uniforme pour tous les modes de cryptage.

Le premier bloc de données ouvertes 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 enregistré dans les lecteurs N 1 et N 2 , la valeur de t 1(1) = a 1(1) (0) est entrée dans le 1er chiffre de N 1 , la valeur de t 2(1) = a 2(1) (0) est entrée dans le deuxième chiffre de N 1 , etc., la valeur t 32(1) = a 32(1) (0) est entrée dans le 32ème chiffre de 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 entrée dans le 32ème chiffre N 2 .

Le remplissage de N 1 et N 2 est soumis à une transformation correspondant aux 16 premiers cycles de l'algorithme de chiffrement en mode de remplacement simple, conformément aux exigences de l'article 3.1. En même temps, dans la KZU, il existe la même clé 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 ш(1) , T ш(2) , ..., T w(M) .

Le remplissage de 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)), sommés 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 somme est entré dans N 1 et N 2 et subit une transformation correspondant aux 16 premiers cycles de l'algorithme de cryptage en mode de remplacement simple.

Le remplissage résultant de 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é par un bloc complet de 64 bits avec zéros, est ajouté au CM 5 modulo 2 avec le remplissage de 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 somme est entré dans N 1 , N 2 et est crypté dans le mode de remplacement simple par les 16 premiers cycles de l'algorithme. Sur le remplissage obtenu des accumulateurs 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 )].

Imitovta AND l est transmis sur un canal de communication ou dans une mémoire d'ordinateur à la fin des données cryptées, c'est-à-dire Tw(1) , Tw(2) , ..., Tw(M) et l .

Les données cryptées reçues Tw (1) , Tw(2) , ..., Tw(M) sont décryptées à partir des blocs de données ouvertes reçues T 0(1) , T 0(2) , ..., T 0(M), la sortie est générée. Et l , qui est ensuite comparé à l’imitation ET l , obtenue avec les données cryptées du canal de communication ou de la mémoire de l’ordinateur. En cas de non concordance des émetteurs, les blocs de données ouverts 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 le simulateur) est déterminée par les exigences cryptographiques valides, en tenant compte du fait que la probabilité d'imposer de fausses données est égale à 2 - l .