| ||||
| ||||
| Я тут прочитал ветку форума http://www.cryptopro.ru/cryptopro/forum/view.asp?q=5046. Заинтересовали следующие моменты: 1. "Проверка УЭЦП возможна только до окончания действия сертификата TSP" 2. "УЭЦП можно проверить в случае, если истекли сертификаты: 1) самого подписавшего, 2) ЦС, выдавшего сертификат подписавшего 3) OCSP-службы 4) ЦС, выдавшего сертификат OCSP Но, УЭЦП нельзя проверить, если истёк срок действия сертификата TSP-службы" То есть получается, что сертификат оператору TSP надо выдавать примерно на такой же срок, как и сертификат уполномоченного лица УЦ. Иначе допустим, пол года назад я подписал документ, а сейчас хочу его проверить. За эти пол года сменился сертификат оператора TSP (срок действия старого уже закончился). В итоге результат проверки подписи - отрицательный!!! | ||||
| Ответы: | ||||
| ||||
| Да, сертификат службы штампов времени (TSP) должен быть "длинным" по сроку действия. Обычно используют так: ключи уполномоченного лица УЦ и ключи служб TSP и OCSP формируют на специальный программно-аппаратный криптографический модуль "Атликс-HSM" (http://www.cryptopro.ru/cryptopro/products/atlix-hsm/default.htm). Тогда срок действия сертификата(включая TSP) может достигать 30 лет. | ||||
| ||||
| Кстати, Юрий, я тоже довольно долго размышлял на эту тему и в части архивного хранения тоже. Получается, что видимо всеже придется поперек 3280 вводить "продолжительность закрытого ключа", поскольку ПО не умеет читать всякие там ЖТЯ и ему явно надо указывать что открытый ключ, а значит и все остальное вот такой продолжительности. Как считаешь? | ||||
| ||||
| Да, Сергей, ты прав и ПАК "КриптоПро УЦ" версии 2.0 будет делать сертификаты со сроком действия закрытого ключа. Действительно, ссылки на ЖТЯИ - это не серьезно. Оргмер мало. Нужно технически. Некоторые организации (НП АТС, например) в своем прикладном ПО проверяют срок действия закрытых ключей, используя срок начала действия сертификата+срок действия ключей подписи, получаемых через SOAP-интерфейс ЦР "КриптоПро УЦ". Нужно думать как заставлять прикладное ПО без "переделки" работать с таким расширением сертификата. Типа, как с поошью RP "научили" определять статус сертификата по OCSP-протоколу | ||||
| ||||
| Наверное, самое простое, подправить на уровне CSP или чего аналогичного процедуру выработки ЭЦП, чтобы не вываливаться за срок действия закрытого ключа, а при проверке ЭЦП проверять еще дату создания ЭЦП, чтобы также не вываливаться за срок закрытого ключа. Более прикладное ПО ни где править то и не надо. И еще в конфиге УЦ (или на АП у кого как реализовано)предусмотреть ввод константы - продолжительности закрытого ключа из формуляра на установленное СКЗИ (то самое ЖТЯ, ТКЛЮ у кого что есть). Как то так должно быть. | ||||
| ||||
| 1. Самое простое - не всегда самое верное :-) Цель КРИПТО-ПРО - не делать местечковые интерфейсы, а стараться использовать стандартные. Так вот интерфейс CSP такого не позволяет, ибо CSP знать не знает, что такое сертификат. Если не веришь - посмотри документацию от Microsoft. Поэтому CSP не сможет обработать расширение того, что он не получал. Информурую, что в Microsoft Windows, работа с сертификатами лежит на уровне CryptoAPI. А вот его мы трогать не будем и не можем, ибо это нарушение прав корпорации Microsoft. Так, что как я и говорил, надо думать и активно думать... 2. В ПАК "КриптоПро УЦ" еще начиная с самой первой версии, есть константа, определяющая срок действия закрытого ключа и ПАК работает с ним. Оповещает об окончании срока действия закрытого ключа все и вся. Также дает возможность программистам узнать об этом через программный интерфейс. Механизм у нас есть, реализован. Но нужно сделать теперь стандартно, не трогая ПО третьих лиц... | ||||
| ||||
| Коллеги, занятный спор выходит! А существует ли возможность проверять не истек ли срок действия сертификата TSP, да и всех остальных, не на текущий момент времени, а на момент, указанный в штампе времени (в TSP ответе)? | ||||
| ||||
| TO Николай Пушкин: Этого никто не делат (хотя технически можно) т.к. не логично. Если у Вас нет доверия к сертификату TSP (у сертификата истек срок действия), который подписал штамп времени, значит нет доверия и подписанным данным, а именно к времени, указанному в штампе времени. Почему и сделали срок действия сертификата службы штампов времени TSP "крайним" :-) | ||||
| ||||
| Позволю себе не согласиться! Проверять статус сертификата оператора TSP на мой взгляд необходимо на момент, указанный в штампе времени. Соответственно, если на момент штампа времени сертификату оператора TSP было доверие, то и подпись верна (при прочих удачных проверках, есессно). Как Вы на это смотрите? | ||||
| ||||
| Отрицательно смотрю. Повторяю, что у Вас нет доверия к достоверности времени указанного в штампе. Что доверие ПОЯВИЛОСЬ, Вы должны проверить подлинность ЭЦП в штампе. Процедура проверки подлинности ЭЦП включает установление статуса сертификата TSP на момент (времени) ПРОВЕРКИ ЭЦП в штампе. Ибо у Вас есть доверие к времени ПРОВЕРКИ ЭЦП. Попытаюсь объяснить на пальцах... Срок действия сертификата открытого ключа всегда конечный и максимум этого срока определяется ФСБ исходя из разных параметров, которые, в том числе, учитавают и вероятность неявной компрометации закрытого ключа. Т.о. после окончания срока действия сертификат, считается достаточно вероятным событие, что у постороннего лица появится копия закрытого ключа или информация о закрытом ключе. Представьте, что это постореннее лицо является злоумышленником, типа великого комбинатора Остапа Бендере, например. И он придумал схему мошенических действий, в которых используется штам времени. Т.о. он сможет сформировать штамп времени, содержащий время старое, например год назад, подписанное на ключе TSP, сертификат которого месяц назад окончил свое действие. И что, Вы хотите доверять иакому штампу?! Я нет и все прогрессивное человестве вместе с Вами тоже не захочет! :-) | ||||
| ||||
| В принципе понял... Тогда получается для того чтобы подпись была действительна, в любом случае требуется какой-либо ее компонент, действительный на момент проверки (необязательно сертификат TSP). Соответственно проверить подпись лет через 100 после подписания невозможно будет (если об УЦ выдавшем СПК уже и не помнят). Нда, с архивным хранением слжно получается. | ||||
| ||||
| Вы правильно поняли, при верке, хоть один компонент должен быть доверенным :-) Да, с архивным хранением электронных документов всегда сложно :-( | ||||
| ||||
| Юрий Геннадьевич, если предполагать вариант компрометации TSP Остапом, следует учитывать и тот факт, что в это же время может быть скомпрометирован и ЦС и OCSP, тк при генерации ключей используется один и тот же матаппарат и длина ключей (возможно я ошибаюсь, поправьте плз), да и хранятся ключевые носители примерно одинаково, а сроки действия сертификатов выбираются исходя из орг мер по их защите от компрометации. За то же время Остап сможет 10 раз скопировать дискету с ключами пользователя, подсмотреть у него пин-код на токене, думаю вероятность наступления этого события в разы больше, чем в случае с TSP (опять же насколько я помню, срок действия сертификата подписавшего не проверяется)? И еще, что интереснее, исправить архивный документ 3-х летней давности или отправить платежку сегодня например, т.е. каким ключом интереснее завладеть Остапу: подбором -- ЦС или тихо увести у пользователя. Вопрос с моей точки зрения сводится: кто, что, как и кому будет доказывать при возникновении конфликта интересов. А там уже комиссия логи УЦ пускай поднимает и выдает экспертное заключение, что такого штампа времени не выдавалось. Как я понимаю из дискуссии, самый актуальный вариант -- делать срок действия сертификата TSP равному сроку действия сертификата ЦС = 60 лет, внедрять повсеместно и складывать все в Атликс и не забивать голову, тк через 60 лет где нас будут искать :). Может быть несколько путано, однако очень хочется понять позицию компании КРИПТО-ПРО, и решить, как делать правильно. Возможно Сергей Михайлович как-нибудь прокомментирует, было бы тоже интересно. | ||||
| ||||
| PS практически все действуют по принципу добросовестности и разумности. Мало у кого возникают проблемы напр. при оплате копии счета, переданной по факсу. А ответственность вроде бы лежит на том, кто ключ подобрал и совершил неправомерные действия, а не на УЦ и тем более не на том, кого обманули. А мы своими силами можем только усложнить задачу мошенникам. Больше то собственно ничего сделать и не сможем, да и в принципе не требуется. | ||||
| ||||
| Николай, учтите, что срок действия любого сертификата, выдаваемого Центром Сертификации НЕ может превышать срок действия сертификата самого ЦС. Таким образом, на момент проверки как минимум два сертификата должны быть действительны: 1) сертификат TSP 2) сертификат ЦС, выдавшего сертификат TSP | ||||
| ||||
| TO Николай Пушкин: 1. Поправка Василия правильная. Нужно учитывать и сертификат ЦС. 2. Складывая ключи в Атликс мы получаем срок действия сертификата (любого!) 30 лет, а не 60 лет. Тут Вы опечатались 3. Срок действия сертификата TSP не может быть равным сроку действия сертификата ЦС. TSP всегда строго меньше чем ЦС, т.к. сертификат ЦС "появляется" раньше чем сертификат TSP. 4. На УЦ лежит ответственность за достоверность сведений указанных в сертификате и, следовательно, за весь реальный ущерб+упущенная выгода, который владелец сертификата подписи понес за ненадлежащее выполнение УЦ своей обязанности. Больше ни за что он не отвечает! Если УЦ, как лицо, по своей глупости, в договоре с пользователем не взвалил на себя ответственность еще за что-то, что он не может контролировать :-) ПРименение ЭЦП в информационной системе УЦ точно не может контролировать. 4. Порядок применения ЭЦП (включая применение сертификатов) определяется соглашением участников системы. Поэтому, что касается штампов времени, то тут не зона ответственности УЦ, а зона Оператора системы (в терминах ФЗ "Об инфомации, информационных технологиях и защите информации". 5. А ответственность будет лежать на том, чью вину докажут (по умыслу или по неосторожности). УЦ или Оператор системы или участник системы или посторонее лицо. Судебная практика показывает, что чаще суд вину перекладывает на Оператора системы, если он является субъектом, организовавшем систему с возможностью соверешения мощенических действий в этой системе. Это будет вина по неосторожности (чаще всего). Суд и органы дознания считают, что участникам системы Оператор навязал условия, имеющие "дыры". Значит, участники в той или иной мере освобождаются от ответственности, если не будет доказан их умысел при совершении противоправных действий. А это сложно доказать :-) | ||||
| ||||
| Коллеги, 60 лет и равные сроки для TSP и CA были указаны условно, я имел ввиду, что срок действия сертфиката TSP должен заканчиваться раньше сертификата ЦС, про 60 лет да, в одном из предыдущих постов было именно 30 лет, и даже через 30 лет где нас искать :) Итак, правильно ли я делаю вывод (мне видятся два варианта, имеющие право на существование): Вариант 1: Делать срок действия сертификата TSP равным максимальному сроку хранения документа, заверенного усовершенствованной ЭЦП + например 1 год и каждый год делать плановую смену сертификата или ключей TSP, а за время, равное сроку хранения заверенного документа так же делать и плановую смену сертификата или ключей ЦС. Вариант 2: Делать равными окончания действия сертификатов ЦС и TSP и планово менять оба за время, равное максимальному сроку хранения заверенного документа? Более предпочтительным мне видится второй вариант, тк. он предусматривает меньше действий. | ||||
| ||||
| Делаем начальные установки: Тцс1 - срок действия ключа подписи (закрытого ключа) ЦС Тцс2 - срок действия сертификата ключа подписи (открытого ключа) ЦС Тцс3 - период плановой смены ключа подписи и сертификата ключа подписи ЦС Тtsp1 - срок действия ключа подписи (закрытого ключа) службы TSP Тtsp2 - срок действия сертификата ключа подписи (открытого ключа) службы TSP Тtsp3 - период плановой смены ключа подписи и сертификата ключа подписи службы TSP Tэд1 - максимальный срок хранения электронного документа, удостоверенного ЭЦП усовершенствованного формата Между этит временами устанавливается следующая зависимость: Тцс1 <= 1 год 3 месяца (если по КС2, без HSM) Тцс1 <= 7 лет (если по КB2, с HSM) Тцс2 <= 6 лет (если по КС2, без HSM) Тцс2 <= 30 лет (если по КB2, с HSM) Тцс3 < (Тцс1 - Ttsp1) < Тцс2 (иначе не начем будет подписать СRL, в случае аннулирования сертификата TSP) Тtsp3 <= Тtsp1 < Тtsp2 Тtsp3 <= Тtsp1 < Тtsp2 Tэд1 < Тtsp2 < Тцс2 Вот исходя из этих начальных условий, предложенный Вами второй вариант не подходит. | ||||
| ||||
| Уважаемые господа, извините что вмешиваюсь. Хочу заметить следующее: 1. Ttsp2 – (максимальное) не зависит от желания приравнять его к Тэд1, а зависит от того что написано в формуляре на применяемое СКЗИ. 2. Интуитивно понятно, что ключи для ЦС и TSP надо делать максимально продолжительными и почти одинаковыми, поскольку назначение ключей родственное – оба выступают в роли обслуживающих сервисов, один для заверения сертификатов , другой для заверения штампов. Соответственно и режимы их эксплуатации должны быть схожи. 3. Перед завершением Ttsp2 (которое меньше чем Тцс2, как совершенно правильно замечено) следует пролонгировать штамп, подкладывая всю требуемую информацию для выполнения проверки «на борту» после истечения Тцс2. | ||||
| ||||
| Все таки я хочу осмелиться сказать, что нужно максимизировать сроки действия сертификатов открытых ключей ЦС и TSP. Все таки только они влияют на Тэд1 ибо они используются при проверке ЭЦП. А сроки действия закрытых ключей ЦС и TSP, равно как и периодичность их плановой смены - это не существенно. Хоть каждый год меняйте! Равно как и вместе их менять или по отдельности, не суть важно! :-) | ||||
| ||||
| Тэд1 в данной схеме (если не использовать механизмы пролонгации или переподписания) – есть период между моментом выработки штампа и временем протухания подписателя штампов (Ttsp2), и этот промежуток надо подтягивать к периоду установленному регламентом, законом или иными нормативными документами для хранения документов данного назначения. | ||||
Иван