Цифровая подпись неотрекаемость шифрование ключей шифрование данных f0 что это значит
Регламент Удостоверяющего центра » по созданию и использованию сертификатов ключей проверки электронных подписей, выдаваемых юридическим и физическим лицам (стр. 4 )
 | Из за большого объема этот материал размещен на нескольких страницах: 1 2 3 4 |
2. Атрибут 1.3.6.1.4.1.311.2.1.14
Название: Расширения сертификатов
Расширения сертификата X.509
1. Расширение 2.5.29.15 (критическое)
Название: Использование ключа
Значение: Цифровая подпись, Неотрекаемость, Шифрование ключей, Шифрование данных(F0)
2. Расширение 1.2.840.113549.1.9.15
Название: Возможности SMIME
Значение: [1]Возможности SMIME Идентификатор объекта=1.2.643.2.2.21
3. Расширение 2.5.29.37
Название: Улучшенный ключ
Значение: Пользователь Центра Регистрации (1.2.643.2.2.34.6) Проверка подлинности клиента (1.3.6.1.5.5.7.3.2) Защищенная электронная почта (1.3.6.1.5.5.7.3.4)
3. Атрибут 1.3.6.1.4.1.311.13.2.2
Название: CSP заявки
Сведения о провайдере
Назначение ключа: ОБМЕН
Название провайдера: Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider
Подпись провайдера: AA03 C083 A1B5 CCDC 20A0 F6A9 29D0 FF71 C51A 52D5 469B 684B 7B7D 342F E0D8 8DDB 09EB B3BF 8DA6 3C98 AF07 327E 7EEB A121 A372 CA57 030A 87D2 AFA9 CDBB D3AA 7575 AA85 01B7 0AB3 79B5 98BA 8453 9B62 AA33 AA4C F07E 6043 64AB BCA5 0A4B EB59 A3D0 E55B D306 78A8 0B0B B05E 79F0 9001 E7B1 E133 B708 C11D 6AA1 400 0000
Подпись Удостоверяющего центра:
Название: ГОСТ Р 34.11/34.10-2001
Значение: BABC 1455 ADA3 DC7F 0EC9 3A1A 5020 C0DE F561 CBB2E B180 A5B0 091A 7F0A 6FA1 1A6E EE48 A366 BA311 D966 BB2F FC7C EB75 3F0A 49ED A651 3E10 258A
Владелец ключа подписи подпись
(для юридических лиц) подпись
к Регламенту Удостоверяющего центра » по созданию и использованию сертификатов ключей проверки электронных подписей, выдаваемых юридическим и физическим лицам
Для юридических лиц
Заявление о прекращении действия сертификата
ключа проверки электронной подписи
(полное наименование организации, включая организационно-правовую форму)
в лице __________________________________________________________________,
(фамилия, имя, отчество)
действующего на основании _______________________________________________,
просит прекратить действие сертификата ключа проверки электронной подписи, содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Фамилия полномочного представителя, действующего от имени организации
Имя и Отчество полномочного представителя
Должность руководителя организации
Подпись руководителя организации
Дата подписания заявления
Для физических лиц
Заявление о прекращении действия сертификата
ключа проверки электронной подписи
(фамилия, имя, отчество)
прошу прекратить действие сертификата ключа проверки электронной подписи, содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Фамилия Имя Отчество
Пользователь Удостоверяющего центра
к Регламенту Удостоверяющего центра » по созданию и использованию сертификатов ключей проверки электронных подписей, выдаваемых юридическим и физическим лицам
Для юридических лиц
Заявление о приостановлении действия сертификата
ключа проверки электронной подписи
(полное наименование организации, включая организационно-правовую форму)
в лице _________________________________________________________________,
(фамилия, имя, отчество)
действующего на основании _______________________________________________,
просит приостановить действие сертификата ключа проверки электронной подписи, содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Фамилия полномочного представителя, действующего от имени организации
Имя и Отчество полномочного представителя
Срок приостановления действия сертификата ____________________________ дней.
Должность руководителя организации
Подпись руководителя организации
Дата подписания заявления
Для физических лиц
Заявление о приостановлении действия сертификата
ключа проверки электронной подписи
(фамилия, имя, отчество)
прошу приостановить действие сертификата ключа проверки электронной подписи, содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Фамилия Имя Отчество
Срок приостановления действия сертификата ____________________________ дней.
Пользователь Удостоверяющего центра
к Регламенту Удостоверяющего центра » по созданию и использованию сертификатов ключей проверки электронных подписей, выдаваемых юридическим и физическим лицам
Для юридических лиц
Заявление о возобновлении действия сертификата ключа проверки электронной подписи
(полное наименование организации, включая организационно-правовую форму)
в лице _________________________________________________________________,
(фамилия, имя, отчество)
действующего на основании _______________________________________________,
просит возобновить действие сертификата ключа проверки электронной подписи, содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Фамилия полномочного представителя, действующего от имени организации
Имя и Отчество полномочного представителя
Должность руководителя организации
Подпись руководителя организации
Дата подписания заявления
Для физических лиц
Заявление о возобновлении действия сертификата ключа проверки электронной подписи
(фамилия, имя, отчество)
прошу возобновить действие сертификата ключа проверки электронной подписи, содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Фамилия Имя Отчество
Пользователь Удостоверяющего центра
к Регламенту Удостоверяющего центра » по созданию и использованию сертификатов ключей проверки электронных подписей, выдаваемых юридическим и физическим лицам
Для юридических лиц
Заявление о получении информации о статусе сертификата ключа проверки электронной подписи, созданного Удостоверяющим центром »
(полное наименование организации, включая организационно-правовую форму)
в лице _________________________________________________________________,
(фамилия, имя, отчество руководителя)
действующего на основании _______________________________________________,
просит предоставить информацию о статусе сертификата ключа проверки электронной подписи, созданного Удостоверяющим центром ФГУП «ГРЧЦ» и содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Наименование организации, если владелец сертификата – юридическое лицо;
Фамилия, Имя, Отчество, если владелец сертификата – физическое лицо
Время[1] (период времени), на момент наступления которого требуется установить статус сертификата: с «______________________» по «________________________».
Должность руководителя организации
Подпись руководителя организации
Дата подписания заявления
Для физических лиц
Заявление о получении информации о статусе сертификата ключа проверки электронной подписи, созданного Удостоверяющим центром »
(фамилия, имя, отчество)
прошу предоставить информацию о статусе сертификата ключа проверки электронной подписи, созданного Удостоверяющим центром ФГУП «ГРЧЦ» и содержащего следующие данные:
Серийный номер сертификата ключа проверки электронной подписи
Наименование организации, если владелец сертификата – юридическое лицо;
Фамилия, Имя, Отчество, если владелец сертификата – физическое лицо
Время[2] (период времени), на момент наступления которого требуется установить статус сертификата: с «______________________» по «________________________»
Пользователь Удостоверяющего центра
к Регламенту Удостоверяющего центра » по созданию и использованию сертификатов ключей проверки электронных подписей, выдаваемых юридическим и физическим лицам
Для юридических лиц
Заявление о проверке подлинности электронной подписи
в электронном документе
(полное наименование организации, включая организационно-правовую форму)
в лице _________________________________________________________________,
(фамилия, имя, отчество руководителя)
действующего на основании _______________________________________________,
просит проверить подлинность электронной подписи в электронном документе на основании следующих данных:
1. Файл формата CMS, содержащий сертификат ключа проверки электронной подписи, с использованием которого необходимо осуществить проверку подлинности электронной подписи в электронном документе на прилагаемом к заявлению носителе – рег. № Н–ХХХ;
2. Файл, содержащий подписанные электронной подписью данные и значение электронной подписи формата CMS, либо файл, содержащий исходные данные и файл, содержащий значение электронной подписи формата CMS, на прилагаемом к заявлению носителе – рег. № Н–ХХХ
3. Время[3] подписания электронной подписью электронного документа: «______:_______» «_______/_________________/______________»;
Часов минут день месяц год
Если момент подписания электронного документа не определен, то указать время, на момент наступления которого необходимо проверить подлинность электронной подписи:
Часов минут день месяц год
Должность руководителя организации
Подпись руководителя организации
Дата подписания заявления
Для физических лиц
Заявление о проверке подлинности электронной подписи
в электронном документе
(фамилия, имя, отчество)
прошу проверить подлинность электронной подписи в электронном документе на основании следующих данных:
1. Файл формата CMS, содержащий сертификат ключа проверки электронной подписи, с использованием которого необходимо осуществить проверку подлинности электронной подписи в электронном документе на прилагаемом к заявлению носителе – рег. № Н–ХХХ;
2. Файл, содержащий подписанные электронной подписью данные и значение электронной подписи формата CMS, либо файл, содержащий исходные данные и файл, содержащий значение электронной подписи формата CMS, на прилагаемом к заявлению носителе – рег. № Н–ХХХ
3. Время[4] подписания электронной подписью электронного документа: «______:_______» «_______/_________________/______________»;
Часов минут день месяц год
Если момент подписания электронного документа не определен, то указать время, на момент наступления которого необходимо проверить подлинность электронной подписи:
Часов минут день месяц год
Пользователь Удостоверяющего центра
* Настоящая доверенность должна быть нотариально удостоверена.
[1] Время и дата должны быть указаны с учетом часового пояса г. Москвы (по московскому времени). Если время и дата не указаны, то статус сертификата устанавливается на момент времени принятия заявления Удостоверяющим центром ».
[2] Время и дата должны быть указаны с учетом часового пояса г. Москвы (по Московскому времени). Если время и дата не указаны, то статус сертификата устанавливается на момент времени принятия заявления Удостоверяющим центром ».
[3] Время и дата должны быть указаны с учетом часового пояса г. Москвы (по московскому времени).
[4] Время и дата должны быть указаны с учетом часового пояса г. Москвы (по московскому времени).
Электронная подпись для чайников: с чем ее есть и как не подавиться. Часть 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 есть некоторое количество козырей за пазухой, с помощью которых он не только не погибает, но и продолжает успешно развиваться.
Более подробное рассмотрение каждого из форматов, а также рекомендации, когда, где и какой из них использовать вы сможете прочитать уже в следующих статьях.
Электронная цифровая подпись для чайников: с чем ее есть, и как не подавиться. Часть 1
Итак, все чаще в кругах, работающих с документами все чаще звучат слова «электронный документ» и, связанное с ним почти неразрывно «электронная цифровая подпись», иначе — ЭЦП.
Данный цикл статей предназначен для того, чтобы раскрыть «тайное знание» о том, что это такое, когда и как это можно и нужно использовать, какие есть плюсы и минусы.
Естественно, статьи пишутся не для специалистов по криптографии, а для тех, кто эту самую криптографию будет использовать, или же только начинает ее изучение, желая стать специалистом, поэтому я старался максимально упростить понимание всего процесса, приводя аналогии и рассматривая примеры.
Зачем нам вообще что-то подписывать? Естественно, чтобы удостоверить, что мы ознакомились с содержимым, согласны (а иногда наоборот, не согласны) с ним. А электронная подпись еще и защищает наше содержимое от подмены.
Итак, начать, естественно, стоит с того, что такое электронная цифровая подпись.
В самом примитивном случае это — результат хэш-функции. Что это такое лучше меня разъяснит википедиа, в нашем же случае главное, что с высокой степенью вероятности ее результат не повторяется для разных исходных данных, а также что результат этой функции мало того, что короче исходных данных, так еще по нему исходную информацию восстановить нельзя. Результат функции называют хэшем, а применение этой функции к данным называют хешированием. Грубо, можно назвать хэш функцию архивированием, в результате чего мы получаем очень маленькую последовательность байт, но восстановить исходные данные из такого «архива» нельзя.
Итак, мы читаем файлик в память, хэшируем прочитанное. И что, уже получаем ЭЦП? Почти. Наш результат с большой натяжкой можно назвать подписью, но, все же, полноценной подписью он не является, потому что:
1. Мы не знаем, кто сделал данную подпись
2. Мы не знаем, когда была сделана подпись
3. Сама подпись не защищена от подмены никак.
4. Ну и да, хэш функций много, какая из них использовалась для создания этого конкретного хэша?
Поэтому применять к хэшу слово «подпись» еще нехорошо, будем называть его дальше просто хэш.
Вы посылаете ваш файл другому человеку, допустим, по почте, будучи уверенными, что он точно получит и прочитает именно то, что вы послали. Он же, в свою очередь, тоже должен хэшировать ваши данные и сравнить свой результат с вашим. Если они совпали — все хорошо. Это значит что данные защищены? Нет.
Ведь хэшировать может кто угодно и когда угодно, и вы никогда не докажете, что он хэшировал не то, что вы послали. То есть, если данные будут перехвачены по дороге злоумышленником, или же тот, кому вы посылаете данные — не очень хороший человек, то данные могут быть спокойно подменены и прохэшированы. А ваш получатель (ну или вы, если получатель — тот самый нехороший человек) никогда не узнает, что он получил не то, что вы отправляли, или сам подменил информацию от вас для дальнейшего использования в своих нехороших целях.
Посему, место для использование чистой хэш функции — транспорт данных в пределах программы или программ, если они умеют общаться между собой. Собственно, с помощью хэш функций вычисляются контрольные суммы. И эти механизмы защищают от случайной подмены данных, но не защищают от специальной.
Но, пойдем дальше. Нам хочется защитить наш результат хеширования от подмены, чтобы каждый встречный не мог утверждать, что это у него правильный результат. Для этого самое очевидное что (помимо мер административного характера)? Правильно, зашифровать. А ведь с помощью шифрования же можно и удостоверить личность того, кто хэшировал данные! И сделать это сравнительно просто, ведь есть ассиметричное шифрование. Да, оно медленное и тяжелое, но ведь нам всего-то и надо — зашифровать маленькую последовательность байт. Плюсы такого действия очевидны — для того, чтобы проверить нашу подпись, надо будет иметь наш открытый ключ, по которому личность зашифровавшего (а значит, и создавшего хэш) можно легко установить.
Суть этого шифрования в следующем: у вас есть закрытый ключ, который вы храните у себя. И есть открытый ключ. Открытый ключ вы можете всем показывать и раздавать, а закрытый — нет. Шифрование происходит с помощью закрытого ключа, а расшифровывание — с помощью открытого.
Приводя аналогию, у вас есть отличный замок и два ключа к нему. Один ключ замок открывает (открытый), второй — закрывает (закрытый). Вы берете коробочку, кладете в нее какую-то вещь и закрываете ее своим замком. Так, как вы хотите, чтобы закрытую вашим замком коробочку открыл ее получатель, то вы открытый, открывающий замок, ключик спокойно отдаете ему. Но вы не хотите, чтобы вашим замком кто-то закрывал коробочку заново, ведь это ваш личный замок, и все знают, что он именно ваш. Поэтому закрывающий ключик вы всегда держите при себе, чтобы кто-нибудь не положил в вашу коробочку мерзкую гадость и не говорил потом, что это вы ее положили и закрыли своим замком.
И все бы хорошо, но тут сразу же возникает проблема, а, на самом деле, даже не одна.
1. Надо как-то передать наш открытый ключ, при этом его должна понять принимающая сторона.
2. Надо как-то связать этот открытый ключ с нами, чтобы нельзя было его присвоить.
3. Мало того, что ключ надо связать с нами, надо еще и понять, какой зашифрованный хэш каким ключом расшифровывать. А если хэш не один, а их, скажем, сто? Хранить отдельный реестр — очень тяжелая задача.
Все это приводит нас к тому, что и закрытый ключ, и наш хэш надо хранить в каких-то форматах, которые нужно стандартизировать, распространить как можно шире и уже тогда использовать, чтобы у отправителя и получателя не возникало «трудностей перевода».
Как водится у людей, к чему-то единому прийти так и не смогли, и образовалось два больших лагеря — формат OpenPGP и формат S/MIME + X.509. Но об этом уже в следующей статье.