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

Уведомление

Icon
Error

2 Страницы<12
Опции
К последнему сообщению К первому непрочитанному
Offline KDA  
#21 Оставлено : 28 августа 2020 г. 19:52:32(UTC)
KDA

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 4 раз в 4 постах
Автор: Андрей * Перейти к цитате
Нужно правильное решение? Да, начинаем читать все rfc, с 90х, чтобы иметь понятия, что означает SHOULD и почему нет до сих пор MUST


Не обязательно все. MUST и MUST NOT в одном 5280 более чем достаточно. Как и преамбулы (Раздел Introduction, как ни странно) с отсылкой на RFC с их трактовкой.
Ну и по практике CryptoApi. Есть функционал, расчитывающий не более чем на 20 байт, но не попадалось - на фиксированную длину keyIdentifier.

Ну и для резюме - вывод certutil из последней десятки (сколько разных keyid):
Цитата:

Signature Algorithm:
Algorithm ObjectId: 1.2.643.7.1.1.3.2 GOST R 34.11-2012/34.10-2012 256 bit
Algorithm Parameters: NULL
Signature: UnusedBits=0
0000 c6 3c 76 37 6f 27 56 7e ed 72 00 98 1e 3a f0 e4
0010 fb e8 a9 59 18 11 fb fd ea 61 23 d8 99 69 f8 2f
0020 38 56 c2 ec c7 0f 1c 52 ba fc 4d 1b 14 f2 5e 92
0030 b3 91 d4 5c 23 71 04 a3 ad 56 e2 24 ac ec b1 ec
Non-root Certificate
Key Id Hash(rfc-sha1): 81b9a2d526242d98c66d467b4f57a0dd8c5e3085
Key Id Hash(sha1): b78e32a4b4b3c3ffec3e0d9849e7095b3289fbe4
Key Id Hash(md5): 3e4223ee82b477defdec7222302e99f4
Key Id Hash(sha256): 1b56c5011dabf271ab5100ddda24022086f01f9806a063c361449fcc5bcf26fc
Key Id Hash(pin-sha256): VSuX+RNIMMYaR+aesHpfiTThQHChqBMrBE39Zv8Mhss=
Key Id Hash(pin-sha256-hex): 552b97f9134830c61a47e69eb07a5f8934e14070a1a8132b044dfd66ff0c86cb
Cert Hash(md5): 4674851debe8916bc651444b2cc56ced
Cert Hash(sha1): 7df2bb42466869c44cafcfcdf3df930902eccde6
Cert Hash(sha256): 46e7d0fe2b81850c289177d358252f4b4b94e3f8766a00817c036bec83089882
Signature Hash: dcaf8a7b46e571097448a94f11e1b06c9c1f79e5216974bce5e1eca9b0ad8ee3
CertUtil: -dump command completed successfully.

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

Offline Андрей *  
#22 Оставлено : 28 августа 2020 г. 20:06:03(UTC)
Андрей *

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

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

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
Автор: KDA Перейти к цитате
Автор: Андрей * Перейти к цитате
Нужно правильное решение? Да, начинаем читать все rfc, с 90х, чтобы иметь понятия, что означает SHOULD и почему нет до сих пор MUST


Не обязательно все. MUST и MUST NOT в одном 5280 более чем достаточно. Как и преамбулы (Раздел Introduction, как ни странно) с отсылкой на RFC с их трактовкой.
Ну и по практике CryptoApi. Есть функционал, расчитывающий не более чем на 20 байт, но не попадалось - на фиксированную длину keyIdentifier.

Ну и для резюме - вывод certutil из последней десятки (сколько разных keyid):
Цитата:

