I am making a cipher class while teaching myself about java's security api. This class is going to have some sensitive stuff in it, such as the type of encryption and the like. All of this can be reflectively retrieved it some one had the motivation.
I have used reflection to bypass private variables and methods before (not proud of it), so I know that can be done. Is there a way to wholly prevent reflection from working on an entire class - or even parts of it, or does that go against java's - more specifically the security api - design?
This is called security by obscurity - if the details of your encryption algorithm being known would render it insecure, it already is insecure.
ReplyDeleteNo, you cannot stop people from reflecting on your class. In the very worst case, they could load a JNI library which would go straight into the JVM heap and read the memory contents from there (or write them)! If your code is running on a machine under the control of others, nothing it does is ever truly private.
If you yourself write a JNI library, it can be decompiled and reverse engineered (and this is explicitly legal by past caselaw in many jurisdictions, moreover).
Just make the algorithm secure even when its workings are known to all, or (better yet!) use an implementation which has already been written and is part of the Java language.
If what you're worried about is the disclosure of keying material, use the Java methods for keystore access. If you're truly paranoid, enforce that the backing store be a PKCS11 hardware token.
No - if you don't have any control of the security managers involved, or of the physical distribution of your code, then anyone can have a look at it. Even if you can make sure that your app normally runs with a security manager which is configured to prevent reflection, if an attack has your code (e.g. a jar file) then they can run it however they like - or decompile it, look at the contents etc.
ReplyDelete