We Keep Coding

JavaFX Application - What needs to be signed?

I'm deploying a JavaFX application and am not quite sure what does and doesn't need to be signed. Here are my thoughts:
- Installation file:
This obviously needs to be signed.
- The EXE that launches the application:
I believe this needs to be signed, although it feels a little bit funny because it isn't my code.
- My JAR files: I believe that these also need to be signed, although I'm not sure if anything terrible happens if I don't.
- Library JARs that I've grabbed off the internet: I don't feel like I should sign these. Is there any reason to?
- Java runtime:
I'm guessing there's no reason to sign this, and I'd probably violate some agreement if I do.
- JNLP file:
Not using this, no reason to touch this.
Have I looked at this properly? Am I signing the correct files?

A friend of mine has a saying " it's not what you did... it's what you can prove in court. "
With this respect, I advise you to look at this problem from a legal point of view and assume the worst possible context it can apply in; i.e. you becoming legally accountable after someone tampers with your software.
Digital signatures are designed especially for these types of problems.
With this respect, let's split your answer into 2 different classification parts:
the software you're releasing - includes your jars, jnlp, bundled .exes, etc.
all of these must be singed in order to ensure that you can't be affected by any unauthorized tempering with your own code. It doesn't matter whether or not you've released that jnlp. If someone generates an invasive one and it's traced back to you, your failure to authenticate your own released version of that jnlp will not be ok.
the software released by other people. - includes everything which you're using in order to get your system to work. (jre, libs)
when using something like this, it's a good idea to make sure you're using a genuine copy of whatever your lib manufacturer has released. Use their checksums/signatures/etc. to validate and verify their software integrity upon demand. You have to read their liability and disclaimer statements and in the event they fail to provide one themselves.
In general it is a good idea to place as little trust as possible when it comes to software sources other than yourself. Unfortunately, there are many compromised or malicious libs out there which are in fact security risks.
it is always a good idea to make sure you're releasing a downloaded lib which is certified by an external issuer and as such cannot be held responsible for any malicious code detected within.
To answer your question... it really depends on the client endpoint and the likelyhood of you getting sued for providing them with a security risk (i advise you to always expect this to be 100%). If you're liable for damages... you need to proceed accordingly.
In short... the best possible answer to this quesiton is to do whatever is possible to cover yourself in the event the worst happens.

Does your application need elevated privileges? If the installer is targeting Windows you wish to install the application to Program Files, then your installer will need to be signed. Without it, Windows will give a yellow banner during privilege escalation request.
So - sign your installer.
The exe that launches the application should ideally be signed as well. But for a java application, this is perhaps a mute point. Signing the exe is easy enough, that I'd just do it anyways.
Sign launcher exe - Optional, but I'd do it
Jar files. This is an interesting one and depends on what you goal is. Ie, the OS and the end user are probably not going to be aware of the signed or unsigned nature of your Jar. Therefore you will probably have to verify the integrity of the jar yourself. See https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html
Perhaps the launcher application can perform the integrity checks before the launch step ?
Library jars, Similar to the case above, if you want to make sure that no one has dropped in a diff jar into your application or some such use case, you will need to verify this yourself.
Java Runtime If you shipping this, is this not already signed by Oracle or your JVM vendor ?

Encrypting a JAR where source protection is a priority

I have a dilemma. Basically, I've given a group of people I'm friends with a program that utilizes source code that I don't want anyone outside the group knowing of. We all know Java is absolutely horrible at doing any level of obfuscation, as most obfuscation tools only rename objects, scramble code, etc. I've used such tools, but to be honest I'd like to go as far as possible with the security of the program.
Since the application requires a username, password, and other identifiers to log in to the server it uses, I was beginning to wonder if a unique AES key could be generated for the user to secure the JAR.
Basically, upon running a launcher of sorts to log in, the launcher app may request an AES key from the server, and use it to decrypt a secured JAR it's downloaded from the server already. The key would be completely unique to each user, which would mean the server would have to encrypt the JAR differently for each user.
Now, I know how crazy this sounds. But since this is such a low-level thing, I need to know if there is a way you can somehow both decrypt and run a JAR from any type of stream. Or, if that isn't possible, would it be reasonable to decrypt the file, run it, then re-encrypt it?

Of course you can decrypt and run Java bytecode on the fly - bytecode manipulation libraries such as ASM even go as far as creating new classes dynamically.
But, quite honestly, if something actually runs on a computer then its code is definitely going to be available to anyone with the knowledge. Java, especially, is even more convenient since it allows far better access to the bytecode of a class that is loaded by the JVM than any natively compiled language.
You could theoretically take your obfuscation a bit further by using JNA/JNI and a native shared library or two. But, in the hands of a determined attacker no measure will protect your code completely - it would just take more time for them to figure out how your algorithms work. And if you are concerned about piracy, well, we are in the era of virtualization; you can actually clone whole computer systems from top to bottom with a couple of key presses - you figure out the rest...
The only potentially viable solution would be to offer your software as a service, with all the issues entailed by that approach - and you would still not have absolute security.
If you are that concerned about protecting your intellectual property, then get a lawyer and consider publishing your algorithms in some form - obscurity will only go so far. It will not stop someone from doing black-box analysis on your system and quite often just knowing that something is possible is enough.
Please stop trying to find technical solutions to a problem that is so obviously not of a technical nature...

