Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Об ошибках в iBank 2 13.06.02 11:33 Число просмотров: 2361
Автор: Komlin Статус: Незарегистрированный пользователь
Отредактировано 13.06.02 11:50 Количество правок: 2
|
Привет Влад.
>Это должен доказывать эксперт. Клиенту надо лишь доказать, что спорный софт получен им от
> банка/производителя.
В случае III можно предъявить апплет с возможностью подмены провайдера. Он подписан производителем.
Принципиальной возможности строго доказать изменения или отсуствие таковых в xml невозможно по определению, как и влюбом другом случае
получения неподписанной информации в WEB.( Состояние сервера можно поменять в секунды.)
Но на скандал хватит. Вполне. Собственно никакой подмены на практике может и не быть. Главное, что банку будет также трудно
строго доказать обратное. На его заверения в надёжности орг. контроля всегда мжно ответить: Вы то лицо заинтересованное, за
вину сотрудника если её докажут отвечать Вам.
Здесь классическая ситуцация когда недоказанность вредна обеим сторонам.
> Александр, сейчас Вас безопасники закидают гнилыми
> помидорами.
> Организационные меры всю жизнь были наиболее действенными
> при низких затратах на их реализацию.
IMHO, очень трудно помешать АСУшнику украсть скажем SSL/RSA ключ сервера если он сам его и генерирует.
Чтобы обеспечить нормальный контроль надо посадить на прослушку (видеонаблюдение) как минимум специалиста равного класса.
Например, чтобы понять что он именно злонамеренно модифицирует xml, а не настраивает его надо также хорошо разбираться
в продукте.
Я согласен, что в крупных банках это может быть сделано, но сейчас ещё есть куча мелких.
Не знаю как в Москве, а у нас с десяток таких наберётся.
И таких примеров до кучи. Никто не говорит что оргметоды плохи, но IMHO стойкость подмены ключа правильном алгоритме очень
высока и сама по себе идеальная защита.
Собственно в описанной ситуации доверия внутреннему контролю банка ЭЦП просто не нужна. Вполне хватит симметричного
ключа (или пароля) известного клиенту и асушнику.
>
> Кстати, из начального постинга это не очень ясно.
Это моя вечная проблема. :(
> Хорошо, давайте рассмотрим модель нарушителя в этой атаке.
> 1. Это сотрудник банка.
> 2. Этот банк использует i-bank
> 3. Сотрудник "окучивает" потенциального клиента
> подключиться к системе удаленного управления счетом (или
> знает, что это сделали люди из подразделения "завленкания
> клиентов").
> 4. Клиент идет знакомиться с системой на демо-стенд Бифита.
> 5. Всемогущий сотрудник банка устраивает подмену части кода
> (DLL внешней СКЗИ) с целью внедрить закладку на комп.
> клиента чтобы в дальнейшем, когда клиент подключится
> "по-настоящему", утянуть его секретный ключ ЭЦП.
>
> Начинаем смотреть неувязки.
> 1. Сотрудник банка настолько крут, что может "врезаться" в
> канал между клиентом и Бифитом? Или у него столько денег на
> подкуп тех. персонала сетей?
В предложенном варианте Dll качается с сервера банка.
> 2. Насколько мне известно, на демо-стенде не используется
> внешняя криптография по лицензионным соображениям (Бифит
> может раздавать свой продукт как угодно, но отдавать чужие
> DLL у него права нет). Что и где в этом случае должен
> подменять злоумышленник?
Dll и ссылающаяся на них html-ина лежат в архиве iBank.zip.
> 3. Совсем не факт, что для ознакомления и последующей
> работы будет использован один и тот же компьютер.
Да, не факт. Как и обратное утверждение.
> Соответственно, упираться ради неясного результата никто не
> будет.
Не получиться с одним, получится с другим. Злоумышленнику в приниципе без разницы кого накрывать.
> И еще один принципиальный момент, касающийся
> доказательности etc. Хорошо, пусть будет ssl, пусть будет
> ЭЦП аплета и всей пачки. Клиентский софт позицируется как
> "тонкий", это не "абоненткий пункт сети секретной связи",
> выражаясь армейским языком, на котором ведутся журналы
> работы. Что клиент будет предъявлять в арбитраже?
Клиенту в этом случае идти арбитраж бесполезно. Поэтому его защита и должна лежать на плечах разработчика.
Это я позиции клиента говорю. Может в жизни оно и не так. По сути продукт-то продаётся банку, а их вопрос защищённости
клиента, когда последний не сможет ничего доказать не сильно волнует.
> Типичная
> отмазка нечестного банка: "У нас все нормально, можете
> посмотреть на сервере, а откуда взялась эта кривая DLL на
> компьютере клиента, мы не знаем".
> Нет, все-таки тут надо не мудрить, а принять недорогие орг.
> меры с правильной передачей дистрибутива СКЗИ клиенту
> (договор, контрольне суммы). И клиент будет защищен
> юридически, и нечестному асуизатору в банке (буде такой
> найдется) неповадно будет...
Наверное, но будет ли это уже тонкий клиент? Многие его преимущества (мобильность и др.) пропадут.
Александр.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
