signed Applets : Java Glossary

Signed Applets are a technique of adding a digital signature to an Applet to prove that it came untampered from a particular trusted author. Signed Applets can be given more privileges that ordinary Applets. They even allow someone finding a jar file floating about the Internet to know that file is what it purports to be, even without checking with the author’s website.

Signed Applets are potentially dangerous. They have power to potentially damage your machine, e.g erase all your files or format your hard disk, or post your diary on LiveJournal. Just because an Applet is signed does not make it safe. Anyone, even a terrorist, can write a signed Applet. There are many schemes for signing and OKing signed Applets to run on your machine. I will concentrate on the most recent scheme.

Sun Plugin 1.3+ RSA (Rivest, Shamir and Adelman) Plug-in Style Applet Signing

This signing schemes uses a policy file where the system administrator pre clears certain dangerous Applets to run without asking the user. It is supported by Opera, Firefox, SeaMonkey and IE (Internet Explorer). Permission can also be a simple go/no go user grant, or individual permissions to do a variety of dangerous deeds.

Unless you are forced to support other styles of signing at gunpoint, I suggest you ignore every signing scheme but his one. Demand your clients upgrade to recent browsers that support the latest Sun JVM (Java Virtual Machine). Here is the basic recipe for making your Applet work with Sun-style signing:

1. Buy a Sun Java Code Signing certificate from Thawte. You use keytool to create your certificate request. You then send the public key part of your certificate to Thawte for them to digitally sign as authentic and return to you. You don’t disclose your private key to Thawte.
2. Alternatively, after reading my warnings, you can create a free phony certificate using keytool.
3. Write your Applet as normal Java code. You don’t need to include any special permission-asking code. Just go ahead and do naughty things like read the local hard disk or talk to servers other than mother. Normally, your Applet just goes ahead and does what it wants, without any sort of pre-check. If it gets a SecurityException, it catches the exception and does its best to carry on. A signed Applet that was not granted permission can still do useful work, recovering from SecurityException exception after SecurityException the way Wassup does. However, if you want to avoid SecurityExceptions in the middle of your application code, you can do probes like this to see if you have permission:
4. Then build your Applet as normal in a jar using jar.exe.
5. Then sign your jar using jarsigner.
6. If you want others to be able to use your Applet without hassle they must import your phony cert into their browsers as an officially accepted cert. This is not strictly necessary, but if you don’t do this, Sun will disparage your Applet and discourage users from granting it permission. For real certs you can skip this step so long at the browser has the root cert for the signing authority installed.
7. You might consider adjusting the policy file at client sites to either give your Applet permission to run without having to OK it each time, or to control precisely what is it allowed to do, in terms of where on disk it can write and just what naughty things it is allowed to do. You, as programmer, don’t control your client’s policy files. Typically some site administrator bureaucrat does and he puts the same policy files on nearly every desk in the institution.

java.policy

It is actually a little more complicated than that. There are three files to be concerned with: J:\Program Files\java\jdk1.8.0_131\ \jre\lib\security\java.security points to the policy files, usually two, one called: J:\Program Files\java\jdk1.8.0_131\ \jre\lib\security\java.policy and the other called user.home/.java.policy. To find out what user.home is, check out the system properties with Wassup. It will be something like C:\Documents and Settings\%username%. And if that was not confusing enough, the JDK (Java Development Kit) has two JRE (Java Runtime Environment) s, the public one in C:\Program Files\java\jre1.8.0_131\ and the debugging one in J:\Program Files\java\jdk1.8.0_131\ \jre each with its own set of policy files.

.keystore

cacerts

%JRE64\lib\security\cacerts

One common error to make is to change the wrong copy of cacerts., .keystore or java.policy. If you don’t know what you are doing, change them all!

Enhancements in Java version 1.3 or later

When Do You Need to Sign?

Overall Process of Creating A Signed Applet

• Buy a certificate or forge one. Do this well in advance. It is quite a song and dance to get one. You may need a DUNS number, a listed business phone number, a passport, a document from a notary…
• If you use a phony certificate, you will probably want in some way install it on all client’s machines. Techniques vary. See how I do it. If you use a real one, that step should not be necessary.
• Write your Java code. This may require method calls to request fine grain permission. Coarse grain security does not require these. Make sure you never execute these calls unless you are running under the appropriate browser. The necessary classes won’t be present otherwise and further they don’t like being called outside the browser.
• Create a jar, picking the files you need from all over. I use ant and genjar.
• Sign the jar with jarsigner. I use ant and the signjar task. Oddly signjar uses jarsigner.exe.
• In some corporations, the administrator will install a fine-grain policy file on all the client machines, (such as C:\WinNT\Profiles\username\policy.java ). You have to talk him into modifying that file to give you the permissions you need.
• When you run the Applet, grant the requested privileges.

