Suggestions for a custom bootstrap class loader
Erik Trimble
erik.trimble at oracle.com
Tue Jun 1 01:06:01 PDT 2010
Encrypting bytecodes makes no sense, as it's easily subverted. Slap a
debugger (or other inspection tool) onto your customized VM, and voila -
I can see all the bytecodes (and execution) unencrypted.
This kind of thing only makes sense if you have a hardware device doing
the encrypt/decrypt. Any software-only program which has to continuously
decrypt data is subject to relatively straightforward attacks. A good
example of why software-only encryption doesn't work for IP/DRM is the
whole CSS debacle - CSS was useful for protecting DVDs so long as the
DVD players were only hardware consumer-electronics devices, sealed from
outside use. As soon as the first software DVD player for a PC came
along, it was relatively simple to break the encryption.
Software has to be able to see the data unencrypted to do anything
useful with it. So long as you allow access to the system while the
software is running, your data is completely unsecured, and you
shouldn't even have bothered encrypting it in the first place.
Now, if you're planning on deploying the JVM into a sealed box design,
well, then, you probably want to attack the problem other ways. It's
simpler, faster, and cheaper to provide a standalone decryption program
to decrypt the to-be-run program. That is, encrypt the java bytecode on
your "master" device, deliver the encrypted result via whatever
distribution method you chose (network, physical media, etc.), and then
have the sealed device unencrypt the program to (internal) local
storage, and run the program with the standard JVM. Saves you a lot of
work, with the same outcome. Forcing the JVM to do the decrypt is
going to seriously hurt performance (radically increasing load times).
Not to mention being a royal PITA to implement.
-Erik
On 6/1/2010 12:21 AM, George H wrote:
> Hi,
>
> I have in mind a feature that I would like to see in the OpenJDK and I
> was reading on the OpenJDK webpage that it is better to discuss a new
> feature first on the mailing list before starting on it. And I have a
> few questions to ask. Thought if anyone could provide me with insight,
> tips and some sort of starting point it would be on this mailing list.
>
> My ultimate goal to have the virtual machine load encrypted java
> byte-byte code. Yes, its the age old protecting intellectual property
> (IP) routine.
> Doing this with a custom class loader in Java is out of the question.
> I believe the best way to do this is through the bootstrap class
> loader which is written natively. I was hoping of trying to do the
> following.
>
> 1: Be able to supply a cryptographic key to the VM so that it may use
> it to decrypt/encrypt bytecode on the fly
>
> and/or
>
> 2. Be able to register a second bootstrap class loader that performs
> the on the fly encryption/decryption on the fly, and I can call it
> from inside java programs.
>
> I was thinking that this might be a nice feature for everyone to use
> especially if point No.1 is done. The VM will be better adopted by
> persons and entities who require protection from decompiling class
> files. It would certainly make it easier than having to deploy a
> custom built OpenJDK variant that will load encrypted class files.
>
>
> Currently I have looked at
> "openjdk-6-src-b19-15_apr_2010\hotspot\src\share\vm\classfile\classLoader.cpp"
> and I wonder if there is any more documentation about this file and
> the whole bootstrap class loading process.
>
> What are your suggestions, opinions and responses? I am eager to know
> if this is something many people want or just me?
> I am probably going to inevitably try to do this so any help in
> getting to know the OpenJDK source code would be great.
>
> Thanks
> --
> George
>
--
Erik Trimble
Java System Support
Mailstop: usca22-123
Phone: x17195
Santa Clara, CA
More information about the hotspot-dev
mailing list