Support for PBMAC1 algorithms

[dev-koan]

This update adds support for PBMAC1 algorithms. The algorithms are supported for OpenJCEPlus and OpenJCEPlusFIPS provider. The PBMAC1Core class extends the regular HmacCore class overriding engineInit method as PBMAC1 uses PBKDF2 key derivation.
PBMAC1 tests have also been added.

Signed-off-by: Dev Agarwal dev.agarwal@ibm.com

[JinhangZhang]

Did you by any chance make a build and put openjceplus on the top of the order and create a PKCS12 keystore file with keytool command? e.g. by specifying -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256

[johnpeck-us-ibm]

Since, the need here is for use in keystore. I would like to see some keystore tests that test this functionality. First to make sure this work, but also to make sure the keystores created using our impliementation work when Sun's implementation is used.

[dev-koan]

Since, the need here is for use in keystore. I would like to see some keystore tests that test this functionality. First to make sure this work, but also to make sure the keystores created using our impliementation work when Sun's implementation is used.

I am reading P12 files using PKCS12 KeyStore after adding OpenJCEPlus to the top the security provider list.
If we have the required crypto the openjdk keystore class will use ours.

[johnpeck-us-ibm]

Since, the need here is for use in keystore. I would like to see some keystore tests that test this functionality. First to make sure this work, but also to make sure the keystores created using our impliementation work when Sun's implementation is used.

I am reading P12 files using PKCS12 KeyStore after adding OpenJCEPlus to the top the security provider list. If we have the required crypto the openjdk keystore class will use ours.

It might be fine than. However, sometimes keytool does things a little differently than our code and that causes issues. So, at the bare minimum I think it is best to verify the code using keytool. Even if the test is a one off and not added to our tests.

[jasonkatonica]

Instead of returning and assuming that the test was run we instead have been using assume statements. Something like the following would assume we are not using OpenJCEPlusFIPS for example and record it as skipped in Junit. Similar comment to other places where you check for fips provider and excute return.

assumeFalse("OpenJCEPlusFIPS".equals(getProviderName()) && ... .... ...    );

[dev-koan]

Updated.

[jasonkatonica]

No reason to assert true. You could however assert that the exception message is as expected in all these locations where we are doing an assertTrue(true);

[dev-koan]

Updated.

[jasonkatonica]

Can you please add some comments here as to where these pkcs12 file values were found. I believe that these were found in an RFC as a known answer test? Besides a comment saying where we obtained these values ideally we would add a comment showing the human readable asn1 breakdown of the value so we can easily know what is within these pcks12 files in terms of crypto.

Also my understanding is that these are not really PKCS12 standard files. They are RFC 9579 (and its successor, RFC 9879) format files correct?

[dev-koan]

The decoded value is extremely long and on directly copying pasting as text there is no indentation making it hard to read.
can still add it if preferred.

[jasonkatonica]

No need to strip out all the stack trace information or even to catch the exception. The try catch can be removed and just allow the exception to be thrown in the case of a failure. Similar comment for the rest of the checks being done here.

Maybe the test should also be parameterized such that there is not so much duplicate cod here taking in a pkcs12 file instead?

[dev-koan]

Updated.
Now using a helper method and letting the exception get thrown.

[jasonkatonica]

Should we assert the error message? Seems checking we are are getting a reasonable error message would be better then accepting any IOException that occurs. Similar comment on line 561 and 569.

[dev-koan]

WARNING: OpenJCEPlusFIPS is running in developer mode. Non production workload assumed. This environment is not certified for FIPS 140-3: Mac OS X:aarch64
WARNING: OpenJCEPlusFIPS is running in developer mode. Non production workload assumed. This environment is not certified for FIPS 140-3: Mac OS X:aarch64
Integrity check failed: java.security.UnrecoverableKeyException: Failed PKCS12 integrity checking

This is the exception message not sure if asserting the message provides much value.

[dev-koan]

Since, the need here is for use in keystore. I would like to see some keystore tests that test this functionality. First to make sure this work, but also to make sure the keystores created using our impliementation work when Sun's implementation is used.

I am reading P12 files using PKCS12 KeyStore after adding OpenJCEPlus to the top the security provider list. If we have the required crypto the openjdk keystore class will use ours.

