Re: Problem with signature verification on microchip embedded controller
Yes, you can verify 'by hand' by doing the raw public key operation, stripping off the padding and OID (what you call the asn1 formatting), and then comparing the hashes. When you say this is what I got from the PIC controller, I assume you mean the result of applying the public key to the signature. Since you don't see the obvious 00 01 ff ... padding, there are three possibilities: - you're using the wrong public key, or it got altered, or it's in the wrong format for the crypto library - you're using the wrong signature, or it got altered - the raw public key operation isn't working correctly, or you called it incorrectly It's not a hashing issue, since you don't see the padding. From: TSCOconan chu...@tsco.ca To: openssl-users@openssl.org, Date: 10/18/2011 03:03 PM Subject: Problem with signature verification on microchip embedded controller Sent by: owner-openssl-us...@openssl.org Hi, I'm trying to implement certificate signature verification (certificates are generated and signed using OpenSSL) on a Microchip pic controller. The Microchip PIC controller doesn't support OpenSSL libraries, but it does have an encryption/decryption function. I was successful in getting a SSL connection between PIC controller and a web server. My next step is to setup signature verification on the PIC controller. After reading PKCS#1 V2.1 RSA Cryptography Standard (http://www.rsa.com/rsalabs/node.asp?id=2125) I realized that encryption is essentially the same as signature verification and decryption is the same as signing. More specifically both encryption and verification uses the public key and the following formula: m = s^e mod n. Where s is the signature or the message, e is the public exponent, n is the modulus and m is the encrypted message or decoded signature. Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. In order to verify the certificate, I generate the SHA1 hash of the certificate; Decode signature using CA's public key and encryption algorithm. Remove the padding from the decoded signature, the result hash should be equal to the SHA1 hash of the certificate. However, I cannot get the two hash values to be equal. I tried to verify my assumption and PIC controller results using OpenSSL command line. openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem -pubin db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65 this matches the hash value I'm getting from PIC controller openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb This is my signature 7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4 0f66 db3a a3c1 a254 5be5 11d3 a691 63ef 0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6 This is my public key (I'm using a very small key just for testing, will make it larger once everything works) 96 FE CB 59 37 AE 8C 9C 6C 7A 01 50 0F D6 4F B4 E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1 B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B Exponent is 01 00 01 I'm wondering are my assumptions wrong that I cannot use encryption algorithm for decoding signature? or I'm doing something else wrong. Thank you for any help.
Problem with signature verification on microchip embedded controller
Hi, I'm trying to implement certificate signature verification (certificates are generated and signed using OpenSSL) on a Microchip pic controller. The Microchip PIC controller doesn't support OpenSSL libraries, but it does have an encryption/decryption function. I was successful in getting a SSL connection between PIC controller and a web server. My next step is to setup signature verification on the PIC controller. After reading PKCS#1 V2.1 RSA Cryptography Standard (http://www.rsa.com/rsalabs/node.asp?id=2125) I realized that encryption is essentially the same as signature verification and decryption is the same as signing. More specifically both encryption and verification uses the public key and the following formula: m = s^e mod n. Where s is the signature or the message, e is the public exponent, n is the modulus and m is the encrypted message or decoded signature. Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. In order to verify the certificate, I generate the SHA1 hash of the certificate; Decode signature using CA's public key and encryption algorithm. Remove the padding from the decoded signature, the result hash should be equal to the SHA1 hash of the certificate. However, I cannot get the two hash values to be equal. I tried to verify my assumption and PIC controller results using OpenSSL command line. openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem -pubin db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65 this matches the hash value I'm getting from PIC controller openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb This is my signature 7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4 0f66 db3a a3c1 a254 5be5 11d3 a691 63ef 0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6 This is my public key (I'm using a very small key just for testing, will make it larger once everything works) 96 FE CB 59 37 AE 8C 9C 6C 7A 01 50 0F D6 4F B4 E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1 B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B Exponent is 01 00 01 I'm wondering are my assumptions wrong that I cannot use encryption algorithm for decoding signature? or I'm doing something else wrong. Thank you for any help. Conan -- View this message in context: http://old.nabble.com/Problem-with-signature-verification-on-microchip-embedded-controller-tp32677043p32677043.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Problem with signature verification on microchip embedded controller
From: owner-openssl-us...@openssl.org On Behalf Of TSCOconan Sent: Tuesday, 18 October, 2011 14:57 I'm trying to implement certificate signature verification snip on a Microchip pic controller. snip After reading PKCS#1 V2.1 snip I realized that encryption is essentially the same as signature verification and decryption is the same as signing. snip Therefore, I'm trying to use the encryption algorithm provided to perform signature verification. Raw RSA encrypt/decrypt are the same as verify/sign, but the standard paddings are different. (PKCS#1 type2 padding for encrypt is similar to type1 padding for sign but not identical, and it proved vulnerable in application so it was mostly superseded by OAEP which is very different. And encrypt is pad-then-modexp-pub while verify is modexp-pub-then-unpad.) In order to verify the certificate, snip usual openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin -raw -hexdump 00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30 09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb 78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65 I believe this is what I should get after decoding the signature. After removing ff paddings I'll end up with asn1 format of the certificate hash. Yes. (To be exact, removing type 01, at least 8 IIRC FF's, and delimiter 00; those are all part of the padding.) However this is what I got from the PIC controller which is much different 8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c 9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43 b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb I'm not sure what that encryption primitive is doing. Does it take any kind of setting to do padding or not? If it is doing any real padding it should reject your call because no padding scheme can encrypt a 384-bit (or even 376-bit) value with a 384-bit key. Maybe it is failing to return the error or you are failing to recognize it. If it is supposed to be doing unpadded something is wrong. snip data This is my public key (I'm using a very small key just for testing, will make it larger once everything works) I suggest you use a key large enough to give OAEP some elbow room, at least 512. Then try encrypting several known short values like 01; 01 02; 01 02 03; etc. and see if rsautl -decrypt -raw or -oaep gives them back. (Or maybe -pkcs, but as noted that is rare these days.) Increase up to the length you need (about 48 bytes). If you can get raw-encrypt to match, you can use it for the modexp-pub part of verify. (And the rest is, as you correctly described, relatively simple.) __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
