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

Государственные закупки [1, 2] — не совсем частнокапиталистический рынок, где конкуренция продавцов и личная заинтересованность покупателя служат мощнейшими экономическими стимулами. Государственный чиновник не похож на типичного субъекта рынка. Ему куда проще приобретать товары у одного, возможно, давно знакомого ему поставщика. У него практически нет стимулов для тщательного отбора выгодных для государства предложений. При отсутствии четкой регламентации процесса госзакупок этот сектор быстро становится питательной средой для злоупотреблений.

В России за последние несколько лет принят ряд нормативных документов, касающихся механизма госзакупок. Наиболее существенный из них — Указ Президента РФ «О первоочередных мерах по предотвращению коррупции и сокращению бюджетных расходов при организации закупки продукции для государственных нужд». Этим указом закреплена обязательность конкурсного размещения заказов на закупку продукции для государственных нужд за счет средств федерального бюджета и бюджетов субъектов федерации. Однако в принятых нормативно-правовых актах не учтен новый фактор, способный серьезно повлиять на организацию отношений между госзаказчиком и поставщиками, — массовое распространение в деловой жизни страны ИТ и, прежде всего, Internet. Сегодня госзакупки по-прежнему предполагают исключительно «бумажный» документооборот, что значительно снижает их эффективность. Создание системы конкурсных торгов на базе сетевых технологий [3] чрезвычайно актуально для сегодняшней России. Публикация в Сети всей открытой информации о проводимых торгах и их результатах дает выигрыш в оперативности и общедоступности.

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

При электронном документообороте собственноручную подпись заменяет электронная цифровая подпись (ЭЦП). Вступивший в действие с января 2002 года «Федеральный закон об электронной цифровой подписи» [4] призван создать необходимую правовую основу для такой замены. Закон определяет правовые условия, при соблюдении которых ЭЦП в электронном документе признается равнозначной собственноручной подписи на бумажном документе. Технически равнозначность обеспечивается тем, что ЭЦП гарантирует неизменность (защиту от подделки) подписанного ЭЦП электронного документа, неотрекаемость от подписи и позволяет безошибочно идентифицировать лицо, подписавшее документ (точнее, правомерного владельца закрытого ключа подписи). ЭЦП — неотъемлемая составная часть инфраструктуры открытого ключа (PKI — public key infrastructure).

Электронные госзакупки и PKI

В системе электронных госзакупок [8] непосредственно участвуют: организатор электронных торгов; государственные заказчики; поставщики. Предполагается, что все эти юридические лица обеспечены сертификатами ключей подписи, принадлежащими соответствующим уполномоченным должностным лицам. Там, где на бумажном документе должна быть собственноручная подпись должностного лица, на аналогичном электронном документе ставится его ЭЦП, по закону равнозначная собственноручной. Правильно подписанный электронный документ имеет такую же юридическую силу, что и бумажный. Все юридически значимые действия участников подтверждаются электронными документами с ЭЦП. При необходимости на документах проставляется печать времени (timestamp).

Публикация конкурсной документации

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

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

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

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

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

Подача заявки

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

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

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

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

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

Рис. 2. Шифрование заявки

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

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

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

Вскрытие заявок

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

Рис. 3. Вскрытие заявки закрытым ключом конкурса

Особый путь России

За полтора года пребывания в недрах Государственной Думы закон об ЭЦП [4] претерпел существенные изменения по сравнению с внесенным правительством законопроектом [5] и приобрел сугубо российские особенности. Справедливости ради следует признать, что некоторые изменения можно только приветствовать: например, определения стали более четкими. Однако возникают сильные сомнения в возможности технической реализации предписаний закона с соблюдением общепринятых международных стандартов PKI. В частности, вряд ли возможно использование, например, Microsoft CryptoAPI и Certificate Service. Основными проблемами при технической реализации закона, по нашему мнению, является, например, исключение юридических лиц из числа владельцев сертификата, а также запутанность и непроработанность статуса уполномоченных федеральных органов, призванных надзирать за деятельностью удостоверяющих центров.

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

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

В законе проводится четкое разграничение между изготовлением сертификата и выдачей его пользователям. Сертификат на имя физического лица изготавливается удостоверяющим центром. Необходимые для изготовления сертификата ключи ЭЦП могут быть созданы участником информационной системы самостоятельно или по его просьбе удостоверяющим центром. В последнем случае сохранение тайны закрытого ключа — обязанность удостоверяющего центра. Для создания ключей ЭЦП должны использоваться только сертифицированные средства. Заметим, что в немецком законе об ЭЦП [7] также допускается создание ключей ЭЦП удостоверяющим центром, но закрытый ключ после передачи владельцу должен быть немедленно уничтожен.

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

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

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

