Difference between revisions of "JGridstart/Bouncycastle and Java Web start"
(add note about currently used approach) |
|||
(23 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | [http://www.bouncycastle.org/java.html BouncyCastle] is a cryptographic library for [http://java.sun.com/ Java] that complements | + | {{JGridstart}} |
+ | [http://www.bouncycastle.org/java.html BouncyCastle] is a cryptographic library for [http://java.sun.com/ Java] that complements the default [http://java.sun.com/javase/technologies/security/ Java Cryptography Extension]. To use it as a provider (e.g. to access a [http://java.sun.com/j2se/1.4.2/docs/api/java/security/KeyStore.html KeyStore] that is supported by BouncyCastle), one has to use the [http://en.wikipedia.org/wiki/JAR_%28file_format%29 JAR] file provided by them because that is signed by Sun (because of countries' security policies). When creating a [http://java.sun.com/javase/technologies/desktop/javawebstart/ Java Web Start] application, both the application and the BouncyCastle JAR need to be included. This page explains how this can be done. | ||
+ | |||
+ | There is a number of ways in which Bouncycastle and Java Web Start can be combined. | ||
+ | |||
+ | # Using the Java Cryptography Extension with Bouncycastle | ||
+ | ## All JARs in a single JNLP (requires signing the Bouncycastle JAR twice) | ||
+ | ## Putting the Bouncycastle JAR in an extension JNLP | ||
+ | ### Keep Bouncycastle JAR signed with just the JCE certificate (extra security dialog for user) | ||
+ | ### Sign Bouncycastle JAR additionally with the application's certificate | ||
+ | # Using Bouncycastle's leightweight API, bypassing the JCE (different API, no signing problems) | ||
+ | # Running the application outside of Java Web Start using a wrapper (e.g. [http://one-jar.sourceforge.net/ One-JAR]) | ||
+ | |||
+ | Option 1.1 suffers from [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6598556 Java bug #6598556] on JRE 1.6.0 until 1.6.0_13. Option 1.2.1 shows an extra security dialog to the user, which is confusing. Option 1.2.2 only seems to work when the publisher's certificate is stored as an accepted certificate in some cases (on by default on Linux and Windows for commercial certificates, off by default on Mac OS X; seen on JRE 1.6.0_26). | ||
+ | |||
+ | Option 2 is a lot of migration work when the application is written to use the standard Java Cryptography API. | ||
+ | |||
+ | Option 3 is currently used by jGridstart in module '''jgridstart-wrapper'''. | ||
+ | |||
+ | ==Using a BouncyCastle JNLP extension== | ||
+ | |||
+ | the way to do this is by referencing to a bouncycastle JNLP file using the extension tag. For example the file <tt>app.jnlp</tt>: | ||
<?xml version="1.0" encoding="utf-8"?> | <?xml version="1.0" encoding="utf-8"?> | ||
Line 12: | Line 33: | ||
</security> | </security> | ||
<resources> | <resources> | ||
− | <j2se href="http://java.sun.com/products/autodl/j2se" version="1. | + | <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/> |
<jar href="app.jar"/> | <jar href="app.jar"/> | ||
− | <extension name="BouncyCastle cryptography library" href="bcprov.jnlp"/> | + | <extension name="BouncyCastle cryptography library" href="bcprov-jdk15.jnlp"/> |
</resources> | </resources> | ||
<application-desc main-class="app.Main"/> | <application-desc main-class="app.Main"/> | ||
</jnlp> | </jnlp> | ||
− | References the file bcprov.jnlp which describes the BouncyCastle extension. This can not be put in the application's JNLP because all JARs in a single JNLP file need to be signed by the same key. The file bcprov.jnlp can contain: | + | References the file <tt>bcprov-jdk15.jnlp</tt> which describes the BouncyCastle extension. This can not be put in the application's JNLP because all JARs in a single JNLP file need to be signed by the same key. The file <tt>bcprov-jdk15.jnlp</tt> can contain: |
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | ||
− | <jnlp spec="1.0+" codebase="http://somewhere/" href="bcprov.jnlp"> | + | <jnlp spec="1.0+" codebase="http://somewhere/" href="bcprov-jdk15.jnlp"> |
<information> | <information> | ||
− | <title>bcprov- | + | <title>bcprov-jdk15</title> |
<vendor>Sun Microsystems, Inc.</vendor> | <vendor>Sun Microsystems, Inc.</vendor> | ||
<offline-allowed/> | <offline-allowed/> | ||
Line 32: | Line 53: | ||
</security> | </security> | ||
<resources> | <resources> | ||
− | <jar href="bcprov- | + | <jar href="bcprov-jdk15-146.jar"/> |
</resources> | </resources> | ||
<component-desc/> | <component-desc/> | ||
</jnlp> | </jnlp> | ||
− | You see that this file also has the all-permissions tag in the security section. This is to allow the file to register itself as a cryptography provider. | + | You see that this file also has the <tt>all-permissions</tt> tag in the security section. This is to allow the file to register itself as a cryptography provider. |
Now when the Java Web Start application is run, the user has to accept a warning dialog twice: one for the application itself, and one for the BouncyCastle extension. This is a little troublesome, since the user doesn't care about the extension; if he has just consented to grant the application access why does it ask for it again? | Now when the Java Web Start application is run, the user has to accept a warning dialog twice: one for the application itself, and one for the BouncyCastle extension. This is a little troublesome, since the user doesn't care about the extension; if he has just consented to grant the application access why does it ask for it again? | ||
− | + | The solution to this issue is to sign the BouncyCastle JAR with the same key as the application JAR; the resulting BouncyCastle JAR will be signed twice: <tt>META-INF/BC-KEY.*</tt> gives the security permissions to be used as a cryptography provider, and <tt>META-INF/<MY-KEY>.*</tt> gives the other permissions. Because you use the same key for your application as BouncyCastle, the user only needs to accept it once. | |
− | The | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | If you don't want to sign the BouncyCastle JAR yourself, it is still possible to workaround the issue, please see [[JGridstart/Bouncycastle and Java Web start workaround|Bouncycastle and Java Web Start workaround]]. | |
− | ' |
Latest revision as of 10:34, 13 November 2012
<sidebar>
- jGridstart
- JGridstart|Home
- JGridstart/Help|Help
- JGridstart/Support|Support
- jGridstart for ...
- JGridstart/Certificate_Authorities|Certificate Authorities
- JGridstart/Developers|Developers
</sidebar> BouncyCastle is a cryptographic library for Java that complements the default Java Cryptography Extension. To use it as a provider (e.g. to access a KeyStore that is supported by BouncyCastle), one has to use the JAR file provided by them because that is signed by Sun (because of countries' security policies). When creating a Java Web Start application, both the application and the BouncyCastle JAR need to be included. This page explains how this can be done.
There is a number of ways in which Bouncycastle and Java Web Start can be combined.
- Using the Java Cryptography Extension with Bouncycastle
- All JARs in a single JNLP (requires signing the Bouncycastle JAR twice)
- Putting the Bouncycastle JAR in an extension JNLP
- Keep Bouncycastle JAR signed with just the JCE certificate (extra security dialog for user)
- Sign Bouncycastle JAR additionally with the application's certificate
- Using Bouncycastle's leightweight API, bypassing the JCE (different API, no signing problems)
- Running the application outside of Java Web Start using a wrapper (e.g. One-JAR)
Option 1.1 suffers from Java bug #6598556 on JRE 1.6.0 until 1.6.0_13. Option 1.2.1 shows an extra security dialog to the user, which is confusing. Option 1.2.2 only seems to work when the publisher's certificate is stored as an accepted certificate in some cases (on by default on Linux and Windows for commercial certificates, off by default on Mac OS X; seen on JRE 1.6.0_26).
Option 2 is a lot of migration work when the application is written to use the standard Java Cryptography API.
Option 3 is currently used by jGridstart in module jgridstart-wrapper.
Using a BouncyCastle JNLP extension
the way to do this is by referencing to a bouncycastle JNLP file using the extension tag. For example the file app.jnlp:
<?xml version="1.0" encoding="utf-8"?> <jnlp spec="1.0+" href="app.jnlp" codebase="http://somewhere/"> <information> <title>App</title> <vendor>Nikhef</vendor> <homepage href="http://somewhere/"/> </information> <security> <all-permissions/> </security> <resources> <j2se href="http://java.sun.com/products/autodl/j2se" version="1.5+"/> <jar href="app.jar"/> <extension name="BouncyCastle cryptography library" href="bcprov-jdk15.jnlp"/> </resources> <application-desc main-class="app.Main"/> </jnlp>
References the file bcprov-jdk15.jnlp which describes the BouncyCastle extension. This can not be put in the application's JNLP because all JARs in a single JNLP file need to be signed by the same key. The file bcprov-jdk15.jnlp can contain:
<?xml version="1.0" encoding="UTF-8"?> <jnlp spec="1.0+" codebase="http://somewhere/" href="bcprov-jdk15.jnlp"> <information> <title>bcprov-jdk15</title> <vendor>Sun Microsystems, Inc.</vendor> <offline-allowed/> </information> <security> <all-permissions/> </security> <resources> <jar href="bcprov-jdk15-146.jar"/> </resources> <component-desc/> </jnlp>
You see that this file also has the all-permissions tag in the security section. This is to allow the file to register itself as a cryptography provider.
Now when the Java Web Start application is run, the user has to accept a warning dialog twice: one for the application itself, and one for the BouncyCastle extension. This is a little troublesome, since the user doesn't care about the extension; if he has just consented to grant the application access why does it ask for it again?
The solution to this issue is to sign the BouncyCastle JAR with the same key as the application JAR; the resulting BouncyCastle JAR will be signed twice: META-INF/BC-KEY.* gives the security permissions to be used as a cryptography provider, and META-INF/<MY-KEY>.* gives the other permissions. Because you use the same key for your application as BouncyCastle, the user only needs to accept it once.
If you don't want to sign the BouncyCastle JAR yourself, it is still possible to workaround the issue, please see Bouncycastle and Java Web Start workaround.