Улучшенный ключ сертификата что это
Усовершенствованная квалифицированная подпись
Что такое УКЭП?
Формат усовершенствованной подписи предусматривает включение в электронную подпись информации о времени создания подписи (TSP) и о статусе сертификата электронной подписи (OCSP) в момент подписания (действителен или отозван).
Время создания электронной подписи удостоверяется электронной подписью специального сервера точного времени. Для этого в процессе создания электронной подписи происходит обращение к серверу, создается метка точного времени, которая и сохраняется в электронной подписи.
Правовой статус сертификата электронной подписи на момент подписи обеспечивается электронной квитанцией Удостоверяющего центра, полученной в момент подписи по средствам OCSP. Документ содержит статус запрашиваемого сертификата, на который также ставится штамп времени, подтверждающий их целостность в момент проверки. Статус так же сохраняется в электронной подписи.
Для чего нужна УКЭП?
УКЭП поможет доказать юридическую значимость документа в спорных ситуациях. Например, когда помимо авторства и целостности документа (которые дает обычная КЭП) необходимо подтвердить, что сертификат был действителен в момент подписания документа.
УКЭП — необходимое условие для самостоятельного архивного хранения документов, удостоверенных квалифицированной электронной подписью. Подлинность подписи в этом случае может быть подтверждена и по прошествии длительного периода времени, в том числе после окончания срока действия самого сертификата.
Метка времени и служба статусов также являются условием электронного документооборота с информационными системам некоторых государственных служб, например, Федеральной таможенной службы.
Улучшенный ключ сертификата что это
Не задан ID пользователя.
Если начинать с базовых понятий, электронное подписание основывается на асимметричных алгоритмах шифрования. Основная особенность этих алгоритмов в том, что для шифрования и расшифровки сообщения используются два разных ключа. Широкой общественности более знакомы симметричные алгоритмы, когда одним ключом (или паролем) мы и шифруем и расшифровываем сообщение, например архивируем файл с паролем или защищаем документ MS Word.
На асимметричных алгоритмах шифрования основаны многие вещи, хотя сам по себе тот факт, что для шифрования и расшифровки используются разные ключи, ещё не позволил бы найти сколько-нибудь полезного применения этим алгоритмам. Для этого они должны обладать ещё некоторыми дополнительными свойствами. Во-первых, ключи не должны быть вычисляемыми, то есть зная один ключ вы не можете вычислить второй. Также очень важно, чтобы разным ключам шифрования соответствовали разные ключи расшифровки и наоборот — одному ключу расшифровки соответствовал только один ключ шифрования.
При чем тут собственно подпись? Ведь нам надо подписать документ, а не зашифровать его. Для начала надо разобраться, что такое собственно подпись и для чего она нужна. Когда вы ставите свою собственноручную подпись на бумажный документ, вы тем самым заверяете, что именно вы (а не кто-то другой) видели (и согласны) именно этот документ (а не какой-то другой). Важнейшее свойство подписи — неотрекаемость (non-repudiation). Это означает, что подписав документ, вы не можете позже отказаться от этого факта. В случае бумажной подписи вас уличит графологическая экспертиза, в случае электронной — математические методы, основанные на асимметричных алгоритмах шифрования.
Как все это работает, в двух словах. Берем асимметричный алгоритм шифрования, генерируем пару ключей (для шифрования и расшифровки). Ключ шифрования даем человеку, который будет подписывать документы. Он его должен всегда держать при себе и никому не давать. Поэтому его называют «закрытый» ключ. Другой ключ (расшифровки) даем всем желающим, поэтому он «открытый». Подписывая документ, человек должен зашифровать его своим закрытым ключом. На самом деле шифруется не сам документ, так как он может быть достаточно большим, а нам вообще-то и не нужно его шифровать. Поэтому по документу получают хэш — это некая числовая последовательность с большой долей вероятности разная для разных документов, как бы «отпечаток» документа. Его и шифруют закрытым ключом подписанта. Этот зашифрованный хэш и есть электронная подпись документа. Теперь имея документ, подпись и открытый ключ, любой может легко проверить, что именно этот документ был подписан именно этим закрытым ключом. Для этого снова получаем хэш документа, расшифровываем открытым ключом подпись и сравниваем. Должны получить две идентичные числовые последовательности.
Все это прекрасно, но пока мы получили неотрекаемость подписи для закрытого ключа, то есть доказали, что документ подписан конкретным ключом. Нам же необходимо доказать, что он был подписан конкретным человеком. Для этого существуют удостоверяющие центры и цифровые сертификаты. Самое важное, что делает удостоверяющий центр — он удостоверяет, что закрытый ключ принадлежит конкретному лицу. Чтобы это гарантировать, именно удостоверяющий центр генерирует пары ключей и выдает их лично в руки владельцам (есть варианты по доверенности, удаленно, но это уже детали). Вместе с ключами генерируется цифровой сертификат — это электронный документ (бывает и бумажное его представление), в котором содержится информация о владельце ключа, самом ключе, удостоверяющем центре и некоторая другая информация. Владелец, как правило, получает все это добро на защищенном носителе (смарт-карте, ру-токене и так далее), на котором содержится закрытый ключ и сертификат с внедренным открытым ключом. Сам носитель необходимо всегда держать при себе, а скопированный с него сертификат с открытым ключом можно давать всем желающим, чтобы они могли проверить вашу электронную подпись.
Итак, подписание производится закрытым ключом, а проверка подписи открытым. Поэтому фраза «документ подписывается набором OID» (прозвучавшая в упомянутом споре) лишена всякого смысла. В процедуре подписания и проверки участвуют только два ключа, в 63-ФЗ они и названы соответственно — ключ подписи и ключ проверки подписи.
А что такое эти пресловутые OID? Формат цифрового сертификата X.509 позволяет сохранять в нем расширения (extensions). Это некие необязательные атрибуты, при помощи которых можно хранить дополнительную информацию. Каждый такой атрибут является объектом, который задается идентификатором из иерархического справочника. Отсюда OID — Object Identifier. Углубляться в природу самих OID здесь смысла нет. По сути это некоторая дополнительная информация, которая может присутствовать в сертификате.
Данные дополнительные атрибуты могут использоваться для разных целей. Они могут либо предоставлять дополнительную информацию о владельце, ключах, УЦ, либо нести какую-то дополнительную информацию для приложений и сервисов, которые этот сертификат используют. Самое распространенное применение — это управление доступами на основе ролей. Например, в сертификате можно прописать, что владелец ключа является руководителем организации, и это даст ему возможность сразу во всех ИС получить доступ к нужным функциям и сведениям, без необходимости связываться с администраторами каждой ИС и менять настройки доступа. Все это конечно при условии, что все эти ИС используют сертификат пользователя для его авторизации и анализируют один и тот-же атрибут одинаковым образом (для того-то атрибуты и выбираются из справочника, а не задаются произвольно).
Как видим, никакие законодательные нормы не диктуют обязательного наличия в квалифицированном сертификате атрибутов, связанных с авторизацией в каких-либо информационных системах. Откуда тогда эти требования берутся? А исходят они от разработчиков (или «владельцев») конкретных систем. Возьмём например «Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)», размещенные на технологическом портале СМЭВ. Действительно, в пункте 6 данного документа читаем: «При подготовке сведений для формирования сертификата ЭП-СП необходимо определить необходимость запроса сведений из Росреестра (выписки из ЕГРП). При необходимости такого запроса в поле “Улучшенный ключ” (OID=2.5.29.37) в сертификате ЭП-СП должен быть указан OID по требованиям Росреестра.». То есть информационная система Росреестра использует этот атрибут для определения сведений, которые можно выдавать владельцу сертификата. Однако этот же документ содержит важное примечание, а именно — данное требование действует до полного запуска ЕСИА (единый сервис авторизации в гос. системах) и подключения к ней системы Росреестра. Это важное замечание, запомним его.
Не буду разбираться с другими ИС, применяемыми в гос. органах. Подозреваю, что там ситуация похожая. Портал госзакупок, электронные торговые площадки, различные бухгалтерские и финансовые приложения также могут требовать наличия тех или иных дополнительных OID в сертификате пользователя. При этом утверждение, что прописывая OID информационной системы в сертификате, я каким-либо образом делегирую ответственность удостоверяющему центру, мягко говоря, неверно. УЦ вносит эти данные в сертификат согласно моей заявки. Если у меня изменилась должность, а я забыл подать заявку на отзыв старого и выпуск нового сертификата, УЦ никак не может отвечать за мою забывчивость. К тому-же закон 63-ФЗ прямо закрепляет ответственность за неправильное использование сертификата за его владельцем. В пункте 6 статьи 17 читаем:
Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
2) использовать квалифицированную электронную подпись в соответствии с ограничениями, содержащимися в квалифицированном сертификате (если такие ограничения установлены).
Необходимость хранить в сертификате сведения о ролях и доступах пользователя в конкретных информационных системах приводит к проблеме, из-за которой разгорелся спор в фейсбуке, а именно — сертификат приходится перевыпускать гораздо чаще, чем это диктуют требования безопасности к персональной электронной подписи. Поменялась должность — перевыпускаем сертификат. Появилась новая ИС — перевыпускаем сертификат. Появилась необходимость запроса сведений из ИС новой организации (Росреестр) — перевыпускаем сертификат.
Налицо стопроцентное попадание в концепцию, именуемую в мире Attribute Certificate (или Authorization Certificate), о которой говорилось выше и при которой рекомендуется выпускать эти сертификаты другим удостоверяющим центром (Attribute Autority, в отличие от Certificate Authority — обычного УЦ, выпускающего квалифицированные сертификаты ЭП) и по упрощенной схеме. Этот сертификат сам по себе не должен содержать ключа электронной подписи и информации о владельце. Вместо этого он содержит ссылку на сертификат открытого ключа владельца, из которого можно получить остальную необходимую информацию о персоне.
Необходимо заметить, что и эта схема имеет весьма ограниченное применение и не решает всех проблем. Что если очередная информационная система решит использовать то-же поле сертификата “Улучшенный ключ” (OID=2.5.29.37), которое уже занято значением Росреестра, для своих нужд? Вписать два разных значения в одно поле не получится. Следовательно придется выпускать ещё один AC! Другая проблема связана с коротким временем жизни PKC (один год). Если имеем несколько AC (в которых содержится ссылка на персональный сертификат), их все придется перевыпустить по истечении срока PKC. Для эффективного применения AC необходим некий единый центр авторизации пользователей во всех информационных системах, а все приложения должны согласованно и единообразно использовать атрибуты сертификатов.
Такой единый центр авторизации для гос. органов уже есть — это ЕСИА. Вспомним про примечание, касающееся OID’ов Росреестра. В будущем они будут заменены информацией из ЕСИА. Так же должны поступать и прочие информационные системы, в которых работают гос. служащие. Вместо использования AC для авторизации, необходимо интегрироваться с ЕСИА и получать необходимую информацию оттуда. ЕСИА должна иметь возможность привязки квалифицированного сертификата ЭП к учетной записи, таким образом информационные системы смогут проводить аутентификацию пользователя по персональному ключу, а его авторизацию (предоставление доступа к приложению) через ЕСИА. Такая система представляется универсальней и надежней, чем применение полей сертификатов, а в перспективе позволит автоматизировать управление доступами. Если будет создана единая система кадрового учета гос. служащих, ЕСИА сможет брать информацию о полномочиях того или иного лица непосредственно оттуда. Перевелся человек на другую должность — автоматически потерял доступ к одним системам и получил к другим. При этом он продолжает пользоваться своим ключом ЭП для подписания документов, ничего перевыпускать не нужно.
Вывод — OID’ы информационных систем в сертификате, не являясь абсолютным злом сами по себе, требуют взвешенного применения. У данного подхода есть альтернативы, которые стоит рассмотреть, например единые сервисы авторизации.
Что такое сертификат ключа электронной подписи
Из нашей статьи вы узнаете:
О сертификате: что это такое
Сертификат ключа ЭЦП — это документ, несущий информацию о владельце. В открытом ключе зашифрованы данные о статусе владельца, реквизитах и полномочиях. Сертификат подтверждает принадлежность ключа конкретному лицу, отвечающему за его применение. Документ имеет электронный цифровой или бумажный вариант. Выдача сертификата электронного ключа происходит в удостоверяющем центре. Вся информация о сертификатах хранится в едином федеральном реестре. УЦ гарантирует соответствие предоставленных данных действительности, подтверждает личность владельца и защищает цифровой ключ от взлома.
Электронная цифровая подпись (ЭЦП) — аналог рукописного варианта подписи владельца. Используется в документообороте и при работе с электронными системами управления финансами. ЭП составляет электронный сертификат, выданный удостоверяющим центром. В ней зашифрованы данные о владельце, внесенные в базы единого реестра. ЭЦП применима в работе с судами, биржами, при сдаче документов в налоговые службы и т. д.
Цифровой аналог реальной подписи делится на квалифицированный и неквалифицированный тип. В зависимости от профиля у электронного сертификата есть уровень допуска для работы с теми или иными ресурсами. Квалифицированный вариант обладает самой высокой степенью защиты, благодаря чему его применяют в операциях с недвижимостью, финансами и для подписания документов. Подписание квалифицированным типом договоров или соглашений принимается в судах, на биржах, торгах. У квалифицированного сертификата шире область действия, поскольку он обеспечивает большую степень защиты.
Информация о сертификатах хранится в базах Единого реестра ЕСИА. Вносить данные имеют право удостоверяющие центры, прошедшие сертификацию. Все УЦ делятся на аккредитованные и неаккредитованные.
Для чего нужен сертификат
Рукописная подпись имеет юридическую силу, так как подтверждается присутствующей личностью. В электронном документообороте гарантией сделки служит квалифицированный сертификат, поскольку в нем содержится вся информация об участнике процесса, она подтверждает принадлежность ЭЦП владельцу.
Подделку или махинации с подписанием документов предотвращает ключ. Он кодируется методом криптографии, делится на открытый и закрытый. Кодирование настолько сложно, что полностью исключает взлом. Только владелец токена с подписью может внести данные в документ, засвидетельствовав свое согласие на сделку или передачу информации.
Открытый и закрытый ключ
Открытый ключ доступен лицам, участвующим в документообороте или сделке. Закрытый известен исключительно владельцу, его нельзя определить, используя открытый ключ. Выданный на них сертификат легализирует оба ключа, обеспечивает их взаимодействие с системой. Через него утверждаются сроки начала и окончания работы ключей.
Подпись на документе ставится открытым ключом. В момент проверки информации от открытого ключа к закрытому идет сигнал. Подпись проходит проверку на соответствие внесенных в базу данных о владельце. Если информация совпадает, идет подтверждение подлинности личности владельца. В таком случае сделка или акт подписания считаются легальными.
Удостоверяющие центры: какие УЦ могут выдавать усиленные сертификаты
Электронную подпись имеют право выдавать центры, получившие сертификацию в Едином федеральном центре. В каждом регионе работает от 20 до 50 таких заведений. Сертификация дает им правом собирать информацию о гражданах и работать с ней, выдавать сертификаты и создавать подписи. Полученная от граждан, юридических лиц и организаций информация заносится в Единый реестр, где используется для идентификации личности владельца подписи. Всего в России существует более 400 удостоверяющий центров.
Что такое аккредитованный удостоверяющий центр
Аккредитованный удостоверяющий центр (УЦ) — это организация, получившая доступ к Единому реестру, имеющая право на сбор и хранение ключевой информации. Она имеет право на создание квалифицированного электронного сертификата и распространение лицензий на криптографию. В распоряжении организации доступ к ПО, обеспечивающему кодировку, и управлению структурой ЭП.
Организация обслуживает серверы, с которых пользователи ЭЦП получают информацию и доступ к законодательной базе по подписям. УЦ обслуживает владельца подписи, обновляя дату истечения срока работы сертификата ЭП и устраняя ошибки в работе токена.
В УЦ можно продлить, аннулировать или заказать новую подпись. Чтобы подписывать документы в электронном виде, необходимо иметь квалифицированный электронный сертификат. Именно такую услугу оказывают УЦ.
Удостоверяющий центр выдает исключительно квалифицированные сертификаты. Получение в УЦ сертификата гарантирует достоверность и безопасность ключа электронной подписи. Для работы с кодами используется специальное ПО, обеспечивающее защиту исходных данных. Сертификат из центра гарантирует предотвращение подделок и взлома, для чего используется уникальная система шифрования.
Познакомиться со списком сертифицированных удостоверяющих центров можно на сайтах ФНС и Минкомсвязи. В специальном разделе по регионам указаны действующие организации. Здесь же можно проверить данные о закрытых и лишенных лицензий организациях, узнать, кому переданы права и полномочия после закрытия.
Состав: из чего состоит сертификат ЭП
Электронная подпись имеет вид буквенно-цифрового кода или графического изображения. В работе с сертификатами используется специализированное ПО, обеспечивающее шифрование информации. Чтобы получить подпись, будущий владелец должен предоставить о себе достоверные данные, подав документы в удостоверяющий центр.
Составляющие сертификата подписи:
Перед получением производится подробная проверка указанных данных. Только после подтверждения происходит выдача лицу электронного сертификата. Выполняются изготовление и передача носителя с ключом. Чтобы создать и подписать юридический документ, владельцу необходимо установить специализированное ПО.
На официальных порталах программ производителей выложен инструкции, как пользоваться ЭП в их программах (Microsoft Office, Acrobat Reader и других). Через установленное на ПК программное обеспечение наносится скрипт подписи. После нанесения ЭП документ не может быть изменен сторонними лицами.
Электронная подпись для чайников: с чем ее есть и как не подавиться. Часть 2
Продолжая раскрывать тайное знание о цифровой подписи простым языком, разберем, что же нам надо для удобной и эффективной работы с ними, а также главное различие между лагерями S/MIME + X.509 и PGP.
Перед тем, как рассматривать особенности этих двух больших лагерей, стоит рассмотреть, какая информация нужна получателю для проверки подписи (а наш зашифрованный хэш уже вполне можно называть подписью), и в каком виде ее можно ему передать.
Каждую из частей информации можно передать вместе с открытым ключом, или вместе с нашей подписью, а можно и с тем и с тем, для большего удобства. Конечно, можно не разделять информацию на передаваемую с открытым ключом и передаваемую с подписью. Но тогда каждый раз отправляя подписанную информацию мы отправляем одно и то же. Как если бы к каждому отправляемому нами бумажному письму (даже короткому, в две строки), мы бы прикладывали дополнение вида «Здравствуйте! Это я, В. Пупкин, которого вы встречали на Красной площади Москвы, где мы и познакомились, потом пошли в ресторан, потом ». Согласитесь, слегка неудобно.
Но вернемся к нашей информации, необходимой для проверки подписи.
Начнем с простого: информация, которая позволит нам узнать, кто же сделал эту подпись. Как мы уже договорились, ассиметричное шифрование позволяет однозначно связать наш открытый ключ и полученную подпись. Беда в том, что сам по себе открытый ключ – набор байт. При этом он, конечно, связан с закрытым, которым мы (то есть отправитель) владеем, но связь эта для получателя неочевидна. У него есть набор байт от В. Пупкина, от И. Петрова, от С. Сидорова… И от десятка других людей. И как ему их идентифицировать? Держать отдельный реестр для того, кому какой набор байт принадлежит? Это что же, получается уже второй реестр (помимо того, где должно быть записано, с помощью какой хэш-функции какой хэш сделан)! И опять, неудобно!
Значит, надо связать каждый открытый ключ с информацией о том, кому этот ключ принадлежит, и присылать это все одним пакетом. Тогда проблема реестра решается сама собой – пакет (а если более правильно, контейнер) с открытым ключом можно будет просто посмотреть и сразу понять его принадлежность.
Но эту информацию все так же надо связать с подписью, пришедшей получателю. Как это сделать? Надо соорудить еще один контейнер, на сей раз для передачи подписи, и в нем продублировать информацию о том, кто эту подпись создавал.
Продолжая нашу аналогию с красивым замком, мы пишем на ключе «Этот ключ открывает замок В. Пупкина». А на замке тоже пишем «Замок В. Пупкина». Имея такую информацию, получатель нашей коробочки не будет каждый из имеющихся у него ключей вставлять наугад в наш замок, а возьмет наш ключ и сразу его откроет.
Теперь, по переданной информации при проверке можно найти контейнер открытого ключа, взять оттуда ключ, расшифровать хэш и…
А собственно, что «и»? Мы ведь пока так и не решили проблему, как донести до получателя информацию о том, какая хэш-функция применялась для хэша, а ведь для проверки подписи эта информация необходима! Решить ее можно достаточно просто: положить эту информацию в контейнер вместе с нашим открытым ключом. Ведь именно связка «хэширование – шифрование результата хеширования» считается процедурой создания цифровой подписи, а ее результат – подписью. А значит, достаточно логичным представляется объединение в связку алгоритма шифрования хэша и хэш-функции, с помощью которой он сформирован. И доставлять эту информацию тоже надо в связке.
Теперь, ненадолго вернемся к информации о подписывающем. Какого рода эта информация должна быть? ФИО? Нет, В. Пупкиных много. ФИО + год рождения? Так и родившихся в один день В. Пупкиных тоже предостаточно! Более того, это может быть Василий, Виктор, или даже Василиса или Виктория Пупкины. Значит, информации должно быть больше. Ее должно быть столько, чтобы совпадение всех параметров, по которым мы идентифицируем человека, было максимально невероятным.
Безусловно, такой пакет информации создать возможно. Вот только, работать с ним уже трудновато. Ведь надо наши контейнеры открытых ключей надо сортировать, хранить, использовать, в конце концов. А если для каждого использования придется указывать по полсотни параметров, то уже на втором контейнере станет понятно, что что-то надо менять. Решение этой проблемы, конечно же, было найдено.
Чтобы понять, в чем же оно заключалось, обратимся к бумажному документу, который есть у всех нас: к паспорту. В нем можно найти и ФИО, и дату рождения, и пол, и много другой информации. Но, главное, в нем можно найти серию и номер. И именно серия и номер являются той уникальной информацией, которую удобно учитывать и сортировать. Кроме того, они существенно короче всей оставшейся информации вместе взятой, и при этом все так же позволяют опознать человека.
Применяя этот же подход к контейнерам открытых ключей, мы получим, что у каждого контейнера должен быть некий номер, последовательность символов, уникальная для него. Эту последовательность символов принято называть идентификатором, а сами контейнеры – сертификатами, либо просто ключами.
Вот здесь и начинаются принципиальные различия в идеологиях OpenPGP и S/MIME + X.509. Для краткого понимания их, вернемся к нашей аналогии с паспортом.
С другой стороны, в кругу друзей, или внутри компании вам достаточно представиться так: «В. Пупкин из твоей группы в институте» или же «В. Пупкин из отдела продаж». И людям, с которыми вы контактируете в этом кругу уже не нужна третья сторона, они и так помнят Пупкина из группы с которым проучились пять лет, или Пупкина из отдела продаж, с которым недавно ходили обедать, и предоставленной вами информации им вполне достаточно.
Так же можно разделить и эти два лагеря.
Сертификат X.509 – это аналог нашего паспорта. Здесь сертификаты вам выдаются суровой третьей стороной, гарантом вашей личности: Удостоверяющим Центром (УЦ). Получающий ваши подписи человек всегда может обратиться в УЦ и спросить интересующую его информацию по вот этому конкретному сертификату.
PGP же (и стандарт OpenPGP, появившийся в дальнейшем) создавался на основе так называемых сетей доверия. Такая идея подразумевает, что обмениваются подписями люди, которым третья сторона для их взаимоотношений не нужна, а нужна только защита от нехороших лиц.
Конечно, с течением времени такое разделение стало уже достаточно условным, так как на данный момент и в S/MIME+X.509 и в PGP можно использовать методы лагеря соперников. Но все же, стандарты достаточно продолжительное время развивались параллельно и развились до той степени, что взаимная совместимость между ними стала невозможной.
Более популярным стандартном, в силу своей ориентированности на участие более компетентной третьей стороны, стал стандарт S/MIME + X.509, однако и у PGP есть некоторое количество козырей за пазухой, с помощью которых он не только не погибает, но и продолжает успешно развиваться.
Более подробное рассмотрение каждого из форматов, а также рекомендации, когда, где и какой из них использовать вы сможете прочитать уже в следующих статьях.