| ||||
| ||||
| Результат функции CryptSignMessage(&P,true,1,M,MSize,NULL,cbSignature) (при использовании вашего провайдера и алгоритма ГОСТ Р34.10-2001) cbSignature - то что в дальнейшем считается подписью - занимает 715 байт. Вопрос: какую ещё информацию кроме самой подписи содержит этот результат ? | ||||
| Ответы: | ||||
| ||||
| Например, сертификат, которым Вы подписываете. Это можно посмотреть утилитами типа dumpasn1 | ||||
| ||||
| сертификата там нет - он занимает 918 байт | ||||
| ||||
| ну тогда там может быть информация о сертификате подписчика (серийный номер и издатель) и информация об алгоритме подписи | ||||
| ||||
| Вообще то CryptSignMessage на фыходе имеет формат, определенный RFC 2630 "Cryptographic Message Syntax" http://www.ietf.org/rfc/rfc2630.txt. Состав дополнительнах данных в формате определенном как SignedData в том числе зависит от атрибутов и флагов, которые пользуются при создании. | ||||
| ||||
| очень хочется узнать как именно он зависит от параметров. очень не хочется ПУБЛИКОВАТЬ лишнюю информацию. | ||||
| ||||
| 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 } Т.е. не сам сертификат, а ссылка на него. Все остальное: сам сертификат, атрибуты (время подписи, тип данных и еще какие вы захотите положить) опциональны. | ||||
| ||||
| вы сказали: "и еще какие вы захотите положить" то есть вместе с подписью опубликованной может оказаться ЛЮБАЯ информация. (в частности никто не запретит разработчику записать туда закрытый ключ, замаскировав его любым безобидным именем поля) - вообще-то в криптографических системах всякая ЛИШНЯЯ информация образует дыру, люди ломают головы как передать лишний БИТ информации скрытно от пользователя, а вы создали скрытый от пользователя канал передачи неограниченой ширины. - спасибо. | ||||
| ||||
| Пожалуйста. Прежде чем комментировать, посмотрите о чем написано выше. Формат криптографических сообщений определен международными рекомендациями: RFC 2630 "Cryptographic Message Syntax" http://www.ietf.org/rfc/rfc2630.txt. А как разрабатывать системы защиты информации - это не есть вопрос данного обсуждения. | ||||
| ||||
| вы сказали регламентирован ФОРМАТ, а не _контент_, и это чистая правда. так что я прекрасно понимаю о чём говорю. В данный формат (о котором речь) можно вписать ЛЮБУЮ инфу. И даже Вы это подтверждаете словами "и ещё всё что вы захотите передать". | ||||
| ||||
| Описание или отсутсвие формата не мешает "плохому" программисту сделать закладки в разрабатываемом софте в том числе для передачи ключевой информации. Для этого рекомендуют соблюдать определенный порадядок создания системы. А чтобы ключ нельзя было передать нужно пользовать устройства, которые не позволяют ключ с него экспортировать. | ||||
| ||||
| вы либо издеваетесь, либо пытаетесь заболтать проблему. - проблема не в хранении ключа, а в том что у вас есть СКРЫТЫЙ ОТ ПОЛЬЗОВАТЕЛЯ КАНАЛ ПЕРЕДАЧИ ДАННЫХ. Он не гипотетический, он уже есть, уже запрограммирован. | ||||
| ||||
| Заболтать не пытаюсь, т.к. подразумевается, что при этом много пишут (говорят). Давайте попытаемся по-шагам, типа ТЗ. Определите задачи системы и способы их решения. Как я понял одна из задач - закрытых ключ не должен попасть в канал передачи данных. Теперь определим, что такое канал передачи данных: 1. Данные передаваемые между компьютерами в процессе штатной эксплуатации прикладной системы зарегистрированными пользователями. 2. Данные передаемые зарегистрированными пользователями с тех же компьютеров, но без использования штатных средств системы (например почта, ftp и т.д.). 3. Данные передаваемые пользователями вообще без компьютеров (на магнитном носители). И программно в разрабатываемой системе вопросы защиты информации без организационных мер и только криптографическими методами вы не решите. А теперь просьба, объясните подробнеем чем вам не нравится формат, в котором кроме подписанных данных могут быть дополнительные атрибуты, например время создания подписи. И кто мешает програмисту в атрибут "время создания подписи" положить закрытых ключ или добавить его к тем же данным, которые он подписывает. Формат то международный причем тут. | ||||
| ||||
| спасибо, мне понятно, вы хотите заболтать проблему. - при чём здесь "цели и задачи", у вас есть вполне конкретная проблема: возможность передать вместе с подписью ЛЮБУЮ ИНФОРМАЦИЮ. и это никак не зависит от физического уровня передачи. | ||||
| ||||
| Извините, а вы программист или какова практическая цель ваших изысканий ? | ||||
| ||||
| ну вот - вы перешли на личности. значит по предмету нашего разговора я оказался прав. | ||||
| ||||
| Конечно вы правы, у вас есть собственное мнение, которое может отличасться от мнения других. Не нравится вам форматы RFC - не пользуйте (если вы в праве принимать такое решение для выполнения конкретной работы). Если это не для работы, а для "души" - напишите статью, а еще лучше свой проект стандарта (они кстати принимаются от любого человека), публикуйте и реализуйте. | ||||
| ||||
| ну вот опять вы пускаетесь в словеса. у Вас проблема. и её наличие никак не зависит ни от моего мнения ни от вашего. Дыра объективна. | ||||
| ||||
| Здравствуйте! Просмотрел Ваш диалог и решил спросить. Нет ли у Вас примера добавления к сообщению дополнительной информации(например, времени подписи)? Спасибо. | ||||
| ||||
| Есть в http://www.cryptopro.ru/CryptoPro/test/sample2_0.zip, signtsg.c, функция do_sign - как раз пример с добавлением времени. | ||||
| ||||
| В примере 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; | ||||
| ||||
| Большое спасибо. Все работает. | ||||
| ||||
| Прочитал топик и удивился, честно говоря, вопросу... Контейнер подписи, в общем случае, не является криптографически закрытым объектом. Поэтому формат не препятствует тому, что в нём _может быть_ размещена конфиденциальная информация в открытом виде. Но размещена она там может быть _пользователем_ СКЗИ, вызывающим функцию создания подписи, а никак не разработчиком СКЗИ. И это подтверждает сертификат, выданный на данное средство СКЗИ соответствующими органами. А чтобы разработчики высокоуровневых систем не организовали утечку конфиденциальной информации, неправильно применяя сертифицированные СКЗИ, проводится исследование корректности встраивания СКЗИ... Так что проблема эта не новая, известна давно и решения так же давно найдены... ИМХО. | ||||
Евгений Евгеньевич