Closed ayushev closed 3 years ago
you can find the answer here on what to prepend to the signature to make it accepted by openssl
Find the answer where? I think you forgot to link something or add the relevant information? Thanks in advance
tir. 12. okt. 2021 kl. 13:43 skrev Artem Yushev @.***>:
you can find the answer here on what to prepend to the signature to make it accepted by openssl
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Infineon/optiga-trust-m/issues/73#issuecomment-940931692, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGJWKX75NERCQDMWQGWBE6LUGQNPZANCNFSM5F2LT3OA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Find the answer where? I think you forgot to link something or add the relevant information? Thanks in advance
Thanks for pointing. Fixed now.
I see you say that I should prepend the header to the SIGNATURE in your answer, but in the original post you answered you told the guy to prepend it to his public key to make it accepted by third party tools. Do I need to prepend the header to BOTH public key and signature or ONLY signature if I want to make it compatible with the openssl-dgst command?
As a supplement. This is my public key which is being used in the optiga_sign() process: 0x3 0x42 0x0 0x4 0x79 0x91 0x93 0xe8 0xe4 0x7a 0x1d 0xd8 0x57 0xee 0xe7 0x43 0x5d 0x2b 0xcf 0x2f 0xc4 0x89 0xf1 0x31 0x3c 0x7e 0xa8 0x27 0x7 0xb4 0x1e 0xba 0xf1 0x8c 0x6 0xb6 0x29 0x2 0x33 0x2 0x45 0xb4 0xef 0x52 0x84 0x2 0x75 0x94 0xcb 0xb8 0xe 0xd7 0x5c 0x27 0x76 0xbd 0xe1 0x6f 0xc2 0x6f 0x87 0x6a 0x22 0xcb 0xed 0xc6 0x9a 0xbf
And this is the signature generated by optiga_sign() which is used with success in the optiga_verify() function 0x2 0x21 0x0 0x99 0x2 0xfa 0x6c 0x73 0x57 0xe6 0xd3 0x84 0x26 0x3 0x82 0x75 0xdc 0x69 0x70 0x11 0x89 0x58 0x38 0x10 0x72 0xa4 0xf8 0x9a 0xd8 0xd4 0x25 0x76 0x12 0x52 0x55 0x2 0x21 0x0 0xf0 0xe2 0x38 0xec 0x66 0xb3 0x7c 0xbe 0x81 0x66 0xc7 0xe7 0xda 0xe3 0x62 0xc3 0xbb 0x10 0x4a 0x46 0x1b 0x4d 0xa9 0x32 0x58 0xaa 0x90 0xe4 0x3c 0x9b 0x1c 0xde
The digest is generated using the example function optiga_crypt_hash_data() and looks like this: 0xd3 0xcb 0x71 0x59 0x1a 0xf 0x36 0xf7 0x3d 0x26 0x2a 0x97 0xe6 0x47 0x35 0xba 0x88 0x1b 0xc5 0xe5 0x22 0xba 0x45 0x55 0x4c 0xd2 0xfc 0xb 0xae 0xa1 0xf5 0xb8
Indeed, unfortunatelz I can|t find right now the exact issue number who asked a similar thing, so I'll write it here once again.
The format of data generated by chip are denoted in Solution Reference manual and here. This is a Raw DER encoded signature.
In external crypto libraries rely on various formats, in general it is enough just to prepend certain bytes to the signature generated by the chip to let OpenSSL to verify it. YOu can have a look here as well
A format of the signature generate by Trust M which will be accepted by OpenSSL is following:
30
44
02 20 65 27 c2 a7 8c 77 5d 4b 26 03 28 9c 8b 75 a1 5c b4 aa 77 14 c9 8f 37 2c bb 92 02 11 49 2a a1 a6
02 20 65 2e 14 d0 32 f9 f2 6b 76 24 09 8a 5d b5 91 fb 0f 8b 35 ec c5 43 de 84 81 46 90 bf 57 f9 41 73
Two last lines is what you get from the chip
So just add two bytes beforehand 0x30 (ASN.1 Sequence Tag) and 0x44 (Length)
does it work for you? can we close the ticket?
YEs, it works great now. Thanks for the help once again!
man. 18. okt. 2021 kl. 22:19 skrev Artem Yushev @.***>:
does it work for you? can we close the ticket?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Infineon/optiga-trust-m/issues/73#issuecomment-946133582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGJWKX54OIOMGQIGBV5ICQTUHR6ODANCNFSM5F2LT3OA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Thanks, I got what you answered cleared up and now I got another question. I have gotten both storage of keys, signing of digest, and verification of it to work great using the optiga chip. I however do not wanna rely on the optiga chip for verification of digest. I have therefore tried the inbuilt function of openssl dgst, but I cant get it to work. Do you have any clue what kind of conversion you have to do(if any) of public key, signature and digest from the pure hex format they are given in using the optiga sign function and generate_key function. That is to get them to work with the openssl dgst command. A programmatic approach not relying on the optiga chip is also very welcome if you have any. THe way I understand it the public key is encoded in ASN.1 format, and the signature is encoded in just pure HEX-format?
Originally posted by @KjetilSekse in https://github.com/Infineon/optiga-trust-m/issues/70#issuecomment-940740504