Наверх

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

Архив
Время чтения: 2 минуты
4
Цифровые подписи и форматы документов в России

Какой формат офисных документов можно использовать в качестве стандарта межведомственного/внекорпоративного документооборота в России

Пока разбирался с проблемами 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.

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

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

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

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 4

ГОСТы в 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

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

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

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

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

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