Mulesoft GovCloud Blowfish Migration

If an application is using the Blowfish algorithm for secure property file encryption, will it fail to start/run?

Yes, an application using the Blowfish algorithm for secure property file encryption will fail to start or run in the new, FIPS-enforced runtime.

Here is the reason why:

1. Blowfish is Not a FIPS-Validated Cipher: The Blowfish algorithm is not, and has never been, approved by NIST under the Federal Information Processing Standards (FIPS). It is considered a legacy, non-standard cipher.

2. Strict FIPS Mode Enforcement: The new security upgrade configures the Bouncy Castle FIPS (BCFIPS) module to operate in its strict, FIPS-approved mode. This mode explicitly disallows the use of any non-validated algorithms, which prevents the application from starting if it requests Blowfish for decryption.

This behavior is a core part of the new FIPS enforcement, as it guarantees that only approved cryptography is used within the runtime.

How to Remediate Secrets Encrypted with Non-Compliant Ciphers

Customers must re-encrypt any secrets that were previously encrypted with a non-compliant cipher like Blowfish.

The recommended approach is to replace Blowfish with AES using CBC mode. AES is the modern federal standard for symmetric encryption (FIPS 197), and using it in CBC mode is a FIPS-approved method for ensuring confidentiality that is directly supported by MuleSoft's Secure Properties Tool.

You have two primary options for this remediation: rotating the secret or migrating the secret. Both options are performed within the application's source code project before deploying to the new FIPS-enforced runtime.

Option 1 and Option 2 are provided as examples, for a detailed guide and to download the Secure Properties Tool, see Mule Runtime: Secure Configuration Properties. 

Option 1: Rotate the Secret (Recommended)

This is the simplest and most secure approach. It involves generating a new secret and encrypting it directly with the FIPS-compliant AES algorithm.

1. Generate New Secret: In the source system (e.g., database, API provider), generate a new password, API key, or token.

2. Encrypt New Secret: On your local machine, use the secure-properties-tool.jar to encrypt the new plaintext secret using AES.

# Encrypt the *new* secret directly with AES

java -cp secure-properties-tool-j17.jar com.mulesoft.tools.SecurePropertiesTool string encrypt AES CBC <your-key> "<new-plaintext-secret>"

3. Update Project: Replace the old encrypted value in your project's properties file with the new one.

Option 2: Migrate the Existing Secret

This approach is for secrets that are difficult to rotate (e.g., a shared private key). It requires you to know the original encryption key.

1. Decrypt Old Secret: On your local machine, use the secure-properties-tool.jar to decrypt the existing Blowfish-encrypted secret and retrieve the plaintext value.

# Decrypt the old secret to get the plaintext

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool string decrypt Blowfish CBC <your-key> "<old-encrypted-string>"

2. Re-encrypt with AES: Use the tool again to re-encrypt the recovered plaintext secret with the AES algorithm.

# Re-encrypt the plaintext secret with AES

java -cp secure-properties-tool.jar com.mulesoft.tools.SecurePropertiesTool string encrypt AES CBC <your-key> "<plaintext-secret>"

3. Update Project: Replace the old encrypted value in your project's properties file with the new one.

Final Step: Update Application Configuration

After following either of the options above, you must ensure your Mule application's global configuration is updated to use the new AES algorithm.

In your Mule project's configuration XML, verify that the secure-properties:config element specifies AES:

<secure-properties:config key="${encryption.key}" file="your-properties.yaml" name="secureProps">

    <!-- Ensure the algorithm attribute is set to AES -->

    <secure-properties:encrypt algorithm="AES" mode="CBC"/>

</secure-properties:config>