Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Наши способы организации безопасного удалённого доступа к рабочим местам и корпоративным ресурсам
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline Андрей Врагов  
#1 Оставлено : 25 августа 2020 г. 18:52:03(UTC)
Андрей Врагов

Статус: Новичок

Группы: Участники
Зарегистрирован: 11.04.2017(UTC)
Сообщений: 9

Всем доброго дня!

Интересует способ построения в .NET Framework/Core (C#) списка сертификатов субъектов, выданных на одном и том же корне. Имеется двухуровневая схема УЦ (корневой и подчиненный) и конечные субъекты. Как оптимально построить список сертификатов субъектов, чьи цепочки доверия имеют один и тот же корень? Пока вижу только один способ - построение цепочек по каждому сертификату субъекта до корня, и если корень удовлетворяет условиям поиска, то добавление серта субъекта в список. Интересут, например, вариант сделать это с использованием класса Enumerable из namespace'а System.Linq. Но как связать два серта субъекта и УЦ, по какому свойству? Насколько я понимаю, прямой связи между сертами нет, а есть только связь посредством ЭП серта субъекта выданного на ключе УЦ. Т.е. необходима проверка ЭП серта субъекта при помощи серта УЦ. И если я прав, то класс X509Chain строит цепочку доверия как раз используя эти проверки ЭП.
В общем хотелось бы услышать мнения мастеров.
Offline Андрей *  
#2 Оставлено : 25 августа 2020 г. 19:00:55(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Здравствуйте.

Строить по Идентификатору ключа ЦС.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей Врагов  
#3 Оставлено : 26 августа 2020 г. 18:31:47(UTC)
Андрей Врагов

Статус: Новичок

Группы: Участники
Зарегистрирован: 11.04.2017(UTC)
Сообщений: 9

Автор: Андрей * Перейти к цитате
Здравствуйте.

Строить по Идентификатору ключа ЦС.


var caKeyId = x509.Extensions.Cast<X509Extension>()
.Where(n => n.Oid.Value.Equals("2.5.29.35"))
.Select(n => new AsnEncodedData(n.Oid, n.RawData))
.Select(n => n.Format(true))
.FirstOrDefault();

При помощи такого кода я выбираю содержимое, но там кроме идентификатора ключа ЦС присутствует и другая информация типа серийного номера серта и названия ЦС. Есть ли варианты сразу получить только ИД ключа ЦС или надо самому парсить содержимое?
Offline Андрей *  
#4 Оставлено : 26 августа 2020 г. 18:43:16(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Можно декодировать или просто взять 20 байтов,
это sha1 от структуры с открытым ключом Уц, в hex 40 длина, её показывает ОС.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей Врагов  
#5 Оставлено : 27 августа 2020 г. 18:42:26(UTC)
Андрей Врагов

Статус: Новичок

Группы: Участники
Зарегистрирован: 11.04.2017(UTC)
Сообщений: 9

Автор: Андрей * Перейти к цитате
Можно декодировать или просто взять 20 байтов,
это sha1 от структуры с открытым ключом Уц, в hex 40 длина, её показывает ОС.

А как декодировать? Вроде как в .NET нет такого класса, который бы соответствовал расширению AKI. Или можно каким-то образом использовать CX509ExtensionAuthorityKeyIdentifier из CERTENROLLLib? Я попытался, но не понял как использовать метод InitializeDecode. Просто не хочется колхозить самому и разбирать байтовый массив AKI, чтобы вытащить оттуда поле keyIdentifier. Понимаю, что это абсолютно несложно сделать, но хотелось бы воспользоваться какими-то стандартными инструментами.
P.S. Кстати, насколько я понял из описания Microsoft для расширения AKI, цеопчка доверия как раз и строится на его основе и расширения SKI из серта вышестоящего УЦ. Т.е. в поле keyIdentifier из AKI записывается sha1 от PublicKey УЦ. Но sha1 вроде как признан уязвимым еще несколько лет назад. Тогда собственно доверие к цепочке, построенной таким образом, тоже пропадает.

Offline Андрей Врагов  
#6 Оставлено : 27 августа 2020 г. 18:44:40(UTC)
Андрей Врагов

Статус: Новичок

Группы: Участники
Зарегистрирован: 11.04.2017(UTC)
Сообщений: 9

Да, кстати, получать keyIdentifier через подсчет sha1 от открытого ключа вышестоящего УЦ тоже не хочется. А вдруг завтра это уже не будет sha1.
Offline Андрей *  
#7 Оставлено : 27 августа 2020 г. 18:46:55(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: Андрей Врагов Перейти к цитате
Но sha1 вроде как признан уязвимым еще несколько лет назад. Тогда собственно доверие к цепочке, построенной таким образом, тоже пропадает.


не имеет отношения ... хеш - для быстрого поиска - есть ли в хранилище такой сертификат, далее - выполняется же .. проверка самой подписи в выданном сертификате с учётом найденного сертификата УЦ.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#8 Оставлено : 27 августа 2020 г. 18:55:38(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: Андрей Врагов Перейти к цитате
Да, кстати, получать keyIdentifier через подсчет sha1 от открытого ключа вышестоящего УЦ тоже не хочется. А вдруг завтра это уже не будет sha1.


RFC будут менять для начала... софт переписывать все...


Код:



 foreach (X509Extension extension in  Certificate.Extensions)

 if (extension.Oid.Value.ToString() == "2.5.29.35")

  использовать extension.RawData.Length
  и extension.RawData 


типа:
  StringBuilder sb2 = new StringBuilder();

 if (extension.RawData.Length > 30)
                         {
                             for (int i = 6; i < 26; i++)
                             {
                                 sb2.Append(extension.RawData[i].ToString("X2"));
                             }
                         }
                         else
                         {
                             for (int i = 4; i < extension.RawData.Length; i++)
                             {
                                 sb2.Append(extension.RawData[i].ToString("X2"));
                             }
                         }




Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#9 Оставлено : 27 августа 2020 г. 19:15:06(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Два варианта:

1.
Snimok ehkrana ot 2020-08-27 20-12-59.png (77kb) загружен 6 раз(а).

2.
Snimok ehkrana ot 2020-08-27 20-14-18.png (69kb) загружен 6 раз(а).



Техническую поддержку оказываем тут
Наша база знаний
Online KDA  
#10 Оставлено : 28 августа 2020 г. 13:00:33(UTC)
KDA

Статус: Активный участник

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 38

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 4 раз в 4 постах
Прошу прощения, что встреваю, но истина дороже :)

