Предлагаю собрать воедино все известные факты касательно этого алгоритма и разложить их по полочкам и, наконец, восстановить его.

Вот общий вид алгоритма (см рисунок).
Главные отличия от Comp128-1 это новые секции "Подготовка ключа" и "Подготовка RAND". Все это конечно пока предположительно. Обе функции очень схожи структурно, видимо выполняется один и тот же алгоритм. Время выполнения этих секции составляет примерно половину от времени шифрования, что говорит о том что использован не совсем тривиальный алгоритм. Предположительно алгоритм обеспечивает очень хорошую дисперсию входных данных, что подтверждено экспериментально на RAND. Похоже что изменение одного бита входа ведет к изменению примерно половины битов выхода, причем распределено оно довольно равномерно (но это еще требует проверки).
Обработка ключа происходит в 32 стадии, обработка RAND - в 48. Несколько странно, учитывая что Ki и RAND одинаковой длины.

Так выглядят несколько операций цикла подготовки RAND при всех байтах RAND установленых в ноль. Изменение битов RAND восновном отражается на низкочастотных компонентах сигнала. Высокочастотная "гребёнка" остается почти без изменений.

А нельзя ли. посмотреть кусочек шифрования но на участке по шире?

Похоже что изменение одного бита входа ведет к изменению примерно половины битов выхода, причем распределено оно довольно равномерно (но это еще требует проверки).
Ну. здесь ничего нового. Любая приличная хеш-функция должна этому удовлетворять.

fox: А нельзя ли. посмотреть кусочек шифрования но на участке по шире?
Отчего же нет, можно, конечно.

2 Баньщик: Спасибо что разлочил ветку :-)

PIC-ador: Ну. здесь ничего нового. Любая приличная хеш-функция должна этому удовлетворять.

Ну я в том смысле чта приличная хеш-функция находится еще ДО раундов шифрования. Тоесть перед входом в итерации основного алгоритма.

А это как влияет изменение RAND на выполнение перемешивания.
Первая картинка в RAND все байты нули. Вторая - первый байт FF, остальные нули.

Сейчас кардинально перестраиваю схему, АЦП будет работать на частоте карты и синхронизироваться от её генератора. Уже по первым опытам детализация получается горадо более глубокая и картинки на порядок интереснее.

Как ты смотришь на заявление Мегасим? Тут копошисси, понимашь, а они опа - уже ВСЕ карты всем желающим.. Каково твоё мнение?

Как ты смотришь на заявление Мегасим? Тут копошисси, понимашь, а они опа - уже ВСЕ карты всем желающим.. Каково твоё мнение? П.....ь Не мешки ворочать.....золотые слова !

