Клиент Банк

← →
Anatoly Podgoretsky © (2006-03-19 21:05) [40]

Reindeer Moss Eater © (19.03.06 21:00) [39]
Странно, а я постоянно пользуюсь и не подозревал, что нельзя, стандартный IE и ни каких дополнительных программ. Работаю с любого компьютера.
Вход возможен по таблице паролей, с помощью PIN калькулятора и с помощью card-reader, в который всовывается аналог паспорта.

← →
Reindeer Moss Eater © (2006-03-19 21:07) [41]

Так я и не говорю, что это технически невозможно.
Я сомневаюсь в практической ценности "не устанавливать ПО"

← →
Reindeer Moss Eater © (2006-03-19 21:15) [42]

Доверять паролю и пину конечно можно.
Но вот закон об ЭЦП у нас есть, а закона о пароле нет.
ЭЦП возможна благодаря криптографии на асиметричных ключах.
И есть практические реализации в виде соответствующего ПО.
Вот в чем суть собственно.

← →
Anatoly Podgoretsky © (2006-03-19 21:27) [43]

ЭЦП у меня находится в паспорте, в чипе

← →
Reindeer Moss Eater © (2006-03-19 21:31) [44]

ЭЦП чего в паспорте?
Личных данных?

А ЭЦП платежных документов?

← →
Anatoly Podgoretsky © (2006-03-19 21:36) [45]

ЭЦП не чего, а моя электронная подпись, выданая мне госудаством. Которой я могу подписывать что угодно, например я подписываю все транзакции с банком. К тому же в отличии от обычной ее не оспорить через суд.

← →
Alexander Panov © (2006-03-19 21:39) [46]

> На том компьютере в кафе необязательно бкдет криптопровайдер,
> подддерживающий нужный вам алгоритм.

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

В таком случае почему не использовать услуги ActiveX, который все это будет выполнять?

> Про ключ я уже говорил. Его недостаточно.

См. выше.

1. Ключи есть на дискете.
2. Функцию подписывания и шифрования будет выполнять ActiveX-компонент.

Теперь все есть, что нужно?

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

Опять же см. выше.

← →
Reindeer Moss Eater © (2006-03-19 21:43) [47]

Видимо речь идет о личном сертификате.
Тогда весь вопрос об используемом там алгоритме подписи и наличии этого алгоритма в предустановленных в windows криптопровайдерах.

Только вот если бы в РФ государство выдавало гражданам такие сертификаты, то алгоритмом ЭЦП там бы был ГОСТ.
А его в предустановленных криптопровайдерах как раз и нет.
И подписать ничего не получится без инсталяции нужного ПО.

← →
Reindeer Moss Eater © (2006-03-19 21:46) [48]

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

Именно.

В таком случае почему не использовать услуги ActiveX, который все это будет выполнять?

У меня вопрос: в чем прелесть постоянного выкачивания кода, который 100% нужен для работоспособности системы?
И почему считается большим счастьем, если каждый раз приходится качать ActiveX, если можно скачать один раз дистрибутив и инсталировать его?

Вопрос о грамотности и надежности собственной реализации криптоалгоритмов внутри ActiveX пока опускаем.

← →
Anatoly Podgoretsky © (2006-03-19 21:47) [49]

Reindeer Moss Eater © (19.03.06 21:43) [47]
Это в случае ID card, в случае PIN калькулятора или таблицы паролей, сертификат выдается банком на сеанс.

← →
Anatoly Podgoretsky © (2006-03-19 21:50) [50]

Reindeer Moss Eater © (19.03.06 21:43) [47]
Да забыл про сертификат, сертификат выдается государством, получено от Verisign и открытый ключ хранится у Verisign. ЭЦП вроде только в чипе. Сертификат человека тоже только в чипе.
То есть в чипе есть три сертификата, удостоверение личности, ЭЦП и закрытый ключ.

← →
Alexander Panov © (2006-03-19 21:51) [51]

> У меня вопрос: в чем прелесть постоянного выкачивания кода,
> который 100% нужен для работоспособности системы?
>И почему считается большим счастьем, если каждый раз приходится качать
>ActiveX, если можно скачать один раз дистрибутив и инсталировать его?

Уже было указано: в отсутствии необходимости таскать с собой дистрибутив и работать с электронными платежами без установки дополнительного ПО.

> Вопрос о грамотности и надежности собственной реализации
> криптоалгоритмов внутри ActiveX пока опускаем.

Почему опускаем?
Наши программисты ничем ни хуже программируют, чем зарубежные.

