информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медSpanning Tree Protocol: недокументированное применениеГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Вы меня неправильно поняли 24.10.02 08:59  Число просмотров: 2146
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 24.10.02 09:07  Количество правок: 1
<"чистая" ссылка>
> Александр, Ваше мнение, что в ГОСТе должно быть прописано
> все, вплоть до действий сотрудников банка, инициализирующих
> систему, понятно. Не вижу смысла это обсуждать.
>
Нет, Вы меня не поняли.

Моё мнение, что в ГОСТе должны быть прописаны полные требования к используемым значениям.

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

Если следовать вашей логике можно и требование к случайности личного и дополнительного ключей опустить. Всё равно их хорошие разработчики случайными сделают.

А если плохие попадутся - то чтож, пользователю не повезло. Не расстраивайтесь они когда нибудь уйдут с рынка

P.S. Конечно я догадываюсь, что при сертификации вопрос выбора параметров поднимется, но может, если бы был грамотно написаный ГОСТ то и сертификация стала бы не нужна? Как например в остальном мире.
<theory>
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 20.10.02 16:27  
Автор: 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. ВНИМАНИЕ! Уважаемые читатели, прошу Вас не забывать, что этот материал только что выложен и вполне может быть опровергнут в процессе обсуждения.
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 22.10.02 16:15  
Автор: pms Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Нетрудно заметить, что, фактически, подписывается
> не значение хэша, а остаток от его деления по модулю q: e=
> h (mod q). Очевидно, что для хэшей удовлетворяющих условию
> h_(i)=h+q подпись будет выглядеть одинаково.
> Разумеется само по себе это использовать нельзя
> т.к. пока не известен способ получить документ с заданными
> значения хэш -функции. Но здесь это и необязательно.
> Ведь мы имеем возможность выбрать q (и связанные с ним
> p,m,P)!

Вот только пользователь не выбирает значения q. Он имеет лишь ключ подписи - целое число d, удовлетворяющее неравенству 0<d<q и ключ проверки - точку эллиптической кривой Q с координатами (x_q, y_q), удовлетворяющей равенству dP=Q.
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 23.10.02 02:59  
Автор: Komlin Статус: Незарегистрированный пользователь
<"чистая" ссылка>
ppm :


Вот только пользователь не выбирает значения q. Он имеет лишь ключ подписи - целое число d …


Начнём с того, что в ГОСТе не регламентируется, кто именно выбирает параметры и ключи подписи (там указываются только отдельные требования к ним (размерность, простота, общедоступность и т.п.) ), так, что это вполне может быть и пользователь.


Стандарт не определяет процесс генерации параметров схемы цифровой подписи
Конкретный … способ … определяется субъектами схемы …


В начале статьи также была явно указана область её применения.


Ниже описана недоработка стандарта, позволяющая злоумышленнику, имеющему доступ к генерации параметров при внедрении продуктов на базе нового ГОСТА ЭЦП [1] задать такие параметры, чтобы можно было подменить подписываемый объект.


Кстати это не регламентировалось и в старом ГОСТе (там явно было указано, что параметры могут создаваться как для группы так и для отдельных пользователей любым согласованным лицом). Не надо смешивать стандарт и его реализации.

Другое дело, что в конкретных реализациях те или иные недоработки ГОСТа могут быть устранены за счёт профессионализма разработчиков , но это никак не красит стандарт.
Пока промышленных реализаций нового ГОСТа практически нет , поэтому рано говорить о их возможностях.
-----------------------------------------------------------------------------------------------------------------

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

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

2-я схема. Предсказание.

После подключения пользователя ему обычно даётся на подпись некоторое контрольное сообщение для проверки существования ключа (см. обсуждения прошлых статей в bugtraq’e).
Если при смене программы заранее подготовить платёжку и контрольное сообщение по описанной схеме ( с хэшами, различающимися на простое число заданного диапазона, и указать разность в качестве q), то после подписания контрольного сообщения сотрудник банка получает и подпись для платёжки.
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 23.10.02 09:13  
Автор: pms Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Впрочем, даже если параметр выбирается для группы
> пользователей например разработчиком или сотрудником банка,
> всё равно существуют схемы позволяющие нанести ущерб.

