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

Цифровые подписи и форматы документов в России

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

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

В качестве кандидатов для обмена офисными документами я выбрал:

  • OpenXML
  • ODF
  • PDF
  • XPS

(Первые два - распространенные офисные форматы, два последних - форматы неизменного хранения и распространения).

И вот что получилось:

  • OpenXML - ну, с ним все ясно. Из-за ограничений спецификации XML-DSig, использовать национальные криптоалгоритмы в нем нельзя.
  • XPS - он построен на том же формате контейнера, что и OpenXML. И имеет те же проблемы.
  • ODF - с ним все еще интереснее
    • в ODF до версии 1.2 вообще не было описано использование ЭЦП. Вся криптография была только на уровне шифрования zip-контейнера. Причем, официально версии 1.2 еще пока нет - она находится на рассмотрении соответсвующего комитета OASIS.
    • даже если версия формата ODF 1.2 будет выпущена, она столкнется с теми же проблемами использования цифровой подписи, что и OpenXML, т.к. на текущий момент, там предлагается использовать все тот же XML-DSig.
  • PDF - в спецификации PDF (раздел 8.7.2 Signature Interoperability) указано, что в качестве контейнера используются пакеты на базе PKCS#1 или PKCS#7, но при этом оговаривается лишь использование хэша на базе SHA-* и ассиметричной криптографии на базе семейства RSA.

Так вот, получается, что на сегодняшний день, ни один из перечисленных форматов не поддерживает напрямую внедрение ЭЦП на базе алгоритмов ГОСТ. Если решения и есть, то непредусмотренные стандартами. А других кандидатов на обмен офисными документами как-то не видится.

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

Буду очень признателен за ваши комментарии.

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

ГОСТы в XML-DSig - люди работают
PDF - сделано (только тяжеловато для использования в промышленных масштабах).

Cryptographic Message Syntax (CMS) RFC 5652 или CMS Advanced Electronic Signatures (CAdES) RFC  5126  - и не надо изобратать свой волшебный формат(велосипед)!

Если до сих пор ничего не разработано единого "с интегрированной ЭЦП" - наверное нет в мире в этом потребности.

Конечно, можно взять и сделать свой супермегаправильноудобный формат, только будет он работать в рамках одной системы/программы (например, как в Office 200#) и нигде больше (т.е. есть и плюсы,  и минусы - смотря откуда глядеть :-)).  А корректность встраивания СКЗИ (хотя, конечно, это только косвенно связано с форматом криптограммы)?

P.S. опять же есть RFC 5830 , RFC 5831, RFC 5832

Михаил Романов 02 июня 2010 г. 07:47  
ГОСТы в XML-DSig - люди работают

Как я понимаю, висит еще с 2004 года, но так и не принят?
PDF - сделано

А на сколько это соответсвует формату PDF, и особенно PDF/A? Вы не интересовались случайно (я на сайте не нашел информацию, а ставить и разбираться как оно работает сейчас нет времени)

Если до сих пор ничего не разработано единого "с интегрированной ЭЦП" - наверное нет в мире в этом потребности

А единый и не надо. Другое дело, что все перечисленные мною формты прекрасно умеют работать с внедренной ЭЦП, т.к. это удобно - использовать исходный формат без необходимости оборачивть в дополнительный контейнер только лишь затем, чтобы навесить ЭЦП.
Другое дело, и это уже только проблема России - мы премся рогами против всего мира и настоятельно требуем использовать только свои криптоалгоритмы, которыми в мире кроме нас никто не пользуется. Соответсвенно, и производители ПО не торопятся вводить их поддержку, и в стандарты они не попадают.
Вадим Майшев 02 июня 2010 г. 19:19  
А на сколько это соответсвует формату PDF, и особенно PDF/A?
Не знаток PDF и PDF/A, но с СКЗИ и PDF модулями ГОСТ-подпись в acrobat/reader работает - проверено.
использовать исходный формат без необходимости оборачивть в дополнительный контейнер только лишь затем, чтобы навесить ЭЦП
Так не оборачивайте - кладите криптограмму рядом. Все равно сертифицированные средства ЭЦП нужны не всем, да и не будут у всех, т.е. кому надо - тот проверит и убедится, остальным достаточно увидеть, что "подписано Ивановым И.И. Подпись верна".
мы премся рогами против всего мира и настоятельно требуем использовать только свои криптоалгоритмы, которыми в мире кроме нас никто не пользуется
Такова жизнь. Сильное государство для защиты своих интересов должно опираться на свои алгоритмы и проверенные реализации, а не слепо полагаться на то, что сваяли за кордоном (Вы слышали про ограничения на экспорт оружия/технологий 2 назначения/криптографии).
Alexey Vesnin 09 мая 2012 г. 17:21  

просто в ГОСТ криптографии есть возможность подлога ) Наши ГБшники просто не могут допереть до прочтения не-дырявой криптографии. А внедрять настоящую защиту в современной России - нельзя, откат не возьмешь, и сервис e-Взятки еще не запущен.

Вячеслав Смирнов 09 мая 2012 г. 19:04  
просто в ГОСТ криптографии есть возможность подлога
Возможность слабого шифрования есть везде. Например, есть способы быстрого поиска коллизий в MD5, а не стойкость MD4 уже является фактом. Говорю о хешировании, так как есть алгоритм хеширования ГОСТ и алгоритм шифрования ГОСТ, а в ЭЦП используется и то и другое. Можно при сильном алгоритме выбрать слабый ключ и всё.
 
Если сертификат для подписания использует в качестве алгоритма хеширования MD5, то создание его дубликата вполне возможно. Последними исследованиями в этом направлении можно считать работу Марка Стивенса http://marc-stevens.nl/research/md5-1block-collision/. А значит, часть SSL сертификатов, и возможно, какие-то сертификаты для установки ЭЦП могут быть скомпрометированы в короткие сроки.
 
Размер ключа у алгоритма шифрования ГОСТ такой же как и у других (256 бит), у некоторых утвеждённых алгоритмах других стран он и того меньше. Если выбрать заведомо слабую таблицу замены, то получится слабое шифрование, иначе же, получится нормальное шифрование, слабость которого ещё надо доказать.
 
Можно допустить возможность того, что разработчик приходит к ФСБ и говорит: "Хочу использовать вот такую таблицу замены, сертифицируйте пожалуйста". А ему отвечают: "Такую нельзя, используйте вот эту". И при этом предложенная таблица окажется слабой, а у разработчика не хватит подготовки, чтобы сравнить стойкость. О таких случаях не слышал.
 
Наши ГБшники просто не могут допереть до прочтения не-дырявой криптографии
Вероятно, те кто могут являются медиумами, способными по шифротексту восстанавливать открытый текст.
 
Остальное комментировать сложно, взяток не давал и не брал. Каким образом в этом процессе может участвовать криптография − ума не приложу.
Сейчас обсуждают
Исхаков Роберт 23 января 2017 г. 23:43  
Роберт, разумеется!

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

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

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

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

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

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

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

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

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