Bug 2007331 - SecretKey generate/import operations don't add the CKA_SIGN attribute in FIPS mode [rhel-8, openjdk-17]
Summary: SecretKey generate/import operations don't add the CKA_SIGN attribute in FIPS...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: java-17-openjdk
Version: 8.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Francisco Ferrari Bihurriet
QA Contact: OpenJDK QA
URL:
Whiteboard:
Depends On:
Blocks: 2108191 2020290 2108190
TreeView+ depends on / blocked
 
Reported: 2021-09-23 15:13 UTC by zzambers
Modified: 2022-11-08 10:13 UTC (History)
7 users (show)

Fixed In Version: java-17-openjdk-17.0.3.0.7-5.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 2108190 2108191 (view as bug list)
Environment:
Last Closed: 2022-11-08 09:30:31 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Fedora Package Sources java-17-openjdk pull-request 17 0 None None None 2022-10-14 15:23:19 UTC
Red Hat Issue Tracker RHELPLAN-98073 0 None None None 2021-09-23 15:16:29 UTC
Red Hat Product Errata RHBA-2022:6691 0 None None None 2022-11-08 09:31:34 UTC

Description zzambers 2021-09-23 15:13:58 UTC
Mac keys generated by KeyGenerator do not work with the corresponding Mac in FIPS mode. The same failure is obtained with keys imported from plain bytes (through the Bug 1991003 work). This second case had already been identified and fixed in Bug 2020290 (and reported upstream [5]).

The Mac service initialization fails with CKR_KEY_TYPE_INCONSISTENT because the generated key doesn't have the CKA_SIGN attribute: see how NSC_SignInit() calls sftk_InitGeneric(..., CKA_SIGN) to verify the attribute [1], this ends up calling sftk_isTrue(key, operation) with operation=CKA_SIGN [2].


Original reproducer for the 'generate' operation:
/////////////////////////////////////////
import javax.crypto.KeyGenerator;
import javax.crypto.Mac;
import java.security.Key;

public class MacTest {
    public static void main(String[] args) throws Exception {
        Mac mac = Mac.getInstance("HmacSHA256");
        KeyGenerator kg = KeyGenerator.getInstance("HmacSHA256");
        Key key = kg.generateKey();
        System.out.println("key: " + key);
        mac.init(key);
    }
}

Also see the comment 2 reproducer, for the 'import' operation.

Failure:
////////////////////////////////////////
Exception in thread "main" java.security.InvalidKeyException: init() failed
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Mac.engineInit(P11Mac.java:214)
	at java.base/javax.crypto.Mac.chooseProvider(Mac.java:365)
	at java.base/javax.crypto.Mac.init(Mac.java:434)
	at MacTest.main(MacTest.java:11)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT
	at jdk.crypto.cryptoki/sun.security.pkcs11.wrapper.PKCS11.C_SignInit(Native Method)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Mac.initialize(P11Mac.java:183)
	at jdk.crypto.cryptoki/sun.security.pkcs11.P11Mac.engineInit(P11Mac.java:212)
	... 3 more


Additional info:
////////////////
Mac however works with key obtained from "SunTls12KeyMaterial" (internal class) following way: [3]. Note that SunPKCS11 provider in earlier JDKs did not provide Mac key generators and this was the only way (I am aware of) to obtain Mac key. Mac key generators were added to SunPKCS11 together with SHA3 support [4].

This means that the 'generate' operation isn't available in earlier JDKs, however the issue for the 'import' operation is reproducible in 8 & 11. An updated and more polished reproducer that works in OpenJDK 8, 11 & 17 is in bug 2105395, comment 7.

[1] https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L2777-L2778
[2] https://github.com/nss-dev/nss/blob/NSS_3_67_RTM/lib/softoken/pkcs11c.c#L444
[3] https://github.com/judovana/CryptoTest/blob/a4bb593d6faa2052606fffb0554141c63468efbb/cryptotest/utils/KeysNaiveGenerator.java#L144
[4] https://bugs.openjdk.java.net/browse/JDK-8242332
[5] https://bugs.openjdk.java.net/browse/JDK-8278640

Comment 2 Jonathan Klotzbach 2022-06-20 22:45:26 UTC
I am having the same issue and have raised a Red Hat ticket. They told me to ask for an escalation on this so that it gets more attention. 

I am getting this issue when using this code as well:

import javax.crypto.spec.SecretKeySpec;
import javax.crypto.Mac;

public class HmacTest {

