Java Webapp и KeyStore

Question

Я разрабатываю небольшой инструмент (веб-интерфейс и веб-службы) для подписывания некоторых больших двоичных данных с помощью закрытого ключа RSA.Приложение будет иметь более одного закрытого ключа (т.е. для различных типов BLOB-объектов), и в будущем мы можем отказаться от некоторых ключей (и добавить новые).

Вопрос в том, где мне хранитьфайл хранилища ключей?Добавление его в META-INF не кажется хорошей идеей, поскольку оно будет перезаписано обновлением программного обеспечения.Другими вариантами будет сохранение в что-то вроде /etc/myapp/keys.keystore или в таблицу в столбце BLOB-объектов.

Итак, каков "канонический" способ хранения хранилища ключей?

Answer 1

Я не думаю, что есть канонический путь.Возможно, лучшим вариантом будет иметь хранилище ключей, внешнее по отношению к приложению, и настроить его местоположение (например, через -Dkeystore.location=/home/.. (что-то похожее на this ).

Answer 2

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

Документы Tomcat здесь

С этим вопросом связан стекопоток

Кроме того, описание того, как вы собираетесь реализовать шифрование, может показаться, что с ним могут возникнуть некоторые проблемы.Прочитайте рекомендации пользователя erickson в различных ответах, чтобы увидеть, как это сделать правильно.Вот вопрос для начала: Java 256-битное шифрование на основе пароля AES

Answer 3

В прошлом я хранили хранилища ключей в файловой системе как файл с расширением .jks. Рассматриваемое приложение всегда запускается как отдельный пользователь, поэтому мы помещаем файл в (подкаталог) домашнего каталога пользователя. Затем у нас был некоторый код в соответствии с

String keystorePath = System.getProperty("ourapp.keystore.path");
File keystoreFile;
if (keystorePath!=null)
    keystoreFile = new File(keystorePath);
else
    keystoreFile = new File(System.getProperty("user.home"), "ourapp.jks");
if (!f.exists()) {
    // Some sort of whining, return
}
// ...load and deal with keystore...

Я не думаю, что есть канонический способ сделать это (хотя я могу ошибаться). Этот способ хорошо сработал для нашего варианта использования.