Enhancing Security - Expert Oracle and Java Security - page 267

RMI has an RMIClassLoader that can load a class from a stub or skeleton class and match it with the
implementation class on the RMI server. The URLClassLoader can load classes from a jar file or class files
located remotely, for instance on a web server.
In the case of Roubtsov's EncryptedClassLoader , the byte code needs to be decrypted before the
object or class is realized. That is all well and good, and we're all thinking green light!
However, Roubtsov points out the fallacy of trusting in this security. At some point in every class
loader, the byte code is passed to the defineClass() method, which must present the class in a form
readable by the JVM. It is at that point that the form and function of our classes are revealed to any Java
hacker.
I'm not saying that encrypted byte code is a bad idea, just that we are not achieving meaningful
encryption—just a complex obfuscation. Perhaps that can be said about all encryption: it is only
encryption up to the point that it needs to be decrypted for use.
There are some concerns with implementing our own class loader: it is so close to the core of the
JVM that we will need to take caution and may need to revisit it with every Java update. An error there in
the ClassLoader could be devastating to our applications. That alone repels us from byte code
encryption.
Get It from an Encrypted String
Why don't we just encrypt our password and only decrypt it as needed? That's a good idea, but what
about the encryption key, how do we protect that? Is this another “chicken and egg” problem? I think so.
Exposing the key is tantamount to exposing the password.
Get It from an Encoded String
What if we encode our string so that it is unrecognizable? This is perhaps as good as encrypting it, but it
doesn't require an encryption key. We will look at some example Java code in a class we will call OJSCode
to encode our password.
Using the Encode Method
In brief, our OJSCode.encode() method will take the connection string and encode it byte by byte by
doing a binary Exclusive Or (XOR) with other bytes. An XOR conversion can be done twice to get back to
the original byte. In XOR, the resultant bit is 1 only if the analogous bit in one or the other, but not both
original bytes is 1. This is what the process looks like:
Original Byte 0 1 0 0 1 1 0 1
Other Byte 1 1 1 0 0 1 0 1
Result of XOR 1 0 1 0 1 0 0 0 (resultant bit is 1 where only one of bits is 1)
Other Byte 1 1 1 0 0 1 0 1
Result 2 nd XOR 0 1 0 0 1 1 0 1 (notice this is the same as our original Byte)
For security reasons that we'll discuss later, we will reach outside the OJSCode class to get our “other”
bytes. Our intent for OJSCode is only to use it from the OracleJavaSecure class, so how about we reach
back to that expected class to get our other bytes? We will assemble our other bytes from a static string
named “location” in OracleJavaSecure .
Because we know we are going to be doing an XOR on our original bytes, we will need to have the
same number of other bytes as we have original bytes. Listing 11-1 shows how we get two byte arrays
representing our connection string ( encodeThis ) and an array of other bytes of the same length.