На практике сертификация открытых ключей выполняется следующим образом.
1. Лицо (юридическое или физическое), создавшее себе пару ключей (открытый и закрытый) с помощью средства ЭЦП, должно обратиться в орган, уполномоченный выполнить сертификацию. Этот орган называется Центром сертификации (Certification Authority, CA).
2. Центр сертификации проверяет принадлежность открытого ключа заявителю и удостоверяет этот факт добавлением к открытому ключу своей подписи, зашифрованной собственным закрытым ключом.
3. Любой партнер, желающий вступить в контакт с владельцем открытого ключа, может прочитать удостоверяющую запись с помощью открытого ключа центра сертификации. Если целостность этой записи не нарушена и он доверяет центру сертификации, то может использовать открытый ключ партнера для связи с ним.
► Обратите внимание на тот факт, что центр сертификации заверяет только факт принадлежности открытого ключа конкретному лицу или организации. В опубликованной литературе имеются некорректные утверждения о том, что центр сертификации якобы заверяет добросовестность владельца открытого ключа. Это не так. Сертификация открытого ключа не имеет никакого отношения к добросовестности, платежеспособности, исполнительности и любым другим деловым качествам его владельца. Хороший пример — общегражданский паспорт. Это средство удостоверения только личности его владельца. Паспорт не может и не должен содержать какие-либо данные, характеризующие своего владельца. Для этого служат совершенно иные средства.
Наличие полноценного сертификата открытого ключа говорит о том, что ключ можно использовать для удостоверения личности партнера. Но целесообразность этих отношений центром сертификации не удостоверяется.
Две модели системы сертификации
В этом разделе мы рассмотрим вопрос доверия к сертифицирующему органу. Если, например, в рамках одного министерства существует свой центр сертификации, то, скорее всего, существует и приказ министра, разрешающий доверять сертификатам, подписанным этим центром. То же можно сказать и о других министерствах. Но как быть, если возникают договорные отношения между подразделениями, относящимся к разным ведомствам или между государственными и негосударственными структурами? В этом случае необходима некая система органов сертификации, образующая структуру.
Существует две структурные модели системы сертификации. Первая модель — централизованная. Она имеет иерархический характер и соответствует потребностям служебного документооборота. Вторая модель — децентрализованная. Она имеет сетевой характер и может использоваться в гражданском электронном документообороте.
Централизованная система сертификации. Корневые и доверенные центры
Централизованная модель сертификации — иерархическая. В ее основе находится один уполномоченный орган сертификации. Такой орган называется корневым центром сертификации.
Если чисто технически корневой центр не может обеспечить все запросы на выдачу и проверку сертификатов, поступающие от юридических и физических лиц, то он может сертифицировать другие дополнительные органы, называемые доверенными центрами сертификации.
Доверенные центры тоже могут удостоверять чужие открытые ключи своими закрытыми ключами, но при этом их открытые ключи тоже нуждаются в удостоверении. Их удостоверяет своим закрытым ключом вышестоящий центр сертификации.
Таким образом, участник электронного документооборота, получивший откуда-то открытый ключ неизвестного партнера, может:
а) установить наличие сертификата, удостоверенного электронной подписью центра сертификации;
б) проверить действительность подписи Центра сертификации в вышестоящем центре сертификации;
в) если вышестоящий центр тоже является не корневым, а доверенным, то и его подпись можно проверить в вышестоящем центре, и так далее, пока проверка не дойдет до корневого центра сертификации.
Рассмотрим пример. Допустим, в государстве функции корневого центра сертификации возложены на Центральный банк. Предположим, что Центральный банк, не способный справиться со всем электронным документооборотом страны, открыл несколько доверенных центров сертификации на базе уполномоченных банков: «Бета-Банк», «Гамма-Банк», «Дельта-Банк» и т. д. Допустим, что «Бета-Банк», чей авторитет весьма высок в Тульской области, открыл на базе своего местного филиала доверенный центр сертификации в г. Тула. В этом случае юридические и физические лица Тульской области могут использовать его сертификаты при взаимодействии друг с другом. Однако, когда им придется взаимодействовать с партнером из Ярославской области, тот может не выразить доверие к электронному сертификату, выданному Тульским филиалом «Бета-Банка». В этом случае он проверит сертификат самого филиала по сертификату, выданному «Бета-Банком». Если он никогда с этим банком дел не имел, то может не выразить доверие и этому сертификату. Тогда он проверит сертификат, выданный корневым центром — Центробанком.
Такую проверку надо выполнить только один раз. Убедившись в правомочности доверенного центра сертификации, можно настроить свое программное обеспечение так, чтобы в дальнейшем доверие ему выражалось автоматически. И лишь в тех случаях, когда цепочку сертификатов не удается проследить до ранее проверенного доверенного центра (или до корневого центра), программное обеспечение выдаст предупреждение о том, что открытый ключ не имеет удостоверенного сертификата и пользоваться им нельзя.
► В связи с тем, что в настоящее время как в России, так и в мире структура органов сертификации электронной подписи только начинает складываться, существуют многочисленные самодеятельные, неуполномоченные и, возможно, фиктивные «центры сертификации». Опрометчиво выразив доверие подобному центру, можно неумышленно настроить свое программное средство таким образом, что оно перестанет предупреждать о негодности сертификатов, заверенных данным органом, и сертификатов, выданных его уполномоченными органами.
Столкнувшись с сертификатом, достоверность которого нельзя проследить до корневого центра сертификации, категорически нельзя выражать ему доверие!
Сетевая модель сертификации. Взаимная сертификация
Структура системы сертификации ЭЦП в государстве определяется «Законом об электронной цифровой подписи». Если же таковой закон отсутствует, то могут действовать другие модели системы сертификации, основанные на подзаконных актах или на взаимных договоренностях сторон (в последнем случае они будут иметь правовое значение, только если прямо отражены в двусторонних договорах). Так, например, при отсутствии централизованной структуры доверенных центров сертификации (или параллельно с ней, если Закон это допускает), могут действовать сетевые модели сертификации. Такие модели охватывают группы юридических и физических лиц по ведомственной или, например, картельной принадлежности.
Два юридических или физических лица, вступающих в электронные коммерческие взаимоотношения, могут сами взаимно заверить друг другу открытые ключи, если обменяются ими при личной встрече с предъявлением друг другу учредительных документов или удостоверений личности (для физических лиц). В этом случае у них нет оснований сомневаться в истинной принадлежности открытых ключей.
Однако электронная коммерция должна строиться исходя из того факта, что ее участники не нуждаются в очной встрече. В этом случае две стороны могут договориться о том, что им взаимно заверит ключи третья сторона, которую они выберут сами. Так же могут договориться и прочие участники рынка. В результате возникает сложная структура, в которой все участники связаны, с одной стороны, двусторонними договорными отношениями, а с другой стороны, еще и выполняют функции заверителей для своих традиционных партнеров. С точки зрения отдельного коммерсанта, доверие к его открытому ключу будет тем выше, чем большее количество сертификатов он получит от прочих участников рынка.
Рассмотрим пример. Допустим, клиенту Anna приходится регулярно покупать писчую бумагу у поставщика Bella, и до сих пор проблем в их взаимоотношениях не было, несмотря на то что электронная подпись поставщика никем не была сертифицирована. В этом случае можно говорить о том, что клиент Anna сам сертифицировал для себя открытый ключ своего партнера Bella, выразив ему полное доверие.
Это возможно, если эти партнеры встретились лично и обменялись открытыми ключами «из рук в руки».
Далее предположим, что у клиента Anna возникла потребность в приобретении картриджа для лазерного принтера. Он обращается по электронным средствам связи к поставщику Charly, получает от него открытый ключ и видит, что этот ключ имеет сертификат компании Bella с полным доверием. В этом случае Anna может предположить, что Bella и Charly когда-то тоже встречались лично и взаимно сертифицировали друг другу открытые ключи. Таким образом, возникает ситуация, при которой Anna тоже может доверять ключу Charly, хотя это доверие и не полное (ведь они не встречались), а ограниченное.
Может ли в данном случае клиент Anna отправлять поставщику Charly свои конфиденциальные данные, зашифровав их его открытым ключом? Этот вопрос остается открытым на усмотрение самого клиента. Чем больше среди сертификатов ключа Charly будет таких, которые выданы партнерами, известными клиенту Anna, тем больше доверия к ключу Charly. Далее Anna может по своему усмотрению настроить свое программное обеспечение. Например, можно сделать так, чтобы два или три сертификата с ограниченным доверием рассматривались как один сертификат с полным доверием.
Так работает сетевая модель сертификации. Она связывает между собой группу участников, находящихся в сложной системе взаимоотношений. Еще раз обращаем внимание на то, что, взаимно сертифицируя открытые ключи, а стало быть, и электронные подписи друг друга, никто не принимает на себя ответственность за деловую репутацию партнера. Речь идет только о том, что стороны либо подтверждают факт принадлежности открытого ключа данному партнеру, либо имеют основание на это полагаться. В первом случае они выражают полное, а во втором случае — ограниченное доверие.
Пример структуры электронного сертификата
Структура электронного сертификата закреплена Международным союзом связи в стандарте ITU-T X.509. С этой структурой можно наглядно познакомиться с помощью броузера Internet Explorer, рассмотренного нами выше при изучении службы World Wide Web. Поскольку при занятии электронной коммерцией в Web достаточно часто приходится работать с сертификатами, в эту программу уже встроены некоторые сертификаты, которые могут потребоваться наиболее часто при работе со службами WWW, поставляющими программное обеспечение. Пример сертификата, удостоверяющего центр сертификации компании Microsoft, приведен на рис. 9.4.
Чтобы открыть сертификат, запустите программу Microsoft Internet Explorer 5.0 и дайте команду Сервис → Свойства обозревателя. В открывшемся диалоговом окне Свойства обозревателя выберите вкладку Содержание и на панели Сертификаты щелкните на кнопке Сертификатов — откроется диалоговое окно Диспетчер сертификатов. Далее выберите вкладку Доверенные корневые центры сертификации, в поле Кому выдан разыщите запись Microsoft Root Authority, а в поле Кем выдан убедитесь, что этот самодеятельный центр сертификации выдал сертификат сам себе.
Рис. 9.4. Диспетчер сертификатов в броузере Internet Explorer
В этом нет ничего удивительного. В частности, пока в России не принят закон об ЭЦП, у нас тоже можно встретиться с центрами сертификации, сертифицировавшими себя самолично.
Выделив сертификат Microsoft Root Authority, щелкните на кнопке Просмотр и изучите свойства данного сертификата. На вкладке Общие приведены основные сведения о сертификате (для чего он предназначен), а на вкладке Состав приведена структура полей сертификата (рис. 9.5).
Версия (V3). Стандарт ITU-T X.509 постепенно меняется. В этом поле указано, с какой версией стандарта совместим данный сертификат. Это важно для правильного подбора программ, способных с ним работать. В данном случае речь идет о третьей версии (Version 3).
Серийный номер. Это уникальный номер, присвоенный сертификату организацией, которая его выписывала. Во-первых, он используется для учета выданных сертификатов внутри центра сертификации, а во-вторых, он важен в случае, если сертификат будет отозван при компрометации закрытого ключа владельца. Именно по этому номеру просматривается список аннулированных сертификатов.
Алгоритм подписи (md5RSA). Указывает на то, какой метод несимметричного шифрования был использован при подписании данного сертификата, а также на метод генерации дайджеста (электронной печати).
Рис. 9.5. Пример структуры сертификата
Метод RSA относится к широко распространенным. Он был разработан в 1976 г. на базе новой математической дисциплины — дискретного логарифмирования и назван по именам своих создателей (Ron Rivest, Adi Shamir, Leonard Adleman).
MD5 (Message Digest Algorythm 5) — это метод получения дайджеста сообщения. Он генерирует дайджест длиной 128 бит с помощью хэш-функции. Метод был введен разработчиками алгоритма RSA и, несмотря на то что в последние годы стало известно о некоторых его слабостях, продолжает использоваться преимущественно с сообщениями, зашифрованными алгоритмом RSA.
Поставщик. Сведения, идентифицирующие издателя сертификата (кто выдал сертификат).
Действителен с... Дата начала действия сертификата.
Действителен по... Дата окончания действия сертификата.
Субъект. Сведения, идентифицирующие держателя сертификата (кому сертификат выдан).
Открытый ключ (RSA 2048 bits). Сам сертифицируемый открытый ключ с указанием метода его получения. В данном случае приводится ключ, полученный методом RSA, имеющий длину 2048 бит.
Идентификатор ключа. Это поле является дополнительным. Такие поля принято называть расширениями стандарта. Некоторые производители программного обеспечения вводят подобные расширения для удобств центров сертификации. В данном случае здесь приводится внутренний идентификатор ключа, позволяющий центру сертификации ускорить свои процедуры. Нет гарантий, что расширения стандарта могут быть понятны произвольным средствам ЭЦП.
Алгоритм печати (SHA1). Имеется в виду алгоритм хэш-функции, с помощью которой получен дайджест ключа (электронная печать). В данном случае использован стандартный алгоритм SHA (Secure Hashing Algorithm), разработанный Агентством национальной безопасности США (National Security Agency, NSA) для Национального института стандартов и технологии (National Institute of Standards and Technology, NIST). С помощью этого алгоритма создается «отпечаток» сертификата, имеющий стандартный размер 160 бит.
Печать. Здесь приводится сам дайджест (электронная печать), имеющий для принятого алгоритма размер 20 байтов (160 бит). Необходимость в наличии дайджеста связана с особенностями распространения сертификата в составе программы Microsoft Internet Explorer 5.0. Поскольку никто заранее не может предсказать, каким образом (откуда, из чьих рук) конкретный пользователь получит эту программу вместе с сертификатом, электронная печать гарантирует целостность и неизменность сертификата на всех этапах хранения, распространения и эксплуатации программы.
В качестве примера мы рассмотрели международный стандарт на формат электронного сертификата, введенный Международным союзом связи. Однако не следует забывать, что наряду с ним могут существовать национальные стандарты, стандарты отраслей и ведомств, а также квазистандарты, связанные с отдельными средствами ЭЦП и действующие в ограниченных кругах пользователей данных средств. Обычно структура сертификата специально оговаривается в национальном законодательстве, посвященном электронной коммерции и электронной цифровой подписи, или в постановлениях органов, уполномоченных государством на ведение деятельности, связанной с регулированием отношений, возникающих в сфере электронной коммерции.
9.4. Правовое обеспечение электронной цифровой подписи
Правовое обеспечение электронной цифровой подписи следует понимать не только как совокупность нормативно-правовых актов, обеспечивающих правовой режим ЭЦП и средств ЭЦП. Это гораздо более широкое понятие. Оно лишь начинается с государственного закона об электронной цифровой подписи, но развивается далее и впоследствии охватывает все теоретические и практические вопросы, связанные с электронной коммерцией вообще.
Становление законодательства об электронной подписи
Первый в мире закон об электронной цифровой подписи был принят в марте 1995 г. Законодательным собранием штата Юта (США) и утвержден Губернатором штата. Закон получил название Utah Digital Signature Act. Ближайшими последователями штата Юта стали штаты Калифорния, Флорида, Вашингтон, где вскоре тоже были приняты соответствующие законодательные акты.
В качестве основных целей первого закона об электронной подписи были провозглашены:
минимизация ущерба от событий незаконного использования и подделки электронной цифровой подписи;
обеспечение правовой базы для деятельности систем и органов сертификации и верификации документов, имеющих электронную природу;
правовая поддержка электронной коммерции (коммерческих операций, совершаемых с использованием средств вычислительной техники);
придание правового характера некоторым техническим стандартам, ранее введенным Международным союзом связи (ITU — International Telecommunication Union) и Национальным институтом стандартизации США (ANSI — American National Standards Institute), а также рекомендациям Наблюдательного совета Интернета (IAB — Internet Activity Board), выраженным в документах RFC 1421 — RFC 1424.
Закон состоит из пяти частей:
1. В первой части вводятся основные понятия и определения, связанные с использованием ЭЦП и функционированием средств ЭЦП. Здесь же рассматриваются формальные требования к содержательной части электронного сертификата, удостоверяющего принадлежность открытого ключа юридическому или физическому лицу.
2. Вторая часть закона посвящена лицензированию и правовому регулированию деятельности центров сертификации.
Прежде всего, здесь оговорены условия, которым должны удовлетворять физические и юридические лица для получения соответствующей лицензии, порядок ее получения, ограничения лицензии и условия ее отзыва. Важным моментом данного раздела являются условия признания действительности сертификатов, выданных нелицензированными удостоверителями, если участники электронной сделки выразили им совместное доверие и отразили его в своем договоре. Фактически здесь закрепляется правовой режим сетевой модели сертификации, рассмотренной нами выше.
Кроме того, во второй части закона определен порядок квалификации центров сертификации и контроля за их деятельностью посредством внешнего аудита. Здесь же рассмотрены практические вопросы, связанные с ведением регистров изданных сертификатов и порядком прекращения деятельности центра сертификации.
3. В третьей части закона сформулированы обязанности центров сертификации и владельцев ключей. В частности, здесь рассмотрены:
• порядок выдачи сертификата;
• порядок предъявления сертификата и открытого ключа;
• условия хранения закрытого ключа;
• действия владельца сертификата при компрометации закрытого ключа;
• порядок отзыва сертификата;
• срок действия сертификата;
• условия освобождения центра сертификации от ответственности за неправомерное использование сертификата и средств ЭЦП;
• порядок создания и использования страховых фондов, предназначенных для компенсации ущерба третьим лицам, возникшего в результате неправомочного применения ЭЦП.
4. Четвертая часть закона посвящена непосредственно цифровой подписи. Ее основное положение заключается в том, что документ, подписанный цифровой подписью, имеет ту же силу, что и обычный документ, подписанный рукописной подписью.
5. В пятой части закона рассмотрены вопросы взаимодействия центров сертификации с административными органами власти, а также порядок функционирования так называемых репозитариев — электронных баз данных, в которых хранятся сведения об изданных и отозванных сертификатах.
В целом закон об ЭЦП штата Юта отличается от других аналогичных правовых актов высокой подробностью.
Закон об электронной подписи Германии
Германский закон об электронной подписи (Signaturgesetz) был введен в действие в 1997 г. и стал первым европейским законодательным актом такого рода. Целью закона объявлено создание общих условий для такого применения электронной подписи, при котором ее подделка или фальсификация подписанных данных могут быть надежно установлены.
В Законе прослеживаются следующие основные направления:
• установление четких понятий и определений;
• подробное регулирование процедуры лицензирования органов сертификации и процедуры сертификации открытых ключей пользователей средств ЭЦП (правовой статус, порядок функционирования центров сертификации, их взаимодействие с государственными органами и другими центрами сертификации, требования к сертификату открытого ключа электронной подписи);
• рассмотрение вопросов защищенности цифровой подписи и данных, подписанных с ее помощью, от фальсификации;
• порядок признания действительности сертификатов открытых ключей.
По своему духу германский Закон об электронной подписи является регулирующим.
Закон об электронной подписи США
К моменту написания данной книги Федеральный Закон США об электронной подписи принят Конгрессом, но еще не вступил в действие (он вступает в силу 1 октября 2000 г.). В отличие от аналогичного закона Германии, Федеральный Закон об электронной подписи США является координирующим правовым актом. Это связано с тем, что ко времени его принятия соответствующее регулирующее законодательство уже сложилось в большинстве отдельных штатов.
Как видно из названия Закона (Electronic Signatures in Global and National Commerce Act), его основное назначение состоит в обеспечении правового режима цифровой электронной подписи в электронной коммерции. Подписание Закона Президентом США состоялось в день национального праздника — 4 июля 2000 г. (День независимости), что должно придать этому законодательному акту особое значение. По мнению обозревателей принятие данного закона символизирует вступление человечества в новую эру — эру электронной коммерции.
По содержанию Закон отличается краткостью. Он вводит ограниченное число основных понятий, устанавливает правовой режим электронной подписи и определяет компетенцию государственных органов, ответственных за функционирование ее инфраструктуры. Не сосредоточиваясь на конкретных правах и обязанностях центров сертификации, которым уделяется особое внимание в законодательствах других стран, Федеральный Закон США относит их к понятию инфраструктура ЭЦП и в самых общих чертах оговаривает взаимодействие элементов этой структуры с правительственными органами.
Проект закона об электронной подписи Российской Федерации
В России Федеральный Закон об электронной подписи в настоящее время еще не принят, но с его основными положениями можно познакомиться на примере проекта. Согласно проекту, Закон состоит из пяти глав и содержит более двадцати статей.
1. В первой главе рассмотрены общие положения, относящиеся к Закону. Как и аналогичные законы других государств, российский законопроект опирается на несимметричную криптографию. Основной целью Закона провозглашается обеспечение правовых условий для применения ЭЦП в электронном документообороте и реализации услуг по удостоверению ЭЦП участников договорных отношений.
2. Во второй главе рассмотрены принципы и условия использования электронной подписи. Здесь, во-первых, выражена возможность, а во-вторых, приведены условия равнозначности рукописной и электронной подписи. Кроме того, особо акцентировано внимание на характерных преимуществах ЭЦП:
• лицо может иметь неограниченное количество закрытых ключей ЭЦП, то есть, создать себе разные электронные подписи и использовать их в разных условиях;
• все экземпляры документа, подписанные ЭЦП, имеют силу оригинала.
Проект российского Закона предусматривает возможность ограничения сферы применения ЭЦП. Эти ограничения могут накладываться федеральными законами, а также вводиться самими участниками электронных сделок и отражаться в договорах между ними.
Интересно положение статьи о средствах ЭЦП, в которой закрепляется утверждение о том, что «средства ЭЦП не относятся к средствам, обеспечивающим конфиденциальность информации». На самом деле это не совсем так. По своей природе средства ЭЦП, основанные на механизмах несимметричной криптографии, конечно же, могут использоваться для защиты информации. Возможно, это положение включено для того, чтобы избежать коллизий с другими нормативными актами, ограничивающими применение средств криптографии в обществе.
Важным отличием от аналогичных законов других государств является положение российского законопроекта о том, что владелец закрытого ключа несет ответственность перед пользователем соответствующего открытого ключа за убытки, возникающие в случае ненадлежащим образом организованной охраны закрытого ключа.
Еще одной отличительной чертой российского законопроекта является список требований к формату электронного сертификата. Наряду с общепринятыми полями, рассмотренными нами выше, российский законодатель требует обязательного включения в состав сертификата наименования средств ЭЦП, с которыми можно использовать данный открытый ключ, номер сертификата на это средство и срок его действия, наименование и юридический адрес центра сертификации, выдавшего данный сертификат, номер лицензии этого центра и дату ее выдачи. В зарубежном законодательстве и в международных стандартах мы не находим требований столь подробного описания программного средства ЭЦП, с помощью которого генерировался открытый ключ. По-видимому, это требование российского законопроекта продиктовано интересами безопасности страны.
► Массовое применение программного обеспечения, исходный код которого не опубликован и потому не может быть исследован специалистами, представляет общественную угрозу. Это относится не только к программным средствам ЭЦП, но и вообще к любому программному обеспечению, начиная с операционных систем и заканчивая прикладными программами.
Россия не единственная страна в мире, проявляющая осторожность в вопросе применения на своей территории закрытых программных средств с неопубликованным содержанием, не прошедшим всесторонней проверки в виде исходного кода. Беспечность в этом вопросе может приводить к стратегическому ущербу не только в смысле государственной, но и в смысле экономической безопасности. Такую же осторожность проявляют Франция, Китай и некоторые другие страны.
3. В третьей главе рассмотрен правовой статус центров сертификации (в терминологии законопроекта — удостоверяющих центров открытых ключей электронной подписи). В России оказание услуг по сертификации электронной подписи является лицензируемым видом деятельности, которым могут заниматься только юридические лица. Удостоверение электронной подписи государственных учреждений могут осуществлять только государственные удостоверяющие центры.
Законопроект предусматривает материальную ответственность удостоверяющего центра за убытки лиц, пострадавших в результате доверия к сведениям, указанным в сертификате, которые центр был обязан проверить и подтвердить. Эта ответственность исчисляется в размере реального ущерба и не включает штрафные санкции, упущенную выгоду, возмещение морального вреда.
По своему характеру структура органов сертификации — централизованная иерархическая.
4. Содержание четвертой главы российского законопроекта определяет самые общие черты порядка использования электронной цифровой подписи. Важным положением этой главы является то, что в корпоративных информационных системах использование ЭЦП может регламентироваться внутренними нормативными документами системы, соглашениями между участниками системы или между ее владельцами и пользователями. Указанные нормативные документы или соглашения должны содержать положения о правах, обязанностях и ответственности лиц, использующих ЭЦП, а также о распределении рисков убытков при использовании недостоверной ЭЦП между участниками системы.
5. Пятая глава законопроекта называется «Заключительные положения» и рассматривает:
• вопросы признания иностранных сертификатов на открытые ключи электронной подписи;
• вопросы использования документов, подписанных ЭЦП, в судебном разбирательстве;
• ответственность за нарушение законодательства при использовании ЭЦП;
• порядок разрешения споров.
Международное признание электронной подписи
Важный шаг в деле координации законодательств различных государств в области электронной цифровой подписи предприняла Комиссия Организации Объединенных Наций по международному торговому праву (UNCITRAL). Она разработала модельный закон, который предлагается использовать в качестве основы при разработке национальных законодательств. Этот закон был опубликован в 1995 г.
Сегодня в большинстве национальных законодательных актов вопрос международного признания электронной подписи (и связанных с ней ключей и их сертификатов) обеспечивается включением соответствующих положений. В частности, обычно в них говорится, что электронная подпись, которая может быть проверена открытым ключом, имеющим иностранный сертификат, признается таковой, если с государством, орган которого выдал сертификат, имеется договор о признании таких свидетельств.
Однако существуют и другие интересные правовые конструкции. Так, например, в Своде правительственных актов штата Калифорния (California Government Code) сказано, что «...цифровая подпись — это электронный идентификатор, созданный средствами вычислительной техники, обладающий всеми необходимым атрибутами полноценной общепризнанной подписи, как то: уникальностью и возможностью проверки; находящийся в нераздельном распоряжении своего владельца, связанный с документом таким образом, что при изменении документа подпись нарушается, а также признанный в качестве стандартного по крайней мере двумя из следующих организаций:
• Международный союз связи ITU;
• Национальный институт стандартизации США ANSI;
• Наблюдательный совет Интернета IAB;
• Национальный институт технологии и науки США NIST;
• Международная организация по стандартизации ISO».
Это пример гибкого подхода к признанию международных документов, подписанных электронной подписью.
Практическое занятие
На этом занятии мы отработаем приемы практической работы с программным средством ЭЦП. В качестве учебного средства используется программа Pretty Good Privacy (PGP), получить которую можно на одном из многочисленных серверов, поставляющих бесплатное и условно-бесплатное программное обеспечение.
В России имеются нормативно-правовые акты, ограничивающие эксплуатацию нелицензированных программных средств, основанных на криптографии. В связи с этим правовой режим практической эксплуатации программы PGP на территории России в настоящее время не определен. В данном случае речь идет только об ее использовании в качестве наиболее доступной учебной модели.
Упражнение 9.1. Создание ключей в системе PGP
15 мин
Это и последующие упражнения предполагают, что на компьютере установлена программа PGP, автоматически стартующая при запуске операционной системы.
1. Щелкните на значке PGPtray на панели индикации правой кнопкой мыши и выберите в контекстном меню пункт PGPkeys. Откроется окно служебного средства PGPkeys.
2. Щелкните на кнопке Generate new keypair (Сгенерировать новую пару ключей). Произойдет запуск Мастера генерации ключей (Key Generation Wizard). Щелкните на кнопке Далее.
3. Введите свое полное имя в поле Full name (Полное имя) и свой адрес электронной почты в поле Email address (Адрес электронной почты). Открытые ключи, не содержащие полной и точной информации, не воспринимаются всерьез. Щелкните на кнопке Далее.
4. Установите переключатель Diffie-Hellman/DSS. Это более современный алгоритм генерации пары ключей. Щелкните на кнопке Далее.
5. Установите переключатель 2048 bits (2048 бит), определяющий длину ключа. Щелкните на кнопке Далее. (По надежности ключ такой длины соответствует примерно 128-битному ключу для симметричного шифрования.)
6. Для данного упражнения установите переключатель Key pair never expires (Пара ключей действует бессрочно). На практике рекомендуется задавать ограниченный срок действия ключей. Щелкните на кнопке Далее.
7. Дважды введите произвольную парольную фразу (Passphrase) в соответствующие поля. Так как в данном случае реальная секретность не существенна, можно сбросить флажок Hide Typing (Скрыть ввод), чтобы вводимый текст отображался на экране. Рекомендуется, чтобы парольная фраза легко запоминалась, но при этом содержала пробелы, буквы разного регистра, цифры, специальные символы. Качество (трудность подбора) ключевой фразы отображается с помощью индикатора Passphrase Quality (Качество ключевой фразы). Удобно использовать какую-нибудь известную цитату или пословицу на русском языке, но вводить ее в латинском регистре. После того как парольная фраза введена дважды, щелкните на кнопке Далее.
8. Просмотрите за процессом генерации пары ключей, что может занять до нескольких минут. После появления сообщения Complete (Готово) щелкните на кнопке Далее. Затем может потребоваться еще несколько щелчков на кнопках Далее и, в конце, Готово, чтобы завершить создание ключей (публикацию ключа на сервере выполнять не следует).
9. Посмотрите, как отображается только что созданный ключ в списке Keys (Ключи). Убедитесь, что этот ключ автоматически подписывается его создателем, который, как предполагается, абсолютно доверяет самому себе.
10. Щелкните на ключе правой кнопкой мыши и выберите в контекстном меню пункт Key Properties (Свойства ключа). Ознакомьтесь со свойствами ключа, в том числе с «отпечатком» (fingerprint), предназначенным для подтверждения правильности ключа, например по телефону. Убедитесь, что установлен флажок Implicit Trust (Полное доверие), указывающий, что вы доверяете владельцу данного ключа, то есть самому себе.
► В этом упражнении мы научились создавать пару ключей, используемых для несимметричного шифрования в системе PGP. Мы также познакомились с механизмом доверия, используемым для подтверждения подлинности ключей.
Упражнение 9.2. Передача открытого ключа PGP корреспондентам
Мин
1. Щелкните на значке PGPtray на панели индикации правой кнопкой мыши и выберите в контекстном меню пункт PGPkeys. Откроется окно служебного средства PGPkeys.
2. Выберите в списке ключ, который планируется передать корреспонденту, и дайте команду Edit → Copy (Правка → Копировать).
3. Запустите используемую по умолчанию программу электронной почты. Далее мы будем предполагать, что это программа Outlook Expre