Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Об ошибках в iBank 2 13.06.02 07:47 Число просмотров: 2392
Автор: cybervlad <cybervlad> Статус: Elderman
|
Добрый день, Дмитрий!
> банк. Если банк не способен качественно решать свои
> кадровые вопросы, нанимая нелояльных сотрудников, или же
> периодически не контролируя лояльности своих сотрудников, а
> также создавая потенциальные возможности для
> злоупотреблений - это плохой банк.
Тут предлога не пропущено? ;) Как это банк должен создавать возможности для злоупотреблений?
> В этом случае единственным решением является привлечение
> некоего независимого Сертификационного Центра, который бы
> проводил независимую экспертизу на соответствие заявленным
> возможностям и отвечал бы финансово за выданный клиенту
Речь не о функциях. Даже имеющаяся сейчас сертификация по НДВ, как бы это помягче сказать, вызывает недоумение. Экспертиза утверждает, что в продукте нет недокументированных возможностей. А что, если она их просто не нашла?
Мне кажется, более правильный подход должен заключаться в том, чтобы всегда можно было доказать, что именно получил клиент от производителя/поставщика. Т.е. ЭЦП/контрольные суммы. Не доверяем банку/разработчику - пусть они будут подписаны третьей стороной (нотариусом). Но именно подписаны для фиксации состояния, а не в смысле проверки функционала.
> Вариант с публикациями хеш-функции от дистрибутива также
> влечет проблемы. Встанет вопрос: "Нет ли закладки в утилите
> верификации?" Ок. Выложим исходники. Но потом закрадутся
> сомнения в корректности работы классов java.math.*
А почему обязательно java? Зачем утилита верификации из того же источника? Большинство образов CDROM выкладываются на веб с контрольными суммами MD5 (защита от случайного искажения, ибо злоумышленник и сумму пересчитать не обломится). Чем проверять - личное дело каждого. Можно взять md5sum из pgp или другую утилиту, можно выдрать процедуру расчета MD5 из любого open source софта, можно, в конце концов, самому написать по формальному описанию алгоритма. Главное, чтобы был зафиксирован способ расчета и его результат.
Это самый эффективный по соотношению цена/результат способ.
> Далее вспомним о возможности наличия закладки в
> компиляторе, потом - в среде исполнение (например в
> Java-машине). После - встанет вопрос о наличие закладки в
> ОС, о проверке целостности всей среды.
Это уже для законченных параноиков ;)
> Но в самом конечном итоге мы всё равно придем к давно
> известной аксиоме - К НЕОБХОДИМОСТИ
> ДОВЕРИЯ.
Просто чем дальше углубляемся, тем меньше вероятность закладки. Я полностью с Вами согласен, что чему-то доверять надо. иначе лучше сразу застрелиться. Вопрос в установке планки доверия. На мой взгляд, доверие клиента банковскому софту должно характеризоваться примерно так: "Да, я доверяю банку, софт хороший, в нем нет закладок (один фиг проверить не могу!). Но мне нужна возможность корректного разрешения конфликтной ситуации, когда банк будет утверждать, что поставил мне один софт, а у меня на самом деле другой". Справедливо? Все-таки банк и клиент не до конца доверяют друг другу, иначе они бы применяли симметричные коды подтверждения достоверности, а не ЭЦП.
> Если же банк хочет защититься от недобросовестного
> сисадмина, то он должен организовать комиссию из трех
> человек (лучше из пяти, один из которых - провокатор),
> которые бы при формировании клиентского дистрибутива
> несколько раз совместно проверяли бы дискету, далее
Не очень понял, зачем тут провокатор...
> Использование протола SSL при загрузке дистрибутива с сайта
> исключит возможность подобных атак.
При одном условии: сертификат для SSL "правильный" (Thawte etc). К сожалению, у некоторых банков (не буду делать антирекламу, называя конкретные имена) стоит самоподписанный сертификат, что создает возможность MitM. Впрочем, в Вашем случае, все нормально, это просто уточнение ;)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
