Очистка подписи от сертификатов- Page 5

Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Error

5 Страницы«<3 45

Очистка подписи от сертификатов

Опции

Предыдущая тема Следующая тема

basid		#41 Оставлено : 30 декабря 2021 г. 10:52:02(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 21.11.2010(UTC) Сообщений: 1,098 Сказал(а) «Спасибо»: 7 раз Поблагодарили: 151 раз в 136 постах		Не надо придумывать никаких сценариев. Если ЭП имеет доверенную метку времени и если все необходимые сертификаты были на этот момент действительны, то и сама подпись - тоже действительна. Этот факт не может отменить даже достоверное знание о том, что конкретную ЭП сформировал злоумышленник. Просто потому, что отзыв сертификатов задним числом - тоже мошенничество. P.S. Если вы доверяете списку отзыва, то обязаны доверять и отметкам времени, которые в нём указаны. spisok otzyva.png (8kb) загружен 3 раз(а).


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Андрей *		#42 Оставлено : 30 декабря 2021 г. 11:28:48(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз Поблагодарили: 2212 раз в 1727 постах		Автор: basid Не надо придумывать никаких сценариев. Если ЭП имеет доверенную метку времени и если все необходимые сертификаты были на этот момент действительны, то и сама подпись - тоже действительна. Этот факт не может отменить даже достоверное знание о том, что конкретную ЭП сформировал злоумышленник. Просто потому, что отзыв сертификатов задним числом - тоже мошенничество. P.S. Если вы доверяете списку отзыва, то обязаны доверять и отметкам времени, которые в нём указаны. spisok otzyva.png (8kb) загружен 3 раз(а). Пример... Крупный УЦ выпускает CRL раз в 12ч (и там бывает отозвано и 1К сертификатов за это время) и по OCSP службе "всё ровно", потому что она по предыдущему CRL работает... (вчера пример разбирал: в 11ч отозвали, до 17ч "кто-то (кому доверил или сам владелец) подписывал документы", CRL вышел в 21ч - сертификат отозван... (среди прочих 9К сертификатов) Snimok ehkrana ot 2021-12-30 12-27-06.png (33kb) загружен 2 раз(а). Что делать (не подписанту, а тому, кому потом нужно будет доказывать\требовать ответа по подписанным файлам)? Документы подписывались уже отозванным сертификатом и получатель еще об этом не знает (получил\проверил\может подписал\деньги перевёл?). Будет аннулирование документов\контракта или всё нормально? Получатель, выявив этот факт затребовал аннулирование всего за 29.12.2021. Один УЦ в своем регламенте даже прописывал такое: дата и время отзыва сертификата = дата и время начала действия CRL, в который он попал, а не дата\время записи CRL... Нормально?
		Техническую поддержку оказываем тут Наша база знаний
		WWW

Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Андрей *		#43 Оставлено : 30 декабря 2021 г. 11:34:37(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз Поблагодарили: 2212 раз в 1727 постах		Автор: two_oceans Автор: basid Придумался еще сценарий для более явного акцента в чем проблема. Допустим, злоумышленники давным давно сделали самоподписанный сертификат и подписали им некий документ, без включения сертификата в подпись, но с меткой доверенного времени. Все замечательно, но сертификат неквалифицированный. Затем, допустим ключ УЦ украли и сделали на тот ключ и тот же DN из самоподписанного сертификата квази-квалифицированный конечный сертификат с началом на полгода назад, чтобы и подпись и метка попадали в срок действия. Сертификат УЦ отозван с даты кражи, но технически сделанный задним числом квази-квалифицированный конечный сертификат неотличим от настоящего. Ну кроме того, что сам УЦ и Минцифра о нем не знает. Собственно если злоумышленники рискнут, они могут и на портал Минцифры его загрузить. Получается, неквалифицированная подпись магически станет квалифицированной и даже заверенной подлинной меткой времени. Если мы не будем считать все сертификаты, выданные УЦ у которого отозвали сертификат, недействительными, то неизвестно какое число таких сертификатов появится. и подшаманили так, чтобы ещё и серийный номер первого сертификата был (смотрим описание CMS и возможности CAdES BES\T)?
		Техническую поддержку оказываем тут Наша база знаний
		WWW

Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

