in 1999 i wrote a paper on security in set-top boxes (one of my first papers); yay. but, one approach we had was to build a custom class loader that would actually load encrypted classes.
the details of the paper are:
1999 - Security in Set-Top boxes European Multimedia, Embedded Systems and Electronic Commerce EMMSEC '99, Stockholm, SWEDEN June 21-23, 1999
The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details
I have implemented an encrypted class loader that never delivers the unencrypted bytes to the java class. The author of this article is mostly correct, and I have read this article before. He states the following:
until JVM architecture changes to, say, support class decoding inside native code...
This is already possible and I have implemented it. It involves making direct calls to the jvm libraries from JNI rather than callbacks to java from JNI. There is still a way to get the bytes, but it involves hacking native code...a much harder task.
another alternative = encrypted class files (Score:5, Interesting)
the details of the paper are:
1999 - Security in Set-Top boxes
European Multimedia, Embedded Systems and Electronic Commerce
EMMSEC '99, Stockholm, SWEDEN
June 21-23, 1999
COPY: (pdf)
http://www.ardiri.com/publications/emmsec9 9
there was a lot of interest on this topic back in the time
Doesn't work (Score:5, Informative)
There are a number of papers and articles detailing why this type of approach to "IP security" is so misguided. One such article is here: http://www.javaworld.com/javaworld/javaqa/2003-05/ 01-qa-0509-jcrypt.html [javaworld.com]
The crux is that at some point in time, you have to deliver the encrypted class to the JVM in an unencrypted format. Intercepting this delivery is incredibly easy (no expert knowledge required, the details
Re:Doesn't work (Score:2)
until JVM architecture changes to, say, support class decoding inside native code...
This is already possible and I have implemented it. It involves making direct calls to the jvm libraries from JNI rather than callbacks to java from JNI. There is still a way to get the bytes, but it involves hacking native code...a much harder task.
-Dan