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

Злом метро (проїзних, карток) + Алгоритм КРИПТОГРАФІЧНИХ ПЕРЕТВОРЕНЬ ВІДПОВІДНО ДО ГОСТ 28147-89

На сторінці:


Злом метро (проїзних, карток)

Чи знайоме тобі бажання розгадати всі загадки та розкрити всі захисту Московського Метрополітену? Зробити, наприклад, собі «вічний квиток»? Але ж фахівці метро постійно знаходять все більш витончені способи захисту. Металеві жетони змінилися пластиковими, ті, в свою чергу, магнітними квитками, а на зміну магнітним прийшли безконтактні карти. У багатьох дослідників опустилися руки - здається, ніби Метрополітен став неприступною фортецею. Але будь-який захист можна обійти. І часто, розкрити її виявляється в рази простіше, ніж побудувати ...

Як все починалося

Інтерес до систем підземки з'явився у мене давно, можна сказати, зі шкільної лави, коли в ходу ще були квитки з магнітною смугою. Тоді ж (з десяток років тому) ввели в обіг безконтактну соціальну карту для учнів. Я став цікавитися, що ж це таке і як працює. Але в ті часи і у мене не було достатньо навичок, та й інформації, особливо за цими технологіями, у відкритому доступі було небагато. Довелося відкласти ідею досліджень в довгий ящик, але я пообіцяв собі, що обов'язково до неї повернуся ...

Років зо три тому у мене знову прокинувся інтерес до теми метро. Я активно вивчав магнітні квитки (інформації по цій темі в інтернетах було більш ніж достатньо) і навіть зібрав маленький станочек для виготовлення дублікатів з двох головок від котушкові магнітофонів і невеликої кількості рассипухі. Не забув і про свою соціальну карту (вже студентську). Але після вивчення документації мені стало зрозуміло, що система практично неприступна - чіп MF1S50 Mifare Classic 1K, на базі яких виготовляються соціальні карти, захищений двома 48-бітними ключами. На апаратному рівні зламати його так просто не вийде, а перебирати ключі можна до кінця сонячної системи. Та й картоводом, що підтримують Classic, коштували на той час якихось непідйомних грошей (про Ebay я якось не подумав, на жаль). Інтерес до магнітних квитках швидко охолов, а соціальну карту довелося знову відкласти до кращих часів.

Зустрічайте: «Ультралайт»

Квитки «Ультралайт» з'явилися в нашому метро недавно, але відразу ж викликали у громадськості бурхливий інтерес. Їх почали курочіть, рвати, розклеювати праскою і застосовувати інші методи терморектального криптоанализа. Треба зізнатися, жага знань змусила і мене розкурочити парочку. В результаті їх вивчення і пошуків в інтернетах було встановлено - це не що інше, як Mifare Ultralight, «полегшена» сумісна версія Mifare Classic. Побіжний перегляд документації по чіпам цього стандарту дав зрозуміти - вбудованих систем захисту у цих карт немає. До всього іншого я напав на статтю, детально описує успішний злом схожою транспортної системи голландськими студентами. Всі разом підштовхнуло мене до нових досліджень.

Поїхали!

Для початку, зрозуміло, просто необхідно було десь роздобути бездротової картовод, що підтримує «Ультралайт». Було два варіанти: або зібрати самому (що зайняло б багато часу), або купити вже готовий пристрій. При думці про другий варіант, пам'ятаючи про ціни трирічної давності, у мене пішли мурашки по шкірі. Але я все ж таки зважився подивитися актуальні ціни. І не дарма! Я був приємно здивований, дізнавшись, що можна купити повністю функціональний девайс (OmniKey CardMan 5321), який підтримує купу дротових і бездротових карт за привабливою ціною - 4000 рубликів.

Звичайно, не мало, але з іншого боку, це і не 10000; тим більше, покупка готового рідера давала можливість відразу зосередитися на дослідженнях квитків, а не на конструюванні і налагодженні заліза, яка могла затягтися на невизначений термін. Разом з рідером у тієї ж фірми (ISBC) був придбаний дуже зручний оригінальний SDK місцевого виробництва. Він, знову ж таки, дозволив не розтрачувати сили і час на написання нізкоуровневкі і налагодження роботи ПО з рідером, а зосередитися безпосередньо на квитках. Отже, за пару днів неспішного кодинга народилася маленька програмка, за допомогою якої можна було в зручній формі спостерігати і правити всю внутрішню структуру «ультралайти». Тоді я почав вивчати квитки.

глуха стіна

У процесі вивчення через мій рідер пройшло дуже багато квитків. Якісь я, засукавши рукава, діставав «з смітника», якісь купував - дивився, що на них записано, потім проходив і дивився ще раз. Це були квитки майже всіх типів, за винятком, мабуть, проїзного «ультралайти» на 70 поїздок. Через пару тижнів у мене накопичилася велика і відсортована база дампов різних квитків і в різних станах. Були і дампи, зняті з одного і того ж квитка після кожної поїздки, і кілька квитків з метрополітенівськими номерами, що йдуть підряд. В мою колекцію потрапило навіть кілька дампов двох різних часових єдиних соціальних квитків (один був виданий строком на 5 днів, інший на 30), знятих через певний часовий інтервал. Це виявилися дуже цікаві екземпляри, і при цьому дуже рідкісні (мені вони діставалися з перших рук з негайним поверненням, тільки на «прочитати»).

По суті, це майже єдиний тип «ультралайти», який працює не тільки в метро, ​​але і на наземному транспорті. До того ж, тільки у цього типу квитків взагалі немає обмеження на кількість поїздок. Згодом, саме вони співслужили мені велику службу ... Весь цей зоопарк я збирав з однією метою - чітко визначити структуру і формат запису даних на квитку. Звичайно, якісь поля було видно відразу, неозброєним оком, але деякі ні. Наприклад, я не відразу зрозумів, де записаний номер квитка метро (той самий, який на ньому надруковано). Усвідомлення прийшло зовсім випадково. Справа в тому, що я (як і, думаю, більшість з нас), дивлячись в Хекс, звик вирівнювати для себе інформацію по байтам і мислити, мінімум, байтами. З'ясувалося, що тут цей підхід є невірним. Дивлячись на дамп квитка, потрібно мислити більш дрібними одиницями - тетрадами, а іноді і битами. Зрозумів я це тоді, коли «побачив» нарешті номер квитка, - він виявився зрушать на 4 біта щодо початку байта, а що залишилися 4 біта з одного і з іншого боку номера займала інша службова інформація. Через деякий час формат запису даних на квитки став майже повністю зрозумілий.