TolikTipaTut1		#44 Оставлено : 30 декабря 2021 г. 13:26:56(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 05.07.2018(UTC) Сообщений: 467 Сказал(а) «Спасибо»: 43 раз Поблагодарили: 69 раз в 61 постах		Автор: Андрей * Автор: two_oceans Придумался еще сценарий для более явного акцента в чем проблема. Допустим, злоумышленники давным давно сделали самоподписанный сертификат и подписали им некий документ, без включения сертификата в подпись, но с меткой доверенного времени. Все замечательно, но сертификат неквалифицированный. Затем, допустим ключ УЦ украли и сделали на тот ключ и тот же DN из самоподписанного сертификата квази-квалифицированный конечный сертификат с началом на полгода назад, чтобы и подпись и метка попадали в срок действия. Сертификат УЦ отозван с даты кражи, но технически сделанный задним числом квази-квалифицированный конечный сертификат неотличим от настоящего. Ну кроме того, что сам УЦ и Минцифра о нем не знает. Собственно если злоумышленники рискнут, они могут и на портал Минцифры его загрузить. Получается, неквалифицированная подпись магически станет квалифицированной и даже заверенной подлинной меткой времени. Если мы не будем считать все сертификаты, выданные УЦ у которого отозвали сертификат, недействительными, то неизвестно какое число таких сертификатов появится. и подшаманили так, чтобы ещё и серийный номер первого сертификата был (смотрим описание CMS и возможности CAdES BES\T)? Мне кажется, что эта схема не сработает: Вот злоумышленники выпустили самоподписанный сертификат и создали сообщение формата CAdES-T. По-хорошему, в CAdES-T должен быть подписанный атрибут ESS-Signing-Certificate-V2. Если его нет, то проверка ЭП может и не завершиться успехом (например, проверка на dss.cryptopro.ru дает сбой, если атрибута ESS-Signing-Certificate-V2 нет в подписи). Если я правильно прочел и понял спецификацию, то этот атрибут содержит хэш-код сертификата подписанта, а также может содержать CN и серийник УЦ, выдавшего этот сертификат). Т.о., если они затем украдут ключ у УЦ, выпустят свой end-entity сертификат и включат его в подпись вместо самоподписанного, то проверка ЭП завершится неудачей, так как хэш-код сертификата, подписанного с использованием выкраденного ключа УЦ, будет отличаться от изначального. Рассмотрим другой вариант: злоумышленники изначально выпустили самоподписанный сертификат в точь точь такой же, как и сертификат УЦ, у которого они планировали "украсть" ключ (если сравнить 2 сертификата, отличаться будут только открытый ключ и хэш-код). Затем они (злоумышленники) выпустили end-entity сертификат c использованием этого самоподписанного сертификата. Создали подпись формата CAdES-T с использованием end-entity сертификата (всю цепочку они не включали в ЭП). После этого они украли ключ и сертификат УЦ, и перевыпустили себе end-entity сертификат (сохранили серийник и все остальное). Однако и в этом случае проверка завершится неудачей, так как в новом end-entity сертификате будет другая ЭП, а, следовательно, и хэш-код будет другим. Поэтому, как мне кажется, и эта схема работать тоже не будет. Если я в чем-то ошибся - поправьте пожалуйста ... Отредактировано пользователем 30 декабря 2021 г. 13:30:12(UTC) \| Причина: Не указана
		GithHub: https://github.com/anatolkavassermann/


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

basid		#45 Оставлено : 30 декабря 2021 г. 17:40:53(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 21.11.2010(UTC) Сообщений: 1,098 Сказал(а) «Спасибо»: 7 раз Поблагодарили: 151 раз в 136 постах		Автор: Андрей * Крупный УЦ выпускает CRL раз в 12ч (и там бывает отозвано и 1К сертификатов за это время) и по OCSP службе "всё ровно", потому что она по предыдущему CRL работает... Код: `2.4. Semantics of thisUpdate, nextUpdate, and producedAt Responses defined in this document can contain four times -- thisUpdate, nextUpdate, producedAt, and revocationTime. The semantics of these fields are: thisUpdate The most recent time at which the status being indicated is known by the responder to have been correct.` Цитата: (вчера пример разбирал: в 11ч отозвали, до 17ч "кто-то (кому доверил или сам владелец) подписывал документы" Тут существенно кто был инициатором отзыва и знал ли владелец (подписант) о грядущем отзыве. Это существенно повлияет на: Цитата: Что делать (не подписанту, а тому, кому потом нужно будет доказывать\требовать ответа по подписанным файлам)? Документы подписывались уже отозванным сертификатом и получатель еще об этом не знает (получил\проверил\может подписал\деньги перевёл?). Будет аннулирование документов\контракта или всё нормально? Получатель, выявив этот факт затребовал аннулирование всего за 29.12.2021. ... потому, что влияет на позицию (силу позиции) проверяющего. Особо отмечу, что опять всё упирается в доверие к отметке времени подписания. Краткое резюме. Если мы доверяем отметке времени подписания и на этот момент сертификат был отозван, то ЭП - недействительна. Вне зависимости от технической возможности обнаружить этот факт сразу же. Отредактировано пользователем 30 декабря 2021 г. 17:41:55(UTC) \| Причина: исправил опечатку


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Андрей *		#46 Оставлено : 30 декабря 2021 г. 18:11:33(UTC)
Статус: Сотрудник Группы: Участники Зарегистрирован: 26.07.2011(UTC) Сообщений: 13,340 Сказал «Спасибо»: 550 раз Поблагодарили: 2212 раз в 1727 постах		Автор: basid Тут существенно кто был инициатором отзыва и знал ли владелец (подписант) о грядущем отзыве. Это существенно повлияет на: Цитата: Что делать (не подписанту, а тому, кому потом нужно будет доказывать\требовать ответа по подписанным файлам)? Документы подписывались уже отозванным сертификатом и получатель еще об этом не знает (получил\проверил\может подписал\деньги перевёл?). Будет аннулирование документов\контракта или всё нормально? Получатель, выявив этот факт затребовал аннулирование всего за 29.12.2021. ... потому, что влияет на позицию (силу позиции) проверяющего. Особо отмечу, что опять всё упирается в доверие к отметке времени подписания. Краткое резюме. Если мы доверяем отметке времени подписания и на этот момент сертификат был отозван, то ЭП - недействительна. Вне зависимости от технической возможности обнаружить этот факт сразу же. Причина: замена сертификата (хорошо, что не компрометация), видимо получают, чтобы не было "проблем в 2022", предыдущие сертификаты, которые попадались были до апреля-августа 2022.
		Техническую поддержку оказываем тут Наша база знаний
		WWW

Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

basid		#47 Оставлено : 30 декабря 2021 г. 18:38:39(UTC)
Статус: Активный участник Группы: Участники Зарегистрирован: 21.11.2010(UTC) Сообщений: 1,098 Сказал(а) «Спасибо»: 7 раз Поблагодарили: 151 раз в 136 постах		Несколько уточню свою позицию. "Технически-упрощённо" электронная подпись выглядит так. Есть общеизвестный алгоритм вычисления (криптостойкого) хэша и (тоже) общеизвестный алгоритм асимметричного шифрования. Отправитель вычисляет хэш документа, генерирует (псевдо)случайную имитовставку и эфемерную ключевую пару. Хэш плюс имитовставка шифруются на связке "открытый ключ эфемерной пары - собственный закрытый ключ" и уничтожается эфемерный открытый ключ. Проверяющему передаётся документ или некая ссылка на него, "шифровка", эфемерный закрытый ключ и открытый ключ подписанта. Проверяющий имеет возможность самостоятельно вычислить хэш документа, произвести расшифровку, сравнить вычисленный и присланный хэши и сделать вывод о неизменности документа после подписания. Но столь примитивная схема не отвечает на многие другие вопросы: кому принадлежит открытый ключ, не был ли скомпрометирован закрытый ключ отправителя, имел ли отправитель право на подпись и т.д. и т.п. Поэтому существуют гораздо более "навороченные" инфраструктура открытых ключей и форматов ЭП. Статус ЭП складывается из статуса собственно ЭП (удостоверяет неизменность документа) и статуса сертификата подписанта (действует, приостановлен, отозван и неизвестен). По моему скромному мнению, проблемы и заморочки начинаются тогда, когда игнорируется тот факт, что статус сертификата подписанта может быть неизвестен. В частности, если в нашем распоряжении есть CRL/OCSP-ответ в которых нет проверяемого сертификата и thisUpdate раньше времени валидируемой подписи, то статус проверки должен быть "Неизвестно", а значит и "вынесение вердикта" должно откладываться "до лучших времён". Отредактировано пользователем 30 декабря 2021 г. 18:41:22(UTC) \| Причина: ачипятки


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

RSS Лента

Atom Лента

Пользователи, просматривающие эту тему
Guest

5 Страницы«<3 45

Быстрый переход

Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.

Important Information: The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More Details Close