Suggestions for a custom bootstrap class loader

[George H]

Thanks for the insight. I didn't realize that the debugger would cause
this attempt to be futile.

Your sealed box design is interesting. The only problem I would have
is the internal local storage. Deployment would be on regular
(centrally controlled) PCs. I was think if the class files were
decrypted and placed in an encrypted disk volume (something like
TrueCrypt) and the VM would read the files from there. This would
solve the problem if the hard-disk was stolen or if the OS was broken
into.

Though still remains that someone might be able to copy the
un-encrypted class files if they gained access. It would be
interesting if I stored the un-encrypted class files in a Derby
(JavaDB) embedded database that is encrypted.

Would it be possible to feed class files to the VM via some sort of
connection channel ?

Thanks for your feed back.
--
George


On Tue, Jun 1, 2010 at 11:06 AM, Erik Trimble <erik.trimble at oracle.com> wrote:
> 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
>
>