| ||||
| ||||
| добрый день! подскажите, пожалуйста, как происходит следующее: 1. в документации КриптоПро ряд "документов" выводится на принтер для собственноручного заверения, напимер, бланк запрос на сертификат, бланк сертификата. Эта функция поддерживается КриптоПро, т.е. где-то есть кнопка "вывести на печать" (если да, то где?) или это происходит как-то по-другому? 2. Когда бумажный бланк запроса сверяется с запросом, полученным через WEB, агент регистрации просто водит пальцем по бумаге, чтобы сверить, что все символы открытого клча соответствуют или есть какие-то более "продвинутые" способы? 3. Допустим, пришло время плановой смены ключа ЦС (для простоты он всего один, т.е. без иерархии). Для примера, срок действия предыдущего ключа заканчиается 01.01.2003. По идее, допустим, 01.12.2002 ЦС должен сгенерировать новую ключевую пару, выдать самоподписанный сертификат. Сертификат направляется всем пользователям системы, которые вносят его в список доверенных сертификатов без удаления существующего. До 01.01.2003 ЦС подписывает сертификаты старым секретным ключом. И где-то 29.12.2002 выдает сертификат Васе Пупкину, подписывая его опять же старым ключом. Отсюда вопрос: Как происходит проверка ЭЦП Васи Пупкина, чтобы и после 01.01.2003 его сертификат был действительным? Или необходимо будет обновить сертификаты (переподписать те же данные) для всех пользователей, кто имеет сертификат, подписанный старым ключом (слабо похоже на правду, т.к. это близко к объему действий, проводимых при компрометации)? 4. Из той же области: А как проверяются документы, заверенные ЭЦП на секретном ключе, срок действия которого давно истек? заранее ОГРОМНОЕ спасибо | ||||
| Ответы: | ||||
| ||||
| 1. КриптоПро CSP это библиотека с интерфейсом криптопровайдера и кнопки напечатать запрос или сертификат в ней нет. Есть в удостоверяющем центре. Стандартно это можно сделать через certutil, входящей в состав мицрософт CA либо немножчко написать скрипта, который пользую xenroll при генерации запроса сформирует страничку в base64. 2. Сканируйте запрос с бланка (например FineReader), переводите в электронный вид, проверяете ЭЦП. 3. Посмотрите описнаие микрософтовского CA. Там не совсем так как вы описываете. Сделаете ключ и сертификат 01.12 и все следующие сертификаты будут подписываться этим ключом. Так что если Васе вы сделаете сертификат 29.12 он будет подписан уже новым ключом. 4. Документы программно проверяются так же, единственно, что обычно это относится уже к системе архивирования документов и при проверке нужно использовать сертификаты, которые были туда добавлены пока действовали. | ||||
| ||||
| Игорь, спасибо огромное за помощь! Ваши ответы всегда многое проясняют и очень помогают разобраться. Осталось непонятным совсем немножко: 1. КриптоПро CSP это библиотека с интерфейсом криптопровайдера и кнопки напечатать запрос или сертификат в ней нет. Есть в удостоверяющем центре. Стандартно это можно сделать через certutil, входящей в состав мицрософт CA либо немножчко написать скрипта, который пользую xenroll при генерации запроса сформирует страничку в base64 Что-то я пыталась «подружиться» с certutil, но не нашла ни одного ключа, который бы позволил вывести запрос на сертификат на печать. Может быть, не там ищу? Необходимо решить следующую задачу: поскольку личное присутствие пользователя в ЦС невозможно в силу объективных обстоятельств, основанием для обработки запроса на сертификат является заверенный его собственноручной подписью бланк запроса, где прописан открытый ключ и имя пользователя и т.п. Т.е. при создании запроса на сертификат через веб, он его печатает, подписывает и посылает по почте. Для этого надо обязательно писать свой скрипт или уже существуют какие-то готовые скрипты? 2. Сканируйте запрос с бланка (например FineReader), переводите в электронный вид, проверяете ЭЦП. А как будет проверяться ЭЦП в этом случае? Ведь по умолчанию, если я правильно понимаю, берется открытый ключ из запроса на сертификат. Получается, что тоже надо писать отдельный скрипт или уже существуют эффективные решения? Еще раз спасибо за помощь | ||||
| ||||
| Опции Certutil certutil.exe -dump requestfilename На выходе получаем (на экран) Запрос сертификата PKCS10: Версия: 1 Субъект: CN=Base64 E="" OU=Development O=OOO Crypto-Pro L=Moscow S="" C=RU Алгоритм открытого ключа: ObjectId алгоритма: 1.2.643.2.2.20 ГОСТ Р 34.10-94 Параметры алгоритма: 0000 30 12 06 07 2a 85 03 02 02 20 02 06 07 2a 85 03 0...*.... ...*.. 0010 02 02 1e 01 .... Открытый ключ: UnusedBits = 0 0000 04 81 80 8f 9f e6 d6 fd 03 e4 8b e1 91 cd 63 0a ..............c. 0010 ad 2d b5 a7 76 b2 15 d0 06 5b 92 ec c6 1f 64 3e .-..v....[....d> 0020 55 47 c2 67 88 7b 33 8d 67 12 cc a4 3a 64 6d ee UG.g.{3.g...:dm. 0030 31 c3 9e 27 e1 5e 5e 32 83 32 e2 12 88 d7 e6 fc 1..’.^^2.2...... 0040 73 96 14 bc dc 75 68 b8 ea 98 6a 44 dd 08 ec de s....uh...jD.... 0050 59 8c 47 e0 cf 8e 83 7f d7 b1 47 ff 6b 58 73 df Y.G.......G.kXs. 0060 1b 09 b3 d6 6a 1f 8f ac 3b 0e 83 13 83 9e c5 18 ....j...;....... 0070 b3 d0 10 8c 9f 35 4f e1 a0 43 2e 05 30 6c 09 9b .....5O..C..0l.. 0080 2d d6 8f -.. Запрос атрибутов: 3 Атрибуты 3: Атрибут[0]: 1.3.6.1.4.1.311.13.2.3 (OS Version) Значение[0][0]: 5.1.2600.2 Атрибут[1]: 1.3.6.1.4.1.311.2.1.14 (Certificate Extensions) Значение[1][0]: Неизвестный тип атрибута Расширения сертификатов: 3 2.5.29.15: Флаги = 1(Критический), Длина = 4 Key Usage Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment (f0) 1.2.840.113549.1.9.15: Флаги = 0, Длина = c SMIME Capabilities [1]SMIME Capability Object ID=1.2.643.2.2.21 2.5.29.37: Флаги = 0, Длина = c Enhanced Key Usage Secure Email (1.3.6.1.5.5.7.3.4) Атрибут[2]: 1.3.6.1.4.1.311.13.2.2 (Enrollment CSP) Значение[2][0]: Неизвестный тип атрибута 0000 30 7e 02 01 01 1e 72 00 43 00 72 00 79 00 70 00 0~....r.C.r.y.p. 0010 74 00 6f 00 2d 00 50 00 72 00 6f 00 20 00 47 00 t.o.-.P.r.o. .G. 0020 4f 00 53 00 54 00 20 00 52 00 20 00 33 00 34 00 O.S.T. .R. .3.4. 0030 2e 00 31 00 30 00 2d 00 39 00 34 00 20 00 43 00 ..1.0.-.9.4. .C. 0040 72 00 79 00 70 00 74 00 6f 00 67 00 72 00 61 00 r.y.p.t.o.g.r.a. 0050 70 00 68 00 69 00 63 00 20 00 53 00 65 00 72 00 p.h.i.c. .S.e.r. 0060 76 00 69 00 63 00 65 00 20 00 50 00 72 00 6f 00 v.i.c.e. .P.r.o. 0070 76 00 69 00 64 00 65 00 72 03 05 00 6e 6f 6e 65 v.i.d.e.r...none Алгоритм подписи: ObjectId алгоритма: 1.2.643.2.2.4 ГОСТ Р 34.11/34.10-94 Параметры алгоритма: 05 00 .. Подпись: НеиспользБит=0 0000 44 39 8d a5 9d a9 4a df 70 5d d8 1f 64 06 de ae D9....J.p]..d... 0010 3f ba 7b 58 44 e1 fe fe 86 cf e1 00 88 31 9b 87 ?.{XD........1.. 0020 81 a4 73 33 ae 98 b6 0d 64 8d 97 8b da ea 92 38 ..s3....d......8 0030 f4 7f fd 34 86 43 96 13 dd e3 29 78 2c c4 8c 28 ...4.C....)x,..( Подпись соответствует открытому ключу Для веб интерфейса готового скрипта я не видел, но если это делается через xenroll, то сводится все к тому, что нужно отобразить на странице значение, в результате выполнения функции XEnroll.createPKCS10(strDN, usage). Проверить подпись запроса (т.е. взьть из него открытый ключ и проверить на нем подпись всего запроса) можно: функцией CryptoAPI (она есть в нашем тесте с опцией -rc) той же утилитой certutil -dump в результате получите Подпись не соответствует открытому ключу: 80090006 Не удалось расшифровать объект: 0x80090006 (-2146893818) CertUtil: -dump команда НЕ ВЫПОЛНЕНА: 0x80090006 (-2146893818) CertUtil: Invalid Signature. Сам центр проверяет подпись запроса. | ||||
| ||||
| 1. Спасибо! 2. Немножко не про то - мне не понятно, как администратор ЦР (или ЦС для простоты) будет проверять, что отсканированный открытый ключик как раз тот, что надо, т.е. соответствует секретному ключу, на котором запрос подписан ведь отсканировать и получить электронный формат открытогоключа, под которым пользователь "подписался" - еще не значит сравнить... спасибо еще раз (заранее :) | ||||
| ||||
| Но ведь после того как запрос перевели в электронный вид его можно и проверить. Он самодостаточен для проверки. Если, например, его отдаем микрософт СА, то он сначала проверит подпись, а потом выпустит сертификат. | ||||
Nadia