Puede ocultarse un secreto en una clase Java 'segura' que ofrece credenciales de acceso?

Esta es una pregunta de lluvia de ideas sobre lo que es posible en Java (o no). Quiero saber si es posible ocultar un secreto dentro de una clase y evitar que más acceda a élutilizando código Java o cualquiera de sus características solo (seguridad, reflexión, serialización, cargadores de clases, lo que quieras ...).

quí está lo que tengo en mente hasta ahora:

public final class Safe {

    private String secret;
    private HashMap<String, Credentials> validCertificates
            = new HashMap<String, Credentials>();

    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!!!");
    }

}

¿Se puede mejorar? ¿Debería ser mejorado? ¿Es imposible lograr la idea de encerrar un secreto en una clase segura?

EDITA

Pertinencia

Algunas personas cuestionan la relevancia del problema que estoy planteando aquí. Aunque estoy haciendo una pregunta general para iniciar una conversación abierta, hay una aplicación muy concreta para esta clase:

Si quiero descifrar algunos mensajes, necesito cargar datos de clave privada en una clase. Si no puedo evitar que otro código Java acceda a él, entonces es imposible crear un sistema seguro. Por supuesto, si quiero descifrar un mensaje, prefiero hacerlo en clase que revelar el secreto, pero aún así, la caja fuerte debe ser irrompible.

Aclaración

as instancias de la clase solo se crean en tiempo de ejecución, no en tiempo de compilacióCode puede ejecutarse en aplicaciones de servidor web o cualquier aplicación de escritorio o dispositivoLa clase solo se usa para almacenar un secreto en tiempo de ejecución, en la memoria, no hay planes para persistirlo (por persistencia, uno puede / debe usar técnicas de cifrado clásicas)

Hechos

Para implementar la seguridad en una aplicación Java, se debe establecer una instancia de SecurityManager dondecomprobació los métodos se anulan según sea necesarioEsta aplicación puede cargar código no confiable con cargadores de clases seguros y asignar un dominio de protección para las clases que carga. Este dominiono deberí incluir un RuntimePermission ("setSecurityManager"). El código no confiable puede intentar cambiar el SecurityManager, pero dado que Secure Class Loader no otorgó el permiso setSecurityManager, se lanzará una SecurityException.

Problemas resueltos:

En cuanto al entorno de ejecución, debemos distinguir dos casos:

Ambiente controlado Podemos iniciar la aplicación que usará código no confiable tratando de romper nuestra 'caja fuerte'.

Si establecemos un SecurityManager adecuado deshabilitando la reflexión y restringiendo los permisos en cualquier código cargado que no sea de confianza, entonces nuestro secreto está a salvo.

Entorno no controlado: Hacker inicia la aplicación que utiliza código no confiable que intenta romper nuestra 'seguridad'.

El hacker puede crear su propia aplicación con su propio administrador de seguridad y cargador de clase segura. Podría cargar nuestro código desde el classpath y ejecutarlo como si fuera nuestra propia aplicación. En este caso, podría romper la caja fuerte.

Según lo establecido enuna pregunta separada, sun.misc.Unsafe no puede romper un administrador de seguridad

Respuestas a la pregunta(12)

Su respuesta a la pregunta