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 / 7 - JCA Helper Classes

1.6 JCA Helper Classes

 

Understanding the provider architecture is important, and it is equally important to understand a couple of the utility or helper classes. The two classes we will look at include the java. security. Security and the java. security .Provider. These classes in tandem can provide access to JCA/JCE metadata, actually perform the dynamic installation of a provider, etc. The remainder of this chapter builds on our architectural under­standing, presenting practical code examples and discussions around JCA metadata and providers.

 

 

1.6.1   The Security Class

The j ava. security. Security class is directly responsible for provider management. There is no public constructor, so its functionality is accessed only via its publicly declared static methods. This class also enjoys a strong working relationship with the Java secu­rity policies, as defined in $JAVA_HOME/jre/lib/security/java.policy. For example, this file reinforces our earlier statements surrounding the extensions loader and dynamic registration of a provider.

// Standard extensions get all permissions by default grant CodeBase "file:${java.home}/lib/ext/*" { permission java.security.AllPermission;

};

This grant indicates that any .jar file loaded from the $JAVA_HOME/jre/lib/ext directory has full permissions to do what they see fit.

There are two ways to dynamically register a third-party JCE provider programmati-cally if editing the $JAVA_HOME/jre/lib/security/java. security file on client machines is considered non-trivial. The Security class declares two methods, addProviderO and insertProviderAt () that append the provider to the end of the list and at a 1-based posi­tion, respectively. In addition to these registration methods, there is a very useful method for data mining—getProvidersQ. This method is rarely invoked directly by the devel­oper; it returns an array of Provider objects. The best way to understand how these two classes (Security and Provider) complement each other is through code examples. Let's walk through the Provider class and those examples next.

1.6.2  The Provider Class

The java. security.Provider class serves two primary purposes: accessing provider meta­data and registering implementations of cryptographic services. On the surface, this information may seem trivial to the developer, and in fact, developers will probably have little to no direct interaction with this class. However, to the provider, this class represents the cornerstone of development. Each provider must subclass the Provider class, and their constructor must provide values for mandatory metadata fields, including but not limited to the provider name, version number, and a list of name-value pairs that define what concrete implementations the provider supports.

To verify that each provider's class extends the Provider class, jump out to a com­mand line and use the javap (as a mnemonic aid, think of javap as Java "Ping" or Java "Print" where details about the class is displayed) command:

wiseman in ~ (2)—> javap sun.security.provider.Sun

Compiled from Sun.java

public final class sun.security.provider.Sun extends java.security.Provider { public sun.security.provider.Sun();

}

This output verifies that the sun.security.provider.Sun class correctly extends the java.security.Provider class. It also indicates that the provider's class does not expose any additional methods beyond that declared in the Provider class. The question at hand is how to determine the programmatic name of any given provider's implementation. Let's take a look how to decipher that information.

1.6.3  Code Example: Obtaining a List of Installed Providers, Formal Names

The core class java.security.Security class is used to obtain a list of providers. This list is represented as an array of java.security.Provider classes. It is imperative that developers remember there is a difference between the logical and physical names of the providers. By that I mean that the provider may be commonly referred to in speech as the "Bouncy Castle" provider, yet in terms of using a transparent algorithm strategy the provider parameter that must be used is "BC" or a NoSuchProviderException will be thrown.

 

NOTE: Whenever a transparent algorithm strategy is employed, always explicitly catch the NoSuchProviderException and handle it effectively!

 

When developers use an opaque algorithm strategy, they expressly rely on the declared order of the providers in the java. security properties class found inside the JRE. The invo­cation of any getlnstance(algorithmName) factory method delegates the provider selec­tion to the JRE, or more specifically its java. security properties file and the order in which providers are listed—this includes any dynamically registered providers and their respec­tive priority. When developers determine that a specific provider's implementation offers desirable characteristics, they may choose to switch to a transparent strategy and explicitly name the provider. In this situation, the invocation of any getInstance(algorithmName, providerName) factory method explicitly locates the provider's class. Where does the provider name come from? Recall that each provider must declare a formal provider name as part of the subclassed Provider constructor. The following example is extremely useful for quickly printing out a list of the available providers and their programmatic provider name:

 

Example 1.2 Sample Code Location: com.mkp.jce.chapl .ProviderDetail

try {

//Dynamically register our Cryptix provider

//without requiring java.security modification

//Place the provider in the fifth position

Provider prov = new cryptix.jce.provider.CryptixCryptoQ;

Security.insertProviderAt(prov, 5);

 

if("all".equalsIgnoreCase(args[0])) {


Provider[] providers = Security,getProvidersQ;

for(int i=0;i<providers.length;i++)

{

System.out.println("********************"); System.out.println("** Provider: " +

providers[i] .getNameO); System.out.printlnC********************"); System.out.print(providers[i].toStringO); System.out.print(" is formally referred to as '" +

providers[i] .getNameO + ""');

 

System.out.printlnC in a getlnstanceQ factory method"); System.out.println("");

}

System.out.println("Total Providers: " + providers.length);

 

} else {

Provider provider = Security.getProvider(args[0]); System.out.printIn(provider.getName() + " formally supports: ");

 

Iterator iter = provider.entrySet().iterator();

while(iter.hasNext())

{

Map.Entry entry = (Map.Entry) iter.next(); System.out.println("\t" + entry.getKeyO + " = " + entry.getValue());

}


} catch (NullPointerException nspe) {

//NPE means Provider wasn't found!

System.err.println("The requested provider is not installed in the JRE"); } catch (ArraylndexOutOfBoundsException aioobe) {

System.err.println("Usage: java ProviderDetail providerName"); System.err.println("Set providerName to 'all' to list all");

}

 

 

 

Here is the output of this example from my machine using "all" as the command line argument:

********************

** Provider: SUN

********************

SUN version 1.2 is formally referred to as the 'SUN' provider in a getlnstanceO factory method

 

********************

** Provider: SunJSSE

********************

SunJSSE version 1.41 is formally referred to as the 'SunJSSE' provider in a getlnstanceO factory method

 

 

********************

** Provider: SunRsaSign

********************

SunRsaSign version 1.0 is formally referred to as the 'SunRsaSign' provider in a getlnstanceO factory method

********************

** Provider: SunJCE

********************

SunJCE version 1.4 is formally referred to as the 'SunJCE' provider in a getlnstanceO factory method

 

********************

** Provider: BC

********************

BC version 1.19 is formally referred to as the 'BC provider in a getlnstanceO factory method

 

 

********************

** Provider: CryptixCrypto

********************

CryptixCrypto version 1.3 is formally referred to as the 'CryptixCrypto' provider in a getlnstanceO factory method

 

********************

** Provider: SunJGSS ********************

SunJGSS version 1.0 is formally referred to as the 'SunJGSS' provider in a getlnstanceO factory method

 

 

Total Providers: 7

The com.mkp.jce.misc.CryptoUtils class provided in the code examples offers a useful method that makes it easy for your applications to determine if a specific provider is available. The signature looks like this:

public final static boolean providerExists(String providerName);

This helper method can be used to eliminate NoSuchProviderException risks at run time.

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