Since you are now reading this blog post, I bet you are a security guru who knows that IAIK is the primary cryptographic provider used in SAP NetWeaver Java. But, is it possible to use a 3rd-party crypto provider to carry out the cryptographic tasks that are usually performed by IAIK? The answer is: it depends, but in many typical scenarios, yes.
Before we dive into all the security concepts and jargons, let's first step back and take a look at why you would need a 3rd-party crypto provider. Here are some of the reasons:
- Legal reasons (e.g., export AND import restrictions)
- Government/Corporate regulations
- Special crypto algorithms/key length required that are not provided by IAIK
*IMPORTANT NOTE: the following steps to plug in 3rd-party cryptographic providers into NetWeaver J2EE engine may result in breaks or malfunction in standard software functionalities, due to the fact that each cryptographic provider may behave differently even though they may all comply with the JCE specification. Therefore it is your responsibility to make sure that software components on the NetWeaver J2EE engine continue to function normally after plugging in the 3rd-party cryptographic provider. This article is provided AS IS and provides no warranty whatsoever. Since the 3rd-party cryptographic providers are not tested/certified by SAP, issues arising from the below steps will not be supported by SAP.
The Theory
Now let's get started. First of all, a quick recap of how Java cryptographic provider works with the JVM.
The Java Cryptography Architecture (JCA) was designed to offer implementation independence, so that you can use cryptographic services without worrying about the implementation details. This is achieved by using a "provider"-based architecture. A Cryptographic Service Provider is a basically a package or a set of packages that implement one or more cryptographic services, such as digital signature algorithms, message digest algorithms, and key conversion services. Java programs can use Cryptographic Service Providers in two ways:
1) Refer to generic Java security objects (such as a Signature object) without knowing which underlying Cryptographic Service Provider is in use.
2) Refer to provider-specific security objects explicitly to take advantage of provider-specific crypto features.
Therefore whether you can safely plug in or replace a Cryptographic Service Provider in any Java-based application server depends on:
1) Whether all the Java programs are based on generic Java security objects
2) Whether the new crypto provider implements all the cryptographic services that are used by the Java programs.
For more details about JCA and JCE (Java Cryptography Extension), refer to the JCA API specification and reference: http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html.
How does SAP Java-based applications use cryptographic objects?
Well, it is simply impossible to check all Java-based applications released so far. However we can easily check out some frequently used scenarios, especially the fundamental APIs that are used by most applications, such as:
- SAP Logon Ticket API
- Digital Signatures and Document Encryption API, a.k.a. SSF API
SAP Logon Ticket is the foundation of the most frequently used Single Sign-On mechnism. It is based on digtal signature technology and its implementation uses generic Java security/cryptographic objects. Therefore, as long as the 3rd-party provides the same digital signature services required by the Logon Ticket API, you can plug it in.
The Digital Signatures and Document Encryption API is a Java implementation of SAP's standard Secure Store and Forward (SSF) mechanisms. It is widely used in both NetWeaver and Business Suite applications to protect sensitive documents. Currently it supports the following three formats:
- PKCS#7
- S/MIME v2
- XML
Unfortunately the PKCS#7 and S/MIME formats rely on direct reference to IAIK libraries; however the XML format, which is used most nowadays, is based on generic Java security/crypto objects. So as long as your 3rd-party crypto provider offers the crypto services required for SSF-based XML security, it is safe to plug it in.
You might want to ask, "what about SSL/HTTPS?" Although this seems to be normal scenario, in reality, it is not. There is typically a reverse proxy or load balancer sitting in front of the J2EE engine, offloading SSL overhead from the J2EE engine. How to use a 3rd-party crypto provider on the reverse proxy or load balance is out of the scope of this article.
See It in Action
Now I would like to show you an example in which the Bouncy Castle crypto provider will be plugged into NetWeaver J2EE engine 7.01 SPS05. The crypto provider will then be used for SAP Logon Ticket generation/verification and XML security.
First, you would need to get a copy of JCE-compliant crypto provider from your vendor. In my case, the Bouncy Castle crypto library can be downloaded from http://www.bouncycastle.org/. Make sure the crypto library is compatible with JDK 1.4.2.
Then you can choose whether you want to add the crypto provider statically or dynamically. If you would like to add it statically, you can copy the library to $JAVA_HOME$/jre/lib/ext and edit $JAVA_HOME$/jre/lib/security/java.security (see more details in the JCA API Specification and Reference mentioned above). In the below steps, I will use the dynamic approach for better flexibility.
In the next step you will need to include the crypto library in your J2EE application/service development project, and deploy it to the J2EE engine. Make sure you set it with priority 2 so that IAIK is right after it. Do not set it to 1 because that is reserved for the Controlled Provider (by SAP) which performs housekeeping tasks. The following code snippet shows how to add the Bouncy Castle crypto provider with priority 2.
java.security.Provider bcProvider = new org.bouncycastle.jce.provider.BouncyCastleProvider();
java.security.Security.insertProviderAt(bcProvider , 2);
You can now verify whether the crypto provider is inserted successfully. Launch Visual Administrator, and go to server->services->Security Provider->Runtime->Cryptography Providers. The newly added crypto provider should be listed in the second place, as shown in the below figure:
Note that we are not trying to remove the IAIK library. Instead we are only lowering its priority so that the 3rd-party crypto provider becomes the preferred provider for your application, IF it provides the crypto services required (otherwise the JVM will go down the priority list until it finds the first provider that offers the service). We have to keep IAIK for applications that explicitly reference IAIK, and for applications that rely on the crypto services provided only by IAIK.
So how do we know whether the 3rd-party crypto provider is indeed in use? Remember that listing the crypto provider with the highest priority doesn't necessarily mean it will get used. Let's run some tests to confirm that Bouncy Castle crypto provideris actually in use. To do that, I instrumented the Bouncy Castle crypto library with CA Wily Introscope. As a result, I can turn on Wily Transaction Tracer to monitor whether the Bouncy Castle crypto provider is invoked by a particular user session. If you are not familiar with Wily Introscope, take a look at the Wily Introscope User Guide at http://service.sap.com/diagnostics.
Test No. 1 - SAP Logon Ticket Creation
In this test I logged on to the Enterprise Portal. I turned on Wily Transaction Tracer right before I entered the user credentials. Check the below figure of Wily trace and you will see that the CreateTicketLoginModule, the login module which generates Logon Tickets with digital signature upon logon, implicitly called the Bouncy Castle crypto library.
Test No. 2 - SAP Logon Ticket Verification
In this test I logged on to the Enterprise Portal with a logon ticket obtained from another SAP system that the portal trusts. In the below figure of Wily trace, you can see that the EvaluateTicketLoginModule, the login module that verifies the digital signature of the ticket, implicitly called the Bouncy Castle crypto library.
Test No. 3 - Saving Portal User Mapping Data with Strong Encryption
In this test I am trying to store Portal User Mapping data on the portal which has Strong Encryption for User Mapping turned on. In the below figure of Wily trace, you can see that the user mapping data encryption implicitly called the Bouncy Castle crypto library.
Test No. 4 - Digitally Sign an XML document
In this test I will use a small WebDyrnpo application to digitally sign an XML document twice with the standard SSF API, using SHA and MD5 digest algorithms, respectively. The key pair used is retrieved with standard keystore API from the J2EE keystore which was created by Visual Administrator.
In the below figure of Wily trace, you can see that the SsfDataXML.sign() method implicitly called the Bouncy Castle crypto library.
Test No. 5 - Encrypt an XML document
In this test I will use a small WebDyrnpo application to encrypt an XML document with the standard SSF API, using the DES_EDE3_CBC algorithm. The key pair used is the same as in the last test.
Here is the code snippet used for XML encryption:
com.sap.security.api.ssf.ISsfData data = new com.sap.security.core.server.ssf.SsfDataXML(stream) ;
......
boolean res = data.encrypt(signer, pab, "DES_EDE3_CBC");
In the below figure of Wily trace, you can see that the SsfDataXML.encrypt() method implicitly called the Bouncy Castle crypto library.
Conclusion
Depending on your overall usage scenario, it is possible to make use of a 3rd-party cryptographic provider on your NetWeaver J2EE engine in many typical cases, such as logon ticket-based Single Sign-On, standard SSF-based XML signature/encryption (and all the functionalities which are built upon XML signature/encryption), as long as your crypto provider supports the crypto services required.
It is worthwhile to reiterate that plugging a cryptographic provider into your NetWeaver J2EE engine has a global impact on all functionalities that rely on cryptography, explicitly or implicitly. Not all crypto provider behaves the same way - expect compability issues. So think twice before you decide to use a 3rd-party crypto provider. Work out a comprehensive test plan before making the change in your production systems.
- SAP Managed Tags:
7 Comments
