Порча электронных ключей

[Евгений]

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

В связи с этим остро встает вопрос, как идентифицировать ключи и на сколько методы идентификации адекватны ситуации возврата. Например, очевидно, что наклейка легко переклеивается, а краска может просто стереться.

[Anton]

Еще хорошие способы:
Гравировка на металлическом разъёме USB порта ключа. Либо термотиснение на пластик.

[mig_morozov]

У нас просто пользовател заявлял, что ключ украден с машиной и по человечески мы давали еще один раз ключ. После третьего такого случая в ключ стали прописывать идентификатор машины на которой он работает и время работы (1 год) и проблемы исчезли.

[Lithium™]

У нас просто пользовател заявлял, что ключ украден с машиной и по человечески мы давали еще один раз ключ. После третьего такого случая в ключ стали прописывать идентификатор машины на которой он работает и время работы (1 год) и проблемы исчезли.

Как в анекдоте, я глазом о дверной косяк ударился, и так несколько раз подряд...

На мой взгляд, самый лучший вариант в договоре на покупку ПО указать, что в случае утери/порчи ключа новый ключ бесплатно предоставляться не будет. Юридически обезопасив себя таким образом, можно смело решать с кем и сколько раз поступать по-человечески .

[svp]

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

С утерей всё, конечно же, ясно. Пользователь сам не уследил и сам виноват. А вот с порчей всё обстоит, ИМХО, сложнее. Положим электронная часть ключа вышла из строя. Как доказать, что это произошло по вине пользователя, а не из-за брака в самом ключе? Ключ мог быть испорчен, положим, разрядом пьезоэлемента от обычной зажигалки. Такую причину, мне кажется, очень сложно диагностировать, и независимая экспертиза обойдётся скорее всего дороже лицензии.

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

[Lithium™]

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

Погорячился. Вынужден согласиться. Рынок сложнее захватить с жесткими условиями договора.

[Евгений]

В случае потери ключа, как правило, конечному пользователю приходится покупать новую копию ПО. Это очень серьезная проблема, но единственным приемлемым вариантом решения является использование лицензий, ограниченных по времени. Это может быть продажа ПО в лизинг, либо в договоре прописывается обязанность вендора предоставлять лицензии, допустим, раз в пол года. Таким образом, при потери ключа вендор может быть уверен, что более полугода его лицензия не проработает.
Такая схема 100% надежно строится на SenseLock RTC + система лицензирования.

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

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

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

[svp]

Тут возникает ещё один нюанс.
RTC версия ключа громоздка по сравнению с SenseLock EL-Genii и не удобна для использования в ноутбуках.
Может быть отсутствие компактной модификации RTC ключа связано с необходимостью размещать в нём батарейку -- не знаю, но факт на лицо: при непрерывном торчании чего-то из usb порта ноутбука это что-то очень рискует отломаться.

Вопрос Евгению:
Почему в ключе не был предусмотрен простейший механизм прерываний по времени от встроенного таймера?
С помощью этого прерывания можно было бы реализовывать более гибкие механизмы лицензирования посредством обычных ключей (не RTC).
Выглядело бы это примерно так:
Известно, что во всех ключах есть встоенный таймер с периодом переполнения около четырёх часов.
Достаточно зарезервировать какой-то диапазон идентификаторов файлов для исполняемых модулей, в которые можно было бы загрузить обработчики прерываний по таймеру. Эти обработчики запускались бы при наличии питания на ключе через некоторый фиксированный интервал времени.

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

[Anton]

Кстати поделюсь методом, как с помощью обычного (не RTC) ключа учитывать текущее время.
Делается следующим образом: в протокол общения программы с ключом внедряется текущее время компьютера. Ваш исполняемый в ключе модуль получает блок данных, расшифровывает, получает из него системное время, сравнивает с тем временем которое сохранено от предыдущего пакета. Если время больше предыдущего, то записываем его в память. Если время меньше предыдущего - значит нас обманывают.
А при помощи встроенного внутреннего таймера (он расчитан на 4 часа) можно контролировать периоды обращения к ключу и детектить искусственное замедление внешнего времени.

[Евгений]

Уважаемый SVP, действтельно ключ RTC, имеет больший размер из за того, что в нем хранится батарейка.

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

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

Если нужно ограничить программу не на дату, а по количеству рабочих часов - тут вообще все тривиально.

[svp]

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

Если интервал между вызовами обработчиков сделать большим (минуты или десятки минут), сами обработчики делать в формате XA и нетребовательными к ресурсам, то не сильно затормозило бы (ИМХО).

а также потенциально привело бы к зависаниям электроники в случае ошибок при программировании

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

другими словами, оно не стоит того, чтобы это реализовывать.

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

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

Не так уж и тривиально. Период переполнения таймера четыре с половиной часа, а при длительных перерывах между вызовами функций ключа (например, приложение висит в трее или просто имет длительные периоды ожидания в запущенном состоянии) девайс просто мертв. То есть не может в принципе считать сколько прошло периодов.
Даже одно единственное прерывание на переполнение счетчика (раз в 4.5 часа) уже делает ключ гораздо более гибким в использовании. Без этого прерывания однозначно сказать сколько прошло времени с момента запуска программы нельзя.
Регулярная посылка нефункциональных пакетов с текущим временем во многих случаях бесполезна, так как её, зачастую, можно безболезненно блокировать.

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

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

Потенциально опасны для честных пользователей любые механизмы лицензирования, особенно не вполне продуманные. Здесь важно найти разумный компромисс.
Senselock, как неоднократно акцентировалось, представляет нам не готовое решение по защите и лицензированию ПО, а инструмент, позволяющий строить свои индивидуальные механизмы защиты. Любой хороший инструмент, конечно же должен быть лаконичным и максимально простым, даже если это немного снижает его функциональную гибкость. Однако, если есть возможность без больших усложнений добавить достаточно "вкусный" функционал, зачем же её упускать?
---------------
Прощу прощения за оффтоп.

[Anton]

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

Может быть я зря встреваю в беседу, но что мешает заставить приложение всётаки обращаться к ключу хотя-бы раз в пять минут ?
И это не обязательно должен быть пустой вызов. Да даже если это будет пустой вызов, и если злоумышленник его "вырежет" из программы, то ключ не получив очередного обращения (с текущим системным временем) может просто "заснуть" и потребовать перезапуска приложения. Это просто как вариант...

[svp]

то ключ не получив очередного обращения (с текущим системным временем) может просто "заснуть" и потребовать перезапуска приложения

Да.. как часто бывает, о самом простом варианте я и не подумал.
Вы, Anton, меня убедили=). Прерывания не нужны!

[bon002]

Поясните еще раз, пожалуйста. Если ключ физически вскрыть, там есть серийный номер, чтобы можно было идентифицировать нерабочий ключ? Мне (как разработчику ПО) не принципиально заменять ключ в Секьюлэб, готов выслать клиенту новый за свой счет, главное убедиться, что клиент не прислал пустой ключ, специально выведенный из строя.

[Alexey]

Поясните еще раз, пожалуйста. Если ключ физически вскрыть, там есть серийный номер, чтобы можно было идентифицировать нерабочий ключ? Мне (как разработчику ПО) не принципиально заменять ключ в Секьюлэб, готов выслать клиенту новый за свой счет, главное убедиться, что клиент не прислал пустой ключ, специально выведенный из строя.

Вскрывал и не один раз. Все ключи изнутри одинаковые...