Можно ли спрятать секрет в «безопасном» классе Java, предлагающем учетные данные для доступа?

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

Вот что я пока имел в виду:

public final class Safe {

    private String secret;
    private HashMap validCertificates
            = new HashMap();

    public Safe(String aSecret) {
        this.secret = aSecret;
    }

    public final class Credentials {
        private String user;
        private Credentials(String user) {
            this.user = user;
        }
    }

    public final Credentials getCredential(String user) {
        // Following test is just for illustrating the intention...
        if ( "accepted".equals(user) ) {
            return new Credentials(user);
        } else {
            return null;
        }
    }

    public String gimmeTheSecret(Credentials cred) {
        if ( this.validCertificates.get(cred.user) == cred ) {
            return secret;
        } else {
            return null;
        }
    }

    private void writeObject(ObjectOutputStream stream) throws IOException {
        throw new RuntimeException("No no no no no no no!!!");
    }

}

Можно ли это улучшить? Следует ли его улучшить? Невозможно ли реализовать идею блокировки секрета в безопасном классе?

РЕДАКТИРОВАТЬ

Актуальность:

Некоторые люди сомневаются в актуальности проблемы, которую я здесь поднимаю. Хотя я задаю общий вопрос, чтобы вызвать открытый диалог, для этого класса есть очень конкретное приложение:

• Если я хочу расшифровать некоторые сообщения, мне нужно загрузить данные закрытого ключа в класс. Если я не могу предотвратить доступ к нему другого кода Java, тогда невозможно создать безопасную систему. Конечно, если я хочу расшифровать сообщение, я лучше сделаю это в классе, чем разглашу секрет, но, тем не менее, сейф должен оставаться нерушимым.

Пояснение:

• Экземпляры класса только создаются во время выполнения, а не во время компиляции
• Код может выполняться в приложениях веб-сервера или в любых приложениях для настольных компьютеров или устройств
• Класс используется только для хранения секрета во время выполнения, в памяти, без планов по его сохранению (для сохранения, можно / нужно использовать классические методы шифрования)

Факты:

• Для реализации безопасности в приложении Java необходимо установить экземпляр SecurityManager, где методы проверки при необходимости переопределяются
• Это приложение может загружать ненадежный код с помощью загрузчиков безопасных классов и назначать домен защиты для загружаемых классов. Этот домен не должен включать RuntimePermission ("setSecurityManager").
• Ненадежный код может попытаться изменить SecurityManager, но поскольку загрузчик классов безопасности не предоставил разрешение setSecurityManager, будет выброшено исключение SecurityException.

Решенные проблемы:

Что касается среды выполнения, нам нужно различать два случая:

• Контролируемая среда: Мы запускаем приложение, которое будет использовать ненадежный код, пытаясь взломать нашу «безопасность».

Если мы настроим соответствующий SecurityManager, отключающий отражение и ограничивающий разрешения для любого загруженного ненадежного кода, тогда наш секрет в безопасности.

• Неконтролируемая среда: Хакер запускает приложение, которое использует ненадежный код, пытаясь взломать наш код safe '.

Хакер может создать собственное приложение со своим собственным менеджером безопасности и загрузчиком Secure Class. Он может загрузить наш код из пути к классам и выполнить его, как если бы это было наше собственное приложение. В этом случае он может взломать сейф.

• Как установлено в отдельный вопрос , sun.misc.Unsafe не может взломать диспетчер безопасности