22.02.2001 11:28:15Выбор уровня встраивания. Зачем сертификаты. Ответов: 3
Игорь Курепкин
Сушествует два способа использования ЭЦП:
1. Встраивать на уровне CryptoAPI 1.0 (посчитать хэш, затем подпись, передать открытых ключ и т.д. и т.п.)
2. Использовать сертификаты X.509 и CryptoAPI 2.0 (уровень Simplified или Low Level Message Functions).

Попробуем дать ответ.

1. Насчет первого способа подписи. Пример подписывания с использованием CryptoAPI 1.0 и LoadLibrary находится в файле ctkey.c. Схема такая:
Генерим долговременные ключи CPGenKey, подписи (AT_SIGNATURE) и/или "обмена" AT_KEYEXCHANGE. Последний используется не для шифрования данных а для (экспортирования) шифрования сессионного симетричного ключа ГОСТа по алгоритму Диффи-Хелмана для последующей передачи получателю. На ключе обмена можно подписывать. На подписи нельзя экспортировать сессионный ключ.

Ключ долговременный есть, можно подписывать.
Создаем контекст хэша (безо всяких случайных ключей) и с помощью него вычисляем хэш от подписываемый данных (нр. файла).
Полученнoe значение хэш (CPGetHashParam) можно возврать (если нужно)
Получаем подпись, используя контекст хэше и ДОЛГОВРЕМЕННЫЙ ключ.
В результате имеем 64 байта ЭЦП по ГОСТу.
На стороне подписавшего почти все, за исключением того что у остальных должен появиться открытый ключ и они все должны понять кому этот ключ принадлежит.

Вот тут всегда и начинается полная ж....

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

Так что по этому пути идти - это для настоящих героев, или если только была уже сделана система распределения и управления ключами и нужно лишь поменять алгоритмы.

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

Т.е. сделать можно. Ну взять с помощью функции CPExportKey, экспортнуть открытых ключ, соответствующий долговременному на котором подписывали. Передать его получателю. Может и его подписать. А может отдавать только при встрече. Придумать для него формат, чтобы знать от кого пришел. И даже при этом НЕЛЬЗЯ быть уверенным, что получив ключ по сети можно определить что кому он принадлежит (только ногами и при визуальном контакте), или делая свой софт, вводя понятия администратора, заверяя все ключи его подписью или имитовсатвкой (как в Вербе-О). Каждый может написать, что он английская королева.
Ну вот вроде и все.


2. Таки вот это все сделано через систему управления сертификататми.
Единственна проблема в этом случае - организационное создание доверенного Центра Сертификации. Но зато софта писать не надо. И проблема только организационная.
Какие зайцы при этом убиваются.

ПО администратора для заверения открытых ключей есть - Центр Сертификации.

Формат есть - Х.509. И этот формат позволяет добавить кучу необходимой информации в сертификат. Хочешь номер
паспорта, хочешь BMP владельца сертификата.

Система распределения сертификатов есть. Сразу все клюдется в LDAP. При желании Центр Сертификации можно расширить. Есть множество COM интерфейсов к Центру (описано в MSDN). Хочешь использовать свою базу - добавь EXIT модуль и положи все выпущенные сертификаты в Оракл, а хочешь рассылай по почте по списку.

Проблемы компрометации ключей решены. Нажал кнопку - выпустил CRL (certificate revocation list). Он сразу помещается в LDAP или через тот же EXIT модуль распространяется как захочется.

На каждом клиентском месте уже есть справочники сертификатов. Интерфейс к ним универсальный (CertOpenStore). Если не устраивает стандартный набор справочников, можно дописать свой экзотический.

Формат подписанных сообщений стандартный PKCS#7 (RFC 2315) или новый RFC 2630. Хочешь подписывай однум куском. Хочешь подпись отдельно от файла (detached signature). Формат ASN.1. Время подписи и дополнительные атрибуты дополняются легко функциями CryptoAPI.

Связь подписи с сертификатом однозначная. Она определена в PKI через поля Issuer и SerialNumber. И именно они используется в PKXS#7 для индексации сертификата, который нужно использовать для порверки ЭЦП.

В подписанное сообщение можно вложить сертификат. Искать тогда не надо. Так по умолчанию поступает Outlook и Outlook Express.

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

Популярное описание о сертификата и PKI на нашем сервере: http://www.cryptopro.ru/CryptoPro/pki/pki.asp
 
Ответы:
24.06.2002 12:34:08Nadia
>Система распределения сертификатов есть. Сразу все клюдется в LDAP. При желании Центр Сертификации можно расширить. Есть множество COM интерфейсов к Центру (описано в MSDN). Хочешь использовать свою базу - добавь EXIT модуль и положи все выпущенные сертификаты в Оракл, а хочешь рассылай по почте по списку

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

спасибо
24.06.2002 15:17:47Kure
У Microsoft CA можно подключить модуль "policy" (через который модифицируется содержимое сертификатов) и "exit" (через который можно публиковать сертификаты).
05.11.2007 14:08:32Mike
Hi! Nice site! I wish you well!