| ||||
| ||||
| Пытаю подписать файл. Получаю описатель ключа вызовом CryptGetUserKey с параметром AT_SIGNATURE. Функция валится с ошибкой 8009000D - NTE_NO_KEY. При получении контекста криптопровайдера CryptAcquireContext передаю имя контейнера с сертификатом сзязанным с секретным ключем ("You have a private key that corresponds to this certificate"). В чем может быть дело? | ||||
| Ответы: | ||||
| ||||
| Возможно, в контейнере нет ключа обмена а есть ключ подписи AT_KEYEXCHANGE. | ||||
| ||||
| Очень похоже на то! Когда делаю вызов CryptGetUserKey с AT_KEYEXCHANGE, все проходит нормально. Но мне требуется произвести подпись. ! Cтранно то, что через CAPICOM с тем же контейнером подпись происходила нормально. ! Но если перед CryptGetUserKey вызываю CryptGenKey - все работает. Вообще запутался, что за ключ в таком случае (CryptGenKey с AT_SIGNATURE) генерируется? Если это закрытый ключ (или пара закрытый/открытый) как получатель сможет идентифицировать отправителся? В таком случае требуется отправлять получателю и открытый ключ "проверки" подписи? Но в таком случае вообще не понятен смысл такой подписи и ее верификации получателем. Вобщем, наверно слишком много вопросов. Но все же пожалуйста разъясните. Главное, обрисуйте общую схему подписи файла отправителем и верификацию получателем на уровне CryptoAPI (какие вызовы делать) с помощью сертификата. Спасибо! | ||||
| ||||
| AT_SIGNATURE - ключ, который может использоваться только для подписи. AT_KEYEXCHANGE - ключ, который может использоваться и для подписи, и для шифрования (обмена ключами на самом деле) CAPICOM выбирает тот ключ, на который стоит ссылка у сертификата ("You have a private key.."), поэтому с ним и работало. Получателю открытый ключ конечно нужен! Он с помощью него проверяет 1) то что сообщение не изменялось 2) то, что подпись была сделана обладателем данной ключевой пары Схема достаточно проста Подпись - CryptSignMessage, проверка CryptVerifyMessageSignature. Все необходимые операции с ключами и хэшами выполнит CryptoAPI | ||||
Максим