My answer would be to keep the server information outside of the jar entirely. Use a parameter or configuration file to point to where to get that information. Then the jar file has no secrets in it. Only the server where the code runs has that information. You can then do things like make the configuration file readable only by the user that can run the code in the jar.

What are common Java vulnerabilities?

What are common Java vulnerabilities that can be exploited to gain some sort of access to a system? I have been thinking about it recently, and havent been able to come up with much of anything - integer overflow - maybe? race condition - what does it give you?
I am not looking for things like "sql injection in a web app". I am looking for a relationship similar to buffer overflow - c/c++.
Any security experts out there that can help out? Thanks.

Malicious Code injection.
Because Java (or any language using an interpreter at runtime), performs linkage at runtime, it is possible to replace the expected JARs (the equivalent of DLLs and SOs) with malicious ones at runtime.
This is a vulnerability, which is combated since the first release of Java, using various mechanisms.
There are protections in places in the classloaders to ensure that java.* classes cannot be loaded from outside rt.jar (the runtime jar).
Additionally, security policies can be put in place to ensure that classes loaded from different sources are restricted to performing only a certain set of actions - the most obvious example is that of applets. Applets are constrained by the Java security policy model from reading or writing the file system etc; signed applets can request for certain permissions.
JARs can also be signed, and these signatures can be verified at runtime when they're loaded.
Packages can also be sealed to ensure that they come from the same codesource. This prevents an attacker from placing classes into your package, but capable of performing 'malicious' operations.
If you want to know why all of this is important, imagine a JDBC driver injected into the classpath that is capable of transmitting all SQL statements and their results to a remote third party. Well, I assume you get the picture now.

After reading most of the responses I think your question has been answered in an indirect way. I just wanted to point this out directly. Java doesn't suffer from the same problems you see in C/C++ because it protects the developer from these types of memory attacks (buffer overflow, heap overflow, etc). Those things can't happen. Because there is this fundamental protection in the language security vulnerabilities have moved up the stack.
They're now occurring at a higher level. SQL injection, XSS, DOS, etc. You could figure out a way to get Java to remotely load malicious code, but to do that would mean you'd need to exploit some other vulnerability at the services layer to remotely push code into a directory then trigger Java to load through a classloader. Remote attacks are theoretically possible, but with Java it's more complicated to exploit. And often if you can exploit some other vulnerability then why not just go after and cut java out of the loop. World writable directories where java code is loaded from could be used against you. But at this point is it really Java that's the problem or your sys admin or the vendor of some other service that is exploitable?
The only vulnerabilities that pose remote code potential I've seen in Java over the years have been from native code the VM loads. The libzip vulnerability, the gif file parsing, etc. And that's only been a handful of problems. Maybe one every 2-3 years. And again the vuln is native code loaded by the JVM not in Java code.
As a language Java is very secure. Even these issues I discussed that can be theoretically attacked have hooks in the platform to prevent them. Signing code thwarts most of this. However, very few Java programs run with a Security Manager installed. Mainly because of performance, usability, but mainly because these vulns are very limited in scope at best. Remote code loading in Java hasn't risen to epidemic levels that buffer overflows did in the late 90s/2000s for C/C++.
Java isn't bullet proof as a platform, but it's harder to exploit than the other fruit on the tree. And hackers are opportunistic and go for that low hanging fruit.

I'm not a security expert, but there are some modules in our company that we can't code in java because it is so easy to de-compile java bytecode. We looked at obfuscation but if you want real obfuscation it comes only with a lot of problems (performance hit/loss of debug information).
One could steal our logics, replace the module with a modified version that will return incorrect results etc...
So compared to C/C++, I guess this is one "vulnerability" that stands out.
We also have a software license mechanism built-in in our java modules, but this can also be easily hacked by de-compiling and modifying the code.

Including third party class files and calling upon them basically means you are running unsecure code. That code can do anything it wants if you don't have security turned on.

How to deliver a java program to a client?

I wrote a software application in Java. Now I want to deliver it to my clients. But before that, I want to do something on that software which are mentioned below. You can answer any or all of the below questions:
I want to:
Encrypt all the .class files so that no one can decompile it. How can I encrypt it?
After encryption I want to obfuscate that code to add extra safety. How can I do that?
Add some "serial-key" functionality so that the software works only after registering it with the key provided by me. This is very important so as to prevent multi-user usage of my software. How can I add that key functionality and how can I generate keys. And how can I restrict that software to work only on a single computer.
The jar file can be unzipped and the .class file can be seen. Is there any way to wrap jar file into something so that no one can unzip that file.
I don't want to tell the client to first install java to run my application. So is there any way by which if anyone installs my software, the java automatically gets installed on his/her computer without informing him that java is being installed to his computer. If it is possible, then Is it legal to use Java software in this way.
Change the icon of the jar file permanently.
Implement a code which checks my site for any available updates.
If you want any other suggestions to increase the security of the softwre, then you are welcomed too.

