Security Lab



Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти  
Форум » Для программистов и разработчиков » Криптография и защита информации
Страницы: 1
RSS
Информационная защита систем моментальных платежей
 
#1
Это нравится:0Да/0Нет
13.05.2010 15:36:42
Привет,
хочу проконсультироваться с сообществом по вопросу, указанному в теме.
Так получилось, что это к тому же и тема моего диплома, хотя не совсем по теме моей кафедры.

Собственно мне нужно придумать программку, обосновать выбор средств защиты, причем желательно с уклоном в математику.

Сейчас я вижу это так.
Есть система платежей. В ней регистрируются дилеры (которые будут принимать платежи) и в ней же регистрируются провайдеры (которые будут получать платежи).
Я делаю веб-сервисы у провайдера и у системы платежей.
Дилер, получив деньги, кидает запрос вебсервису системы платежей (подписанный, по ssl), система платежей обращается к веб сервису провайдера по такой же схеме и отдает ответ. Результаты транзакций пишу в бд.

Вопросы такие:
какие алгоритмы выбрать для генерации ключей? Писать ли генератор самому или воспользоваться например pgp?
по какой схеме производить обмен ключами? Как хранить ключи дилеров?

И еще такой вопрос, нужны ли мне межстетевые экраны и прочие штуки для информационной защиты? Если с криптографией и программированием я хоть немного знаком, то эта часть для меня совсем темный лес.

Спасибо за внимание, буду ждать ответов )
 
 
 
#2
Это нравится:0Да/0Нет
13.05.2010 18:58:43
Раз это всего лишь диплом, то чем больше фитч вы вставите тем лучше :) .
 
 
 
#3
Это нравится:0Да/0Нет
13.05.2010 19:50:28
Ну вот мне интересно, чего я могу накрутить помимо криптографии. И к тому же, чтобы люди разбирающиеся в теме не нашли серьезных дыр )
 
 
 
#4
Это нравится:0Да/0Нет
14.05.2010 10:21:43
Цитата
нужны ли мне межстетевые экраны и прочие штуки для информационной защиты? Если с криптографией и программированием я хоть немного знаком, то эта часть для меня совсем темный лес.

А чего тут темного-то? Вот, представьте, Вы сделали невскрываемый замок и поставили его на картонную дверь... :)
 
 
 
#5
Это нравится:0Да/0Нет
14.05.2010 14:30:47
Цитата
Вопросы такие:
какие алгоритмы выбрать для генерации ключей? Писать ли генератор самому или воспользоваться например pgp?
по какой схеме производить обмен ключами? Как хранить ключи дилеров?
eToken
 
 
 
#6
Это нравится:0Да/0Нет
14.05.2010 15:08:33
Хороший ответ )
Темный, потому что не знаю всех аппаратных технологий и не знаю, как из применять.
Ну например, я поставлю брендмауэр и закрою все порты кроме 443, который оставлю под хттпс. Ограничу доступ недоверенным ip. Что-то еще клевое я могу им сделать? Ну еще https могу пустить через VPN, хотя тоже не очень понимаю, какие это даст преимущества.

Вообще, каким образом, злоумышленник будет выбивать картонную дверь без этих вещей?

OBDOLBANIY, да про eToken знаю, но на них пусть дилеры хранят свои секретные ключи, а мне нужно еще как-то базу их публичных организовать.
 
 
 
#7
Это нравится:0Да/0Нет
14.05.2010 17:24:14
Цитата
Yossarian пишет:
Темный, потому что не знаю всех аппаратных технологий и не знаю, как из применять.
Аппаратные технологии следует применять в последнюю очередь, в силу их полной негибкости и неремонтопригодности.

Цитата

Ну например, я поставлю брендмауэр и закрою все порты кроме 443, который оставлю под хттпс. Ограничу доступ недоверенным ip. Что-то еще клевое я могу им сделать? Ну еще https могу пустить через VPN, хотя тоже не очень понимаю, какие это даст преимущества.
Часть типов icmp можно зафильтровать. Подумать о том, что делать в случае ddos-а этого канала... Защититься от подмены шлюза...

Цитата

Вообще, каким образом, злоумышленник будет выбивать картонную дверь без этих вещей?
Сделают выемку серверов под предлогом возможности хранения на них детской порнографии.

Цитата

про eToken знаю, но на них пусть дилеры хранят свои секретные ключи, а мне нужно еще как-то базу их публичных организовать.
Не нужно. При авторизации по ssl - проверяется CA и правильность подписи сертификата клиента. Публичные сертификаты - вещь не секретная, их специально воровать никому не нужно (разве что получить список клиентов). Вот базу того, что заливается дилерам на e-token-ы (файлы pkcs12) - надо держать отдельно на флэшке в сейфе, и работать с флэшкой под линуксом, желательно не подключенным к сети.
 
 
 
#8
Это нравится:0Да/0Нет
14.05.2010 17:54:42
Код
Аппаратные технологии следует применять в последнюю очередь, в силу их полной негибкости и неремонтопригодности.


Аппаратные технологии надежнее будут...
 
 
 
#9
Это нравится:0Да/0Нет
14.05.2010 17:54:46
Andrey Y. Ostanovsky, спасибо за полезные комментарии.

Я просто думал обойтись без CA и сертификатов, тогда была возможность того, что злоумышленник заменит в базе публичный ключ дилера на свой и сможет совершать транзакции от имени дилера. Если делать с сертификатами, то задача у него намного усложнится (придется получить сертификат на имя дилера), но я все равно не уверен, что тут нет уязвимости.

