Home Page Javascript Download Core Servlets & Java Server Java Cryptography Java in 60 Min A Day Javascript Tutorial About Us Contact Us
Site Search
Free Javascript Lessons
Newest Java Articles
Checkbox Changer
Check Entry
Check All
Block Key Press
Basic Validation
Auto Email Link
JavaScript Forms: Agree Before Entry
Auto Tab
JavaScript Calendars: Time Entered - Day Highlighted
JavaScript Calendars: Days Left
Related SE Keywords
Java virtual machine
Java Applet
Javascript Lesson
Javascript Tutorial
Java Programming
Java Games
Java Xml
Java String
Cryptography Extensions
Free Web Master Tools
 
JavascriptDownload.net > Free Javascript Lessons > Java Cryptography Extensions > Chapter 1 / 6 - Installing Providers

1.5  Installing Providers

 

The role of a provider in Java's cryptography platform is very important. Sun isn't in the business of developing cryptographic algorithms. It's really that simple. This is not intended as a slam against Sun; on the contrary, it is a credit to them for encouraging the cryptographic researchers to design, build, and publish their implementations through a provider. Almost every application with strong cryptography needs will deploy with it one or more third party JCE providers.

As previously stated, each provider includes implementations of one or more cryptographic algorithms that may be software-only or hardware/software combinations— all of which is encapsulated behind the JCA's engine metaphor. Knowing how to access additional providers is an important ability every developer should understand. In fact, developers can access provider implementations using one of two possible strategies.

   Opaque algorithm strategy is where the developer simply requests an algorithm by name, allowing the JCA to choose a provider based on set of rules covered shortly. Think of the opaque algorithm strategy as a black box—developers have no idea what goes on inside the box, just the end result of receiving an instance of the engine class that implements the requested algorithm.

   Transparent algorithm strategy is where the developer explicitly names the algo­rithm and the provider that must supply the implementation of that algorithm. This approach effectively side-steps several of the JCA design goals, and it should only be used in rare situations. The transparency is related to the fact that you can see inside of the algorithm, that is, who it is from, how it is implemented, unique idiosyncrasies as a result of this provider's implementation, etc.

Providers can be registered either statically or dynamically, and the exact approach used will be determined based on the application's nature, runtime environment, and deploy­ment method. For example, if you control the JRE static may make more sense, but if your software will be deployed to heterogeneous environments, a dynamic approach may be the simplest in terms of configuration.

 

1.5.1   Static Provider Registration

Static registration of a provider occurs through a formal declaration process in the Java Runtime Environment. Sun's documentation on this topic is included under the Installing Providers section of the JCA JavaDocs [1]. Specifically, the Sun JDK 1.4 statically reg­isters providers in the file found at $JAVA_HOME/jre/lib/security/Java.security. The Java.security file allows individual end-users to establish a preferred search sequence. When the developer opts to use an opaque algorithm strategy, the providers are searched sequentially until a match is found. The search sequence relies on the name-value pair naming convention commonly used by Java properties files. For example, my java. security file declares its providers in this sequence:

security.provider.l=sun.security.provider.Sun

security.provider.2=com.sun.net.s si.internal.s si.Provider

security.provider.3=com.sun.rsaj ca.Provider

security.provider.4=org.bouncycastle.j ce.provider.BouncyCastleProvider

security.provider.5=sun.security.j gss.SunProvider

The numbers 1... 5 represent the explicit search sequence. This list is strict in that the providers must be in counting order (e.g., 1,2,3,4 ... and not 4,1,3,2 ...), and a number cannot be skipped. The opaque algorithm strategy queries each provider to determine if they support a concrete implementation of the algorithm requested by the developer. The first provider that can respond "yes" will always service the request when an opaque algorithm strategy is employed. Notice that each provider entry listed is identified with a fully qualified package name.

While this step formally introduces what is effectively a bootstrap routine that reg­isters the provider's offerings, there is still the problem of exposing the physical classes. Providers will typically ship production code inside of a signed .jar file, and there are two ways in which these classes can be added to a runtime environment.

 

Provider Class Deployment: Option 1

The first option is to drop the .jar file into the $JAVA_HOME/jre/lib/ext directory. This approach effectively treats the .jar as an extension of the physical runtime environment. Any .jar file dropped here will be found prior to classes accessible to the system class loader. This option makes the provider's implementation available to all applications,


 

there is no messing around with the SCLASSPATH environment variable, and with mini­mal Iegwork, you can validate the signature of the .jar prior to blindly placing it into the extensions directory.

If you need a refresher on class loaders, one of the better discussions on Java's class loader architecture is from JavaGeeks.com [2]. If you haven't had a need to work with Java extensions, you may want to review the Java Extensions FAQ [3].

 

 

Provider Class Deployment: Option 2