Avoiding Signed Applets

This gives blanket permission to all locally created Applets to do what they please.

Other ways to avoid signing are converting your Applets to applications by adding a main method. See Applet for how. This can be useful for debugging. Get the Applet working as an application first, then worry about Appletness and signing later. Also consider Java Web Start as an alternative to Applets.

Signed Applet Tutorials and Documentation

• See Daniel Griscom’s cookbook essay on how to digitally sign Applets (and request privileged capabilities).
• Thawte Code-Signing Overview.
• See Thawte’s Code Signing Guide.
• To learn about the keytool, jar, policytool and jarsigner tools of the JDK, and the .keystore, java.policy and cacerts files.
• See Apple Applet Signing with MRJ (Macintosh Runtime for Java) and Javakey. See also Apple’s Java page.
• If you buy a Symantec Verisign certificate, you will be put on a mail list that sporadically emails you information about signing.

Tame vs Wild Applets

In contrast, a wild Applet is intended to be run by the general public without any special preparation such as installing a certificate or policy file. A wild Applet in one you might just stumble across in your web browsing. You don’t know much about the author. The Applet might be signed, self-signed or unsigned. If there are any security decisions to me made, the browser asks the end user for permission each time the Applet is run, using technobabble.

Some security schemes are aimed at writing tame and others at writing wild Applets. User grant schemes are primarily for wild Applets, where the java.policy schemes are primarily for tame Applets.

Tame schemes typically use an ASCII (American Standard Code for Information Interchange) policy text file that describes all the Applets, users and websites and what permissions each has. It is thus just about impossible for an individual Applet to automatically maintain. It is designed to be maintained by a network administrator who tightly controls just what can be run. The policy files can also control the activities of applications. Most people find it easier to compose the policy file with a text editor than using Oracle’s GUI (Graphic User Interface) policytool.

Tame schemes typically use a certificate file completely separate from the browser’s list of root certificates. This is managed by keytool. Again certificates from all different Applets are merged in this file. This makes it almost impossible for an Applet to manage its certificates. The network administrator must compose and control this file.

Signed Applet Jars

• MANIFEST.MF (the manifest) containing the SHA-1 (Secure Hash Algorithm 1) digests of each of your class files.
• MINDPROD.SF (the signing manifest) containing the SHA-1 digests (computed with your certificate) of each of your class files and the signature of the jar as a whole.
• MINDPROD.DSA (or MINDPROD.RSA) the public key from your code-signing certificate. It is a binary file, not human readable.

Signed Applet Tips

1. If the end user refuses to grant permission, your Applet will run anyway! It has to soldier on somehow without permission. It can either:
   • Die on a  java.security.AccessControlException leaving people to think your Applet has a bug.
   • Catch the  java.security.AccessControlException and give some explanation for poor performance to the user.
   • Check if the user has granted permission and if not, chastise the user for lack of trust and possibly carry on in some degraded mode.
