Introduction
Now we’re going to introduce the JAVA PKI programming scheme. As it was said before, JAVA has a security architecture based on providers, isolating the algorithms implementation from the cryptography services.
Basically, it relies on three packages: JCA, JCE and JSSE. Each package represents a collection of interfaces and abstract classes, specifying cryptographic services available for the developers. Something like the following picture:
On the top level of picture you can see the API packages, containing interfaces and abstract classes definition. These APIs was defined by Sun, and are intended to be the most generic and independent from any particular standard. On the low level, there are the providers that implement one or more APIs.
First of all, we’re going to introduce the APIs.
JAVA Cryptography Architecture (JCA)
JCA is a provider based cryptographic API. It was intended to be the main API, covering all the high level PKI services and definitions. One doesn’t have to worry about key parameters, hash algorithms details and the using of padding in public key ciphering. He or she only have to think about hashing, signing and ciphering.
The key objects are treated in an abstract manner. You don’t need to go into specific concerns like public or private parameters, or neither the key storage and access details.
JCA provides the following services:
- Resume (hash) generation;
- Digital signatures;
- Digital certificate supporting;
- Certificate chains and CRLs supporting;
- Key pair generation and handling.
- Etc.
JCA is really generic about its services. When it defines the digital signature service, it is not committed to any kind of standard or algorithm, like RSA or DSA. Also, JCA doesn’t define particular schemes or signature presentations, such as PKCS#7 and XMLDsig standards.
Java Cryptography Extension (JCE)
JCE exists mostly due to export control restrictions by the U.S. Commerce Department. As JCA, JCE is a provider based API, and allows that any kind of algorithm, with any key size, can be plugged in the API. The U.S. Exporting policy was an effort to prevent this mechanism of ending in wrong hands (also known as Cuba, Iran, North Korea and other misfits nations).
To be conform to this policy, Sun Microsystems decided to separate the cryptography API in two: JCA and JCE. The second one would be an extension package subject to a jurisdiction policy. By default, this jurisdiction policy would allow applications to use strong specifications for algorithms and key sizes. No restricted nations would be allowed to use the unlimited policy.
We’re going later to see in more detail how to use this policy schema.
Java Secure Socket Extension (JSSE)
JSSE is a provider based API that defines services for secure communication in computer networks, using SSL and TLS connections. It completes Sun architecture, also leaving the implementation issues to the available providers.
Java Architecture Use Case
What is the scenario of using this architecture? If you need, for example, to add a password resume functionality to your application, what steps you have to follow?
First of all, you have to find a suitable hash service offered by JAVA API. You will easily find out that JCA has the MessageDigest service, which one defines methods for generating a resume of a particular message. MessageDigest exposes to you a clear interface, so you’re able to call its methods from your application code.
After deciding which service to use, you may choose a hash algorithm. For password resume, MD5 sounds nice.
Finally, you have to indicate a provider that implements MD5 algorithm for MessageDigest.
And voila!
The Cryptography Developer 