Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Об ошибках в iBank 2 14.06.02 05:07 Число просмотров: 2195
Автор: Komlin Статус: Незарегистрированный пользователь
|
> Александр, но мы же договорились, что в случае применения
> "внешней" криптографии все, что не входит в аплет,
> поставляется клиенту на дискете, по договору с указанием
> контрольных сумм. Согласно требованиям по безопасности СКЗИ
> на клиентском рабочем месте должен быть обеспечен контроль
> целостности среды.
Совершенно с Вами согласен, Влад. Процедура передачи внешних СКЗИ должна быть надёжной.
В принципе не так уж Важен конектретный механизм. Лучше всего - передача на внешнеем носителе CD-R
с фиксацией контрольных сумм, но допустима и подпись в апплете.
Проблема iBank описанная под номером III состоит в том, что в автоматически, без ведома и участия клиента,
подключается находящаяся на сервере неподписанная криптобиблиотека. Для этого достаточно чуть-чуть
изменить HTML -файл.
> Опять запутались.Опять запутались ;) Поехали с начала.
> О какой подмене речь? DLL получена пользователем на дискете. Аплет подписан.
Влад, речь идёт о другой ошибке, за # III. Она позволяет подключать библиотеки непосредственно
с сервера банка а не с машины клиента. Соответственно никакого ПО клиенту передавать не надо.
>Или какую именно DLL загружать прописывается в XML?
Почти так. Банк имеет право подключить свою JAR библиотеку с сервера, указав её имя в XML файле на сервере.
Кончено, Java это не DLL,захватитть машину она не сможет, а вот "засветить" секретный ключ или нестойко
сгенерировать его - пожалуйста
Поэтому я и считаю эту недоработку самой серьёзной из всех.
IMHO, Нельзя основывать защищённость клиента исключительно на оргметодах банка. В противном случае технология
цифровой подписи просто не нужна. В ней нет смысла если банк имеет доступ к секретному ключу.
Более грамотно и полно эта мысль изложенна на bankir.ru
Возвращаемся к ошибке II.
> > В предложенном варианте Dll качается с сервера банка.
> В каком? В демо?>
В инсталляте бифит. В предисловии написанно, что на сервере лежит подлинный инсталлят, отличающийся
лишь отсуствием лицензии.
> Не согласен. Разработчик (Бифит) делает прикладной продукт
> ( i-bank), предусматривая в нем интерфейс с внешним
> криптографическим модулем. Целостность всей этой байды
> должна обеспечиваться СЗИ от НСД. Целостность кода аплета -
> ЭЦП и сертификатом Thawte.
Только апплету надо предупреждать клиента, когда вместо заявленных стандартных
модулей бифит или Базис-Защита подключается совсем другой (это снова об ошибке III).
Ведь клиент вправе знать с чьей крипто он работает и иметь возможность проверить её подлинность?
Или я ошибаюсь?
> Удобство и безопасность всегда в противофазе. "Истинно
> тонкий" и "абсолютно мобильный" клиент по определению не
> может быть безопасным, хотябы потому, что он исполняется в
> недоверенной среде. Если человек хочет безопасности, должен
> смириться с ограничением мобильности (необходимость
> инсталляции хотябы критичных компонентов). Хочет работать
> из интернет-кафе или просто с чужого оборудования - пусть
> понимает, что это опасно. Это почти как в сексе: либо один
> партнер (безопасно), либо разнообразие (со всеми
> вытекающими последствиями ;)).
Не знаю, здесь от подмены библиотеки защититься очень легко встроив XML (и при желении DLL) в подписанную
часть апплета. Что и сделано в новой версии.
Александр.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
