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

Уведомление

Icon
Error

5 Страницы<1234>»
Опции
К последнему сообщению К первому непрочитанному
Offline TolikTipaTut1  
#11 Оставлено : 24 декабря 2021 г. 22:29:51(UTC)
TolikTipaTut1

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

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

Сказал(а) «Спасибо»: 43 раз
Поблагодарили: 69 раз в 61 постах
Автор: Alexander Kumanyaev Перейти к цитате
Подскажите, возможно ли у отделенной подписи Cades Bes удалять подписанта перед сохранением подписи и добавлять его обратно после ее чтения, а сам сертификат подписанта хранить отдельно?
Требуется хранить подпись максимально сжато, т.к. файлов очень много, а подписывают их одни и те же люди.


Правильно ли я понял: вы хотите, после создания ЭП (например, формата CAdES-BES), ее разобрать на составные части, а потом, при "чтении", заново ее собрать. Вы эту ЭП будете передавать другим лицам, вне вашей организации? Потому что стандартных средств "разборки" и "сборки" CAdES-BES лично я не знаю.

Исходя из ваших требований можно (мы не говорим о том, правильно ли это с точки зрения безопасности, и вообще удобно ли это) вот как сделать (для CAdES-BES): передавать контрагентам подписываемый документ, ЭП (256 бит) и метку локального времени:
1. ContentType скорее всего будет 1.2.840.113549.1.7.1;
2. ESS-Signing-Certificate-v2 можно "собрать" самостоятельно, обладая нужными сертификатами, а как я понял, ваши контрагенты обладают ими;
3. MessageDigest можно вычислить самостоятельно.
Если вычисленные вашими контрагентами значения этих атрибутов будут отличаться от ваших - ЭП не проверится.
Код:
{ContentType; ESS-Signing-Certificate-v2; MessageDigest; SigningTime} #набор для CAdES-BES.


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

Однако для такого рода "сборки" вам нужно самостоятельно разработать и протестировать инструмент, а также убедить всех ваших контрагентов доверять этому инструменту и обучить пользоваться им. Более того, важен порядок сборки атрибутов: если вы их подписали в порядке:
Код:
{ContentType; ESS-Signing-Certificate-v2; MessageDigest; SigningTime}
а ваш контрагент собрал CAdES-BES в другом, например:
Код:
{ContentType; ESS-Signing-Certificate-v2; SigningTime; MessageDigest}
ЭП не проверится. Также вам придется разработать какой-то проприетарный формат для упаковки и передачи указанных выше сведений контрагенту.

Что делать с остальными форматами ЭП - ума не приложу... Должно быть какое-то централизованное хранилище CRL какое-то всех УЦ, однако в случае с TSP или OCSP ответами ничего выкинуть не получится...

P.S. Пожалуйста, не пинайте меня сильно...) Я понимаю, что это не совсем правильно, но исходя из требований - это самый "сжатый" вариант... Но мне кажется, что затраты, которые возникнут в ходе реализации этого варианта, будут несопоставимы с профитом.

P.P.S. Или, возможно, вы сможете так хранить у себя эти ЭП, а при передаче ЭП внешним контрагентам: собирайте CAdES-BES обратно и передавайте нормальное сообщение

Отредактировано пользователем 25 декабря 2021 г. 9:03:47(UTC)  | Причина: Не указана

Offline two_oceans  
#12 Оставлено : 27 декабря 2021 г. 8:23:12(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: TolikTipaTut1 Перейти к цитате
Автор: Alexander Kumanyaev Перейти к цитате
Подскажите, возможно ли у отделенной подписи Cades Bes удалять подписанта перед сохранением подписи и добавлять его обратно после ее чтения, а сам сертификат подписанта хранить отдельно?
Требуется хранить подпись максимально сжато, т.к. файлов очень много, а подписывают их одни и те же люди.
Правильно ли я понял: вы хотите, после создания ЭП (например, формата CAdES-BES), ее разобрать на составные части, а потом, при "чтении", заново ее собрать. Вы эту ЭП будете передавать другим лицам, вне вашей организации? Потому что стандартных средств "разборки" и "сборки" CAdES-BES лично я не знаю.

