Suggestions for a custom bootstrap class loader

Tue Jun 1 02:22:52 PDT 2010

Yes I am totally with you on that Ben.

Problem did not arise form sprinkling magical encryption dust on the JVM, it
came from trying to find an opensource solution to this. So far the only
solution I can see if by using a Java to Native compiler. The likes of which
ExcelsiorJet is the only fully working and proprietary solution. There are
others like the GNU classpath, but it lacks AWT and Swing support. There is
the JNC (JavaNativeCompiler) but it too is lacking in certain things.

So in the hopes of trying to find something opensource that might be a
viable solution without having to write a java to native compiler was the
option of encrypting byte code and binding the process to the JVM via
OpenJDK.

So you see the situation I am in.

I also wondered if I could tweak the JVM to use the JIT to compile
everything and cache the results somewhere and just re-use them ? It even
sounds crazy to me but maybe there is such a tweak.

Thanks again.
--
George

On Tue, Jun 1, 2010 at 12:14 PM, Ben Evans <ben.evans at db.com> wrote:

>
> It's also worth remembering that not every seemingly-technical problem
> needs a technical solution.
>
> When trying to decide whether to make these types of expensive, intrusive
> and complicated changes (bear in mind, it's not just the sealed-box runtime
> environment that you'd be needing to secure - if you really and genuinely
> have IP which is so valuable that it needs this level of protection, it's
> going to have massive knock-on effects to your development environments,
> your corporate firewalling arrangements, etc, etc) -  it's really important
> to have an independent check of the risk concerned - done by someone who
> does security (or better yet risk) at a professional level - all day, every
> day.
>
> As stated, this problem sounds a bit like:
>
> "Oh noes! People might decompile our bytecodes and steal our valuable IPs!"
> "Quick, sprinkle magical encrypting pixie dust over the JVM"
>
> and that's rarely a good start for seeing the problem (and attendent risks)
> in the full context they deserve.
>
> Thanks,
>
> Ben
> --
> Ben Evans
> GFFX Auto Trading
> Deutsche Bank, London
> Office: +44 (0)20 7541 3953
>
>
>  *Erik Trimble <erik.trimble at oracle.com>*
> Sent by: hotspot-dev-bounces at openjdk.java.net
>
> 01/06/2010 09:06
>   To
> George H <george.dma at gmail.com>
> cc
> hotspot-dev at openjdk.java.net
> Subject
> Re: Suggestions for a custom bootstrap class loader
>
>
>
>
> 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
>
>
>
>
> ---
>
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and delete this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
>
> Please refer to http://www.db.com/en/content/eu_disclosures.htm for
> additional EU corporate and regulatory disclosures.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20100601/d41461a8/attachment.html 