Signature Algorithm:
Algorithm ObjectId: 1.2.643.7.1.1.3.2 GOST R 34.11-2012/34.10-2012 256 bit
Algorithm Parameters: NULL
Signature: UnusedBits=0
0000 c6 3c 76 37 6f 27 56 7e ed 72 00 98 1e 3a f0 e4
0010 fb e8 a9 59 18 11 fb fd ea 61 23 d8 99 69 f8 2f
0020 38 56 c2 ec c7 0f 1c 52 ba fc 4d 1b 14 f2 5e 92
0030 b3 91 d4 5c 23 71 04 a3 ad 56 e2 24 ac ec b1 ec
Non-root Certificate
Key Id Hash(rfc-sha1): 81b9a2d526242d98c66d467b4f57a0dd8c5e3085
Key Id Hash(sha1): b78e32a4b4b3c3ffec3e0d9849e7095b3289fbe4
Key Id Hash(md5): 3e4223ee82b477defdec7222302e99f4
Key Id Hash(sha256): 1b56c5011dabf271ab5100ddda24022086f01f9806a063c361449fcc5bcf26fc
Key Id Hash(pin-sha256): VSuX+RNIMMYaR+aesHpfiTThQHChqBMrBE39Zv8Mhss=
Key Id Hash(pin-sha256-hex): 552b97f9134830c61a47e69eb07a5f8934e14070a1a8132b044dfd66ff0c86cb
Cert Hash(md5): 4674851debe8916bc651444b2cc56ced
Cert Hash(sha1): 7df2bb42466869c44cafcfcdf3df930902eccde6
Cert Hash(sha256): 46e7d0fe2b81850c289177d358252f4b4b94e3f8766a00817c036bec83089882
Signature Hash: dcaf8a7b46e571097448a94f11e1b06c9c1f79e5216974bce5e1eca9b0ad8ee3
CertUtil: -dump command completed successfully.

Мы про парсинг данных, в сертификате.
А хешей можно всяких написать.
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#23 Оставлено : 28 августа 2020 г. 20:11:54(UTC)
Андрей *

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

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

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
>Есть функционал, расчитывающий не более чем на 20 байт, но не попадалось - на фиксированную длину keyIdentifier.


Это про вывод от CertUtil?
Я не встречал ещё не 20 байтный идентификатор ключа в сертификате. Если есть пример, приложите
Техническую поддержку оказываем тут
Наша база знаний
Offline two_oceans  
#24 Оставлено : 31 августа 2020 г. 13:42:48(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 75 раз
Поблагодарили: 257 раз в 241 постах
Автор: Андрей * Перейти к цитате
Тогда взять RAW расширения, прочитать размер идентификатора и считать его. Всё.
В общем да, вопрос этим и исчерпывается. Детали что ASN1 представления длины могут быть разные в зависимости DER BER или еще что несущественны, если делать через библиотечную функцию умеющую их все читать.
KDA написал:
Так же не надо никакой софт переписывать, если изначально не кодировать в него ограничение в 20 байт.
Согласен полностью.
KDA написал:
Видел в продакшене. Хеш по какому-то из ГОСТов. Правда, это не КриптоПро
Ну так, как бы помягче сказать, этому разве место на Форуме КриптоПро? Это раз. Конечно все по-разному к КриптоПро относятся, но по факту это стандарт, который используют большинство отечественных организаций. Аналогично с параметрами гост - их можно задать разные, но фактически почти везде используют предложенные КриптоПро - так больше шанс, что подпись проверится другими криптопровайдерами.

Есть исходники на Си от Майкрософт с базовым кодом криптопровайдера, на их основе может любой Анонимус написать любой криптопровайдер как захочет и сформировать хэш для идентификатора ключа как захочет, это два. Поэтому наверно надо ограничить круг официальными (сертифицированными в случае отечественных) криптопровайдерами. Желательно бы пруф по этому поводу из нормативки ТК26, раз речь про гост.
KDA написал:
А если проверять - придется разбираться с тем, что дали.
Да, это естественно. Или отбраковать все подписи не подходящие под некие параметры установленные в неком своем нормативном акте. Сейчас большинство ГИС так делают опубликуют критерии и все неподходящее бракуют.

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

Offline Андрей Врагов  
#25 Оставлено : 31 августа 2020 г. 17:26:07(UTC)
Андрей Врагов

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

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

Цитата:

Мы про парсинг данных, в сертификате.
А хешей можно всяких написать.

