Форматы электронной подписи

[vanxant]

Вы лучше скажите, когда уже наступит всеобщее киберсчастье? В смысле можно будет прийти с паспортом в любой <название организации>, купить брелок и получить свою личную стандартную ЭЦП, которую будут обязаны принимать все, хоть госорганы, хоть частные конторы?
Когда можно будет сделать то же самое для юрлиц?
Когда, наконец, можно будет настроить почтовый клиент на режим «не принимать емейлы без валидной ЭЦП отправителя»?

[VicTun]

«Коммунизм в СССР будет построен к 1980 году» © :)

[toxicdream]

Обещанного три года ждут.
Применяем это к стандартной формуле «вычисление сроков реализации ИТ-проектов»: взять следующую временной интервал и помножить на два то получаем:
3 года => 30 лет; 30 лет * 2 = 60 лет.
Когда там ГОСТ был реализован в OpenSSL? В 2012-м? Значит к году этак 2072-му возможно будет вам ваше киберсчастье.

[as1an]

Кажется, Казахстану грех жаловаться в плане развития на пути к киберсчастью)

[bolk]

Гораздо раньше.

[Disasm]

О, может мне сразу тут спросить по поводу вашей продукции? Вот есть Rutoken ЭЦП, у которого заявлена аппаратная поддержка шифрования ГОСТ и защищённый микроконтроллер. На деле там самый обыкновенный зарубежный микроконтроллер общего назначения (NXP LPC1765FET100), у которого 99.9% что нет аппаратной поддержки ГОСТ, и, скорее всего, ещё и хорошей защиты. Как так получается? На бумаге одно, а на деле другое.

[Mingun]

Картинки у вас хорошие, понятные, даже вроде что-то проясняют, если бы не информация из других источников… Вот, в частности, возникают такие вопросы:

1. В данной статье говорится, что подпись вычисляется от части структуры данных, называемой TBS (to be signed — для подписи). Там же говорится, что это просто первый элемент SEQUENCE второго уровня вложенности. В вашей же статье получается, что подписываются блоки Content и Signed Attributes, которые расположены в разных частях сообщения и не являются одним целым куском данных. Как же так, где правда? И если она на вашей стороне, то все-таки от какого массива байт считается подпись?
2. Второй вопрос: где-то описано, что вообще может содержать PKCS#7? Вот на ваших картинках видно, что внутри у него могут содержаться блоки CMS Version, Digest Algorithms и т.п. А где полный список того, какие блоки могут быть?
3. Судя по описанию элемента SET нотации ASN.1 порядок данных в нем не определен. Из вашего же описания содержимого PKCS#7 можно понять, что блоки Digest Algorithms (блок типа SET) и SignedInfo (все они тоже лежат в блоке типа SET, на вашей картинке этот блок-контейнер не показан) содержат список алгоритмов вычисления хеша для подписей и прочую информацию о подписях. Однако каким образом эти значения сопоставляются, ведь порядок в элементе SET не определен? С какой стати я должен считать, что первый Digest Algorithm в блоке Digest Algorithms относится к первой структуре SignedInfo, а не ко второй или десятой? И сопутствующий вопрос — зачем вообще нужен блок Digest Algorithm, почему эту информацию нельзя поместить в блок SignedInfo (а она там и есть, похоже)?
4. Почему в блоках Digest algorithm написано Alice/Bob signature algorithm?

[xelya]

Наверное, вы единственный человек, который вдумчиво прочитал статью!

1. Подписывается только блок Signed Attributes, в котором уже подсчитан хеш сообщения Content. См. RFC

2. Все и описаны согласно RFC:
SignedData ::= SEQUENCE {
version CMSVersion,
digestAlgorithms DigestAlgorithmIdentifiers,
encapContentInfo EncapsulatedContentInfo,
certificates [0] IMPLICIT CertificateSet OPTIONAL,
crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
signerInfos SignerInfos }

3. Вы сами ответили на свой вопрос! Именно для однозначности в Signer Info присутствует поле Digest Algorithm. А вот в Signed Info лежит как раз результат хеширования Content. Мне кажется, оригинал стандарта ответит на ваши вопросы языком нотации ASN.1 гораздо яснее, чем я русским в вольном переложении.

4. Пасхалка найдена! Ошибка чистой воды, конечно, спасибо за вашу внимательность.