In no particular order:
2 - There are products that perform obfuscation. They typically rename classes / variables / methods to single letter names. This makes determining user reported errors rather difficult. Stack traces showing the exception occurs in a.b.c are not particularly helpful.
1,3,4 - You can't fully avoid this risk if your are distributing java. Your code needs to be unpacked and loaded at some point. If someone replaces rt.jar in the jvm then they can replace the top-level class loader and dump out your classes like that. Obfuscation makes this less useful for them, but see the above caveat.
5 - Distribute a "private jre". Basically, you have a jre in your program folder. Your launcher script runs it. Increases the size of your distribution though.
6 - On windows, this would be a file association issue. But that would also affect all other jar files. Unless as part of 4 (however you manage that) you also use a different extension. Not sure about other operating systems.
7 - Use Java Web Start? Failing that, just have a file on your server listing the most recent version, fetch the file and compare with the installed version.
For 1,2,4 and 5 you could also look into compiling to native code using gcj or similar. Beware of compatibility issues if you do that though.

Encrypt all the .class files so that no one can decompile it. How can
I encrypt it?
You can't. If no one can decompile it, how do you expect the target JVM to?
After encryption I want to obfuscate that code to add extra
safety. How can I do that?
I want to add some "serial-key"
functionality so that the software
works only after registering it with
the key provided by me. This is very
important so as to prevent multi-user
usage of my software. How can I add
that key functionality and how can I
generate keys. And how can I restrict
that software to work only on a single
computer.
There are a couple of ways to do this but a simple one is with public key cryptography:
Your software generates a random request ID or a request ID based on the machine attributes and your user submits this to you.
You sign the request ID with your private key and send it back to the user.
The user provides the signed request ID to the software which validates that it was signed by you.
The jar file can be unzipped and the .class file can be seen. Is there
any way to wrap jar file into
something so that no one can unzip
that file.
No
I don't want to tell the client to first install java to run my
application. So is there any way by
which if anyone installs my software,
the java automatically gets installed
on his/her computer without informing
him that java is being downloaded to
his computer. If it is possible, then
Is it legal to use Java software in
this way.
Try building an NSIS installer for your application that detects/installs Java and your program.

Build a better trust relationship with your clients.
Then you can spend extra time ( not doing tasks 1-5 ) to make improvements, fix bugs, etc., which in turn improves relationship with your clients.

You can compile it with GCJ, which will compile your application to a normal Windows/Linux native executable (.exe). Then you can create an installation, using a program like InstallShield.

The company where I work actually ships unobfuscated jar files, with all debug information in place. That way, if an error occurs at a client's site, they can send us the full stacktrace which helps enormously in analyzing and localizing bugs in the code.
Trying to obfuscate your code will lead you into an arms race with potential crackers and consume huge amounts of time with little or no real benefit. Instead, I'd advise you to try and find other ways to make buying (and not pirating) your software worthwhile to your clients. For example, you could offer them free updates, or tech support, or something like that.
As for 6: You can use JSmooth or a similar tool to create an exe wrapper for your app. It will allow you to change the icon, and your clients will have an exe file that they can doubleclick without having to mess with file associations for jar files.
Note, however, that the generated exe won't contain Java or your jar files. It will, however, print a nice error message if Java isn't available.

Just adding on to the other answers here:
1 and 4: You could actually do this if you modify the JVM and pre-package it with your installation, but it's against Java's license agreement to distribute a modified JVM without paying Sun like a billion dollars.

Who is your client? Piratebay.org? Seriously, every major company in the US pays for software. The risk of a client quitting and calling them in is just too high. You need enough protection to make it easier for a programmer to get purchasing to pay for the product than to circumvent your copy protection.

Java Applet - Partially Signed?

Is it possible to sign only part of an applet? Ie, have an applet that pops up no security warnings about being signed, but if some particular function is used (that requires privileges) then use the signed jar?
From what I can tell, some (perhaps most) browsers will pop up the warning for a signed applet even if you don't request privileges at all at execution time. I'd rather avoid that if possible.

Try splitting your code into an unsigned jar and a signed jar.

In theory you can (signed + unsigned jar), but in practice it will result that your code will be handled as unsigned. The access decision should be made from the thread, not the immediate caller. If the thread contains in the stack a call made from an object from unsigned code, the whole call should be treated as unsigned. If you work around this you've found a bug.
In other words... No.
If I'm not being to curious, may I inquire why do you want to partially sign your code?

I've been given the impression that Sun wants to discourage the creation of Applets and encourage the usage of Java Web Start. I think this issue of signing applets is part of the problem. See this documentation from Sun: Java Web start FAQ.
I haven't tried this, but could you segment the features that need signing into separate jars that only require permission checks when the user needs the functionality in those jars?