Hot questions for Using Applets in digital signature

Top Java Programmings / Applets / digital signature

Question:

At the moment we have developed a system that can digitally sign documents using a java applet. However with the ban of applets under chrome we are looking for an alternative solution for digital signing.

At the moment the signing works the following way:

  1. A HTTP GET is sent to a servlet to get the document that is going to be signed;
  2. The applet gets started, the digital signature driver gets extracted from the file system and the user enters the PIN;
  3. The applet gets the certification chain, checks CRLs/OSCP and signs the document;
  4. The applet sends a multipart post with the already signed file to a servlet in the system.

One alternative solution would be to import the certificate in the browser and use js to do the signing. But that won't be an user friendly solution.

Another solution could be to ask the user to download a run a program using JNLP that downloads and signs the document and automatically uploads it using HTTP multipart POST. The drawback of this approach would be it requires additional user interactions (the download action) and we lose browser http session, so we have to authenticate again.

Which is more viable? Can you think of alternative?


Answer:

All post below suggests RSA based signing.

You may sign it in pure Javascript+ Web Crypto api.

Key points is extracting key with HTML5 <file> tag, use forge js library to deal with keys and hashes and canonize xml with deoxxa and use web crypto for sign/verify (in addition, forge also may sign/verify but web crypto is faster).

If you are signing xmls with exclusive canonicalization, use deoxxa (you should browserify it before using). If you sign xml and need to do inclusive canonicalization use my fork of deoxxa (hosted on own gitlab server). I was too lazy to rename exclusive to inclusive but my .js file performs inclusive, believe me) Example of usage forge+deoxxa+html5_p12_file_read in signJs, verifyJs files.

Also, forge supports signing binary files (CMS or in older naming style PKCS#7) but my JSP files doesn't have such example. About OCSP and chain test in JS - I opened the issue in forge, but it seems too difficult to handle CRL/OCSP and TSP protocols in JS, that's why you may sign in JS, but verify may be splitted - hash checking doing in JS(forge usage and additional code showed in my JSP) but smart checks like CRL, chain e.t.c do in your web service - you may extract X509Certificate and send it to your web service and use bouncycastle or any other cool library to do smart checks. X509Certificate is anyway public info, no problem in sending it to service, but digest checking requires files and you may not want to send files to service and thus use forge for checking digest which is showed in my verifyJS file.

My JS code is not refactored and even not in OOP and currently I'm not working on that project but on some stage I had fully working xml RSA siging with p12 keys in file system.

Latest JSP in my repo uses forge just for parsing p12 files and providing keys from them to Web Crypto API but my repo history also has pure Javascript sign/verify (if you don't like web crypto api). see history of the project branches.

Question:

I've been reading an old Java book where it gives an example on how to sign an applet using javakey. I'm using the openjdk-8 for my development and the command line in Linux and it says command not found: javakey. I know Java has already been acquired by Oracle corporation though I still want to know what happened to javakey, but couldn't find any information on the internet.


Answer:

It seems you're referring to a combination of the keytool & jarsigner.

But ignore anything in the keytool documentation about generating your own 'self signed' code signing certificate. Self signed certificates are no longer accepted by the Java plug in.

Question:

I have 4 signed jars (one of them contains applet class) and want to add some functions to applet. I have their sources. Applet jar depends on other 3 non applet jars, let's call them as helper jars. I see 3 approaches:

  1. Create new project, add 3 helper jars as project libraries, copy whole sources of applet jar to new project, add needed functions to applet class. Rebuild project as a jar, sign it with certificate given to me by our national certificate authority.
  2. Create new project, add all 4 jars as libraries, create only one class which extends existing applet, build it as jar, sign it with certificate given to me by our national certificate authority. Now my applet codebase contains 5 jars.
  3. Create new project, copy all sources of all applets, remove sign by removing .RSA files and manifest file inside jar. Add new functions to applet. Rebuild project as single jar, sign it with certificate given to me by our national certificate authority.

Questions:

  1. First and second options may lead to situation, that some jars will be signed with one key (used as is), others will be signed with my key. Is it OK?
  2. In all 3 choices I have to sign at least one jar with my key. I know, that java 7u51 and higher doesn't allow self-signed jars, but I have certificate given to me by our national certificate authority. Is it OK to use such certificate, will it still be blocked?

I installed root certificates from trusted site, but not fully understand is it necessary or not. AFAIK, my certificate contains url, where certificate can be verified and installations of root certificates forces my JVM to trust to this URL. Am I right?


Answer:

  • You need to sign all your jars with the same certificate
  • Yes, an official certificate will suffice

For redistribution you have two possibilities:

  1. Make one fat jar and sign it (3rd party libs are "unpacked" and inside)
  2. Create an applet.jar out of your sourcecode, and sign it including all your 3rd party libs

Please note that you also need to set the permissions Manifest attributes (1,2)