Надежность использования сетевых ключей (EL-NET)

Общие вопросы по защите программного обеспечения

Надежность использования сетевых ключей (EL-NET)

Сообщение Lithium™ » Чт, 10 июл 2008 10:47

Несетвые ключи мы изучили, протестили, внедрили - к ним претензий кроме отсутствия удобного GUI для разработчика нет. Дошло дело до сетевых....
Не имею времени и желания углубиться в хакерские деяния и протестировать самостоятельно сетевой ключ SenseLock на такой предмет уязвимости:
1. Покупается ключ с минимальным количеством лицензий.
2. Создается некий эмулятор-посредник между ключом и приложением.
В процессе эксплуатации программы к ключу коннектится только один эмулятор-посредник, соответственно захватывает только одну лицензию. Все остальные N пользователей подключаются к эмулятору-посреднику, он передает Настоящему Ключу запросы пользователей и ID своей лицензии, пользователям возвращает результат обработки и опять таки ID своей лицензии.
В итоге "все работают, все счастливы".

На мой взгляд такого рода взлом реален и не дорогой.

Если я ошибаюсь, просьба предоставить убедительные опровержения.
Слова "не надо нервничать" хорошо помогают привести человека в нормальное состояние бешенства.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение svp » Чт, 10 июл 2008 17:58

Эдакий прокси-сервер лицензий получается.=).
Мне видится следующий способ существенно усложнить такого рода обход лицензионных ограничений:
1. Весь сетевой трафик защиты необходимо шифровать несимметричными алгоритмами. При этом закрытые ключи лежат на аппаратном ключе, а открытые известны клиентам.
// не следует забывать: то, что известно клиентам -- известно и злоумышленникам.

2. К аргументам каждой защищенной функции нужно добавить ещё один аргумент -- номер вызова в пределах сессии. Ключ должен хранить последний (максимальный) номер, пришедший от клиента и в случае прихода пакета аргументов с номером, меньшим, либо равным, текущему, отказывать в лицензии. Такая ситуация, очевидно, возникнет, из-за того, что счетчики на клиентах локальные и независимые друг от друга.

Усложнение взлома здесь состоит в том, что придётся вмешиваться в код клиентов и принудительно синхронизировать их счетчики пакетов на всех машинах централизованно. Это уже не тривиальная задача, хотя она и разрешима.

Пример: злоумышленники помимо своего прокси делают патчи клиентов подменяя адрес функции выдачи текущего номера пакета. Функция обращается к выдеоенному серверу выдачи номеров пакетов (физически, м.б. к тому же прокси но через другой порт=).

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

Можно придумать ещё меры противодействия подобным атакам. Например выбрать защищенные фрагменты кода из областей инициализации и финализации сеанса работы клиента. При двух подряд вызовах функций инициализации ключ должен отказать в лицензии.

Короче, фантазию применять всё же придётся. Тут не может быть панацеи.

Интересно что по поводу такой атаки думают представители Senselock.
svp
 
Сообщения: 15
Зарегистрирован: Ср, 11 июн 2008 17:40

Сообщение Ivan Petrov » Чт, 10 июл 2008 19:57

Данная схема атаки применятеся для спутникого телевидения.
Называется кард-шаринг.

Лечиться двумя способами:
1. Загрузкой процессора смарткарты или канала связи близкой к 100%
2. Схемой предложенной SVP. Введением синхронизированного счетчика-рандомизатора при шифровании трафика. Шифрование в этом случае ассиметричное, а само положение счетчика в ПО должно быть максимльно защищено от внедряемых процессов (виртуалка + многократное дублирование).
Ivan Petrov
 
Сообщения: 30
Зарегистрирован: Пн, 30 апр 2007 11:53

Сообщение Lithium™ » Пт, 11 июл 2008 07:06

svp писал(а):Короче, фантазию применять всё же придётся. Тут не может быть панацеи.


Спс за советы! На первый взгляд задача разрешимая... но не для простых смертных) буду разбираться...


svp писал(а):Интересно что по поводу такой атаки думают представители Senselock.


мне вот тоже интересно... :)
Слова "не надо нервничать" хорошо помогают привести человека в нормальное состояние бешенства.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение Евгений » Пт, 11 июл 2008 17:45

Уважаемый Lithium и Svp,

Как вы совершенно правильно отметили - такая атака вполне осуществима.

Реализация с асимметричными алгоритмами представляется мне мало реальной ввиду большого объема работы и общей ненужности, а вот идея счетчиков, на мой взгляд, очень хороша.
На асимметричных алгоритмах можно, конечно, попробовать построить протокол обмена сессионными ключами, но взломщик сможет пропатчить клиентское приложение, хотя сильно усложнить задачу можно.

