26.04.2004 10:16:03Подпись какова она есть. Ответов: 22
Евгений Евгеньевич
Результат функции CryptSignMessage(&P,true,1,M,MSize,NULL,cbSignature) (при использовании вашего провайдера и алгоритма ГОСТ Р34.10-2001) cbSignature - то что в дальнейшем считается подписью - занимает 715 байт.

Вопрос: какую ещё информацию кроме самой подписи содержит этот результат ?
 
Ответы:
26.04.2004 11:10:47Kirill Sobolev
Например, сертификат, которым Вы подписываете. Это можно посмотреть утилитами типа dumpasn1
26.04.2004 12:23:14Евгений Евгеньевич
сертификата там нет - он занимает 918 байт
26.04.2004 12:26:23Kirill Sobolev
ну тогда там может быть информация о сертификате подписчика (серийный номер и издатель) и информация об алгоритме подписи
26.04.2004 12:33:48kure
Вообще то CryptSignMessage на фыходе имеет формат, определенный RFC 2630 "Cryptographic Message Syntax"
http://www.ietf.org/rfc/rfc2630.txt.

Состав дополнительнах данных в формате определенном как SignedData в том числе зависит от атрибутов и флагов, которые пользуются при создании.
30.04.2004 9:07:54Евгений
очень хочется узнать как именно он зависит от параметров.

очень не хочется ПУБЛИКОВАТЬ лишнюю информацию.
30.04.2004 9:37:22kure
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
signerInfos SignerInfos }


SignerInfo ::= SEQUENCE {
version CMSVersion,
sid SignerIdentifier,
digestAlgorithm DigestAlgorithmIdentifier,
signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
signatureAlgorithm SignatureAlgorithmIdentifier,
signature SignatureValue,
unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

Как минимум (не считая номера версии, идентификаторов хэша и подписи, и самой подписи) будет информация о сертификате, который нужно пользовать для проверки ЭЦП в виде
SignerIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }

Т.е. не сам сертификат, а ссылка на него.
Все остальное: сам сертификат, атрибуты (время подписи, тип данных и еще какие вы захотите положить) опциональны.
12.05.2004 8:37:56Евгений
вы сказали:
"и еще какие вы захотите положить"
то есть вместе с подписью опубликованной может оказаться ЛЮБАЯ информация.
(в частности никто не запретит разработчику записать туда закрытый ключ, замаскировав его любым безобидным именем поля)
-
вообще-то в криптографических системах всякая ЛИШНЯЯ информация образует дыру, люди ломают головы как передать лишний БИТ информации скрытно от пользователя, а вы создали скрытый от пользователя канал передачи неограниченой ширины.
-
спасибо.
12.05.2004 9:32:59kure
Пожалуйста.

Прежде чем комментировать, посмотрите о чем написано выше.
Формат криптографических сообщений определен международными рекомендациями:
RFC 2630 "Cryptographic Message Syntax"
http://www.ietf.org/rfc/rfc2630.txt.

А как разрабатывать системы защиты информации - это не есть вопрос данного обсуждения.
13.05.2004 9:06:28Евгений
вы сказали регламентирован ФОРМАТ, а не _контент_, и это чистая правда.
так что я прекрасно понимаю о чём говорю. В данный формат (о котором речь) можно вписать ЛЮБУЮ инфу. И даже Вы это подтверждаете словами "и ещё всё что вы захотите передать".
13.05.2004 18:02:13kure
Описание или отсутсвие формата не мешает "плохому" программисту сделать закладки в разрабатываемом софте в том числе для передачи ключевой информации.

Для этого рекомендуют соблюдать определенный порадядок создания системы.

А чтобы ключ нельзя было передать нужно пользовать устройства, которые не позволяют ключ с него экспортировать.
14.05.2004 8:38:18Евгений
вы либо издеваетесь, либо пытаетесь заболтать проблему.
-
проблема не в хранении ключа, а в том что у вас есть СКРЫТЫЙ ОТ ПОЛЬЗОВАТЕЛЯ КАНАЛ ПЕРЕДАЧИ ДАННЫХ. Он не гипотетический, он уже есть, уже запрограммирован.
14.05.2004 9:14:53kure
Заболтать не пытаюсь, т.к. подразумевается, что при этом много пишут (говорят).
Давайте попытаемся по-шагам, типа ТЗ.
Определите задачи системы и способы их решения.
Как я понял одна из задач - закрытых ключ не должен попасть в канал передачи данных.
Теперь определим, что такое канал передачи данных:
1. Данные передаваемые между компьютерами в процессе штатной эксплуатации прикладной системы зарегистрированными пользователями.
2. Данные передаемые зарегистрированными пользователями с тех же компьютеров, но без использования штатных средств системы (например почта, ftp и т.д.).
3. Данные передаваемые пользователями
вообще без компьютеров (на магнитном носители).

