Защита XML-документов при передаче по открытым коммуникациям

Антон Тульчинский

Формат XML сегодня

Потребность в защите XML-документов

Общие сведения об электронной цифровой подписи

   ЭЦП и возможность ее подделки

   Центр сертификации

   Формирование и проверка ЭЦП

   Хэш-функции

Общие сведения о шифровании

   Шифрование данных и его отличие от ЭЦП

   Взлом

   Электронная цифровая подпись XML-документов

   Спецификации на ЭЦП XML от W3C

   Тэг <Signature> — подпись XML

   Проверка ЭЦП XML

   Спецификации W3C о шифровании XML

   Тэг <EncryptedData>

   Процесс зашифрования и дешифрования

   Реализация защиты XML-документов

   XML Security Suite (IBM)

   XML Security (Apache)

Защита данных на основе XML

   Язык разметки заявлений системы безопасности (SAML)

   Спецификация управления ключами XML

Федеральный закон «Об электронной цифровой подписи»

   Цели

   Условия равнозначности ЭЦП и обычной подписи

   Сертификаты и удостоверяющие центры

   Закрытые (секретные) ключи

Отечественные стандарты на алгоритмы ЭЦП

   Схема Эль-Гамаля

   Эллиптическая кривая

   Ссылки Электронная цифровая подпись XML-документов (спецификации W3C)

   Шифрование XML-документов (спецификации W3C)

   Пакеты (реализации) защиты XML

   Другие ресурсы

 

Несколько слов о защите данных при применении Web-сервисов XML

Формат XML сегодня