Я бы сказал так, 100% решения проблемы не будет. Если хотите 100% надежность, придется раздавать каждому пользователю по локальному ключу!
Seculab co-founder
Евгений
 
Сообщения: 23
Зарегистрирован: Ср, 11 апр 2007 16:51

Сообщение Lithium™ » Пн, 14 июл 2008 08:30

Евгений писал(а):Если хотите 100% надежность, придется раздавать каждому пользователю по локальному ключу!

Поясню, мы занимаемся разработкой только многопользовательского ПО, ценовая политика не грабительская с расчетом заинтересовать клиентов из провинций. И для нас самым серьезным является увеличение стоимости одной лицензии. Кроме того есть еще целый ряд неудобств...

Евгений писал(а):а вот идея счетчиков, на мой взгляд, очень хороша.

Со счетчиками тоже не все гладко. Опять-таки, "прокси-сервер лицензий" может подменять аргументы функций, устанавливая свои значения счетчиков. Это даже без патча клиентских программ.
Как Евгений правильно заметил, с сетевым вариантом 100% защиты не будет (в части утери лицензий).

В виду этого хотелось бы услышать мнение участников форума по поводу такой схемы защиты:
1. Имеется серверная часть, естесственно жизненно необходимая для работы клиентских приложений.
2. На сервере стоит единственный несетевой ключ SenseLock со встроенным таймером, к примеру на полгода. Отсчет времени ведется с помощью (из топика "Порча электронных ключей")
Anton писал(а): заставить приложение всётаки обращаться к ключу хотя-бы раз в пять минут, ключ не получив очередного обращения (с текущим системным временем) может просто "заснуть" и потребовать перезапуска приложения.

В ключ вынесена часть серверных функций.
3. Клиентские приложения обращаются к серверу.
4. Раз в полгода (период времени) перепрошиваем заказчику ключ или даем новый в обмен на старый.

Особенность данного способа - невозможность использовать "конкурентные лицензии". ПО продавать на общее количество рабочих мест которые будут с ним работать.
На первый взгляд плохо - заказчик ПО может купить меньше "неконкурентных" лицензий, чем нужно. Но разработчик осуществляет контроль при продлении ключа. Опять-таки есть несколько вариантов:
- выезд специалиста к заказчику для продления ключа. на месте можно определить активность использования ПО и количество пользователей, проанализировав оставленный след их работы. В случае обмана со стороны заказчика не продлевать ключ пока не будут докуплены недостающие лицензии.
- в ключе реализовать собственный счетчик (энергонезависимый) сколько разных пользователей обращались к тем или иным функциям (возможно связанных с модулями). При получении ключа для перепрошивки эти счетчики считываются разработчиком для проверки.
Слова "не надо нервничать" хорошо помогают привести человека в нормальное состояние бешенства.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение Евгений » Вт, 15 июл 2008 21:58

Уважаемый Lithium,

Метод, который Вы описали, кажется мне излишне затратным. Выезд специалиста, контроль логов, это действительно проблематично, так как, во-первых, надо найти человека, который будет ездить и анализировать, оплачивать командировки, и потом анализ... Если есть человеческий фактор - система автоматически становится ненадежна.
Локальные ключи кажутся лично мне менее затратным и более надежным вариантом.

Во-вторых, зачем использовать методом отсчета времени если есть ключ с таймером реального времени. Усложнять тут нечего.

В-третьих, если Вы сами пишете сервер лицензий, обновляйте его вместе с протоколом при смене версии. Естественно, еще меняете либо ключ целиком, либо прошивку. Тут, в отличии от других ключей, пространство для маневра действительно велико. При обновлении клиент, в итоге, получит больше убытков от простоя ранее отпираченных мест прежде чем дождется обновления менеджера лицензий.

Используйте асимметричную криптографию и контроль целостности публичных ключей в программе для реализации протокола обмена.
Seculab co-founder
Евгений
 
Сообщения: 23
Зарегистрирован: Ср, 11 апр 2007 16:51

Сообщение Lithium™ » Ср, 16 июл 2008 08:28

Уважаемый Евгений,

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

Соглашусь, что "Если есть человеческий фактор - система автоматически становится ненадежна". Тем не менее, считаю что этот фактор имеет место при любом раскладе. Но это уже другая тема, если ее обсуждать, защита о которой идет речь на форуме теряет смысл... :)

С таймером дествительно не стоит изобретать. У SenseLock есть все необходимое.

