RSA Verify

[DIEGGOMEZ]

Hi @ayushev ,

I am trying to test the RSA verification, with the root CA inside 0xE0EF, but invalid parameter is always occuring, this is the code:

Any idea?

[ayushev]

Hello @DIEGGOMEZ ,

1. the function call doesn't correspond to a call pattern mentioned in the previous issue
2. Not sure what OID you are using, but if this is one of default Certificate OIDs, then it doesn't have a correct format to be used for itself verification (not a generic usecase when a chip needs to verify its own generated signature, but it's possible to organize). For the OPTIGA_CRYPT_OID_DATA parameter usage, the target Certificate shall be in bare DER encoding (no prepended tags in the certificate). If you still want to try this out, you can read the certificate out, remove first bytes and write it back into a Trust Anchor Slot, then use it for the verification.

[DIEGGOMEZ]

Hi @ayushev ,

The OID Certificate in 0xE0EF that i am trying to use to verify, is one generated by Infineon in base to one ours, so i suppose that the format is correct.

So I dont understand 100% what is wrong in the optiga_crypt_rsa_verify parameters.

Regards!

[DIEGGOMEZ]

Ok, another annotation, the optiga_status returned in rsa verify has been 0x000 (Is this that the process is correct?) with two diferent digest and the same signature.

Regards

[DIEGGOMEZ]

Update:

I write this to explain as detailed as possible in order to solve the problem as quickly as possible:

I have copy the example_optiga_crypt_rsa_verify.c, where I:

• Open an application (OK)
• Read the certificate in 0xE0EF (OK)
• I extract the public key (294 bytes)
• Create the struct public_key_from_host_t public_key_details = { rsa_public_key, [Public Key extracted from certificate and store in another array] rsa_public_key_length, [294] (uint8_t)OPTIGA_RSA_KEY_2048_BIT_EXPONENTIAL };
• I call the function: return_status = optiga_crypt_rsa_verify (me, OPTIGA_RSASSA_PKCS1_V15_SHA256, digest, sizeof(digest), signature, sizeof(signature), OPTIGA_CRYPT_HOST_DATA, &public_key_details, 0x0000);

And this return me 0x8005.

Digest is the message in hexadecimal array that i have signed, and signature is the digest that i have signed in an hexadecimal array stored.

Thank your for the help and apologies for the inconvencience @ayushev !

[ayushev]

Hello @DIEGGOMEZ ,

is the data signed (in resulting signature) by the the corresponding to the certificate (0xE0EF) private key using the RSASSA_PKCS1_V15 signature generation scheme? How is the digest calculated? In addition to this, please have a look on the message structure (Page 63) with all annotations. You can enable the logs here

[koblibri]

Hi @DIEGGOMEZ,

an additional pointer might be that the format of your RSA public key is not as the function expects.

Can you check if the format of the RSA public key is as stated in Section 6.2.5 of the Solution Reference Manual?

I don't know what toolset you are using, but most likely your extraction from the certificate returns the "full ASN.1 RSA key structure" consisting of ASN.1 RSA object identifier, modulus and key exponent, but the optiga_crypt_rsa_verify function expects only the modulus and exponent. See the attached file for the difference. pubkey_format.txt

[DIEGGOMEZ]

Hi both @koblibri @ayushev digest is calculated via SHA256 algorithm(Has optiga any function to do this hash256??), and the data is signed with the private key in the certificate and RSASSA_PKCS1_V15 scheme.

I used the public key without headers, but 0x802C error is occuring (Well, it is an advance), any idea??

Thank you, if you think that a call will be quicker, let me know.

Regards.

[koblibri]

Hi @DIEGGOMEZ

there is a function on the Trust M to calculate a SHA256 hash (see here) but lets focus on the RSA issue first.

0x802C is defined as "Signature Verification Failure" (List of Device Error Codes) - are you sure the keys used to generate and verify the signature are matching?

[DIEGGOMEZ]

Perfect @koblibri , Yes, both Public Key and private key used to generate and verify matches. Digest matches too.

[DIEGGOMEZ]

Annotation: Digest is calculated in base to binary file data.

[koblibri]

If you are sure that the digest has been calculated correctly, it is still an option that too few bytes are sent to the Trust M (e.g. by miscalculating array sizes). A 2048bit RSA signature should contain exactly 256 bytes.

Basically: The digest, signature and/or key do not match, otherwise the Trust M would respond with a different error-code. Without knowing which data is sent, it is difficult to find the exact problem.

[DIEGGOMEZ]

@koblibri Signature is 256 bytes correctly, what data do you need to check that everything is correct??

Regards!!

[DIEGGOMEZ]

As extra info:

For example digest is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 and i introduce it as:

