Non-Compliance with NIST Standard for RSA and ECC Key Size Discovery in PIV Implementation

[Sanmilie]

public static KeyType fromKeyParams(PrivateKeyValues keyValues)

public static KeyType fromKey(Key key)

These functions not respect the key size discovery statement in the norm : https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf page 48 C.1 PIV Algorithm Identifier Discovery for Asymmetric Cryptographic Authentication As illustrated in the authentication mechanisms in Appendix B, an asymmetric cryptographic authentication involves issuing a challenge (request to sign a nonce) to the PIV Card. The relying party issuing the command provides the nonce to be signed, the key reference, and the PIV algorithm identifier as parameters of the command. The nonce is random data generated by the relying party and the key reference is known. The PIV algorithm identifier, on the other hand, is unknown to the relying party and needs to be identified in order to issue the challenge command. The PIV algorithm identifier can be derived from the previous steps of the authentication mechanism. The relying party, prior to issuing the challenge command, retrieved and parsed the X.509 certificate from the card in order to 1) validate the certificate and 2) extract the public key for the pending verification of the signed nonce once returned from the card. It is during the parsing of the X.509 certificate that the PIV algorithm identifier can be identified in two steps:27 Step 1: Algorithm Type Discovery: The X.509 certificate stores the public key in the subjectPublicKeyInfo field. The subjectPublicKeyInfo data structure has an algorithm field, which includes an OID that identifies the public key’s algorithm (RSA or ECC) as listed in Table 3-4 of SP 800-78. Step 2: Key Size Discovery: If the algorithm type, as determined in Step 1, is ECC then the key size is determined by the elliptic curve on which the key has been generated, which is P-256 for all elliptic curve PIV Authentication keys and Card Authentication keys. If the algorithm type, as determined in Step 1, is RSA then the key size is determined by the public key’s modulus. The public key appears in the subjectPublicKey field of subjectPublicKeyInfo and is encoded as a sequence that includes both the key’s modulus and public exponent.

The norm is not restrictive for the RSA algorithm. The norm instructs to use the modulus from the public key, regardless of the type of key used for generation. Please adjust the function according to these specifications. This allows for key signatures greater than RSA 2048 and is in accordance with the PIV norm. Typically, it is the public certificate, not the private key, that is used. The PIV application does not have knowledge of the private slot or the key size. This data is usually inaccessible to the PIV application. In this context, the correct implementation is to take the modulus of the public key and build the challenge with it. The PIV device knows the truth about the key and it is the device’s responsibility to return an error, not the PIV application’s. If the device returns a bad length, the key is not supported. It is important to respect the role of each. The PIV application does not build the key parameters from the norm; it discovers the algorithm and size from the public key.

[dainnilsson]

I'm not sure I follow, is there something in the current API that prevents you from doing key algorithm and size discovery as you've outlined above?

[Sanmilie]

I am using a new pre-release version of a PIV device that supports RSA 4096-bit keys for use in Android with Microsoft Authenticator. However, the signature is not being generated because your Android kit is used by the Microsoft Authentication Library (MSAL) does not comply with the PIV norm and rejects RSA keys greater than 2048 bits. It’s important to note that the PIV norm does not specifically limit the use of RSA keys for PIV application implementation; however, the limitation on the ECC curve is related to p256.

In future publications, the algorithm identifiers for RSA 4096 are 4 and 5, while for RSA 3072, you can find them in the public draft available at this link https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-5.ipd.pdf . Although the new implementation document has not been released yet, the old implementation sends 0x07 for any size of RSA key greater than 2048. It’s important to note that the algorithm identifier is not actively used in the card; it is primarily used for key generation. The card’s slots contain the necessary information about the algorithm and size to validate the generated padding.

[dainnilsson]

This issue was due to using the SDK with an unreleased product with features unsupported by this library at the time. YubiKey 5.7 supports RSA keys up to 4096, and this SDK has been updated to do so as well. If you run into issues with the current version of the SDK (2.6.0) please feel free to open a new issue!