Bankir.Ru
8 декабря, четверг 01:16

Объявление

Свернуть
Пока нет объявлений.

4 АУДЭД. Достоверность сведений сертификата.

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • 4 АУДЭД. Достоверность сведений сертификата.

    Проблема в следующем.

    Допустим в сертификате Петрова Н.Н. указано, что с 1.01.03 он является гл. бухгалтером ООО "Привет". Но 10 февраля его уволили. Кто и как должен в связи с этим анулировать данный сертификат? А если этот сертификат еще и личный для гражданина Петрова?

    Аналогично с паспортом. Девушка вышла замуж и сменила фамилию...

    P.S. Четверка в начале названия топика означает, что тема выносится на обсуждение не самой Ассоциацией, а для нее .

    P.P.S. О том, как стать участником АУДЭД и зачем это нужно см. "Ассоциация участников доверительного электронного документооборота" (http://dom.bankir.ru/showthread.php?s=&threadid=28266 )

  • #2
    sandyman -- это далеко не единственная проблема, которая должна решаться не технологическим, а организационно-административным путем. Что и есть главная задача Ассоциации.

    Комментарий


    • #3
      to alexve
      Не сомневаюсь .
      Тут как-то А.Волчков приводил ссылку на совершенно бредовый проект закона об электронном документе, где пытались регламентировать вопрос его доставки.
      Поэтому я и предлагаю, чтобы подходы Ассоциации к решению подобных проблем выносились на всебанкирское обсуждение. Иначе, не исключена возможность их отторжения .

      Комментарий


      • #4
        sandyman

        Допустим в сертификате Петрова Н.Н. указано, что с 1.01.03 он является гл. бухгалтером ООО "Привет". Но 10 февраля его уволили. Кто и как должен в связи с этим анулировать данный сертификат? А если этот сертификат еще и личный для гражданина Петрова?

        Замечательно. Если его уволили, то руководство ООО "Привет" должно направить в УЦ заявление об отзыве сертификата. Ситуация полностью аналогична карточке образцов подписей - меняется состав распорядителей счета, меняется карточка. У нас в банке все эти ситуации с отзывом/выдачей сертификатов сразу предусмотрены в процедуре.
        Что до "личного сертификата" - неправильно все мешать в одну кучу. Это как паспорт и служебное удостоверение. Паспорт привязан к личности, а удостоверение - к личности и должности. Увольняешься - надо сдать
        Хотя, проблема неудобства с кучей сертификатов имеет место быть, это бесспорно...

        См. также
        http://cybervlad.port5.com/ecp/index.html
        Earl Vlad Drakula. ///

        Комментарий


        • #5
          Уважаемые господа для привязки "сертификата гражданина" (выданного все равно кем и где) к системам разграничения доступа обычно используются так называемые Атрибутные сертификаты (короткоживущие сертификаты) RFC 3281 (если навскидку не путаю от прошлого года разработанную RSA и Балтимором).

          Комментарий


          • #6
            to Sergey_Murugov

            Думаю, здесь следует отталкиваться от практики. Допустим, в банк каким-то образом (например, по e-mail) попал договор. Разумеется, договор в XML-формате. Среди полей - номер договора, дата договора, место подписания, реквизиты сторон, должностные лица, полномочия лиц (устав или доверенность), даты подписей, content-type и т.д. Все это может понадобиться для последующей автоматической обработки договора.

            Договор подписан. Подпись может содержать либо идентификаторы УЦ и сертификата, либо же сам сертификат, подписанный УЦ. Интернет-банк в обоих случаях проверяет подпись, и показывает реквизиты (поля) сертификата. Например:
            - тип сертификата: юрлицо
            - фирма: ООО "Привет"
            - должность: зам. директора
            - полномочия: доверенность №__ от __
            - ФИО: Петров А.А.

            Доверенность может поступить вместе с договором. В случае, если сертификат поступил с договором, ИБ должен проверить на УЦ, нет ли данного сертификата среди аннулированных.

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

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

            to hugevlad

            Вы свой УЦ покупали или сами делали?

            Комментарий


            • #7
              Я несколько далек от Банковских технологий, зато неплохо ориентируюсь в PKI, о чем собственно и идет разговор. Что бы не было написано в договоре, если он подписан, а именно такой случай интересен, должен быть выполнен ряд процедур для принятия подписанного электронного документа абстрактной автоматизированной системой:
              1. должна быть проверена ЭЦП с точки зрения криптографии.
              2. должна быть проверена лигитимность с точки зрения политики применения сертификата – в частности имеет ли право Петров подписывать такого рода документы.
              Первая составляющая выполняется достаточно просто и неинтересно. А вот со второй составляющей – проблема. Банковская система должна знать о том что Петров имеет право подписания документов, поэтому его сертификат должен быть зарегистрирован в системе – это если говорить о полностью автоматической системе. Если рассматривать ситуацию, что пользователи могли получать сертификат где угодно (но в доверенном УЦ) (поскольку поддержка самой инфраструктуры ОЧЕНЬ хлопотная вещь и для малых банков экономически не оправдана) нужно привязать этот паспорт (сертификат) Петрова к его полномочиям – праву подписания такого рода документов – это целиком ответственность автоматизированной системы (банка) и не относится к валидности самого цифрового сертификата Петрова. А именно для таких целей и придуманы Атрибутные сертификаты.
              Если же планировать использовать несколько сертификатов (сертификат заверено связывает криптографическую пару с персоной – каждой паре соответствует свой сертификат - у вас мне кажется некоторая путаница в ключах и сертификатах) то банк должен сам вести PKI, что как я уже говорил – очень хлопотная вещь. Более того, в сертификат (который по ФЗ «Об ЭЦП» выдается только физлицам) очень проблематично ввести персональную - служебную информацию, поскольку вы обязаны публиковать сертификаты в Реестре, а значит, вы ее раскрываете всем. Для случая с атрибутными сертификатами, они дальше системы не уходят и туда можно написать все что угодно, даже то что подпадает под понятие персональной информации, которую по ФЗ «Об ИИИ» вы обязаны защищать.

              P.S. Отвечая на вопрос - Фирма делает УЦ начиная с 1997 года (кажется) в 98 была первая поставка, а сейчас в основном ориентируемся на УЦ очень больших и распределенных систем PKI.

              Комментарий


              • #8
                to Sergey_Murugov

                Если я Вас правильно понял, атрибутные сертификаты хранятся в некоем неполноценном банковском УЦ. И другим банкам эта информация недоступна. Но давайте не ограничиваться банками. Допустим, договор заключают две фирмы, которые, к тому же, обслуживаются в разных банках. И одна фирма посылает другой по e-mail подписанный договор...

                Sergey_Murugov: Если же планировать использовать несколько сертификатов (сертификат заверено связывает криптографическую пару с персоной – каждой паре соответствует свой сертификат - у вас мне кажется некоторая путаница в ключах и сертификатах) то банк должен сам вести PKI

                Не понимаю, откуда такой вывод. В моем примере совсем не обязательно банку иметь собственный УЦ. Банк должен лишь уметь общаться с любым УЦ, который обозначен в подписи договора, для получения сертификата или списка аннулированных сертификатов. Вопрос только в том, как УЦ должен взаимодействовать с должностными лицами фирмы при изменении ее руководства.
                И в чем путаница? Где в ФЗ «Об ЭЦП» запрет физическому лицу иметь несколько сертификатов, в том числе, содержащих один и тот же открытый ключ?

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

                Комментарий


                • #9
                  Ваша путаница происходит от непонимания принципов работы PKI:
                  1. Назначение сертификата – связь криптографической информации с информацией о персоне. Сертификат – это (в общем случае) 3 блока информации:
                  a. Информация о персоне – ФИО и так далее (в том числе, что допускает закон служебная информация, например, что Петров – бухгалтер, такого рода информация вносится в сертификат на основании распоряжения – приказа по организации, который должен быть представлен в УЦ в котором будет издаваться сертификат Петрова).
                  b. Открытый ключ (каждому открытому соответствует один единственный закрытый) Более того УЦ следит за тем, чтобы эти открытые ключи были уникальны Статья 9 пунк 1. (не бывает одинаковых открытых ключей – это в PKI коллизия). Поэтому не может быть ситуации, когда на один и тот же открытый ключ выдано несколько сертификатов!!!
                  c. ЭЦП УЦ, которая заверяет истинность первых двух блоков.
                  2. Как только изменяется (по любым причинам) информация в одном из блоков – сертификат либо автоматом считается недействительным (например, отозвали по компрометации или истекло время действия корневого сертификат УЦ) либо сертификат надо отзывать - изменилась информация из первого блока, например, Петров перестал быть бухгалтером, а эта информация присутствовала в сертификате.
                  3. Физлицо может иметь много сертификатов, но все они будут отличаться как минимум вторым блоком – открытым ключом.
                  Теперь по существу (см. Самое первое сообщение) если у Петрова сменилась должность, то его сертификат становится недействительным (изменился первый блок информации в сертификате) и его надо отзывать, эту процедуру должен выполнить УЦ (УЦ ведет CRL своего корня), которое выдало сертификат на основании приказа по организации (логика очень простая – приказ на занесение в сертификат Петрова служебной информации – приказ об изменении служебной информации в сертификате).
                  Для того чтобы не связываться с взаимоотношениями с УЦ (Петров формально мог получить сертификат на самого себя сам как просто на человека и в составе такого сертификата нет информации служебного характера) существует техническое решение о котором собственно я и написал. Т.е. должно быть что то, чтобы связывало Петрова и его лигитимность ставить подпись на договоре – это и есть Атрибутный сертификат. И не важно где размещен сервер AA, надо только обеспечить к нему доступ двух (или всех кому надо) сторон (АА обслуживает обе эти фирмы, в рамках банка – все фирмы которые под ним, в том случае если подписанные договора касаются банка).
                  Для вашего примера, где несколько банков и фирмы между собой ничем не связаны, кроме как включать в сертификат Петрова информацию о том что он имеет право подписывать договор – другого пути нет, а отсюда и издержки – начальник Петрова должен отслеживать валидность «служебного» сертификата Петрова.
                  Желаю удачи.

                  Комментарий


                  • #10
                    sandyman

                    Какой смысл здесь вводить специальный тип сертификата - атрибутный? Почему я не могу для своего одного и того же открытого ключа зарегистрировать на УЦ несколько разных сертификатов
                    Смысл такой: Вы подписали документ своим секретным ключом. Как получатель должен разруливать, при помощи которого из сертификатов открытого ключа ее проверять?
                    Если уж на то пошло, то УЦ проще перевыпускать сертификат, меняя состав Key Usage, если уж так не хочется перегенерировать ключи...

                    Вы свой УЦ покупали или сами делали?
                    Вопрос с двойным дном
                    Софт, в котором прооисходит изготовление сертификата, ведение реестра, выпуск CRL и т.п. - покупной. Но УЦ - это гораздо больше. Самое ценное - организационная процедура, т.е. как PKI функционирует, процедура рабора конфликтов и т.п. Это разрабатывали сами, очень долго и продуманно...
                    Earl Vlad Drakula. ///

                    Комментарий


                    • #11
                      Sergey_Murugov

                      P.S. Отвечая на вопрос - Фирма делает УЦ начиная с 1997 года (кажется) в 98 была первая поставка, а сейчас в основном ориентируемся на УЦ очень больших и распределенных систем PKI.

                      Сергей, а сколько внедрений "Вепря" на сегодняшний день?

                      (мы с Вами примерно год назад общались e-mailом на тему УЦ)
                      Earl Vlad Drakula. ///

                      Комментарий


                      • #12
                        Еще раз (думаю последний :-)) под одним и тем же корнем НЕ МОЖЕТ быть издано сертификатов с одинаковыми открытыми ключами – это коллизия (ФЗ «Об ЭЦП» Статья 9 пунк 1 УЦ - «проверяет уникальность открытых ключей ……").

                        Я не понял про чей УЦ спрашивали, если про «Вепрь» - мы его делали с нуля сами и изначально позиционировались как публичный (в нынешней ситуации, к сожалению – большая корпоративная PKI система, где число сертификатов измеряется тысячами, а не штуками или сотнями). Это не коробочное решение – это комплекс из пяти машин и ясное дело он не продается как пончики у метро. Мы живем не с продаж УЦ, а с систем.
                        Что касается вопроса УЦ как организации, то вы совершенно правы – УЦ это целая организация со своим штатом, регламентом и т. д. За рубежом «жизнь» любых УЦ подчиняется специальному документу – Certification Practice Statement (CPS) – это книжка в 50 страниц – у них, а у нас еще еще толще – российская специфика (правила эксплуатации сертифицированного СКЗИ, ФЗ «Об ЭЦП» не работатет, нет публичных УЦ, нет лицензий на УЦ, если нет прямого договора по ГК между двумя спорящими не решаемая задача в суде и т.д.)
                        Но самая большая техническая засада для варианта, о котором мы рассуждали (сертификаты издаются в публичных УЦ, если вспомнить Петрова) – это НЕСОВМЕСТИМОСТЬ сертифицированных СКЗИ и факта, что не существует договоренности производителей о формате сертификата открытого ключа (следом тянется куча проблем по регистрации OID криптоалгоритмов различных производителей (СКЗИ) и иных объектов как ИНН, а также дерева имен для сетевых справочников публичных УЦ в рамках РФ).

                        Комментарий


                        • #13
                          Sergey_Murugov

                          Я не понял про чей УЦ спрашивали, если про «Вепрь» - мы его делали с нуля сами
                          Гм. А как еще можно интерпретировать вопрос "Сколько внедрений "Вепря" на сегодня"

                          Это не коробочное решение – это комплекс из пяти машин и ясное дело он не продается как пончики у метро.
                          1. Я специальнно написал "внедрений", а не продаж, ибо знаю, что такое "Вепрь", Вы мне год назад очень подробно объяснили.
                          2. Вы считаете, что RSA Keon - это пончики? Вполне себе коробочный продукт (требующий, естественно, некоторого приложения головы и рук при внедрении), хотя и в состоянии "тянуть" 8 миллионов сертификатов (а не тысяч ).

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

                          (следом тянется куча проблем по регистрации OID криптоалгоритмов
                          Кстати, если не секрет, а почему ваша компания решила регистрировать OIDы в DoDовском дереве (1.3.6.1.4.1), а не в российском (1.2.643)?
                          Earl Vlad Drakula. ///

                          Комментарий


                          • #14
                            hugevlad: Вы подписали документ своим секретным ключом. Как получатель должен разруливать, при помощи которого из сертификатов открытого ключа ее проверять?

                            Так ведь, я полагаю, к подписи прилагается идентификатор сертификата, которым ее проверять. Разве не так?

                            to Sergey_Murugov

                            Спасибо за разъяснения. Я, действительно, не обратил внимание на Статью 9 пункт 1 об уникальности открытого ключа в реестре УЦ. Но тогда возникает вопрос, как обеспечить уникальность открытого ключа на всех УЦ? Ведь общий реестр сертификатов в законе не предусмотрен.

                            Sergey_Murugov: Для вашего примера, где несколько банков и фирмы между собой ничем не связаны, кроме как включать в сертификат Петрова информацию о том что он имеет право подписывать договор – другого пути нет, а отсюда и издержки – начальник Петрова должен отслеживать валидность «служебного» сертификата Петрова.

                            Есть еще вариант, когда фирма заводит и анулирует свои сертификаты через банк, в котором она обслуживается. Разумеется, на основании соответствующего договора с банком. Мне кажется этот вариант естественным, т.к. каждая фирма или организация обслуживаются в банке и
                            фирмам и так приходится носить в банк карточки с образцами подписей и печати. Так что такая процедура для них привычна.
                            Только для реализации такой схемы следует предусмотреть в сертификате поле для указания того, что для физлица фирмы он создан банком. В этом случае УЦ должен будет реагировать на электронные запросы по анулированию данного сертификата, подписанные банком. И никаких бумажных документов фирме не нужно будет тогда носить в УЦ, только в свой банк, по проторенной дорожке .

                            Комментарий


                            • #15
                              to hugevlad
                              Давайте не уходить в сторону от темы конференции. Я всячески стараюсь остаться в рамках регламента и не напрашиваться на развитие темы по промоушену «Вепря». Если интересно заезжайте, поговорим. Хочу сказать только одно 8 миллионов это одна 20 часть населения нашей страны (включая стариков и младенцев), второе, такой Keon стоит 8000000$ + обязательный саппорт + таможня с НДС + стоимость сертифицированного СКЗИ на 8 миллионов копий и я не знаю ни одной конторы в стране, которая бы заплатила за подобную «игрушку» такие деньги.
                              [/B]

                              Комментарий


                              • #16
                                Что-то я не могу понять схему.
                                Сертификаты для Петрова кто делал, банк? Тогда у него должен быть УЦ. И тогда что в банк идти, что в УЦ – это одно и тоже.
                                Или банк – уполномоченное лицо фирмы в УЦ и для Петрова банк получает сертификат в УЦ?
                                Мы говорили о другом – Петров получил сертификат на стороне, этот сертификат должен быть каким то образом зарегистрирован в банке. Это может быть сделано либо через служебную информацию в сертификате Петрова или созданием атрибутного сертификата в банковской системе. Далее Петров перестает быть «подписывающим» лицом, банк об этом факте должен каким то образом узнать и не принимать его (Петрова) ЭЦП. Т.е. на основании уведомления от фирмы отозвать в УЦ сертификат Петрова, либо уничтожить самому атрибутный сертификат. Все это чисто регламентные процедуры и технических трудностей не представляют.
                                Но при этом есть одна техническая проблема – сертификат Петрова должен быть выполнен в той криптосистеме (того производителя СКЗИ) который понимается и банком в его автоматизированной системе. А тут несколько путей, либо ложиться только под одного производителя СКЗИ, либо использовать DVCS.

                                Комментарий


                                • #17
                                  sandyman

                                  Так ведь, я полагаю, к подписи прилагается идентификатор сертификата, которым ее проверять. Разве не так?
                                  Не факт. Ладно, если прилагается номер сертификата (3 разных сертификата на один открытый ключ будут иметь разные номера). А если только CN?

                                  Sergey_Murugov
                                  всячески стараюсь остаться в рамках регламента и не напрашиваться на развитие темы по промоушену «Вепря». Если интересно заезжайте, поговорим
                                  Причем тут промоушн? Здесь нечасто появляются разработчики, и уж за сведения о количестве продаж/внедрений продукта никто ни на кого не наезжал. Тем более, что Вы бы их сказали в процессе ответа на вопрос
                                  Впрочем, как хотите, я могу и e-mailом написать...

                                  Хочу сказать только одно 8 миллионов это одна 20 часть населения нашей страны
                                  Цифра была приведена исключительнно для иллюстрации мощи/масштабируемости решения. Никто никого не заставляет брать именно такую конфигурацию. Реально востребованные конфигурации стоят существенно меньше, вполне приемлемые для крупного банка деньги.

                                  + стоимость сертифицированного СКЗИ на 8 миллионов копий
                                  Сергей, Вы не хуже меня знаете, что на рынке существуют СКЗИ с понятием unlimited, или когда "сервер" на определенное количество подключений пользователей, а клиентская часть идет как бесплатное приложение.
                                  Ладно, раз не хотите публично - напишу e-mail.
                                  Earl Vlad Drakula. ///

                                  Комментарий


                                  • #18
                                    hugevlad , а что такое CN?

                                    Sergey_Murugov: Что-то я не могу понять схему.

                                    Наверное потому, что я привел две схемы и в обеих банковский УЦ отсутствует. В первой Петров сам заводит сертификат в публичном УЦ, во второй по просьбе Петрова с публичным УЦ контактирует банк. А еще есть Ваша схема с атрибутными сертификатами в УЦ (PKI?) банка. Кстати, если Ваша фирма может предложить банкам софт для работы с атрибутными сертификатами, то приведите хотя бы ссылку, чтобы с ним ознакомиться. А вообще, банкиры заинтересованы в представлении (и сопоставлении) разработчиками своих продуктов на форуме. В качестве положительного примера можно привести разработчиков Фактуры. Да и Дмитрий Репан,разработчик интернет-банкинга, несмотря на некоторую агрессивность, на форуме всегда желанный гость .

                                    Sergey_Murugov: Все это чисто регламентные процедуры и технических трудностей не представляют.

                                    Значит в Вашем УЦ уже сейчас любой банк может завести (анулировать) сертификат на должностное лицо фирмы? И для этого ни о чем в рамках АУДЭД договариваться не нужно?

                                    А еще Вы не ответили на вопрос, каким же образом на Вашем УЦ обеспечивается уникальность открытого ключа. Вы отсылаете запросы на все другие УЦ?

                                    Sergey_Murugov: А тут несколько путей, либо ложиться только под одного производителя СКЗИ, либо использовать DVCS
                                    Назовите этого производителя !

                                    P.S. Кстати, я создал топик "Стоит ли банку заводить свой УЦ?" (http://dom.bankir.ru/showthread.php?s=&threadid=28735 ), приглашаю высказываться.

                                    Комментарий


                                    • #19
                                      2 sandyman

                                      А еще Вы не ответили на вопрос, каким же образом на Вашем УЦ обеспечивается уникальность открытого ключа. Вы отсылаете запросы на все другие УЦ?

                                      Уникальности открытого ключа среди всех УЦ не требуется! Предположим, у Вас два сертификата в разных УЦ (УЦ1 и УЦ2) с одинаковым открытым ключом. Вы отослали сообщение в рамках определенной системы. Для проверки ЭЦП используется ваш сертификат и сертификат открытого ключа УЦ1. Если вместе с сообщением пересылается сертификат и вы отправите сертификат, выданный УЦ2, то не пройдет проверка сертификата, так как для проверки используется сертификат открытого ключа УЦ1.
                                      Just do it!

                                      Комментарий


                                      • #20
                                        1. Новый Адам – фирма разработчик автоматизированных систем по технологии PKI (УЦ «Вепрь» одна из компонент PKI) и мы не предоставляем услуги публичного УЦ.
                                        2. По поводу AA (Сервера атрибутных сертификатов) основано на RFC3281 от апреля 2002 года и насколько я знаю, его еще никто у нас не реализовывал. У нас в планах стоит сделать такую штуку во втором полугодии, правда несколько для других целей – разграничение доступа к ресурсам. У нас никто DVCS то не делает, хотя это более актуальный сервис, в части проверки ЭЦП на различных СКЗИ и вывода проверки ЭЦП из разряда задач прикладного сервера аппликаций (отсутствие сертифицированного СКЗИ под конкретную аппаратную платформу сервера, обслуживание произвольного числа СКЗИ …..).
                                        3. Я не понял о чем в рамках АУДЭД надо договариваться? Вопрос чистого регламента и способа размещения УЦ. Если УЦ принадлежит банку – все просто – выдали сертификат Петрову, кончились его полномочия – отозвали сертификат у Петрова. Для случая внешнего (публичного или ассоциативного) УЦ (если он в регламенте поддерживает обслуживание коллективных заявок от фирм с указанием качественной принадлежности каждого сотрудника) – тоже нет проблем.
                                        4. Перечень производителей сертифицированного СКЗИ можно найти на сайте ФАПСИ.

                                        Комментарий


                                        • #21
                                          sandyman

                                          а что такое CN?

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

                                          Обычный набор:

                                          cn - Common Name
                                          ou - Organizational Unit
                                          o - Organization
                                          c - Country
                                          e - E-mail
                                          Earl Vlad Drakula. ///

                                          Комментарий


                                          • #22
                                            pms Уникальности открытого ключа среди всех УЦ не требуется!

                                            А зачем нужна уникальность открытого ключа в отдельном УЦ?

                                            Sergey_Murugov: Я не понял о чем в рамках АУДЭД надо договариваться? Вопрос чистого регламента

                                            Не только. Я уже говорил, что наиболее естественным для фирм было бы общение с УЦ через банки, в которых они обслуживаются. При смене руководства фирмы, ей все равно нужно нести в банк новую карточку с образцами подписей, зачем фирме еще тащиться и в УЦ? Да и самому УЦ как-то несподручно этим заниматься.
                                            Но тогда в сертификатах фирмы должно быть где-то указано, что за них отвечает банк. Более того, электронные распоряжения банка на заведение или аннулирование сертификатов фирм должны быть подписаны конкретным сотрудником банка, которому поручили эту работу. И такой сотрудник должен быть не один - сертификат-то ведь личный, а люди болеют или в отпуск уходят. Значит где-то в УЦ должен вестись список таких сотрудников банка. Ваш УЦ готов к реализации такой схемы?

                                            Комментарий


                                            • #23
                                              Уникальность открытых ключей нужна, чтобы избежать мошеннических действий. RFC допускает вид подписи как сама подпись + серийный номер персонального сертификата (автора подписи) + имя издателя. Если допустить что открытые ключи у двух субъектов одинаковые, следовательно, и секретные тоже одинаковые, тогда я очень легко смогу сделать подпись с указанием серийного номера и издателя моего «двойника» и провести за него например платеж и в таком случае – «мизер не ловится».

                                              Зачем в процедуру получения сертификатов вплетать еще и банк. Я когда при социализме открывал счет в сберкассе мне хватало только паспорта, к получению которого банк отношения не имеет, так и с цифровыми сертификатами – это те же паспорта. Банк единственно только должен их зарегистрировать у себя в системе с привязкой к конкретной фирме – обычная задача прикладного ПО, Даже в сертификате можно не писать, что Петров - бухгалтер, достаточно в самом начале иметь бумажку от фирмы о том что Петров - бухгалтер, имеет право что-то подписывать и вот его сертификат. Если уж так хочется банкам тут немного «порулить» - это можно рассматривать как дополнительная услуга клиентам банка со стороны банка, что он для них где-то в УЦ получит еще и сертификаты.

                                              Комментарий


                                              • #24
                                                to Sergey_Murugov
                                                А разве вероятность генерации двух идентичных пар секретного и открытого ключей не равна нулю?

                                                Sergey_Murugov: Зачем в процедуру получения сертификатов вплетать еще и банк

                                                Я же говорил - чтобы фирмы могли подписать между собой договор без всяких дополнительных бумажек, даже, если они обслуживаются в разных банках.
                                                Для физлиц общаться с УЦ через банк необязательно. Но представьте, что толпа физиков, которая обслуживается в куче банков с филиалами ринется заводить сертификаты в один или два публичных УЦ.

                                                Вообще, имеет смысл говорить о 3 разновидностях сертификатов:

                                                1. Личный (или почтовый) - для получения которого физику не нужно нести в УЦ никаких документов. Сертификат оформляется исключительно в онлайне и ответственность за достоверность приведенных в сертификате сведений лежит на самом физике. Данный тип сертификата можно использовать в личной переписке теми, кто не хочет заводить гражданский сертификат.

                                                2. Гражданский - тоже для физиков, но для получения которого нужно предъявить в УЦ паспорт. Данный тип сертификата может использоваться для проверки подписи, которая уже будет аналогом собственноручной подписи.
                                                Правда, появление гражданских сертификатов может затянуться, т.к. здесь требуется участие паспортно-визовой службы. Скажем, МВД организует сервер, на котором периодически будут публиковаться списки недействительных паспортов. В таком случае, УЦ на основании этих списков должны аннулировать соответствующие сертификаты. А значит, требуется согласование регламента и формата списков. В рамках той же АУДЭД.

                                                3. Служебный - о котором, мы здесь, в основном, и говорили. Где записывается должность и полномочия руководства фирмы, подтвержденные соответствующими документами.

                                                Комментарий


                                                • #25
                                                  2 sandyman
                                                  Про необходимость уникальности открытого ключа в рамках одного УЦ Сергей уже ответил. А вероятность генерации двух одинаковых ключей не равна нулю, потому что множество ключей конечно
                                                  Just do it!

                                                  Комментарий


                                                  • #26
                                                    Опять какая то «каша» получается – давайте стуктурируем задачи:
                                                    1. банковский сектор – автоматизированная система построена на использовании цифровых сертификатов. Мы выяснили, что УЦ может находится:
                                                    a. либо в самом банке и выдавать сертификаты своим клиентам и отслеживать кто из них перестал обладать «правом подписи». Проблем нет кроме как в межбанковской интеграции и для пользователей держащих счета в нескольких банках.
                                                    b. Либо где-то внешне (публичный или межбанковский) но банк должен обязательно доверять этому УЦ. Выданные там сертификаты регистрируются в автоматизированной системе любым образом, наприер, через атрибутные сертификаты или как удобней это сделать в автоматизированной системе банка. Тоже проблем нет, есть трудности о которых я писал ранее – перечень поддерживаемых СКЗИ, OIDы, структура сетевого справочника и т.д. Кстати на официальном сервере ФАПСИ нашел фразу – привожу дословно "Средства криптографической защиты информации удостоверяющих центров должны:
                                                    i. обеспечивать проверку ЭЦП с различными значениями параметров на всех уровнях иерархической системы управления сертификатами;
                                                    ii. при использовании в Центрах Сертификации, СКЗИ должны обеспечивать формирование ЭЦП с различными значениями параметров."
                                                    Так что от поддержки нескольких СКЗИ в публичных системах никуда не деться.
                                                    2. «головная боль за всю страну» - система электронной коммерции на основе сертификатов (какая разница банку по какому договору идет проплата, одна сторона выставила счет, другая дала поручение банку перевести деньги и подтвердила это своей ЭЦП в рамках банковской системы и как между собой эти оба разбираются банку наверное все равно). Я хоть и не юрист, но точно знаю, что на сегодня можно работать с ЭЦП только в рамках предварительной – «бумажной» договоренности сторон – Гражданский кодекс.

                                                    Теперь по поводу разновидностей сертификатов, конечно очень хочется иметь разные для разных целей, однако кто пользовался кучей сертификатов тот подтвердит – это очень хлопотное занятие (я например в своей работе использую их порядка десятка). И мне кажется, что подход должен быть такой же как и обычной жизни – есть паспорт (сертификат) , далее ресурс (служба) должна «привязать» этот паспорт к своей системе (для случая с атрибутными сертификатами – это аналог сберкнижки или пропуска на объект) и пользователю не нужно ломать голову как выглядит или из чего состоит эта дополнительная привязка. Очень красиво все получается.

                                                    P.S. Личные (по вашей классификации) сертификаты и сейчас легко получить – например в Thawte для почты или у нас на www.office.ru . И это забота пользователя, а не банка. Зачем бумать за других - все равно наша строна пойдет как всегда своим путем.

                                                    Комментарий


                                                    • #27
                                                      Для Вашего пункта 1б возможно 2 решения:
                                                      1. За достоверность служебной информации в сертификатах фирм отвечает УЦ. Технических проблем здесь действительно нет. Только это неудобно ни фирмам, ни самому УЦ.
                                                      2. Я же предлагаю возложить ответственность за достоверность служебной информации в сертификатах подопечных фирм на банки. Это и фирмам удобно и УЦ не нужно возиться с бумажными документами. Вот здесь и может потребоваться некоторая доработка ПО.

                                                      Sergey_Murugov: я например в своей работе использую их порядка десятка
                                                      Вы работаете в десяти местах ?
                                                      Когда СКЗИ будут понимать друг друга большинству будет достаточно одного сертификата - личного или гражданского, а руководителям - два (гражданский и служебный)

                                                      Sergey_Murugov: Личные (по вашей классификации) сертификаты и сейчас легко получить.. И это забота пользователя, а не банка

                                                      Личные - конечно, ведь там паспорт не требуется. Я говорил о том, что получение гражданских сертификатов могут взять на себя банки. Ведь если УЦ организует свою собственную сеть оффисов для приема физиков, это скажется на его тарифах.

                                                      P.S. Интересно, вот допустим, будет функционировать сервер МВД. Но если гражданка потеряет паспорт, никому об этом не скажет и будет активно пользоваться электронной подписью. Не возникнет ли тут каких-либо проблем?

                                                      Комментарий


                                                      • #28
                                                        УЦ – отвечает за все, потому что он своей ЭЦП подписывает сертификат. И если он будет безоговорочно верить банку – это ни есть совсем правильно. Насчет доработки в ПО не очень понятно. Например, как сделано у нас – есть некий Абонентский Пункт Администратора на котором создаются заявки на выпуск сертификатов и управления их статусом. Этот АП может находиться где угодно, например, когда мы строили стенд на сертифицированной ОС Утес-К – АП находился на площадке Инфотекса, а второй Центр Регистрации и сам УЦ у меня в подвале, посередине был VPN с «бумажкой». И Инфотекс «пек» себе сертификаты из-под моего УЦ. Аналогично можно сделать и с банком – поставить в банке АП и «печь» с него сертификаты для пользователей (правда формально человек сидящий на АП должен числиться в структуре УЦ) либо еще «хитрей» в банке ставиться дополнительный Центр Регистрации (УЦ может поддерживать очень большое число ЦР) и также с АП «печь» сертификаты. В этом случае вариант более «честный».

                                                        Но мне все же не нравиться когда банк ввязывается в выдачу «паспорта», а что если пользователь держит несколько счетов по разным банкам + использует сертификаты на работе как элемент средств разграничения доступа для TLS – появляется все та же куча сертификатов – головная боль для пользователя (с одним в одно место, с другим в другое – и не перепутай). Более логично – регистрировать в банковской системе сертификат или оказывать услугу по получению сертификата пользователю, если у того его нет.

                                                        На счет сертификатов – сертификаты не коррелируются с числом рабочих мест – это десять удостоверений личности определяющих круг моих полномочий для разных систем.

                                                        На счет мечты о том что СКЗИ будут понимать друг друга – при нынешней системе сертификации СКЗИ такого не будет – ГОСТ однозначно НЕ определяет 3 таблички (хэшь, параметры подписи и таблицы замены) следовательно они могут быть разные, более того они (выдаются если ну очень не попросишь) вкомпилированы в СКЗИ и на все это дается сертификат. Меняешь таблички – не работает сертификат. Я еще несколько лет назад ФАПСюкам говорил, что с таким подходам мы «вляпаемся» в публичных системах – но им видней. Именно поэтому мы и ввязались в реализацию DVCS и поддержку PKCS#11 в своем УЦ, чтобы «малой кровью» не переделывая уровень аппликаций легко поддерживать наращиваемую кучу различных сертифицированных СКЗИ.

                                                        По поводу утери паспорта – конечно будут проблемы – потенциальная атака на систему. Также как если потерять кредитку, никому об этом не сказать, а потом удивляться – «а где мои деньги?».

                                                        Комментарий


                                                        • #29
                                                          Sergey_Murugov УЦ – отвечает за все, потому что он своей ЭЦП подписывает сертификат. И если он будет безоговорочно верить банку – это ни есть совсем правильно

                                                          Зачем верить? Это может быть договор на оказание услуг банком УЦ.
                                                          А заявки Администратора на создание сертификата и изменение его статуса подписываются или просто ведется протоколирование действий Админа? И доступ к АП просто по паролю?
                                                          А, вообще, идея с абонентскими пунктами в банках лично мне нравится!

                                                          Sergey_Murugov: а что если пользователь держит несколько счетов по разным банкам

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

                                                          Sergey_Murugov: сертификаты не коррелируются с числом рабочих мест – это десять удостоверений личности определяющих круг моих полномочий для разных систем

                                                          Почему Вам будет недостаточно одного гражданского и одного служебного? Зачем Вам еще восемь, когда все системы смогут использовать сертификаты публичных УЦ?

                                                          Sergey_Murugov: На счет мечты о том что СКЗИ будут понимать друг друга

                                                          Я так понимаю, что АУДЭД собирается усадить разработчиков СКЗИ за стол переговоров, чтобы они нашли общий язык. Мечты сбываются и не сбываются.. Посмотрим.

                                                          Sergey_Murugov: По поводу утери паспорта – конечно будут проблемы – потенциальная атака на систему

                                                          Я о том, что гражданка потом заявит, что, подписывая электронные документы, не знала о том, что потеряла паспорт (через полгода какой-то мальчик принесет найденный паспорт в милицию). Не объявит ли суд подписанные документы недействительными?

                                                          Комментарий


                                                          • #30
                                                            1. У нас весной выходит 4 версия Вепря (в старой версии тоже кое что поддерживалось) там все запросы из АП оформляются как подписанные сообщения на ключе администратора и реализовано в рамках RFC для CMS, CMC (RFC2797), CRMF (RFC2511). Доступ к АП администратор имеет только при наличии аппаратного токена (iKey или eToken), PIN и налиция в сертификате администратора специальных мандатных меток определяющих уровень полномочий, например, «обычный» админ ни при каких условиях не может отозвать сертификат более старшего по уровню админа или корневой сертификат. Все запросы и ответы хранятся в «истории жизни сертификата» как взаимосвязанные события с ЭЦП автора события. На самом АП журнал действий администратора не ведется – это бессмысленно, поскольку нет достоверного контроля за АП, а сам Windows позволяет любому (или с легкими ухищрениями любому) делать все что угодно на компьютере. АП связываются с серверами служб УЦ по TLS, где по мимо шифрования используется контроль доступа к ресурсу на основе именно админсткого сертификата. Все это в каком то виде есть у нас на сервере (http://www.adam.ru/).
                                                            2. Сертификат пользователя выдал один банк, а другие банки этот сертификат принимают – автоматизированные системы банка в таком случае должны уметь привязывать этот «чужеродный» сертификат пользователя о чем я писал ранее и не в одном письме. И тогда просто напрашиваются несколько тезисов:
                                                            a. Банки должны уметь работать с “чужими» сертификатами – интегрировать их в свои АС (о техреализации я писал ранее).
                                                            b. Поддерживать всю кучу несовместимых СКЗИ, т.к. неизвестно с чем придет пользователь.
                                                            c. Оказывать опциональные услуги по выдачи сертификатов своим клиентам (если согласно вашей схемы у клиента не было сертификата).
                                                            3. По поводу моих сертификатов, некоторые их них используют различные СКЗИ, некоторые в своем составе содержат специальные расширения служебного характера типа Петров – бухгалтер, Петров – генеральный директор и т.д. Это иллюстрация того, что Петров должен иметь только один паспорт – сертификат, а дело ресурса или банковской системы построить связку сертификат пользователя – уровень привилегий в системе, например на основе атрибутных сертификатов, что мы и будем реализовывать к концу года.
                                                            4. Усадить разработчиков за стол переговоров. Я же вам говорил – они то не при чем, они честно заплатили денег (и не малые) за сертификацию – им ФАПСИ выдало различные (за некоторым исключением) параметры и все. За чей счет производить пересертификацию? По формату сертификата и TLS – выбирая те или иные способы реализации (особенно под Windows CSP) не все можно сделать как хочется-правильно, поэтому всех уговорить не удастся, почему трудности одних должны стать трудностями всех.
                                                            5. По поводу гражданки – я не понял при чем тут утерянный паспорт. На основании паспорта можно выпустить новый сертификат или отозвать старый – это из гадостей и в этом атака. И по закону, что имеет ЭЦП на валидном сертификате – действительно.

                                                            Комментарий

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

                                                            Свернуть

                                                            Присутствует 1. Участников: 0, гостей: 1.

                                                            Обработка...
                                                            X