Как обеспечить подлинность электронных документов?

А. В. Лукацкий
Научно-инженерное предприятие "Информзащита"

Введение

Последние несколько лет ознаменовались постепенной заменой бумажной технологии обработки информации ее электронным аналогом. Со временем можно ожидать полного вытеснения бумажного документооборота электронным. Однако представление традиционных бумажных документов в виде электронных последовательностей, состоящих из нулей и единиц, обезличивает последние. Защитных атрибутов бумажных документов: подписей, печатей и штампов, водяных знаков, специальной фактуры бумажной поверхности и т.д., - у электронного представления документов нет. Но электронные документы нужно защищать не менее тщательно, чем бумажные. Поэтому возникает задача разработки такого механизма электронной защиты, который бы смог заменить подпись и печать на бумажных документах. Т.е. необходимо разработать механизм цифровой подписи (digital signature), которая представляет собой дополнительную информацию, приписываемую к защищаемым данным. Цифровая подпись зависит от содержания подписываемого документа и некоего секретного элемента (ключа), которым обладает только лицо, участвующее в защищенном обмене. Что должен обеспечивать такой механизм?

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

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

Правовые аспекты

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

В 1995 году был принят Федеральный Закон "Об информации, информатизации и защите информации". В пункте 3 статьи 5 говорится, что юридическая сила документа может подтверждаться электронной цифровой подписью. При этом "юридическая сила электронной цифровой подписи признается при наличии в автоматизированной информационной системе программно-технических средств, обеспечивающих идентификацию подписи установленного режима их использования". Однако "право удостоверять идентичность электронной цифровой подписи осуществляется на основании лицензии" (п.4).

Можно заметить, что и Гражданский Кодекс и Закон "Об информации, информатизации и защите информации" лишь подтверждают возможность применения ЭЦП, но никаким образом не регламентируют случаи и порядок ее использования. Эти задачи возлагаются на дополнительные правовые акты. Однако, никаких подзаконных актов, кроме наделавшего много шума Указа Президента № 334 от 3 апреля 1995 года, до сих пор не разработано. В Государственной Думе давно ждут рассмотрения Законы "Об электронном документе" и "Об электронной цифровой подписи". Но рассмотреть их планируется не ранее конца текущего года. А если учесть предстоящие выборы, то можно с уверенностью сказать, что о данных законопроектах заговорят не ранее 2000 года. Поэтому необходимо заметить, что для обеспечения юридической значимости цифровой подписи необходимо, чтобы в договоре об обмене электронными документами между сторонами была обязательно расписана процедура "порядка согласования разногласий". Без этой процедуры суд вправе не принимать в качестве доказательства документы, подписанные электронной цифровой подписью (Письмо Высшего Арбитражного Суда РФ от 19 августа 1994 г. № С1-7/ОП-587).

В Указе Президента от 3 апреля, в п.2 говорится о том, что использовать в информационно-телекоммуникационных системах средства ЭЦП, не имеющих сертификата Федерального агентства правительственной связи и информации (ФАПСИ), запрещено. Однако самое большое противоречие вызывает пункт 4, в котором запрещается деятельность нелицензированных ФАПСИ юридических и физических лиц, связанных с разработкой, реализацией, производством и эксплуатацией шифровальных средств (в т.ч. и систем цифровой подписи). Т.е. согласно данному пункту запрещено использовать системы цифровой подписи даже в домашних условиях. Однако статья 6 Закона "Об информации, информатизации и защите информации" говорит о том, что собственник информационного ресурса имеет право сам устанавливать правила защиты своей информации.

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

Хочется отметить работы, ведущиеся в этой области в Ассоциации Документальной Электросвязи. Во-первых, в Комитете по защите информации ведутся работы по реализации защищенной электронной почты X.400, невозможной без ЭЦП. Работы в области правового обеспечения ЭЦП ведутся также в Комитетах по электронному ведению бизнеса и Комитете по стандартизации.

Подпись документов при помощи симметричных криптосистем

Первые варианты цифровой подписи были реализованы при помощи симметричных криптосистем, в которой абоненты, участвующие в обмене сообщениями, используют один и тоже секретный ключ для простановки и проверки подписи под документом. В качестве алгоритма криптографического преобразования может использоваться любая из симметричных криптосистем, обладающая специальными режимами функционирования (например, DES, ГОСТ 28147-89 и т.п.).

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

1. Алекс и Юстас обладают одинаковым секретным ключом K.