Меня там слегка перекоробило от того что топикстартер подписывает хэш - зачет конечно по знанию RAW подписи, вот только есть разница сколько раз хэш вычислять в cades, правда? Если подписываются атрибуты, то это значит что хэш документа не сам идет на вход CryptSignHash, а включается в какой-то вторичный блок вместе с остальными атрибутами и вот уже хэш этого блока идет на CryptSignHash. Догадайтесь что еще там будет в этом блоке... а не данные ли это о поиске сертификата подписавшего? Или где топикстартер нашел в cades-bes доказательства - их там нет! Доказательства и метки доверенного времени появляются как минимум в cades X long type и всех более сложных форматах. Об этом изящно намекнул Андрей, но кажется иронию не распознали.

Про пропиетарный формат это Вы конечно глобально замахнулись, но этого собственно не нужно. Поясню свою мысль, на основе которой я отвечал топикстартеру. Что имел ввиду он - пусть сам отвечает, я расскажу свое видение. Смысл в том, что внутри своей ИС подпись можно хранить разобранной, а вот когда понадобиться ее передать контрагенту или проверить, то выполняется сборка частей и из ИС выдается полная подпись. Контрагенту просто нет нужды ставить какие-то несертифицированные программки - он имеет дело с собранной подписью общепринятого формата.
Автор: TolikTipaTut1 Перейти к цитате
P.S. Пожалуйста, не пинайте меня сильно...) Я понимаю, что это не совсем правильно, но исходя из требований - это самый "сжатый" вариант... Но мне кажется, что затраты, которые возникнут в ходе реализации этого варианта, будут несопоставимы с профитом.

P.P.S. Или, возможно, вы сможете так хранить у себя эти ЭП, а при передаче ЭП внешним контрагентам: собирайте CAdES-BES обратно и передавайте нормальное сообщение
Да - да. Только вот CAdES-BES разбирать несколько неперспективно (максимум сертификат не включать), формат должен быть посложнее.

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

НЕподписанные атрибуты, как правило, это что уже имеет подпись из других источников - списки отзыва сертификатов подписаны ключом УЦ, метки доверенного времени - ключом сервера TSP, ответы OCSP - ключом ответчика. Представьте, Вы "штампуете" одной ключевой парой подписи формата cades X long type. 100 документов за сутки, с доказательствами, которые по сути одни и те же, отличие только в моменте времени (ну хэш от этого меняется, но это несущественно).

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

Итак, у нас появился у всех 100 подписей за день одинаковый блок доказательств (плюс метка доверенного времени на доказательства). Тогда почему бы его не хранить отдельно и сэкономить место на 99 таких блоков. Формально конечно этого же можно добиться просто заархивировав файлы подписи (если они не шифруются после подписания). Без манипуляций архивированный размер будет чуть больше, так как время отличается.

Идеи дальше, допустим мы не уверены в сервере TSP и получаем метку от двух серверов. Тогда мы можем доказательства сервера 1 подтвердить меткой сервера 2, и наоборот. Тогда если один из серверов (пусть 2) скомпрометирует ключ и его сертификат будет отозван, мы сможем доказать что метка была сделана до отзыва по метке от сервера 1. Чтобы не остаться с одним сервером, мы вводим сервер 3 вместо сервера 2 и продолжаем взаимные подтверждения. Понятно, что такая "косичка" из доказательств займет очень много времени если ее продолжать несколько лет и ее уже проще хранить отдельно. Ну просто представьте обновлять в каждой подписи сделанной за 10 лет... хотя бы раз в год и 3 месяца на которые выдают сертификаты... думаю есть занятия поинтереснее. Не проще ли обновлять каждый день но только 2-3 доказательства.
(пошел на обед... продолжение возможно следует)

Отредактировано пользователем 27 декабря 2021 г. 8:29:19(UTC)  | Причина: Не указана

Offline TolikTipaTut1  
#13 Оставлено : 27 декабря 2021 г. 10:06:09(UTC)
TolikTipaTut1

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

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