В ГОСТе и не могут быть прописаны меры, защищающие от несанкционированных действий, например, сотрудника банка, выбирающего начальные параметры при инициализации системы. Это уже относится к области организационных мер.

Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 23.10.02 13:15  
Автор: Komlin Статус: Незарегистрированный пользователь
<"чистая" ссылка>

В ГОСТе и не могут быть прописаны меры, защищающие от несанкционированных действий, например, сотрудника банка, выбирающего начальные параметры при инициализации системы. Это уже относится к области организационных мер

Во-первых защитить несложно именно математически: это было неплохо сделано в старом ГОСТе (доказуемая случайная генерация по установленному алгоритму) или в FIPS-2 (предопределённые параметры пяти разных длин на все случаи жизни :).
Как раз организационные меры здесь более трудоёмки.

Проблема в том, что новый ГОСТ вообще не требует, чтобы параметры выбирались с доказуемой случайностью (или хотя бы просто случайно как k, хотя этого не совсем правильно). Если бы это требование было прописано - проблем не было. Это стало бы головной болью разработчиков(как например требование простоты).
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 23.10.02 13:56  
Автор: pms Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Проблема в том, что новый ГОСТ вообще не требует, чтобы
> параметры выбирались с доказуемой случайностью (или хотя бы
> просто случайно как k, хотя этого не совсем правильно).
> Если бы это требование было прописано - проблем не было.
> Это стало бы головной болью разработчиков(как например
> требование простоты).

Проблема выбора параметров - это и так есть головная боль разработчиков.
В ГОСТе же четко написано: "Стандарт не определяет процесс генерации параметров схемы цифровой подписи. Конкретный алгоритм (способ) реализации определяется субъектом схемы цифровой подписи исходя из требований к аппаратно-программным средствам, реализующим электронный документооборот".

И если разработчик хочет работать на рынке долго, то параметры он будет выбирать надлежащим образом.
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 23.10.02 16:12  
Автор: Komlin Статус: Незарегистрированный пользователь
<"чистая" ссылка>

1) Забота разработчиков - выбор алгоритма, удовлетворяющего требованиям ГОСТа. Обязанность ФАПСИ - дать правильный стандарт, не содержащий ловушек, годный к употреблению без доделок и додумываний. В конце концов они за это деньги получают. В конце концов в програме может быть хороший алгоритм но без доказательных возможностей, и где гарантия, что именно он будет применён. Проверить-то это невозможно.


3) А если конкретный АСУшник банка выберет параметры ненадлежащим (имеется в виду неслучайным) образом, то что с ним будет? Ничего не будет, потому, что он не обязан их так выбирать. Нет такого требования в ГОСТе, нет и нарушения.
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 24.10.02 08:37  
Автор: pms Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Александр, Ваше мнение, что в ГОСТе должно быть прописано все, вплоть до действий сотрудников банка, инициализирующих систему, понятно. Не вижу смысла это обсуждать.

Вы меня неправильно поняли 24.10.02 08:59  
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 24.10.02 09:07  Количество правок: 1
<"чистая" ссылка>
> Александр, Ваше мнение, что в ГОСТе должно быть прописано
> все, вплоть до действий сотрудников банка, инициализирующих
> систему, понятно. Не вижу смысла это обсуждать.
>
Нет, Вы меня не поняли.

Моё мнение, что в ГОСТе должны быть прописаны полные требования к используемым значениям.

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

Если следовать вашей логике можно и требование к случайности личного и дополнительного ключей опустить. Всё равно их хорошие разработчики случайными сделают.

А если плохие попадутся - то чтож, пользователю не повезло. Не расстраивайтесь они когда нибудь уйдут с рынка

P.S. Конечно я догадываюсь, что при сертификации вопрос выбора параметров поднимется, но может, если бы был грамотно написаный ГОСТ то и сертификация стала бы не нужна? Как например в остальном мире.
Вы меня неправильно поняли 25.10.02 09:35  
Автор: pms Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Моё мнение, что в ГОСТе должны быть прописаны полные
> требования к используемым значениям.
>
> Я всего лишь хотел показать, что требование случайности q
> (и точке P см. прошлую статью) так же важно для стойкости
> метода как, например, требование его простоты.
>
> Если следовать вашей логике можно и требование к
> случайности личного и дополнительного ключей опустить. Всё
> равно их хорошие разработчики случайными сделают.

