Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvement: EC (Elliptic-curve) Private Key Decryption Compatibility for Incoming Messages #403

Merged
merged 4 commits into from
Nov 22, 2024

Conversation

szabarna
Copy link
Contributor

Description

This pull request enhances OpenAS2’s BCCryptoHelper.java to support decryption for messages when the recipient’s private key is based on Elliptic Curve (EC) cryptography, in addition to the existing support for RSA. Previously, OpenAS2’s decryption functionality could only handle RSA-based private keys, leading to limitations when users relied on EC-based cryptography for incoming message decryption.
Problem Statement

In OpenAS2, incoming messages are encrypted by the sender using the recipient’s public certificate, and the recipient decrypts them using their private key. However, if the recipient’s private key was based on EC cryptography, OpenAS2’s BCCryptoHelper could not properly identify or process the decryption. This limitation prevented any message encrypted with the recipient’s EC-based public key from being decrypted by OpenAS2, thus obstructing the ability to receive encrypted messages for organizations using EC private keys.
Solution

The updated BCCryptoHelper.java extends the existing decryption method to support both RSA and EC-based private keys:

Key Algorithm Detection: The decryption method now dynamically checks whether the recipient’s private key uses RSA or EC cryptography and selects the appropriate decryption algorithm.
Recipient Type Handling: Different recipient types (KeyTransRecipientInformation for RSA and KeyAgreeRecipientInformation for EC) are identified and processed accordingly. This ensures that the correct algorithm is used for each private key type without additional configuration.

Changes Made

Modified the decrypt function in BCCryptoHelper.java to support EC-based keys alongside RSA by adding checks for the key algorithm and using appropriate recipient types for each.
Added debug logging to assist in diagnosing recipient matching issues, showing details about recipient IDs and types when a match fails.

Benefits

Broadened Cryptography Support: OpenAS2 now supports decryption with both RSA and EC-based private keys, allowing greater flexibility and security options for users.
Compatibility for Modern Cryptographic Standards: As more organizations adopt EC cryptography, OpenAS2 users can leverage EC-based security without hindrance.

Testing

This update has been successfully tested with both RSA- and EC-based cryptography setups to confirm that OpenAS2 can now decrypt incoming messages regardless of the recipient’s key type.
Summary

The enhancement broadens OpenAS2’s decryption capability, enabling it to support both RSA and EC-based private keys, which aligns with modern cryptographic standards and allows users greater flexibility in their security configurations. This approach resolves the previous limitations with EC cryptography, ensuring that OpenAS2 remains compatible with a wider range of encryption standards in secure communications.

@szabarna szabarna changed the title Add EC Private Key Decryption Compatibility for Incoming Messages Improvement: EC Private Key Decryption Compatibility for Incoming Messages Nov 14, 2024
@szabarna szabarna changed the title Improvement: EC Private Key Decryption Compatibility for Incoming Messages Improvement: EC (Elliptic-curve) Private Key Decryption Compatibility for Incoming Messages Nov 14, 2024
Copy link
Contributor

@uhurusurfa uhurusurfa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution. Looks good to me.

In order to ensure the EC based certificate path gets tested as part of the CI/CD run please can you change the certificates for the "openas2b" alias to an EC algorithm certificate in the as2_certs.p12 file here:
https://github.com/OpenAS2/OpenAs2App/blob/master/Server/src/test/resources/OpenAS2ServerTest/OpenAS2A/config/as2_certs.p12

... then copy that file to the matching folder here overwriting the file of the same name in the below folder:
https://github.com/OpenAS2/OpenAs2App/blob/master/Server/src/test/resources/OpenAS2ServerTest/OpenAS2B/config/as2_certs.p12

Copy link
Contributor

@uhurusurfa uhurusurfa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀 Thank you!

@uhurusurfa
Copy link
Contributor

I can only imagine that the Windows failures are a result of some change or error in configuring Windows instances deployed for running Java testing.
I will check in again on Monday and try to rerun the failed tests.

@szabarna
Copy link
Contributor Author

Hi! I realized this needs more testing and also i am updating the encryption part as well to support EC based private keys. Currently the test between A and B partner is failing, i will commit my changes when i got over this problem and tested it throughly.

@szabarna
Copy link
Contributor Author

Should i extend the getOutputEncryptor function to handle OID-s for EC as well? What i mean is rather than hardcoding the encryption algorithm here:

        JceKeyAgreeRecipientInfoGenerator recipientGenerator
                = new JceKeyAgreeRecipientInfoGenerator(
                    CMSAlgorithm.ECMQV_SHA256KDF, 
                    keypair.getPrivate(), 
                    keypair.getPublic(),
                    CMSAlgorithm.AES128_WRAP
                    ).setProvider("BC");

        recipientGenerator.addRecipient((X509Certificate) receiverCert);

        encryptor = new JceCMSContentEncryptorBuilder(CMSAlgorithm.AES128_CBC)
        .setProvider("BC").build();

I will leave the keyAgreementOID as it is: CMSAlgorithm.ECMQV_SHA256KDF.

But the encryptionOID should come from the partnership, in this context i am talking about:
CMSAlgorithm.AES128_WRAP and CMSAlgorithm.AES128_CBC

What are your thoughts?

@uhurusurfa
Copy link
Contributor

It is looking good.

Yes please use the "algorithm" parameter passed into the encrypt() method for the EC by doing this on line 316:

encryptor = new JceCMSContentEncryptorBuilder(getOutputEncryptor(algorithm));

…pientInfoGenerator and its OutputEncryptor
Copy link
Contributor

@uhurusurfa uhurusurfa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀 Perfect. thank you for the excellent contribution.

@uhurusurfa uhurusurfa merged commit cac360f into OpenAS2:master Nov 22, 2024
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants