Электронная цифровая подпись в документировании: проблемы разработки и применения

4. Подделка подписей

Анализ возможностей подделки подписей называется криптоанализ. Попытку сфальсифицировать подпись или подписанный документ криптоаналитики называют «атака».

Модели атак и их возможные результаты

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

Также в работе описана классификация возможных  результатов атак:

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

Ясно, что самой  «опасной» атакой является адаптивная атака на основе выбранных сообщений, и при анализе алгоритмов ЭЦП на криптостойкость нужно рассматривать именно ее (если нет каких-либо особых условий).

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

Подделка документа (коллизия первого рода)

Злоумышленник может попытаться подобрать документ к данной подписи, чтобы подпись  к нему подходила. Однако в подавляющем  большинстве случаев такой документ может быть только один. Причина  в следующем:

• Документ представляет из себя осмысленный текст.
• Текст документа оформлен по установленной форме.
• Документы редко оформляют в виде Plain Text — файла, чаще всего в формате DOC или HTML.

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

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

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

Вероятность подобного  происшествия также ничтожно мала. Можно считать, что на практике такого случиться не может даже с ненадёжными  хеш-функциями, так как документы обычно большого объёма — килобайты.

Получение двух документов с одинаковой подписью (коллизия второго рода)

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

Социальные атаки

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

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

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

5. Управление ключами

Управление открытыми ключами

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

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

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

Хранение закрытого ключа

Смарт-карта  и USB-брелоки eToken

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

В настоящее  время существуют следующие устройства хранения закрытого ключа:

• Дискеты
• Смарт-карты
• USB-брелок
• Таблетки Touch-Memory

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

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

В соответствии с законом «ОБ ЭЛЕКТРОННОЙ  ЦИФРОВОЙ ПОДПИСИ», ответственность  за хранение закрытого ключа владелец несет сам. 
 
 
 
 
 
 
 
 
 
 
 
 

6. Использование ЭЦП

6.1. В России

В России юридически значимый сертификат электронной подписи  выдаёт удостоверяющий центр. Правовые условия использования электронной цифровой подписи в электронных документах регламентирует федеральный закон от 10 января 2002 г. № 1-ФЗ «Об электронной цифровой подписи», ст. 3 и определяет ЭЦП так:

«Электронная  цифровая подпись — реквизит электронного документа, предназначенный для защиты данного электронного документа от подделки, полученный в результате криптографического преобразования информации с использованием закрытого ключа электронной цифровой подписи и позволяющий идентифицировать владельца сертификата ключа подписи, а также установить отсутствие искажения информации в электронном документе»

После становления ЭЦП при использовании в электронном документообороте между кредитными организациями и кредитными бюро в 2005 году активно стала развиваться инфраструктура электронного документооборота между налоговыми органами и налогоплательщиками. Начал работать приказ Министерства по налогам и сборам РФ от 2 апреля 2002 г. N БГ-3-32/169 «Порядок представления налоговой декларации в электронном виде по телекоммуникационным каналам связи». Он определяет общие принципы информационного обмена при представлении налоговой декларации в электронном виде по телекоммуникационным каналам связи.

В Законе РФ от 10 января 2002 г. № 1-ФЗ «Об электронной цифровой подписи» прописаны условия использования ЭЦП, особенности её использования в сферах государственного управления и в корпоративной информационной системе.

Благодаря ЭЦП  теперь, в частности, многие российские компании осуществляют свою торгово-закупочную деятельность в Интернете, через «Системы электронной торговли», обмениваясь с контрагентами необходимыми документами в электронном виде, подписанными ЭЦП. Это значительно упрощает и ускоряет проведение конкурсных торговых процедур.

ЭЦП В РОССИЙСКИХ КОММЕРЧЕСКИХ И ГОСУДАРСТВЕННЫХ  СТРУКТУРАХ  
 
Положение с использованием ЭЦП в коммерческом секторе 
Коммерческие структуры продолжают использовать процедуры ЭЦП в рамках замкнутых (корпоративных) систем по схеме, для которой достаточно было соответствующих статей Гражданского кодекса и Закона "Об информации, информатизации и защите информации". Закон об ЭЦП здесь применим лишь постольку, поскольку он не нарушается, определяя правила использования ЭЦП в корпоративной системе ее владельцем. Для того чтобы обмен электронными документами с ЭЦП между участниками такой системы был юридически значимым, по-прежнему требуется дополнительное двустороннее письменное соглашение между сторонами.  
 
Определенные сдвиги произошли только в банковско-финансовой сфере. Прежде всего следует отметить важный шаг в организационной области, который был сделан в результате подписания в конце февраля 2003 года Меморандума о создании "Ассоциации участников доверительного электронного документооборота" (АУДЭД). Его организаторами стали Ассоциация российских банков (АРБ) и Национальная ассоциация участников фондового рынка (НАУФОР). До сих пор банки, например, использовали в общем случае различное программное обеспечение и несовместимые друг с другом форматы ЭЦП, что вызывало справедливую критику со стороны клиентов, имевших отношения с рядом банков и вынужденных эксплуатировать множество программных пакетов и цифровых сертификатов ЭЦП, которые, по сути, предназначались для решения однотипных задач. Одна из основных задач АУДЭД - унификация использования соответствующего ПО в финансовой сфере.

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