Стало очевидно, де і як зберігаються всі дати, лічильники, ідентифікатори. Залишалася лише пара полів, призначення яких було неясно просто тому, що від дампа до дампи дані в них були однакові. Але на цьому вся радість і закінчилася - нерозумно було б припускати, що такі квитки можуть залишити незахищеними. У кожному дампі було 32 біта різної інформації, що не корелювало з іншим вмістом. Я припустив, що це свого роду контрольна сума, «хеш» даних, записаних на квитку. Всі спроби прикинути або розрахувати ці 32 біта обернулися повним провалом (зокрема, було припущення, що це якийсь вид CRC32, з нестандартним поліномом і стартовим значенням).

При спробі змінити хоча б півтора біта інформації всередині квитка термінал перевірки в метро висвічував «ПОГАНИЙ КВИТОК», важким домкратом забиваючи останні цвяхи в кришку труни. Звичайно, були спроби обійти систему і іншими способами, наприклад, спробувати скопіювати квиток на чисту карту один-в-один (тут, на жаль, завадив заводський серійний номер, який, як з'ясувалося, теж брав участь в генерації «хеша») або виставити біти блокувань так , щоб заборонити турнікету змінювати вміст квитка. Перевірки термінал такої «вічний» квиток визнавав, але турнікет пускати відмовлявся ... Таким чином, я уперся в стіну. В ту велику, міцну бетонну стіну, про яку багато хто має звичку побиватися з розбігу. Не знайшовши жодної інформації на форумах і дошках, я вирішив, що на цьому мої дослідження закінчені - шляхів більше немає, і поставив жирну крапку. Як з'ясувалося, даремно ...

дивне знайомство

Вересневий вечір нічим не відрізнявся від інших. Уже майже настала ніч, на вулиці було прохолодно і сиро. Я сидів перед екраном монітора, і, попиваючи теплий, трохи солодкий зелений чай, мирно розводив плату для чергової своєї вироби. DipTarce, трохи башорга, аська ... Хтось подзвонив по скайпу - відволікають! Знову аська, знову DipTrace - в загальному, все як завжди. В черговий раз на передній план вивалилося вікно аськи - хтось, досі мені невідомий, написав «Привіт». Я, нічтоже сумняшеся, відповів тим же. Наступне повідомлення стало переломним у всій історії: «Ти начебто метро цікавишся, у мене тут таке-сяке барахло є. Якщо цікаво, давай зустрінемося, я тобі передам ». Спочатку мене це трохи збентежило і насторожило (може бути, розлучення або підстава, а може, і «спецслужби» зацікавилися - параноя бере свій), але потім я подумав: чому б і ні?

Спецслужби мною цікавитися навряд чи б стали, а грунту для розлучення, і вже тим більше, для підстави тут начебто і немає. Після недовгої бесіди ми домовилися про зустріч вдень, в центрі залу одній зі станцій московського метро. Незнайомець виявився високим хлопцем, в окулярах, з великим чорним поліетиленовим пакетом в руках. Ми привіталися, потім він передав мені пакет зі словами: «На, тримай. Мені це все одно не стало в нагоді, може тобі буде корисно ». Зазирнувши всередину, я побачив два метрошний терміналу, перекладених газетами, дещо хаотично розкиданих білих пластикових карток і болванку в коробочці. На моє запитання про те, скільки я за це повинен (грошей), хлопець похитав головою, посміхнувся і сказав: «Та ти що, ніхто нічого нікому не винен, займайся ... Так, мені вже бігти треба, он і поїзд мій як раз! Бувай!".

З цими словами він втік, застрибнув у вже закриваються двері вагона і поїхав. А я, зізнаюся, трохи в непонятка поїхав додому. Контакт з аськи я про всяк випадок видалив, заодно почистивши контактліст на сервері і прибравши логи (ще раз привіт, параноя). Зрештою, напише ще раз, якщо що. Але більше він мені так і не написав ...

Явище софта народу

Прийшовши додому, я розібрав пакет. Другий з терміналів виявився автобусним валідатором (важкий, блін!); картки були Mifare Classic 1K (чисті), а на диску красувався один єдиний архів. Після побіжного ознайомлення зі змістом з'ясувалося - це софт, який використовується на касах метро. Відклавши убік термінал і валідатор, я вирішив впритул зайнятися вивченням цікавого софту. Приблизно за годину з бардаку, який розпакувати, мені вдалося вибудувати і запустити у себе на комп'ютері цю програму. Ще годину потрібен, щоб розібратися в її структурі. Прочесавши все ini-файли (з коментарями, люб'язно залишеними розробником), я вже мав повне уявлення що це, як це працює і з чим це їдять. Їдять, як з'ясувалося, з рідером Parsec PR-P08, тому, за відсутністю оного, спробувати софт в дії не вдалося.

Розробником значилася фірма «Смартек» - великий державний підрядник, який розробляє системи такого роду (докладніше можна почитати на їхньому сайті). Програма була написана на Delphi з використанням рантайм-bpl'ок. Причому, софт мав модульну структуру, і все підпрограми, класи і компоненти розташовувалися в окремих DLL або bpl'ках з промовистими назвами (ось це був і найголовніший фейл розробників). Після побіжного аналізу нутрощів софта я з'ясував, що, по-перше, інформація про всі видані квитках передається в централізовану базу даних (до речі, це Oracle) і, по-друге, в програмі використовується якийсь механізм ключів. Програма могла спілкуватися з БД не тільки в режимі реального часу. Робимо висновки: всі операції в системі можуть відбуватися з певною затримкою. Теоретично, це дає нам фору.

Але перш за все мене зацікавив механізм ключів (я приблизно вже почав здогадуватися, навіщо він може бути потрібен). Отже, я взявся за дизассемблер і приступив до роботи. Механізм складався з двох файлів - CryptKeyRef.dll і keys.d (єдиний «хитрий» файл у всій програмі, який, крім як на файл з ключами, більше ні на що не схожий). А користувалася усім цим добром рантайм-bpl'іна SmLayout.bpl. Ця бібліотека виявилася просто знахідкою для моїх досліджень - в ній містилися класи для роботи з внутрішнім наповненням квитків. Так як це рантайм-bpl, то досить було просто поглянути на її таблицю експорту, щоб вже відсотків на 60 зрозуміти, що до чого. Більш детальний аналіз розставив все на свої місця. Пам'ятаєш, на початку статті я говорив про те, що в структурі «ультралайти» залишилися ще кілька полів, призначення яких було незрозумілим?

Одне з цих полів - так званий «ідентифікатор розкладки». По суті, всі квитки метро будуються з фіксованою заголовної частини і змінної частини даних. Так ось, це поле «Layout» в заголовку якраз і визначало, яким чином і які дані розташовані в решти квитка. Таких розкладок існує кілька (кожна під свій тип квитка), і в SmLayout.bpl кожної з них відповідав свій клас (плюс загальний клас-батько, в якому були методи для роботи з заголовної частиною). Тому розібратися, які поля в кожній розкладці за що відповідають, було просто (ще б пак, з промовистими-то іменами методів в експорті!). Добивши повністю весь Layout 8 (який використовується в «ультралайти») і перевіривши, про всі чи полях в структурі квитка у мене було вірне уявлення, я взявся за механізм ключів. Дійсно, він відповідав за генерацію «хеша». Як працює механізм, стало цілком зрозуміло після вивчення роботи методу, який відповідав за обчислення «хеша». Перш за все, з файлу з ключами (keys.d) вибирається вірний ключ.

Система влаштована так, що у кожного типу квитків є свій ідентифікатор (в комплекті присутня повна таблиця з ідентифікаторами і назвами квитків, у вигляді текстового файлу зі значеннями, розділеними коми). Складається він з ідентифікатора зони (додатки) і ідентифікатора типу карти. Так ось, виходячи з цих чисел, в файлі ключів вибирається кейрінг, всередині якого може бути вже кілька ключів (на випадок, коли новий ключ ввели, а старі квитки ще використовуються). Запис нового квитка відбувається з використанням самого першого, а перевірка на валідність - з використанням всіх ключів в кейрінге. Далі обраний ключ розшифровується за допомогою CryptKeyRef.dll (навіщо їх зберігають зашифрованими, розуму не прикладу). Після чого розшифрований ключ і майже всі дані квитка, а також його апаратний серійний номер і число (метод генерації «хеша», який вказується для кейрінга в keys.d) - передаються в функцію ckCalcHashCode, що знаходиться в тій же CryptKeyRef.dll. На виході ми отримуємо значення, на якому я свого часу і «застряг» - той самий «хеш». Зрозуміло, я написав маленьку програмку, яка, використовуючи ці функції з CryptKeyRef.dll і файл keys.d, могла перевіряти і, в разі чого, перераховувати «хеш» всередині будь-якого дампа. Я перевірив ще раз все на кількох дампи, і, отримавши позитивний результат, пішов, задоволений, спати.

протухлі ключі

Незважаючи на теоретичний успіх, хотілося перевірити все, так би мовити, «в бою». На наступний день, повертаючись з роботи, я спеціально прикупив свіжий «Ультралайт» на одну поїздку, щоб подивитися, чи діють мої ключі або вже немає (судячи з усього, вони були старенькі). Можна, звичайно, відразу було спробувати записати «сфабрикований» «Ультралайт» і піти перевірити, але на той момент у мене закінчилися порожні карти, та й трохи страшнувато йти «навмання» - раптом що? По приходу додому я першим ділом, навіть не помивши руки, з нетерпінням кинувся перевіряти свіжий квиток своїми ключами. І тут мене чекав великий облом - «хеш», записаний в квитку не проходив ні по одному з ключів. Стало бути, ключі дійсно вже протухли і на зміну їм прийшли нові. Це повністю перечеркивало всі мої труди. Мені трохи стало сумно. Я заварив зеленого чаю, пограв трохи на фортепіано (да-да) і сіл далі розводити свою незакінчену плату ...

Ще не все втрачено

Ідея прийшла до мене несподівано, коли я в черговий раз чогось дивився всередину файлу з ключами. Я помітив, що в «ходовому» кейрінге (який використовується для розрахунку 1-, 2-, 5-поездочних і інших «ультралайти») було два ключі - новий (на той момент, зрозуміло) і, по всій видимості, - старий. Але був також кейрінг, в якому лежав всього один ключ. Раніше я не звертав на нього уваги, а концентрувався на «ходовому». Для розрахунку яких квитків використовується цей ключ, я не знав. Коли я подивився, що за тип квитка прив'язаний до кейрінгу, то у мене спалахнула маленька іскорка надії. Справа в тому, що цей тип квитка був - весб. Так, саме той рідкісний тип квитка, - тимчасовий проїзний на всі види транспорту. Я прикинув, що якщо квиток єдиний, то цей ключ повинен використовуватися не тільки в метро, ​​але і на наземному транспорті, де його дуже складно і довго замінювати на новий.

До того ж, ключ в кейрінге всього один, що побічно підтверджувало мій здогад. До всього іншого, я згадав, що, коли вичищав метрошний програму від різного «сміття», там було щось, схоже на архів старих файлів ключів. Відкопавши і відкривши оригінальний архів, я побачив, що це дійсно так. І найголовніше, переглянувши всі старі файли ключів, я виявив, що саме цей ключ залишався незмінним! Уже без єдиної краплі сумніву я склепав свій власний весб (благо, у мене були дампи такого типу, що в рази спростило завдання - я просто поміняв в дампи дати і номер), а «хеш» розрахував з використанням цього ключа. Отже, настав час перевірки (тим більше, я як раз купив ще трохи чистого пластика). Зайшовши в вестибюль, я спочатку доклав свій «квиток» до перевірочного терміналу. На табло висвітився термін дії квитка, який я вказав, і загорівся зелений світлодіод. Стало бути, працює. Зробивши гримасу простіше і сховавши білосніжний пластик в рукав, я підійшов до турнікету, доклав руку до валідатора і ... спокійно пройшов на весело загорівся зелений. Це ознаменувало остаточну перемогу.

А що ж далі?

А далі почалися експерименти, в ході яких було з'ясовано безліч цікавих речей. Наприклад, за таким «лівому» весб можна ходити лише два-три дні. Справа в тому, що номер, який всередині квитка я вказую «від балди», при кожному проході зберігається в пам'яті голови турнікета, а через якийсь час відсилається разом з іншими в центр обробки даних. Там система не знаходить реально виданого квитка з таким номером і вносить його в стопліст, який потім розсилається по всіх турнікетів метро. І так повинно відбуватися з усіма типами квитків, не тільки з весб - на додаток до «хешу» і часто мінливих ключам це дуже хороший захист. Обійти її, зі зрозумілих причин, не представляється можливим.

Також було відмічено, що установка або не настановами бітів блокування не має ніякого значення на те, спрацює квиток чи ні. Виняток становить тільки біт блокування зони OTP, який турнікет, мабуть, перевіряє завжди, навіть незважаючи на те, що писати в OTP не збирається. Надалі я взявся за метрошний і автобусний термінали, привів їх в порядок, вивчив і запустив на стенді. Тепер, щоб перевірити чергову здогадку, вже не треба було бігти зі свіжоспеченим білетиком-мутантом в метро, ​​а стало можливим перевіряти їх «не відходячи від каси». Тим більше, термінал метро виявився такий же старий (до всього іншого і глючний), як і мої ключі. Так що я міг спробувати «в роботі» і будь-які інші типи квитків «Ультралайт» - то, чого я ніколи не зможу зробити «вживу» в метро. Паралельно з цими експериментами я продовжував займатися софтом.

Так як велося багато суперечок про те, що ж за алгоритм використовується при обчисленні «хеша», я вирішив повністю відновити його, переписавши алгоритм з нуля на «людському» мовою програмування, а в процесі якраз сподівався зрозуміти, який же це алгоритм - що -то широко відоме або ж якась своя, внутрішня розробка. Попутно мене відвідувало багато різних думок (в тому числі, що це може бути і AES), але при детальному вивченні вже працюючого коду без використання Смартековскіх бібліотек з'ясувалося, що алгоритм цей - «всього-на-всього» ГОСТ - вітчизняний стандарт шифрування (всю необхідну інформацію про нього ти зможеш без праці знайти в Мережі). Конкретно, для обчислення «хеша» використовувався цикл 16-З. «Хеш», по суті, це не що інше, як имитовставка ГОСТ.

Структура інформації, записаної на квитку «Ультралайт»

Що таке сторінка, де і як розташовуються апаратний серійний номер, біти блокування і зона OTP, ти можеш прочитати в оригінальній документації (файл-специфікація в форматі PDF з повним описом чіпа є на диску). Рекомендую почати вивчення саме з неї. Я ж опишу структуру розташування даних, що формується системами метро в призначеній для користувача області, доступною для читання і перезапису (при відсутності блокувань, природно). Весь вміст квитка можна умовно розділити на заголовну частину і дві повністю дублюють один одного частини даних (це зроблено з метою резервування та захисту від помилок). Заголовна частина в квитках «Ультралайт» починається зі сторінки 4. Частина її однакова за структурою у всіх квитках й ідентифікацію системи Метрополітену і Мосгортранс. Перші 10 біт - ідентифікатор додатки; наступні 10 біт - ідентифікатор типу карти (про те, які бувають ідентифікатори, ти можеш прочитати в іншій, спеціально виділеної для цього врізки). Після ідентифікаторів розташовується серійний номер квитка (він вибитий на зворотному боці квитка, що не плутай його з апаратним - це різні речі!) Розміром 32 біта. Останні 4 біта - поле Layout, яке вказує системі, яким чином інтерпретувати наступні дані (щось на зразок формату файлу).

Для квитків «Ультралайт» значення Layout одно 0x08. На цьому однакова частина заголовка закінчується. Далі в квитку «Ультралайт» вказана дата, по яку придатний бланк (16 біт). Всі дати в системі вказуються в форматі кількості минулих днів з 01.01.1992. Тут заголовна частина квитка «Ультралайт» закінчується (в квитках з іншим Layout ще може бути записана різна додаткова інформація). Перша область даних починається зі сторінки 8. Спочатку записані 16 біт дати видачі квитка. Після цього зазначений термін дії квитка в днях (з моменту видачі) - 8 біт. Перші 16 біт сторінки 9 - лічильник поїздок. Він може бути або зменшується до нуля (у всіх квитках з обмеженням числа поїздок), або збільшується від нуля (у квитках весб, без обмеження числа поїздок). Після лічильника в частині сторінки турнікет при кожному проході вписує свій унікальний ідентифікатор. По всій видимості, це використовується для запобігання повторного проходу без очікування по квитку весб (турнікети у вестибюлі з'єднані в мережу і опитують один одного), а також для можливості подивитися, через який турнікет був здійснений прохід (наприклад, в разі помилки або для ведення статистики ). Сторінка 10 повністю зайнята 32-бітовим «хешем».

Сторінка 11 пуста. Ця область даних цілком реплицируется на решту 4 сторінки (з 12 по 15). Виходить, що при нормальному функціонуванні ці дві області завжди містять однакові дані. Окремо варто сказати про використання системою зони OTP. Вона використовується для поступового «випалювання» квитка з кожною поїздкою (квитків весб це не стосується). Два наймолодших біта виставляються при гасінні або анулювання квитка (по стоп-листу). Анульований квиток відновленню не підлягає. Для випалювання залишається всього 30 біт. Ця зона представляється системою як 100% поїздок. З кожною новою поїздкою виставляється певну кількість біт (від молодших до старшого), що відповідає тому, скільки відсотків займає одна поїздка. Наприклад, для 5-поездочного квитка з кожною новою поїздкою буде «випалюватиметься» по 6 біт, а для 60-поездочного - по половинці біта (з округленням у більшу сторону). Варто згадати, що повторне використання квитків «Ультралайт» неможливо не тільки через «випалювання» OTP, але також через те, що на касі, при видачі квитка (а можливо навіть і при його виготовленні) майже всі сторінки блокуються для перезапису . Таким чином, ні «перезарядити», ні змінити тип квитка на інший вже не вийде.

Приклади використовуваних ідентифікаторів квитків метро

Всі числа вказані в десятковій системі числення!

Ідентифікатори програми:

  • 262 - Квиток Московського Метро.
  • 264 - Квиток наземного транспорту Москви.
  • 266 - Єдиний соціальний Москви і МО.
  • 270 - Квиток «Легкого метро».

Ідентифікатори типу квитків «Ультралайт»:

  • 120 - Одна поїздка.
  • 121 - Дві поїздки.
  • 126 - П'ять поїздок.
  • 127 - Десять поїздок.
  • 128 - Двадцять поїздок.
  • 129 - Шістдесят поїздок.
  • 130 - Багаж + прохід.
  • 131 - Тільки багаж.
  • 149 - Єдиний «Ультралайт» (70 поїздок).
  • 150 - весб.

Mifare Classic

Не оминув увагою в своїх дослідженнях я і нещасливий Mifare Classic 1K. Як ти розумієш, найголовнішою перешкодою на шляху до «Класикам» стояли апаратні ключі A і B. Завдяки щасливому випадку, ці ключі лежали в одному з модулів програми у відкритому вигляді (превед розробникам!) І мені не склало ніяких труднощів написати невелику програмку для роботи з вмістом цих карт, використовуючи отримані ключі. В процесі експериментів були виявлені деякі цікаві особливості, як то: метро для зберігання квитка використовує перший сектор карти, а наземний транспорт - четвертий; ніякого захисту, крім апаратних ключів (які, будучи записаними в софт в такому вигляді, швидше за все, взагалі жодного разу не змінювалися з моменту введення системи в експлуатацію) на цих квитках не існує.

Замість цього, в кінці кожного блоку вказана CRC-16, просто для захисту даних від пошкодження. До того ж, на соціальних картах, крім квитків, записано ще багато різноманітної та цікавої інформації. Наприклад, в 13 і 14 секторах соціальних карт вказані прізвище, ім'я та по батькові власника. Ці (і деякі інші) дані можна прочитати з використанням публічного ключа 0xA0A1A2A3A4A5. В ході експериментів вдалося повністю клонувати студентську СКМ, а також кілька проїзних квитків на чисті карти Classic.

Але від клонування, як з'ясувалося, чудово рятує система стоп-листів - таким квитком можна користуватися не більше двох днів, потім він анулюється (правда, на відміну від «Ультралайт», карту «Класик» можна відновити після анулювання, але від стоп-листа це не врятує). Оскільки ніякої захисту на картах Classic не використовувалося, вони досить швидко стали мені нецікаві, і я вирішив все-таки зосередитися на дослідженні «Ультралайт».

The End, або Підіб'ємо підсумки

Системи метро, ​​а зокрема, нові квитки «Ультралайт», всупереч думкам і здогадів, виявилися добре захищені. Дуже радує, що розробники використовували надійний та перевірений часом ГОСТ, а не стали винаходити велосипед. З таким захистом підробити квиток «Ультралайт», не маючи доступу до конфіденційних даних (ключової інформації), просто неможливо. Чудово продумана і система змінних ключів, і механізм стоп-листів. Звичайно, не обійшлося без недоліків і помилок. Найбільша з них - програмне забезпечення, яке ніяк не захищене.

Досить було відмовитися від використання рантайм-bpl, і це ускладнило б аналіз в десятки разів! Як варіант, - обробка особливо важливих частин програми AsProtect'ом або ExeCryptor'ом, з подальшою запаковування всіх файлів MoleBox'ом звели б можливість аналізу майже до нуля. Інструментарій-то недорогий. А використання хорошою (бажано, маловідомої або зробленої на замовлення) захисту подібного роду, але з апаратними ключами зробило б розбір програми повністю неможливим. Зрозуміло, Метрополітен - це режимне підприємство, але не варто при цьому забувати про людський фактор. Адже ще Кевін Митник говорив (і не тільки говорив, але і демонстрував на власному прикладі, за що і сіл, ги), що іноді для досягнення мети простіше і ефективніше використовувати «соціальну інженерію», ніж намагатися зламати непробивну захист. Що ж, на цій ноті я й закінчу свою розповідь. А тобі, читачу, бажаю більше цікавих і вдалих досліджень!








Опис алгоритму криптографічних перетворень відповідно до ГОСТ 28147-89

Даний стандарт встановлює єдиний алгоритм криптографічного перетворення для систем обробки інформації в мережах електронних обчислювальних машин (ЕОМ), окремих обчислювальних комплексах і ЕОМ, який визначає правила шифрування даних і вироблення имитовставки.

Алгоритм криптографічного перетворення призначений для апаратної або програмної реалізації, задовольняє криптографічним вимогам і за своїми можливостями не накладає обмежень на ступінь секретності інформації, що захищається.

Стандарт є обов'язковим для організацій, підприємств та установ, які використовують криптографічний захист даних, що зберігаються і передаються в мережах ЕОМ, в окремих обчислювальних комплексах або в ЕОМ.

Структурна схема алгоритму криптографічного перетворення

Структурна схема алгоритму криптографічного перетворення (кріптосхеми), наведеного на малюнку 1, містить:

  • - ключове пристрій (КЗУ) на 256 біт, що складається з восьми 32-розрядних накопичувачів (Х 0, Х 1, Х 2, Х 3, Х 4, Х 5, Х 6, Х 7);
  • - чотири 32-розрядних накопичувача (N 1, N 2, N 3, N 4);
  • - два 32-розрядних накопичувача (N 5, N 6) із записаними в них постійними заповнення З 2, З 1;
  • - два 32-розрядних суматора по модулю 2 32 (СМ 1, СМ 3);
  • - 32- розрядний суматор поразрядного підсумовування по модулю 2 (СМ 2);
  • - 32-розрядний суматор за модулем (2 32 -1) (СМ 4);
  • - суматор за модулем 2 (СМ 5), обмеження на розрядність суматора СМ 5 Не накладається;
  • - блок підстановки (К);
  • - регістр циклічного зсуву на одинадцять кроків у бік старшого розряду (R).

Малюнок 1.

Блок підстановки До складається з восьми вузлів заміни До 1, К 2, К 3, К 4, К 5, К 6, К 7, К 8 з пам'яттю на 64 біта кожен. Вступник на блок підстановки 32-розрядний вектор розбивається на вісім послідовно йдуть 4-розрядних векторів, кожен з яких перетворюється в 4-розрядний вектор відповідним вузлом заміни, що представляє собою таблицю з шістнадцяти рядків, що містять по чотири біта заповнення в рядку. Вхідний вектор визначає адресу рядки в таблиці, заповнення цього рядка є вихідним вектором. Потім 4-розрядні вихідні вектори послідовно об'єднуються в 32-розрядний вектор.

При додаванні і циклічному зсуві довічних векторів старшими розрядами вважаються розряди накопичувачів з великими номерами.

При записи ключа (W 1, W 2, ..., W 256), W q Є {0,1}, q = i ÷ 256, â КЗУ значення W 1 вводиться в 1-й розряд накопичувача Х 0, значення W 2 вводиться у 2-й розряд накопичувача Х 0, ..., значення W 32 вводиться в 32-й розряд накопичувача Х 0; значення W 33 вводиться в 1-й розряд накопичувача Х 1, значення W 34 вводиться в 2-й розряд накопичувача Х 1, ..., значення W 64 вводиться в 32-й розряд накопичувача Х 1; значення W 65 вводиться в 1-й розряд накопичувача Х 2 і т.д., значення W 256 вводиться в 32-й розряд накопичувача Х 7.

При перезапису інформації вміст p -го розряду одного накопичувача (суматора) переписується в p -й розряд іншого носія (суматора).

Значення постійної заповнення З 1 (константа) накопичувача N 6 наведено в таблиці 1.

Таблиця 1

Розряд накопичувача N 6

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

значення розряду

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Розряд накопичувача N 6

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

значення розряду

0

0

0

0

0

0

0

1

0

0

0

0

0

1

0

0

Значення постійної заповнення З 2 (константа) накопичувача N 5 приведено в таблиці 2.

Таблиця 2

Розряд накопичувача N 5

32

31

30

29

28

27

26

25

24

23

22

21

20

19

18

17

значення розряду

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Розряд накопичувача N 5

16

15

14

13

12

11

10

9

8

7

6

5

4

3

2

1

значення розряду

0

0

0

0

0

0

0

1

0

0

0

0

0

0

0

1

Ключі, що визначають заповнення КЗУ і таблиць блоку підстановки До, є секретними елементами і поставляються в установленому порядку.

Заповнення таблиць блоку підстановки До є довготривалим ключовим елементом, загальним для мережі ЕОМ.

Організація різних видів зв'язку досягається побудовою відповідної ключової системи. При цьому може бути використана можливість вироблення ключів (заповнення КЗУ) в режимі простої заміни та шифрування їх в режимі простої заміни із забезпеченням імітозащіти для передачі по каналах зв'язку або зберігання в пам'яті ЕОМ.

У кріптосхеми передбачено чотири види роботи:

  • - зашифрование (розшифрування) даних в режимі простої заміни;
  • - зашифрование (розшифрування) даних в режимі гамування;
  • - зашифрование (розшифрування) даних в режимі гамування зі зворотним зв'язком;
  • - режим вироблення імітовставки.

Шифрування в режимі простої заміни

Зашифрування відкритих даних в режимі простої заміни

Кріптосхеми, що реалізує алгоритм шифрування в режимі простої заміни, повинна мати вигляд, наведений на малюнку 2.


малюнок 2

Відкриті дані, що підлягають зашифрування, розбиваються на блоки по 64 біта в кожному. Введення будь-якого блоку Т 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)) двійковій інформації в накопичувачі N 1 та N 2 проводиться так, що значення a 1 (0) вводиться в 1-й розряд N 1, значення a 2 (0) вводиться у 2-й розряд N 1, і т.д., значення a 32 ( 0) вводиться в 32-й розряд N 1; значення b 1 (0) вводиться в 1-й розряд N 2, значення b 2 (0) вводиться у 2-й розряд N 2 і т.д., значення b 32 (0) вводиться в 32-й розряд N 2. В результаті отримують стан (a 32 (0), a 31 (0), ..., a 2 (0), a 1 (0)) накопичувача N 1 і стан (b 32 (0), b 31 (0), ... , b 2 (0), b 1 (0)) накопичувача N 2.

В КЗУ вводяться 256 біт ключа. Вміст восьми 32-розрядних накопичувачів Х 0, Х 1, ..., Х 7 має вигляд:

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

Алгоритм шифрування 64-розрядної блоку відкритих даних в режимі простої заміни складається з 32 циклів.

У першому циклі початкове заповнення накопичувача N 1 підсумовується по модулю 2 32 в суматорі СМ 1 із заповненням накопичувача Х 0, при цьому заповнення накопичувача N 1 зберігається.

Результат підсумовування перетворюється в блоці підстановки До і отриманий вектор надходить на вхід регістра R, де циклічно зсувається на одинадцять кроків у бік старших розрядів. Результат зсуву підсумовується поразрядно по модулю 2 в суматорі СМ 2 з 32-розрядних заповненням накопичувача N 2. Отриманий в СМ 2 результат записується в N 1, при цьому старе значення N 1 переписується в N 2. Перший цикл закінчується.

Наступні цикли здійснюються аналогічно, при цьому в 2-му циклі з КЗУ зчитується заповнення Х 1, в 3-му циклі з КЗУ зчитується заповнення Х 2 і т.д., в 8-му циклі з КЗУ зчитується заповнення Х 7. У циклах з 9-го по 16-й, а також в циклах з 17-го по 24-й заповнення з КЗУ зчитуються в тому ж порядку: Х 0, Х 1, Х 2, Х 3, Х 4, Х 5, Х 6, Х 7.

В останніх восьми циклах з 25-го по 32-й порядок зчитування заповнень КЗУ зворотний: Х 7, Х 6, Х 5, Х 4, Х 3, Х 2, Х 1, Х 0.

Таким чином, при зашифрованими в 32 циклах здійснюється наступний порядок вибору заповнень накопичувачів:

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

У 32-му циклі результат з суматора СМ 2 вводиться в накопичувач N 2, а в накопичувачі N 1 зберігається старе заповнення.

Отримані після 32-го циклу шифрування заповнення накопичувачів N 1 та N 2 є блоком зашифрованих даних, відповідних блоку відкритих даних.

Розшифрування зашифрованих даних в режимі простої заміни

Кріптосхеми, що реалізує алгоритм розшифрування в режимі простої заміни, має той же вигляд (див. Рисунок 2), що і при зашифрованими. В КЗУ вводяться 256 біт того ж ключа, на якому здійснювалося зашифрование. Зашифровані дані, що підлягають розшифрування, розбиті на блоки по 64 біта в кожному. Введення будь-якого блоку Т ш = (а 1 (32), а 2 (32), ..., а 32 (32), b 1 (32), b 2 (32), ..., b 32 (32)) в накопичувачі N 1 і N 2 проводиться так, що значення а 1 (32) вводиться в 1-й розряд N 1, значення a 2 (32) вводиться у 2-й розряд N 1, і т.д., значення a 32 (32) вводиться в 32-й розряд N 1; значення b 1 (32) вводиться в 1-й розряд N 2, значення b 2 (32) вводиться у 2-й розряд N 2 і т.д., значення b 32 (32) вводиться в 32-й розряд N 2.

Розшифрування здійснюється за тим же алгоритмом, що і зашифрування відкритих даних, з тією зміною, що заповнення накопичувачів Х 0, Х 1, ..., Х 7 зчитуються з КЗУ в циклах розшифрування в наступному порядку:

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

Отримані після 32 циклів роботи заповнення накопичувачів N 1 та N 2 складають блок відкритих даних.

Т 0 = (a 1 (0), a 2 (0), ..., a 32 (0), b 1 (0), b 2 (0), ..., b 32 (0)), відповідний блоку зашифрованих даних, при цьому значення а 1 (0) блоку Т 0 відповідає вмісту 1-го розряду N 1, значення а 2 (0) відповідає вмісту 2-го розряду N 1 і т.д., значення а 32 (0) відповідає вмісту 32- го розряду N 1; значення b 1 (0) відповідає вмісту 1-го розряду N 2, значення b 2 (0) відповідає вмісту 2-го розряду N 2, і т.д., значення b 32 (0) відповідає вмісту 32-го розряду N 2 .

Аналогічно розшифровуються інші блоки зашифрованих даних.

режим гамування

Зашифрування відкритих даних в режимі гамування

Кріптосхеми, що реалізує алгоритм шифрування в режимі гамування, повинна мати вигляд, наведений на малюнку 3.


малюнок 3

Відкриті дані, розбиті на 64-розрядні блоки Т 0(1), Т 0(2), ..., Т 0(М-1), Т 0(М), зашифровуються в режимі гамування шляхом порозрядного підсумовування по модулю 2 в суматорі СМ 5 з гамою шифру Г ш, яка виробляється блоками по 64 біта, тобто

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

де М - визначається обсягом шифрованих даних.

Г ш(i) - i-й 64-розрядний блок, i = 1 ÷ Ì, число двійкових розрядів у блоці Т 0(М) може бути менше 64, при цьому невикористана для шифрування частина гами шифру з блоку Г ш(М) відкидається.

В КЗУ вводяться 256 біт ключа. У накопичувачі N 1, N 2 вводиться 64-розрядна двійкова послідовність (сінхропосилка) S = (S 1, S 2, ..., S 64), що є вихідним заповненням цих накопичувачів для подальшого вироблення М блоків гами шифру. Сінхропосилка вводиться в N 1 та N 2 так, що значення S 1 вводиться в 1-й розряд N 1, значення S 2 вводиться в 2-й розряд N 1, і т.д., значення S 32 вводиться в 32-й розряд N 1; значення S 33 вводиться в 1-й розряд N 2, значення S 34 вводиться в 2-й розряд N 2 і т.д., значення S 64 вводиться в 32-й розряд N 2.

Початкове заповнення накопичувачів N 1 та N 2 (сінхропосилка S) зашифрована в режимі простої заміни відповідно до вимог пункту 1.3.1. Результат шифрування переписується в 32-розрядів накопичувачі N 3 і N 4 так, що заповнення N 1 переписується в N 3, а заповнення N 2 переписується в N 4.

Заповнення накопичувача N 4 підсумовується по модулю (2 32 -1) в суматорі СМ 4 з 32-розрядної константою З 1 з накопичувача N 6, результат записується в N 4.

Заповнення накопичувача N 3 підсумовується по модулю 2 32 в суматорі СМ 3 з 32-розрядної константою З 2 з накопичувача N 5, результат записується в N 3.

Заповнення N 3 переписується в N 1, а заповнення N 4 переписується в N 2, при цьому заповнення N 3, N 4 зберігається.

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

Для отримання наступного 64-розрядної блоку гами шифру Г ш(2) заповнення N 4 підсумовується по модулю (2 32 -1) в суматорі СМ 4 з константою З 1 з N 6, заповнення N 3 підсумовується по модулю 2 32 в суматорі СМ 3 з константою з 2 з N 5. Заповняти N 3 переписується в N 1, а ми радимо заповнити N 4 переписується в N 2, при цьому заповнення N 3 і N 4 зберігається.

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

У канал зв'язку або пам'ять ЕОМ передаються сінхропосилка S і блоки зашифрованих даних Т ш(1), Т ш(2) ..., Т ш(М).

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

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

Режим гамування зі зворотним зв'язком

Зашифрування відкритих даних в режимі гамування зі зворотним зв'язком

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


малюнок 4

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

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

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

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

Блок зашифрованих даних Т ш(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 розрядів, то з Г ш(М) використовується тільки відповідне число розрядів гами шифру, інші розряди відкидаються.

У канал зв'язку або пам'ять ЕОМ передаються сінхропосилка S і блоки зашифрованих даних Т ш(1), Т ш(2) ..., Т ш(М).

Розшифрування зашифрованих даних в режимі гамування зі зворотним зв'язком

При розшифрування кріптосхеми має той же вигляд, що і при зашифрованими (див. Малюнок 4). В КЗУ вводяться 256 біт того ж ключа, на якому здійснювалося зашифрование Т 0(1), Т 0(2) ..., Т 0(М). Сінхропосилка вводиться в N 1, N 2 так, що значення S 1 вводиться в 1-й розряд N 1, значення S 2 вводиться в 2-й розряд N 1, і т.д., значення S 32 вводиться в 32-й розряд N 1; значення S 33 вводиться в 1-й розряд N 2, значення S 34 вводиться в 2-й розряд N 2 і т.д., значення S 64 вводиться в 32-й розряд N 2.

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

Блок зашифрованих даних Т ш(1) є вихідним заповненням N 1, N 2 для вироблення другого блоку гами шифру Г ш(2). Блок Т ш(1) записується в N 1, N 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, отриманий в результаті блок Г ш(2) підсумовується поразрядно по модулю 2 в суматорі СМ 5 з другим блоком зашифрованих даних Т ш(2). В результаті виходить блок відкритих даних Т 0(2).

Аналогічно в N 1, N 2 послідовно записуються блоки зашифрованих даних Т ш(2), Т ш(3) ..., Т ш(М-1), з яких в режимі простої заміни виробляються блоки гами шифру Г ш(3), Г ш(4), ..., Г ш(М). Блоки гами шифру підсумовуються поразрядно по модулю 2 в суматорі СМ 5 з блоками зашифрованих даних Т ш(3), Т ш(4) ..., Т ш(М), в результаті виходять блоки відкритих даних Т 0(3), Т 0( 4), ..., Т 0(М), при цьому довжина останнього блоку відкритих даних Т 0(М) може містити менше 64-розрядів.

Режим вироблення імітовставки

Для забезпечення імітозащіти відкритих даних, що складаються з М 64-розрядних блоків Т 0(1), Т 0(2), ..., Т 0(М), М≥2, виробляється додатковий блок з l біт (имитовставки І l). Процес вироблення имитовставки единообразен для всіх режимів шифрування.

Перший блок відкритих даних Т 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)) записується в накопичувачі N 1 та N 2, при цьому значення t 1(1) = a 1(1) (0) вводиться в 1-й розряд N 1, значення t 2(1) = a 2(1) (0) вводиться у 2-й розряд N 1, і т.д., значення t 32(1) = a 32(1) (0) вводиться в 32-й розряд N 1; значення t 33(1) = b 1(1) (0) вводиться в 1-й розряд N 2 і т.д., значення t 34(1) = b 32(1) (0) вводиться в 32-й розряд N 2.