Сказал(а) «Спасибо»: 43 раз
Поблагодарили: 69 раз в 61 постах
Автор: two_oceans Перейти к цитате
По поводу возможности разборки - в подписи cades есть подписанные атрибуты и неподписанные атрибуты. Как правило, подписанные подписаны тем, кто подписывает документ. Их разбирать нельзя - подпись математически нарушится.


Мне казалось, что для CAdES-BES можно разобрать блок с подписанными атрибутами. По идее, при наличии нужных сертификатов и использовании одних и тех же методов что до разборки, что после нее, ESS-Signing-Certificate-V2 будет одним и тем же. Как мне кажется, это касается и ContentType, и MessageDigest, и SigningTime. Однако, если данные были изменены (например, документ изменился), то подпись просто не соберется (нет, фактически, если просто в какой-то ASN.1 парсер вставлять эти блоки, то все соберется), но данная подпись не пройдет проверку в дальнейшем. Т.е. если данные не изменялись, то блок подписанных атрибутов для некоторых форматов ЭП можно разбирать.

Ну а вообще, я пошел учить мат. часть. Я пост Ваш прочел и понял, что мало знаю и еще меньше видел в этой жизни...

Offline Андрей *  
#14 Оставлено : 27 декабря 2021 г. 10:22:59(UTC)
Андрей *

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

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

Сказал «Спасибо»: 494 раз
Поблагодарили: 2035 раз в 1579 постах
two_oceans,
интересует Ваше мнение:

1) подписываем документ XLong1 (при этом до подписания и после с небольшими интервалами проверяем CRL\OCSP, сохраняем).
2) через 10ч после подписания выходит CRL, по которому сертификат уже был отозван до подписания, на момент в п.1)
3) при этом в этот же момент по OCSP статус сертификата - не отозван и успешно проверяется некоторое время
(воздушный зазор, перенос CRL к службе OCSP, например, 10-15 минут)

понятно, что проблема "с действиями в УЦ" (плановая публикация CRL, большой период действия (12ч)).

такой вопрос:
что сильнее OCSP из XLong1 или CRL (юридически\технически)?


p.s.
Случай реальный, все совпадения не случайны.

