Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Java programs can simply request a particular cryptographic object or implement a particular cryptographic service. They can also ask for a specific provider by name or by the name and service. As mentioned before, providers have a preference order, and new providers can be added statically and dynamically. The idea behind the cryptography extension is to remove the programmer from the math and complexity involved in algorithms, and instead utilize provider classes that take care of the implementation. This way, different providers can implement algorithms that are software based, or hardware based. They can also implement platform-specific or platform-dependent algorithms.
A cryptographic service is always associated with a particular algorithm or type. The service either provides cryptographic operations, generates or supplies the cryptographic materials, or generates data objects that encapsulate cryptographic keys in a secure fashion.
A cryptographic provider is simply a collection of classes that implement cryptographic algorithms. Java’s Provider subclass represents the provider as a whole. It keeps track of how the algorithms and classes are related using a list of the algorithm names and their implementations. A provider can include several different kinds of algorithms, from key pair generators to ciphers.
The application interfaces are implemented in terms of a Service Provider Interface (SPI). For each engine class there is a corresponding abstract SPI class that defines the SPI methods that the cryptographic security provider must implement. An instance of an engine class (application programming interface) encapsulates an instance of the corresponding SPI object and is created by a call to the
getInstance |
Java provides a cryptographic concept class for the algorithm and then a corresponding implementation class. For example: Signature, and Signature.Spi. Each SPI class is the name of the corresponding engine class, followed by .Spi. Each SPI class is abstract. The provider must subclass the corresponding SPI class and provide implementation of all of its abstract methods.
A Little History
Providers were first introduced in JDK 1.1 and originally could create digital signature algorithms, message digest algorithms, and key generation algorithms. JDK 1.2 added key factories, keystore creation and management, algorithm parameter management, certificate factories, and RNG algorithms.
In the JDK, Generators create new objects, while factories create objects from existing material. The engine class provides the interface to a specific service’s functionality. It defines the application programming interface (API) method that allows an application to access the service. For example, the Signature engine class provides access to the functionality of a digital signature algorithm. The engine classes defined in Java Cryptography Environment (JCE) 1.2 are listed in the first article in this series.
JCE 1.2.1 made export possible. Using a transparent jurisdiction method, the JCE can now be used to some degree outside of the U.S. and Canada. Sun now provides a single JCE bundle, and providers have to follow more-specific implementation guidelines, particularly if outside of the U.S. and must be considered trusted by the JCE 1.2.1. This is all outlined a little further in part three of this series.
JCE 1.2.1 also added a few new features. The first was SPI
javax.crypto.ExceptionMechanism |
engineWrap |
engineUnwrap |
The following engine classes are added by JCE 1.2.1:
- Cipher — encrypts or decrypts specified data.
- KeyAgreement — for key exchange protocol between two or more parties.
- KeyGenerator — generates a symmetric key for a specified algorithm.
- Mac — computes the Message Authentication Code specified data.
- SecretKeyFactory — converts opaque cryptographic keys into key specifications and vice versa.
- ExemptionMechanism — provides the functionality of an exemption mechanism.
In part three, we will look at an a overview of Java’s provider implementation.
References and Resources
- JCE Overview
- How to Implement a Provider for the JCE
- Inside Java 2 Platform Security, Li Gong, Addison Wesley, 1999
- Java Cryptology, Jonathon Knudsen, O’Reilly and Associates, 1998
- Java Security Handbook, Jamie Jaworski and Paul Perrone, SAMS Publishing, 2000
About the Author
Thomas Gutschmidt is a freelance writer, in Bellevue, Wash., who also works for Widevine Technologies.