Заповнення N 1 та N 2 піддається перетворенню, що відповідає першим 16 циклів алгоритму зашифрування в режимі простої заміни, відповідно до вимог пункту 3.1. В КЗУ при цьому знаходиться той же ключ, яким зашифровуються блоки відкритих даних Т 0(1), Т 0(2), ..., Т 0(М) до відповідних блоки зашифрованих даних Т ш(1), Т ш(2), ..., Т ш(М).

Отримане після 16 циклів роботи заповнення N 1 та N 2, що має вигляд (a 1(1) (16), a 2(1) (16), ..., a 32(1) (16), b 1(1) ( 16), b 2(1) (16), ..., b 32(1) (16)), підсумовується в СМ 5 по модулю 2 з другим блоком Т 0(2) = (t 1(2), t 2( 2), ..., t 64(2)). Результат підсумовування заноситься в N 1 та N 2 і піддається перетворенню, що відповідає першим 16 циклів алгоритму зашифрування в режимі простої заміни.

Отримане заповнення N 1 та N 2 підсумовується в СМ 5 по модулю 2 з третім блоком Т 0(3) і т.д., останній блок Т 0(М) = (t 1(М), t 2(М), ... , t 64(М)), при необхідності доповнений до повного 64-розрядної блоку нулями, підсумовується в СМ 5 по модулю 2 із заповненням N 1, a 1(М-1) (16), a 2(М-1) ( 16), ..., a 32(М-1) (16), b 1(М-1) (16), b 2(М-1) (16), ..., b 32(М-1) (16) . Результат підсумовування заноситься в N 1, N 2 і зашифрована в режимі простої заміни за перші 16 циклів роботи алгоритму. З отриманого заповнення накопичувачів N 1 та N 2 вибираємо відрізок І l = [a 32 l +1(М) (16), a 32 l +1(М) (16), ..., a 32(М) (16 )].

Имитовставка І l передається по каналу зв'язку або в пам'ять ЕОМ в кінці зашифрованих даних, тобто Т ш(1), Т ш(2), ..., Т ш(М), І l.

Надійшли зашифровані дані Т ш(1), Т ш(2), ..., Т ш(М) розшифровуються, з отриманих блоків відкритих даних Т 0(1), Т 0(2), ..., Т 0(М) виробляється имитовставка І 'l, яка потім порівнюється з імітовставки І l, отриманої разом з зашифрованими даними з каналу зв'язку або пам'яті ЕОМ. Що стосується розбіжності імітовставок отримані блоки відкритих даних Т 0(1), Т 0(2), ..., Т 0(М) вважають помилковими.

Значення параметра l (число двійкових розрядів у імітовставки) визначається діючими криптографічними вимогами, при цьому враховується, що ймовірність нав'язування помилкових даних дорівнює 2 - l.