Mosip 42334

[kameshsr]

No description provided.

The best solution is to avoid using "RSA/ECB/NoPadding" and instead use "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" (or similar, depending on what is supported). This ensures that padding and unpadding are handled by trusted, tested library functions, which drastically lowers the risk of padding oracle and similar attacks. The main required change is in the cipher instantiation within asymmetricDecrypt:
Replace all references in this method to "RSA/ECB/NoPadding" (RSA_ECB_NO_PADDING) with "RSA/ECB/OAEPWithSHA-256AndMGF1Padding", using standard OAEP parameters with SHA-256 as the hash and MGF1.

• The constant RSA_ECB_NO_PADDING on line 85 can be replaced or a new appropriately named constant can be added (e.g., RSA_ECB_OAEP_PADDING).
• The cipher initialization in asymmetricDecrypt should be updated to use the OAEP algorithm and, if required, consistently provide the OAEP parameters (with SHA-256, MGF1, and default PSource).
• Remove the call to the custom/deprecated unpadOAEPPadding, as OAEP unpadding will be handled by the Cipher.
• Remove the workaround comment and related code blocks.

The changes are localized to asymmetricDecrypt and the relevant constant, with no change to the rest of the class functionality.

---

To properly fix the vulnerability, the RSA cipher initialization must use OAEP padding instead of no padding. Specifically, in the asymmetricDecrypt method at line 370, update the cipher initialization from RSA_ECB_NO_PADDING (likely "RSA/ECB/NoPadding") to "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". Additionally, OAEP padding should be configured via an OAEPParameterSpec to ensure MGF1 and a hash function (like SHA-256) are used. This change applies unless the keystore type or HSM provider truly does not support OAEP; in such cases, a clear fallback and possibly a blocking exception with a strong warning should be used instead of proceeding with insecure decryption.
Edit the cipher initialization block and also the cipher.init(...) call on line 379 to supply the OAEP parameters for key decryption. Remove or update the subsequent manual unpadding, since the cipher should now handle padding natively.

• Edit the cipher getInstance calls (line 370/371) to request OAEP padding.
• Add/support OAEP parameters via OAEPParameterSpec as needed.
• Remove or bypass the manual OAEP unpadding (unpadOAEPPadding) since padding will be handled by the cipher.
• Ensure imports for OAEP are present (javax.crypto.spec.OAEPParameterSpec etc.).
• Make sure any callers (e.g., asymmetricDecrypt overloads) calling this are not broken by the change.

---

The best fix is to use OAEP padding in the Cipher instance, i.e., replace RSA_ECB_NO_PADDING with a specification that uses OAEP padding (e.g., "RSA/ECB/OAEPWithSHA-256AndMGF1Padding" or similar, depending on your environment and provider). If storeType is not provided, use OAEP padding by default; if SoftHSM now supports OAEP, use it there too.

If OAEP is not supported by the existing provider, the underlying HSM or PKCS#11 module may need to be upgraded. If so, fallback logic (which is discouraged) could remain temporarily, but ONLY after all feasible efforts to upgrade to OAEP support are made.

In the code region around lines 370-371, change how the Cipher is instantiated to always use OAEP padding, removing any use of "NoPadding". You may also need to adapt how manual OAEP unpadding is done—ideally, remove it because the cipher now handles the padding properly.

Specifically:

• Change RSA_ECB_NO_PADDING to an OAEP padding string, e.g., "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"
• Remove manual OAEP unpadding if possible
• Adjust imports only if necessary, but you have all needed OAEP classes imported.

---

To fix the problem, the cipher transformation should be changed from "AES/ECB/NoPadding" to "AES/GCM/NoPadding". GCM is a modern, secure, authenticated mode for AES, mitigating the risks inherent in ECB.

• Edit the WRAPPING_TRANSFORMATION string on line 43 to "AES/GCM/NoPadding".
• The cipher initialization at line 80 (Cipher.getInstance(WRAPPING_TRANSFORMATION)) will now use GCM.
• Any use of Cipher created through this thread-local should be audited (outside your snippet) to ensure it properly provides and expects the GCM mode, specifically setting a secure random IV for GCM mode (e.g., via GCMParameterSpec). You should at minimum add an inline note indicating that callers must set a secure IV and GCM parameters before use.
• No extra dependencies are needed; Java's standard library supports GCM mode from Java 8 onwards.
• No other code blocks in the provided snippet show compatibility concerns, but if logic is later found that assumes ECB (e.g., block sizes, lack of IV), further refactoring may be required.

---