        private static final byte[] CLIENT_KEY_HMAC_KEY = "Client Key".getBytes();
        private static String HMAC_ALGORITHM_NAME = "HmacSHA256";

        public static void main (String[] args) {
            try {
                SecretKeySpec sKey = new SecretKeySpec(CLIENT_KEY_HMAC_KEY, HMAC_ALGORITHM_NAME);
                Mac mac = Mac.getInstance(HMAC_ALGORITHM_NAME);
                mac.init(sKey);
                System.out.println(mac.doFinal("message".getBytes()));
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
}

Comment 3 Andrew John Hughes 2022-06-21 16:16:35 UTC
What is the full RPM version of the OpenJDK version where you're seeing this failure?

Comment 4 zzambers 2022-06-21 16:24:13 UTC
I think any jdk17 rpm should do. I think this probably never worked (at least not on NSS). Generators were added in JDK16.

Comment 5 zzambers 2022-06-21 16:28:30 UTC
Hmac* KeyGenerators were added in JDK16.

Comment 6 Jonathan Klotzbach 2022-06-22 16:05:18 UTC
Just as an added note - this is the version of Java that we have installed:

java-17-openjdk-devel-17.0.3.0.7-2.el8_6.x86_64

Comment 7 Francisco Ferrari Bihurriet 2022-06-23 02:15:13 UTC
Using the following in nss.fips.config makes this test pass:
attributes(generate,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true }

This is related to https://access.redhat.com/support/cases/03208568


If we combine that with the work belonging to Bug 2020290 (which does the same but for the 'import' operation instead of 'generate'), we should finally end up with:
attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true }


See https://docs.oracle.com/en/java/javase/17/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9__PKCS11-ATTRIBUTES-CONFIGURATION

Comment 8 Francisco Ferrari Bihurriet 2022-06-23 17:13:31 UTC
Some clarifications
===================

 • Comment 0 reproducer uses the KeyGenerator service to create the key, so it involves the 'generate' operation
 • Comment 2 reproducer directly passes a SecretKeySpec, so it involves the 'import' operation, and it additionally requires Bug 1994661 work [*]
   • Additionally, this test fails with CKR_KEY_SIZE_RANGE because the key must be at least 16 bytes long due to FIPS restrictions

In OpenJDK 17, if I increase the key size of Comment 2 reproducer and add the following to nss.fips.cfg, both reproducers end without any errors:
attributes(*,CKO_SECRET_KEY,CKK_GENERIC_SECRET)={ CKA_SIGN=true }

In OpenJDK 11 and OpenJDK 8, with the same addition to nss.fips.cfg, Comment 2 reproducer works (with a 16 bytes key). Comment 0 reproducer still fails with 'NoSuchAlgorithmException: HmacSHA256 KeyGenerator not available', due to the absence of JDK-8242332 work (as already mentioned).


[*]: As shown in the following stack for OpenJDK 17:
     [1]: sun.security.pkcs11.FIPSKeyImporter.importKey(FIPSKeyImporter.java:67)
          [...] java.lang.invoke.LambdaForm* [...]
     [2]: sun.security.pkcs11.wrapper.PKCS11$FIPSPKCS11.C_CreateObject(PKCS11.java:1970)
     [3]: sun.security.pkcs11.P11SecretKeyFactory.createKey(P11SecretKeyFactory.java:285)
     [4]: sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:191)
     [5]: sun.security.pkcs11.P11SecretKeyFactory.convertKey(P11SecretKeyFactory.java:123)
     [6]: sun.security.pkcs11.P11Mac.engineInit(P11Mac.java:210)
     [7]: javax.crypto.Mac.chooseProvider(Mac.java:365)
     [8]: javax.crypto.Mac.init(Mac.java:434)

[1]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/FIPSKeyImporter.java#L67
[2]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11.java#L1970
[3]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L285
[4]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L191
[5]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java#L123
[6]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java#L210
[7]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/java.base/share/classes/javax/crypto/Mac.java#L365
[8]: https://github.com/rh-openjdk/jdk/blob/abcd0954643eddbf826d96291d44a143038ab750/src/java.base/share/classes/javax/crypto/Mac.java#L434

Comment 9 Francisco Ferrari Bihurriet 2022-06-30 18:43:04 UTC
Proposed equivalent Fedora pull request for the fix: https://src.fedoraproject.org/rpms/java-17-openjdk/pull-request/17#request_diff

Comment 25 errata-xmlrpc 2022-11-08 09:30:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (java-17-openjdk bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:6691


Note You need to log in before you can comment on or make changes to this bug.