This is a brainstorming question about what's possible in Java (or not). I want to know if it is possible to hide a secret within a class and prevent anyone from accessing it using Java code or any of its feature only (security, reflection, serialization, class loaders, you-name-it...).
Here is what I have in mind so far:
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!!!");
}
}
Can it be improved? Should it be improved? Is the idea of locking a secret in a safe class impossible to achieve?
EDIT
Relevance:
Some people question the relevance of the issue I am raising here. Although I am asking a general question in order to trigger an open conversation, there is a very concrete application to this class:
- If I want to decrypt some messages, I need to load a private key data into a class. If I can't prevent other Java code from accessing it, then it is impossible to create a secure system. Of course, if I want to decrypt a message, I should rather do it in the class than giving away the secret, but still, the safe has to remain unbreakable.
Clarification:
- Instances of the class are only created at runtime, not at compile time
- Code can run in web server applications or any desktop or device applications
- The class is only used to store a secret at runtime, in memory, no plans to persist it (for persistence, one can/should use classic encryption techniques)
Facts:
- To implement security in a Java application, one should set a SecurityManager instance where checking methods are overridden as needed
- This application can load untrusted code with secure class loaders and assign a protection domain for the classes it loads. This domain should not include a RuntimePermission("setSecurityManager").
- Untrusted code can try to change the SecurityManager, but since the Secure Class Loader did not grant the setSecurityManager permission, a SecurityException will be thrown.
Solved issues:
Regarding the execution environment, we need to distinguish two cases:
- Controlled environment: We get to start the application that will use untrusted code trying to break our 'safe'.
If we set a proper SecurityManager disabling reflection and restricting permissions on any loaded untrusted code, then our secret is safe.
- Uncontrolled environment: Hacker gets to start the application which uses untrusted code trying to break our 'safe'.
The hacker can create his own application with its own security manager and Secure Class loader. It could load our code from the classpath and execute it as if it were our own application. In this case, he could break the safe.
- As established in a separate question, sun.misc.Unsafe cannot break a security manager
