Re: [oss-gost-crypto] EC-RDSA and a key substitution attack

["Дмитрий Державин" <dd@basealt.ru>]

Вт, 04 дек 2018, 09:54, Vitaly Chikunov:

>   NOTE 5 The mechanisms of EC-DSA, EC-GDSA. EC-RDSA and EC-FSDSA may be
>   vulnerable to a key substitution attack[10]. […]
>
> Где EC-RDSA это ГОСТ Р 34.10-2001 (а значит и 34.10-2012).
>
> На сколько эта атака актуальна для ГОСТа или это очередной наговор на
> российскую криптографию в стиле Н. Куртуа?

Вопрос неоднократно обсуждался. Например, по-моему, тут:
https://events.yandex.ru/lib/talks/2970/

> Добавить signing key к message не сложно, но я исхожу из того, что
> этого делать не надо, так как в ГОСТе такого нет. Но если бы был
> рекомендованный метод формирования подписи с учетом этой атаки, то
> другое дело.

В общем, это, видимо, и есть рекомендованный метод. Спросил у Смышляева,
вот что он ответил:

«Да, это известное свойство схем на основе конструкции Эль-Гамаля, в
т.ч. нашего ГОСТ Р 34.10.

В российской литературе иногда встречается как "атака Грунтовича".
http://itsec.ru/articles2/crypto/sertifitsirovannye-skzi-chto-nuzhno-znat--chtoby-pravilno-ih-vybrat

Фактически при использовании на практике ландшафт для проведения атаки
создать не удастся по следующим причинам:

1) Сертифицированные СКЗИ не дают возможности через API фиксировать
значение закрытого ключа, он создается только с помощью встроенных
ДСЧ. Хотя, конечно, под отладчиком нарушитель вполне может это обойти.

2) Электронная подпись имеет смысл в документообороте только как ЭП,
формируемая на ключах, на открытые компоненты которых выданы
сертификаты в УЦ (аккредитованном в случае квалифицированной ЭП или УЦ
с внутренним регламентом в случае, например, внутренней подписи в
банке). А УЦ как правило работают по схеме, предполагающей генерацию
ключа на АРМе на территории самого УЦ.

3) На практике в документообороте ЭП применяется не абы как, а в
форматах CAdES, PAdES и пр. - расширенных форматах, предоставляющих
информацию о сертификатах.

4) Массово распространяемая сейчас облачная подпись (см. КриптоПро DSS
или SafeTech myDSS) - средство, которое гарантировано устраняет эту
проблему, так как ключи генерятся в HSM и не извлекаются из него.

Конечно, при всем при этом сама реализация примитива остается как бы
без мер защиты против такого рода атак. Но и применяют ее не в чистом
виде, а в системах. Собственно, защита против подобных атак на систему
и является одним из вопросов, рассматриваемых в процессе сертификации
СКЗИ (с прикладными компонентами) и контроля встраивания в ФСБ России.

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

От себя добавлю, что вариант «2» с генерацией ключа в УЦ выглядит,
по-моему, просто ужасно. В отличие от «3». Кстати, CADES мы умеем
генерировать. Ну почти умеем. ;)

-- 
Дмитрий Державин,
BaseALT/Базальт СПО