Dell BSAFE Crypto-J User guide

Brand: Dell

Model: BSAFE Crypto-J

Type: User guide

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

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:

...

<resource-root path="<path_to_lib>/cryptoj-6.2.5.jar"

use-physical-code-source="true" />

</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:

...

<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.

Dell BSAFE Crypto-J User guide

Dell BSAFE Crypto-J User guide

Dell BSAFE Crypto-J User guide

Related papers

Other documents