Java 11 - Как перезаписать конфиденциальную информацию в JVM- и System-Memory (возможно, с помощью System.gc ()?)

Question

Проблема: Как принудительно перезаписать системную память в Java - Более конкретно: Когда защищенные ключи не должны оставаться в памяти более нескольких секунд: ни в jvm-память, ни в OS-Memory?

Что я пробовал: Модификация реализации java сборщика мусора, чтобы она наверняка перезаписывала объекты случайными байтами, а не просто освобождала их,Однако:

Все, что я прочитал о System.gc(), показало мне, что я никогда не могу действительно полагаться на это, и что не следует использовать это в производстве.Однако что, если я знаю, что использую определенную JVM?Что если я знаю, что хочу использовать OpenJDK с Java 11 и что я настраиваю JVM для использования конкретной реализации GC (чтобы не позволить JVM выбрать GC)?

Вопрос 1: Могу ли я тогда каким-то образом быть уверен, что System.gc() вызовет сборку мусора 100% раз?

Вопрос 2: Могу ли я узнать, какова максимальная продолжительность между System.gc() был вызван и начнется фактическая сборка мусора?Это важная часть вопроса!Я мог только найти ответы на саму эффективность сборки мусора (например, пропускная способность по сравнению с временами пауз остановки), но это НЕ ответ на этот вопрос.(Прочитайте всю документацию здесь )

Вопрос 3: Если идея с модифицированным сборщиком мусора, безусловно, является наихудшей идеей надежной перезаписи каждого случаяразличные разумные объекты Java в памяти, тогда как я мог бы перезаписать эти объекты в памяти?Это вообще возможно с Java?Было бы неплохо иметь возможность удалять и перезаписывать эти объекты непосредственно в Java-коде, подобно освобождению объектов в C / C ++?Есть ли другие возможности, кроме как в Java, где я могу перезаписывать каждое появление такой чувствительной информации в памяти, которая должна быть запущена как можно быстрее, как только объект Java больше не используется?

Мои исследования до сих пор:

• Официальные документы Java для Java 11
• Принудительная установка виртуальной машины Java для запуска сборщика мусора [duplicate] с 2013 года
• Когда System.gc () что-либо делает с 2008 года
• System.gc () для сбора мусора с2013
• Что гарантирует System.gc ()?[duplicate] от 2013 г.
• Вызывает ли вызов System.gc () в java сборку мусора как для подержанного поколения, так и для молодого поколения? из 2010
• Почему плохой практикой является вызов System.gc ()? из 2010
• Как форсировать сборку мусора в Java? из 2009
• Есть ли деструктор для Java? из 2008
• Явно вызовите system.gc () в коде [duplicate] из 2016

Как вы можете видеть, они, за исключением официальных документов, довольно старые, поэтому:

Вопрос 4: Есть ли какие-либо более новые идеи, доступные для беспокойства, ведет ли себя System.gc() так же, как10 лет назад??Спасибо!

* РЕДАКТИРОВАТЬ: Я уже использую байтовые массивы для случаев, когда они могут быть использованы.Речь идет о более сложных Java-объектах с различными полями и свойствами, которые необходимо полностью очистить в памяти.

Answer 1

Предполагая, что вы можете сохранить ключ безопасности в byte[] или другом примитивном массиве, этого должно быть достаточно для обнуления массива после считывания ключа:

for (int i = 0; i < key.length; i++) {
  key[i] = 0;
}

Приведенное выше должно привести к byte[] keyполностью переопределено.Полагаться на GC здесь было бы ошибкой, поскольку это непредсказуемо.