27.06.2005 11:16:04Взаимодействие системы криптования и веб-приложения. Ответов: 24
Алексей Малинин
В системах интернет-банкинга создание платежных документов происходит в веб-приложении (которое работает внутри браузера).
При этом веб-приложение не имеет доступа к файлам и программам клиента.

Криптографическое ПО должно иметь доступ к файлам клиента (для того чтобы достать Private Key).

Каким образом клиент осуществляет подпись платежных документов?

Как при этом взаимодействуют веб-приложение и криптографическое ПО?

Прошу пояснить на концептуальном уровне.

 
Ответы:
27.06.2005 14:35:28Василий
Для поддержки криптографии на стороне клиента (IE) можно использовать COM-объекты (CAPICOM, например, или написать собственные). Закрытые ключи (сертификаты) не обязательно хранить на диске, для этого тот же IE, к примеру, использует хранилище сертификатов, доступ к которому осуществляется с помощью CryptoAPI или того же CAPICOM.
27.06.2005 16:47:48uri
Вот простой пример с 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"
28.06.2005 9:44:44Алексей Малинин
Спасибо.
Есть ли какие-либо другие способы взаимодействия веб-приложения и крипто-ПО кроме технологии COM?
Ведь COM работает только под Windows.

И еще вопрос.
Каким образом можно убедить клиента в том что к его Private Key имеет доступ именно крипто-ПО, поставляемое фирмой Крипто-Про?
28.06.2005 10:04:17uri
На платформах отличных от Windows нет не только СОМ но и нет CryptoAPI :-)
Поэтому способ взаимодействия веб-приложения и СКЗИ "КриптоПро CSP" определяется платформой использования и инструментарием разработчика.
Если клиент не доверяет программному обеспечению, которое работает у него на компьютере - то Вы никак не убедите его, что "к его Private Key имеет доступ именно крипто-ПО, поставляемое фирмой Крипто-Про". Доверие к окружению - это системная задача, для решения которой СКЗИ "КриптоПро CSP" не предназначена.
28.06.2005 10:36:20Алексей Малинин
Спасибо.

Попробую по-другому.

Тому ПО, которое работает на моем компьютере я, конечно, доверять должен.

Теперь я - клиент Банка, который предоставляет мне доступ по интернет к своему счету.

И при этом мне Банк говорит - вот еще крипто-ПО фирмы Крипто-Про, которое следует установить на моем локальном компьютере.

Как мне (как клиенту) получить уверенность в том что это крипто-ПО Ваше? Оно как-то подписано Вами?
28.06.2005 13:30:59uri
:-)
Вы клиент Банка - это означает, что Вы доверили Банку свои ДЕНЬГИ. Почему бы Вам не довериться и словам Банка о происхождении данного ПО? :-)
28.06.2005 13:50:29Алексей Малинин
Спасибо.

Насколько я понял, дело обстоит так:

1. Единственный способ взаимодействия между веб-приложением и крипто-ПО - это СОМ-технология.

2. Крипто-ПО не имеет цифровой подписи изготовителя и потребитель (в случае возникновения конфликтных ситуаций) не сможет доказать в суде тот факт что крипто-ПО разработано Вами.

Если это не так, то прошу поправить.
28.06.2005 13:54:45uri
Вы все неправильно!

1. СОМ - это !!!НЕ!!! единственный способ взаимодействия между веб-приложением и СКЗИ КриптоПро CSP
2. СКЗИ КриптоПро CSP !!!ИМЕЕТ!!! цифровой подписи изготовителя и потребитель (в случае возникновения конфликтных ситуаций) !!!МОЖЕТ!!! доказать в суде тот факт, что копия изделия СКЗИ КриптоПро CSP, установленного на его рабочем месте, разработано ООО "КРИПТО-ПРО"

28.06.2005 14:03:37Алексей Малинин
Уфф...

Зачем же Вы предлагаете верить Банку на слово? Я уже думал махнуть рукой...

OK.

Какие ДРУГИЕ способы взаимодействия между веб-приложением и крипто-ПО(кроме СОМ) Вы можете указать?

28.06.2005 14:19:57uri
1. по рассмотрению в суде... Вы не пробовали почитать АПК?
2. по использованию в веб-приложении без СОМ. Пример: WshShell.Exec
28.06.2005 14:41:15Алексей Малинин
Наверное я чего-то не понимаю.

WSР - это Windows Script Host.
На нем можно писать скрипты.

Если я правильно понял то Вы предлагаете из веб-приложения вызвать некий скрипт.

ОК.

Каким образом этот скрипт получит доступ к файловой системе клиента?

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

Прошу пояснить.
28.06.2005 15:14:56uri
Не знаю как Вы, но мне удается получить доступ к файлам методами типа OpenTextFile :-)
28.06.2005 15:18:28Алексей Малинин
Правильно ли я понял?

Вы можете (без ведома клиента) запустить из браузера скрипт, который получит доступ к файлам на локальном компьютере?