p.s. Топик все-таки о надежности сетевого варианта ключа :wink: , с локальными (см. выше) вопросов нет.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение Евгений » Ср, 16 июл 2008 09:45

Уважаемый Lithium,

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

Как вариант предлагаю следующее: вмешивать в протокол какой-либо случайный идентификатор, пусть это будет случайное число, а в ключе просто отслеживать одновременное количество подключений с разными числами. Если оно превышено, не отбрасывать новые, а делать внутреннюю заметку о превышении, которую уже можно будет получить при обновлении ключа, либо при работе сотрудника. Это если хотите решить этот вопрос через ключ.

Еще есть вариант записи подобных данных в лог, при этом осуществляя контроль его аутентичности с помощью ЭЦП в ключе.

А еще как вариант, храние базу данных пользователей в ключе. Имя -пароль. Тогда для правильности работы системы, даже с точки зрения последующего анализа транзакций, опасно будет загонять двух людей под одним логином. При этом, количество пользователей может быть любым, но одновременно будут работать только разрешенное количество человек.
Seculab co-founder
Евгений
 
Сообщения: 23
Зарегистрирован: Ср, 11 апр 2007 16:51

Сообщение Lithium™ » Чт, 17 июл 2008 10:22

Ок. Себестоимость тема отдельная.
Когда речь идет о конкурентных лицензиях, логировать превышение подключений без запрета подключения смысла нет.
Как я понял реализация защиты по схеме конкурентных лицензий, представленная стандартными средствами SenseLock, легкоуязвима в принципе (в плане утери лицензий).

В "крупном плане" ситуация выглядит так:

Вариант 1 - считать конкурентные лицензии.
Использования EL-NET RTC. Ключ работает некоторый период + запись в ключ факта (и деталей) превышения количества одновременных подключений. При продлении ключа эти данные проверяются. Реализация довольно простая, стандартными средствами SenseLock.
Степень надежности определяется получится ли замаскировать в протоколе обмена данными с ключом информацию о конкретном пользователе. Если сделать эту информацию жизненно важной для правильного выполнения защищенных функций, надежность резко возрастет.

Вариант 2 - считать рабочие места.
Использование EL RTC. Необходима серверная часть приложения, жизненно важная для работы клиентов. Ключ ставится на сервер, работает некоторый период + запись в ключ количества рабочих мест, когда-либо подключавшихся к нему. При продлении ключа эти данные проверяются.
Степень надежности определяется аналогичным образом + возможность анализировать "логи" программы если есть возможность отправить специалиста.

Выходит разницы практически нет (вначале мне казалось иначе). Осталось выбрать.

:!: Всем спасибо :!:
Слова "не надо нервничать" хорошо помогают привести человека в нормальное состояние бешенства.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение Lithium™ » Чт, 24 июл 2008 08:53

Поторопился похоже...
У разработчика нет доступа к механизмам контроля лицензий, соответственно нет возможности самостоятельно отслеживать одновременные подключения.

:arrow: помимо того что предложенные выше варианты требуют хранения в памяти ключа некоторых таблиц достаточно большого объема (по меркам ключа), все лишь усложняют задачу взлома.

Кстати,
Евгений писал(а):Если хотите 100% надежность, придется раздавать каждому пользователю по локальному ключу!

