Комментарии 41
Какова сейчас ситуация с продвижением ГОСТа в качестве мирового промышленного стандарта? Зарубили окончательно или еще нет?
Судьба ГОСТа сейчас под вопросом даже в пределах нашей страны.
Расскажите подробности?
15/06/2011 Сообщения о взломе блочного шифра ГОСТ 28147-89 в разгар усилий по его международной стандартизации
16/06/2011 Показан первый концептуальный взлом ГОСТ 28147-89 путём дифференциального криптоанализа
12/10/2011 Улучшенная атака на полнораундовый ГОСТ 28147-89
22/11/2011 Полная публикация множественных атак на ГОСТ 28147-89 от Николя Куртуа
12/12/2011 Медведев поручил Путину открыть дорогу иностранной криптографии
16/06/2011 Показан первый концептуальный взлом ГОСТ 28147-89 путём дифференциального криптоанализа
12/10/2011 Улучшенная атака на полнораундовый ГОСТ 28147-89
22/11/2011 Полная публикация множественных атак на ГОСТ 28147-89 от Николя Куртуа
12/12/2011 Медведев поручил Путину открыть дорогу иностранной криптографии
>12/12/2011 Медведев поручил Путину открыть дорогу иностранной криптографии
А вот это очень даже хорошая новость.
А вот это очень даже хорошая новость.
На сколько мне известно, на сегодняшний день, единственным недостатком ГОСТа 28147 является его производительность. Если бы не этот фактор, то никто бы и не суетился.
Лучшей реальной атакой является атака предложенная Takanori Isobe на FSE 2011, сложность которой составляет 2^{225}. Однако 2^{225} достаточно для того, чтобы использовать шифр ещё до 2030 года и дальше (согласно NIST SP800-57 Part1 May2011 (Draft)).
Но сточки зрения теории ГОСТ был взломан, с этим я согласен.
Лучшей реальной атакой является атака предложенная Takanori Isobe на FSE 2011, сложность которой составляет 2^{225}. Однако 2^{225} достаточно для того, чтобы использовать шифр ещё до 2030 года и дальше (согласно NIST SP800-57 Part1 May2011 (Draft)).
Но сточки зрения теории ГОСТ был взломан, с этим я согласен.
Куртуа вообще довольно странный парень. Его публикациям я бы лично не стал абсолютно доверять.
Меня всегда поражало, что практически все гос.структуры, у которых есть порталы с https используют самопальные сертификаты, на которые орут все браузеры.
Просто сложно объяснить начальству, что такое сертификат,
и почему он должен быть подписан корневым УЦ :-).
Столкнулся недавно с одной штукой на таких HTTPS соединениях:
Firefox начиная с 4-й версии отказывается на таких соединениях ставить плагины, начинает проверять сертификаты по цепочке и ругается. Задолбался объяснять, и в итоге пришлось ставить плагин через обычный HTTP.
и почему он должен быть подписан корневым УЦ :-).
Столкнулся недавно с одной штукой на таких HTTPS соединениях:
Firefox начиная с 4-й версии отказывается на таких соединениях ставить плагины, начинает проверять сертификаты по цепочке и ругается. Задолбался объяснять, и в итоге пришлось ставить плагин через обычный HTTP.
Ещё сложнее объяснить, почему «крутая госконтора» должна платить деньги «каким-то буржуям» за подписывание сертификатов, и почему сертификату «каких-то буржуев» верят больше, чем сертификату «крутой госконторы» =))
А единой государственной системы сертификации вроде пока ещё не сделали. Хотят, но пока не замечал особых успехов.
А единой государственной системы сертификации вроде пока ещё не сделали. Хотят, но пока не замечал особых успехов.
Интересно :-). Сам периодически сталкиваюсь с криптографией.
Для полноты картины неплохо добавить в провайдер собственно саму подпись.
А если вы сможете сами реализовывать не обычную ЭЦП, а что нить типа CAdES BES, а еще лучше CAdES X_LONG_TYPE_1 как у Крипто Про, то цены не будет вашему провайдеру.
Собственно из-за усовершенствованной подписи и имеет смысл пользовать Крипто Про и другие платные решения, иначе можно взять випнет и радоваться жизни.
Для полноты картины неплохо добавить в провайдер собственно саму подпись.
А если вы сможете сами реализовывать не обычную ЭЦП, а что нить типа CAdES BES, а еще лучше CAdES X_LONG_TYPE_1 как у Крипто Про, то цены не будет вашему провайдеру.
Собственно из-за усовершенствованной подписи и имеет смысл пользовать Крипто Про и другие платные решения, иначе можно взять випнет и радоваться жизни.
Суть в том, что ваш криптопровайдер не сертифицирован, это и есть основная проблема, как правило.
Всегда думал, а почему бы всем миром не скинуться по копейке и сертифицировать бесплатное открытое криптосредство на ГОСТах..? Если поделить расходы на всех заинтересованных получится реально по копейке.
Сертификация подразумевает не столько деньги, сколько выполнение каких-то требований. Иногда эти требования муторные или мутные, не всякий разберётся и не каждый захочет этой рутиной заниматься.
Я не питаю иллюзий по поводу процедур сертификации в этой стране, но согласитесь, что в конечном итоге все упирается в деньги. Были бы деньги, а разработать и сертифицировать можно что угодно. Сейчас компании тратят просто гигантские суммы только на закупку лицензий таких средств, все ради бумажки — сертификата. Львиная доля из них, кстати, госслужбы, которые тратят деньги налогоплательщиков, таких как мы с вами :(
Мы с Вами живем в одном и той же реальности? — первая же сертификация бесплатного открытого криптосредства уничтожит институт сертификации изнутри.
Сертификацией должно заниматься юрлицо, имеющее лицензии на работу с криптографией, для этого, как минимум, нужно иметь несколько специалистов с профильным образованием в штате. То есть просто скинуться одноразово не получится, даже при наличии готового продукта, нужна постоянная «подпитка» хотя бы этим специалистам по МРОТу чтоб платить.
А зачем?
Ну вот сертифицируете вы CSP для Windows — все равно при каждом встраивании придется получать отдельный сертификат.
Ну вот сертифицируете вы CSP для Windows — все равно при каждом встраивании придется получать отдельный сертификат.
Как минимум потому, что сертификаты выдаются только на бинарник, а в случае выхода новой версии, всю процедуру сертификации придётся запускать сначала.
С год назад мне говорили, что стоимость сертификации криптопровайдера порядка 500.000 рублей, а по срокам может затянуться на многие месяцы, при этом gost из openssl не пройдёт этой сертификации, потому что кроме самой реализации алгоритмов надо выполнить ещё кучу требований навроде защиты от вытаскивания ключей из пямяти процесса.
С год назад мне говорили, что стоимость сертификации криптопровайдера порядка 500.000 рублей, а по срокам может затянуться на многие месяцы, при этом gost из openssl не пройдёт этой сертификации, потому что кроме самой реализации алгоритмов надо выполнить ещё кучу требований навроде защиты от вытаскивания ключей из пямяти процесса.
В точку. В виду текущих требований в гос. проектах (например, проект УЭК) все же используют наши ГОСТовые алгоритмы, более того, используют не OpenSSL, про который писали выше, а именно решения от ифнотекса или крипто про, так как они сертифицированы. А это, в общем-то, создает некоторые трудности.
Ну то есть сам ГОСТ-то вы не написали, а взяли чужую реализацию. Так что это не «написать криптопровайдер», а «подключить реализацию OpenSSL».
Во-вторых, зачем что-то патчить (учитывая, что это нарушение целостности системы, и будет убито произвольным обновлением), когда инфраструктура CSP специально сделана расширяемой? И даже в статье с RSDN, на которую вы ссылаетесь, это описано.
(ну и про сертификацию все правильно сказали, несертифицированное встраивание ГОСТа никому не нужно)
Во-вторых, зачем что-то патчить (учитывая, что это нарушение целостности системы, и будет убито произвольным обновлением), когда инфраструктура CSP специально сделана расширяемой? И даже в статье с RSDN, на которую вы ссылаетесь, это описано.
(ну и про сертификацию все правильно сказали, несертифицированное встраивание ГОСТа никому не нужно)
Насчет «подключить реализацию OpenSSL» — это не проблема, можно использовать любое другое криптоядро, просто был выбран наиболее простой способ для демонстрации криптопровайдера «в исходниках». Интересно, есть ли ГОСТ криптофункции в исходниках где-либо, кроме как в OpenSSL?
Насчет патчить или не патчить, в статье на RSDN в разделе Функция I_CryptGetDefaultCryptProvider из crypt32.dll, есть такие слова: «Необходимо заменить эту функцию таким образом, чтобы при получении нулевого параметра algid она возвращала наш провайдер», а как ее можно заменить, кроме как пропатчить crypt32.dll?
Тут же предлагается использовать для этого библиотеку Microsoft Detours, мной был выбран способ попроще — через WriteProcessMemory, благо патчить нужно свой собственный процесс, загрузив предварительно в пространство процесса библиотеку crypt32.dll через LoadLibrary.
Насчет сертификации — да, это проблема. Я не специалист по сертификации, ничего не знаю конкретно, но думаю, что был бы продукт, а получить для него сертификат — дело десятое.
И кстати, какие гарантии дает наличие сертификата, но отсутствие исходных текстов у некоего абстрактного криптопровайдера, может быть, там где-то сбоку встроен ключ ФСБ, как в Windows встроен ключ АНБ, по крайней мере такие слухи периодически появляются?
Но такие слухи лишены основания, насколько я знаю, ключ АНБ в Windows действительно есть, но это не более, чем один из корневых сертификатов, чтобы АНБ могло использовать в Windows свои собственные криптопровайдеры, не подписывая их в Microsoft.
Кстати, проблема подписывания криптопровайдера в Microsoft не освещена ни в статье на RSDN, ни в данной статье просто потому, что раз мы патчим crypt32.dll, то заодно и пропатчим в advapi32.dll функцию SystemFunction035, которая занимается проверкой наличия подписи в криптопровайдере. По крайней мере, когда эта функция вызывается, то ей на вход идет полный путь DLL-ки с криптопровайдером.
Если кому-то удастся решить проблему с недокументированной I_CryptGetDefaultCryptProvider, например, через реестр и отпадет необходимость патчить crypt32.dll, тогда можно задуматься и о сертификации в Microsoft, чтобы получить от них подписанный криптопровайдер и прекратить патчить SystemFunction035.
Кстати, если установить провайдер Крипто-Про и запустить поиск руткитов GMER, то он найдет кучу пропатченных DLL, не только crypt32.dll и advapi32.dll. Интересно, зачем такое большое количество патчей, неужели все настолько плохо?
Кстати, на форуме Крипто-Про предлагают патчить функцию SystemFunction035, чтобы она возвращала eax=0. Но оказалось, что это неправильно, нужно возвращать eax=1. Интересно, это нарочно сделано, или простая описка?
Насчет патчить или не патчить, в статье на RSDN в разделе Функция I_CryptGetDefaultCryptProvider из crypt32.dll, есть такие слова: «Необходимо заменить эту функцию таким образом, чтобы при получении нулевого параметра algid она возвращала наш провайдер», а как ее можно заменить, кроме как пропатчить crypt32.dll?
Тут же предлагается использовать для этого библиотеку Microsoft Detours, мной был выбран способ попроще — через WriteProcessMemory, благо патчить нужно свой собственный процесс, загрузив предварительно в пространство процесса библиотеку crypt32.dll через LoadLibrary.
Насчет сертификации — да, это проблема. Я не специалист по сертификации, ничего не знаю конкретно, но думаю, что был бы продукт, а получить для него сертификат — дело десятое.
И кстати, какие гарантии дает наличие сертификата, но отсутствие исходных текстов у некоего абстрактного криптопровайдера, может быть, там где-то сбоку встроен ключ ФСБ, как в Windows встроен ключ АНБ, по крайней мере такие слухи периодически появляются?
Но такие слухи лишены основания, насколько я знаю, ключ АНБ в Windows действительно есть, но это не более, чем один из корневых сертификатов, чтобы АНБ могло использовать в Windows свои собственные криптопровайдеры, не подписывая их в Microsoft.
Кстати, проблема подписывания криптопровайдера в Microsoft не освещена ни в статье на RSDN, ни в данной статье просто потому, что раз мы патчим crypt32.dll, то заодно и пропатчим в advapi32.dll функцию SystemFunction035, которая занимается проверкой наличия подписи в криптопровайдере. По крайней мере, когда эта функция вызывается, то ей на вход идет полный путь DLL-ки с криптопровайдером.
Если кому-то удастся решить проблему с недокументированной I_CryptGetDefaultCryptProvider, например, через реестр и отпадет необходимость патчить crypt32.dll, тогда можно задуматься и о сертификации в Microsoft, чтобы получить от них подписанный криптопровайдер и прекратить патчить SystemFunction035.
Кстати, если установить провайдер Крипто-Про и запустить поиск руткитов GMER, то он найдет кучу пропатченных DLL, не только crypt32.dll и advapi32.dll. Интересно, зачем такое большое количество патчей, неужели все настолько плохо?
Кстати, на форуме Крипто-Про предлагают патчить функцию SystemFunction035, чтобы она возвращала eax=0. Но оказалось, что это неправильно, нужно возвращать eax=1. Интересно, это нарочно сделано, или простая описка?
«Необходимо заменить эту функцию таким образом, чтобы при получении нулевого параметра algid она возвращала наш провайдер»
Это нужно только для запроса сертификата, а не для всех криптоопераций.
«Я не специалист по сертификации, ничего не знаю конкретно, но думаю, что был бы продукт, а получить для него сертификат — дело десятое.»
Не специалист. Cертифицировать продукт намного сложнее, чем написать. А для использования в соответствующих местах (а зачем вам еще ГОСТ?) сертификация необходима.
Это нужно только для запроса сертификата, а не для всех криптоопераций.
«Я не специалист по сертификации, ничего не знаю конкретно, но думаю, что был бы продукт, а получить для него сертификат — дело десятое.»
Не специалист. Cертифицировать продукт намного сложнее, чем написать. А для использования в соответствующих местах (а зачем вам еще ГОСТ?) сертификация необходима.
Насчёт никому не нужно я бы поспорил. Есть области использования ЭЦП где обязательной сертификации не требуется, но хотелось бы иметь именно ГОСТовскую реализацию, пускай и не сертифицированную. При юридических разборках это будет полезней, чем какой-нибудь иностранный алгоритм. При экспертизе возьмут документ с подписью, введут его в сертифицированный продукт, установят соответствующие сертификаты, и он покажет (или нет) валидность подписи. Как эта подпись сформирована — дело десятое, чем её проверял контрагент — тем более.
" При экспертизе возьмут документ с подписью, введут его в сертифицированный продукт, установят соответствующие сертификаты, и он покажет (или нет) валидность подписи. Как эта подпись сформирована — дело десятое, чем её проверял контрагент — тем более."
Ах если бы. Если подпись сформирована несертифицированным средством, подписант может отказаться от подписанного документа, ссылаясь на то, что при подписании он видел другой документ. И доказать обратное невозможно.
Ах если бы. Если подпись сформирована несертифицированным средством, подписант может отказаться от подписанного документа, ссылаясь на то, что при подписании он видел другой документ. И доказать обратное невозможно.
Вот так штука! Получается, даже от валидной ЭЦП можно отказаться?
Получается, что можно. Потому что описанная мной атака — это даже не атака, а просто детский лепет, и реализуется в пять минут.
Сертификация — она не просто так.
Сертификация — она не просто так.
Вот пришло ко мне мыло, во вложении два файла — letter.odt и signup.gost :) Подпись соответствует документу. Скажет, что не только подписывал, но и отправлял другой документ, а почтовик подсунул что-то левое, причем не просто левое, но договорился с сайнером о том, то именно?
Для detached-подписи несколько сложнее, потому что документ можно просмотреть отдельно. А вот в случае attached, когда результирующий файл ничем не открывается — можно.
Да и тут, на самом деле, можно сказать, что открыл в программе документ, сказал «подписать и отправить», а уже она сама сформировала письмо, а что в том письме — ни сном, ни духом.
Да и тут, на самом деле, можно сказать, что открыл в программе документ, сказал «подписать и отправить», а уже она сама сформировала письмо, а что в том письме — ни сном, ни духом.
блин, нельзя так пугать!
первый скриншот появился посреди экрана и я долго пытался окошко закрыть!!! 8(
первый скриншот появился посреди экрана и я долго пытался окошко закрыть!!! 8(
Какой-то кривокод. И вообще, вы (или разработчики виндоус) наркоман какой-то, зачем патчить ситемные библиотеки Windows? Тем более драйвером, на ходу? Не объясняется. Может, вы дорогу троянам таким образом открываете. И вносите возможные нарушения в систему, а также потенциальные проблемы при обновлении.
Установку библиотеки лучше бы сделать через regserver или как там это в виндоус принято. OpenSSL стоило бы собирать в виде dll, а не намертво прилинковывать.
Используются глобальные переменные — а в многопоточной среде такой код будет нормально работать?
И вообще, какой-то код кривой, неаккуратный, куча оговорок, куча непонятных мест, например, откуда берутся эти цифры и имена ключей:
> CryptDllFindOIDInfo\1.2.643.2.2.19!1
Неужели в виндоус нет функции типа registerCryptoProvider()? Ведь при первом же изменении в ключах реестра ваш провайдер отвалится.
Вместо того, чтобы нормально собрать OpenSSL, опять какие-то собственные костыли делаете. Это у вас Windows программистов так принято что ли? Все делать по-кривому? Как не увижу код под винду, там всегда какие-то костыли, подчеркивания в именах переменных и прочий треш. И патч системных библиотек драйвером. Да у меня просто слов нет выразить мое возмущение.
А возвращаясь к вопросу, сложно ли написать криптопровайдер — ну да, вполне реально, достаточно 1 разработчика + затраты на сертификацию, просто это никому не нужно, ну не нужно, покупайте платные и не жалуйтесь.
Установку библиотеки лучше бы сделать через regserver или как там это в виндоус принято. OpenSSL стоило бы собирать в виде dll, а не намертво прилинковывать.
Используются глобальные переменные — а в многопоточной среде такой код будет нормально работать?
И вообще, какой-то код кривой, неаккуратный, куча оговорок, куча непонятных мест, например, откуда берутся эти цифры и имена ключей:
> CryptDllFindOIDInfo\1.2.643.2.2.19!1
Неужели в виндоус нет функции типа registerCryptoProvider()? Ведь при первом же изменении в ключах реестра ваш провайдер отвалится.
Вместо того, чтобы нормально собрать OpenSSL, опять какие-то собственные костыли делаете. Это у вас Windows программистов так принято что ли? Все делать по-кривому? Как не увижу код под винду, там всегда какие-то костыли, подчеркивания в именах переменных и прочий треш. И патч системных библиотек драйвером. Да у меня просто слов нет выразить мое возмущение.
А возвращаясь к вопросу, сложно ли написать криптопровайдер — ну да, вполне реально, достаточно 1 разработчика + затраты на сертификацию, просто это никому не нужно, ну не нужно, покупайте платные и не жалуйтесь.
Удивлен, что на просторах Интернета не удалось найти подтверждения, что кем-то был создан интерфейс криптопровайдера ГОСТ под Windows с использованием вышеприведенных инструментов.
ГОСТ нужен только тем, кому нужна сертифицированность СКЗИ.
А тем кому нужна сертифицированность СКЗИ не нужны самодельные криптопровайдеры.
Вот и вся мотивация.
ГОСТ нужен только тем, кому нужна сертифицированность СКЗИ.
А тем кому нужна сертифицированность СКЗИ не нужны самодельные криптопровайдеры.
Вот и вся мотивация.
Если кому интересно: OpenSSL + сертифицированное СКЗИ Рутокен ЭЦП — forum.rutoken.ru/topic/1639/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем ГОСТ криптопровайдер