| ||||
| ||||
| В системах интернет-банкинга создание платежных документов происходит в веб-приложении (которое работает внутри браузера). При этом веб-приложение не имеет доступа к файлам и программам клиента. Криптографическое ПО должно иметь доступ к файлам клиента (для того чтобы достать Private Key). Каким образом клиент осуществляет подпись платежных документов? Как при этом взаимодействуют веб-приложение и криптографическое ПО? Прошу пояснить на концептуальном уровне. | ||||
| Ответы: | ||||
| ||||
| Для поддержки криптографии на стороне клиента (IE) можно использовать COM-объекты (CAPICOM, например, или написать собственные). Закрытые ключи (сертификаты) не обязательно хранить на диске, для этого тот же IE, к примеру, использует хранилище сертификатов, доступ к которому осуществляется с помощью CryptoAPI или того же CAPICOM. | ||||
| ||||
| Вот простой пример с CAPICOM на VBScript: Dim sSignedDoc Dim SignedData sSignedDoc = "Привет" Signature = "" Set SignedData = CreateObject("CAPICOM.SignedData") SignedData.Content = sSignedDoc Signature = SignedData.Sign (Nothing, False, 1) SignedData.Verify Signature, False, 1 If HandleError Then MsgBox "Verified error" End If MsgBox "Verified OK" | ||||
| ||||
| Спасибо. Есть ли какие-либо другие способы взаимодействия веб-приложения и крипто-ПО кроме технологии COM? Ведь COM работает только под Windows. И еще вопрос. Каким образом можно убедить клиента в том что к его Private Key имеет доступ именно крипто-ПО, поставляемое фирмой Крипто-Про? | ||||
| ||||
| На платформах отличных от Windows нет не только СОМ но и нет CryptoAPI :-) Поэтому способ взаимодействия веб-приложения и СКЗИ "КриптоПро CSP" определяется платформой использования и инструментарием разработчика. Если клиент не доверяет программному обеспечению, которое работает у него на компьютере - то Вы никак не убедите его, что "к его Private Key имеет доступ именно крипто-ПО, поставляемое фирмой Крипто-Про". Доверие к окружению - это системная задача, для решения которой СКЗИ "КриптоПро CSP" не предназначена. | ||||
| ||||
| Спасибо. Попробую по-другому. Тому ПО, которое работает на моем компьютере я, конечно, доверять должен. Теперь я - клиент Банка, который предоставляет мне доступ по интернет к своему счету. И при этом мне Банк говорит - вот еще крипто-ПО фирмы Крипто-Про, которое следует установить на моем локальном компьютере. Как мне (как клиенту) получить уверенность в том что это крипто-ПО Ваше? Оно как-то подписано Вами? | ||||
| ||||
| :-) Вы клиент Банка - это означает, что Вы доверили Банку свои ДЕНЬГИ. Почему бы Вам не довериться и словам Банка о происхождении данного ПО? :-) | ||||
| ||||
| Спасибо. Насколько я понял, дело обстоит так: 1. Единственный способ взаимодействия между веб-приложением и крипто-ПО - это СОМ-технология. 2. Крипто-ПО не имеет цифровой подписи изготовителя и потребитель (в случае возникновения конфликтных ситуаций) не сможет доказать в суде тот факт что крипто-ПО разработано Вами. Если это не так, то прошу поправить. | ||||
| ||||
| Вы все неправильно! 1. СОМ - это !!!НЕ!!! единственный способ взаимодействия между веб-приложением и СКЗИ КриптоПро CSP 2. СКЗИ КриптоПро CSP !!!ИМЕЕТ!!! цифровой подписи изготовителя и потребитель (в случае возникновения конфликтных ситуаций) !!!МОЖЕТ!!! доказать в суде тот факт, что копия изделия СКЗИ КриптоПро CSP, установленного на его рабочем месте, разработано ООО "КРИПТО-ПРО" | ||||
| ||||
| Уфф... Зачем же Вы предлагаете верить Банку на слово? Я уже думал махнуть рукой... OK. Какие ДРУГИЕ способы взаимодействия между веб-приложением и крипто-ПО(кроме СОМ) Вы можете указать? | ||||
| ||||
| 1. по рассмотрению в суде... Вы не пробовали почитать АПК? 2. по использованию в веб-приложении без СОМ. Пример: WshShell.Exec | ||||
| ||||
| Наверное я чего-то не понимаю. WSР - это Windows Script Host. На нем можно писать скрипты. Если я правильно понял то Вы предлагаете из веб-приложения вызвать некий скрипт. ОК. Каким образом этот скрипт получит доступ к файловой системе клиента? Насколько я знаю веб-приложение не может этого делать. Если бы это было возможно то, зайдя на любой сайт, я рисковал бы тем, что у меня будет украдена моя личная информация. Прошу пояснить. | ||||
| ||||
| Не знаю как Вы, но мне удается получить доступ к файлам методами типа OpenTextFile :-) | ||||
| ||||
| Правильно ли я понял? Вы можете (без ведома клиента) запустить из браузера скрипт, который получит доступ к файлам на локальном компьютере? Можно кусочек исходного кода? Мне нужно будет показать его коллегам, которые в этом разбираются лучше меня. | ||||
| ||||
| <html> <head> <META name=VI60_defaultClientScript content=JavaScript> <title>WshShell</title> <body> <script language="VBScript"> <!-- Option Explicit Dim oPKCS7Message Set oPKCS7Message = CreateObject("DigtCrypto.PKCS7Message") oPKCS7Message.Load "1.txt.pem", 0, "" Dim status status = -1 status = oPKCS7Message.Verify( 0, "" ) Select Case status Case 0 MsgBox "Status: " & "CORRECT" Case 1 MsgBox "Status: " & "CERT_NO_TRUST" Case 2 MsgBox "Status: " & "UNSUFFICIENT_INFO" Case 3 MsgBox "Status: " & "UNCORRECT" End Select Set PKCS7Message = Nothing --> </script> </body> </html> | ||||
| ||||
| Я опять чего-то не понимаю. В предыдущем сообщении Вы привели пример с WshShell.Exec WSH - это нечто, что есть у всех клиентов (входит в комплект Windows). Хотелось бы получить пример кода, который открывает файл на локальном компьютере с использованием упомянутого WSH. Думаю, что это невозможно. В последнем сообщении Вы используете некий другой объект. Видимо этот объект клиент должен сначала установить у себя. Так? И потом. CreateObject - это оператор, который инициирует СОМ объект! А Вы говорите, что это не СОМ! Нестыковочка у Вас получается... Еще раз задаю вопрос: Какие способы взаимодействия между веб-приложением и Вашим припто-ПО (кроме СОМ) Вы можете предложить? Поставляется ли Ваше крипто-ПО для UNIX платформ? И если да, то какие средства взаимодействия следует использовать в этом случае? | ||||
| ||||
| Вы сначала четко сформулируйте: 1. что такое "веб-приложение"? Может Вы не в курсе, что IIS-приложения, Remote Scripting, Java-апплеты, Servlets, и серверные страницы на языке JSP и т.д. - это тоже веб-приложение? 2. какое наше ПО под термином "крипто-ПО" Вы имеете в виду? У нас нет такой сущности!!! У нас есть СКЗИ, есть реализации SSL/TLS, есть ПАК "КриптоПро УЦ", есть "Атликс-HSM", есть реализации TSP и OCSP и.д. Что Вы имеете ввиду под термином "крипто-ПО"??? 3. Я Вам уже указал еще один способ взаимодействия. Могу указать другие: ActiveX, JCP. Вас устроит? 4. что такое "взаимодействие"? Например, SSL/TLS - это тоже взаимодействие? Я считаю дальнейшее обсуждение не продуктивным и его заканчиваю. Что касается UNIX, то у нас есть СКЗИ "КриптоПро CSP" версии 2.0 для Solaris 8 и СКЗИ "КриптоПро CSP" версии 2.0 для Solaris 9, RH 7 и 9, FreeBSD. У нас в разработке (есть бета-версия) СКЗИ "КриптоПро JCP" для Java, а это уже мульти-платформенность. | ||||
| ||||
| Если я чего-то не понимаю, то так и пишу и прошу пояснить. Если Вы не понимаете сути вопроса, то я готов пояснить еще раз. Веб-приложением я называю то, что клиент видит в своем браузере, когда набирает некий URL. Мы обсуждаем веб-приложения, которые разрабатывают банки для того чтобы их клиенты могли создавать платежные документы и подписывать их своей ЭЦП. Если это понятно, то идем дальше. Под взаимодействием я понимаю последовательность действий, которые происходят между моментом нажатия на кнопку Подписать (в веб-приложении) и моментом получения ЭЦП клиента назад. (Например меня бы устроило объяснения типа: "веб-приложение инициирует СОМ-объект и вызывает его метод. СОМ-объект лезет в файл за Private Key, создает ЭЦП и возвращает веб-приложению"). Вот в таких примерно терминах я и хотел бы получить ответ на следующие вопросы. Под Крипто-ПО я понимаю любое ПО, которое поставляется Вами для генерации ЭЦП (пока меня интересует только этот процесс). Если это понятно, то я повторю свой вопрос. Какой код должен написать разработчик банковского веб-приложения для кнопки Подписать? Один вариант (с использованием СОМ технологии) Вы любезно привели. Насколько я понимаю этот код будет работать только если клиент работает на Windows платформе. В связи с этим я спрашиваю: Какие другие способы взаимодействия между веб-приложением и крипто-ПО Вы можете предложить? (например для UNIX платформы - там нет СОМ-объектов). Если Вы ссылаетесь на Ваши новые разработки, то Вам следует еще и пояснить каким образом их следует использовать разработчикам. Закончить обсуждение когда потенциальный клиент не удовлетворен объяснениями - это по меньшей мере невежливо, а по сути наносит вред фирме где Вы работаете. Вы теряете клиентов. | ||||
| ||||
| Вдогонку. Вы пишете: Могу указать другие: ActiveX, JCP Я просил указать способы, отличные от СОМ. Насколько я знаю, ActiveX - это та же СОМ технология, так что это мимо цели. Что такое JCP? Java Communication Process? Так это комитет. Может быть Вы хотели написать JSP? (Java Server Pages)? Прошу уточнить. И сразу по поводу Java. Если банк пишет свое веб-приложение в виде java-аплета и встраивает в него функции подписания документа (поставляемые Вами), то вознивает одна неприятность. Апплет состоит ка бы из двух частей - банковской (которая обеспечивает создание платежных документов) и Вашей - которая обеспечивает создание ЭЦП и которая должна осуществлять доступ к Private Key клиента. Когда клиент грузит апплет, то ему предлагается довериться этому апплету. Клиент вынужден это сделать. Получается ненормальная ситуация - клиент должен доверять только той части апплета, которая занимается созданием ЭЦП, а вынужден доверять всему апплету - то есть и банковской части. Это неправильно потому что у клиента и банка могут быть антагонистические интересы. Как Вы решаете эту проблему? | ||||
| ||||
| Спасибо за пояснения, но прошу Вас еще уточнить: 1. С Windows платформой разобрались? Тут Вам все понятно? Кстати, СОМ-объект не лезет в файл за Private Key. СОМ вызывает соответствующие функции CryptoAPI, которые вызывают соответствующие функции CSP, которые, в свою очередь, выполняют преобразования с использованием ключей. Но нужно ли это знать программисту??? Проектировщику - да, желательно. 2. Какое веб-приложение Вы имеете в виду? Какой браузер? Internet Explorer, Mozilla, Firefox, Opera, Konqueror или Safari? 3. Какую UNIX-платформу Вы имеете ввиду? Какую операционную систему? Мы "работаем" только на Solaris 8, 9, RH 7 и 9, FreeBSD. А семейство UNIX несколько больше. Общее (ремарка к "Вам следует еще и пояснить каким образом их следует использовать разработчикам")... Наша компания всегда старается делать свои продукты в стандартизованных интерфейсах, поэтому "как следует использовать" описывается в соответствующих архитектурных решениях. Например, на Windows использование описывается в MSDN. Или возьмем JCP... Java-криптоправйдеры являются конструкцией Java Cryptography Architecture и их использование описываются в документации Java 2 SDK. Немного особняком стоят наши СКЗИ для Solaris, RH, FreeBSD т.к. на этих платформах нет своего стандартизованного криптографического API, поэтому мы его сделали в виде библиотек с интерфейсом, совпадающим с MS CryptoAPI. Таким образом, вопрос "способы взаимодействия между веб-приложением и крипто-ПО" нужно перефразировать в вопрос "как обратиться к внешней программе". Ответ на этот вопрос лежит в области программирования, не имеющего отношения к нашему СКЗИ. На второе письмо... Мы не решаем проблемы взаимоотношений клиентов и банков. Мы разработчики СКЗИ и средств ЭЦП. Как проектировать банковское ПО - мы подсказать не сможем. Если нет доверия клиента к ПО предоставляемому банком, то о чем мы вообще говорим?! Может в нем вообще нет никаких вызовов СКЗИ! Нет доверия к клиентскому ПО (апплету) - нет доверия и к СКЗИ. А что такое JCP - на это ответил выше. | ||||
| ||||
| Вы тщательно уклоняетесь от прямых ответов на прямо заданные вопросы. Вот еще раз мои прямые вопросы, оставшиеся без ответа. 1. Если клиент работает под Windows (все равно в каком браузере), то разработчик для обращения к крипто-ПО может воспользоваться двумя средствами (технологиями), а именно: COM (ActiveX - это тоже СОМ) и Java. Так? Другие способы есть? Прошу подтвердить. 2. Если клиент работает под Unix-like (тех, что Вы перечислили выше), то какие технологии (способы) вызова вашего крипто-ПО может (должен) использовать разработчик? СОМ в Юниксе нет. Значит остается только Java. Так? Прошу пояснить. | ||||
| ||||
| Вдогонку... Как "дернуть" lib-у из браузера на не виндовой платформе - я не знаю. Не программист :-) Может другие участники форума подскажут. | ||||
| ||||
| Вдогонку... Как "дернуть" lib-у из браузера на не виндовой платформе - я не знаю. Не программист :-) Может другие участники форума подскажут. | ||||
| ||||
| Вдогонку... Как "дернуть" lib-у из браузера на не виндовой платформе - я не знаю. Не программист :-) Может другие участники форума подскажут. | ||||
| ||||
| Сорри за флуд. Случайно получилось :-( | ||||
Алексей Малинин