Главные отличия от Comp128-1 это новые секции "Подготовка ключа" и "Подготовка RAND". Все это конечно пока предположительно.
Меня давно беспокоит один Гондурас:
Чтоб ликвидировать брешь в COMP128v1, вовсе не обязательно переделывать весь алгоритм, можно просто добавить в RAND контрольную сумму. Для старых карт это “фиолетово”, ну а “новые” ее должны проверить, если все O’K, то запускается алгоритм, иначе возвращается этот же (подправленный) RAND или что-то подобное.
Причем даже если известно, как считается контрольная сумма, не поможет. :(
Уже не сформировать RAND’ы дающие коллизию.
p.s. в таком разрезе Опсосу даже не нужно иметь базу по алгоритмам, всего-то только подправить генерацию рандов.

Меня давно беспокоит один Гондурас:
Чтоб ликвидировать брешь в COMP128v1, вовсе не обязательно переделывать весь алгоритм, можно просто добавить в RAND контрольную сумму. Для старых карт это “фиолетово”, ну а “новые” ее должны проверить, если все O’K, то запускается алгоритм, иначе возвращается этот же (подправленный) RAND или что-то подобное.
Причем даже если известно, как считается контрольная сумма, не поможет. :(
Уже не сформировать RAND’ы дающие коллизию.
p.s. в таком разрезе Опсосу даже не нужно иметь базу по алгоритмам, всего-то только подправить генерацию рандов.

Очень и очень дельно!

Дык вот похоже что один гондурас представляет собой перемешивание битов входа (возможно с подмешиванием ключа) и перемешивание ключа. Дальше идет всем известный алгоритм (только вот таблицы надо еще проверить теже ли они). Там конечно могли всунуть подобную проверку, но думаю что действовали более кардинально.

Дык вот похоже что один гондурас представляет собой перемешивание битов входа (возможно с подмешиванием ключа) и перемешивание ключа.
Простое перемешивание ничего не даст, только на время пока не раскусили.
На перемешивание с ключом не очень похоже потому, как
весь алгоритм итак эти занимается, а такой вариант выглядит какой-то “заплаткой”, куда уж лучше мешать, например с IMSI. …Хотя в принципе так тоже можно.

Ну там явно функция которая работает аж половину времени шифрования. Тоесть алгоритм удлинился в 1,5 раза по времени ! Причем там никакой раундности не видно, проводится какая-то равномерная операция с RAND. Причем даже видно на каком этапе какой байт ранд используется. И аналогичная фигня происходит при ресете, только покороче чуть. Структура та же. Так как кроме Ki и RAND больше вроде масивов данных подобной длины нет, то видимо это переработка Ki. Проверить не могу, так как Ki менять не могу. Вообще очень похоже на перемешивание RAND в зависимости от ключа. Кстати этого будет вполне достаточно чтобы ликвидировать bottle-neck алгоритма - малую скорость диффузии и как следистве коллизии на втором раунде.

2Angelex: Т.е. схема будет работоспособна на любых картах без подгонки\подстройки параметров элемнтов схемы?

Я себе такой цели не ставил. Цель понять что изменили в алгоритме и получить код на C :-) А чтобы выковыривать ключ такая сложная схема не понадобится, да и частота будет пониже, думаю и карты звуковой хватит. Причём уже сейчас видно что можно находить коллизии на любом раунде (даже если они не будут проходить наружу). Осталось понять как именно они обрабатывают входы и не поменялись ли таблицы. Таблицы выколупывать это геморой, хотя если удасться получить достаточное разрешение, то впринципе тоже не проблема.

PIC-ador: Простое перемешивание ничего не даст...

Возможно оно не простое, а алгоритм зависит от ключа. Вот тогда даст.

To prcoder
Нельзя ли создать программу которая будет анализировать график энергопотребления карты(сравнивать с предыдущим при выполнении а3а8 ) и сопрячь ее с программой-сканером типа Ворон-скан?

Да это какраз я думаю не проблема. Да и ключ извлечь из всех карт что я видел можно за гораздо меньшее количество запросов. Универсальное устройство тоже можно сделать, но понадобится прилично времени чтобы собрать данные по диапазону изменения характерисик карт и вообще по характеру реализации алгоритма. Только у меня цель другая, такчто я просто меняю схему под конкретную кару.

Prcoder, а какой ты свой АЦП юзаешь? Можно схему? А то что-то у меня карты не хотят запускаться ниже 1.5кгц...сам генератор пашет...
А для анализа саундблястером это конечно не идет

Практически все карты (за очень редким исключением) можно запустить на частоте 600-700 кГц. Такчто смотри форму сигнала на выходе генератора.

А ХЗ какая там форма... Осцилографа не имею... Проверял двумя диодами+стрелочник..Генерация есть.. Генератор по схеме от дежановского ридера...

Да ты не парься, на высокую частоту возьми генератор готовый кварцевый, а если надо пониже, то и на PIC-е собрать можно. А уж на каком-нить Ubicom SX можно наверное и на высокую, правда сам еще не пробовал, пока в руки не попали.

Da na vysokuyu i 2x invertorov s kvarcem hvataet :) vse pashet..A vot na nizkuyu pridetsya sobirat` na PICe...

PS. Nedavno spalil svoj device:) pridetsya novyj delat` uzhe po chelovecheski ;)

