Журнал аудита использования лицензий на программное обеспечение

Question

Folks,

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

В частности, TickZoom продает торговую платформу альфа-поколения для хедж-фондов, стоимость которой в настоящее время составляет 2000 долларов США в месяц, включая поддержку (скоро увеличится более чем вдвое). Это хорошо для учреждений, но слишком дорого для частных лиц. Люди часто просят более низкую цену в обмен на процент от прибыли, полученной с использованием программного обеспечения, пока они не могут позволить себе платить фиксированные сборы.

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

Это приложение написано на C#, и эта часть системы запутана, по крайней мере, затрудняя расшифровку кода.

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

Разумеется, предполагается, что файл будет зашифрован.

Но есть идеи, как сделать его "защищенным от взлома"? Особенно против простой попытки удаления?

Мое первое предположение - заставить программное обеспечение всегда требовать существующий файл аудита, иначе оно откажется работать.

Затем, когда мы поставляем программное обеспечение, оно упаковывается с "пустым" контрольным файлом, который, на самом деле, имеет своего рода проверочную проверку.

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

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

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

С уважением, Вейнек

Answer 1

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

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

Не совсем доказательство, но было бы довольно солидно.

Также проверьте этот вопрос

Answer 2

Утверждение вашей проблемы:

• мы не доверяем клиенту; клиент может быть враждебным.
• Мы хотим, чтобы клиент отправил нам данные, которым мы можем доверять.

Нет решения этой проблемы. Вы также можете сказать: "Я хочу найти двух парней, одного по имени Боб, другого по имени Билл, такого, что Боб на фут выше Билла, а Билл на фут выше Боба". Вы не найдете двух парней с этим свойством.

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

Answer 3

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

-- Редактировать:

Вы только варианты, как я вижу, являются:

• Конвертируйте систему в веб-интерфейс (или, по крайней мере, в тонкий клиент), тем самым осуществляя все транзакции на сервере.

Очевидно, что это, скорее всего, нецелесообразно, если вы уже разработали целую локальную систему

• Придумайте какую-нибудь сложную схему, которую "сложно" сломать, и надейтесь, что люди не сломают ее

И в сочетании с этим методом, своего рода профилированием, показывающим, зарабатывают ли магазины X, и внезапно X-sigificantAmount, вы можете определить, что они больше не приносят прибыли, таким образом, вероятно, обманывая систему (или выходя из бизнеса:) Но это граничит с вторжением в частную жизнь и может быть не совсем уместным.

На практике, я думаю, вам нужно будет сопоставить риски с возможной прибылью или найти другую точку зрения на то, как продавать этим людям (т. Е. Только позволить самому интерфейсу / приложению управлять X в общих средствах, если он переходит, запросить про версию, или как там).