РВС-Криптопровайдер - Это средство криптографической защиты, полностью интегрированное в операционную систему Windows 2000/XP. Поддерживаются криптографические алгоритмы ГОСТ для шифрования и подписания электронной информации на базе криптографического интерфейса фирмы "Микрософт" (Microsoft CryptoAPI 2.0). Использование криптопровайдера позволяет получать в любых продуктах поддерживающих интерфейс Microsoft работу с сертифицированными российскими алгоритмами. РВС-Криптопровайдер распространяется бесплатно.

← →
Alexander Panov © (2006-03-19 21:53) [52]

в посте [51] просто приведен пример реализации криптопровайдера российскими разработчиками.

← →
Reindeer Moss Eater © (2006-03-19 21:53) [53]

>сертификат выдается банком на сеанс.

Сертификат банка, на котором клиент шифрует данные, может жить в одном сеансе. И может быть каждый раз новым. Так как используется только для сокрытия данных
Но сертификат, которым клиент подписывает документ должен быть постоянным. Так как эт неотрицание авторства и прочие тонкости.
Хотя здесь дело вкуса. У нас в приложении к договору распечатывались hex представления открытых ключей клиента (они в сертификатах как раз живут). И клиент не мог в одностороннем порядке менять свои сертификаты.

← →
Reindeer Moss Eater © (2006-03-19 21:55) [54]

в посте [51] просто приведен пример реализации криптопровайдера российскими разработчиками

Там речь про криптопровайдер.
А он именно инсталируется в систему. И в ActiveX его не запихать. Разве что вызовы его функций.

← →
Alexander Panov © (2006-03-19 22:54) [55]

> Reindeer Moss Eater © (19.03.06 21:55) [54]
>
> в посте [51] просто приведен пример реализации криптопровайдера
> российскими разработчиками
>
> Там речь про криптопровайдер.

А кто мешает реализовать функции криптопровайдера в AciveX?

← →
Reindeer Moss Eater © (2006-03-19 23:10) [56]

Да ничто не мешает.
Есть даже COM обертка вокруг CryptoApi - CAPICOM.
Только если нет установленного провайдера, то нет и вызова его функций.

← →
Alexander Panov © (2006-03-19 23:13) [57]

> Только если нет установленного провайдера, то нет и вызова
> его функций.

Так я о чем речь веду - необязательно для использования функций шифрования иметь в системе криптопровайдер вообще.
Можо все реализовать в одном модуле. Даже если это будет DLL, лежащая на дискетке.

PS.

А вообще, думаю, что спор ни о чем.

И еще соображения на этот счет.
Допустим что никто нас не ограничивает в выборе средств защиты и мы решили воспользоваться встроенными средствами.
Замечательно. Все работает.

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

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

Так я о чем речь веду - необязательно для использования функций шифрования иметь в системе криптопровайдер вообще.
Можо все реализовать в одном модуле. Даже если это будет DLL, лежащая на дискетке.

Согласен. Я сам использовал в одной из версий библиотеки от LanCrypto.
Они соответствовали спецификации CryptoAPI, но не были оформлены в качестве провайдера. Я их использовал на уровне импорта функций.

Но:
1.Многие производители криптопровайдеров так же допускают использование своих библиотек напрямую, минуя CryptoAPI. Например Crypto-PRO(тоже российская разработка как и LanCrypto). Но здесь все упрется в тот уровень сервиса, который можно получить от библиотеки работая напрямую. В случае с CryptoPro это только базовый функционал.
Никакой поддержки сертификатов, хранилищ и цифровых конвертов.
Все руками.

2.Библиотеки все равно надо выкачивать. Так лучше качнуть один раз дистрибутив всего клиента и забыть.

Reindeer Moss Eater © (19.03.06 23:20) [58]
А давай отделим ONLINE/OFFLINE от прочего.

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

Стоит называть это клиент-сервер, а не онлайн/оффлайн и тогда все встает на свои места.

Зачем нужна локальная, не безопасная (офлайновая) версия связи с банком.

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

Reindeer Moss Eater © (19.03.06 23:51) [61]
Это как? Как может банк делать расчеты без платежных документов, по своей воле что ли :-)

У клиентов есть локальная БД документов.
Те документы, которые подписаны, уезжают в банк.
Все остальные в банке не нужны.
Ваша схема работы предполагает, что эти "черновики" тоже в банке живут.
Вот я и говорю, что не все на это согласны.
Хотя это и проще.
Не надо синхронизировать статусы там и тут.

Reindeer Moss Eater © (19.03.06 23:57) [63]
И в банке появляется документ, тоже самое и в электронном обмене с банком.
При том акцептирование может проводиться руководителем или акционерами по правилам задаваемым клиентом. Например некоторые платежи акцептируются по весу, а у разных людей разный вес.
Моя схема не предполагает, что в банке есть какие то черновики, в банке есть только платежные документы.

Клиент Банк Найти похожие ветки