информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 20.10.02 16:27  Число просмотров: 1832
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 22.10.02 12:52  Количество правок: 4
<"чистая" ссылка>
Ниже описана недоработка стандарта, позволяющая злоумышленнику, имеющему доступ к генерации параметров при внедрении продуктов на базе нового ГОСТА ЭЦП [1] задать такие параметры, чтобы можно было подменить подписываемый объект.
Проще говоря, в настоящий момент нельзя подписывать или принимать подписанные в соответствии с новым стандартом документы, полученные от лица формировавшего параметры ЭЦП (или документы, могущие быть точно предсказанными им) если нет доказательства , что эти параметры формировались из случайных чисел.

Как уже отмечалось в предыдущей статье [2], один из основных недостатков нового ГОСТа ЭЦП - недостаточность требований к некоторым параметрам подписи, в условиях отсутствия в нём безопасных способов их генерации. Речь идёт о требовании случайности (доказуемой) к некоторым параметрам подписи.
При этом, авторы ГОСТа не считают( или просто не указывают), что это снижает стойкость метода:
"Криптографическая стойкость данной схемы основывается на сложности задач дискретного логарифмирования… а также стойкости используемой хэш функции (Всё- прим. авт.)" (раздел 4 ГОСТа).
Справедливости ради следует сказать, что этого требования в явном виде нет и в старом стандарте[3], но там задан способ генерации параметров с доказательной случайностью и рядом дополнительных ограничений практически исключающий возможность злоупотребления ими.
Американские коллеги поступили ещё проще: привели готовый набор параметров [4] на все случаи жизни :), чтобы никто кроме них не мог злоупотребить этим.

Ранее [1] уже расказывалось об одном из последствий данного подхода. Ниже будет дан ещё один (надеюсь более убедительный чем ранее) пример, что приведённых в разделе 4 требований к одному из параметров подписи - порядку группы q - недостаточно для стойкой реализации метода( От q требуется быть простым числом E [ 2^254;2^256]).
Здесь и далее в статье использованы обозначения из стандарта.

Описание ошибки.

Нетрудно заметить, что, фактически, подписывается не значение хэша, а остаток от его деления по модулю q: e= h (mod q). Очевидно, что для хэшей удовлетворяющих условию h_(i)=h+q подпись будет выглядеть одинаково.
Разумеется само по себе это использовать нельзя т.к. пока не известен способ получить документ с заданными значения хэш -функции. Но здесь это и необязательно.
Ведь мы имеем возможность выбрать q (и связанные с ним p,m,P)!

Поскольку для большинства документов(программ и т. п.) мы можем создавать практически бесконечное количество корректных вариантов ( варьируя к примеру поля примечаний или пробелы) не составит, например, труда подобрать за разумное время две платёжки, чьи хэши различающиются между собой на простое число t в диапазоне [2^254; 2^256]. (Вероятность попадания на простое число для разности двух случайных хэшей в этом диапазоне примерно 0,4%)
После этого мы принимаем это число (t) в качестве порядка группы q. (Доказать впоследствии, что оно не было получено случайно, невозможно). Остальные параметы, подбираются исходя из этого отправного пункта. Теперь можно послав один из документов, заявить, что посылался другой.

Пример применения:

В банковском деле, схема, отлично применима например при уводе государственных денег (ведь доказать вину бухгалтера будет нельзя) или для имитации кражи денег с целью снижения налогооблагаемой базы. Механизмы, мало отличаются от описанного в прошлой статье [2]. Для лиц, регулярно отсылающих платёжки предсказуемой формы могут быт заранее подготовлены подмены, хотя вероятность этого мала.
Ещё более «перспективные» последствия возможны при работе между удалёнными организациями использующими ЭЦП для заверения передаваемых по e-mail договоров и обязательств (страна-то у нас большая, а почта медленная). В этом случае нередко параметры ЭЦП определяются одной из сторон (по крайней мере этому не было разумных препятствий).

Готовится два договора (обязательства) – один согласованный между сторонами, а второй изменённый в пользу одной из подписывающихся сторон. Второй корректируется до тех пор, пока его хэш не станет отличаться на простое число, как описано выше. После этого параметры ЭЦП публикуются или высылаются надёжным способом (например телеграфом), а подписанный цифровой подписью договор высылается в установленном порядке.
После этого можно предъявлять второй вариант и утверждать, что был подписан и согласован именно он.

С Уважением A. V. Komlin

Литература.
1. Описание ГОСТ 34.19-2001.
http://www.bifit.com/gost3410-2001.zip

2. Механизмы махинации с подписью в новом российском стандарте ЭЦП ГОСТ 34.19-2001.
http://www.bugtraq.ru/library/crypto/moregost.html

3.Описание ГОСТ 34.10-94
http://www.ssl.stu.neva.ru/psw/crypto/gost3410.zip

4. FIPS-2 ( описание DSA, ECDSA и рекомендованные параметры подписи )
http://csrc.nist.gov/publications/fips/fips186-2/fips186-2.pdf
эта ссылка почему-то не всегда срабатывает...

P.S. ВНИМАНИЕ! Уважаемые читатели, прошу Вас не забывать, что этот материал только что выложен и вполне может быть опровергнут в процессе обсуждения.
<theory> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach