Application Data Protection Techniques - Secure Java: For Web Application Development - page 183

8.3.1 Implementation Independence
he applications engaged in encryption activities need not implement security algorithms. Instead,
they can request these algorithms as “security services” from the underlying Java platform. Under
such circumstances, security services are implemented by security service providers and are plugged
into the Java platform via a standard interface. An application requiring such security services
may, therefore, rely on multiple independent providers for security functionality.
Implementation independence in JCA is achieved using a cryptographic service provider
(CSP) or provider-based architecture. he term provider refers to a package or set of packages
that implement one or more cryptographic services, such as digital signature algorithms, message
digest algorithms, and key conversion services. he principle of implementation interoperability is
of signiicance in the design of JCA.
8.3.2 Implementation Interoperability
he security service providers are interoperable across applications. his essentially means that an
application is not bound to any speciic security service provider, and a security service provider is
also not bound to a speciic application.
Implementation interoperability essentially means that various implementations can work with
each other. For example, a key from one provider can be used by another provider, or a signature
from one provider can be easily be veriied by other provider. his would mean that for the same
algorithm, a key generated by one provider would be usable by another, or a signature generated
by one provider would be veriiable by another.
8.3.3 Algorithm Extensibility and Independence
he Java platform from Sun Microsystems and its licensees includes a number of built-in provid-
ers that implement a set of security services that can be easily used in building secure applica-
tions. he new Java platform also supports the installation of custom security service providers
that implement security services other than the existing services. Also, while it is very diicult to
achieve a complete algorithm independence, a JCA allows achieving a partial algorithm indepen-
dence by deining types of cryptographic “engines” (or services) and deining classes that provide
the functionality of these cryptographic engines.
herefore, all the necessary cryptographic requirements, such as digital signatures and mes-
sage digests, can be used as services without worrying about the implementation details. Even
cryptographic algorithms can be used as service, without having to look into the details relating
to their implementation.
Before we delve into the details of JCA, it is important to discuss Java Cryptographic Extensions
(JCE). he JCE is essentially a framework under the JCA and extends the JCA by simply exposing
more engines and including an additional provider, the SUNJCE provider, that includes one or
more implementations for each engine.
he JCE framework places its classes in a diferent package, javax.crypto . Some of the
JCE speciic aspects are Cipher Class (for performing encryption and decryption operations),
KeyGenerator (for producing secret keys used by ciphers), SecretKeyFactory (that oper-
ate exclusively on SecretKey instances), KeyAgreement , and MAC.
he JCA and the JCE thus represent a complete cryptographic platform for the Java environ-
ment. Developers interested in infusing cryptographic security aspects need to carefully imbibe