Введение этого института логически вытекает из исключения юридических лиц из числа владельцев сертификата, но плохо согласуется с международным стандартом X.509. Согласно этому стандарту подписать сертификат должно лицо, идентификатор которого указывается в качестве изготовителя (поле Issuer). Но по закону удостоверяющий центр (как юридическое лицо) не владеет никакими сертификатами и не может ничего подписывать. Чтобы выйти из этого положения, в проекте российского профиля сертификата, предложенного компаниями «Новый Адам» и «Сигнал-Ком» [6], в поле Issuer указывается все-таки идентификатор удостоверяющего центра, а идентификаторы всех уполномоченных лиц в числе своих атрибутов полностью содержат все атрибуты этого поля. Это позволяет однозначно привязать уполномоченное лицо к своему удостоверяющему центру и дает возможность подписания им любого сертификата, изготовленного этим центром.

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

Уполномоченный федеральный орган

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

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

Печать времени, электронный нотариат

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

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

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

Техническая реализация закона

Чтобы закон действительно заработал, должна быть выстроена достаточно солидная инфраструктура. Необходимо создать уполномоченный федеральный орган, надзирающий за всеми удостоверяющими центрами, организовать систему сертификации удостоверяющих центров и средств ЭЦП. Должна быть выработана правовая регламентация электронного нотариата, без которого невозможно взаимодействие бумажного и электронного документооборотов. Но, прежде всего, нужно конкретизировать положения закона применительно к PKI, разработав соответствующий профиль X.509 и придав ему статус ГОСТ. Учитывая перспективы международного сотрудничества, было бы желательно этот профиль по возможности приблизить к профилю квалифицирующего сертификата (RFC 3039), на который ориентируется ЕС. Это значительно облегчит взаимное признание иностранных сертификатов в электронной форме и соответствующих ЭЦП. Проблемы стандартизации в связи с технической реализацией закона подробно освещены в [6].

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

Заключение

Вступление в силу российского закона об ЭЦП является одним из обстоятельств, позволяющих с оптимизмом оценивать перспективы построения в России системы электронных государственных закупок. Однако и вопросов новый закон породил немало. Среди неупомянутых в статье вопросов наиболее острые — о конкретике отношений между строящейся системой госзакупок и удостоверяющими центрами. Когда появятся первые удостоверяющие центры, действующие в соответствии с законом об ЭЦП? В какой степени их возможности будут отвечать запросам системы госзакупок? Потребуется ли образование специализированного корпоративного удостоверяющего центра госзакупок? Определенный оптимизм вселяют уже состоявшиеся первые шаги в направлении технической реализации закона об ЭЦП. Так, на сервере www.adam.ru появился документ «Состав сертификата открытого ключа ЭЦП» http://www.adam.ru/Pki/cert.phtml, содержащий проект профиля российского сертификата, предлагаемого в рамках работ по согласованию структуры и формата полей сертификата, удовлетворяющего положениям Закона об ЭЦП, международному стандарту X.509 и Рекомендациям RFC 2459, RFC 3039.

Литература

[1] Н.В. Нестерович, В.И. Смирнов. Конкурсные торги на закупку продукции для государственных нужд. — М.: Инфра-М, 2000

[2] Организация и проведение конкурсов на закупку продукции для федеральных государственных нужд: Учебно-методическое пособие для государственных служащих / Под ред. В.И. Смирнова, Н.В. Нестеровича. — М.: ГУ-ВШЭ, 2001

[3] М.М. Горбунов-Посадов, А.В. Ермаков, Д.А. Корягин, Т.А. Полилова. Предпосылки развертывания электронных торгов для государственных нужд. Препринт ИПМ им. М.В. Келдыша РАН, 2001, № 38

[4] Федеральный закон Российской Федерации от 10 января 2002 г. № 1-ФЗ «Об электронной цифровой подписи». Российская газета. № 6, 12 января 2002 г. http://www.rg.ru//official/doc/federal_zak/1-fz.shtm

[5] Проект закона «Об электронной цифровой подписи». http://www.netoscope.ru/ documents/2000/08/04/32.html

[6] Е. Никонова, Д. Копылов, В. Смирнов. Некоторые технологические аспекты реализации Закона об ЭЦП // PC Week, 2002, № 15 http://www.signal-com.ru/rus/articles/2002_04_n15_pc_week.html

[7] German Digital Signature Law. Translated by Christopher Kuner. http://www.kuner.com/data/sig/digsig4.html

[8] М.М. Горбунов-Посадов, А.В. Ермаков, Д.А. Корягин, Т.А. Полилова. Программное обеспечение государственных закупок. Препринт ИПМ им. М.В. Келдыша РАН, 2001, № 46

Алексей Ермаков (ermakov@keldysh.ru), Евгений Хухлаев (huh@keldysh.ru) — сотрудники ИПМ им. М.В. Келдыша РАН (Москва).

Инфраструктура открытого ключа

Защита информации в PKI (public key infrastructure) основана на методе асимметричного шифрования с использованием пары ключей: открытого и закрытого [1].

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

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

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

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

Хорошо известны криптосистемы RSA и ECC. Другие криптосистемы более специализированы и поддерживают не все возможности. Широко применяются криптосистемы, в основе которых лежат алгоритмы, не являющиеся алгоритмами собственно шифрования, но реализующие только технологию ЭЦП. К их числу относятся: российские алгоритмы электронной цифровой подписи ГОСТ Р 34.10-94 и ГОСТ Р 34.10-2001; алгоритм электронной цифровой подписи DSA, входящий в принятый в США стандарт цифровой подписи Digital Signature Standard. Отметим еще криптосистему на базе алгоритма Диффи-Хелмана согласования ключа, применяемого при конфиденциальной передаче информации.

Приемы защиты на базе асимметричного шифрования

Рассмотрим принципиальную схему выработки и проверки ЭЦП с применением алгоритмов асимметричного шифрования.

Рис. I. Схема выработки ЭЦП при асимметричном шифровании

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

Рис. II. Схема проверки ЭЦП при асимметричном шифровании

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

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

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

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

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

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

Сертификат ключа

Для верификации открытого ключа применяется сертификат ключа — электронный документ, связывающий открытый ключ с субъектом, правомерно владеющим соответствующим закрытым ключом. Без такой верификации злоумышленник может выдать себя за любого субъекта, подменив открытый ключ. Для заверения сертификата используется ЭЦП учреждения, издающего сертификаты (удостоверяющий центр, CA — certificate authority). Удостоверяющий центр — основной компонент PKI. Имея открытый ключ удостоверяющего центра, любой субъект может проверить достоверность изданного им сертификата. За достоверность содержащихся в сертификате данных, идентифицирующих правомерного владельца, отвечает издавший его удостоверяющий центр.

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

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

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

Удостоверяющий центр и проверка сертификата

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

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

ЛИТЕРАТУРА

[1] В. Столлингс. Криптография и защита сетей: теория и практика. М: Вильямс. 2001. Пер. с англ.

Международные стандарты PKI

В основе всех международных стандартов PKI лежит стандарт X.509 ITU-T, определяющий формат сертификата ключа и списка отозванных сертификатов. Его рекомендации оставляют много степеней свободы при определении формата сертификата. Каждое более или менее автономное сообщество пользователей PKI конкретизирует его, создавая профиль. Так, профили для использования в Internet (RFC 2549) выпускаются рабочей группой IETF PKI.

Европарламент в директивах, задающих единые рамки для ЭЦП в странах ЕС, ввел понятие «квалифицирующий сертификат». Основанная на нем ЭЦП признается равнозначной собственноручной подписи. IETF выпустила стандарт RFC 3039, основанный на RFC 2549 и определяющий профиль квалифицирующего сертификата. В некоторых других странах (США, Австралия, Швеция) также разработаны профили X.509. В Microsoft разработали программную среду, реализующую PKI, которая де-факто определяет собственный профиль. Все это разнообразие профилей создает значительные трудности для обмена сертификатами.

Сертификат X.509 включает основные поля и поля дополнений. Основные поля должны единообразно интерпретироваться любым программным обеспечением, разрабатываемым в соответствии со стандартами PKI:

  • серийный номер сертификата;
  • идентификатор алгоритма ЭЦП;
  • имя издателя сертификата;
  • период действия сертификата;
  • имя владельца сертификата;
  • открытый ключ владельца сертификата.

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

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

Возможно определение других дополнений по требованиям приложений. Сертификат должен быть подписан ЭЦП издателя сертификата.

На основе стандартов PKI разработаны следующие стандартные протоколы:

  • протокол защищенной электронной почты S/MIME (IETF);
  • SSL и покрывающий его протокол Transport Layer Security (IETF), стандартизующий защиту на транспортном уровне и использующийся при создании защищенных клиент-серверных приложений;
  • SET (Secure Electronic Transactions - Visa, MasterCard), протокол для электронных банковских расчетов и использования пластиковых карт;
  • IPSec (IETF) - протокол криптографической защиты IP на сетевом уровне.