2. Use a proxy server so that your Applet will talk only to one host, even if two hosts actually service its requests. Then you don’t need a signed Applet.
3. The policy file is just an ASCII text file. It is quite a bit easier to manipulate it with a text editor than the policytool GUI.
4. You need to order your digital certificates well in advance. You need to know which kinds to order. You will need a corporate DUNS (Dun & Bradstreet Universal Numbering System) number to apply.
5. There are many different Applet security/signing schemes, including two for Netscape, two for Internet Explorer, two for Oracle’s Java version 1.1 Plugin, two for Oracle’s  Java version 1.2 Plugin, five for Oracle’s  Java version 1.3 or later Plugin/Web Start and one for the Macintosh. Each kind uses a different type of signing certificate, though there are some multi-purpose certificates you can buy. You have the possibility of self-signed dummy certificates or real ones from Thawte or Verisign. On top of that you have the choice of coarse or fine-grain capabilities. Make sure you are ordering the right kind of code signing certificate. You want a Java version 1.5 code signing certificate.
6. The Applet must download and install the needed DLLs (Dynamic Link Libraries) and certificates on the client machine in magic directories. This is extremely difficult to do, but a piece of cake with JWS (Java Web Start).
7. You need to write JNI (Java Native Interface) glue to your native C++/C/ASM code.
8. Oracle’s JNI tutorials presume Solaris and have no hints on how to handle NT and Windows issues.
9. Signed Applets take much longer to load because of the CPU-intensive verifying of the signatures of each class. Don’t sign jars just for the heck of it.
10. You are best to tackle JNI in applications and signed Applets without JNI separately before combining them. For details on how, see JNI.
11. You can use the Wassup Amanuensis to find out what your browser thinks the user.home directory is and what it is using for a java.class.path and any other system properties.
12. For the Internet Explorer RSA certificate-based schemes, or with a Thawte DSA (Digital Signature Algorithm) Java Plug-In certificate, you don’t need to install the certificate on the client machine, just sign the jar file with your expensive certificate. The signing authority root certificate that Opera, Firefox, SeaMonkey or Microsoft pre-install in the browser is sufficient to check authenticity of your signed jar. See certificate for more details.
13. You can create your own free self-signed phony certificates, but then somehow you must pre-install them on the client’s machine. The main time the hassle of self-signed certificates would be practical is if you had control of all the client machines and were not allowing the general public to use your Applets.
14. For you to be able to verify jars without installing your signing certificate on all the client machines, there needs to be a chain of trusted authorities and automatic verification of public keys with those authorities. Signed Applets are not magic cloak to protect you from bugs. Any boob can create a phony certificate using the signing tools and sign the Applet with it. (You do this when you are debugging and waiting for your real certificate to arrive.) Further, even a trusted author can write buggy code. See my essay on the general theory of digital certificates based on Steven C. Den Beste’s work.
15. Java’s impregnable Applet security is a bit like France’s impregnable Maginot line prior to the second world war. Hitler simply went around it. Windows security is Swiss cheese, so it is easy to attack Java from the rear by replacing the various executables with doctored versions.

Java Web Start

Just when you thought you were beginning to understand all this, Sun invented yet another type of sandbox called Java Web Start. JWS apps are usually signed, but they work more like ordinary applications.

Revoking Perpetual Grant

You can get into a situation when Java no longer asks you if you want to grant permission to a signed Applet to do dangerous things. How can you get it to start asking permission again?

1. Click Start
2. Click Control Panel
3. Tlick Programs
4. Click Java
5. Under Temporary Internet Files, click Settings
6. Click Delete Files
7. Click Security
8. Click Certificates
9. Remove certificates you want to start manually granting.

Signed Applet Tips For Obsolete Signing Schemes

1. If the user of the signed Applet is behind a firewall, for some strange reason, if he invokes the Applet using the IP (Internet Protocol) rather than the DNS name of the website in the codebase e.g CODEBASE="http:// 65.110.21.43 /"" instead of CODEBASE=mindprod.com", all works. Otherwise you get a trustProxy Property error message. This problem may have been fixed.
2. The fiends who devised these security schemes should be shot. The designs deliberately make it very difficult to write a single piece of code that will work under all security schemes. You pretty well have to maintain three separate versions of your code, one for Netscape, one for Internet Explorer and one for the various versions of the Java Plug-in. Thankfully the older schemes have all but disappeared. It is even hard to find documentation on them any more. Good riddance!
3. Netscape wants a jar file and IE a cab for its proprietary scheme. Mostly today IE uses the Java version 1.3 or later scheme.
4. With the Netscape scheme, permission is granted only until the immediate caller of the permission-granting method exits. You can’t introduce even one layer of indirection, or your permissions immediately expire.
5. Each scheme uses different exceptions, which have to nest neatly with try blocks. You must be careful never to execute any code from another security scheme, because its classes won’t be available. Happily, with Java, you can have calls to such methods in your code, so long as you never actually execute them.
6. You can create dummy classes and dummy methods so that you can safely call methods from all security schemes. Netscape no longer supports their old scheme.
7. Beware the catch-22 of not being permitted to examine interesting system properties until you have decided on which security scheme you need to use. You need permission before you can examine the restricted system properties.
8. To your Netscape prefs.js file add this entry:
   user_pref(signed.applets.codebase_principal_support, true);
9. Make sure you have the latest JDK. Early versions did not use the cacerts. file.

Learning More