15.03.2007 9:26:27Как опознать отправителя подписаных данных? Ответов: 11
UTXvTT
Для подписи использую CAPICOM.

Упрощенно задача выглядит так. Есть сервер "А" и допустим 2 клиента "Б" и "С", с сертификатами полученными от сервера "A". Один из клиентов допустим подписывает данные:
Dim oSignedData As New CAPICOM.SignedData
Dim file As New IO.StreamReader(../file/..), str As String
str = file.ReadToEnd()
file.Close()

oSignedData.Content = str

Dim SignSTR As String = oSignedData.Sign

и отправляет содержимое SignSTR на сервер. Сервер делает так:
Dim oDeSignedData As New CAPICOM.SignedData
oDeSignedData.Verify(SignSTR)
Dim UnSignedMessage As String = oDeSignedData.Content

в результате в UnSignedMessage получаю правильное содержимое.

1. Все ли я правильно делаю?
2. Как отличить сообщение клиента "Б" от сообщения клиента "С" на уровне подписи?
3. Где здесь нужно указать сертификат которым будет подписаны данные?
4. Возможно ли этим способом использовать ГОСТ Р 34.10 для шифрования и подписи?
 
Ответы:
15.03.2007 12:16:39Kirill Sobolev
Да, все правильно. CAPICOM при подписи кладет в подписанное сообщение сертификат подписчика, получить его можно из свойства SignedData.Signers после вызова Verify. Можно подписывать по ГОСТу, если установлен КриптоПро CSP.
15.03.2007 12:24:36UTXvTT
Спасибо.

Все же не могли бы вы мне указать где здесь применять сертификат(3)? У клиента в личном хранилище может быть несколько сертификатов, как указать каким именно будет подписывать SignData.Sign()?
15.03.2007 13:39:08Kirill Sobolev
Первый параметр метода Verify - Signer, там сертификат и указывется. Если несколько серификатов и параметр опущен, то вылезет окно выбора.
21.03.2007 7:05:28UTXvTT
Такой нубский вопрос: в чем смысл использовать Cades вместо CAPICOM и обязаны ли мы обязательно использовать Cades при подписи по ГОСТ Р 34-10? CSP стоит
21.03.2007 10:37:05Kirill Sobolev
Смысл в том, что Cades, в отличии от CAPICOM, позволяет к собственно подписи добавлять доказательства момента подписи и действительности сертификата ОК - то, что нужно при проверке.
Использовать конечно не обязательно, грубо говоря - Вы можете реализовать все вообще без участия CryptoAPI, пользуясь только функциями криптопровайдера и ASN.1, но если Вы хотите упростить себе жизнь - то использование Cades вместо CAPICOM конечно имеет смысл
29.03.2007 10:47:15UTXvTT
Такая ситуация:

Компьютер А: Стоит КриптоПро сертификат "А" с закрытым ключем, носитель на дискете. Запущено серверное приложение расшифровывающее приходящие данные:
Dim oEnvelopedData As New CAPICOM.EnvelopedData
oEnvelopedData.Decrypt(sIn)
sOut = oEnvelopedData.Content

Компьютер Б:
Стоит сертификат "Б" полученный путем экспорта сертификата "А" без закрытого ключа, естественно без носителя. Запущено клиентское приложение которое шифрует и отсылает на сервер данные:
Dim oEnvelopedData As New CAPICOM.EnvelopedData

oEnvelopedData.Recipients.Add(oCert) ' oCert - Сертификат "Б"

oEnvelopedData.Content = sIn
sOut = oEnvelopedData.Encrypt()

В результате получаю ошибку "Certificate for recipient(s) specified in the EnvelopedData object cannot be found"

Поиском пользовался, сертификат с закрытым ключем на стороне расшифровщика стоит(см выше).

В чем ошибка? как исправить? помогите плз..
29.03.2007 11:06:56Kirill Sobolev
Сертификат с ссылкой на секретный ключ должен находится в хранилище "Личные" пользователя, под которым работает серверное приложение.
29.03.2007 11:18:38UTXvTT
Сертификаты как "А" так и "Б" стоят в личных своих компьютерах. Может быть проблема в том что в качестве серверного приложения выступает веб-служба запущенная на IIS? Может она имеет собственное личное хранилище отличное от хранилища пользователя? Я просто уже неделю бьюсь, никак догадаться в чем проблема не могу..
29.03.2007 11:23:25UTXvTT
поправка: выше - я имел ввиду оба сертификата в разделе "личные"... там просто небольшая двусмыслица получилась
29.03.2007 11:35:32Kirill Sobolev
Каждый пользователь имеет свое личное хранилище. Запустите IIS под тем, у кого сертификат в хранилище - ели поможет то дело в этом.
Где у отправителя сертификат находится непринципиально - при шифровании его можно явно указать.
29.03.2007 13:14:04UTXvTT
При попытке получить доступ к вебслужбе под определенным пользователем получаю ошибку HTTP 401: Unauthorized...

Ну да ладно.. такой(возможно довольно глупый) вопрос: насколько система передачи данных по сокетам опаснее чем передача данных на вебслужбу на IIS? В плане того что бороться с DoS атакой я не умею и вообще обеспечивать дополнительную защищенность кроме подписи и шифрования на сокет наверно не смогу