Как безопасно узнать, создан ли файл, созданный с моим приложением, с другого компьютера?

Question

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

Это функция Visual Studio уже есть:

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

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

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

Answer 1

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

Давайте рассмотрим общую схему.

• Вы создаете приложение.
• Пользователь на другом компьютере устанавливает ваше приложение на свой компьютер.
• Пользователь создает файлы.
• Компьютер пользователя взломан.
• Пользователь открывает файл в вашем приложении.

Теперь вопросы:

Какого типа компромисса мы проектирование против?

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

Итак, какие компромиссы мы можем разработать против?

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

Как мы аутентифицируем происхождение?

Хэшированные значения, такие как SHA1 и MD5, используются для проверки целостности. Хэш-значение в файле может только сказать вам, был ли файл неизменен с момента создания хэша.Он не сообщает вам, откуда появился файл. Цифровая подпись обеспечивает проверку происхождения. Цифровая подпись сообщает вам, что подписанные данные возникли у человека, который контролирует ключ, используемый для подписания сообщения.

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

Это не проблема, если на одном компьютере имеется только одна копия приложения. Но, когда у вас более одного, вам нужно подумать о генерации и распространении ключей. Генерация ключей и их распределение - очень сложная проблема. Для цифровых подписей требуется пара открытых частных ключей. Частный ключ должен быть защищен, и он должен быть уникальным для каждого компьютера. Ранее мы предполагали, что злоумышленник не может изменить ваше приложение, но я считаю справедливым предположить, что злоумышленник может прочитать ваш исполняемый файл. Это предположение делает ваш исполняемый файл плохим местом для хранения вашего закрытого ключа. Вы можете зашифровать свой ключ, но тогда вам понадобится еще один ключ для дешифрования вашего ключа. Здесь можно найти несколько возможных ответов:

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

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

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

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