Техническую поддержку оказываем тут
Наша база знаний
Offline two_oceans  
#15 Оставлено : 27 декабря 2021 г. 11:18:26(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: TolikTipaTut1 Перейти к цитате
Автор: two_oceans Перейти к цитате
По поводу возможности разборки - в подписи cades есть подписанные атрибуты и неподписанные атрибуты. Как правило, подписанные подписаны тем, кто подписывает документ. Их разбирать нельзя - подпись математически нарушится.
Мне казалось, что для CAdES-BES можно разобрать блок с подписанными атрибутами.
Если очень аккуратно, то конечно и разберем и соберем... только тогда еще и нужен список атрибутов чтобы обратно собрать? Разбираем же не ради разбора, а ради какой-то выгоды. От вырезания массивных списков отзыва или хотя бы сертификата экономия может быть значительной, даже с учетом введения некой БД частей для сбора и того что сейчас сертификаты стали поменьше чем лет 5 назад. А от разрезания на простые ContentType MessageDigest SigningTime наверно эффект будет скорее обратный.
Автор: TolikTipaTut1 Перейти к цитате
Ну а вообще, я пошел учить мат. часть. Я пост Ваш прочел и понял, что мало знаю и еще меньше видел в этой жизни...
Я тоже оцениваю свои знания cades как "плохо знаю", про вот xades-bes я наверно смогу рассказать наизусть среди ночи. С учетом всех необязательных атрибутов и что форматы вложены матрешкой, в cades/xades вообще сложно ориентироваться.
Цитата:
1) подписываем документ XLong1 (при этом до подписания и после с небольшими интервалами проверяем CRL\OCSP, сохраняем).
2) через 10ч после подписания выходит CRL, по которому сертификат уже был отозван до подписания, на момент в п.1)
В норме, я думаю, такая ситуация не должна случиться. Новый CRL выпускается в момент отзыва, другой вопрос что он может быть не опубликован те самые 10-12 часов, когда УЦ изолирован от Интернета. Рассмотрим разные варианты ситуации: 1) мы владелец ключа и не отзывали сертификат - значит сертификат отозван по инициативе УЦ, то есть либо мы где-то нарушили правила обращения с ключами и есть риск компрометации ключей либо кто-то подал запрос на сертификат с таким открытым ключом. Тут все правильно - УЦ защищает безопасность владельца ключей, лучше объявить подпись недействительной с момента пораньше; 2) мы владелец ключа и отозвали сертификат - ситуация вызвана искусственно и в общем, я думаю тут будет правильнее также признать подпись недействительной. Если не ошибаюсь, то в нормативке есть что-то вроде обязательства владельца ключа не использовать ключ после отзыва сертификата; 3) мы не владелец ключа, а скажем "Держатель ключа" (такого в нормативке вроде бы нет), то есть владелец делегировал нам право подписи. Тут я думаю применим тоже пункт о запрете использования ключа после отзыва владельцем, так как с делегированными правами идут и обязанности; 4) мы не владелец, а "злоумышленник" - ну тут само собой подпись надо признать недействительной; 5) мы подали запрос на сертификат и он совпал с неким сертификатом - ну тут понятно, что без сертификата квалифицированной подписи не будет и мы делаем что-то не то. Есть еще какие-то варианты?
Цитата:
понятно, что проблема "с действиями в УЦ" (плановая публикация CRL, большой период действия (12ч)).
такой вопрос: что сильнее OCSP из XLong1 или CRL (юридически\технически)?
Учитывая, что попадались списки отзыва со сроком действия 3 месяца, 12 ч это просто молниеносно. Если что я не юрист. В итоге, во всех вариантах выходит, что чем раньше вступит в силу отзыв, тем безопаснее. Поэтому наверно CRL должен быть сильнее в такой постановке вопроса. Однако если по стандартам, то OCSP достаточно для признания подписи действительной, то есть при наличии OCSP CRL просто не проверяется, что приводит нас к проблемному пункту.
Цитата:
3) при этом в этот же момент по OCSP статус сертификата - не отозван и успешно проверяется некоторое время (воздушный зазор, перенос CRL к службе OCSP, например, 10-15 минут)
Как я понимаю, такая практика вообще не согласуется со стандартом. Понятно, что из-за немного своеобразных требований по полной изоляции УЦ от OCSP и Интернета. В том смысле, что OCSP по моему пониманию мысли стандарта должен получать данные очень быстро (в идеале читать прямо из БД УЦ) и отвечать о статусе в реальном времени, только отозвали еще не успел массивный CRL и дельта CRL записаться, а OCSP уже должен отвечать, что отозван. И исходя из этого стандарт отдает приоритет OCSP. В итоге, думается, что от совмещения несовместимого и случаются всякие проблемные ситуации.

К слову, вопрос: при обмене через CRL как OCSP узнает о вновь выпущенном сертификате?

Отредактировано пользователем 27 декабря 2021 г. 11:33:52(UTC)  | Причина: Не указана

Offline Андрей *  
#16 Оставлено : 27 декабря 2021 г. 11:35:32(UTC)
Андрей *

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

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

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

К слову, вопрос: при обмене через CRL как OCSP узнает о вновь выпущенном сертификате?


служба не видит сертификат в CRL (копия, принесенная админом с УЦ) = не в отозванных = выдает статус "действует", подписывает ответ...
Именно это и наблюдается в момент смены CRL каждые 12ч (в примере) - появляется информация, что было отозвано ххх сертификатов за прошедшие 12ч, но некоторое время по OCSP эти сертификаты ещё действующие.

Моё видение - УЦ должен как можно оперативнее выпускать CRL и предоставлять более актуальные статусы по OCSP (это же у некоторых - за доп.плату, включение URL OCSP в сертификат). Какой смысл от OCSP с задержкой в 12ч...

Некоторые УЦ выкладывают обновления CRL раз в час (хотя период действия сутки, например), уже лучше...


Техническую поддержку оказываем тут
Наша база знаний
Offline two_oceans  
#17 Оставлено : 27 декабря 2021 г. 12:53:45(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Конечно лучше, но.... как-то сомнительно, что клиент будет обновлять списки отзыва так часто даже если УЦ их опубликует (хоть раз в сутки обновят и то хорошо).

