Создание неизменяемых файлов

Question

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

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

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

Есть ли более эффективные подходы к решению такого рода проблем?

Answer 1

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

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

Answer 2

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

Даже решение на стороне сервера можно обойти, прослушивая трафик. Итак, вам нужно создать их и использовать SSL. А потом они просто исправили двоичный файл, как указано выше, и это происходит. Итак, вы применяете различные меры, чтобы запутать ваш бинарный файл, и ваши пользователи извлекают дизассемблер, такой как IDA PRO.

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

Answer 3

Используйте цифровую подпись. Подпись - это хеш, зашифрованный с помощью шифрования с открытым ключом. Ваша заявка содержит только открытый ключ. Этот ключ используется для расшифровки хэша, а затем хэш проверяется. Чтобы «исправить» хеш после изменения файла, пользователь должен вычислить новый хеш, зашифровать его с помощью закрытого ключа и заменить старый в конце файла. Проблема: у него нет закрытого ключа. Закрытый ключ отсутствует в вашем приложении. Закрытый ключ нигде не поставляется с вашим приложением. Ваше приложение имеет только публичный. Если он зашифровывает его с общедоступным, он не расшифровывает с общедоступным, так что это бесполезно. Закрытый ключ находится на вашем компьютере, и никто не имеет к нему доступа.

Answer 4

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

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

Answer 5

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

Я предлагаю использовать цифровую подпись в соответствии с предложением JesperE. Процесс стандартный, вы найдете много примеров, демонстрирующих его.

Answer 6

Нет, если вы хотите 100% решение. Достаточно взглянуть на кино и музыкальную индустрию. Они пытались и потерпели неудачу в течение многих лет:)

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

Answer 7

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

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

Посмотрите на HMACs для кодифицированного метода использования "соли", как вы думаете (где соль вместо этого называется ключом).

Answer 8

Это то, для чего нужны md5-хэши и CRC, и поэтому вы проверяете загруженные файлы из Интернета на предмет их md5-файлов, чтобы убедиться, что они не были похищены на маршруте.

В любом случае, я думаю, что Roddy использует C ++, поэтому я могу порекомендовать Boost :: CRC очень быстро и с небольшими издержками, вам также не нужно шифровать файл таким образом

Answer 9

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

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