А чегобы просто не поделить высокую, скажем на 16 ?

a potom delitel`?

2unixoid: Мы с тобой вроде поняли что алго в KS и Мос. Мегафоне очень похожий по рисунку. Давай картиночки тут характерные разместим чтобы народ тоже мог посмотреть.

Мне так видится что разница между v1 и v2 во-первых в том что в v2 после последнего раунда всёравно делается перестановка, а во-вторых, что самое главное, перед подачей на вход алгоритма comp RAND обрабатывается какой-то пермутацией, предположительно зависящей от ключа оператора. Я так подозреваю (по огромной скорости диффузии) что это какая-то БПФ-подобная функция.

Давай..Сегодня вечером положу свои, а то они дома...
И мож седня днем еще карточек возьму поюзать ;)

Общий вид алгоритма в картах KS от Unixoid-a. Тоже видно восемь раундов по пять сабраундов + пермутация. Однако той длительной байды после засылки RAND вроде бы нету. Из этого можно сделать предположение что алгоритм несколько отличный и в нём врядли есть хорошее перемешивание перед первым раундом. Но похоже что это тоже каким-то образом модифицированиый Comp128-1.

Вид одного раунда алгоритма.

Похоже что вычитание счётчика выполняется сразу после выполения команды еще до отсылки RAND. Это наверное тот сильный всплеск в начале, но там произошло некторое зарезания и большие искажения поэтому укрупнённо не привожу. Зато прилагается вавка.

Чтото у меня не получилось ту зарезку убрать...Ставил резюк и на 10k - просто мало гейна, а посылки байтов не видно....Это только одна такая карта...
Седня,если еще удастся ее взять - попробую без AD623... Мож она такая иесть....

К стати да, я тож заметил,что той бороды нету...
Всего скорее так и есть - 8 раундов и в последнем тоже пермутация..
К стати, смотрел на конец алго(всех,что у меня есть, кроме лайфа) - концовки похожие..тоесть формирование выхода всего скорее осталось как у в1...та же компрессия...

Блин,странные циклы какие-то в этом алго... в в1(да и не только) четко видно,что выполняется алгоритм,разные операции там итд...А тут вроде все время выполняется один и тот же набор операций...
не защита ли это?

Чтото у меня не получилось ту зарезку убрать...Ставил резюк и на 10k - просто мало гейна, а посылки байтов не видно....
А Может и ПДФку по АD623 не докурил :))

Unixoid: А Может и ПДФку по АD623 не докурил Smile)
Наверняка второпях раскуривал ;-) У многих поначалу не так усиливает :-) Ну операций на такой частоте особо не видно, вообще похоже оно на v1, но есть некоторые аномальности. Больше всего меня напрягает эта сверхдлительная пермутация после раунда. Она длиной как весь алгоритм ! Это явно не нормально. В v1 она вчетверо короче и на моём несканящемся мегафоне тоже, но там своя борода есть :-)

da,v toropjah :)
u menya tozhe po nachalu ne tak usilivalo:)
O permutacii v principe soglasen..i eshche tut tozhe netu /* Permutation but not on the last loop */

Картинка алгоритма в М.Мегафоне полученая через АЦП.
Если сравнить с первой, очень заметно сколько информации теряется проходя через нелинейные элементы звуковой карты.
Усиление настроено так чтобы небыло зарезания.

Начало GET RESPONSE вблизи. Так, для наглядности.

А вот как выглядит вблизи декрементация счечика (три таких импульса). Правда иногда их бывает и пять. И чтобы понять какое теперь разрешение стало (вавка с дискретизацией 669600 Гц) вот маленький кусочек который выглядит как жирная полоска во фронте первого импульса.

А вот сам алгоритм с бОльшим усилением. Хорошо видно соотношение энергопотреблений разных операций. Правда нижнюю часть пришлось подрезать.

Вот еще большее усиление. Пришлось добавить еще один ИУ иначе усиления нехватает. На картинке восемь раундов алгоритма.

Хммм...Получается алго в карте поделен на части...
А от куда умозаключение, что операция после 5го байта апду - подготовка ключа?
в некоторых в1 картах тоже что-то подобное есть после 5го байта апду...
По моему туда смотреть пока не надо...Вот я боюсь,что сами раунды переделаны...и таблицы...
Но по всей видимости выход у этого алго тоже 4х битный,тк формирование SRES+Kc для в1 карт и для несканящихся очень похожее...это даже видно на SB:)
Попробуй сравни у себя на АЦП...

Ну возможно с "подготовкой ключа" я и поторопился. Вывод сделан на основе того что операция очень похожа на пермутацию RAND, но от RAND никак не зависит. Подготовку RAND я проверял, она равномерно коррелирована с битами RAND. Сегодня по-внимательнее посмотрю обе эти операции. На большом разрешении по частоте стало видно структуру операций в подготовке RAND. Внимательно сравню с подготовкой ключа, а там и решим она это или нет, да может и поймём что там делается.

Ну возможно с "подготовкой ключа" я и поторопился.
APDU еще принять надо, проверить на корректность параметров и т.д.
Подай другую команду, например SELECT и сравни.

Конечно смотрел. Эта фигня только после RUN GSM ALGORITHM получается. Все остальные команды обрабатываются быстрее. Обработка похожа, но у этой еще есть кусок довольно длительный. Такчто я сделал вывод что это предположительно пермутация Ki. На Ki повлиять не могу, поэтому проверить так это или нет довольно сложно.

2PIC-ador: Проверка АПДУ осуществляется нескольими коммандами...и ессно их на саундбластере не увидишь...а тут идет како-то цикл, и не простой....хотя х3 :)

2prcoder:
В КСах вычитание счетчика идет после посылки РАНД. Проверял вчера..убивал недавно карту с таким же АТРом, и пробовал этой карту тупо APDU подавать и после этого(без посылки ранда) ресет...70 тыс прогнал - живет:)

Ну я несколько сомневаюсь с декрементом в средине алго...xотя все могли накодить :)
Но не видно ранее обращений к ЗУ...так что тоже хз...а счетчик в твоей карте точно есть? ;)

О 5-м байте АПДУ: когда он подается, то карта сразу переходит в режим ожидания данных, тогда начинается изменение в энергопотреблении, можно долго ждать и картинка без изменений все это время. Я это наблюдал вне зависиомсти от АПДУ.

a, da...
eto ja tozhe kogda-to nablyudal na kartah Gemplus...takoj harakternyj shum stoit posle 5go byta APDU....

А вот так выглядит алгоритм в SilverCard. Только снять его оказалось значительно сложнее так как потребление карты на порядок меньше стандартных симок.

А так выглядит comp128-1 в старых картах MTS

А кто-то говорил о том, что сильверы жрут больше обычных симок. Здрасти.

Konstantin,eto sovsem raznye veshchi...
Silver,te sami mikruhi zhrut mozhet i bol`she,no sam proc navadok na pitane daet men`she....Toest` razmah men`she u nego...

nuken: О 5-м байте АПДУ: когда он подается, то карта сразу переходит в режим ожидания данных, тогда начинается изменение в энергопотреблении, можно долго ждать и картинка без изменений все это время. Я это наблюдал вне зависиомсти от АПДУ.

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

PIC-ador, nuken, unixoid: Спасибо что обратили внимание. Похоже и правда те пилы не обрабока rand и ki, а просто цикл ожидания карты. Они действительно встречаются и во время ресета и при выполнении других команд, просто в этой команде она особо длинная. Возможно я плохо измерил корреляцию этой пилы со входом, разрешение было маловато. Вообще получается корреляции там быть недолжно. Разрешения хорошего и SNR я добился, остались некоторые мелочи. Как доделаю попробую промерить снова. Но факт что корреляция входа должна быть или с первым раундом или с чем-то до него. Кудато же эти данные деваются...