Можно кусочек исходного кода?
Мне нужно будет показать его коллегам, которые в этом разбираются лучше меня.
28.06.2005 19:25:17uri
<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>
29.06.2005 8:59:22Алексей Малинин
Я опять чего-то не понимаю.

В предыдущем сообщении Вы привели пример с WshShell.Exec
WSH - это нечто, что есть у всех клиентов (входит в комплект Windows).
Хотелось бы получить пример кода, который открывает файл на локальном компьютере с использованием упомянутого WSH.
Думаю, что это невозможно.


В последнем сообщении Вы используете некий другой объект.
Видимо этот объект клиент должен сначала установить у себя.
Так?

И потом.

CreateObject - это оператор, который инициирует СОМ объект!

А Вы говорите, что это не СОМ!

Нестыковочка у Вас получается...

Еще раз задаю вопрос:

Какие способы взаимодействия между веб-приложением и Вашим припто-ПО (кроме СОМ) Вы можете предложить?

Поставляется ли Ваше крипто-ПО для UNIX платформ? И если да, то какие средства взаимодействия следует использовать в этом случае?

29.06.2005 9:41:57uri
Вы сначала четко сформулируйте:
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, а это уже мульти-платформенность.


29.06.2005 10:21:19Алексей Малинин
Если я чего-то не понимаю, то так и пишу и прошу пояснить.

Если Вы не понимаете сути вопроса, то я готов пояснить еще раз.

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

Если это понятно, то идем дальше.

Под взаимодействием я понимаю последовательность действий, которые происходят между моментом нажатия на кнопку Подписать (в веб-приложении) и моментом получения ЭЦП клиента назад.
(Например меня бы устроило объяснения типа: "веб-приложение инициирует СОМ-объект и вызывает его метод. СОМ-объект лезет в файл за Private Key, создает ЭЦП и возвращает веб-приложению"). Вот в таких примерно терминах я и хотел бы получить ответ на следующие вопросы.


Под Крипто-ПО я понимаю любое ПО, которое поставляется Вами для генерации ЭЦП (пока меня интересует только этот процесс).

Если это понятно, то я повторю свой вопрос.

Какой код должен написать разработчик банковского веб-приложения для кнопки Подписать?

Один вариант (с использованием СОМ технологии) Вы любезно привели.
Насколько я понимаю этот код будет работать только если клиент работает на Windows платформе.

В связи с этим я спрашиваю:
Какие другие способы взаимодействия между веб-приложением и крипто-ПО Вы можете предложить? (например для UNIX платформы - там нет СОМ-объектов).

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

Закончить обсуждение когда потенциальный клиент не удовлетворен объяснениями - это по меньшей мере невежливо, а по сути наносит вред фирме где Вы работаете. Вы теряете клиентов.
29.06.2005 10:40:16Алексей Малинин
Вдогонку.

Вы пишете:
Могу указать другие: ActiveX, JCP

Я просил указать способы, отличные от СОМ.
Насколько я знаю, ActiveX - это та же СОМ технология, так что это мимо цели.

Что такое JCP?
Java Communication Process?
Так это комитет.

Может быть Вы хотели написать JSP? (Java Server Pages)?

Прошу уточнить.

И сразу по поводу Java.
Если банк пишет свое веб-приложение в виде java-аплета и встраивает в него функции подписания документа (поставляемые Вами), то вознивает одна неприятность.

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

Как Вы решаете эту проблему?
29.06.2005 11:28:19uri
Спасибо за пояснения, но прошу Вас еще уточнить:
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 - на это ответил выше.
29.06.2005 11:55:57Алексей Малинин
Вы тщательно уклоняетесь от прямых ответов на прямо заданные вопросы.

Вот еще раз мои прямые вопросы, оставшиеся без ответа.

1. Если клиент работает под Windows (все равно в каком браузере), то разработчик для обращения к крипто-ПО может воспользоваться двумя средствами (технологиями), а именно: COM (ActiveX - это тоже СОМ) и Java.
Так? Другие способы есть?
Прошу подтвердить.

2. Если клиент работает под Unix-like (тех, что Вы перечислили выше), то какие технологии (способы) вызова вашего крипто-ПО может (должен) использовать разработчик?
СОМ в Юниксе нет.
Значит остается только Java.
Так?
Прошу пояснить.

29.06.2005 11:56:07uri
Вдогонку...
Как "дернуть" lib-у из браузера на не виндовой платформе - я не знаю. Не программист :-) Может другие участники форума подскажут.
29.06.2005 11:56:15uri
Вдогонку...
Как "дернуть" lib-у из браузера на не виндовой платформе - я не знаю. Не программист :-) Может другие участники форума подскажут.
29.06.2005 11:56:28uri
Вдогонку...
Как "дернуть" lib-у из браузера на не виндовой платформе - я не знаю. Не программист :-) Может другие участники форума подскажут.
29.06.2005 11:58:13uri
Сорри за флуд. Случайно получилось :-(