JDK-8271566 introduced a change in how sensitive PKCS #11 keys are identified. In addition to CKA_SENSITIVE = TRUE and CKA_EXTRACTABLE = FALSE, CKA_TOKEN = TRUE is used as a sufficient indicator of a private key being opaque. This change was motivated by the NSS Software Token but is non-standard and does not represent all PKCS #11 tokens.

For a token that has a private key with attributes CKA_TOKEN = TRUE, CKA_SENSITIVE = FALSE and CKA_EXTRACTABLE = TRUE, JDK-8271566 introduced an observable —and unintended— API change in KeyStore::getKey: a key object implementing the PrivateKey interface is returned (instance of P11RSAPrivateKeyInternal/P11DSAPrivateKeyInternal/Etc.) when one implementing the public interface RSAPrivateKey/DSAPrivateKey/Etc. should have been returned (instance of P11RSAPrivateKey/P11DSAPrivateKey/Etc).

The NSS Software Token considers private and secret keys with CKA_TOKEN = TRUE as sensitive, regardless of the CKA_SENSITIVE and CKA_EXTRACTABLE attributes. See NSC_GetAttributeValue [1], nsc_GetTokenAttributeValue [2] and sftk_isSensitive [3]. When keys have CKA_TOKEN = FALSE, CKA_SENSITIVE has to be TRUE for a private or secret key to be sensitive. See here [4] and here [5].

Update: the token where the regression was observed uses the ICSF PKCS #11 library.

--
[1] - https://github.com/nss-dev/nss/blob/NSS_3_90_RTM/lib/softoken/pkcs11.c#L4838
[2] - https://github.com/nss-dev/nss/blob/NSS_3_90_RTM/lib/softoken/pkcs11.c#L4789
[3] - https://github.com/nss-dev/nss/blob/NSS_3_90_RTM/lib/softoken/pkcs11u.c#L802
[4] - https://github.com/nss-dev/nss/blob/NSS_3_90_RTM/lib/softoken/pkcs11.c#L4864
[5] - https://github.com/nss-dev/nss/blob/NSS_3_90_RTM/lib/softoken/pkcs11.c#L4867