It might be fine than. However, sometimes keytool does things a little differently than our code and that causes issues. So, at the bare minimum I think it is best to verify the code using keytool. Even if the test is a one off and not added to our tests.

I took the following steps to test PBMAC1 with keytool (with Bob's help)

1. A personal build with OpenJCEPlus first and bundled with PBMAC1 algos
2. Used the generated jdk to generate my p12 file using keytool with the command jdk/bin/keytool -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 -genkeypair -alias mykey -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore mykeystore.p12 -validity 365
3. Exported it to base64 to verify the crypto (Screenshot of the decoding is attached below)
4. Ran the following program to validate everything was working as expected.

public class run {
    public void main() throws Exception {
        // Security.insertProviderAt(new OpenJCEPlusFIPS(), 1);
        System.out.println(Security.getProviders()[0]);
        Mac t = Mac.getInstance("PBEWithHmacSHA384");
        System.out.println(t.getProvider().getName());

        KeyStore ks = KeyStore.getInstance("PKCS12");
        ks.load(new FileInputStream("mykeystore.p12"), "ibmcanada".toCharArray());

        String alias = "mykey";
        PrivateKey privateKey = (PrivateKey) ks.getKey(alias, "ibmcanada".toCharArray());
        Certificate cert = ks.getCertificate(alias);
        PublicKey publicKey = cert.getPublicKey();
        
        // 3. Sign some data
        Signature signature = Signature.getInstance("SHA256withRSA");
        signature.initSign(privateKey);
        String data = "Test data to sign";
        signature.update(data.getBytes());
        byte[] signedData = signature.sign();
        
        // 4. Verify the signature
        signature.initVerify(publicKey);
        signature.update(data.getBytes());
        boolean verified = signature.verify(signedData);
        
        System.out.println("P12 file is valid: " + verified);
    }
}

[johnpeck-us-ibm]

Since, the need here is for use in keystore. I would like to see some keystore tests that test this functionality. First to make sure this work, but also to make sure the keystores created using our impliementation work when Sun's implementation is used.

I am reading P12 files using PKCS12 KeyStore after adding OpenJCEPlus to the top the security provider list. If we have the required crypto the openjdk keystore class will use ours.

It might be fine than. However, sometimes keytool does things a little differently than our code and that causes issues. So, at the bare minimum I think it is best to verify the code using keytool. Even if the test is a one off and not added to our tests.

I took the following steps to test PBMAC1 with keytool (with Bob's help)

1. A personal build with `OpenJCEPlus` first and bundled with PBMAC1 algos

2. Used the generated jdk to generate my p12 file using keytool with the command `jdk/bin/keytool -J-Dkeystore.pkcs12.macAlgorithm=PBEWithHmacSHA256 -genkeypair -alias mykey -keyalg RSA -keysize 2048 -storetype PKCS12 -keystore mykeystore.p12 -validity 365`

3. Exported it to base64 to verify the crypto (Screenshot of the decoding is attached below)

4. Ran the following program to validate everything was working as expected.

public class run {
    public void main() throws Exception {
        // Security.insertProviderAt(new OpenJCEPlusFIPS(), 1);
        System.out.println(Security.getProviders()[0]);
        Mac t = Mac.getInstance("PBEWithHmacSHA384");
        System.out.println(t.getProvider().getName());

        KeyStore ks = KeyStore.getInstance("PKCS12");
        ks.load(new FileInputStream("mykeystore.p12"), "ibmcanada".toCharArray());

        String alias = "mykey";
        PrivateKey privateKey = (PrivateKey) ks.getKey(alias, "ibmcanada".toCharArray());
        Certificate cert = ks.getCertificate(alias);
        PublicKey publicKey = cert.getPublicKey();
        
        // 3. Sign some data
        Signature signature = Signature.getInstance("SHA256withRSA");
        signature.initSign(privateKey);
        String data = "Test data to sign";
        signature.update(data.getBytes());
        byte[] signedData = signature.sign();
        
        // 4. Verify the signature
        signature.initVerify(publicKey);
        signature.update(data.getBytes());
        boolean verified = signature.verify(signedData);
        
        System.out.println("P12 file is valid: " + verified);
    }
}

Did you verify that keytool used OpenJCEPlus when it created the file?