Во-первых, это возможность идентификации принадлежности подписи на основе объективных показателей. Во-вторых, высокая защищенность от подделки. И, в-третьих, это жесткая связь с подписываемым документом. Если первые два требования еще можно реализовать для традиционной подписи, то выполнение третьего возможно только в случае применения электронной цифровой подписи (ЭЦП). Вопрос о применении других аналогов собственноручной подписи выходит за рамки рассматриваемой тематики.
Выполнение всех трех требований становится возможным исходя из самой природы ЭЦП. ЭЦП представляет собой некое достаточно длинное число, полученное в результате преобразования электронного образа защищаемого документа с использованием секретного (личного) ключа отправителя. Любой может проверить ЭЦП под документом при помощи соответствующих преобразований с использованием, опять-таки, электронного образа документа, открытого (публичного) ключа отправителя и собственно значения ЭЦП. Открытый и секретный ключи однозначно связаны между собой, однако невозможно вычислить секретный ключ по открытому. Точнее, если формулировать совсем строго, то в настоящий момент не найдено алгоритмов, позволяющих осуществить такое вычисление за приемлемое время, с учетом современного уровня развития вычислительной техники и используемой длины ключей.
Секретный ключ содержится в тайне и известен только владельцу, никто, кроме владельца не сможет сформировать ЭЦП под документом. Зато любой может проверить (с помощью доступного всем открытого ключа), что документ подписал именно владелец, и что документ не искажен (т.к. значение ЭЦП зависит и от содержимого документа). Логичное следствие состоит в том, что просто перенести ЭЦП с одного документа на другой (по аналогии с ксерокопированием или сканированием обычной подписи на бумажном документе или использованием факсимиле) невозможно. Таким образом, можно сказать, что ЭЦП является реквизитом данного конкретного электронного документа.
Естественно, говорить об этом с уверенностью можно, только если генерацию ключей производил сам владелец ключа, либо (если он не располагает соответствующей техникой) - удостоверяющий центр (см. ниже) в его присутствии. В этой связи вызывает недоумение практика, распространенная в некоторых системах, когда ключи генерируются заранее организатором системы, а потом раздаются пользователям.
Все выглядит прекрасно. Однако, активистам GreenPeace рано устраивать праздник по поводу грядущего сбережения лесов ввиду сокращения расхода бумаги.
А мешают, как обычно, проблемы внедрения и реализации, незаметные на генеральном плане.
Как известно, все несимметричные криптосистемы в чистом виде беззащитны против атаки "человек посередине" (man-in-the-middle). Открытые ключи все участников обмена должны быть доступны всем для возможности проверки ЭЦП. То есть, их можно размещать на серверах, передавать по радио, писать на заборах и публиковать в колонке частных объявлений в газете. Но где гарантия, что ключ с идентификатором "Вася Пупкин" действительно принадлежит Пупкину Василию Степановичу, 19ХХ года рождения, паспорт серия номер, прописан там-то? Правильно, никакой. Никто не мешал злобному хакеру Шурику Мрачноухову сгенерировать свою пару ключей с тем же идентификатором ("Вася Пупкин") и положить открытый ключ на общедоступный сервер под именем Васи. Теперь Шурик, перехватив подписанное сообщение Васи о том, что он продает славянский шкаф, и звонить надо с 17 до 19 часов, отбрасывает ЭЦП Васи, изменяет сообщение (звонить с 1 ночи до 5 утра) и формирует новую ЭЦП (подписывает сообщение) секретным ключом из сформированной им пары. После чего делает сообщение доступным общественности (мы исходим их того, что Шурик настолько злобен, что имеет возможность изымать из канала связи исходящие сообщения Васи). В результате члены электронного сообщества, получив такое сообщение, находятся в полной уверенности, что его написал Вася, ведь проверка ЭЦП проходит успешно (помните, чей открытый ключ на самом деле лежит
на сервере ключей?). Выходов из этой ситуации два. Первый заключается в том, что Вася лично передает свой открытый ключ всем, с кем собирается вести переписку. По очевидным причинам он неприемлем (не со всеми можно встретиться лично, невозможно заранее предусмотреть всех адресатов). Второй выход заключается в создании Центра сертификации (Certificate Authority). В качестве такого центра выбирается лицо, которому все доверяют, и с которым хотя бы один раз могут встретиться лично, либо имеют надежный (т.е. не допускающий искажений/подделок) канал связи. После выборов такого лица, все участники обмена генерируют свои пары ключей и, прихватив свой открытый ключ, выстраиваются в очередь к Центру Сертификации. Центр Сертификации за умеренную плату удостоверяет личность пришедшего и подписывает его открытый ключ своим секретным ключом. Кроме собственно открытого ключа в блок подписываемых данных включаются дополнительные сведения: имя владельца, другие идентифицирующие данные, сроки действия ключа, перечень информационных систем, в которых допустимо его использовать и другая информация (см. стандарт X.509 или статью 6 "Закона об электронной цифровой подписи"). Все это вместе (открытый ключ, блок данных и ЭЦП) называется сертификатом открытого ключа. Счастливый владелец ключа получает на руки сертификат и открытый ключ Центра. Теперь он просто счастлив - Центр удостоверил принадлежность ключа ему (потому в законе об ЭЦП данные центры именуются "Удостоверяющие Центры"). Так как другие участники системы также получают вместе с сертификатом копию открытого ключа Центра (получают лично - самый надежный канал), они могут удостовериться в принадлежности любого открытого ключа, не встречаясь лично с его владельцем, потому что теперь при установлении связи абоненты обмениваются не просто открытыми ключами, а сертификатами.
Так к почти строгому математическому механизму ЭЦП добавился организационный довесок. Все, проблемы решены? Не торопитесь :)
Пока речь идет о продаже славянского шкафа обывателем Васей Пупкиным и его недовольстве ночными звонками - это одно. Но если проблемы возникнут с подписанным ЭЦП сообщением респектабельной фирмы, предписывающей ее не менее респектабельному банку перечислить энную сумму на счет другой, еще более респектабельной фирмы - это совсем другое дело. И встают извечные вопросы российской интеллигенции:
Юридическая правомочность использования аналогов собственноручной подписи (разновидностью каковых и является ЭЦП) декларирована в Гражданском Кодексе [1]. Конечно же, наши респектабельные фирмы и банк заключили между собой соответствующие договора, в которых стороны признают, что подписанные ЭЦП документы имеют такую же юридическую силу, что и документы на бумажном носителе, подписанные обычной подписью и заверенные печатью. В этом же договоре стороны определяют, при помощи какого именно программного обеспечения (ПО) или аппаратуры будет формироваться ЭЦП, порядок его использования (организационные и технические меры безопасности) и, самое главное, порядок разрешения конфликтных ситуаций.
Применительно к ЭЦП разновидностей конфликтных ситуаций не так много:
отказ от авторства сообщения (я это не писал/не посылал!);
отказ от факта приема сообщения (я этого не получал!);
оспаривание времени приема/отправки сообщения.
Возникновение двух последних ситуаций предотвращается изначально продуманным построением протокола обмена сообщениями между абонентами. Во-первых, к каждому сообщению перед подписанием прикрепляется отметка времени. Во-вторых, на каждое полученное сообщение получатель отправляет подписанное ЭЦП подтверждение о его приеме. Отправитель, в свою очередь, получив подтверждение, отправляет подписанную ЭЦП квитанцию. Таким образом, на каждый акт информационного обмена приходится 3 посылки, что, конечно же, является избыточным, но позволяет избежать упомянутых выше проблем (естественно, обе стороны ведут в течение оговоренного времени архивы принятых/посланных сообщений с ЭЦП). Во многих случаях такое трехшаговое общение позволит легко разрешить и ситуацию с отказом от авторства сообщения. Такая ситуация также должна быть предусмотрена в договоре и, во избежание недоразумений, должна быть расписана по шагам: как формируется комиссия (сроки, число членов с обеих сторон, необходимость привлечения независимых экспертов), порядок установки с эталонной копии средств для осуществления проверки, формальные признаки, по которым осуществляется проверка, порядок оформления результатов. Не следует забывать и о необходимости сохранения копий сертификатов открытых ключей в удостоверяющем центре в течение необходимого срока, определяемого договором между участниками обмена. Естественно, срок хранения должен быть не менее исковой давности, определенной Гражданским Кодексом или иными правовыми актами для данного вида договорных отношений.
Если обе стороны согласны с выводами комиссии, то виновный страдает материально, и конфликт считается исчерпанным. В противном случае (одна из сторон не согласна с решением) придется обращаться в Арбитраж. Здесь следует сделать лирическое отступление.
Российское законодательство не запрещает использовать несертифицированные средства криптографической защиты информации, к которым в соответствии с "Системой сертификации СКЗИ" [2] относится и ЭЦП. Однако, эта вольность не распространяется на государственные предприятия, а также на случаи обработки информации, для защиты которой закон требует обязательного применения сертифицированных средств, вне зависимости от формы собственности обрабатывающего ее предприятия. Обязательным является и применение сертифицированных СКЗИ и при взаимодействии с государственными предприятиями.
Деятельность по предоставлению услуг по шифрованию информации, распространению шифровальных средств, техническому обслуживанию шифровальных средств и удостоверению идентичности электронной цифровой подписи подлежит лицензированию в соответствии с "Законом о лицензировании отдельных видов деятельности" [3]. Лицензированием указанных видов деятельности (как и сертификацией СКЗИ) занимается ФАПСИ [4]. Однако, ФАПСИ не может выдать соответствующие лицензии, если заявитель использует несертифицированные СКЗИ (за исключением систем международного обмена, например SWIFT).
Более того, сертифицировано может быть только средство, реализующее алгоритмы в соответствии с отечественными ГОСТ; для ЭЦП это ГОСТ Р 34.10 [5]. Таким образом, если использование СКЗИ выходит за рамки внутреннего документооборота организации, оно подлежит лицензированию, что автоматически подразумевает переход на сертифицированные средства.
Говоря о сертификации, нельзя не упомянуть и небезызвестный Указ Президента N334 [6].
Итак, наши фирмы и банк решили продолжить разрешение конфликта в третейском суде или арбитраже.
В соответствии с "Законом об электронной цифровой подписи" [7] в случае применения несертифицированных средств ответственность лежит на распространителе этих средств (в нашем примере это, видимо, банк). Соответственно, суд может даже не тратить свое драгоценное время, а показать пальцем на виновного и перейти к более важным делам.
Однако, пусть наши участники будут законопослушны: используемое ими СКЗИ имеет сертификат ФАПСИ, а банк имеет соответствующие лицензии ФАПСИ. В этом случае суд, рассмотрев все обстоятельства дела, может принять решение о дополнительной экспертизе СКЗИ. Естественно, для этого должны быть веские основания. Например, отказывающийся от авторства абонент предоставил неопровержимые доказательства того, что его секретный ключ не был разглашен, а сам он вместе с ключом все время находился в другом месте, где его видело много свидетелей. Дальнейшее развитие событий может пойти двумя путями.
Первый - независимая экспертиза обнаружила, что реализованный в СКЗИ алгоритм не соответствует ГОСТ. В этом случае иск на возмещение убытков может быть обращен на испытательную лабораторию, производившую сертификацию СКЗИ.
Второй возможный путь развития процесса: экспертиза обнаружила изъян в самом алгоритме (или он был опубликован кем-то из исследователей). В данной ситуации вина лежит на разработчике стандарта, но пытаться предъявить иск государству - дело мало перспективное. Впрочем, наиболее вероятный исход, если дело все же дойдет до независимой экспертизы, будет заключаться в том, что она либо просто признает оспариваемую ЭЦП истинной (материально страдает оспаривающий), либо в процессе экспертизы будет обнаружено нарушение правил эксплуатации СКЗИ оспаривающим свое авторство абонентом, повлекшее утечку его секретного ключа (материальные страдания снова падают на него).
В теории все это выглядит замечательно. На практике же следует учитывать, что судьи и другие юристы, участвующие в разрешении конфликта не являются специалистами ни в области компьютерной техники, ни в области криптографии. Предъявление некоторых доказательств может вызвать неприятие и отторжение с их стороны, к этому следует относиться с пониманием - пройдет еще не мало лет, пока юристы будут воспринимать конфликты вокруг ЭЦП также естественно, как, например, дела о подделке бумажных документах.
Да, и это еще не последние грабли на тернистом пути всеобщей информатизации и внедрения ЭЦП.
Выше мы неоднократно упоминали о "получении копии открытого ключа Центра". Может возникнуть резонный вопрос: раз это "тот самый гвоздь, на котором висит система" (действительно, ведь открытый ключ УЦ никем не подписан; в лучшем случае - это самоподписанный сертификат), как можно удостовериться в его целостности? Выход очевиден - вместе с файлом (электронным образом ключа) должна выдаваться распечатка ключа на бумажном носителе (вот она, экономия бумаги :)), заверенная подписью и печатью. Соответственно, проверка целостности ключа осуществляется путем визуальной сверки выведенного на экран файла ключа с распечаткой. Неудобно, но другой способ придумать сложно. Конечно, если пользователь является абонентом нескольких систем ЭЦП, ему будет накладно визуально сверять открытый ключ каждого УЦ с распечаткой. Эту проблему можно разрешить, если на федеральном уровне будет построена иерархическая система удостоверяющих центров. При таком подходе открытый ключ УЦ конкретной системы (например, системы "клиент-банк") подписывается (удостоверяется) ключом УЦ уровня местного органа государственной власти. Ключ этого УЦ удостоверяется УЦ уровня субъекта федерации, далее идет УЦ федерального округа, региона и т.п., до самого главного УЦ - федерального УЦ. Таким образом, будет существовать только один открытый ключ, который никем не подписан, и в целостности которого необходимо убеждаться путем визуальной сверки. Открытый ключ (точнее, сертификат открытого ключа) любого другого УЦ всегда можно проверить "по цепочке сертификатов".
Следующая техническая тонкость заключается в том, что все действия, о которых мы говорили выше осуществляются не в памяти человека и не на бумажке столбиком, а при помощи программного обеспечения, которое, в свою очередь, работает на некоторой аппаратуре. Все это делали люди, а им, как известно, свойственно ошибаться. Достаточно высокие гарантии отсутствия ошибок и соответствия производимых программой действий описанным в ГОСТах алгоритмам дает наличие сертификата ФАПСИ на средство криптографической защиты (в нашем рассмотрении - на средство ЭЦП). Но где гарантия, что программный модуль, полученный пользователем системы в качестве средства ЭЦП, соответствует сертифицированному эталону и не искажен? В отличие от открытого ключа УЦ программное обеспечение имеет внушительные размеры, его распечатка представит собой немаленькую стопку бумаги, а сверка распечатки с экраном вряд ли кого-то вдохновит, не говоря уже о ее неэффективности (попробуйте на досуге сверить две бессмысленные цифровые последовательности длиной хотя бы пару сотен чисел - ошибки почти неизбежны). Что же делать? Видится несколько вариантов решения проблемы.
Первый вариант заключается в вычислении контрольной суммы программного обеспечения по некому известному алгоритму. Пользователь может самостоятельно рассчитать контрольную сумму полученного ПО при помощи средства, которому он доверяет, и которое реализует указанный алгоритм. Если контрольная сумма совпала с заявленной (и, конечно, напечатанной на бумаге с подписью и круглой печатью - продолжаем беречь леса :)), ПО можно считать соответствующим эталону. Понятно, что для надежности надо использовать алгоритм, дающий большие гарантии, чем CRC32, например SHA-1 или MD5. Однако, если мы захотим быть патриотичными и использовать отечественный алгоритм хэширования в соответствии с ГОСТ Р34.11 [8], то нас ждет еще одно препятствие. Дело в том, что при вычислении данной хэш-функции используется алгоритм криптографического преобразования в соответствии с ГОСТ 28147-89 [9] (шифрование стартового вектора хэширования в режиме простой замены на ключах, генерируемых из защищаемой информации). Но ГОСТ 28147-89 кроме собственно ключа шифрования определяет так называемую таблицу узлов замен (в англоязычной терминологии - S-boxes), значения которой в ГОСТе не зафиксированы и выбираются для каждой конкретной криптосистемы отдельно. В связи с этим в выдаваемом документе с контрольной суммой (значением хэша ПО) пришлось бы указывать, что оно рассчитано с такими-то значениями таблицы узлов замен.
Второй вариант заключается в том, что распространитель средств ЭЦП (как правило, организатор системы электронного документооборота - банк, фонд, держатель ресурса общего пользования и т.п.) заверяет ПО ЭЦП электронной цифровой подписью нотариуса. Пользователь может убедиться в целостности ПО, обратившись для проверки ЭЦП к подписавшему нотариусу или в соответствующий УЦ, стоящий по иерархии выше. В некотором смысле это гораздо выигрышнее первого варианта: бумага есть бумага, необходимо иметь достаточное количество заверенных подписью и печатью бумажек с контрольной суммой, тиражировать же в электронном виде подписанное ЭЦП программное обеспечение можно бесконечно. В отличие от процесса ксерокопирования бумажных документов, каждая копия имеет силу оригинала, нет необходимости дополнительно заверять ее у нотариуса.
Третий вариант - получать ПО ЭЦП из независимого источника. Например, заложить эталон ПО на хранение нотариусу или получать непосредственно у производителя. Он наиболее логичен, но подразумевает много накладных расходов для своей реализации.
Совсем недавно в Государственной Думе прошел первое чтение "Закон об электронной цифровой подписи", споры вокруг которого не утихают с самого момента появления первых версий проекта. Если необходимость собственно закона никто оспаривать не пытается, то его содержимое вызывает ряд нареканий. Попробуем выделить некоторые спорные, на наш взгляд, положения данного закона, которые могут затруднить практическое использование ЭЦП.
В число обязательных реквизитов сертификата открытого ключа (ст.6 п.1 Проекта "Закона...") включено требование указания правоотношений, в которых данный сертификат используется. Кроме несовместимости с Х.509, из этого следует, что вышеупомянутый Вася Пупкин либо будет вынужден на каждый вид отношений генерировать отдельный ключ и оформлять в Центре сертификат (и не запутаться потом в этой массе!), либо постараться сразу же предусмотреть все необходимые ему отношения и перечислить их в сертификате через запятую. Во втором случае он все равно не гарантирован от ситуации, когда в процессе его жизнедеятельности возникнет новый вид правоотношений, отсутствующий в сертификате. Следует также отметить, что в практически любом договоре отражается целый комплекс различных правоотношений, и далеко не все они очевидны для конечного пользователя. На практике, исполняя дух и букву закона, необходимо будет перед формированием ЭЦП проводить правовой анализ документа, что, согласитесь, несколько затруднительно на практике. В противном случае возникает масса возможностей для злоупотреблений любой из сторон.
Для регулирования значительной части взаимоотношений в законе производится отсылка к другим нормативным актам, которые в настоящее время отсутствуют и неизвестно когда появятся. В качестве примера можно привести ст.19, где описано использование ЭЦП для заверения электронной копии бумажного документа с подписью и печатью.
Не менее значительную часть отношений закон предполагает регулировать взаимной договоренностью сторон (ситуация, уже частично описана в разделе "Кто виноват? и Что делать?"), при этом никак не регламентирована форма такой договоренности (письменный договор и т.п.). Разумеется, фирмы, давно имеющие радость общения с данной проблемой, сей вопрос для себя уже решили, однако и они остаются терзаемы сомнениями: "А не нарушаем ли мы чего-нибудь?".
В законе недостаточно проработаны вопросы разделения ответственности между участниками электронного обмена и удостоверяющими центрами. Выше приведены варианты решений, которые, на наш взгляд, позволяют выполнить такое разграничение. Но необходимо, чтобы эти моменты нашли свое отражение в законе, а не изобретались в каждом конкретном случае отдельно, с риском что-нибудь упустить.
В соответствии с пунктом 1 статьи 8 закона, удостоверяющим центром может быть исключительно коммерческая организация. Данное требование сразу же ущемляет права организаций некоммерческих, а их доля в электронном взаимодействии не так мала, как может показаться (например, OSF). Одним из вариантов разрешения данного противоречия было бы четкое указание, что действие данного закона не распространяется на некоммерческие отношения.
Также не совсем понятно это требование в свете использования ЭЦП государственными организациями, которые также могут вести электронный обмен в системах общего пользования.
В предлагаемом варианте закона предполагается использование исключительно сертифицированных средств ЭЦП, что не позволяет легко использовать ЭЦП в некоторых случаях. Самый очевидный - использование зарубежных сертификатов, средства для работы с которыми вряд ли будут сертифицированы в России.
Необходимо также расставить точки над "i" в вопросах лицензирования. По действующему законодательству техническое обслуживание средств криптографической защиты подлежит лицензированию, однако, это не означает, что каждый участник информационного обмена должен получать такую лицензию (ведь в соответствии с упомянутой выше системой сертификации [2] средства ЭЦП также относятся к СКЗИ) - достаточно, чтобы такую лицензию имел организатор системы.
Пункт 1 статьи 6 требует, чтобы сертификат открытого ключа подписи в обязательном порядке содержал фамилию, имя и отчество владельца. Такая принципиальная позиция о невозможности использования псевдонима вызывает недоумение, т.к. делает невозможным, например, использование ЭЦП для участия в конкурсах под девизом или псевдонимом.
Достаточно спорным представляется и требование к способности УЦ нести гражданскую ответственность в размере не менее, чем в 1000 раз превышающий максимальный предел сделки, указываемый в сертификате. Можно указать целый ряд сделок, в которых указание цены, а, следовательно, и предела ответственности невозможно. Кроме того, такое требование, фактически, дискриминирует форму заключения сделки в электронном виде с использованием ЭЦП - сделки на значительные суммы просто невозможно будет подписать ЭЦП.
Тезис о безвозмездном оказании услуг по подтверждению сертификатов (ст. 9 п.4) логичней было бы заменить ограничением максимального уровня оплаты. Естественно, если принять во внимание поправку о выводе из-под юрисдикции закона некоммерческих применений ЭЦП, автоматически снимутся вопросы с оплатой в некоммерческих системах.
Закон подразумевает использование ЭЦП как аналога подписи физического лица, даже если подпись ставится им не как частным лицом, а как уполномоченным представителем юридического лица. Данное положение представляется логичным, дабы, в соответствии с заветами Окамма, не плодить новых сущностей в виде понятия "подпись юридического лица", и просто проецирует сложившиеся в "бумажном" обороте отношения. Однако, во избежание недоразумений, в сертификате открытого ключа, оформляемом должностному лицу, необходимо указывать, что выдан он не просто Сидорову, а Председателю правления Сидорову Ивану Петровичу, действующему на основании доверенности или Устава предприятия. Легко заметить, что в данном случае Сидоров Иван Петрович имеет два сертификата и как физическое лицо, и как уполномоченное лицо некоего юридического лица.
Таким образом, этот без сомнения нужный и долгожданный закон нуждается в серьезной доработке, т.к. в существующем виде он носит, по большей части, декларативный характер.
Федеральный закон "О лицензировании отдельных видов деятельности".
Постановление Правительства РФ N 326 от 11 апреля 2000 года.
ГОСТ Р 34.10 - 94. Государственный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки, электронной цифровой подписи на базе асимметричного криптографического алгоритма.
Указ президента РФ N 334 от 03.04.1995 "О мерах по соблюдению законности в области разработки, производства, реализации и эксплуатации шифровальных средств, а также предоставления услуг в области шифрования информации" (с изменениями в редакции указа Президента N 1358 от 25.07.2000).
Федеральный закон "Об электронной цифровой подписи" (принят в первом чтении).
ГОСТ Р 34.11 - 94. Государственный стандарт Российской Федерации. Информационная технология. Криптографическая защита информации. Функция хэширования.
ГОСТ 28147 - 89. Государственный стандарт Союза ССР. Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования.
Владислав Мяснянкин - занимается обеспечением защиты информации в банковской сфере с 1994 года. Специализация - защита телекоммуникаций и криптография. В настоящее время работает в банке "Северная казна", г. Екатеринбург.
Андрей Межутков - инженер-системотехник (закончил радиотехнический факультет УГТУ-УПИ). Занимается различными аспектами защиты информации с 1986 года. Преимущественные интересы в области административного и организационно-правового ресурса. В настоящее время - начальник службы автоматизации World Trade Center & Atrium Palace Hotel. г. Екатеринбург.