Нет, нельзя опустить требование случайности личного ключа пользователя и Вы это прекрасно понимаете. В ГОСТе описана ситуация, когда документооборот начинается после инициализации параметров и для этого "случайность" q не требуется.

Кстати, если уж предполагать сговор заранее, то кто и как будет проверять, что значение q выбрано случайным образом???
Подмена подписанного документа в новом ГОСТе ЭЦП(черновик) 22.10.02 12:29  
Автор: pms Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Поскольку для большинства документов(программ и т. п.) мы
> можем создавать практически бесконечное количество
> корректных вариантов ( варьируя к примеру поля примечаний
> или пробелы) не составит, например, труда подобрать за
> разумное время две платёжки, чьи хэши различающиются между
> собой на простое число t в диапазоне [2^214; 2^216].
> (Вероятность попадания на простое число для разности двух
> случайных хэшей в этом диапазоне примерно 0,4%)
> После этого мы принимаем это число (t) в качестве порядка
> группы q. (Доказать впоследствии, что оно не было получено
> случайно, невозможно). Остальные параметы, подбираются
> исходя из этого отправного пункта. Теперь можно послав один
> из документов, заявить, что посылался другой.

Вероятность подбора платежки, чей хэш будет равен заданному числу, равна 2^(-256). И подобрать такую платежку невозможно за реальное время.
Вероятность подбора платежки, хэш которой отличается от хэша заданной платежки на число из интервала [2^214,2^216] равна (2^216-2^214)/2^256= 3/2^42~0.68*10^(-12).

Оценить количество простых чисел в интервале [2^214,2^216] можно используя теорему Чебышева о распределении простых чисел, в соответствии с которой для функции p(x) (количество простых чисел, не превосходящих x) справедливы оценки: 0.89q(x) < p(x) < 1.11q(x), где q(x)=x/lnx.
Таким образом, количество простых чисел в интервале [2^214,2^216] равно p(2^216)-p(2^214)>1.11q(2^216)-0.89q(2^214). И вероятность того, что данное число из интервала [2^214,2^216] окажется простым, равна 0,007885.

Так что ни о какой вероятности 0,4% не может быть и речи. Я уж не говорю о времени, необходимом для выяснения простоты числа из интервала [2^214,2^216].
Извините за опечатку, я её уже исправил диапазон q 2^254-2^256 22.10.02 12:43  
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 22.10.02 12:51  Количество правок: 1
<"чистая" ссылка>
Спасибо за замечание там была опечатка

> > собой на простое число t в диапазоне [2^214; 2^216].
> Вероятность подбора платежки, чей хэш будет равен заданному
> числу, равна 2^(-256). И подобрать такую платежку
> невозможно за реальное время

Это и не требуется

> Вероятность подбора платежки, хэш которой отличается от
> хэша заданной платежки на число из интервала [2^214,2^216]
> равна (2^216-2^214)/2^256= 3/2^42~0.68*10^(-12).

Спасибо за замечание. В текст вкралась досадная опечатка
Конечно же речь идёт о диапазоне 2^254; 2^256
Соответственно вероятности 3/4

> Оценить количество простых чисел в интервале [2^214,2^216]
> можно используя теорему Чебышева о распределении простых
> чисел, в соответствии с которой для функции p(x)
> (количество простых чисел, не превосходящих x) справедливы
> оценки: 0.89q(x) < p(x) < 1.11q(x), где q(x)=x/lnx.
> Таким образом, количество простых чисел в интервале
> [2^214,2^216] равно
> p(2^216)-p(2^214)>1.11q(2^216)-0.89q(2^214).
> вероятность того, что данное число из интервала
> [2^214,2^216] окажется простым, равна 0,007885.

См. выше 0,00785*3/4=0,004= 0,4 %
1




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


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