encrypted source file support in jdk?

java-programmer, encrypted source file support in jdk? Hi

I an wondering if anybody knows if its possible to extend the
functionality of the sun java compiler/vm in jdk6, with for example
plugins or similar? or if the jdk supports something similar already?

What I am looking for is to set up a jdk environment where the source
code is ecrypted at the file level. This requires javac to be able to
en-/decrypt the source files. For further protection, the jvm would need
such support as well.

some details:

To answer the typical question first. For this scenario I am not
interrested in encrytpted filesystems, because it still leaves the
files vulnerable as long as the filesystem is mounted. The secrecy of
the files can still be compromised from hacking, virus, trojans, skype,
xss and all other sorts of system hacking. With encrypted files the
information in the files are still protected, even in the case a trojan
sends a file by email to somebody on the internet. Enctrypted
filesystems only help protect the integrity of the local system and the
disk while the system/disk is not running. Encrypted files help protect
the information during use as well.

I know there are many other issues as well, I'll be working throuhg it.
here is the list of the issues of most importance:

- en-/decryption support in
- ide / editor
- compiler
- code searching tools
- disassembler/debugger
- remove excess information from class files
- how to handle static content files
- html, css, jsp, configuration files for libraries and frameworks etc
- if class files are also encrypted
- en-/decryption support in the jvm runtime, covers tomcat, jboss etc.
- possible encrypted jar/war/ear files etc
- debugger
- information about classes must also be protected from prying
eyes who have obtained the class files and using the debugger to get
information.

java-programmer >> encrypted source file support in jdk? Tom Forsmo wrote:
> Hi
>
> I an wondering if anybody knows if its possible to extend the
> functionality of the sun java compiler/vm in jdk6, with for example
> plugins or similar? or if the jdk supports something similar already?
>
> What I am looking for is to set up a jdk environment where the source
> code is ecrypted at the file level. This requires javac to be able to
> en-/decrypt the source files. For further protection, the jvm would need
> such support as well.

Use the encrypted file capability of your host operating system, or pipe the
source through a decryptor on the way to the compiler.

--
Lew

java-programmer >> encrypted source file support in jdk? Lew wrote:
> Tom Forsmo wrote:
>> Hi
>>
>> I an wondering if anybody knows if its possible to extend the
>> functionality of the sun java compiler/vm in jdk6, with for example
>> plugins or similar? or if the jdk supports something similar already?
>>
>> What I am looking for is to set up a jdk environment where the source
>> code is ecrypted at the file level. This requires javac to be able to
>> en-/decrypt the source files. For further protection, the jvm would
>> need such support as well.
>
> Use the encrypted file capability of your host operating system,

As I stated further down in the post, that is a solution which is not
relevant for this scenario. Becuase does not solve this problem.

> or pipe
> the source through a decryptor on the way to the compiler.

that is a possibility, if the tools used supports feeding the tool with
input through a pipe. I think that might be a problem in java since the
compiler requires files to be located in directories according to their
package names and directory structures can not be communicated through pipes

any solution would have to be integrated into the IDE so that the IDE
can cache keys so the user dont have to enter the password every time
and so that only the IDE environment has access to the decrypted files
(i.e. if its the tool that decrypts the password must be cached by the
tool for the user does not have to type the password everytime. If the
tool caches the password, then anybody can actually run the tool and get
unenecrypted access to the source code.

My current thinking is that it should be integrated at the application
level, i.e. the ide/tools(java, javac) since then the solution is
portable to all platforms. A solution made for the OS or as a middleman
script etc, can not necessarily be utilised on all platforms easily.

regards

tom

java-programmer >> encrypted source file support in jdk? Tom Forsmo wrote:

> Hi
>
> I an wondering if anybody knows if its possible to extend the
> functionality of the sun java compiler/vm in jdk6, with for example
> plugins or similar? or if the jdk supports something similar already?
>
> What I am looking for is to set up a jdk environment where the source
> code is ecrypted at the file level. This requires javac to be able to
> en-/decrypt the source files. For further protection, the jvm would need
> such support as well.
>
> some details:
>
> To answer the typical question first. For this scenario I am not
> interrested in encrytpted filesystems, because it still leaves the
> files vulnerable as long as the filesystem is mounted. The secrecy of
> the files can still be compromised from hacking, virus, trojans, skype,
> xss and all other sorts of system hacking. With encrypted files the
> information in the files are still protected, even in the case a trojan
> sends a file by email to somebody on the internet. Enctrypted
> filesystems only help protect the integrity of the local system and the
> disk while the system/disk is not running. Encrypted files help protect
> the information during use as well.
>
> I know there are many other issues as well, I'll be working throuhg it.
> here is the list of the issues of most importance:
>
> - en-/decryption support in
> - ide / editor
> - compiler
> - code searching tools
> - disassembler/debugger
> - remove excess information from class files
> - how to handle static content files
> - html, css, jsp, configuration files for libraries and frameworks etc
> - if class files are also encrypted
> - en-/decryption support in the jvm runtime, covers tomcat, jboss etc.
> - possible encrypted jar/war/ear files etc
> - debugger
> - information about classes must also be protected from prying
> eyes who have obtained the class files and using the debugger to get
> information.

If you are that paranoid, why are you

a) running Windows
b) connected to the Internet?

