Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Всё-таки хакером надо родиться. 17.04.02 10:26 Число просмотров: 1094
Автор: VoidErr Статус: Незарегистрированный пользователь
|
Интересно, как у таких как комлин голова устроена? Ну я ещё понимаю,
можно там сообразить про липовые ограничения на диапазоны или случайно нолик попробовать.
Но как можно догадаться подставить (p-y) ?
Или всё подряд пробуется- да ведь жизни не хватит.
АК ответь!
|
|
<miscellaneous>
|
Способ махинации с цифровой подписью на базе российского стандарта ГОСТ Р 34.10-94 17.04.02 05:10
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 17.04.02 05:11 Количество правок: 1
|
Усовершенствованный способ махинации с цифровой подписью на базе российского стандарта ГОСТ Р 34.10-94
<P>
1. Вступление. <p>
С момента публикации <A HREF="http://www.bugtraq.ru/cgi-bin/forum.mcgi?type=sb&b=15&m=43214">сообщения</A> о существовании универсальной подписи "серьёзные люди" не раз упрекали автора, что он поднимает шум, из-за совершенно "безвредной" оплошности в диапазоне проверки значений. Именно поэтому и были опубликованы статьи об их практическом применении, а вовсе не для того чтобы испортить жизнь банкам. Наверное, кто ни будь скоро придумает и другие вариант применения универсальных ключей. Мораль этой истории такова: там где вращаются большие деньги не должно быть, даже "безопасных" на первый взгляд лазеек.
В данной заметке, также, предлагается метод отказа от заверенных документов с помощью ошибки ГОСТа, допускающей существование универсальных подписей, но, по сравнению с <A HREF="http://www.bugtraq.ru/library/crypto/gost.html">первой статьёй</A>, используется более совершенный механизм подделки, не требующий явного применения секретного ключа.
Предыдущий способ имел несколько серьёзных недостатков, вытекающих из невозможности "легально" использовать универсальную подпись, т.к. во первых, подобный набор значений не может быть случайно сформирован программой, во вторых, он содержит в явном виде значение секретного ключа, т.е. должен быть сформирован тем, кто его знает.
Поэтому, перед отсылкой "фальшивой подписи", приходилось вначале каким-либо образом компрометировать, вернее "засвечивать", ключ ( метод "слабой подписи" и т.д.). Это также связанно с определённым риском: во-первых подобный приём чреват встречной атакой ( если сканирование действительно имело место), во вторых программа могла быть написана так, что генерация случайного ключа k=1, невозможна ( например программы "Лан Крипто", имеют ограничение k > =2 ). Кроме того, версия об установке ловушек на значение r=a выглядит не очень убедительно , т.к. шанс удачи очень мал... (Хотя доказать обратное невозможно)
Наилучшим решением сложившейся ситуации было бы нахождение подписи (x',...), пригодной для нескольких документов, не содержащей в явном виде секретный ключ, чтобы можно было сослаться на случайное её формирование самой программой...
2. Краткое описание метода шифрования и ошибки
Напомним вкратце суть предлагаемого ГОСТ Р 34.10-94 метода.
р- простое число, 2^509 < р < 2^512 либо 2^1020 < р < 2^1024 .
q- простое число, 2^254 < q < 2^256 и q является делителем для (p-1)
а- целое число, 1 < а < р-1, при этом а^q (mod p)=1.
...
х- секретный ключ пользователя для формирования подписи.
0 < х < q.
у - открытый ключ пользователя для проверки подписи.
у = а^x (mod p).
...
Процедура подписи сообщения включает в себя следующие этапы:
1. Вычислить h(M) (далее- H)-значение хеш-функции h от сообщения М.
Если h(M)(mod q)=0, присвоить h(M) значение 0255 1.
2. Выработать целое число k, 0 < k < q.
3. Вычислить два значения :
r=a^k (mod p) и r' = r (mod q).
Если r' =0, перейти к этапу 2 и выработать другое значение числа k.
4. С использованием секретного ключа х пользователя (отправителя
сообщения) вычислить значение
s= (xr' + kh(M))(mod q).
Процедура проверки :
1. Проверить условие: 0 < s < q и 0 < r' < q.
Если хотя бы одно из этих условий не выполнено, то подпись считается недействительной.
2. Вычислять h(M1 )-значение хеш-функции h от полученного сообщения М1 .
3. Вычислить значение v= (h(M1 ))^q-2 (mod q)
4. Вычислить значения:z1 = sv (mod q) и z2 = (q-r' ) v (mod q)
5. Вычислить значение u = (a^z1 y^z2 (mod p)) (mod q)
6. Проверить условие: r' = u.
. . .
Давайте повнимательнее посмотрим на фразу "k- целое число, 0 < k < q."
В "DSA", этот диапазон задан требованием о мультипликативной инверсии и s=0 при k=iq, i>=0,
а чем в нашем случае обоснованно это требование? ГОСТом ?!
При внимательном изучении метода, выясняется, что существуют многочисленные частные случаи, наборов (x,p,q) в которых это требование не имеет математической основы. Фактически, его поддержание лежит на добросовестности создателя подписи, т.е. вещи, отвергаемой по определению:) (В самом деле, зачем тогда вообще цифровая подпись нужна?).
Впрочем, мы забежали вперёд. Итак, чем грозит методу отсутствие "физических" ограничений на значение k? Рассмотрим ситуацию с k = 0 (или k кратным q);
r=k^0 =1;
s=(xr+kH) (mod q) = x .
Нетрудно видеть, что в этом случае цифровая подпись не зависит от значений H, т. е. выражение (x,1) может служить подписью к любому сообщению!!!
Доказательства этого утверждения приведены в <A HREF="http://www.bugtraq.ru/library/crypto/gost.html"> предыдущих статьях</A>.
Разумеется, саму по себе эту подпись использовать нельзя, т.к. убедительно объяснить знание посторонним злоумышленником x невозможно, но не торопитесь успокаиваться.
3. Способ примения.
Давайте поподробнее рассмотрим формулу проверки подписи. При внимательном анализе, из неё нетрудно увидеть, что вообще-то существуют несколько вариантов открытых ключей, для которых, при опредёлённых условиях проверка будет выполняться корректно.
Пусть нам дан открытый ключ y. Рассмотрим, чему будет равно проверочное равенство при y1=p-y.
r = (a^z1 (p-y)^z2 (mod p)) (mod q).
Разложим (p-y)^z2 в ряд по формуле Тейлора:
y1^z2= p^z2+ z2*p^(z2-1)*(-y)/1! + z2*(z2-1p^(z2-1)-y)^2/2!+...+ y^z2
или проще говоря p*(...) + y^z2.
Отсюда нетрудно увидеть, что при чётном z2, (p-y)^z2 ( mod p) == y^z2 ( mod p)
Конечно, строгое доказательство этого факта гораздо сложнее и объёмистее, чем наш вывод, но и его нетрудно найти. Нам гораздо важнее следствие:
eсли вместо открытого ключа y (соответствующему x) отослать y1=p-y (соответствующий какому-то x1), то примерно в 50% случаев проверка подписи сообщений будет проходить корректно . С учётом случайности k (r) это значит, что для получения подходящей документу подписи достаточно сгенерировать их несколько раз и проверив подстановкой, выбрать корректные!
Зачем вообще нужна эта головная боль спросите Вы? Затем, что:
1) подпись (x,1) продолжает оставаться универсальной при чётном z2, т.е. для 50% документов;
2) x -не является секретной парой к y2=p-y
3) при паре ключей (x1,y1) набор значений (x,1) может быть получен "легальным" путём.
Таким образом, отослав подобную подпись Вы можете смело заявлять, что отсылалась другая платёжка (счёт, договор и т.д.) , искаженная умышленно или вследствие ошибки при передачи (какая Вам в сущности разница). Почему он прошёл проверку - это проблемы банка ( или разработчиков программы, или сертифицирующей ФАПСИ, или ГОСТа и т.д. ). Ваша задача, быстрее бежать в страховую компанию. Вы ведь не забыли застраховать финансовые операции?
Возникает правда вопрос: как найти x1. Вероятно никак, да и зачем это нужно? Имитировать работу с подобным ключём можно и с помощью x, как описано выше. Доказать, что x не Ваш ключ можно простой проверкой y1 != a^x (mod p). Если же оригинальный ключ зачем-то затребуют, то дискета может и испортиться в процессе передачи. Копий Вы разумеется не оставляли, т.к. отказались от этого ключа сразу же после инцидента. Существует правда риск, что ключу p-y не соответствует корректной пары. Только вот, чтобы доказать это, самым быстрым современным компьютерам потребуется несколько столетий.
4. Дополнения и комментарии .
См. <A HREF="http://www.bugtraq.ru/library/crypto/gost.html"> Механизм мошеничества с цифровой подписью на базе российского стандарта ГОСТ Р 34.10-94 . ч.5. </A>.
Благодарности
Я очень благодарен Д. Леонову, за то, что он рискнул репутацией <A HREF="http://www.bugtraq.ru/"> bugtraq.ru </a> и выкладывал, содержащие ошибки черновые варианты сообщений об ошибке до того, как они прошли широкую проверку, и без регулярно мешявшему их на всё новые и новые версии.
Неоценимую помощь оказали критика и консультации А. Волчкова - президента <A HREF="http://www.libertarium.ru/libertarium/rca"> Российской криптологической ассоциации </a>
Также большое спасибо <A HREF="http://www.firebox.ru"> И. Камолову </a>, Маркову Н. А., Олегу Ф., Радовцеву Д. , Макаровой О., аспиранту ДВО РАН Осиповой М. А., и всем кто присылал замечания и редложения по опубликованным методам.
Полезные ссылки
<A HREF="http://sssr.h1.ru/4GostR34.11-94.htm">1. ГОСТ Р 34.10-94</A>
<A HREF="http://www.bifit.com/gost3410-2001.zip"> 2. ГОСТ 34.19-2001. </A>
<A HREF="http://www.bugtraq.ru"> 3. Bugtraq.ru </A>
<A HREF="http://www.libertarium.ru/libertarium/rca">4. Российская криптологическая ассоциация </A>
<A HREF="http://www.bugtraq.ru/library/crypto/gost.html"> Механизм мошеничества с цифровой подписью на базе российского стандарта ГОСТ Р 34.10-94 . ч.5. </A>.
<A HREF="http://www.pvti.ru/dis.htm"> 5.Ещё одна уязвимость цифровой подписи </A>
С Уважением
<A HREF="mailto:tcsvarka@marine.su">А. В. Кобец (Komlin), avkvladru@mail.ru </A>
Полный вариант статьи
Предыдущая статья
|
|
Всё-таки хакером надо родиться. 17.04.02 10:26
Автор: VoidErr Статус: Незарегистрированный пользователь
|
Интересно, как у таких как комлин голова устроена? Ну я ещё понимаю,
можно там сообразить про липовые ограничения на диапазоны или случайно нолик попробовать.
Но как можно догадаться подставить (p-y) ?
Или всё подряд пробуется- да ведь жизни не хватит.
АК ответь!
|
|
|
подробно о проекте
Анализ криптографических сетевых...
