| ||||
| ||||
| Сушествует два способа использования ЭЦП: 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 | ||||
| Ответы: | ||||
| ||||
| >Система распределения сертификатов есть. Сразу все клюдется в LDAP. При желании Центр Сертификации можно расширить. Есть множество COM интерфейсов к Центру (описано в MSDN). Хочешь использовать свою базу - добавь EXIT модуль и положи все выпущенные сертификаты в Оракл, а хочешь рассылай по почте по списку спасибо за подробное разъяснение очень интересно было бы получить дополнительную информацию по возможности интеграции с Оракл - "добавь EXIT модуль" - это о чем? если выложить сертификаты в Оракл (создать для них отдельную таблицу), то и ЭЦП также помещается в одно из полей записи? а процедура проверки - трудоемкая? м.б. подскажете - возможно, где-то уже есть реализованные готовые модули интеграции с Оракл? спасибо | ||||
| ||||
| У Microsoft CA можно подключить модуль "policy" (через который модифицируется содержимое сертификатов) и "exit" (через который можно публиковать сертификаты). | ||||
| ||||
| Hi! Nice site! I wish you well! | ||||
Игорь Курепкин