использование этого варианта для защиты нескольких приложений в одной сети также не дает 100% защиты в теории - аналогичным образом на клентскую машину ставится эмулятор, передающий все обращения к серверу, а на сервере стоит всего один ключ... В итоге все упирается в быстродействие ключа. IM'not'HO быстродействие локального ключа не стоит развивать, иначе такой сервер лицензий может и в инете появиться.
* * *
Сетевой вариант, в теории 100% надежный, у меня практически созрел, однако обломался, за отсутствием доступа к механизму контроля лицензий :(. Свой надежный механизм выдачи лицензий, заточенный под свою задачу, разработать нереально, из-за физически-небольшой памяти ключа.

По-прежнему остается усложнять защиту, без уверенности в ее надежности. Тем временем пребывая в поисках сетевого варианта защиты в теории 100% надежного...
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение Ivan Petrov » Пт, 25 июл 2008 01:52

Lithium™ писал(а):По-прежнему остается усложнять защиту, без уверенности в ее надежности. Тем временем пребывая в поисках сетевого варианта защиты в теории 100% надежного...

Может не стоит искать таблетку от всех болезней? Поставьте задачу более конкретно, сколько сетевых пользователей будет обращаться к ключу, как часто будет он вызываться, какие требования к предъявляются к менеджеру лицензий. И може в этом случае участниками форума будет дано решение, которое на 100% покроет все ваши потребности.
Ivan Petrov
 
Сообщения: 30
Зарегистрирован: Пн, 30 апр 2007 11:53

Сообщение Lithium™ » Пт, 25 июл 2008 08:24

Ivan Petrov писал(а):Поставьте задачу более конкретно

- ~40 пользователей работают одновременно, может колебаться в пределах 0..~100, всего пользователей >300. Коммерческий расчет само собой от минимума до максимума 0..255.
- выдача лицензий помодульная, + на каждый модуль имеется своя защищенная функция.
- частота вызова защищенных функций прямопропорциональна нажатию пользователями на некоторые кнопки в программе, т.е. часто.
- защ. функция в качестве одного из аргументов принимает ID пользователя, этот ID учавствует в обработке и необходим.
- система работает с сервером БД

Менеджер SenseLock не устраивает:
1. в плане уязвимости атак, описанных выше
2. из-за того что для ключа не имеет ниакого значения, на какой модуль я получил лицензию - главное чтоб была хотя бы одна на любой модуль - и ключ будет полнофункционально работать. (p.s. Сегодня только выяснил, волосы дыбом, вот это дыра в защите :!: )

Требуется способ в теории 100% надежный, позволящий детектить нарушение разрешенного количества одновременных подключений (помодульно!), с целью логировать в ключе "объем" этих нарушений.
Слова "не надо нервничать" хорошо помогают привести человека в нормальное состояние бешенства.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

Сообщение Ivan Petrov » Пт, 25 июл 2008 18:03

Lithium™ писал(а):- ~40 пользователей работают одновременно, может колебаться в пределах 0..~100, всего пользователей >300. Коммерческий расчет само собой от минимума до максимума 0..255.
- выдача лицензий помодульная, + на каждый модуль имеется своя защищенная функция.
- частота вызова защищенных функций прямопропорциональна нажатию пользователями на некоторые кнопки в программе, т.е. часто.
- защ. функция в качестве одного из аргументов принимает ID пользователя, этот ID учавствует в обработке и необходим.
- система работает с сервером БД

Я возму небольшую паузу на обдумывание архитектуры.
Предвариетльно - это может быть выдача сертификатов, т.е. подписанный и пошифрованный кусок памяти который, в теории можно выгружать наружу а не хранить постоянно в ключе.

Lithium™ писал(а):Менеджер SenseLock не устраивает:
1. в плане уязвимости атак, описанных выше
2. из-за того что для ключа не имеет ниакого значения, на какой модуль я получил лицензию - главное чтоб была хотя бы одна на любой модуль - и ключ будет полнофункционально работать. (p.s. Сегодня только выяснил, волосы дыбом, вот это дыра в защите :!: )

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

Lithium™ писал(а):Требуется способ в теории 100% надежный, позволящий детектить нарушение разрешенного количества одновременных подключений (помодульно!), с целью логировать в ключе "объем" этих нарушений.

Если говорит в теории ;) то можно подумать о использовании CodeShelter, но у него другие недостатки.
1. Очень слабая защита от инвазивных атак.
2. Отсутсвие комерческого АПИ и пакета документации.
3. Отсутсвие постоянной линии поддержки с нашей стороны.
Но много памяти и быстрое ядро.
Ivan Petrov
 
Сообщения: 30
Зарегистрирован: Пн, 30 апр 2007 11:53

Сообщение Lithium™ » Пн, 28 июл 2008 07:23

Пробило на широкую улыбку, прошу прощения за прямоту)))
Ivan Petrov писал(а):Менеджер лицензий разрабатывался под локальные ключи, для них это не бага а фича :) не влияющая на безопасность.

Странно, зачем менеджер лицензий локальному ключу, и почему он работает только с сетевыми, и почему SenseLock продает его с сетевыми когда он разрабатывался для локальных, и почему в документации об этом ничего нет... а сетевые тогда использовать как заглушки для незанятых USB?...
И в чем feature, собственно? И как быть, если мне нужен сетевой менеджер лицензий без такой "фичи"?
Ivan Petrov писал(а):А так... сравните сетевые менеджеры от других ключей, и то что вы нарыли не будет таким страшным Все в этом мире относительно.

Чесно говоря, такого рода сравнение не утешение :( .
Слова "не надо нервничать" хорошо помогают привести человека в нормальное состояние бешенства.
Lithium™
 
Сообщения: 22
Зарегистрирован: Чт, 10 июл 2008 09:00
Откуда: RND

След.

Вернуться в Защита программного обеспечения

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron