Bankir.Ru
29 мая, понедельник 07:03

Объявление

Свернуть

На Bankir.ru начался цикл публикаций, созданных по следам обсуждений на форуме

Показать больше
Показать меньше

О юридической значимости протокола SSL

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

  • О юридической значимости протокола SSL

    Уважаемые коллеги!

    Некоторые разработчики в своих статьях и выступлениях постоянно упирают на юридическую незначимость протокола SSL в России, настойчиво рекомендуют "общепризнанные стандартные решения" типа Excellence, LanCrypto и пр., и поcтоянно подчеркивают наличие возможности интегрировать в предлагаемые системы решения, сертифицированные ФАПСИ. В связи с этим позволю себе высказать свою личную точку зрения по указанным вопросам.

    Если разобраться со спецификацией и назначением протокола SSL, то очевидными становятся следующие ключевые моменты:

    - Криптографический протокол SSL является открытым и общепризнанным мировым стандартом. SSL был предложен компанией Netscape в начале 90-х, притерпел несколько модификаций, выдержал много атак. Несколько прорех в протоколе SSL, которые были выявлены за всю его историю, были вызваны исключительно ошибками в конкретных реализациях. На текущий момент свободно доступно в исходных текстах несколько реализаций протокола SSL версии 3, широко и повсеместно используемых во всем цивилизованном мире.

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

    - Криптографический протокол SSL позволяет добавлять и использовать различные криптографические алгоритмы. Одним из примеров такого добавления является Inter-Pro, продукт российской компании "Сигнал-КОМ", который на текущий момент находится на завершающей стадии Сертификации в ФАПСИ (со слов сотрудника ФАПСИ из отдела Лицензирования и Сертификации). В рамках Inter-Pro в протокол SSL компанией добавлена реализация российских криптографических алгоритмов - шифрование ГОСТ 28147-89 и ЭЦП ГОСТ Р34.10-94.

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

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

    Что касается юридической значимости. Откроем Гражданский Кодекс Российской Федерации. Обратимся сначала к Часте Первой, Статье 434, пункт 1: "Если стороны договорились заключить договор в определенной форме, он считается заключенным после придания ему условленной формы..."

    Теперь возратимся немного назад, и прочитаем Статью 160 п.2: "Использование при совершении сделок ... электронно-цифровой подписи ... допускается в случаях и порядке, предусмотренных законом, иными правовыми актами или соглашением сторон"

    Здесь можно привести еще с десяток цитат из ГК РФ, ФЗ "Об информации, информатизации и защите информации", вспомнить материалы Высшего Арбитражного Суда РФ, привести комментарии известных юристов и пр. Всё это лежит в основе договорных отношений, на которых строится работа как по классическому толстому Банк-Клиенту, так и по его новой генерации - по Интернет-Банкингу. Именно в соответствии с этими законодательными актами и работают все российские банки. И именно в это поле может отлично "вписаться" любой Договор, предусматривающий работу практически с любым протоколом или механизмом, будь то SSL, файловый обмен, SecureFTP, http поверх SSL, html-формы с ЭЦП, логи с ЭЦП и пр.

    Возвращаясь к статьям разработчика легко заметить, что разработчик достаточно часто сам себе противоречит, утверждая юридическую незначимость криптографического протокола SSL, и тут же юридическую значимость своего самодельного и пока закрытого криптографического протокола, поверх которого работает протокол http.

    И теперь что касается возможности встраивания в системы для Интернет-Банкинга решений, сертифицированных ФАПСИ. Уверен, что при адекватном спросе и соответствующем финансовом обеспечении, ВСЕ разработчики обеспечат данную функцию. Было бы только желание у Заказчика. Я же остановлюсь только на Java-технологиях и предлагаемой нами системе "iBank". Возможно для некоторых будет открытием, но существует с десяток прекомпиляторов, позволяющих получать Java-код из исходных текстов, написанных на С, С++, и на других современных языках программирования. Более того, Java позволяет использовать уже готовые нативные модули и библиотеки. Именно по пути интеграции в iBank Сертифицированных ФАПСИ решений мы готовы пойти для удовлетворения требований наших Заказчиков. Варианты для выбора на российском рынке существуют. Например, программная библиотека защиты информации "Базис-защита" российской компании "АНКОРТ" (Сертификат Соответствия ФАПСИ СФ/114-0334 от 26 мая 2000г.), полностью реализованная на ANSI C.

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

    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com
    С уважением, Репан Димитрий
    Компания "БИФИТ" - www.bifit.com

  • #2
    Дмитрий!
    Вы не упомянули об Указе Президента РФ от 3 апреля 1995 г. N 334 "О мерах по соблюдению законности в области разработки производства, реализации и эксплуатации шифровальных средств, а также предоставления услуг в области шифрования информации". В конференции он уже был озвучен. Вот некоторые выдержки из него:
    "4. В интересах информационной безопасности Российской Федерации и усиления борьбы с организованной преступностью запретить деятельность юридических и физических лиц, связанную с разработкой, производством, реализацией и эксплуатацией шифровальных средств, а также защищенных технических средств хранения, обработки и передачи информации, предоставлением услуг в области шифрования информации, без лицензий, выданных Федеральным агентством правительственной связи и информации при Президенте Российской Федерации связи и информации".
    6. Федеральной службе контрразведки Российской Федерации и Министерству внутренних дел Российской Федерации совместно с Федеральным агентством правительственной связи и информации при Президенте Российской Федерации, Государственной налоговой службой Российской Федерации и Департаментом налоговой полиции Российской Федерации осуществлять выявление юридических и физических лиц, нарушающих требования настоящего Указа."
    Вы предлагаете банкам заключать договора с клиентами, в которых если что будет крайним клиент. Однако этот указ при судебном разбирательстве и использованием банком несертифицированном ФАПСИ ПО криптозащиты окажет "медвежью услугу" банку.

    Герасимов Александр

    Комментарий


    • #3
      Да, и самое главное, не упомянут ФЗ "О Лицензировании отдельных
      фидов деятельности", на котором основывается данный указ Президента.
      По сути на основании этого ФЗ можно судить о полной
      монополии органов (ФАПСИ) на шифровальние средства.
      И тут никуда уже не денешся - используя не сертифицированные шифровальные средства фирмы действуют на свой страх и риск.

      Да, и с самого начала дискусии надо было отделить Использование
      от Сертификации. Использовать никто не запрещает, подписывате
      договор о применении шифрования - и вперед, а сертифицировать
      обязан.

      имхо законы д..мо.
      WBR
      serg

      Комментарий


      • #4
        Господа, ну нельзя же до сих пор путать понятия сертификация и лицензирование. Закон о лицензировании отдельных видов деятельности требует наличие лицензии на эксплуатацию шифровальных средств. Получив лицензию ФАПСИ, вы можете использовать любые шифровальные средства (включая буржуйские). Особые условия, например необходимость использовать именно сертифицированные средства, либо необходимость согласовывать с ФАПСИ перечень используемых средств, должны быть явно оговорены в лицензии. Т.е. если у вас в лицензии написано что она дает право эксплуатировать только сертифицированные средства, значит вас обманули и использовать продукты Элиас-а, ЛанКрипто и RSA Security вам нельзя.

        Правда, я не вполне понимаю о чем спор. У нас что, есть работающие Internet решения в которых используются сертифицированные средства? (То что они принципиально могут быть встроены, или то что у разработчика есть лицензия на эксплуатацию не считается)
        Вообще-то вопрос риторический. Насколько я понимаю не существует ни одного сертифицированного средства удовлетворяющего хоть какому-нибудь стандарту Интернет (IETF RFC) про безопасность.

        Комментарий


        • #5
          Alexander прав, тема уже поднималась ранее - http://www.bankir.ru/ubb/Forum11/HTML/000020.html

          Стоит отметить, что Закон о лицензировании отдельных видов деятельности ╧ 158-ФЗ не предусматривает получение лицензии на эксплуатацию шифровальных средств. ФАПСИ лицензируются лишь следующие виды деятельности (ст.17 Закона):

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

          Дополнительно ФАПСИ лицензирует:
          а) право удостоверения идентичности электронной цифровой подписи
          б) проведение работ, связанных с осуществлением мероприятий и (или) оказанием услуг по защите государственной тайны ( совместно с ФСБ, Гостехкомиссией, СВР).

          Лицензирование деятельности по эксплуатации (использованию) шифровальных средств требуют:
          1) Положение о государственном лицензировании деятельности в области защиты информации" от 27.04.94;
          2) Указ Президента ╧ 334 от 3.04.1995;
          3) Положение о порядке разработки, производства, реализации и использования средств криптографической защиты информации с ограниченным доступом, не содержащей сведений, составляющих государственную тайну от 23.09.1999 (Далее ПКЗ-99)

          1) Положение явно устарело; находится в противоречии с нормами ГК, ФЗ о лицензировании отдельных видов деятельности и Постановления Правительства ╧ 326 от 11.04.00. В соответствии с п.3 указанного Постановления ФАПСИ должно было представить во II квартале этого года новый проект положения о лицензировании деятельности в области защиты информации.Думаю в начале 2001, данное Постановление появится в Базе.

          2) Указ Президента также противоречит Закону. Подробнее - http://www.bankir.ru/ubb/Forum11/HTML/000020.html

          3) ПКЗ-99 вообще представляет собой безграмотно составленный нормативный документ (особенно преамбула). Пункт 36 Положения требует наличие лицензии у лиц использующих СКЗИ. Нормы положения позволяют ФАПСИ лавировать и отказывать в выдачи лицензии на несертифицированные продукты. Мы получили ответ из ФАПСИ касательно Системы Банк-Клиент - " .... Федеральное Агентство выдает лицензии только на сертифицированные средства российского производства... Приобретение указанного программного продукта у потенциального поставщика, не имеющего лицензии, предполагает возмещение возможных убытков потребителем..."
          Естественно, отказ в выдаче лицензии по основанию отсутствия сертификата на продукт ( если продукт не связан с государственной тайной и не используется в государственных органах), можно обжаловать в судебном порядке, как противоречащий ФЗ " О лицензировании отдельных видов деятельности".

          Комментарий


          • #6
            Я как клиент ИнтернетБанка, интересуюсь:
            Достаточно ли SSL, для защищенности системы (процесс аутентификации)?

            Комментарий


            • #7
              BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил b2n
              Я как клиент ИнтернетБанка, интересуюсь:
              Достаточно ли SSL, для защищенности системы (процесс аутентификации)? [/quote]
              Вопрос слишком общий. В первую очередь необходимо определить круг задач, решаемый в Вашем случае при использовании протокола SSL.

              Если рассматривать общий случай, то протокол SSL позволяет решать следующие задачи:
              - аутентификация Web-сервера
              - обеспечение целостности трафика
              - шифрование трафика
              - аутентификация клиента (требует наличия клиентского Сертификата у клиента)

              К сожалению, в спецификации протокола SSL версии 3 не предусмотрено предоставление сервиса ЭЦП под электронными документами. Соответственно, протокол SSL v.3 в чистом виде не может использоваться для создания систем электронного документооборота с ЭЦП (именно электронный документ с ЭЦП клиента, а не логи Web-сервера, должны являться доказательным материалом при разрешении конфликтной ситуации). Также из-за отсутствия в SSL механизма ЭЦП вытекают и не совсем компетентные заявления некоторых разработчиков о юридической незначимости протокола SSL.

              В представленных на российском рынке решениях для Интернет-Банкинга механизм ЭЦП клиента под финансовыми документами реализуется либо в виде отдельного, как правило нативного модуля (BS-Defender, Inter-Pro и др.) требующего установки и настройки , либо в виде Java-апплета. Во втором случае, в отличие от первого, удается сохранить тонкость и многоплатформенность клиента.

              На протокол SSL возлагают, как минимум, задачи по аутентификации клиентом Web-сервера и обеспечения целостности трафика. Возможно также использование функции шифрования трафика. Упоминаемые часто экспортные ограничения в протоколе SSL распространяются на используемые криптографические алгоритмы и длину сеансовых ключей шифрования, ограничивая последнюю 40 битами. На другие функции, например, на формирование стартового вектора для вычисления хэш-функций (обеспечение целостности трафика) экспортные ограничения НИКАК не влияют. В тоже время даже 40 битный сеансовый ключ шифрования требует для взлома 2^39 переборов (это около 500 триллионов комбинаций, и даже при переборе со скоростью 100 тыс. вариантов в секунду потребуется более двух месяцев).

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

              Резюмируя всё выше написанное:

              1. При использовании на стороне клиента непропатченных Web-браузеров (то есть с экспортными ограничениями на SSL), допустимо использование протокола SSL для аутентификации Web-сервера, клиента, и обеспечения целостности.

              2. При использовании на стороне клиента Web-браузеров с полноценным SSL, можно использовать и функцию шифрования протокола SSL.

              3. Одного протокола SSL недостаточно для полноценного Интернет-Банкинга - необходим еще механизи ЭЦП клиента под финансовыми документами.

              С уважением, Репан Димитрий
              Компания "БИФИТ" www.bifit.com
              С уважением, Репан Димитрий
              Компания "БИФИТ" - www.bifit.com

              Комментарий


              • #8
                to b2n:

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

                Но только помогает, а не решает их за вас. Решение же принимаете
                вы на основе анализа данных сертификатов. Что это за сертификаты,
                и для чего они нужны и как ими пользоваться здесь публиковалась статься А. Герасимова, насколько я помню, там об этом говорилось.

                При всех этих условиях можно с уверенностью использовать протокол
                SSL.

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

                Использование ЭЦП (как дополнительно к протоколу SSL дак и без использования последнего) в системах документооборота не всегда оправдано и имеет смысл. Например потому, что две указанные функции ЭЦП в некоторых случаях с уcпехом может выполнить протокол SSL (см. задачи SSL).

                В каких случаях, поясню. В случае, если стороны, которые обмениваются сообщениями, доверяют друг-другу, то использование ЭЦП дополнительно к протоколу SSL бессмысленно. Например, если Банк не собирается "кидать" своего клиента, а заботятся о своей репутации,
                а клиент не собирается "подставлять" свой банк, то нет смысла использовать ЭЦП. SSL сделает все, что необходимо для защиты сторон от злоумышленника. И многие банки исповедуют этот принцип.

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

                Можно предположить и промежуточные случаи: например банк доверяет
                клиенту, а клиент не доверяет банку (наивный банк , или наоборот
                (наивный клиент , то тогда достаточно только ЭЦП одной из сторон,
                думаю понятно. Очевидно, что криптографически равноправного
                Банкинга в последнем случае нет. В первом случае ЭЦП защищен только
                клиент, а во втором - только банк.

                Поэтому, здесь я оппонирую последнему выводу Димитрия: для полноценного (равноправного) банкинга не достаточно одной ЭЦП только
                под документом клиента, нужна еще ЭЦП со стороны банка,нужны чеки,
                и должна присутствовать возможность установить, что ЭЦП была сделана
                правильным програмным обеспечением, и т.д. Только в этом случае
                стороны могут доказывать свою правоту в суде.
                Равноправный банкинг только в первом и втором случаях. И не всегда
                оправдано использование ЭЦП.

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

                WBR serg


                WBR
                serg

                Комментарий


                • #9
                  BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил Sharpcat
                  В случае, если стороны, которые обмениваются сообщениями, доверяют друг-другу, то использование ЭЦП дополнительно к протоколу SSL бессмысленно. Например, если Банк не собирается "кидать" своего клиента, а заботятся о своей репутации, а клиент не собирается "подставлять" свой банк, то нет смысла использовать ЭЦП. SSL сделает все, что необходимо для защиты сторон от злоумышленника. И многие банки исповедуют этот принцип.
                  [/quote]

                  В общем случае, при полном доверии сторон друг-другу, использование ЭЦП действительно может показаться избыточным. Но с другой стороны всегда следует придерживаться высказывания Джима Бидзоса (RSA Data Security): "Независимо от того, используете вы Интернет для деловых или личных целей, безопасность всегда должна находиться на первом месте..."

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

                  BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR> Другая ситуация, когда ни клиент не доверяет банку, ни банк не доверяет клиенту.[/quote]

                  Если Клиент не доверяет Банку, то Клиент вообще не будет работать с Банком!!! Это же очевидно! Ну разве кто-то в здравом уме будет класть деньги в очередной "Чара-Банк", которому он не доверяет?!

                  BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR> В этом случае спасет только стандартная схема,
                  Либо бумажный документооборот: проходишь в банк с подписанной платежкой с печатью, банк принимает платеж, ставит свою печать и подпись, клиент уходит с чеком о принятии, либо тоже самое, только
                  с электронными документами: отправляешь подписанный платеж по платежной системе, получаешь обратно платежку с подписью банка (чек). В случае, разборок какдая сторона демонстрирует чек в суде.[/quote]

                  Да в случае отсутствия доверия к Банку со стороны Клиента уже не спасают никакие "стандартные схемы". А про суд можно просто забыть. Потому как суд - это плохая репутация для Банка, это потеря имиджа Банка, это уход клиентов. Но самое главное, суд - это высокие издержки, потраченное время, силы, нервы, и неизвестный конечный результат ;-)

                  BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR> Поэтому, здесь я оппонирую последнему выводу Димитрия: для полноценного (равноправного) банкинга не достаточно одной ЭЦП только
                  под документом клиента, нужна еще ЭЦП со стороны банка,нужны чеки,
                  и должна присутствовать возможность установить, что ЭЦП была сделана
                  правильным програмным обеспечением, и т.д. Только в этом случае
                  стороны могут доказывать свою правоту в суде.[/quote]

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

                  С уважением, Репан Димитрий
                  Компания "БИФИТ"
                  С уважением, Репан Димитрий
                  Компания "БИФИТ" - www.bifit.com

                  Комментарий


                  • #10
                    >> Не надо в этом вопросе фантазировать и заниматься теоритическими
                    >> изысканиями. Надо расписывать конкретные реальные конфликтные
                    >>ситуации.

                    Реальная конфликтная ситуация: клиент отправил платеж по системе
                    iBank на сумму X. А платеж не ушел вовремя из банка
                    (попросту был потерян). Клиент попадает на штраф Y.
                    Вопрос: с чем клиент придет в суд, отстаивать свою позицию?
                    WBR
                    serg

                    Комментарий


                    • #11
                      > Если банк хочет задержать деньги клиента,

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


                      > он это и так спокойно сделает, без всякого Интернет-Банкинга,

                      безо всякого интернет-банкинга банк не сможет не отправить
                      платеж, потому что у клиента есть чек, с печатью банка и подписью
                      операциониста о там что документ принят к исполнению.

                      что клиент будет демонстрировать в суде в случае с iBank-ом?
                      WBR
                      serg

                      Комментарий


                      • #12
                        BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил Sharpcat
                        безо всякого интернет-банкинга банк не сможет не отправить платеж, потому что у клиента есть чек, с печатью банка и подписью операциониста о там что документ принят к исполнению.[/quote]

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

                        С уважением, Репан Димитрий
                        Компания "БИФИТ" - www.bifit.com
                        С уважением, Репан Димитрий
                        Компания "БИФИТ" - www.bifit.com

                        Комментарий


                        • #13
                          В общем, я еще раз вынужден повторить вопрос: каким образом
                          в системе iBank криптографически обеспечена защита клиента
                          от манипуляций со стороны банка ? Что будет являтся
                          доказательством правоты клиента если дело будет перенесено
                          в суд?
                          WBR
                          serg

                          Комментарий


                          • #14
                            Прежде чем говорить о способе защиты, надо определиться с объектом защиты, и самое главное - и от чего защищаться. В предыдущих сообщениях я постарался показать, что предмет защиты от манипуляции банка для Интернет-Банкинга (как в общем-то и для обычного К-Б) на самом деле отсутствует. Не надо защищать пустоту. Надо разумно использовать те или иные методы. И не всегда это должен быть именно криптографический метод защиты. Ведь могут быть и организационные методы, и юридические и т.д.

                            С уважением, Репан Димитрий
                            Компания "БИФИТ"
                            С уважением, Репан Димитрий
                            Компания "БИФИТ" - www.bifit.com

                            Комментарий


                            • #15
                              Лучшее решение этого вопроса:
                              Надо выбирать надежные банки, которым не нужно задерживать деньги клиентов и которому дорого доверие последнего!

                              Комментарий


                              • #16
                                А разве для себя выбирают другие???
                                С уважением, Репан Димитрий
                                Компания "БИФИТ" - www.bifit.com

                                Комментарий


                                • #17
                                  > Прежде чем говорить о способе защиты, надо определиться с
                                  > объектом защиты

                                  я пытался это сделать в мессэдже к b2n. И рассмотрел
                                  возможные варианты.

                                  > В предыдущих сообщениях я постарался показать, что предмет
                                  > защиты от манипуляции банка для Интернет-Банкинга
                                  > (как в общем-то и для обычного К-Б) на самом деле отсутствует.

                                  Отсутствует почему? Потому что мы просто не хотим его видеть
                                  или от банка бесполезно защищаться?

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

                                  если мы строим систему безопасноси на принципе
                                  доверия сторон обмена (совершенно нормальная ситуация) то нет
                                  необходимости использовать ЭЦП для аутентификации. Аутентификация
                                  как метод нужен, но можно обойтись более простыми методами
                                  "симметричной ЭЦП" (если хотите): паролем или всякими телекс кодами.
                                  суть не меняется.

                                  Если никто не доверяет друг другу, то будь добр, стой систему безопасности по полной программе с чеками и т.д.

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

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


                                  WBR
                                  serg

                                  Комментарий


                                  • #18
                                    BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>отправил Sharpcat
                                    Реальная конфликтная ситуация: клиент отправил платеж по системе iBank на сумму X. А платеж не ушел вовремя из банка (попросту был потерян). Клиент попадает на штраф Y.
                                    Вопрос: с чем клиент придет в суд, отстаивать свою позицию?[/quote]

                                    Если банк хочет задержать деньги клиента, он это и так спокойно сделает, без всякого Интернет-Банкинга, и на полном основании, так как в Договоре на расчетно-кассовое обслуживание в подавляющем большинстве случаев банк оговаривает срок исполнения платежных поручений. И намеренно задержав исполнение на несколько дней, банк просто сошлется на Договор по расчетно-кассовому обслуживанию. Налоги же банки стремяться вообще не задерживать - себе дороже с ГНИ лишний раз конфликтовать.

                                    Что касается конкретно iBank'а, то есть два варианта.

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

                                    Второй вариант - банк не удаляет платеж из системы, а просто не исполняет его (ссылаясь на Договор РКО). Но при разрешении конфликтной ситуации в электронном документе фигурирует и время подписи документа клиентом. Время береться серверное. И здесь опять же возможность злоупотреблять у банка. Причем расклад опять же аналогичен обычному К-Б.

                                    Если же вдаваться в теорию и создавать всё-таки идеальное взаимодействие между Банком и Клиентом, то всё сводится к решению классической криптографической задачи об одновременной подписи двумя сторонами одного документа. А лучше тремя, где третья сторона - "независимый указатель текущего времени" На практике ни в каких предлагаемых на рынке системах я не встречал подобных решений.

                                    С уважением, Репан Димитрий
                                    Компания "БИФИТ" - www.bifit.com
                                    С уважением, Репан Димитрий
                                    Компания "БИФИТ" - www.bifit.com

                                    Комментарий


                                    • #19
                                      Уважаемые коллеги!

                                      Свой ответ на письмо Анатолия Сапрыкина я поместил в отдельный топик - http://www.bankir.ru/ubb/Forum11/HTML/000090.html

                                      С уважением, Репан Димитрий
                                      Компания "БИФИТ" - www.bifit.com

                                      С уважением, Репан Димитрий
                                      Компания "БИФИТ" - www.bifit.com

                                      Комментарий


                                      • #20
                                        to anatoliy_s:

                                        > ..приведу пример простейшего вскрытия iBank злоумышленником..

                                        тема уже обсуждалась в фидошных конференциях. Суть была такая:
                                        некоторые банки, работая с протоколом SSL предлагали скачать и
                                        инсталировать SSL-сертификат класса root подписанный банком
                                        самим себе прямо по интернет без всякого защищенного соединения.
                                        была всказана мысль, что это грубейшее нарушение правил работы
                                        с SSL.
                                        И вторая мысль была высказана: в известных web-браузерах
                                        решение по результатам проверки SSL сертификата носит рекомендательный характер.
                                        То есть, сертификат проверяется но рещение по результатам этой
                                        проверки принимает сам пользователь, который может не там посмотреть и не туда нажать и соединиться не с тем сервером.

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

                                        to Димитрий:

                                        > Твои "выводы" о пригодности или непригодности iBank'а под
                                        > тобою же определенные условия и задачи покоятся исключительно
                                        > на тобою же придуманной интерпретации бизнес-модели РКО,
                                        > для которой ты и пытаешься применить iBank.

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

                                        WBR
                                        serg

                                        Комментарий


                                        • #21
                                          Постепенно от "юридической значимости протокола SSL" Сергей стремится перевести топик к обсуждению достоинств и недостатков системы iBank, и модели, заложенной в основу iBank'а. Я в общем-то не против, более того - я только "ЗА" - за открытое и публичное обсуждение. Главное, чтобы в рамках очерченного топика мы не начинали перепрыгивать на другие темы и уходить в сторону. Итак, начнем. Мое мнение в отношении последнего сообщения Сервегя Фурова (Sharpcat).

                                          BLOCKQUOTE>font size="1" face="Verdana, Arial">цитата:/font>HR>Моя логика: Безопасность работает по принципу, "нарисуем - будем жить", т.е. сначала мы закладываем некую модель о потом выбираем
                                          нужные методы, а не наоборот сначала загрузили систему криптографией по самое немогу, а потом соображаем а нафига все это нужно?
                                          ведь многие без нее обходятся и живут.[/quote]

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

                                          Твои "выводы" о пригодности или непригодности iBank'а под тобою же определенные условия и задачи покоятся исключительно на тобою же придуманной интерпретации бизнес-модели РКО, для которой ты и пытаешься применить iBank.

                                          С уважением, Репан Димитрий
                                          Компания "БИФИТ" - www.bifit.com
                                          С уважением, Репан Димитрий
                                          Компания "БИФИТ" - www.bifit.com

                                          Комментарий


                                          • #22
                                            Димитрий, Вы обладаете поразительной способностью ╚уходить╩ от совершенно конкретных вопросов, неудобных для Вас по каким-либо причинам .
                                            Как Вы ушли в свое время от моего вопроса по поводу разрешения конфликтных ситуаций, так же и уходите в сторону абстрактных рассуждений от конкретного вопроса sharpcat.
                                            Полностью согласен с sharpcat в том, что одного факта наличия ЭЦП под документом для разрешения конфликта мало, важно, при каких обстоятельствах эта ЭЦП была наложена. Для конкретизации своей точки зрения (абстактно же мы с Вами не рассуждаем ), приведу пример простейшего вскрытия iBank злоумышленником. Очень бы хотелось услышать на него Ваши конкретные комментарии.

                                            Многие из клиентов Компании "Бифит" (www.bifit.com/c-clients.html) не приобретают сертификаты мировых сертификационных центров, а используют самим себе выданные сертификаты. Оно и понятно - сертификат, например, Verisign, стоит $900 в год - именно на такую сумму, даже без учета временных и организационных затрат на получение сертификата, возрастет стоимость владения iBank. ╚Вскрытие╩ клиента такого банка выглядит следующим образом:
                                            1. Злоумышленник на подставную фирму получает сертификат Thawte на подпись апплетов и называет его, например, BIFIIT;
                                            2. Злоумышленник пишет простейший java-апплет, внешне на 100% дублирующий окно входа, например, в рублевый апплет, где клиент вводит путь к ключевому файлу и пароль;
                                            3. Злоумышленник сам себе выдает сертификат, содержащий название сайта банка и идентификатор банка;
                                            4. При очередном заходе интересующего злоумышленника клиента на сайт банка, при помощи технологии, например, DNS-Spoofing, клиент перенаправляется на подставной сайт, в точности дублирующий банковский, и заходит на его защищенную SSL зону. При этом клиент видит то же предупреждение о неавторизованности сертификата (причем на английском языке), что и при обычном скачивании настоящего апплета с сайта банка. Естественно, бухгалтер привычно выбирает "Yes" и скачивает троянский апплет.
                                            5. При запуске этого троянского апплета бухгалтер так же привычно нажимает "Да" на проверке подписи под апплетом (согласитесь, когда проделываешь одну и ту же процедуру по три раза в день, на различишь надписи - "BIFIT" и "BIFIIT") и попадет в до боли знакомое окно ввода пароля и пути к ключам, в котором и передает троянскому апплету путь к ключам и пароли.
                                            6. Ключи и пароль немедленно пересылаются злоумышленнику, после чего троянский апплет эмитирует сбой в системе.
                                            7. Ничего не подозревающий клиент коннектится к банку еще раз, на этот раз все нормально, но ключи и пароль уже похищены.
                                            8. Злоумышленник от имени клиента заходит в банк, скачивает апплет, вводит пароль и ключи клиента и переводит все деньги со счета клиента в любой наиболее подходящий для этого по величине остатка счета момент (выписка же тоже видна).
                                            9. iBank вскрыт.

                                            Основана описанная выше процедура ТОЛЬКО на том, что бухгалтер НЕ ОБЯЗАН быть компьтерно грамотным, также он не обязан знать английского языка и имеет, как и любой человек, свойство быть невнимательным. Бухгалтер знает одно √ ╚береги дискету с ключами╩ - и бережет ее, а ключи у него все равно украли.
                                            Поэтому, ответы, ориентированные на требование к минимальной компьютерной грамотность клиента и внимательность бухгалтера, прошу не предлагать.
                                            С уважением, Анатолий Сапрыкин

                                            Комментарий


                                            • #23
                                              Дмитрий!
                                              Вы не упомянули об Указе Президента РФ от 3 апреля 1995 г. N 334 "О мерах по соблюдению законности в области разработки производства, реализации и эксплуатации шифровальных средств, а также предоставления услуг в области шифрования информации". В конференции он уже был озвучен. Вот некоторые выдержки из него:
                                              "4. В интересах информационной безопасности Российской Федерации и усиления борьбы с организованной преступностью запретить деятельность юридических и физических лиц, связанную с разработкой, производством, реализацией и эксплуатацией шифровальных средств, а также защищенных технических средств хранения, обработки и передачи информации, предоставлением услуг в области шифрования информации, без лицензий, выданных Федеральным агентством правительственной связи и информации при Президенте Российской Федерации связи и информации".
                                              6. Федеральной службе контрразведки Российской Федерации и Министерству внутренних дел Российской Федерации совместно с Федеральным агентством правительственной связи и информации при Президенте Российской Федерации, Государственной налоговой службой Российской Федерации и Департаментом налоговой полиции Российской Федерации осуществлять выявление юридических и физических лиц, нарушающих требования настоящего Указа."
                                              Вы предлагаете банкам заключать договора с клиентами, в которых если что будет крайним клиент. Однако этот указ при судебном разбирательстве и использованием банком несертифицированном ФАПСИ ПО криптозащиты окажет "медвежью услугу" банку.(C)

                                              Хотелось бы все-таки услышать ответ как бороться с этим указом!


                                              Комментарий


                                              • #24


                                                iBank обеспечивает юридическую значимость электронного финансового документооборота. Четко проработана процедура разрешения конфликтных ситуаций. Предусмотрена возможность интеграции криптографических средств, сертифицированных ФАПСИ.(c)

                                                где можно подробнее прочитать о процедуре этой интеграции,
                                                и каких именно крипсредств, или любых?


                                                Комментарий


                                                • #25
                                                  iBank позволяет интегрировать любые критографические средства, реализованные в соответствии с JCA (Java Cryptography Architecture). В общем случае есть два варианта.

                                                  Первый вариант - криптографические библиотеки реализованы полностью на Java в соответствии с JCA. Здесь вообще всё очень просто и подключается "в лоб".

                                                  Второй вариант - все оставшиеся случае, когда, например, криптографические библиотеки реализованы на Си, на той же Java но без поддержки JCA, или представлены уже в виде dll-ек, so-шек и пр. В этом случае приходится писать "обертку", которая с одной стороны взаимодействует с криптографической библиотекой через ее API, а с другой стороны поддерживает API JCA.

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

                                                  Если нужна более конкретная информация - приезжайте к нам в офис, мы всё обсудим и предоставим всё необходимое.

                                                  С уважением, Репан Димитрий
                                                  Компания "БИФИТ"
                                                  С уважением, Репан Димитрий
                                                  Компания "БИФИТ" - www.bifit.com

                                                  Комментарий


                                                  • #26
                                                    Коллеги,
                                                    а кто сказал, что Верба -- сертифицированный ФАПСИ продукт? Сертификат на нее уже просрочен. На сегодня он продлен только для учреждений ЦБ РФ. Матюхин поддерживать Вербу, по достаточно достоверным сведениям, не собирается. Вместо нее, судя по всему, будет продукт компании КриптоПро (созданной специально для его маркетинга), в основе которого -- разработки НТЦ Атлас. Для интересующихся причиной - hint: Вербу распространяло МО ПНИЭИ, в котором были интересы Солдатова. Сейчас Солдатова нет, а Пярин (НТЦ Атлас) -- зам Матюхина.

                                                    Комментарий


                                                    • #27
                                                      А кто нибудь скажет, где можно посмотреть список сертифицированных ФАПСИ продуктов?

                                                      Комментарий


                                                      • #28
                                                        Кстати, не далее как неделю назад, 11 марта 2001 года, ООО "Крипто-Про" получило Сертификат Соответствия ФАПСИ СФ/114-0411 на СКЗИ КриптоПро CSP. Подробности - на www.cryptopro.ru/cert.htm

                                                        Для справки. Основные функции, реализуемые КриптоПРО CSP:

                                                        - генерация секретных (256 бит) и открытых (1024 бита) ключей ЭЦП и шифрования;
                                                        - хеширование данных в соответствии с ГОСТ Р 34.11-94;
                                                        - шифрование данных во всех режимах, определенных ГОСТ 28147-89;
                                                        - имитозащита данных в соответствии с ГОСТ 28147-89;
                                                        - формирование электронной цифровой подписи в соответствии с ГОСТ Р 34.10-94;

                                                        В общем, всё бы хорошо, но вот реализации криптоалгоритмов только для Windows (в соответствии с MS Crypto API). Реализация же на JAVA в соответствии с JCA и JCE только в планах Так что о платформонезависимости предлагаемых библиотек можно пока забыть. Хотя использование в банках Sun-ов, Alpha, AS/400 и др. серверных платформ для Интернет-решений уже вполне обыденная картина!

                                                        А вот публикация исходных текстов была бы сильнейшей пиаровской и маркетинговой акцией (кстати OpenSource - не значит Freeware). Доверие к разработкам ФАПСИ (а Государственное Унитарное Предприятие НТЦ Атлас и есть фактически часть ФАПСИ) выросло бы несоизмеримо. Постоянные стоны и сомнения о наличии закладок в ФАПСИшных продуктах были бы полностью развеяны. Ну а если бы и ценовую политику как для конечных потребителей, так и для разработчиков прикладного ПО сделали бы более мягкой, гибкой, ориентированной на горизонтальный рынок (в эпоху Интернет по другому и нельзя) - тогда бы и рынок исчез как таковой . Либо пользуй бесплатные несертифицированные библиотеки, коих в интернете уже много, в том числе и ГОСТы, либо за разумную денюжку сертифицированные. Вот она, свобода выбора

                                                        С уважением, Репан Димитрий
                                                        Компания "БИФИТ"
                                                        С уважением, Репан Димитрий
                                                        Компания "БИФИТ" - www.bifit.com

                                                        Комментарий


                                                        • #29
                                                          Этот Крипто-про только для маст-дая! Меня, например, интересует версии под Юникс (Линукс).

                                                          Александр

                                                          Комментарий


                                                          • #30
                                                            Вот и я говорю (пишу) - были бы сертифицированные библиотеки реализованы на Java, да в соответствии с Java Cryptography Architecture в виде внешнего подключаемого криптопровайдера, да еще с открытыми исходными текстами (но это не значит, что бесплатно - библиотеки Лицензируются за денюжку), да с разумной ценовой политикой (а не манией контроллировать каждую установку у клиента) - цены бы таким библиотекам не было! И работали бы везде, в том числе и на Линуксе, и на Соларисе, и на других платформах. А то переклинило всех на Windows. Раньше такая же мания была с DOS-ом.

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

                                                            И второе. При общении с разработчиками Крипто-Про выяснился интересный факт - Сертификация происходит под конкретную платформу (железка + ОС), что фактически есть "среда исполнения". А вот в отношении Java - как бы и нет (с их слов) конкретной железки. Я же считаю, что в случае Java конкретная реализация виртуальной Java-машины и есть та самая "среда исполнения". То есть можно было бы Сертифицировать криптобиблиотеки для исполнения в JVM от Sun, от IBM, от Microsoft.

                                                            С уважением, Репан Димитрий
                                                            Компания "БИФИТ"
                                                            С уважением, Репан Димитрий
                                                            Компания "БИФИТ" - www.bifit.com

                                                            Комментарий

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

                                                            Свернуть

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

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