Как зашифровать каталог с помощью приложений-ключей?
Я работаю над приложением C ++, которое хранит (и часто обращается к) свои данные во многих файлах в одном каталоге с помощью многочисленных классов, библиотек баз данных и т. Д. Я хотел бы начать шифрование всех этих данных на диске с помощью ключа, управляемого приложение.
В Windows программное включение EFS для каталога было бы идеальным если приложение может установить ключ шифрования напрямую, а не использовать ключ на основе пароля вошедшего в систему пользователя. Это не представляется возможным.
Поскольку в коде есть множество мест для чтения / записи файлов, некоторые с полным произвольным доступом, библиотека, которая экспортирует что-то похожее на API операций с файлами ОС, будет проще всего при отсутствии прямой поддержки ОС.
Windows — самая большая база пользователей, но что-то пригодное для Mac и Linux было бы большим плюсом.
Какие-либо предложения?
Решение
Настройте приложение для запуска в качестве учетной записи службы, предназначенной только для нее. Затем настройте EFS. Поскольку служебная учетная запись приложения будет принадлежать файлам, ее пользовательские ключи должны быть единственными действительными ключами EFS для нее, поэтому только приложение (которое будет работать только под этой новой учетной записью службы) сможет получить доступ к файлам. ,
Другие решения
Рассматривали ли вы хранение файлов в зашифрованном архиве, таком как ZIP-файл? Непонимание того, на каком языке вы работаете, затрудняет более конкретный ответ.
Я не эксперт, но у меня есть несколько предложений,
(«пользователь» здесь считается мужчиной)
В Windows, когда пользователь вошел в систему, он будет иметь все права на управление файлом или папкой, которые ему принадлежат.
Но если он пытается манипулировать файлами или папками, принадлежащими другим пользователям, ему не разрешается это делать. Таким образом, он не может манипулировать файлами других пользователей.
Если пользователь является администратором, он будет иметь все права для манипулирования файлом.
В вашем случае, я считаю, что пользователь не является администратором.
Так, Я предлагаю Вам:
Создайте пользователя для этого приложения, скажем, Боб (Боб не тот пользователь, который собирается использовать это приложение).
Затем вы создаете папку для хранения ваших файлов и даете все разрешения только Бобу (и администратору).
Для всех остальных нет разрешения что-либо делать с папкой.
Ваше приложение должно быть установлено администратором.
При запуске Ваше приложение запрашивает пароль Боба у текущего пользователя.
Если пароль правильный,
Использование вашего приложения разрешает полный доступ к папке для текущего пользователя. Тогда приложение может работать, как вы хотите.
Если пользователь выходит из приложения,
Удалите все разрешения для текущего пользователя, чтобы после выхода из этого приложения другие пользователи не могли получить доступ к этому контенту.
Но администратор все еще может получить доступ к этому контенту.
Это похоже на управление пользователями в Linux.
Когда вы получаете оболочку, вы можете изменить пользователя, используя su username когда работа закончится и он выйдет из оболочки, другие не смогут использовать эти файлы. Но пользователь root может делать все что угодно в Linux.
Но есть одна проблема.
Администратор может получить полный контент и доступ, так как он может изменять разрешения.
Чтобы запретить это, сохраняйте файлы, архивируя их любым способом и используя пароль. Этот пароль известен только пользователю, который его использует. Перед сохранением файла в папку заархивируйте его с помощью пароля. Перед использованием файла распакуйте его, используя пароль.
Если почтовый пароль совпадает с паролем пользователя, значит, есть проблема.
Администратор может сбросить пароль пользователя на что-то и открыть свою учетную запись.
Чтобы предотвратить это, вы можете использовать следующую технику:
Используйте zip-пароль в качестве обратного пароля пользователя, так что если его пароль 1234, пароль zip — 4321, или используйте хеш-значение пароля пользователя в качестве zip-пароля.
Если zip-пароль имеет хеш-значение, такое как MD5-хэш или SHA-1, то перебор по zip-файлу не будет работать из-за длины пароля.
Я не знаю, является ли это рабочим решением или нет, или это может быть реализовано или нет.
Но вы можете извлечь некоторые идеи из этого, если считаете, что в этом есть хорошие идеи.
Если я не пропустил что-то в вашем вопросе, TrueCrypt кажется идеальным решением для вас.
Это позволит:
- Использовать существующий файловый API ОС (так как подключенный том будет вести себя как обычный том)
- Программно управлять ключом доступа (паролем)
- Ограничить доступ к подключенному объему (по механике ОС)
- Используйте одинаковые принципы на всех платформах (Windows, Mac, Linux)
Или, если вы хотите, вы можете зашифровать / расшифровать отдельные файлы с ним.
Есть несколько примеров того, как его использовать.