The alternative to using the extensions directory is to manually add the provider's .jar file onto the SCLASSPATH environment variable.

 

 

1 .5.2   Dynamic Provider Registration

Dynamic registration is possible and often more convenient than static registration. Explicit privileges still have to be declared for the provider before the attempted dynamic registration when a SecurityManager is in effect. Specifically (using the example from the Java Cryptography Extension documentation), if the MyJCE provider deploys their perti­nent classes in the MyApp.jar file that is copied to your /localWork directory, a grant like this would be required if you were using a SecurityManager.

grant CodeBase "file:/localWork/MyApp.jar" {

Permission java.security.SecurityPermission "insertProvider.MyJCE";

};

The code examples in this book that require the use of a third party provider will use dynamic registration, and no SecurityManager is assumed. Deployment of the physical JCE provider class files is a manual process that you will have to complete, and either of the two deployment options described here will be adequate.

 

NOTE: Despite these well-documented procedures for accessing a provider, there are numer­ous posts throughout the web detailing how custom class loaders (especially poorly written ones) do not properly recognize an installed provider. The fact is that each IDE, EJB, and Servlet container on the market uses a distinct architecture that will have its own set of idiosyncrasies. Be sure to check with your vendor for any special considerations you may need to be aware of when accessing the JCE, or more specifically third party providers, from inside these environments.

 

When attempting to dynamically register a JCE provider, that provider cannot be registered too high up in the search order due to a bug in the Sun JVM. This bug has been duplicated on both Mac OS X and Windows 2000, XP. It was registered with Apple as Java Bug #3294108

(JCE Providers Crash with Bus Error) and with Sun's Java Developer Connection under JDC Review ID 188804 (Dynamic Registration of JCE Provider in Position 1 Results in Stack Overflow). If your code is going to employ a dynamic registration strategy, do not place your JCE provider of choice in position 1 without checking if Sun has closed this bug first! Here is the stack trace that results:

j ava.lang.StackOverflowError

at j ava.lang.ClassNotFoundException.<init>(ClassNotFoundException.java:65)

at java.lang,ClassLoader.findBootstrapClass(Native Method)

at java.lang.ClassLoader.findBootstrapClassO(ClassLoader.java:723)

at j ava.lang.ClassLoader.loadClass(ClassLoader.j ava:294)

at java.lang.ClassLoader.loadClass(ClassLoader.java:292)

at sun.misc.Launcher$AppClassLoader.loadClas s(Launcher.j ava:26 5)

at j ava.lang.ClassLoader.loadClas s(Clas sLoader.j ava:2 5 5)

at java.security.Security.doGetlmpKSecurity.java:1122)

at j ava.security.Security.doGetImpl(Security.j ava:1083)

at j ava.security.Security.getImpl(Security.j ava:1044)

at java.security.MessageDigest.getInstance(MessageDigest.java:120)

at sun.security.util.ManifestEntryVerifier.setEntry

(ManifestEntryVerifier.java:111)

at j ava.util.jar.JarVerifier.beginEntry(JarVerifier.j ava:151)

at j ava.util.j ar.JarVerifier$VerifierStream.<init>(JarVerifier.j ava:3 5 2)

at java,util.jar.JarFile.getInputStream(JarFile.java:323)

at sun.misc.URLClassPath$5.getInputStream(URLClassPath.java:617)

at sun.misc.Resource.getBytes(Resource.java:57)

To give you insight into what appears to be happening, when you dynamically register a new JCE provider, the .jar must be verified. A cycle ensues—the MessageDigest engine must be used to verify the .jar, but because the logic expects to use the default provider, which is now the new provider, it must verify the .jar and around it goes until a stack overflow occurs. It would appear that the engine, if being used to verify a .jar file, should explicitly request the SUN provider. Nothing in the java. security file gives any indication that a provider cannot be placed into position 1 dynamically:

#  There must be at least one provider specification in java.security.

#  There is a default provider that comes standard with the JDK. It


 

#  is called the "SUN" provider, and its Provider subclass

#  named Sun appears in the sun.security.provider package. Thus, the

#  "SUN" provider is registered via the following: #

#  security.provider.l=sun.security.provider.Sun #

#  (The number 1 is used for the default provider.) #

#  Note: Statically registered Provider subclasses are instantiated

#  when the system is initialized. Providers can be dynamically

#  registered instead by calls to either the addProvider or

#  insertProviderAt method in the Security class.

However, clearly there are some dependencies on the base algorithms from the SUN provider that require it to always be in position 1. For our purposes in this book, I arbitrar­ily registered my providers dynamically after position 5; your environment may require adjustment of this number up or down.

Add Comment
 
homepage   |  about us  |  contact us
Powered By teknonova.com Sunucu Kiralama