Согласен. Важно иметь четкий алгоритм как вытащить KI из AKI. А по какой методике KI был сформирован это уже вторично. Если я правильно рассуждаю, то и KI в AKI серта субъекта, и KI в SKI из собственного серта УЦ будут сформированы по одной и той же методике, если это корневой УЦ. А вот как это будет работать в иерархической схеме, когда есть три сущности: Корневой УЦ, промежуточный и конечный пользователь?
Насколько я понимаю, в этом случае в самоподписанном серте УЦК будет только SKI, в серте промежуточного УЦ будет AKI и SKI, сформированные УЦК, а в серте пользователя будут AKI, сформированый УЦК и SKI, сформированный промежуточным УЦ. И в случае, если в УЦК и в промежуточном УЦ алгоритмы формирования KI различны, то и в серте пользователя AKI, сформирован УЦК, а SKI, сформированный промежуточным УЦ, тоже будут различны.
Кстати, Андрей, с длиной RawData в вашем примере ошибка. Длина, возвращаемая RawData.Legth, включает в себя и байт идентификатора самого тэга SEQUENCE и байты длины его содержимого. За тэгом обычно следует длина содержимого. В том случае, если длина SEQUENCE больше 127, то используется длинная форма записи длины 80+N, где N указывает количество байт поля длины, следующего за этим байтом.
Например,
1). Если длина SEQUENCE 320 байт, тогда его заголовок в 16-ричной системе будет записан как 30 (ид тэга), 82 (80 + 2, где 2 - количество байт следующей длины), 0140 (длина 320 в десятичной системе).
2). Если длина SEQUENSE 211 байт, тогда его заголовок в 16-ричной системе будет записан как 30 (ид тэга), 81 (80 + 1, где 1 - количество байт следующей длины), D3 (длина 211 в десятичной системе).
3). Если длина SEQUENCE 69 байт, тогда его заголовок в 16-ричной системе будет записан как 30 (ид тэга), 45 (длина 69 в десятичной системе).
Таким образом, с учетом тэга CONTEXT SPECIFIC (+2 байта) если длина SEQUENCE от 1 до 127 байт включительно, то KI с учетом наличия начинаем отсчитывать от RawData[4], если от 128 до 255 - от RawData[5], если от 256 до 65535 - от RawData[6]. Если KI это sha1, то берем 20 байт.
Как-то так вроде.


Offline Андрей *  
#26 Оставлено : 31 августа 2020 г. 18:27:08(UTC)
Андрей *

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

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

Сказал «Спасибо»: 357 раз
Поблагодарили: 1406 раз в 1084 постах
А встречали вариант от rawdata5?
Техническую поддержку оказываем тут
Наша база знаний
Offline Андрей *  
#27 Оставлено : 31 августа 2020 г. 19:34:27(UTC)
Андрей *

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

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

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

Кстати, Андрей, с длиной RawData в вашем примере ошибка. Длина, возвращаемая RawData.Legth, включает в себя и байт идентификатора самого тэга SEQUENCE и байты длины его содержимого. За тэгом обычно следует длина содержимого. В том случае, если длина SEQUENCE больше 127, то используется длинная форма записи длины 80+N, где N указывает количество байт поля длины, следующего за этим байтом.


Да, мне известно это, привёл пример, как "быстро и не думая получить", а не послал изучать ASN.1.
и сам не разобрал размер, не написал парсинг с учётом вариантов,
дал всего лишь 2 условия на проверку размера. Полностью признаю, как и про sha1, который вдруг может быть не sha1 в какой-то ИС или когда нибудь...


по коду "всё просто", 2 условия - когда в 2.5.29.35 есть только идентификатор (меньше 30 байт "проверка") и больше,
а сразу с 6 байта, т.к. "известно из практики", что туда пишется...

Snimok ehkrana ot 2020-08-31 20-14-44.png (28kb) загружен 6 раз(а).


Техническую поддержку оказываем тут
Наша база знаний
Offline KDA  
#28 Оставлено : 31 августа 2020 г. 21:32:25(UTC)
KDA

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

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

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

Ну так, как бы помягче сказать, этому разве место на Форуме КриптоПро? Это раз. Конечно все по-разному к КриптоПро относятся, но по факту это стандарт, который используют большинство отечественных организаций. Аналогично с параметрами гост - их можно задать разные, но фактически почти везде используют предложенные КриптоПро - так больше шанс, что подпись проверится другими криптопровайдерами.


Кажется, при старте темы не указывалось, что сертификаты для поиска созданы исключительно средствами КриптоПро. Кроме того, проверка подписи и содержимое стандартных расширений - это, как бы, немного разные темы.

Цитата:
Есть исходники на Си от Майкрософт с базовым кодом криптопровайдера, на их основе может любой Анонимус написать любой криптопровайдер как захочет и сформировать хэш для идентификатора ключа как захочет, это два. Поэтому наверно надо ограничить круг официальными (сертифицированными в случае отечественных) криптопровайдерами. Желательно бы пруф по этому поводу из нормативки ТК26, раз речь про гост.


Нормативки по софту имеют смысл только при использовании сертифицированного ПО для создания сертификатов - это раз.

