Журнал о системах электронного документооборота (СЭД)
Электронная цифровая подпись (ЭП)

Об использовании национальных криптоалгоритмов в Office 2010

  3 комментариев Добавить в закладки

В январе этого года, я написал небольшую заметку по мотивам блога Digital Signatures in Office 2010 - О цифровых подписях в Office 2010 (в ней давался небольшой экскурс в организацию ЭЦП в документах OpenXML). На тот момент для меня оставлся неясным вопрос о поддержке Office 2010 малораспространенных в мире криптоалгоритмов, таких, например, наш ГОСТ (на самом деле, это целая серия алгоритмов, но для цифровой подписи используется традиционно только ГОСТ Р 34.10-2001). Именно его я задал в исходном блоге, но ответа так и не дождался, хотя периодически мониторил исходный блог на протяжении еще примерно двух месяцев. Не привнес ясности и ответ Максима Коллегина, который написал, что пока с поддержкой Office 2010 в том же КриптоПро никакой ясности нет.

Каково же было мое удивление, когда пересматривая накопившиеся за несколько неделе записи в RSS-ленте я наткнулся в блоге David LeBlanc на пост DSig Q & A, посвященный как раз ответам на вопросы блога "Digital Signatures in Office 2010", оставшихся без ответа. Что особенно приятно - бы там ответ и на мой вопрос. Однако сам ответ назвать обнадеживающим, увы нельзя.

Итак, в двух словах о том, что написал Девид...

В Office 2010 для хранения используется стандарт XML-DSig, который позволяет указывать используемый криптоалгоритм. Например, вот так указывается алгоритм хэширования:

<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

Для ссылки на алгоритм применяется строка URI, полный список которых можно найти в RFC 4051. Так вот, ни о каком алгоритме ГОСТ, данный стандарт ничего не знает. Более того, в нем не предусмотрено механизмов для простого (т.е. без доработки самого стандарта) механизма для расширения списка поддерживаемых криптоалгоритмов.

В принципе, можно реализовать обходное решение, в котором, используя стороннюю/собственную библиотеку формирования ГОСТ-совместимой подписи, и сгенерирова свой URI (OID) для указания алгоритма, внедрять ее (подпись) в документ самостоятельно, благо все форматы и протоколы известны. Однако проблем у такого решения будет больше, чем положительных сторон:

  • не известно поведет себя сторонее ПО (в первую очередь сам Office), встретив сформированную не по стандарту ЭЦП. В самом простом случае - посчитает ее недействительной, в плохом - посчитает ошибочным весь документ.
  • даже если стороннее ПО в вопросах криптозащиты будет полагаться на некое универсальное API (например, CriptoAPI или CNG), которое в свою очередь, будет использовать URI, полученные от установленных криптопровайдеров, вам все равно нужно будет гарантировать наличие одинаковых (т.е., как минимум, от одного производителя!) криптопровайдеров с поддержкой ГОСТ у каждой стороны.

Только ли в Office проблема?

Увы, далеко нет. Проблемы с использованием национальных (и просто неупомянутых в RFC 4051) алгоритмов будут иметь любые приложения, использующие XML-DSig. На вскидку:

  • все приложения, использующие Open Packaging Conventions. А это форматы .docx, .xlsx, .pptx, .xps, ...
  • приложения, работающие с форматами OpenDocument, т.е. с .odt, .ods, .odp, ...
  • любые web-сервисы, работающие по стеку протоколов WS-*, в частности с WS-Security

И если необходимость использования ГОСТ-криптографии для web-сервисов, пока из области общих теоретизирований (тем более, что всегда можно использовать шифрование на уровне транспорта, а там уже давно проблем нет), то подписание электронных документов - проблема насущная. 

Ещё материалы автора
Похожие записи
Комментарии (3)
Вадим Майшев 01 июня 2010 г. 18:07  

ГОСТы в XML-DSig - люди работают

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

Михаил Романов 14 декабря 2010 г. 09:00  

Максим, такой вопрос: Вадим Майшев (выше) утверждает, что:


здравомыслящему человеку не придет в голову доверяться формированию/проверке подписи в Office


 А как считаете вы?

Сейчас обсуждают
Исхаков Роберт 23 января 2017 г. 23:43  
Роберт, разумеется!

Вадим.  Пощупать и посмотреть УКЭП можно только в рамках системы с использованием средств ЭП. Я ровно тоже могу сказать и о простой электронной подписи). Простая электронная подпись работает в рамках системы, в которой мы договорились, что она может использоваться. Вопрос применения простой ЭП -  это не технологический вопрос, по-моему, это методологический вопрос. (Не знаю, смог ли я правильно сформулировать по-русски))) И простая электронная подпись в СЭД уже давно используется) Например, в "канцелярских сэд" уже давно можно нажимать на кнопочку "Согласовано" при работе с проектом документа. И при надобности можно получить информацию: кто, когда, с какого места нажимал эту кнопочку, и пользователю при запросе можно выдавать в удобном окошечке эту информацию) И привязать нажатие на кнопочку к ЭД в СЭД тоже можно. Но повторюсь, эта ПЭП будет работать в рамках конкретной СЭД, где средством ПЭП будут выступать компоненты СЭД. А вопрос про то, что кем-то вдруг в БД может быть записано про "Васю Пупкина" взамен Пети Уткина я отнесу к организации "доверенной среды". Я нечто подобное могу спросить и про систему где УКЭП используется.

Могут ли жить системы, где используется ПЭП? А почему нет? Вот пример аналогия. У нас в России более 100 млн жителей и у подавляющего большинства из них стоят дверные замки, которые вскрываются за минуты)))  И это -"вскрываются за минуты" совсем не мешает существовать этой системе). И еще пример. Да, действительно, мы иногда пользуемся услугами нотариуса, но в подавляющем большинстве случаев мы используем свою бесплатную рукописную подпись)

Вадим Майшев 23 января 2017 г. 14:31  
Под это определение вполне подпадает поле в базе данных о том, под каким логином заходил пользователь, создавший информацию (например, история в СЭД). Информация в нем получается без использования хэш-функции, но вполне "присоединена" к документу. Неизменность документа при этом не обеспечивает, конечно.

Т.е. если в таком поле БД будет написано "ПЭП=С приветом Вася", то ответственность "за все" будет нести Вася?

А если Вася против того, что в некотором поле БД некто напишет его логин? Он будет правовыми способами доказывать свою непричастность к ЭД. В конечном счете, в суд будете предъявлять запись поля БД? Как докажете связь содержимого поля БД с авторством Васи (для оценки доказательств используется почерковедческая экспертиза традиционных документов и экспертиза действительности электронной подписи для электронных документов)?

Не надо путать аутентификацию в информационных системах и обеспечение юридической силы электронных документов с применением электронной подписи...

Иван Чурбаков 23 января 2017 г. 12:24  
любая электронная подпись - это, прежде всего, "информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию"

Под это определение вполне подпадает поле в базе данных о том, под каким логином заходил пользователь, создавший информацию (например, история в СЭД). Информация в нем получается без использования хэш-функции, но вполне "присоединена" к документу. Неизменность документа при этом не обеспечивает, конечно.

Больше комментариев