AAP P E N D I X P P E N D I X MM Java Cryptographic APIsJava Cryptographic APIs Nick%Pullman%(Citigroup Information Security division) Copyright 2010 Introduction................................................................................................................. 1%JCA and JCE Architecture.......................................................................................... 1%JCA Classes ................................................................................................................ 3%JCE Classes................................................................................................................. 5%Conclusion .................................................................................................................. 6%Works Cited ................................................................................................................ 7%Appendix A: Using the Cryptographic Application ................................................. 8%Appendix B: JCA/JCE Cryptography Example...................................................... 12% Supplement to Cryptography and Network Security, Fifth Edition William Stallings Prentice Hall 2010 ISBN-10: 0136097049 http://williamstallings.com/Crypto/Crypto5e.htmlJava Cryptographic APIs 1 Introduction Many applications are currently coded using Java technologies and adoption of Java as a business enabler will continue as more companies invest in service-oriented architecture (SOA) and web services. As Java continues to find its way into the enterprise, security needs to be addressed with the design of all new applications and updated in all existing applications. Java provides an extensible security architecture with which to secure applications that are written in Java; these APIs include: • Java Cryptography Architecture (JCA) • Java Cryptographic Extension (JCE) • Java Certification Path API (CertPath) • Java Secure Socket Extension (JSSE) • Java Authentication and Authorization Service (JAAS) • Java Generic Secure Services (JGSS) (Steel, Nagappan, & Lai, 2005, chap. 3) This paper will discuss the first two APIs, JCA and JCE, in order to illustrate how cryptography can be utilized to secure information in Java. This paper will discuss the architecture and the classes of the two cryptography APIs along with examples to illustrate its uses. JCA and JCE Architecture The Java cryptographic APIs, JCA and JCE, both follow the same architecture for implementing and interfacing cryptographic services. In order to create an extensible framework for implementing cryptographic services, the architecture for cryptography in Java separates engine classes from service providers. JCA and JCE implement the engine classes which provide a standard interface to the service providers. The service providers are the APIs which actually implement the cryptographic algorithms and types that are acted upon. A simple way to think of this is that JCA will implement a class such as a message digest, we know what a message digest is, but just having a generic message digest doesn’t tell us anything; it needs a cryptographic service. The cryptographic service provider will implement the actual algorithm, such as MD5 or SHA-1 in this example. JCA implements the generic class and the service provider implements the actual algorithm or type of cryptographic service that will be used. See figure below for an overview of the architecture along with a few example service providers listed.Java Cryptographic APIs 2 Figure 1: JCA/JCE Architecture (Steel et al., 2005, chap. 3) This architecture is used in order to make the cryptographic APIs extensible by allowing different service providers to be “plugged in” to the framework and then utilized using standard interfaces. For example, if a new algorithm for message digests was created, the message digest class in JCA could still be utilized to implement the new algorithm. The code for instantiating a MessageDigest class in JCA looks like this: MessageDigest myDigest = MessageDigest.getInstance(“MD5”); This instantiation of the MessageDigest class uses the highest level service provider, because one wasn’t specified, based on the java.security file which is located in jre-home\lib\security\java.security. The default installation of service providers from Java 1.5 should look similar to this: security.provider.1=sun.security.provider.Sun security.provider.2=sun.security.rsa.SunRsaSign security.provider.3=com.sun.net.ssl.internal.ssl.Provider security.provider.4=com.sun.crypto.provider.SunJCE security.provider.5=sun.security.jgss.SunProvider security.provider.6=com.sun.security.sasl.Provider The code for instantiating the MessageDigest class in JCA using a specific provider looks like this: MessageDigest myDigest = MessageDigest.getInstance(“MD5”, “SUN”); Although the default Java 1.5 installation comes with a number of service providers, there are a number of reasons why a third party service provider would need toJava Cryptographic APIs 3 be installed such as vendor specific implementations or new algorithms (Kumar, 2005). Unfortunately the installation of a new service provider is somewhat convoluted, although it is for good reason. First, the service provider jar file needs to be put into a directory that is in the CLASSPATH environment variable of your operating system. Secondly, if the application is an applet or is otherwise running underneath a security manager then appropriate permissions must be granted to the application. Finally, in order for the JCE to ensure that the provider is valid, the code must be signed by a trusted Certificate Authority (CA). Currently, the two CAs that can be used are: • Sun Microsystems' JCE Code Signing CA • IBM JCE Code Signing CA (“How to implement a provider for the java cryptography extension”) These steps are all done in order to ensure the validity of the service provider, because if the service provider is compromised, then all of the services performed by the service provider are potentially compromised as well. The cryptography architecture in Java was created in order to separate the actual implementation of the algorithms from the engine classes which interface with the service providers. This allows the architecture to be both flexible for the developer to decide what his/her cryptographic needs are,