Процесс создания запроса на сертификат и сертификата по запросу не имеет ничего общего с упомянутыми исходниками Microsoft.
минимальные обязанности CSP - экспорт низкоуровневых функкций криптографии. Отдельной функции на формирование хеша ключа там нет. Если не верите - можно взять отладчик и посмотреть, в каких случаях получает управление код КриптоПро и когда - Microsoft в CryptoAPI. Это два.

В имеющихся в наличии документах TK26 (и выросших из них рекомендаций по стандартизации) есть ссылки на RFC5280 в плане базовых структур X.509. Мне это достаточно. Если хотите доказать, что я не прав, то пруфы нужны уже от Вас. Это три :)

Отредактировано пользователем 31 августа 2020 г. 22:06:41(UTC)  | Причина: Не указана

Offline Андрей Врагов  
#29 Оставлено : 1 сентября 2020 г. 12:59:57(UTC)
Андрей Врагов

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

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

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

Да, мне известно это, привёл пример, как "быстро и не думая получить", а не послал изучать ASN.1.


За это большое спасибо.

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

по коду "всё просто", 2 условия - когда в 2.5.29.35 есть только идентификатор (меньше 30 байт "проверка") и больше,
а сразу с 6 байта, т.к. "известно из практики", что туда пишется...

Snimok ehkrana ot 2020-08-31 20-14-44.png (28kb) загружен 6 раз(а).



Но вот здесь все-таки неправильно. Как минимум три диапазона м.б.: от 1 до 127, от 128 до 255 и от 256 до 65535. Больше 65535 рассматривать не имеет смысла наверное. Вряд ли AKI будет такой длины. А вот второй диапазон вполне вероятен. У меня такой вариант был. Если длины KI и SN из AKI статичны (для сертов КриптоПро по крайней мере), то authorityCertIssuer зависит от параметров УЦ (ОГРН, ИНН и т.п.). Так что длина AKI вполне может быть от 128 до 255
Offline two_oceans  
#30 Оставлено : 1 сентября 2020 г. 13:54:01(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 75 раз
Поблагодарили: 257 раз в 241 постах
Автор: KDA Перейти к цитате
Кажется, при старте темы не указывалось, что сертификаты для поиска созданы исключительно средствами КриптоПро. Кроме того, проверка подписи и содержимое стандартных расширений - это, как бы, немного разные темы.
Разные конечно, но мысль такая что всем будет глубоко все равно если одна редко распространенная программа не будет работать с очень распространенной. Более вероятно, что станут дорабатывать редкую на совместимость с частой чем наоборот.

Автор: KDA Перейти к цитате
Цитата:
Есть исходники на Си от Майкрософт с базовым кодом криптопровайдера, на их основе может любой Анонимус написать любой криптопровайдер как захочет и сформировать хэш для идентификатора ключа как захочет, это два. Поэтому наверно надо ограничить круг официальными (сертифицированными в случае отечественных) криптопровайдерами. Желательно бы пруф по этому поводу из нормативки ТК26, раз речь про гост.
Нормативки по софту имеют смысл только при использовании сертифицированного ПО для создания сертификатов - это раз.
Ну так а смысл пытаться обнять необъятное и учитывать все несертифицированное ПО, сделанное на коленке.
Автор: KDA Перейти к цитате
Процесс создания запроса на сертификат и сертификата по запросу не имеет ничего общего с упомянутыми исходниками Microsoft.
минимальные обязанности CSP - экспорт низкоуровневых функкций криптографии. Отдельной функции на формирование хеша ключа там нет. Если не верите - можно взять отладчик и посмотреть, в каких случаях получает управление код КриптоПро и когда - Microsoft в CryptoAPI. Это два.
Нисколько не спорю, что в случае КриптоПро велосипед не изобретали и отдали проверку коду Майкрософт, который реализует функционал высокого уровня из базовых низкоуровневых функций. Это отнюдь не значит что высокоуровневые функции не могут быть переопределены криптопровайдером. В CryptoAPI очень много функций, которые можно перегрузить или, как с сожалением приходится признать, "пропатчить" (так как Майкрософт не дает возможность их поменять без патча и даже те самые исходники без патча не заводятся). Поэтому "левый" криптопровайдер может "заодно" пропатчить и код связанный с сертификатами. Что ему помешает?

Потому мою мысль стоит понимать как предложение ограничиться разумными примерами реализации, ведь неразумными методами можно переписать половину операционки и хотя это докажет возможность, такой компьютер будет практически штучный. Да, серьезно, еще есть энтузиасты портирующие фреймворки и библиотеки на Windows 2000 (ну правда перенесенных библиотек там по размеру уже больше чем размер исходной Windows 2000).

Далее, примем с Ваших же слов, при работе с сертификатом выполняется код Microsoft и тогда вопрос - где в нем вариативность вычисления идентификатора ключа? Про то что теоретически возможно и допускается rfc я не спорю. Но, какая выгода, кроме желания Майкрософт продать очередную версию операционки под лозунгами безопасности? Именно лозунгами, потому что по факту безопасности от перехода с sha1 на sha256 прибавляется очень мало. Да, времени на вскрытие шифра потребуется меньше, но если задаться целью за 30 лет все равно можно расшифровать почти любую переписку. Если Вашу переписку зашифрованную записали, то все - прочитать вопрос времени. С другой стороны, даже самые слабые шифры продержаться пару часов и именно такая пара часов имеет критическое значение (на финансовых рынках, при расследованиях и т.д.). Толка от смены хеша в идентификаторе ключа вообще нет, но маркетинг такой маркетинг. Как рядовому пользователю поможет использование трех представлений одно и того же значения хэша на одном скриншоте Десятки, приведенном Вами?
Автор: KDA Перейти к цитате
В имеющихся в наличии документах TK26 (и выросших из них рекомендаций по стандартизации) есть ссылки на RFC5280 в плане базовых структур X.509. Мне это достаточно. Если хотите доказать, что я не прав, то пруфы нужны уже от Вас. Это три :)
В принципе, я тоже уверен в правоте, значит еще один случай когда не читая зарубежного формата, не делая попыток прояснить его относительно гост, отечественная нормативка ссылается на rfc.

Отредактировано пользователем 1 сентября 2020 г. 14:02:16(UTC)  | Причина: Не указана

Offline KDA  
#31 Оставлено : 1 сентября 2020 г. 14:43:56(UTC)
KDA

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

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

Сказал(а) «Спасибо»: 4 раз
Поблагодарили: 4 раз в 4 постах
Автор: two_oceans Перейти к цитате
Нисколько не спорю, что в случае КриптоПро велосипед не изобретали и отдали проверку коду Майкрософт, который реализует функционал высокого уровня из базовых низкоуровневых функций. Это отнюдь не значит что высокоуровневые функции не могут быть переопределены криптопровайдером. В CryptoAPI очень много функций, которые можно перегрузить или, как с сожалением приходится признать, "пропатчить" (так как Майкрософт не дает возможность их поменять без патча и даже те самые исходники без патча не заводятся). Поэтому "левый" криптопровайдер может "заодно" пропатчить и код связанный с сертификатами. Что ему помешает?


Пропатчить код может любое ПО с достаточными правами. Но код CSP здесь абсолютно не при чем. Еще раз, смотрим список обязательных функций для экспорта CSP.
Вариативность работы, очевидно, в полном спектре объектов со стороны штатного API Crypt(Encode/Decode)ObjectXXX.
Что касается штатного API поиска сертификата в хранилище по идентификатору (CryptFindCertificateInStore) - там нет ограничений (в отличии от серийного номера) на длину поля. Отладчик/дизассемблер в помощь. Намного лучше, чем абстрактные размышления на тему "как это могло бы быть".


Вообще, меня несколько удивила такая бурная дискуссия на замечание, что идентификатор ключа в уже сделанных кем-то сертификатах надо брать как есть и целиком, а не делать предположений, что там обязательно какой-то хеш или 20 байт.
Пошли аргументы про "левое" и правильное ПО. Чтож, вот то, что сделано с помощью исключительно правильного ПО КриптоПро:
var_keyid_certs.zip (3kb) загружен 4 раз(а).

В аттаче три сертфиката на ОДИН ключ с кастомным содержимым поля subject key identifier длиной 4, 20 и 21 байт.
Наглядная демонстрация, что надо не на ПО надеяться, а голову включать.

И, пожалуйста, не надо больше "все равно это нечестно или нетипично". Софт должен быть расчитан на то, что он работает с частично недоверенными данными. Иначе зачем постоянно подписи на сертификатах проверять и цепочки строить?

Отредактировано пользователем 1 сентября 2020 г. 14:47:24(UTC)  | Причина: Не указана

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