EnvelopedCms на Linux (?) возможно помещает данные signedCms в дополнительный OCTET STRING about corefx HOT 12 CLOSED

Переоткрыл, пока не решили вопрос с OCTET STRING в 1.2.840.113549.1.7.2.

from corefx.

проблема воспроизводится на unix, csp 5.0.12600, Private.CoreFx.NetCoreApp - 4.7.0-dev.22531.1

from corefx.

Добрый день.

Можете приложить примеры следующих файлов?

• подписанный cms
• зашифрованный подписанный cms
• расшифрованный КриптоАрм cms

Воспроизводится только на unix?

from corefx.

Example.zip

Добрый день!

• подписанный cms - TestFileName_Sign.txt.sig
• зашифрованный подписанный cms - TestFileName_SignEncrypt.txt.sig.enc
• расшифрованный КриптоАрм cms - TestFileName_Decrypt_CryptoARM.txt.sig

так же приложил тестовые сертификаты

на win не проверял

from corefx.

Судя по asn1 структуре в расшифрованном файле лежит всё тот же SEQUENCE (2 elements), но дополнительно обёрнутый в OCTET STRING, который добавляет дополнительные 4 байта в заголовок файла.

Ожидаемая структура:

SEQUENCE (2 elem)
  OBJECT IDENTIFIER 1.2.840.113549.1.7.2 signedData (PKCS #7)
  [0] (1 elem)

Структура после расшифровывания:

OCTET STRING (786 byte) 3082030E06092A864886F70D010702A08202FF308202FB020101310C300A06082A850…
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.113549.1.7.2 signedData (PKCS #7)
    [0] (1 elem)

Варианта возникновения проблемы 2:

• При шифровании содержимое cms сообщения дополнительно кладётся в OCTET STRING, что добавляет 4 байта (ошибка на стороне dotnet)
• При расшифровывании корректного cms сообщения КриптоАрм кладёт содержимое в OCTET STRING (ошибка на строне КриптоАрм)

По первому варианту поиски привели к следующему описанию бага при работе cms на не-виндовых операционных системах в .NET Core 2.0 :
https://learn.microsoft.com/en-us/dotnet/core/compatibility/cryptography/7.0/decrypt-envelopedcms

Рекомендуемые действия для обработки документов, полученных на старых версиях с их стороны следующие (т.е. просто декодировать Asn1 структуру и прочитать содержимое строки, трактуя её как новое содержимое структуры):

envelopedCms.Decrypt(...);

byte[] content = envelopedCms.ContentInfo.Content;

if (envelopedCms.ContentInfo.Oid.Value == "1.2.840.113549.1.7.1")
{
    if (content?.Length > 0 && content[0] == 0x04)
    {
        try
        {
            content = AsnDecoder.ReadOctetString(content, AsnEncodingRules.BER, out _);
        }
        catch (AsnContentException)
        {
        }
    }
}

Осталась ли эта бага в 3.1 (т.е. в текущем форке) - вопрос открытый. Какое то время обеспечивали "совместимость" с данной багой, но в 7 уже не будет (dotnet/docs#29263).

Возможно виновата csp (похожая проблема тут - https://www.cryptopro.ru/forum2/default.aspx?g=posts&t=15475). Выглядит тоже весьма вероятно.

(Jira - CPCSP-9698)

from corefx.

@Chiffafaust постараемся воспроизвести и найти виновника, если он на нашей стороне. Как только будет новая информация - она появится тут.

from corefx.

Судя по всему есть внутренняя логика в EnvelopedCms по работе с различными ContentType. По крайней мере для Pkcs7Data = "1.2.840.113549.1.7.1" есть отдельная ветка:

PkcsPalWindows

public sealed unsafe override byte[] Encrypt(...)
{
    if (contentInfo.ContentType.Value.Equals(Oids.Pkcs7Data, StringComparison.OrdinalIgnoreCase))
    { 
        CryptEncodeObjectToByteArray(); 
    }
    else
    { 
        CryptMsgUpdate(); 
    }
}

@Chiffafaust Попробуйте при шифровании выставить ContentType в Pkcs7Signed (1.2.840.113549.1.7.2):

ContentInfo contentInfo = new ContentInfo(
    new Oid("1.2.840.113549.1.7.2"),
    msg);
EnvelopedCms envelopedCms = new EnvelopedCms(contentInfo);

// остальной код

Если поможет - отпишитесь пожалуйста.

from corefx.

Для "сырых" данных (т.е. просто массива байт) шифрование-расшифрование всё равно приводит к кодированию результата в OCTET STRING, даже при явном указании 1.2.840.113549.1.7.1, что нехорошо.
ContentInfo.ContentType при этом заполнен корректно (1.2.840.113549.1.7.1).

from corefx.

Добрый день!
Данный способ сработал для нас.
Но как я понимаю окончательно проблема решится с переводом форка на .Net7?

Судя по всему есть внутренняя логика в EnvelopedCms по работе с различными ContentType. По крайней мере для Pkcs7Data = "1.2.840.113549.1.7.1" есть отдельная ветка:

PkcsPalWindows

public sealed unsafe override byte[] Encrypt(...)
{
    if (contentInfo.ContentType.Value.Equals(Oids.Pkcs7Data, StringComparison.OrdinalIgnoreCase))
    { 
        CryptEncodeObjectToByteArray(); 
    }
    else
    { 
        CryptMsgUpdate(); 
    }
}

@Chiffafaust Попробуйте при шифровании выставить ContentType в Pkcs7Signed (1.2.840.113549.1.7.2):

ContentInfo contentInfo = new ContentInfo(
    new Oid("1.2.840.113549.1.7.2"),
    msg);
EnvelopedCms envelopedCms = new EnvelopedCms(contentInfo);

// остальной код

Если поможет - отпишитесь пожалуйста.

from corefx.

Для целей подпись-шифрование описанный выше метод не столько "обход бага", сколько корректный способ (так мы сообщаем, что наши данные уже представлены в ASN1 (так как это SignedCms) и их кодировка для шифрования не требуется), так что использование Oid("1.2.840.113549.1.7.2") можно оставить.

Что касается оборачивания и "сырых" данных при шифровании в OCTET STRING - пока выясняем, откуда берётся. Если сможем поправить - поправим.

from corefx.

Спасибо!

from corefx.

С CSP 5.0.12900 проблема должна быть решена.
CryptoPro/libcore#17

from corefx.