2. Алекс зашифровывает цифровое сообщение, используя ключ K, и посылает зашифрованное сообщение Юстасу. При этом, как уже отмечалось, используется криптосистема, обладающая специальными механизмами функционирования, например ГОСТ 28147-89 в режиме выработки имитовставки.

3. Юстас расшифровывает сообщение при помощи ключа K.

Так как только Алекс и Юстас обладают секретным ключом, то тем самым обеспечивается гарантия, что сообщение подписано именно Алексом, а не стариком Мюллером. Однако, данная схема применима только в тех сетях, в которых можно дать стопроцентную гарантирую надежности каждого из абонентов, т.к. в обратном случае существует потенциальная возможность мошенничества со стороны одного из абонентов, владеющих секретным ключом.

Для устранения указанного недостатка была предложена схема с доверенным арбитром. В данной схеме помимо Алекса и Юстаса существует арбитр - радистка Кэт. Она может обмениваться сообщениями и с Алексом, и с Юстасом, и владеет секретными ключами обоих - KА и KЮ. Процедура подписания документов в данной схеме выглядит следующим образом:

1. Алекс зашифровывает сообщение, используя ключ KА, и посылает его Кэт.

2. Кэт расшифровывает сообщение, также используя ключ KА.

3. Расшифрованное сообщение Кэт зашифровывает на ключе Юстаса KЮ.

4. Данное сообщение Кэт посылает Юстасу.

5. Юстас расшифровывает сообщение, полученное от Кэт, используя ключ KЮ.

Насколько эффективна данная схема? Рассмотрим ее с учетом вышеуказанных требований, предъявляемых к цифровой подписи.

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

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

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

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

Подпись документов при помощи криптосистем с открытыми ключами

Поиски методов, устраняющих указанные выше недостатки, велись по нескольким направлениям. Наиболее впечатляющих результатов добились криптографы-математики Уитфилд Диффи (W. Diffie) и Мартин Хеллман (M. Hellman), а также Ральф Меркль (Ralph Merkle), которые в конце 70-х годов опубликовали результаты своих исследований. В своих работах авторы показали, что существует возможность построения криптосистем, не требующих передачи секретного ключа между абонентами, участвующими в обмене защищаемой информацией. В таких криптосистемах нет необходимости и в арбитрах. Суть разработанного подхода заключается в том, что в обмене защищаемыми документами каждый абонент использует пару взаимосвязанных ключей - открытый и секретный. Отправитель подписываемого документа передает получателю открытый ключ. Он может это сделать любым несекретным способом или поместить ключ в общедоступный справочник. При помощи открытого ключа получатель проверяет подлинность получаемой информации. Секретный ключ, при помощи которого подписывалась информация, хранится в тайне от всех.

Можно заметить, что в данной схеме абоненты используют различные ключи, что не позволяет мошенничать ни одной из сторон. Подробный анализ цифровой подписи на основе криптосистем с открытыми ключами показывает, что она полностью удовлетворяет требованиям, предъявляемым к ней и указанным в начале статьи. В настоящий момент широкого известны цифровые подписи, построенные по алгоритмам RSA, Эль-Гамаля, Шнорра, Рабина и математического аппарата эллиптических кривых.

Хэш-функция

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

Хранение ключей

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

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

Распределение ключей

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

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

Подтверждение подлинности абонентов в последнем случае может осуществляться следующим образом:

• Непосредственно между абонентами. Данный метод применяется в том случае, если абонентов всего двое. Для обмена ключами в данном случае может быть использован алгоритм распределения ключей, например, разработанный в 1976 году криптографами Диффи и Хеллманом. Существуют и другие варианты обмена ключами. Например, при помощи симметричных криптосистем или фельдъегерской службы. Однако, в распределенных сетях, насчитывающих не один десяток абонентов, такие варианты не применимы из-за возникающих сложностей.
• С использованием посредника (арбитра). Данный метод может применяться в корпоративных сетях, в которых существует так называемый центр верификации или сертификации ключей. Данный центр удостоверяет ключи, используемые для проверки подписи. Подтверждение подлинности ключей может реализовываться или путем формирования справочника открытых ключей, или путем выдачи сертификатов, которые передаются вместе с сообщением, требующим проверки. Данный сертификат представляют собой ключ для проверки подписи и некоторую аутентифицирующую информацию, скрепленные подписью Центра сертификации. В данном случае достаточно проверить подпись Центра в сертификате, чтобы удостовериться в подлинности ключа абонента.
• С использованием двух и более посредников. Этот метод, являющийся комбинацией двух предыдущих, может применяться в том случае, когда необходимо обеспечить обмен подписанными сообщениями между несколькими корпоративными сетями, в каждой из которых существует свой центр сертификации.