Выходит по вариантам выше, что владелец скорее всего знает об отзыве своего сертификата, а остальным не так уж критично, что ЭП за 12 часов (или тем более 15 минут) стали недействительны. Просто 12 часов это небольшой промежуток по сравнению со сроком действия сертификата год 3 месяца = 457 дней. Примерно 1/900, да еще не каждый сертификат вообще отзывают. Короче, чувствуется недооцененность проблемы из-за малой вероятности.
Автор: Андрей * Перейти к цитате
служба не видит сертификат в CRL (копия, принесенная админом с УЦ) = не в отозванных = выдает статус "действует", подписывает ответ...
То есть на все "взятые с потолка" и потому несуществующие тоже говорит "действует"? Это, мягко говоря, не производит впечатление правильной работы, особенно если вспомнить пункт "УЦ имеет право удалить сертификат из CRL после истечения срока действия этого сертификата". Срок действия и издатель хотя бы проверяются? Или там только номер в запросе?
Offline Alexander Kumanyaev  
#18 Оставлено : 27 декабря 2021 г. 13:31:34(UTC)
Alexander Kumanyaev

Статус: Участник

Группы: Участники
Зарегистрирован: 03.10.2019(UTC)
Сообщений: 28
Российская Федерация
Откуда: MSK

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

Зачем вам подписи хранить, начните с этого... Чтобы что? А после истечения срока действия сертификата подписанта?
О каком кол-ве идёт речь? Х млн файлов ЭП в год? Сжатие не рассматривали? // если всё таки продолжите расширять до усовершенстованной...


У меня требование функционального заказчика в части хранения подписей и документов на 5 лет. Срок истечения сертификата не особо важен (в смысле, что юридически будет сложно создать претензию после того как сертификат истек по периоду действия), т.к. подписываемый документ является важным пару суток с момента подписания, а далее он уже становится устаревшим. По количеству у нас сейчас 2,5 года прошло и мы имеем 46млн документов. По объему это не так много, около 450GB, но напрягает то, что в среднем одна подпись весит 8кб, а данные 2кб, т.е. 4/5 объема - это подписи. Всё это лежит в блобах в постгресе. Весь вопрос зародился из того, что время бэкапа подтгреса стало достаточно большим и эти данные один из самых "жирных" кусков в БД.

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

Отредактировано пользователем 27 декабря 2021 г. 13:54:31(UTC)  | Причина: Не указана

Offline Alexander Kumanyaev  
#19 Оставлено : 27 декабря 2021 г. 13:35:52(UTC)
Alexander Kumanyaev

Статус: Участник

Группы: Участники
Зарегистрирован: 03.10.2019(UTC)
Сообщений: 28
Российская Федерация
Откуда: MSK

Сказал(а) «Спасибо»: 2 раз
Автор: TolikTipaTut1 Перейти к цитате

Правильно ли я понял: вы хотите, после создания ЭП (например, формата CAdES-BES), ее разобрать на составные части, а потом, при "чтении", заново ее собрать. Вы эту ЭП будете передавать другим лицам, вне вашей организации? Потому что стандартных средств "разборки" и "сборки" CAdES-BES лично я не знаю.

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


Offline Alexander Kumanyaev  
#20 Оставлено : 27 декабря 2021 г. 13:46:43(UTC)
Alexander Kumanyaev

Статус: Участник

Группы: Участники
Зарегистрирован: 03.10.2019(UTC)
Сообщений: 28
Российская Федерация
Откуда: MSK

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

Меня там слегка перекоробило от того что топикстартер подписывает хэш - зачет конечно по знанию RAW подписи, вот только есть разница сколько раз хэш вычислять в cades, правда? Если подписываются атрибуты, то это значит что хэш документа не сам идет на вход CryptSignHash, а включается в какой-то вторичный блок вместе с остальными атрибутами и вот уже хэш этого блока идет на CryptSignHash. Догадайтесь что еще там будет в этом блоке... а не данные ли это о поиске сертификата подписавшего? Или где топикстартер нашел в cades-bes доказательства - их там нет! Доказательства и метки доверенного времени появляются как минимум в cades X long type и всех более сложных форматах. Об этом изящно намекнул Андрей, но кажется иронию не распознали.

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

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