Цитата
Andrey Y. Ostanovsky пишет:
Вот базу того, что заливается дилерам на e-token-ы (файлы pkcs12) - надо держать отдельно на флэшке в сейфе, и работать с флэшкой под линуксом, желательно не подключенным к сети.
Тут не понял, зачем мне вообще хранить то, что у дилеров на e-token'ах? Я понимал это так, дилер в CA получает сертификат и закрытый ключ, сертификат передает мне (кстати каким образом? пока думаю только лично при оформлении договора), а закрытый ключ или тот же pkcs12 сохраняет на etoken'е. Потом, чтобы совершить транзакцию, запускает мою прогу, логинется по etoken'у, вводит кодовую фразу и работает. То есть, вроде и мне дилерские закрытые ключи не нужны и дилерам придется засовывать етокены в компы с виндой и интернетом  :)
 
 
 
#10
Это нравится:0Да/0Нет
14.05.2010 17:56:03
Цитата
Дилер, получив деньги, кидает запрос вебсервису системы платежей (подписанный, по ssl), система платежей обращается к веб сервису провайдера по такой же схеме и отдает ответ. Результаты транзакций пишу в бд

БД... на отдельный сервак от приложений... за отдельный ФВ
 
 
 
#11
Это нравится:0Да/0Нет
14.05.2010 18:35:40
Цитата
Yossarian пишет:
БД... на отдельный сервак от приложений... за отдельный ФВ
А что это дает, от каких атак защищает? То есть если бы я реальную делал, то принял бы как есть, а тут придется каждое действие обосновывать ))
 
 
 
#12
Это нравится:0Да/0Нет
15.05.2010 18:39:40
Цитата

Тут не понял, зачем мне вообще хранить то, что у дилеров на e-token'ах? Я понимал это так, дилер в CA
У нас дилеры получают уже готовые ключи со всем содержимым. Соответственно, базу храним мы у себя в сейфе. Это, дополнительно, защищает от размножения одного и того же ключа самим дилером (чаще его недобросовестными содтрудниками).
Цитата

получает сертификат и закрытый ключ, сертификат передает мне (кстати каким образом? пока думаю только лично при оформлении договора), а закрытый ключ или тот же pkcs12 сохраняет на etoken'е. Потом, чтобы совершить транзакцию, запускает мою прогу, логинется по etoken'у, вводит кодовую фразу и работает. То есть, вроде и мне дилерские закрытые ключи не нужны и дилерам придется засовывать етокены в компы с виндой и интернетом  
Таких ужасов - не требуется. :) Пользователь  ставит у себя на компьютере драйвера e-token-а, после чего может авторизоваться с помощью сертификатов токена и браузера firefox - на станадртном web-сервере, типа апача, или nginx. С серверной стороны, для авторизации пользователя, нужен только CA, которым подписан сертификат пользователя.  Т.е. никаких дополнительных программ писать не надо!
 
 
 
#13
Это нравится:0Да/0Нет
16.05.2010 13:37:34
Цитата
Andrey Y. Ostanovsky пишет:
Пользователь ставит у себя на компьютере драйвера e-token-а, после чего может авторизоваться с помощью сертификатов токена и браузера firefox - на станадртном web-сервере, типа апача, или nginx. С серверной стороны, для авторизации пользователя, нужен только CA, которым подписан сертификат пользователя. Т.е. никаких дополнительных программ писать не надо!

Мне все равно нужна программа, которая формирует передаваемое сообщение. Я так понял, вы просто таким образом устанавливаете https соединение. Но в рамках этого соединения, мне нужно принимать запросы дилеров. Они же должны быть подписаны эцп.
 
 
 
#14
Это нравится:0Да/0Нет
16.05.2010 18:59:36
Цитата
Yossarian пишет:
Мне все равно нужна программа, которая формирует передаваемое сообщение. Я так понял, вы просто таким образом устанавливаете https соединение. Но в рамках этого соединения, мне нужно принимать запросы дилеров. Они же должны быть подписаны эцп.
Вы установите соединение и посмотрите - что там в переменных среды может отдать тот же апач. :)  Данные о том, кто пришел, у нас уже есть. А если нужно показательно подписывать - то это проще делать почтой.
 
 
 
#15
Это нравится:0Да/0Нет
16.05.2010 20:35:49
Andrey Y. Ostanovsky,
Я правильно понял, что вы хотите сказать, что для отправки клиентом (дилером) веб-сервису системы платежей сообщения: "сними с моего счета n рублей и скажи мегафону положить их на телефон m", достаточно просто https соединения?
 
 
 
#16
Это нравится:0Да/0Нет
17.05.2010 10:06:36
Цитата
Yossarian пишет:
что вы хотите сказать, что для отправки клиентом (дилером) веб-сервису системы платежей сообщения: "сними с моего счета n рублей и скажи мегафону положить их на телефон m", достаточно просто https соединения?
Большинству банк-клиентов - достаточно, т.е. авторизовавшийся пользователь может проводить операции. При авторизации клиента по ssl-сертификату - процесс повторяется при запросе каждого элемента, а не один раз при входе, как это делается при логине/пароле, так что, оно достаточно надежно.

Ну, можете еще ввести, как у альфа-банка, отправку дилеру одноразового "кода авторизации платежа" через sms - но это будет замедлять каждую операцию секунд на 30. Либо делать такую отправку при сумме платежа, большей N рублей, где N - величина настраиваемая.
 
 
 
Страницы: 1
Читают тему