Стандарты

В России в 1994 году были приняты стандарты ГОСТ Р 34.10-94 "Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма" и ГОСТ Р 34.11-94 " Криптографическая защита информации. Функция хэширования". Чем могут помочь пользователю данные стандарты? Во-первых, они должны гарантировать криптостойкость, т.е. надежность реализованных по ним алгоритмов. Во-вторых, применение стандартов должно обеспечить совместимость продуктов различных производителей. Однако есть и проблемы при использовании принятых стандартов.

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

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

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

Требования пользователей

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

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

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

Поскольку при приобретении системы цифровой подписи, как правило, у заказчика уже сложилась информационная инфраструктура, то очень часто на первое место выходит вопрос об интеграции приобретаемой системы в принятую технологию обработки информации. Например, если в качестве средства отправки электронной почты используется Microsoft Outlook, то необходимо, чтобы система ЭЦП могла быть встроена в эту почтовую программу. Такую возможность предлагают многие зарубежные и некоторые российские системы ЭЦП, например, PGP (Pretty Good Privacy), которая также может быть встроена в почтовую программу Eudora, наравне с Microsoft Outlook, широко распространенную в России. Если система ЭЦП не поддерживает используемое у заказчика программное обеспечение (например, потому что оно разработано самим заказчиком), то поставщик должен поставлять интерфейс (API) для встраивания возможностей работы с цифровой подписью в систему заказчика. Такую возможность предлагают многие российские производители (например, МО ПНИЭИ, ЛАН КРИПТО, НИП "Информзащита"). Причем желательно, чтобы данный интерфейс существовал для различных операционных систем и платформ (Windows NT, Windows 9x, MS DOS, HP UX, AIX и т.д.).

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

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

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

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

Окончательный выбор системы ЭЦП может быть определен наличием или отсутствием следующих дополнительных возможностей:

• Постановка нескольких подписей под одним документом и их выборочная проверка;
• Хранение цифровой подписи не только в подписываемом документе, но и в отдельном файле;
• Использование командной строки для работы с системой ЭЦП;
• Подпись и проверка группы файлов;
• Постановка и проверка подписи под заданными фрагментами (полями) документа;
• Выработка и проверка групповой подписи;
• Совместное использование функций шифрования и цифровой подписи;
• Постановка подписи и ее проверка для участка оперативной памяти;
• Архивация использованных ключей;
• И т.д.

Атаки на цифровую подпись

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

Атаки на алгоритмы

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

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

Кроме того, иногда в российских журналах или телеконференциях в сети Internet и FIDOnet можно прочитать сообщения об оптимизации существующих стандартов (например, ГОСТ 28147-89 или DES), которые якобы не снижают надежности самих стандартов, а скорость работы при этом возрастает на один-два порядка. К таким сообщениям надо относиться с определенной степенью скептицизма. Выгоды от применения "оптимизированных" алгоритмов сомнительны, а вот вероятность фальсификации документов, подписанных с их помощью, увеличивается.

Атаки на криптосистему

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

Для алгоритмов, основанных на открытых ключах, например, RSA или Эль-Гамаля, существует ряд математических проблем, которые не всегда учитываются при построении криптосистемы. К таким моментам можно отнести выбор начальных значений, на основе которых создаются ключи. Есть определенные числа, которые позволяют очень быстро вычислить секретный ключ ЭЦП. В то же время правильный выбор начальных значений позволяет гарантировать невозможность "лобовой" атаки в течение нескольких сотен лет при современном развитии вычислительной техники.

Атаки на реализацию

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

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

В качестве примера атаки на реализации систем ЭЦП можно назвать случай, описанный в середине 90-х годов в отечественной прессе и связанный с устанавливаемой "закладкой" в широко распространенную программу PGP.

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

Атаки на пользователей

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

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

Заключение

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

Сделайте правильный выбор - и Ваша информация будет надежно защищена от подделки.

Список литературы

1. Bruce Schneier. Applied Cryptography, Second edition. John Wiley & Sons, 1996

2. Брюс Шнайер. Слабые места криптографических систем. "Открытые системы", №1, 1999.

3. Ю. Мельников. Электронная цифровая подпись: всегда ли она подлинная? Банковские технологии, №5, 1995.