uint8_t digest [] = { 0xe3,0xb0,0xc4,0x42,0x98,0xfc,0x1c,0x14,0x9a,0xfb,0xf4,0xc8,0x99,0x6f,0xb9,0x24,0x27,0xae,0x41,0xe4,0x64,0x9b,0x93,0x4c,0xa4,0x95,0x99,0x1b,0x78,0x52,0xb8,0x55 };

[DIEGGOMEZ]

And signature is:

9ad3463e84320b11546673f3001c8d9f971b6e9a5c4c327d7f5acaa41580196ed7b7f9564794c6251d1e9a9b83b26f95f9ce25d0cefe5ab84617f269c74fc407fda63b02ecbe8601de259e1ed804f842f670ed1f4ebe5a2ca5ae3367f80e89050007c6ff80ff2d8d944faa265b969592dd303cb24eee1429a3aa9e21c14ba196ca8733e9fc6d5f4329203ef0c4788fcec500afd68e92ccb9c5c60c12f9df465fc1bd972fd82b601936473e954a3ab30ddcfac3a9608b4a9b865e171c984a2f5bf0698a98b4dd79d5eec80163282132e2cccf8bf4c0ee3a14a0a874d66857e0c6978da15d3bfed8946f263296a63fa04318733c73da724a252b70978e82e7564d

And i introduce it as: uint8_t signature [] = { 0x9a,0xd3,0x46,0x3e,0x84,0x32,0x0b,0x11,0x54,0x66,0x73,0xf3,0x00,0x1c,0x8d,0x9f,0x97,0x1b,0x6e,0x9a,0x5c,0x4c,0x32,0x7d,0x7f,0x5a,0xca,0xa4,0x15,0x80,0x19,0x6e,0xd7,0xb7,0xf9,0x56,0x47,0x94,0xc6,0x25,0x1d,0x1e,0x9a,0x9b,0x83,0xb2,0x6f,0x95,0xf9,0xce,0x25,0xd0,0xce,0xfe,0x5a,0xb8,0x46,0x17,0xf2,0x69,0xc7,0x4f,0xc4,0x07,0xfd,0xa6,0x3b,0x02,0xec,0xbe,0x86,0x01,0xde,0x25,0x9e,0x1e,0xd8,0x04,0xf8,0x42,0xf6,0x70,0xed,0x1f,0x4e,0xbe,0x5a,0x2c,0xa5,0xae,0x33,0x67,0xf8,0x0e,0x89,0x05,0x00,0x07,0xc6,0xff,0x80,0xff,0x2d,0x8d,0x94,0x4f,0xaa,0x26,0x5b,0x96,0x95,0x92,0xdd,0x30,0x3c,0xb2,0x4e,0xee,0x14,0x29,0xa3,0xaa,0x9e,0x21,0xc1,0x4b,0xa1,0x96,0xca,0x87,0x33,0xe9,0xfc,0x6d,0x5f,0x43,0x29,0x20,0x3e,0xf0,0xc4,0x78,0x8f,0xce,0xc5,0x00,0xaf,0xd6,0x8e,0x92,0xcc,0xb9,0xc5,0xc6,0x0c,0x12,0xf9,0xdf,0x46,0x5f,0xc1,0xbd,0x97,0x2f,0xd8,0x2b,0x60,0x19,0x36,0x47,0x3e,0x95,0x4a,0x3a,0xb3,0x0d,0xdc,0xfa,0xc3,0xa9,0x60,0x8b,0x4a,0x9b,0x86,0x5e,0x17,0x1c,0x98,0x4a,0x2f,0x5b,0xf0,0x69,0x8a,0x98,0xb4,0xdd,0x79,0xd5,0xee,0xc8,0x01,0x63,0x28,0x21,0x32,0xe2,0xcc,0xcf,0x8b,0xf4,0xc0,0xee,0x3a,0x14,0xa0,0xa8,0x74,0xd6,0x68,0x57,0xe0,0xc6,0x97,0x8d,0xa1,0x5d,0x3b,0xfe,0xd8,0x94,0x6f,0x26,0x32,0x96,0xa6,0x3f,0xa0,0x43,0x18,0x73,0x3c,0x73,0xda,0x72,0x4a,0x25,0x2b,0x70,0x97,0x8e,0x82,0xe7,0x56,0x4d

    };

[koblibri]

In theory, this looks good. If you can additionally provide me the Public Key (DER or PEM) , I can try to verify the signature on my end.

[DIEGGOMEZ]

Ok, i have finally verified it, digest data was the problem, my colleague give me an incorrect one.

Apologies for the inconveniences.

Regards.

[koblibri]

Glad that worked out. No worries!