August 2019 Copyright © 2019 Dell Inc. or its subsidiaries. All rights reserved. 1
Troubleshooting Guide
18.07.19
RSA BSAFE
®
Crypto-J 6.2.5
Troubleshooting Guide
This document provides information and instructions for troubleshooting common
issues for RSA BSAFE Crypto-J 6.2.5 (Crypto-J) on all released platforms.
Contents:
Enforce Strict DER Encoding of X.509 Certificates .....................................2
Statically Register JsafeJCE Provider as the Default JCE Provider .........3
Dynamically Register the JsafeJCE Provider ..............................................4
Use Crypto-J in FIPS-140 Mode in Compliance with FIPS 140-2
Requirements ...................................................................................................5
Slow FIPS-140 Start-up on Android ..............................................................5
Install JCE Unlimited Strength Jurisdiction Policy Files ..............................6
Error when Re-Signing the Jar Files .............................................................7
Errors when Running a Java Web Start Application ...................................7
Decrease the Time Taken for Cryptographic Operations ............................8
Entropy Generation ..................................................................................8
Decrease the Time Taken for Cryptographic Operations that use
Blinding .......................................................................................................8
Convert Oracle JKS Keystore to PKCS #12 format ....................................9
Error ‘Algorithm not allowable in FIPS140 Mode’ ........................................9
Use Crypto-J with J2EE Applications and Application Servers ................ 10
Static Registration ...................................................................................10
Dynamic Registration .............................................................................10
Explicit use of Provider Instances ......................................................... 11
Intermittent Test Failures with some EC Algorithms ..................................11
Signature Verification Fails for some RSA PSS Signatures .....................12
Use Crypto-J in FIPS 140-2 Mode on Oracle WebLogic 11g and 12c ...12
Use Crypto-J Jars in an EAR Application on Red Hat JBoss ..................13
Use Crypto-J jars in an EAR Application on JBoss 5 and 6 ..............13
Use Crypto-J jars in non-FIPS 140-2 mode, in an EAR Application on
JBoss 7 .....................................................................................................13
Use Crypto-J jars in FIPS 140-2 mode, in an EAR Application on
JBoss 7 .....................................................................................................14
Use Crypto-J Jars in an EAR Application on Oracle WebLogic ...............14
Gradle Incompatibility with Android Studio .................................................15
Reuse of IV is Not Allowed in GCM Mode .................................................. 15
Customization Using the System and Security Properties .......................15
2 Enforce Strict DER Encoding of X.509 Certificates
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Enforce Strict DER Encoding of X.509 Certificates
When DER encoding of X.509 certificates is not strictly enforced, the unsigned
portion of the certificate (including the signature or signature algorithm) can be
modified without breaking the validity of the certificate. Such modifications could
allow a remote attacker to defeat fingerprint-based certificate-blacklist protection
mechanisms.
The security property,
com.rsa.cryptoj.cert.strictencoding, strictly
enforces DER encoding of certificates. By default, this property is set to
true. For
backward compatibility with existing certificates, the property can be set to
false,
but this is not recommended because of vulnerability to attack.
For more information about the system and security properties in Crypto-J, see
Introduction To Crypto-J-> System and Security Properties in the RSA BSAFE
Crypto-J Developers Guide.
Statically Register JsafeJCE Provider as the Default JCE Provider 3
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Statically Register JsafeJCE Provider as the Default JCE
Provider
A statically registered Crypto-J JsafeJCE provider can be used without having to
instantiate it, and without having to programmatically add it to the provider list.
Statically registering the JsafeJCE provider as the default, that is, in first position,
allows it to be the default provider of algorithms.
Complete the following to statically register the JsafeJCE provider as the default JCE
provider:
1. Copy the relevant Crypto-J jar file(s) to the
<jdk install directory>/jre/lib/ext directory.
2. Edit the
java.security file found in the
<jdk install directory>/jre/lib/security directory:
a. Add the following line to the beginning of the list of providers:
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
b. Alter the numeric values for all other providers in the list to ensure the
numeric values are contiguous. For example, for Oracle
®
JRE 1.6, the
provider list looks like the following:
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI
3. To ensure no other cryptographic providers are available, remove all other JCE
providers. Ensure the numeric values for the remaining providers are contiguous.
For instance, for Oracle JRE 1.6, the provider list looks like the following:
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.sun.net.ssl.internal.ssl.Provider
security.provider.3=sun.security.jgss.SunProvider
security.provider.4=com.sun.security.sasl.Provider
security.provider.5=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.6=sun.security.smartcardio.SunPCSC
Ensure the JsafeJCE provider is used for all supported cryptographic
operations:
To ensure the JsafeJCE provider is used for all supported cryptographic operations,
explicitly provide the JsafeJCE provider name to cryptographic
getInstance()
calls as demonstrated in the JsafeJCE Samples. For example:
Signature signer = Signature.getInstance(“SHA256WithRSA”, “JsafeJCE”);
4 Dynamically Register the JsafeJCE Provider
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Dynamically Register the JsafeJCE Provider
To dynamically register the Crypto-J JCE provider, JsafeJCE:
1. Add the relevant Crypto-J jar file(s) to the class path.
2. Load the provider using the following Java code:
// Create a Provider object
Provider jceProvider = new com.rsa.jsafe.provider.JsafeJCE();
// Add the JCE Provider class to the current list of providers
//available on the system.
Security.insertProviderAt(jceProvider, 1);
Note: To set the JsafeJCE provider as the default provider, the provider
position should be set to 1 as in the above example.
To verify that JsafeJCE is present in the list of JCE providers, print out the list using
the following Java code:
// Print out a list of the current providers.
Provider[] currentProviders = Security.getProviders();
System.out.println(“Current providers: “);
for (int index = 0; index < currentProviders.length; index++) {
System.out.println(currentProviders[index].getName() + “ " +
currentProviders[index].getVersion());
System.out.println(“ " + currentProviders[index].
getInfo());
}
Ensure the JsafeJCE provider is used for all supported cryptographic
operations:
To ensure the JsafeJCE provider is used for all supported cryptographic operations,
explicitly provide the JsafeJCE provider name to cryptographic
getInstance()
calls as demonstrated in the JsafeJCE Samples. For example:
Signature signer = Signature.getInstance(“SHA256WithRSA”, “JsafeJCE”);
For more information about the system and security properties in Crypto-J, see
Introduction To Crypto-J-> System and Security Properties in the RSA BSAFE
Crypto-J Developers Guide.
Use Crypto-J in FIPS-140 Mode in Compliance with FIPS 140-2 Requirements 5
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Use Crypto-J in FIPS-140 Mode in Compliance with
FIPS 140-2 Requirements
To ensure that Crypto-J is used in the FIPS-140 mode in compliance with FIPS 140-2
requirements, complete the following:
• Use the correct jar file:
– For non-Android environments, use the
jcmFIPS-6.2.5.jar file
– For Android environments, use the
jcmandroidfips-6.2.5.jar file.
• Set the initial FIPS-140 mode of operation security property,
com.rsa.cryptoj.fips140initialmode to one of:
–
FIPS140_MODE (default)
– FIPS140_SSL_MODE
– FIPS140_ECC_MODE
– FIPS140_SSL_ECC_MODE.
• Set the FIPS-140 role authentication security property,
com.rsa.cryptoj.fips140auth to the required FIPS140 Security Level.
The recognized values are:
–
LEVEL1 indicates Security Level 1 (default).
–
LEVEL2 indicates Security Level 2.
For further details, see Customization Using the System and Security Properties.
For more information about using Crypto-J on Android in FIPS-140 mode, see
Introduction to Crypto-J > Android in the RSA BSAFE Crypto-J Developer Guide.
For more information about the system and security properties in Crypto-J, see
Introduction To Crypto-J-> System and Security Properties in the RSA BSAFE
Crypto-J Developers Guide.
Slow FIPS-140 Start-up on Android
FIPS 140-2 compliance requires that the Crypto-J JSAFE and JCE Software Module
runs algorithm self-tests before Crypto-J can perform cryptographic operations. The
time taken to run these self-tests can cause a noticeably slow start-up on some older
Android devices.
The self-tests are triggered by the first usage of a cryptographic object, such as a JCE
getInstance factory method or a new SecureRandom().
To minimize the impact of an extended start-up time, update the application code to
trigger the self-tests in a new thread which executes while an Android activity User
Interface is displayed and/or a user interaction is required.
6 Install JCE Unlimited Strength Jurisdiction Policy Files
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Install JCE Unlimited Strength Jurisdiction Policy Files
The JCE requires the presence of Unlimited Strength Jurisdiction Policy Files in order
to use some algorithms and key strengths.
The following algorithms require these policy files:
• AES with key sizes greater than 128 bits
• RC2 with key sizes greater than 128 bits
• RC4 with key sizes greater than 128 bits
• RC5 with key sizes greater than 128 bits
• RSA Encryption.
For the latest unlimited strength jurisdiction policy file guidelines, see the
install_jre/lib/security/java.security file.
The latest JDK updates use the unlimited strength jurisdiction policy files by default.
To check that the installed JDK does this, look for the
install_jre/lib/security/policy directory. If this directory is not present,
complete the following instructions to manually download and install the unlimited
policy files. The JDK version installed determines the unlimited strength jurisdiction
policy file to download.
For Oracle JDK 9, follow the instructions in the README.txt located in the
<jdk9 install directory>/conf/security/policy directory of the JDK
download.
For all other JDK versions, obtain the applicable Jurisdiction Policy File from the
following download locations:
• JCE Unlimited Strength Jurisdiction Policy Files 7 for:
– Oracle JDK 7.0
– HP JDK 7.0.
• JCE Unlimited Strength Jurisdiction Policy Files 8 for:
– Oracle JDK 8.0
– HP JDK 8.0.
• IBM Unrestricted JCE Policy Files for IBM
®
JDK 7.x and 8.0.
To install the unlimited Jurisdiction Policy Files:
1. Extract the local_policy.jar and US_export_policy.jar files from the
downloaded zip file.
2. Copy
local_policy.jar and US_export_policy.jar to the
<jdk install dir>/jre/lib/security directory, overwriting the
existing policy files.
Error when Re-Signing the Jar Files 7
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Error when Re-Signing the Jar Files
The following error can occur when re-signing cryptoj-6.2.5.jar or
cryptojce-6.2.5.jar:
Invalid SHA-1(or other SHA digest) signature file digest for
<class file name>.
This occurs because cryptoj-6.2.5.jar and cryptojce-6.2.5.jar are
signed by a SHA-256 digest algorithm. The Oracle JDK 6
jarsigner digest
algorithm defaults to SHA-1, while the Oracle JDK 7
jarsigner digest algorithm
defaults to SHA-256.
If this error occurs, supply
-digestalg SHA256 as a parameter for the jarsigner
executable. For example:
jarsigner -digestalg SHA256
-keystore <keystore>
-storepass <store_password>
-keypass <key_password> <jar_to_be_signed> <alias>
Errors when Running a Java Web Start Application
The following errors can occur when running a Java Web Start application on the
client side:
• Failed to validate signing of launch file. The signed
version does not match the downloaded version.
In addition to signing all jar files, the Java Network Launch Protocol (JNLP) file
must be signed. Refer to the following link for more details:
http://docs.oracle.com/javase/7/docs/technotes/guides/web/security/signedJNLP.html.
• The application launch for a Java Web Start application is blocked by a security
warning on the client side.
In addition to signing the JNLP file and all jar files using the same trusted
certificate, the application provider must follow the security guidelines from Java
Web Start. Refer to the document provided by Oracle at
http://docs.oracle.com/javase/tutorial/deployment/webstart/index/html.
8 Decrease the Time Taken for Cryptographic Operations
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Decrease the Time Taken for Cryptographic Operations
Entropy Generation
Crypto-J relies on the operating system to provide the entropy needed to seed the
SecureRandom object used for cryptographic operations. These operations can take
an unusually long time if the operating system is unable to provide sufficient entropy.
RSA recommends using a Hardware Security Module (HSM) with Crypto-J to
generate entropy.
Refer to the “HSM Random Number Generation Entropy” samples for the JsafeJCE
and Jsafe APIs in the RSA BSAFE Crypto-J Developers Guide.
Decrease the Time Taken for Cryptographic Operations that use
Blinding
By default, the following cryptographic operations use blinding for greater private key
protection:
• RSA decryption
• RSA signing
• DSA signing
• ECDSA signing.
To minimize the time taken to complete these operations, the
com.rsa.cryptoj.disable.blinding system and security property can be
used to disable all blinding:
For usage instructions and the security implications concerning this system and
security property, see Introduction To Crypto-J-> System and Security Properties
in the RSA BSAFE Crypto-J Developers Guide.
Convert Oracle JKS Keystore to PKCS #12 format 9
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Convert Oracle JKS Keystore to PKCS #12 format
The keytool utility has an importkeystore option, for JDK1.6.x onwards, which
can be used to convert a JKS keystore to PKCS #12 format.
<jdk_install_dir>/bin/keytool
-importkeystore
-srckeystore <src_jks_keystore>
-destkeystore <destination_p12_keystore>
-srcstoretype JKS
-deststoretype PKCS12
-srcstorepass <src_keystore_password>
-deststorepass <destination_keystore_password>
-srckeypass <src_keys_password>
-destkeypass <destination_keys_password>
-noprompt
Note: The ciphers used to encrypt the PKCS #12 keystore are the same used
in the JKS keystore. These may include a Non-FIPS 140 cipher, for example
RC2. To convert these into a FIPS 140 approved cipher, for example
Triple-DES, write a simple java class to import the PKCS #12 file and then
export it back out to a file. By default Crypto-J always uses FIPS 140
approved algorithms when exporting PKCS #12 files. Refer to the JsafeJCE
Samples -> Key Storage section of the RSA BSAFE Crypto-J Developers
Guide for information on how to load and export PKCS #12 key stores.
Error ‘Algorithm not allowable in FIPS140 Mode’
Older IBM JDK versions, such as IBM JDK7, may encounter an error Algorithm
not allowable in FIPS140 mode: FIPS186Random when Crypto-J is used
in FIPS140 mode.
This occurs because Crypto-J does not allow
FIPS186Random to be used in FIPS140
mode.
If this error occurs, RSA suggests an upgrade to the latest supported IBM JDK version
of the Java™ SE Runtime Environment:
• JDK7:
– x86
build pxi3270_27sr2fp10-20141218_02(SR2 FP10)
– x64
build pxa6470_27sr2fp10-20141218_02(SR2 FP10)
10 Use Crypto-J with J2EE Applications and Application Servers
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Use Crypto-J with J2EE Applications and Application
Servers
Java Application Servers use a hierarchy of class loaders to isolate the applications in
the Web and Enterprise JavaBeans containers. The use of class loaders affects how
Crypto-J can be used in this environment.
Static Registration
Crypto-J can be statically registered and successfully used in most Application Server
environments. Static registration allows the Application Server to take advantage of
Crypto-J, however there are some disadvantages to using this approach.
• All applications must use the statically registered Crypto-J. For static registration,
Crypto-J jars must be installed in the
ext directory of the Java runtime so that
they appear in the class path of all applications.
The existence of multiple instances of the Crypto-J jars in the class path is an
unsupported configuration, so no application can have a private copy of Crypto-J
within its EAR file.
• All applications must use the same version of Crypto-J, so if Crypto-J is updated
then all applications should be tested with the new version. Note that some
Application Servers may provide additional controls over isolation. Configuration
options may enable the installation of Crypto-J so that it is visible only to the
Application Server and not to the applications in the containers.
• It is necessary to shut down the entire Application Server in order to upgrade
Crypto-J.
Dynamic Registration
The use of dynamic registration can lead to a number of problems. The provider list is
maintained by the
java.security.Security class, which is in the Java Runtime
Library. As a result, any dynamically registered provider instance is available to all
applications.
Dynamic registration can work successfully if:
• The Crypto-J jars are installed in
ext directory of the JRE, not in any
application’s EAR file.
• Before registration, the applications checks if the JsafeJCE provider has already
been registered by another application.
This approach has the same disadvantages as static registration.
It is not recommended for applications that contain Crypto-J jars in their EAR file to
register their own instance of JsafeJCE, as that instance would be visible to other
applications.
Intermittent Test Failures with some EC Algorithms 11
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Where applications have their own copies of Crypto-J, it is possible for one
application to use a combination of classes from its own Crypto-J jars along with those
from a JsafeJCE instance registered by a different application. Problems such as
unexpected
ClassCastExceptions and unrecognized AlgorithmParameters
can result. This can even occur with a single application as it is being upgraded as
there may briefly be two instances of the same application. If applications are using
different versions of Crypto-J then the problems can be more severe.
Problems such as unexpected
ClassCastExceptions and unrecognized
AlgorithmParameters can result. If the applications are using different versions
of Crypto-J then the problems can be more severe.
Explicit use of Provider Instances
Crypto-J can be used as a library bundled within the EAR file of each application that
uses it. This provides all the usual advantages of an Application Server environment
such as allowing different applications to use different versions of Crypto-J, however
there are some restrictions:
• Crypto-J jars should not be loaded by a parent class loader and visible to the
application in addition to the private jars bundled in the EAR file.
– Crypto-J jars should not be installed in the
ext directory of the Java runtime.
– Crypto-J jars should not be added to the Application Server’s class path unless
the Application Server provides a mechanism to isolate this from applications.
• Applications must be written to exclusively use the
getInstance methods that
take a provider instance. To reduce the number of JsafeJCE instances created, they
could:
– Pass around the JsafeJCE instance
– Place the JsafeJCE instance as a static field on an application class.
• Applications should not register the JsafeJCE instance as that can interfere with
other applications.
Intermittent Test Failures with some EC Algorithms
Older IBM JDK versions, such as IBM JDK7, may encounter an error with some EC
algorithms. The failures seemed to occur for a variety of EC algorithms with curves
B233, K233, B409, K409. The common factor for these curves is the customized
FieldElementF2mTrinomialWithSmallMiddle.mod(BitString) method
These failures appear in release FP40 and not in FP50. There is no release between
FP40 and FP50.
12 Signature Verification Fails for some RSA PSS Signatures
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Signature Verification Fails for some RSA PSS
Signatures
When using RSA PSS Signature objects the JsafeJCE provider does not support using
a digest algorithm for the Mask Generation Function (MGF) that is different to the
digest algorithm used for the signature. For example, if an RSA PSS Signature object
is created using the algorithm string
SHA256withRSAandMGF1 then the signature
will be created using a SHA256 digest and the MGF will also use a SHA256 digest.
When verifying signatures, the JsafeJCE provider uses the same digest function for
the signature and the MGF. If a signature has been created by another JCE provider
using different digest functions for the signature and the MGF, then the JsafeJCE
provider will fail to verify this signature.
Use Crypto-J in FIPS 140-2 Mode on Oracle WebLogic
11g and 12c
Oracle WebLogic uses FIPS186PRNG as the default random algorithm. Use of
FIPS186PRNG is no longer allowed in FIPS-2 140 Mode.
To change the default random number generator used by Crypto-J, complete either
one of the following:
• Use the Oracle WebLogic system property to use the Crypto-J default random
algorithm. For example:
-Dweblogic.security.allowCryptoJDefaultPRNG=true
• Use the Crypto-J security property com.rsa.crypto.default.random to
change the default random algorithm as required. For example:
-Dcom.rsa.crypto.default.random=CTRDRBG128
The following are valid values for this security property:
For more information about the system and security properties in Crypto-J, see
Introduction To Crypto-J-> System and Security Properties in the RSA BSAFE
Crypto-J Developers Guide.
For information about how to use Crypto-J in FIPS 140-2 mode, see Use Crypto-J in
FIPS 140-2 Mode on Oracle WebLogic 11g and 12c.
• CTRDRBG
• CTRDRBG128
• CTRDRBG192
• CTRDRBG256
• HASHDRBG
• HASHDRBG128
• HASHDRBG192
• HASHDRBG256
• HMACDRBG
• HMACDRBG128
• HMACDRBG192
• HMACDRBG256
Use Crypto-J Jars in an EAR Application on Red Hat JBoss 13
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Use Crypto-J Jars in an EAR Application on Red Hat
JBoss
Use the following steps and recommendations to enable the use of Crypto-J jar files in
an EAR application for Red Hat
®
JBoss
®
(JBoss) application servers:
• Use Crypto-J jars in an EAR Application on JBoss 5 and 6
• Use Crypto-J jars in non-FIPS 140-2 mode, in an EAR Application on JBoss 7
• Use Crypto-J jars in FIPS 140-2 mode, in an EAR Application on JBoss 7.
Use Crypto-J jars in an EAR Application on JBoss 5 and 6
RSA recommends that the Crypto-J toolkit is not included in the EAR/WAR
application due to the default application deployment strategy in JBoss unpacking all
the jars in the application.
See JBAS-7882 (https://jira.jboss.org/browse/JBAS-7882) for more details.
To use Crypto-J jars in an EAR Application on JBoss 5 and 6:
1. Statically register JsafeJCE as the JCE provider as described in Statically Register
JsafeJCE Provider as the Default JCE Provider.
Use Crypto-J jars in non-FIPS 140-2 mode, in an EAR Application on
JBoss 7
To use Crypto-J jars in non-FIPS 140-2 mode, in an EAR Application on JBoss 7:
1. To allow the code source to be changed for Crypto-J jars to be used in non-FIPS
140-2 mode, edit the jboss:deployment-structure.xml file to add one of the
following
resources configurations:
<resources>
...
<resource-root path="<path_to_lib>/cryptoj-6.2.5.jar"
use-physical-code-source="true" />
</resources>
Or
<resources>
...
<resource-root path="<path_to_lib>/cryptojce-6.2.5.jar"
use-physical-code-source="true" />
<resource-root path="<path_to_lib>/cryptojcommon-6.2.5.jar"
use-physical-code-source="true" />
<resource-root path="<path_to_lib>/jcm-6.2.5.jar"
use-physical-code-source="true" />
...
</resources>
For more details about how to change the code source used by deployments, see
AS7-308 (https://issues.jboss.org/browse/AS7-308).
14 Use Crypto-J Jars in an EAR Application on Oracle WebLogic
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Use Crypto-J jars in FIPS 140-2 mode, in an EAR Application on
JBoss 7
To use Crypto-J jars in FIPS 140-2 mode, in an EAR Application on JBoss 7:
1. To allow the code source to be changed for Crypto-J jars to be used in FIPS 140-2
mode, edit the jboss:deployment-structure.xml file to add the following
resources configuration:
<resources>
...
<resource-root path="<path_to_lib>/cryptojce-6.2.5.jar"
use-physical-code-source="true" />
<resource-root path="<path_to_lib>/cryptojcommon-6.2.5.jar"
use-physical-code-source="true" />
<resource-root path="<path_to_lib>/jcmFIPS-6.2.5.jar"
use-physical-code-source="true" />
...
</resources>
For more details about how to change the code source used by deployments, see
AS7-308 (https://issues.jboss.org/browse/AS7-308).
Use Crypto-J Jars in an EAR Application on
Oracle WebLogic
To use the current release of Crypto-J in an EAR application on Oracle WebLogic,
load the Crypto-J jars from the application’s class path.
To load c
om.rsa packages from the application class path loader, add the following
prefer-application-packages configuration to the WebLogic Application
Deployment Descriptor file, weblogic-application.xml.
<wls:weblogic-application
...>
<wls:prefer-application-packages>
<wls:package-name>com.rsa.*</wls:package-name>
</wls:prefer-application-packages>
...
</wls:weblogic-application>
Gradle Incompatibility with Android Studio 15
RSA BSAFE Crypto-J 6.2.5 Troubleshooting Guide
Gradle Incompatibility with Android Studio
Due to the deprecation of one of the Gradle 4.0+ APIs, the following compilation
error occurs when using Gradle 4.0+ with Android Studio 3.0:
com.android.build.gradle.tasks.factory.AndroidJavaCompile.set
DependencyCacheDir(Ljava/io/File;)V
If this error occurs during the compilation process:
1. Check the version of Gradle:
gradle -version
2. Check the version of Android Studio.
– If you have an open project, go to Help > About to display the version.
– If you have Android Studio running, go to the Welcome Screen. The version
number is located under the logo.
3. If the version of Gradle is 4.0+ and the version of Android Studio is 3.0, change to
either Gradle 3.0+ or Android Studio 2.3.
Reuse of IV is Not Allowed in GCM Mode
Using the same IV with a secret key using AES in GCM mode is not secure. A check
has been added to prevent the accidental reuse of an IV.
When using the JCE API, the Cipher object is automatically reinitialized after a call to
the
doFinal() method. To reuse the Cipher object in this way in GCM mode is not
secure and will cause an
IllegalStateException with the message Reuse of IV
not allowed in GCM mode.
If the reuse of the same IV is really necessary, for example, because the same IV/key
combination has been used to encrypt multiple data sets, an
init() method that sets
the IV/key combination can be called on the Cipher object to prevent the exception.
Customization Using the System and Security Properties
System and security properties in Crypto-J are used to statically register the JsafeJCE
provider and to configure the toolkit and FIPS-140 mode behavior.
For more information about the system and security properties in Crypto-J, see
Introduction To Crypto-J-> System and Security Properties in the RSA BSAFE
Crypto-J Developers Guide.
/
