Java Cryptography Architecture
JCA is described as a provider architecture. The primary principal in the design of the JCA has been to separate the cryptographic concepts from their algorithmic implementations. It is designed to allow different vendors to provide their own implementation of the cryptographic tools and other administrative functions. This makes a very flexible framework which willcater for future requirements and allow vendor independence.
The architecture defines a series of classes, called engine classes, that are representations of general cryptographic functions. So, for example, there are several different standards for digital signatures, which differ in their detailed implementation but which, at a high level, are very similar. For this reason, a single engine class, java.security.Signature, has been created that represents all of the variations in a digital signature. The actual implementation of the different signature algorithms is done by a provider class which may be offered by a number of vendors.
Figure . Provider and Engine Classes
The provider architecture has the virtue of offering a standard interface to the programmer who wants to use a cryptographic function, while at the same time having the flexibility to handle different underlying standards and protocols. The providers may be added either statically or dynamically.
Support for the management of keys and access control lists was not in the initial release of JDK 1.1, but has been provided in Java 2 SDK, Standard Edition, V1.2. Currently, Sun Microsystems’ version of the JRE comes standard with a default provider, named SUN. Other Java Runtime Environments (JREs) may not necessarily supply the SUN provider. The SUN provider includes an implementation of the following algorithms:
• Digital Signature Algorithm (DSA)
• SHA 3 -1 and MD5 4 message digest algorithms
• SHA1PRNG pseudo-random number generation algorithm
Moreover, the SUN provider implements a DSA key factory, a certificate factory for X.509 certificates and certificate revocation list (CRLs), and a keystore implementation for the proprietary keystore type named Java Keystore (JKS).
