PKINIT fails with PKCS#11 middlware that implements PKCS#1 V2.1

[Jacques]

Problem: can't do PK-INIT with a smartcard PKCS#11 middleware that implements PKCS#1 v2.10

$ kinit -E name.surname@something@REALM

-> fails

Diagnostic using PKCS11-SPY from OpenSC:

16: C_Sign
2016-09-16 14:31:53.265
[in] hSession = 0x6bc3a70e
[in] pData[ulDataLen] 0931e898 / 33
    00000000 30 1F 30 07 06 05 2B 0E 03 02 1A 04 14 17 07 D3 0.0...+.........
    00000010 5A 2B F8 78 C0 FD CD 87 EE 25 08 C2 DD AA 50 3D Z+.x.....%....P=
    00000020 DC .
Returned: 32 CKR_DATA_INVALID

The signing algorithm is SHA1. However the Data Formatting is incorrect:

30 1F 30 07 06 05 2B 0E 03 02 1A 04 14 17 07 D3 5A 2B F8 78 C0 FD CD 87 EE 25 08 C2 DD AA 50 3D DC

instead it should be:

30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 17 07 D3 5A 2B F8 78 C0 FD CD 87 EE 25 08 C2 DD AA 50 3D DC

See the PKCS#1 paper (page 43) https://tools.ietf.org/html/rfc3447

Extract:
"
1. For the six hash functions mentioned in Appendix B.1, the DER
      encoding T of the DigestInfo value is equal to the following:

      MD2: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 02 05 00 04
                   10 || H.
      MD5: (0x)30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04
                   10 || H.
      SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H.
"

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: krb5-pkinit 1.12+dfsg-2ubuntu5.2
Uname: Linux 3.13.0-68-generic x86_64
Architecture: amd64
Date: Fri Sep 30 12:49:09 CEST 2016
ProcEnviron:
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
SourcePackage: krb5-pkinit

[Sam Hartman (hartmans)]

I've forwarded this to upstream krbdev.mit.edu #8506
I don't know if this is pkcs 11 2.10 specific or specific to the backend in question, but it's worth having upstream take a look.

[Taylor Yu (tlyu)]

RFC 3447 seems somewhat ambiguous about whether the AlgorithmIdentifier parameters (which consist of an ASN.1 NULL, DER-encoded as 05 00) must be present in various situations. Cross-checking with various CMS RFCs suggests that they are required when using EMSA-PKCS1-v1_5. cms_signeddata_create() in pkinit_crypto_openssl.c appears to omit the parameters when id_cryptoctx->mech is CKM_RSA_PKCS, which leads me to wonder how this ever worked. (Maybe this combination of conditions -- a token that can only do CKM_RSA_PKCS that also verifies the encoding of the DigestInfo -- is rare, but I lack sufficient information to be certain.)

[Jacques (caramba696)]

Sorry, I was referring to PKCS#1 v2.2

See https://www.emc.com/collateral/white-papers/h11300-pkcs-1v2-2-rsa-cryptography-standard-wp.pdf

Page 49, B.1

Exception: When formatting the DigestInfoValue in EMSA-PKCS1-v1_5 (see 9.2), the
parameters field associated with id-sha1, id-sha512/224, id-sha224, id-sha256, id-sha384,
id-sha512, and id-sha512/256 shall have a value of type NULL. This is to maintain
compatibility with existing implementations and with the numeric information values
already published for EMSA-PKCS1-v1_5 which are also reflected in IEEE 1363a-2004
[26].

[Taylor Yu (tlyu)]

Thanks. It seems that omitting the NULL would produce signatures that don't interoperate (or would require additional code complexity in the signature verifier). With default compilation options, pkinit_crypto_openssl.c forces PKCS11 tokens to use CKM_RSA_PKCS, so it's unlikely that this code has worked at all in the recent past. (Older versions might have checked the crypto token's mechanism list; I haven't tracked down the history yet.)

[Jacques (caramba696)]

Thanks for this.
So maybe I could try recompiling with the flag PKINIT_USE_MECH_LIST
?

[Taylor Yu (tlyu)]

That is one possible workaround, but I don't have an easy way to test this.

[Taylor Yu (tlyu)]

Also there's a proposed patch in https://github.com/krb5/krb5/pull/550 if you would be interested in testing that out.

[Jacques (caramba696)]

The patch in https://github.com/krb5/krb5/pull/550 works well for me!
Thanks

[Taylor Yu (tlyu)]

Thanks for the confirmation!

What name should I use for you in acknowledgments?

[Jacques (caramba696)]

You can use my surname: Florent

And thanks again for you quick help!