Встроенная база данных и шифрование

Question

Я хочу создать приложение с открытым исходным кодом, где данные, специфичные для пользователя, хранятся во встроенной базе данных (например, SQLite, H2, HSQLDB). Кроме того, будет экран входа в систему, где пользователь должен ввести пароль зашифрованной базы данных. Но я еще не уверен, как обрабатывать шифрование: обрабатывается только базой данных и/или, например, BouncyCastle с полным шифрованием файлов?

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

Большое спасибо за вашу помощь! :)

Answer 1

Хорошо, я решил мою проблему теперь следующим способом:

Я использую HSQLDB сейчас и встроенного шифрования с AES-128 (и другие, как Blowfish). HSQLDB создает разные файлы, в то время как существует открытое соединение.

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

Чтобы защитить этот ключ и, кроме того, файлы, я сначала упакую всю папку с файлами базы данных в zip-файл. На следующем шаге я зашифрую этот файл паролем, введенным пользователем на экране входа в систему. Этот пароль не будет сохранен физически. Для дешифрования я использую AES-реализацию Java Cryptography API Bouncy Castle.

Шифрование в деталях: 1. Создайте случайный вектор инициализации (IV; 16 байт), соль (8 байт) с ключом SecureRandom-Class и ключ шифрования данных (DEK; 16 байт) с KeyGenerator для AES. 2. Создайте 32 байтовый ключ PBKDF2 с введенным паролем и солью и разделите его на ключ проверки (VK; 16 байт) и ключ шифрования ключа (KEK; 16 байт). 3. Установите папку, в которую хранятся файлы базы данных, в zip-файл и зашифруйте байты этого файла с помощью DEK и AES-Provider. 4. Зашифруйте DEK с помощью KEK и IV поставщиком AES. 5. Храните IV, соль, DEK и VK в начале зашифрованного zip-файла. Если вы дополнительно работаете с внутренним шифрованием базы данных, вы получаете CRYPT_KEY, который также хранится в zip-файле.

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

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