И программно в разрабатываемой системе вопросы защиты информации без организационных мер и только криптографическими методами вы не решите.

А теперь просьба, объясните подробнеем чем вам не нравится формат, в котором кроме подписанных данных могут быть дополнительные атрибуты, например время создания подписи.
И кто мешает програмисту в атрибут "время создания подписи" положить закрытых ключ или добавить его к тем же данным, которые он подписывает. Формат то международный причем тут.
17.05.2004 12:16:19Евгений
спасибо, мне понятно, вы хотите заболтать проблему.
-
при чём здесь "цели и задачи", у вас есть вполне конкретная проблема: возможность передать вместе с подписью ЛЮБУЮ ИНФОРМАЦИЮ.
и это никак не зависит от физического уровня передачи.
17.05.2004 12:34:10kure
Извините, а вы программист или какова практическая цель ваших изысканий ?
20.05.2004 13:37:38Евгений
ну вот - вы перешли на личности.
значит по предмету нашего разговора я оказался прав.
20.05.2004 14:27:38kure
Конечно вы правы, у вас есть собственное мнение, которое может отличасться от мнения других.
Не нравится вам форматы RFC - не пользуйте (если вы в праве принимать такое решение для выполнения конкретной работы).
Если это не для работы, а для "души" - напишите статью, а еще лучше свой проект стандарта (они кстати принимаются от любого человека), публикуйте и реализуйте.
20.05.2004 16:24:38Евгений
ну вот опять вы пускаетесь в словеса.
у Вас проблема. и её наличие никак не зависит ни от моего мнения ни от вашего. Дыра объективна.
16.02.2005 16:50:36Дробязко Алексей
Здравствуйте! Просмотрел Ваш диалог и решил спросить. Нет ли у Вас примера добавления к сообщению дополнительной информации(например, времени подписи)?
Спасибо.
16.02.2005 16:54:33Kirill Sobolev
Есть в http://www.cryptopro.ru/CryptoPro/test/sample2_0.zip, signtsg.c, функция do_sign - как раз пример с добавлением времени.
16.02.2005 16:55:32kure
В примере signtsf.c

/*---------------------------------------------------------------------------------
Определим системное время и добавим его в список аутентифицируемых (подписанных)
атрибутов PKCS#7 сообщения с идентификатором szOID_RSA_signingTime.
---------------------------------------------------------------------------------*/
GetSystemTime(&systemTime);
SystemTimeToFileTime(&systemTime, &fileTime);

/* Определим требуемую длину для хранения времени*/
bResult = CryptEncodeObject(TYPE_DER,
szOID_RSA_signingTime,
(LPVOID)&fileTime,
NULL,
&cbAuth);
if (!bResult) {
ret = DebugErrorFL("Cannot encode object");
goto err;
}

pbAuth = (BYTE*) malloc (cbAuth);
if (!pbAuth)
HandleErrorFL("Memory allocation error");

/* Кодирование времени в атрибут типа szOID_RSA_signingTime */
bResult = CryptEncodeObject(TYPE_DER,
szOID_RSA_signingTime,
(LPVOID)&fileTime,
pbAuth,
&cbAuth);
if (!bResult) {
ret = DebugErrorFL("Cannot encode object");
goto err;
}

cablob[0].cbData = cbAuth;
cablob[0].pbData = pbAuth;

ca[0].pszObjId = szOID_RSA_signingTime;
ca[0].cValue = 1;
ca[0].rgValue = cablob;

param.cAuthAttr = 1;
param.rgAuthAttr = ca;

16.02.2005 18:30:17Дробязко Алексей
Большое спасибо. Все работает.
23.04.2007 16:27:33Гидеон
Прочитал топик и удивился, честно говоря, вопросу...
Контейнер подписи, в общем случае, не является криптографически закрытым объектом. Поэтому формат не препятствует тому, что в нём _может быть_ размещена конфиденциальная информация в открытом виде. Но размещена она там может быть _пользователем_ СКЗИ, вызывающим функцию создания подписи, а никак не разработчиком СКЗИ. И это подтверждает сертификат, выданный на данное средство СКЗИ соответствующими органами.
А чтобы разработчики высокоуровневых систем не организовали утечку конфиденциальной информации, неправильно применяя сертифицированные СКЗИ, проводится исследование корректности встраивания СКЗИ...
Так что проблема эта не новая, известна давно и решения так же давно найдены...
ИМХО.