Мое беспокойство - то, что криптографические ключи и секреты, которыми управляет сборщик "мусора", могут быть скопированы и перемещены в памяти без zeroization.
Как возможное решение, это достаточно к:
public class Key {
private char[] key;
// ...
protected void finalize() throws Throwable {
try {
for(int k = 0; k < key.length; k++) {
key[k] = '\0';
}
} catch (Exception e) {
//...
} finally {
super.finalize();
}
}
// ...
}
Править: Обратите внимание на то, что моя проблема расценивает не только zeroization копии чиновника на которую (ссылаются), объекта, но также и любых устаревших копий, которые, возможно, сделал сборщик "мусора", в то время как это переставляет память вокруг для эффективности скорости и пространства.
Самым простым примером является метка-и-развертка GC, где объекты отмечены, как 'ссылается', и затем все те объекты копируются в другой регион. Остальные - затем мусор и таким образом, они собраны. Когда копия происходит, который мог бы оставить остаточные ключевые данные, которыми не управляет больше сборщик "мусора" (потому что 'официальные' данные находятся в новом регионе).
Решающее испытание для этого было бы то, если Вы используете ключ в криптомодуле, обнуляете ключ, затем осматриваете все пространство процесса JVM, Вы не должны находить тот ключ.
Итак, из @jambjo и @james я пришел к выводу, что я действительно ничего не могу сделать, чтобы предотвратить копирование ключей и становится пропавшим без вести.
Лучшей стратегией для разработчика было бы переложить криптографическую библиотеку на C (или любой другой неуправляемый язык) и реализовать там свои вещи.
Я был бы более чем готов принять ответ от кого-то другого, если бы они могли придумать лучшее решение.
Лучше всего использовать allocateDirect
в NIO. В разумной реализации это не следует перемещать. Но, вероятно, он будет иметь право на подкачку на диск (я думаю, вы можете опросить его) и гибернацию.
В Справочном руководстве по расширению криптографии Java рекомендуется всегда использовать символьные массивы вместо строк для паролей, чтобы их впоследствии можно было обнулить. Они также предоставляют пример кода , как вы могли бы его реализовать .
И что , если данные в памяти не перезаписываются в определенное время? Если вам нужно беспокоиться о том, что злоумышленник прочитает память вашей машины, это проблема, а не то, что он мог там найти в какое время.
Какой реальный сценарий атаки вас беспокоит, где ключи, оставленные где-то в памяти JVM, могут стать серьезной проблемой? Если злоумышленник может взглянуть на память JVM, он может точно так же поймать эти ключи, пока вы их все еще используете.
И если вас беспокоит, что злоумышленник, работающий в системе как обычный пользователь, овладеет памятью, сброшенной JVM: AFAIK, все современные ОС перезаписывают вновь выделенную память нулями.