Как я могу убедиться, что кто-то не отправляет поддельные данные?

Question

Я уже давно читаю Переполнение стека, но это мой первый опубликованный вопрос.

У меня есть эта программа отслеживания, написанная на C #, которая собирает информацию об использовании локального компьютера и отправляет ее на сервер. Данные в формате XML отправляются один раз в ~ 10 минут.

Моя проблема: независимо от того, как я шифрую данные XML (будь то симметричные или асимметричные), кто-то всегда может декомпилировать мою программу отслеживания C #, выяснить, какие соглашения о ключах / сертификатах / шифровании я использую, и написать другую программу, которая отправляет поддельные отчеты. на сервер.

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

Вопросы: 1) как я могу убедиться (насколько это возможно), что данные отправляются с реального трекера, а не с клона / фейкера? 2) как я могу настолько плохо запутать код, что восстановление ключей / сертификатов / соглашений о шифровании становится адом или почти невозможным?

Я хочу потратить немного или, скорее всего, нет денег на решение (так что о 500 $ обфускаторах не может быть и речи. Я студент университета, и я дешев: :)

Заранее спасибо.

Answer 1

Как * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1003

Никогда не доверяй клиенту. Никогда ничего не кладите на клиента. Клиент в руках врага. Никогда и никогда не забывай этого.

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

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

Например: если ваше приложение отправит свои данные в виде обычного текста по электронной почте, это победит примерно ноль злоумышленников. Отправка его в электронном письме rot13 может победить, возможно, 5% злоумышленников. Отправка его в зашифрованном виде с использованием имени пользователя в качестве ключа будет побеждать больше. Запутывание кода отправки бесплатным обфускатором побеждает больше. Обфусцирование с помощью обфускатора коммерческого уровня победит больше. Требование к каждому клиенту иметь аппаратный ключ может победить «всех, кроме самых решительных» злоумышленников, как любят говорить люди, но это, вероятно, будет невыносимой.

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

Answer 2

Мы использовали аппаратное решение для обеспечения этой необходимой функциональности.

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

Answer 3

Кажется довольно безнадежным.Ваш трекер, вероятно, использует Windows для предоставления метрик, например, в конечном итоге вызывая GetUserName () / GetTickCount () / CollectPerformanceData () / etc.Таким образом, злоумышленник просто должен перехватить ваш код (независимо от того, насколько он запутан и не удосуживается декомпилировать) в любой точке входа Windows, подставить поддельные данные и позволить вашему коду продолжать работать весело.

Жизнь слишком коротка, чтобы биться головой о такие кирпичные стены.

Answer 4

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

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

Answer 5

Теоретически, приложение просто не может защитить себя при работе в ненадежной среде.Итак, ответ на первый вопрос таков: «Вы никогда не можете быть уверены в том, что данные отправлены реальным трекером».

На практике обфускация будет мешать злоумышленникам до определенного момента.Точка определяется качеством обфускации и мотивации атакующего.Таким образом, ответ на второй вопрос зависит от того, кто является злоумышленником, насколько он способен и какие ресурсы они могут использовать для решения этой проблемы.Обфускация, которая является «адом / почти невозможным» для немотивированного дилетанта, чтобы распутать, может быть тривиальным для эксперта или кого-то, кто может нанять эксперта.

Вот список некоторых обфускаторов C #.

Answer 6

1. Другой подход: при условии, что вы не часто меняете свой исполняемый файл.сделайте DigSig вашего (HASH + Encrypt) образа исполняемого файла вашего клиента и отправьте его вместе с ним, чтобы аутентифицировать вашего клиента как реального клиента, а не как измененную версию.совершенно другой клиент, который может получить Digsig вашего исполняемого образа.