--
Nigel Wade, System Administrator, Space Plasma Physics Group,
University of Leicester, Leicester, LE1 7RH, UK
E-mail : email***@***.com
Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555

java-programmer >> encrypted source file support in jdk? Nigel Wade wrote:
> If you are that paranoid, why are you

> a) running Windows

I am not running windows.

> b) connected to the Internet?

Thats quite a naive statement. do you actually think industrial
espionage does not exists? The biggest threat to internet security these
days are all the viruses, trojans etc which are now developed by
international organised crime to extort money or sell information.
The only way to reduce the risk of these malwares are by encrypting the
actual files.

regards

tom

java-programmer >> encrypted source file support in jdk? On Thu, 27 Sep 2007 13:17:55 +0100, Tom Forsmo <email***@***.com> wrote:

> I know there are many other issues as well, I'll be working throuhg it.
> here is the list of the issues of most importance:
>
> - en-/decryption support in

...

> - disassembler/debugger
> - remove excess information from class files

You can do this bit with an obfuscator, such as Proguard
(http://proguard.sourceforge.net).

> - if class files are also encrypted
> - en-/decryption support in the jvm runtime, covers tomcat, jboss etc.
> - possible encrypted jar/war/ear files etc
> - debugger
> - information about classes must also be protected from prying
> eyes who have obtained the class files and using the debugger to get
> information.

This is a common suggestion for protecting class files but it won't work
(see
http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html).

Dan.

--
Daniel Dyer
http://www.uncommons.org

java-programmer >> encrypted source file support in jdk? Tom Forsmo wrote:
> The biggest threat to internet security these
> days are all the viruses, trojans etc which are now developed by
> international organised crime to extort money or sell information.
> The only way to reduce the risk of these malwares are by encrypting the
> actual files.

Some combination of the JSE 6 javax.tools package interfaces (JSR 199 compiler
API) and the new support for encryption should give you the capability you desire.

--
Lew

java-programmer >> encrypted source file support in jdk? In article <fdg739$6g8$email***@***.com>, Tom Forsmo <email***@***.com> wrote:
>Hi
>
>I an wondering if anybody knows if its possible to extend the
>functionality of the sun java compiler/vm in jdk6, with for example
>plugins or similar? or if the jdk supports something similar already?
>
> (...)
> - debugger
> - information about classes must also be protected from prying
>eyes who have obtained the class files and using the debugger to get
>information.

If you are looking to protect your code from the owner/user of the
system, then you can only do this if all the software that is capable
of decrypting your ciphertext /and/ all instances of decrypted
cleartext are run and stored on a piece of hardware that is
effectively under your control.

You might achieve this by giving the user a dongle with a processor in
it (a SmartCard perhaps) that is actually running the software and
presenting /only/ the final results of the software's computations to
the computer. Not knowing what your software actually does, I can't
comment on what sort of protocols you'd need in order to achieve this.

Or you might require the user to be online and use an internet site of
yours as a "remote dongle" where everything is actually run. This
effectively converts your software into a web-application-like animal.

Cheers
Bent D
--
Bent Dalager - email***@***.com - http://www.pvv.org/~bcd
powered by emacs

java-programmer >> encrypted source file support in jdk? On Thu, 27 Sep 2007 14:17:55 +0200, Tom Forsmo <email***@***.com> wrote:

>Hi
>
>I an wondering if anybody knows if its possible to extend the
>functionality of the sun java compiler/vm in jdk6, with for example
>plugins or similar? or if the jdk supports something similar already?
>
>What I am looking for is to set up a jdk environment where the source
>code is ecrypted at the file level. This requires javac to be able to
>en-/decrypt the source files. For further protection, the jvm would need
>such support as well.
Encryption is a solution to a problem. Since I am not clear what your
roblen is then is is difficult for me to suggest a solution, or even
if encryption is the right solutin to your problem.

You want to protect your source files. Why? Do you have some
super-secret algorithm in your program that a competitor wants to get
their hands on?

Are you writing a virus that you want to encrypt so that it avoids
virus detectors?

Do you want to stop people copying your code and running it without
paying you?

If you are so interested in keeping your source code secret, then why
are you using Java? C++ with a highly optimising compiler will do
more to obscure the source code than any Java obfuscator.

>
>some details:
>
>To answer the typical question first. For this scenario I am not
>interrested in encrytpted filesystems, because it still leaves the
>files vulnerable as long as the filesystem is mounted. The secrecy of
>the files can still be compromised from hacking, virus, trojans, skype,
>xss and all other sorts of system hacking. With encrypted files the
>information in the files are still protected, even in the case a trojan
>sends a file by email to somebody on the internet.
No. Any piece of memory can be copied to the swap file, so in
principle anything that is in memory can also appear on disk. Since
at some point the executable byte code, and the executable machine
code, must be in memory then the level of security you seem to be
looking for is not possible.

>Enctrypted filesystems only help protect the integrity of the local system and the
>disk while the system/disk is not running. Encrypted files help protect
>the information during use as well.
>
>I know there are many other issues as well, I'll be working throuhg it.
>here is the list of the issues of most importance:
>
>- en-/decryption support in
> - ide / editor
> - compiler
> - code searching tools
Do you want to encrypt your source files during development as well as
during operation?

>- disassembler/debugger
> - remove excess information from class files
As I said, use C++ or another compiled language instead of Java and
this problem goes away.

>- how to handle static content files
> - html, css, jsp, configuration files for libraries and frameworks etc
Easy enough to encrypt or obscure - anything from ROT13 to AES
depending on what you are hiding them from. ROT13 will protect from
your kid sister, AES (properly used) will protect from Nasty Megacorp
Inc.

rossum

>- if class files are also encrypted
> - en-/decryption support in the jvm runtime, covers tomcat, jboss etc.
> - possible encrypted jar/war/ear files etc
> - debugger
> - information about classes must also be protected from prying
>eyes who have obtained the class files and using the debugger to get
>information.

java-programmer >> encrypted source file support in jdk? Tom Forsmo wrote:
>> or pipe the source through a decryptor on the way to the compiler.
>
> that is a possibility, if the tools used supports feeding the tool with
> input through a pipe. I think that might be a problem in java since the
> compiler requires files to be located in directories according to their
> package names and directory structures can not be communicated through
> pipes

Look into the javax.tools package (since Java 6).

> any solution would have to be integrated into the IDE so that the IDE
> can cache keys so the user dont have to enter the password every time
> and so that only the IDE environment has access to the decrypted files
> (i.e. if its the tool that decrypts the password must be cached by the
> tool for the user does not have to type the password everytime. If the
> tool caches the password, then anybody can actually run the tool and get
> unenecrypted access to the source code.

Integrating into IDEs is a whole other can of worms...

> My current thinking is that it should be integrated at the application
> level, i.e. the ide/tools(java, javac) since then the solution is
> portable to all platforms. A solution made for the OS or as a middleman
> script etc, can not necessarily be utilised on all platforms easily.

... except it might be worthwhile to create pseudo-javac's that executes
some Java code that uses javax.tools.

If you really want to get down and dirty, start going through the Java
source code with regard to the stuff in tool.jar

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth

java-programmer >> encrypted source file support in jdk? On Thu, 27 Sep 2007 14:17:55 +0200, Tom Forsmo <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>What I am looking for is to set up a jdk environment where the source
>code is ecrypted at the file level. This requires javac to be able to
>en-/decrypt the source files. For further protection, the jvm would need
>such support as well.

You can either do this with JCE, see
http://mindprod.com/jgloss/jce.html

If your files are short, and you want a lightweight solution that uses
public key cryptography without needing the JCE library installed, see
http://mindprod.com/products1.html#TRANSPORTER

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> encrypted source file support in jdk? On Thu, 27 Sep 2007 14:17:55 +0200, Tom Forsmo <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>I an wondering if anybody knows if its possible to extend the
>functionality of the sun java compiler/vm in jdk6, with for example
>plugins or similar? or if the jdk supports something similar already?

other things to look into:

1. ZIP encryption. http://mindprod.com/jgloss/zip.html
2. Secure Thumbdrives with a en embedded private key
http://mindprod.com/bgloss/thumbdrive.html

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> encrypted source file support in jdk? Daniel Dyer wrote:
> On Thu, 27 Sep 2007 13:17:55 +0100, Tom Forsmo <email***@***.com> wrote:
>> - if class files are also encrypted
>
> This is a common suggestion for protecting class files but it won't work
> (see
> http://www.javaworld.com/javaworld/javaqa/2003-05/01-qa-0509-jcrypt.html).

Not quite, the scenario described in that article is for when you sell a
binary and want to protect the binary. Of course, that would not work
because the users must have the password to decrypt the files in the
classloader and of course anybody can listen in if they have the password.

My scenario is for protecting source/class files where only a limited
number of people have access to it, such as for internal use during
development of a new product etc. or if you dont sell the code, but
sell a web service that only you provide. In such situations class files
can be protected on the server with this scheme.

But you will allways have the problem of protecting the machine from
directed hacking, so they can not tamper with your rt environment or
similar. but that is allways a concern. If they have root access its
difficult to protect from anythin, unless you start using ACLs and
role-based security (used in military systems).

regards

tom

java-programmer >> encrypted source file support in jdk? Bent C Dalager wrote:
> In article <fdg739$6g8$email***@***.com>, Tom Forsmo <email***@***.com> wrote:
>> Hi
>>
>> I an wondering if anybody knows if its possible to extend the
>> functionality of the sun java compiler/vm in jdk6, with for example
>> plugins or similar? or if the jdk supports something similar already?
>>
>> (...)
>> - debugger
>> - information about classes must also be protected from prying
>> eyes who have obtained the class files and using the debugger to get
>> information.
>
> If you are looking to protect your code from the owner/user of the
> system, then you can only do this if all the software that is capable
> of decrypting your ciphertext /and/ all instances of decrypted
> cleartext are run and stored on a piece of hardware that is
> effectively under your control.

What I was thinking of here was if somebody had illegally obtained the
class files, and using debugging to reverse engineer the code. The usage
scenario is that the class files are not public either, therefor no one
should have a copy of the class files either, except for the people
working in the company that owns the code.

Its not about protecting binaries sold to customer. Its about protecting
IP of internal projects in progress, in the same way you would protect
marketing plans etc.

regards

tom

java-programmer >> encrypted source file support in jdk? rossum wrote:
> On Thu, 27 Sep 2007 14:17:55 +0200, Tom Forsmo <email***@***.com> wrote:
>
> Encryption is a solution to a problem. Since I am not clear what your
> roblen is then is is difficult for me to suggest a solution, or even
> if encryption is the right solutin to your problem.
>
> You want to protect your source files. Why? Do you have some
> super-secret algorithm in your program that a competitor wants to get
> their hands on?

Sorry to have to say this, but why is none of your business.
Every company has its intelectual property it wants to protect, if not
then lets just open all gateways and firewalls. That does not seem right
does it?
Try a little more open minded thinking next time you ask questions, dont
just assume the person you are talking to is asswipe.

> Are you writing a virus that you want to encrypt so that it avoids
> virus detectors?
>
> Do you want to stop people copying your code and running it without
> paying you?
>
> If you are so interested in keeping your source code secret, then why
> are you using Java? C++ with a highly optimising compiler will do
> more to obscure the source code than any Java obfuscator.

read the original post a little close or read my other replys, maybe you
find some asnwers.

>> some details:
>>
>> To answer the typical question first. For this scenario I am not
>> interrested in encrytpted filesystems, because it still leaves the
>> files vulnerable as long as the filesystem is mounted. The secrecy of
>> the files can still be compromised from hacking, virus, trojans, skype,
>> xss and all other sorts of system hacking. With encrypted files the
>> information in the files are still protected, even in the case a trojan
>> sends a file by email to somebody on the internet.
> No. Any piece of memory can be copied to the swap file, so in
> principle anything that is in memory can also appear on disk. Since
> at some point the executable byte code, and the executable machine
> code, must be in memory then the level of security you seem to be
> looking for is not possible.

That is why i mentioned encrypted filessystem to protect the system, and
that includes protecting swap as well.

>
>> Enctrypted filesystems only help protect the integrity of the local system and the
>> disk while the system/disk is not running. Encrypted files help protect
>> the information during use as well.
>>
>> I know there are many other issues as well, I'll be working throuhg it.
>> here is the list of the issues of most importance:
>>
>> - en-/decryption support in
>> - ide / editor
>> - compiler
>> - code searching tools
> Do you want to encrypt your source files during development as well as
> during operation?

at least until the product is released to the public.

regards

tom

java-programmer >> encrypted source file support in jdk? tom forsmo wrote:
..
>Sorry to have to say this, but why is none of your business.

Sure, but then your *original* question becomes none
of our business (or particular concern) either.

If you have a question that is so secret and special that
the details can only be shared with trusted persons, it is
best to take it to a consultant or help desk.

This, on the other, is a discussion forum, so if you post
here, please be prepared to discuss the matter.

--
Andrew Thompson
http://www.athompson.info/andrew/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-setup/200709/1

java-programmer >> encrypted source file support in jdk? >What I am looking for is to set up a jdk environment where the source
>code is ecrypted at the file level.

You might also be thinking about obfuscating.
See http://mindprod.com/jgloss/obfuscator.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> encrypted source file support in jdk? Andrew Thompson wrote:
> tom forsmo wrote:
> ..
>> Sorry to have to say this, but why is none of your business.
>
> Sure, but then your *original* question becomes none
> of our business (or particular concern) either.

I am asking how to keep specified things secret, and that is certainly
something I am willing to discuss. What the particular source code I
want to keep secret is, is nobodys business. Thats why its called a secret.

regards

tom

java-programmer >> encrypted source file support in jdk? On Fri, 28 Sep 2007 08:42:41 +0200, tom forsmo <email***@***.com>
wrote, quoted or indirectly quoted someone who said :

>Try a little more open minded thinking next time you ask questions, dont
>just assume the person you are talking to is asswipe.

Quite often people want to spend huge amounts protecting software that
nobody wants to pirate. They think it is just the thing to do. There
are legal remedies as well.

Usually all you want is just to make it more expensive to crack your
code than compose it from scratch. The problem is, even with native
compilation, all you can do is slow down a determined hacker. After
all, the CPU has to crack the code to run it, so in principle all the
information needed is also available to the hacker.

To block brute force attacks you pretty well have to make the program
mutate and get fresh information frequently from the net, information
the hacker does not have in advance.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

java-programmer >> encrypted source file support in jdk? Roedy Green wrote:
> On Fri, 28 Sep 2007 08:42:41 +0200, tom forsmo <email***@***.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> Try a little more open minded thinking next time you ask questions, dont
>> just assume the person you are talking to is asswipe.
>
> Quite often people want to spend huge amounts protecting software that
> nobody wants to pirate. They think it is just the thing to do. There
> are legal remedies as well.

First of all, when you create something you hope it will be of interest
to others. So the only resonable thing to do is to protect it as best
you can (unless its an open source project). If you create something
that is going into a market with f.ex. intense competition and you are
certain that BigDollars are going to notice and perhaps copy, then legal
remedies does not help you. since the legal system is slow and by the
time its finished there, they might have copied all your ideas, bundled
it with their systems and marketing plans, made you spend so much money
on legal stuff that you are unable to actually do something in the
market or even develop the product furhter. And by the time the case is
over, they have 100 million customers using their solution while you are
broke and the company has next to no market share.

To explain again, what I am looking for is a way to protect the SOURCE
CODE and CLASS FILES during DEVELOPMENT, that means only when the code
is in-house. I am not talking about protecting class files distributed
to the public.
It could perhaps be of interrest to protect the class files, but thats
only relevant if I am the only one with access to the class files, for
example when of I provide a web service where the class files are never
distributed to the public.

> Usually all you want is just to make it more expensive to crack your
> code than compose it from scratch. The problem is, even with native
> compilation, all you can do is slow down a determined hacker. After
> all, the CPU has to crack the code to run it, so in principle all the
> information needed is also available to the hacker.
>
> To block brute force attacks you pretty well have to make the program
> mutate and get fresh information frequently from the net, information
> the hacker does not have in advance.

I dont agree that just because you cant get 100% security, you should
abstain from any security.

regards

tom