Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Об ошибках в iBank 2 13.06.02 15:36 Число просмотров: 2235
Автор: cybervlad <cybervlad> Статус: Elderman
|
> доказать, что спорный софт получен им от
> > банка/производителя.
> В случае III можно предъявить апплет с возможностью подмены
> провайдера. Он подписан производителем.
Александр, но мы же договорились, что в случае применения "внешней" криптографии все, что не входит в аплет, поставляется клиенту на дискете, по договору с указанием контрольных сумм. Согласно требованиям по безопасности СКЗИ на клиентском рабочем месте должен быть обеспечен контроль целостности среды.
> получения неподписанной информации в WEB.( Состояние
> сервера можно поменять в секунды.)
> Но на скандал хватит. Вполне. Собственно никакой подмены
> на практике может и не быть. Главное, что банку будет также
Опять запутались ;) Поехали с начала.
О какой подмене речь? DLL получена пользователем на дискете. Аплет подписан. Или какую именно DLL загружать прописывается в XML?
> > Организационные меры всю жизнь были наиболее
> действенными
> > при низких затратах на их реализацию.
> IMHO, очень трудно помешать АСУшнику украсть скажем SSL/RSA
> ключ сервера если он сам его и генерирует.
1. Если админ сам генерирует и ставит ключ, то это не банк, а сарай.
2. Помешать можно.
> Чтобы обеспечить нормальный контроль надо посадить на
> прослушку (видеонаблюдение) как минимум специалиста равного
> класса.
Зачем видеонаблюдение и прослушка? Изменения в сервер вносятся не каждый день. Все это должно делаться коллегиально. Никто из админов не должен иметь возможность внести изменения на сервер единолично.
> Я согласен, что в крупных банках это может быть сделано, но
> сейчас ещё есть куча мелких.
Ну да. Можно смело покупать продукт в нормальном магазине, а можно пойти в сомнительную лавочку. Действительно, каждый выбирает сам, но о последствиях пусть тоже думает сам.
> Собственно в описанной ситуации доверия внутреннему
> контролю банка ЭЦП просто не нужна. Вполне хватит
> симметричного
> ключа (или пароля) известного клиенту и асушнику.
Ну конечно. По нормальной схеме асуизатор к "боевой системе" вообще подходить не должен.
> > Начинаем смотреть неувязки.
> > 1. Сотрудник банка настолько крут, что может
> "врезаться" в
> > канал между клиентом и Бифитом? Или у него столько
> денег на
> > подкуп тех. персонала сетей?
> В предложенном варианте Dll качается с сервера банка.
В каком? В демо?
> Клиенту в этом случае идти арбитраж бесполезно. Поэтому его
> защита и должна лежать на плечах разработчика.
Не согласен. Разработчик (Бифит) делает прикладной продукт ( i-bank), предусматривая в нем интерфейс с внешним криптографическим модулем. Целостность всей этой байды должна обеспечиваться СЗИ от НСД. Целостность кода аплета - ЭЦП и сертификатом Thawte.
> > меры с правильной передачей дистрибутива СКЗИ клиенту
> > (договор, контрольне суммы). И клиент будет защищен
> > юридически, и нечестному асуизатору в банке (буде
> такой
> > найдется) неповадно будет...
>
> Наверное, но будет ли это уже тонкий клиент? Многие его
> преимущества (мобильность и др.) пропадут.
Удобство и безопасность всегда в противофазе. "Истинно тонкий" и "абсолютно мобильный" клиент по определению не может быть безопасным, хотябы потому, что он исполняется в недоверенной среде. Если человек хочет безопасности, должен смириться с ограничением мобильности (необходимость инсталляции хотябы критичных компонентов). Хочет работать из интернет-кафе или просто с чужого оборудования - пусть понимает, что это опасно. Это почти как в сексе: либо один партнер (безопасно), либо разнообразие (со всеми вытекающими последствиями ;)).
|
|
|
подробно о проекте
Анализ криптографических сетевых...