RFC 5280 не имеет требований, что идентификатор ключа должен быть 20 байтов или что это должен быть SHA-1
Оговорка про 20 октетов есть у серйиного номера, но это несколько другое.

На практике видел сертификаты, у которых это поле было большей размерности. И это удовлетворяло формулировкам упомянутого RFC.
Offline Андрей *  
#11 Оставлено : 28 августа 2020 г. 13:17:06(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: KDA Перейти к цитате
Прошу прощения, что встреваю, но истина дороже :)

RFC 5280 не имеет требований, что идентификатор ключа должен быть 20 байтов или что это должен быть SHA-1
Оговорка про 20 октетов есть у серйиного номера, но это несколько другое.

На практике видел сертификаты, у которых это поле было большей размерности. И это удовлетворяло формулировкам упомянутого RFC.



certutil выводит по Хеш ИД ключа (rfc-sha1) и Хеш ИД ключа (sha1)
Snimok ehkrana ot 2020-08-28 14-09-42.png (56kb) загружен 3 раз(а).



4.2.1.1. Authority Key Identifier
ссылается на
Two common methods for generating key
identifiers from the public key are described in Section 4.2.1.2.

где написано:
Цитата:
(1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
value of the BIT STRING subjectPublicKey (excluding the tag,
length, and number of unused bits).


(2) The keyIdentifier is composed of a four-bit type field with
the value 0100 followed by the least significant 60 bits of
the SHA-1 hash of the value of the BIT STRING
subjectPublicKey (excluding the tag, length, and number of
unused bits).






Техническую поддержку оказываем тут
Наша база знаний
Online KDA  
#12 Оставлено : 28 августа 2020 г. 13:40:30(UTC)
KDA

Статус: Активный участник

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 38

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 4 раз в 4 постах
Забыли существенное
ДО
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:

Т.е. в лучшем случае - рекомендации. Иначе было бы MUST

И после (самое главное):

Other methods of generating unique numbers are also acceptable.

Т.е. там вполне мог бы быть, например, ГОСТ-хеш, у которого размер побольше
Offline Андрей *  
#13 Оставлено : 28 августа 2020 г. 13:43:52(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: KDA Перейти к цитате
Забыли существенное
ДО
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:

Т.е. в лучшем случае - рекомендации. Иначе было бы MUST

И после (самое главное):

Other methods of generating unique numbers are also acceptable.

Т.е. там вполне мог бы быть, например, ГОСТ-хеш, у которого размер побольше


Технически кто-то должен это для начала реализовать и поддерживать. А сейчас sha1
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#14 Оставлено : 28 августа 2020 г. 13:49:09(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
SHOULD должен.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#15 Оставлено : 28 августа 2020 г. 13:51:24(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: KDA Перейти к цитате
Забыли существенное
ДО
For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:

Т.е. в лучшем случае - рекомендации. Иначе было бы MUST

Для сертификатов CA идентификаторы ключа субъекта ДОЛЖНЫ быть получены из
открытого ключа или метод, генерирующий уникальные значения.
Техническую поддержку оказываем тут
Наша база знаний
Offline two_oceans  
#16 Оставлено : 28 августа 2020 г. 13:57:23(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,125
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 75 раз
Поблагодарили: 257 раз в 241 постах
Оно конечно может быть изменено, но смысл менять? Для поиска важно чтобы:
- способ вычисления давал достаточно длинное значение (160 бит примерно 10 в 48 степени, столько сертификатов нескоро навыпускают)
- не выдавал одно значение на разные данные (это общее у всех хэшей, пока вариантов данных намного меньше чем значений - результаты практически уникальны)
- был быстрым (sha1 отточили до предела за годы).
Поэтому смысл менять будет только если найдется алгоритм дающий 160 бит быстрее чем sha1. Гост-2012 дает больше бит, но и считается дольше.

Какая разница спорить про SHOULD/MUST там "Должен" только про уникальность идентификатора и не более того.

К слову, в xades-bes вместо отпечатка считается хэш от всего сертификата, расчет возможен по гост-2012 (алгоритм можно выбрать). Так что старые хэши уже только там где их реально нет смысла обновлять (в поисковых идентификаторах).

Отредактировано пользователем 28 августа 2020 г. 13:58:27(UTC)  | Причина: Не указана

Online KDA  
#17 Оставлено : 28 августа 2020 г. 19:17:47(UTC)
KDA

Статус: Активный участник

Группы: Участники
Зарегистрирован: 12.10.2009(UTC)
Сообщений: 38

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 4 раз в 4 постах
Автор: Андрей * Перейти к цитате


Для сертификатов CA идентификаторы ключа субъекта ДОЛЖНЫ быть получены из
открытого ключа или метод, генерирующий уникальные значения.


Ну и вообще забавно, сначала
Цитата:
RFC будут менять для начала... софт переписывать все...


Т.е. RFC уже не переписываем, а переводим.
Но к переводу рекомендую обратиться так же к RFC 2119
Там объясняют разницу между словами капсом.

Так же не надо никакой софт переписывать, если изначально не кодировать в него ограничение в 20 байт.

Так же, из 5280 Про authority key identifier (Выделил жирным)
Цитата:
Two common methods for generating key
identifiers from the public key are described in Section 4.2.1.2.
Where a key identifier has not been previously established, this
specification RECOMMENDS use of one of these methods for generating
keyIdentifiers or use of a similar method that uses a different hash
algorithm
.



Автор: two_oceans Перейти к цитате
Оно конечно может быть изменено, но смысл менять?


Позволю повториться
Автор: KDA Перейти к цитате

На практике видел сертификаты, у которых это поле было большей размерности.


Видел в продакшене. Хеш по какому-то из ГОСТов. Правда, это не КриптоПро, что не отменяет факта, что
"просто взять 20 байт" - это, мягко говоря, некорректно.

Автор: two_oceans Перейти к цитате

К слову, в xades-bes вместо отпечатка считается хэш от всего сертификата, расчет возможен по гост-2012 (алгоритм можно выбрать). Так что старые хэши уже только там где их реально нет смысла обновлять (в поисковых идентификаторах).


Та же ситуация, кстати. Выбрать можно, если подписанные атрибуты генерировать самостоятельно. А если проверять - придется разбираться с тем, что дали.
Как и с длиной идентификатора ключа, которую мог сгенерировать неизвестный софт.

Отредактировано пользователем 28 августа 2020 г. 19:27:09(UTC)  | Причина: Не указана

Offline Андрей *  
#18 Оставлено : 28 августа 2020 г. 19:32:52(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: KDA Перейти к цитате
Автор: Андрей * Перейти к цитате


Для сертификатов CA идентификаторы ключа субъекта ДОЛЖНЫ быть получены из
открытого ключа или метод, генерирующий уникальные значения.


Ну и вообще забавно, сначала
Цитата:
RFC будут менять для начала... софт переписывать все...


Т.е. RFC уже не переписываем, а переводим.
Но к переводу рекомендую обратиться так же к RFC 2119
Там объясняют разницу между словами капсом.

Так же не надо никакой софт переписывать, если изначально не кодировать в него ограничение в 20 байт.

Так же, из 5280 Про authority key identifier (Выделил жирным)
Цитата:
Two common methods for generating key
identifiers from the public key are described in Section 4.2.1.2.
Where a key identifier has not been previously established, this
specification RECOMMENDS use of one of these methods for generating
keyIdentifiers or use of a similar method that uses a different hash
algorithm
.



Автор: two_oceans Перейти к цитате
Оно конечно может быть изменено, но смысл менять?


Позволю повториться
Автор: KDA Перейти к цитате

На практике видел сертификаты, у которых это поле было большей размерности.


Видел в продакшене. Хеш по какому-то из ГОСТов. Правда, это не КриптоПро, что не отменяет факта, что
"просто взять 20 байт" - это, мягко говоря, некорректно.

Автор: two_oceans Перейти к цитате

К слову, в xades-bes вместо отпечатка считается хэш от всего сертификата, расчет возможен по гост-2012 (алгоритм можно выбрать). Так что старые хэши уже только там где их реально нет смысла обновлять (в поисковых идентификаторах).


Та же ситуация, кстати. Выбрать можно, если подписанные атрибуты генерировать самостоятельно. А если проверять - придется разбираться с тем, что дали.
Как и с длиной идентификатора ключа, которую мог сгенерировать неизвестный софт.


Речь была вообще не о прикладной софте. Как ОС будет искать, думая, что там sha1, а по факту sha512?


А в целом, я предложил вариант, чтобы не декодировать asn1, не подключать тот же BC...

Нужно правильное решение? Да, начинаем читать все rfc, с 90х, чтобы иметь понятия, что означает SHOULD и почему нет до сих пор MUST

Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#19 Оставлено : 28 августа 2020 г. 19:41:26(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Хотя нет, о чем я, sha1, sha512, гост, без разницы же, это просто идентификатор, для поиска
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#20 Оставлено : 28 августа 2020 г. 19:46:57(UTC)
Андрей *

Статус: Сотрудник

Группы: Участники
Зарегистрирован: 26.07.2011(UTC)
Сообщений: 9,737
Мужчина
Российская Федерация

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Тогда взять RAW расширения, прочитать размер идентификатора и считать его. Всё.

Техническую поддержку оказываем тут
Наша база знаний
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.