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

[Vitaly Chikunov]

Дмитрий,

Большое спасибо за подробную информацию!

Виталий,

On Wed, Dec 05, 2018 at 10:35:05AM +0300, Дмитрий Державин wrote:
> Вт, 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/Базальт СПО
> _______________________________________________
> oss-gost-crypto mailing list
> oss-gost-crypto at lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/oss-gost-crypto