ХML, или расширяемый язык разметки (eXtensible Markup Language), в настоящее время становится стандартным способом транспортировки информации в Web (и не только). Более того, появляются все новые и новые надстройки, в которых применяется синтаксис XML (XML-приложения). Например, к таковым относится упрощенный протокол доступа к объектам SOAP (Simple Object Access Protocol), в котором XML выступает в качестве универсального средства представления параметров вызова удаленных процедур RPC (Remote Procedure Call). Другим примером надстройки является оболочка описания ресурсов RDF (Resource Description Framework). Можно заглянуть на сайт консорциума World Wide Web (W3C), разрабатывающий стандарты в этой области (http://www.w3.org/), и убедиться, что языку XML действительно уделяется повышенное внимание.

Напомним, что основным назначением XML является описание структуры и семантики документа. Основным преимуществом XML по сравнению с другими форматами электронных документов является то, что в нем описание внешнего представления документа отделено от структуры документа и его содержания. XML является гибким языком, который можно использовать для различных целей, при этом он способен обеспечить взаимодействие со многими системами и базами данных. Таким образом, уже сегодня XML используется во многих информационных системах в качестве основного формата обмена данными. Более того, мощный шаг навстречу XML сделали производители систем управления базами данных. Например, корпорация Oracle выпустила утилиту XSU (XML-SQL Utility), которая является надстройкой над JDBC, позволяющей сохранять XML-данные в базе данных и извлекать их оттуда (http://otn.oracle.com/tech/xml/xdk_java/content.html). XSU представляет собой иерархию Java-классов, предназначенную для трансформации данных из таблиц и представлений (views) объектно-реляционной базы данных в формат XML, вставки данных из XML-документов в таблицы и представления и других полезных операций.

Потребность в защите XML-документов

ХML — мощное средство, часто применяемое для обмена данными через Интернет. Но, к сожалению, само по себе оно не обеспечивает необходимую защиту данных, которые «перевозит». Иными словами, существуют серьезные проблемы безопасности при применении формата XML (как, впрочем, и при использовании других форматов).

XML может быть легко использован для передачи сообщений-транзакций между банком и банкоматом, конфиденциальных или полуконфиденциальных сведений о физических лицах, сведений об электронных сделках или просто для передачи закрытых документов в этом формате. Но при этом нужно обеспечить защиту информации от непроизвольных или намеренных искажений как со стороны пользователей информационных систем, так и при передаче по каналам связи. Защита должна быть основана на выполнении следующих функций:

  • аутентификации взаимодействующих сторон;
  • подтверждении подлинности и целостности информации;
  • криптографическом закрытии передаваемых данных.

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

Общие сведения об электронной цифровой подписи

ЭЦП и возможность ее подделки

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

Проверка электронной цифровой подписи блока информации проводится путем криптографического преобразования ЭЦП с помощью соответствующего секретному ключу открытого ключа, участвовавшего в процессе установки ЭЦП.

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

Центр сертификации

Выше мы упоминали термины «секретный ключ» и «открытый ключ». Откуда взялись эти ключи? Их формирует центр сертификации — некоторая структура (организация), которая занимается управлением сертификатами. Сертификат открытого/закрытого ключа представляет собой следующую совокупность данных:

  • имя субъекта или объекта системы, однозначно идентифицирующее его в системе;
  • открытый/закрытый ключ субъекта или объекта системы;
  • дополнительные атрибуты, определяемые требованиями использования сертификата в системе;
  • электронная цифровая подпись издателя (центра сертификации), заверяющая совокупность этих данных.

Таким образом, к примеру, сертификат закрытого ключа содержит собственно закрытый ключ и дополнительные сведения к нему.

Каждому зарегистрированному пользователю информационной системы сертификационный центр (СЦ) формирует два сертификата — сертификат закрытого ключа и сертификат открытого ключа. При этом первый СЦ выдает лично в руки зарегистрированному пользователю (например, на дискете) и никому другому — это и есть «подпись». Второй сертификат — открытый — СЦ публикует в общедоступном хранилище, чтобы любой заинтересованный мог легко его найти.

Формирование и проверка ЭЦП

Отправитель информации с помощью секретного ключа и заранее выбранного по договоренности между абонентами асимметричного алгоритма (алгоритма ЭЦП) шифрует передаваемую информацию, представленную в цифровом виде, и таким образом получает цифровую подпись данных. Далее отправитель информации по открытому каналу связи посылает незашифрованную информацию и полученную вышеописанным способом цифровую подпись получателю.

Получатель сообщения с помощью открытого ключа (который общедоступен) и выбранного по договоренности между абонентами алгоритма ЭЦП рассекречивает цифровую подпись. Далее он сравнивает принятую им незашифрованную информацию и информацию, полученную при расшифровке цифровой подписи. Если цифровая подпись не была подделана и передаваемая открытая информация не искажена, то эти две информации должны полностью совпасть. Если подпись подделана, то принятая открытая информация и информация, полученная при дешифровании, будут существенно различаться (рис. 1).

Хэш-функции

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

Используемая хэш-функция должна уметь преобразовывать сообщение любой длины в бинарную последовательность фиксированной длины. Кроме того, она должна удовлетворять следующим требованиям:

  • сообщение после применения хэш-функции должно зависеть от каждого бита исходного сообщения и от порядка их следования;
  • по хэшированной версии сообщения нельзя никакими способами восстановить само сообщение.

Общие сведения о шифровании

Шифрование данных и его отличие от ЭЦП

Шифрование информации — взаимно-однозначное математическое (криптографическое) преобразование, зависящее от ключа (секретный параметр преобразования), которое ставит в соответствие блоку открытой информации, представленной в некоторой цифровой кодировке, блок шифрованной информации, также представленной в цифровой кодировке. Шифрование объединяет два процесса: зашифрование и расшифровку информации (рис. 2).

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

Взлом

Теоретически любой шифровальный алгоритм с использованием ключа может быть вскрыт методом перебора всех значений ключа. Если ключ подбирается, требуемая мощность компьютера растет экспоненциально с увеличением длины ключа. Ключ длиной в 32 бит требует 232 (около 109) шагов. Такая задача под силу любому дилетанту и решается на домашнем компьютере. Системы с 40-битным ключом (например, экспортный американский вариант алгоритма RC4) требуют 240 шагов — такие компьютерные мощности имеются в большинстве небольших компаний. Системы с 56-битными ключами (DES) требуют для вскрытия заметных усилий, однако они могут быть легко вскрыты с помощью специальной аппаратуры. Стоимость такой аппаратуры значительна, но доступна для мафии, крупных компаний и правительств. Ключи длиной 64 бит в настоящий момент, возможно, могут быть вскрыты крупными государствами, а уже в ближайшие несколько лет будут доступны для вскрытия преступным организациям, крупным компаниям и небольшим государствам. Ключи длиной 80 бит могут стать уязвимыми в будущем. Ключи длиной 128 бит в обозримом будущем, вероятно, останутся недоступными для вскрытия методом перебора. Можно использовать и более длинные ключи.

Однако длина ключа — это еще не все. Многие шифры можно вскрыть, не перебирая всех возможных комбинаций, а применяя специальный алгоритм (например, с полиномиальной сложностью). Вообще, очень трудно придумать шифр, который нельзя было бы вскрыть при помощи другого способа, более эффективного, чем перебор.

Обратите внимание, что степень надежности криптографической системы определяется ее слабейшим звеном. Нельзя упускать из виду ни одного аспекта разработки системы — от выбора алгоритма до политики использования и распространения ключей.

Электронная цифровая подпись XML-документов

Работающие с XML уже давно поняли важность механизма контроля над данными, передаваемыми и представляемыми в XML. Основные требования, предъявляемые к передаваемым данным, — аутентификация взаимодействующих сторон и подтверждение подлинности и целостности информации в XML-документе. Такие задачи решает ЭЦП XML-документов.

Спецификации на ЭЦП XML от W3C

Консорциум W3C разрабатывает сейчас спецификацию «XML — Signature Syntax and Processing» («Синтаксис и обработка подписи XML») и другие связанные с этим документы. Пока она имеет статус рекомендации (http://www.w3.org/TR/xmldsig-core/). Этот документ предусматривает подпись как всего XML-документа, так и его части. Для взаимооднозначности процесса подписания XML определяется понятие канонического представления XML-данных. Например, в XML-документе тэги, стоящие на одном и том же уровне в дереве иерархии, могут перемешиваться между собой, создавая таким образом неоднозначность для процесса подписания. Каноническое представление XML — это своеобразная сортировка (а точнее, приведение к простейшему виду), не допускающая таких вольностей. Методы и правила канонизации XML описываются в отдельном документе — «Canonical XML» (http://www.w3.org/TR/xml-c14n), который также имеет статус рекомендации. Другие связанные с подписанием XML-документа материалы доступны по адресу: http://www.w3.org/Signature/.

Тэг <Signature> — подпись XML

Рекомендация «XML — Signature Syntax and Processing» определяет, что подпись и информация о ней должны содержаться в тэге <Signature>, который имеет следующие части (в основном они нужны для верификации подписи):

  • метод канонизации (CanonicalizationMethod) определяет конкретный набор правил для упрощения и структурирования экземпляра XML до подписания. Эти сведения обеспечивают надлежащий вид подписываемых данных, чтобы алгоритм проверки дал положительный результат, если содержательные данные не были изменены;
  • метод подписи (SignatureMethod) определяет алгоритм подписи дайджеста сообщения. Дайджест сообщения — это уникальная символьная строка фиксированного размера, она является результатом обработки данных с помощью односторонней хэш-функции, задаваемой методом дайджеста;
  • метод дайджеста (DigestMethod) — алгоритм составления дайджеста сообщения, подписываемого с помощью заданного метода подписи. Задание определенного метода дайджеста гарантирует обработку данных одним и тем же способом;
  • значение дайджеста (DigestValue) — собственно дайджест сообщения, то есть строка фиксированной длины, выдаваемая в результате обработки данных с помощью алгоритма дайджеста. Такая строка является уникальной и необратимой: ее практически невозможно получить из другого содержимого, как и невозможно воссоздать по ней исходные данные. Это как бы отпечаток пальцев для подписываемых данных; положительный результат сравнения значений дайджеста гарантирует целостность содержимого;
  • непосредственно подпись (SignatureValue) — это данные, получаемые после обработки методом подписи;
  • информация о открытом ключе (KeyInfo) — ключ для верификации ЭЦП. Точнее, не ключ, а сертификат, потому что в нем, кроме самого ключа, могут быть указаны имя владельца и алгоритм ЭЦП.

Естественно, что это не исчерпывающая информация о том, что может содержаться в тэге <Signature>. Вот простейший пример такой подписи (листинг 1).

Формирование ЭЦП XML

Следует отметить некоторые отличия процесса подписания XML от классического. Дело в том, что процесс подписания экземпляра XML начинается с канонизации, то есть с упрощения структуры данных. Как уже было сказано, эта процедура необходима для того, чтобы для одного и того же XML-документа, представленного по-разному, можно было корректно верифицировать ЭЦП. Это означает, что перед подписанием необходимо все XML-документы привести к единой канонической форме. Дальнейшие действия аналогичны стандартному процессу добавления цифровой подписи: для данных создается значение дайджеста с помощью заданного метода, затем это значение подписывается закрытым ключом автора документа.

Проверка ЭЦП XML

Для проверки подписи нужно выполнить два шага: проверку самой подписи и проверку значения дайджеста.

Сначала проверяется сама подпись, чтобы обеспечить аутентификацию ее владельца и предотвратить отказ от авторства. Затем происходит проверка значения дайджеста, чтобы убедиться, что данные не изменились, и подтверждается целостность содержимого XML-документа.

ШифрованиеXML-документов

Спецификации W3C о шифровании XML

Перейдем к шифрованию, которое позволяет нам закрыть (то есть преобразовать в такой вид, при котором будет непонятен смысл) передаваемые данные и восстановить их на принимающей стороне. В консорциуме W3C создана рабочая группа (http://www.w3.org/Encryption/2001/), которая специально занимается вопросами шифрования XML-данных. Спецификация «XML — Encryption Syntax and Processing» («Синтаксис и обработка шифрования XML») сегодня получила статус рекомендации и доступна по адресу: http://www.w3.org/TR/xmlenc-core/.

Тэг <EncryptedData>

Тэг <EncryptedData> в XML-документе рекомендуется использовать для шифрования данных. Он содержит следующие сведения:

  • метод шифрования (EncryptionMethod) описывает алгоритм шифрования данных. Если этот тэг отсутствует, то алгоритм шифрования должен быть известен принимающей стороне, иначе расшифровка сообщения невозможна;
  • шифрованные данные (CipherData) — собственно зашифрованные данные или ссылка на их местоположение. Разнообразие подлежащих шифрованию типов данных и методов их логической организации практически ничем не ограничено;
  • информация о ключах (KeyInfo) — сведения о ключах, с помощью которых выполняются шифрование и соответственно дешифрование. Они могут храниться в другом месте и заменяться в экземпляре XML на ссылку URL;
  • другая информация (например, о предполагаемых получателях).

Пример тэга <EncryptedData> представлен на листинге 2.

Процесс зашифрования и дешифрования

Шифрование данных XML производится традиционными методами криптографии с открытыми ключами. Сначала шифруются сами данные, как правило, с помощью случайно формируемого секретного ключа, который затем тоже кодируется — при помощи открытого ключа предполагаемого получателя. Эта информация упаковывается так, чтобы извлечь секретный ключ и расшифровать данные мог только указанный получатель. Для дешифрования секретного ключа применяется скрытый ключ, а затем происходит дешифрование данных с помощью найденного секретного ключа.

Реализация защиты XML-документов

Мы рассмотрели общие принципы работы электронной цифровой подписи и спецификации, которые выработал консорциум W3C в этой области. Все это хорошо, но что если действительно имеется потребность в реализации описанных схем защиты XML-данных?

Уже сегодня, несмотря на то что стандарты W3C появились совсем недавно, некоторые компании объявили о выпуске своих пакетов (библиотек классов), реализующих и ЭЦП, и шифрование. Рассмотрим возможности некоторых из них.

XML Security Suite (IBM)

Этот пакет, основанный на языке программирования Java, доступен по адресу http://www.alphaworks.ibm.com/tech/xmlsecuritysuite. XML Security Suite является средством, обеспечивающим такие элементы безопасности, как цифровая подпись, шифрование и управление доступом для документов XML. С его помощью можно добиться больших успехов, нежели используя возможности протоколов безопасности транспортного уровня (например, Secure Sockets Layer, SSL).

Этот пакет реализует три технологии:

  • ЭЦП основана на спецификации «XML — Signature Syntax and Processing» от W3C и IETF (и на спецификации «Canonical XML»);
  • шифрование реализовано на основе спецификации «XML — Encryption Syntax and Processing» от W3C;
  • управление доступом для документов XML (XML Access Control Language).

XML Security Suite — это одно из лучших современных средств для защиты XML-документов. Кроме самого архива (JAR) с библиотекой классов, оно включает подробную документацию и примеры, позволяющие быстро сориентироваться в иерархии классов.

XML Security (Apache)

Проект XML Security от Apache (http://xml.apache.org/security/) — это также реализация стандартов в области защиты XML. В настоящий момент он включает реализации для спецификаций «Canonical XML» и «XML — Signature Syntax and Processing». Это означает, что вы можете использовать данное программное обеспечение для создания и верификации цифровых подписей XML и подписывать и XML, и/или другие данные. Пакет, различные версии которого можно скачать по адресу http://xml.apache.org/security/dist/, кроме библиотек классов, также поставляется с документацией и примерами использования.

Другие реализации

Доступны и другие реализации с различными вариантами лицензирования — как реализации спецификации электронной цифровой подписи XML-документов, так и шифрования XML-документов. Вот некоторые из них:

XML Security Library (Aleksey Sanin) — http://www.aleksey.com/xmlsec/;

KeyTools XML (Baltimore) — http://www.baltimore.com/keytools/xml/;

XML Security (Phaos) — http://phaos.com/products/category/xml.html;

XML Signature SDK (Verisign) — http://www.xmltrustcenter.org/xmlsig/developer/verisign/index.htm.

Защита данных на основе XML

Язык разметки заявлений системы безопасности (SAML)

Направление, отличное от защиты XML-данных, но тесно с ним связанное, — это улучшение безопасности и защищенности систем (протоколов) на базе XML. В этом случае при помощи XML защищаются другие документы/системы/приложения. В настоящее время комитет безопасности Организации по развитию стандартов структурирования информации (Organization for the Advancement of Structured Information Standards, OASIS) занимается разработкой языка разметки заявлений системы безопасности (Security Assertion Markup Language, SAML).

SAML (http://www.oasis-open.org/committees/security/) заимствует синтаксис и семантику у XML и использует ее для расширения функций безопасности, относящихся к аутентификации и авторизации. Основные задачи, возлагаемые на SAML, — построение базовых конструкций, необходимых для обмена мандатами, определение протоколов для запросов, ответов и основных правил, а также описание связей SAML с другими протоколами, такими как HTTP, SOAP (Simple Object Access Protocol) и ebXML.

В настоящее время SAML рассматривается как первый стандарт для защиты транзакций электронной коммерции.

Спецификация управления ключами XML

Спецификация XML Key Management Specification (XKMS) определяет протоколы распространения и регистрации открытых ключей, поиск и проверку достоверности ключей, используемых для целей безопасности (как для ЭЦП, так и для шифрования). Она состоит из двух частей: спецификации XML Key Information Service (X-KISS) и XML Key Registration Service (X-KRSS) и доступна по адресу: http://www.w3.org/TR/xkms/.

Федеральный закон «Об электронной цифровой подписи»

Цели

Давайте немного отвлечемся от законодателей в области Web и рассмотрим Федеральный закон «Об электронной цифровой подписи», который был утвержден Президентом РФ 10 января 2002 года (http://www.internet-law.ru/intlaw/laws/ecp.htm). Принятие этого закона обеспечило правовые условия использования электронной цифровой подписи в электронных документах, при соблюдении которых электронная цифровая подпись в электронном документе признается равнозначной собственноручной подписи в документе на бумажном носителе. Таким образом, заложены основы для создания юридически значимого электронного документооборота.

Условия равнозначности ЭЦП и обычной подписи

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

Сертификаты и удостоверяющие центры

Закон подробно описывает, из чего состоит сертификат ключа подписи (уникальный регистрационный номер, ФИО владельца, открытый ключ ЭЦП, наименование и местонахождение удостоверяющего центра и др.); сроки и порядок хранения сертификата в удостоверяющем центре. Так, срок хранения сертификата ключа подписи в форме электронного документа в удостоверяющем центре определяется договором между удостоверяющим центром и владельцем сертификата ключа подписи. Что касается хранения, то оно определяется законодательством Российской Федерации об архивах и архивном деле.

Отдельная глава закона посвящена удостоверяющим центрам. Сам процесс выработки и проверки ЭЦП может проходить и без участия удостоверяющих центров, если это подтверждено договором сторон. Однако в информационных системах общего пользования и во многих корпоративных информационных системах применение ЭЦП без функционирования удостоверяющих центров невозможно, так как это приведет к достаточно простым механизмам подделки подписи.

Закрытые (секретные) ключи

Свои функции ЭЦП может выполнить только при наличии у подписывающего лица некоторой информации, недоступной посторонним людям. Эта информация аналогична ключу при шифровании и поэтому получила название «закрытый ключ электронной цифровой подписи» (раньше использовался аналогичный термин «секретный ключ»). Необходимо сохранять в тайне как закрытый ключ, так и ключ шифрования, поскольку знание закрытого ключа подписи соответствует чистому листу бумаги с подписью владельца закрытого ключа, на котором злоумышленник может написать любой текст, который будет приписан настоящему владельцу закрытого ключа. Ст. 12 закона прямо указывает на обязанность владельца сертификата ключа подписи хранить в тайне закрытый ключ и немедленно требовать приостановления действия сертификата ключа подписи при наличии оснований полагать, что тайна закрытого ключа подписи нарушена.

Ст. 5 Закона устанавливает порядок создания закрытых ключей подписи именно с учетом строгого соблюдения тайны их создания. На это же обстоятельство указывает и ст. 9 Закона, касающаяся деятельности удостоверяющих центров. В корпоративных информационных структурах вопрос изготовления и рассылки закрытых ключей ЭЦП может решаться собственными методами, однако при этом пользователь ЭЦП должен отдавать себе отчет в возможных последствиях такой организации функционирования ЭЦП. Вполне возможны случаи, когда в качестве закрытого ключа будет использоваться какая-то закономерная последовательность, как это бывает при использовании системы паролей.

Отечественные стандарты на алгоритмы ЭЦП

Схема Эль-Гамаля

В 1994 году был принят первый отечественный стандарт в области ЭЦП — ГОСТ Р34.10 — 94 «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма». Он определяет процедуры работы с ЭЦП на основе схемы Эль-Гамаля. Невозможность подделки подписи обусловлена сложностью решения задачи дискретного логарифмирования в поле из р элементов или сложностью заданного большому простому числу р и числам a, b из интервала от 2 до р-1 определения числа х, которое выполняется сравнением:

ax== bmodp.

Однако математики не стоят на месте, и в последнее время достигнут большой прогресс в развитии методов решения задачи дискретного логарифмирования в поле из р элементов. Недавно был создан так называемый метод решета числового поля. С его помощью можно взломать ЭЦП, сформированную вышеуказанным методом (по крайней мере в случае 512-битного модуля р).

Одно из простейших решений этой проблемы — увеличение длины модуля р. Но, к сожалению, при увеличении р ухудшаются эксплуатационные свойства алгоритма, поскольку увеличиваются длина открытого ключа и время выработки и проверки подписи.

Эллиптическая кривая

Российские ученые в конце концов пришли к выводу, что можно немного усложнить схему Эль-Гамаля и таким образом без дополнительных вычислительных затрат во много тысяч раз увеличить сложность подделки ЭЦП. Новый вариант схемы Эль-Гамаля использует аппарат эллиптических кривых над конечным полем из р элементов, которые определяются как множество пар чисел (х,у) (каждое из них лежит в интервале от 0 до p-1), удовлетворяющих сравнению (числа а и b фиксированы и соответствуют некоторому дополнительному условию):

y2 == x3 + ax + bmodp.

Новый закон базируется на процедурах выработки и проверки подписи на основе математического аппарата эллиптических кривых. Предварительно были подтверждены его высокие криптографические качества, гарантирующие, при сохранении в тайне закрытого ключа подписи, невозможность ее подделки в течение нескольких десятков лет, даже с учетом развития вычислительной техники и соответствующих математических алгоритмов.

Ссылки Электронная цифровая подпись XML-документов (спецификации W3C)

В начало В начало

Шифрование XML-документов (спецификации W3C)

В начало В начало

Пакеты (реализации) защиты XML

В начало В начало

Другие ресурсы

КомпьютерПресс 3'2003

1999 1 2 3 4 5 6 7 8 9 10 11 12
2000 1 2 3 4 5 6 7 8 9 10 11 12
2001 1 2 3 4 5 6 7 8 9 10 11 12
2002 1 2 3 4 5 6 7 8 9 10 11 12
2003 1 2 3 4 5 6 7 8 9 10 11 12
2004 1 2 3 4 5 6 7 8 9 10 11 12
2005 1 2 3 4 5 6 7 8 9 10 11 12
2006 1 2 3 4 5 6 7 8 9 10 11 12
2007 1 2 3 4 5 6 7 8 9 10 11 12
2008 1 2 3 4 5 6 7 8 9 10 11 12
2009 1 2 3 4 5 6 7 8 9 10 11 12
2010 1 2 3 4 5 6 7 8 9 10 11 12
2011 1 2 3 4 5 6 7 8 9 10 11 12
2012 1 2 3 4 5 6 7 8 9 10 11 12
2013 1 2 3 4 5 6 7 8 9 10 11 12
Популярные статьи
КомпьютерПресс использует