Encryption 单片机PIC控制器的证书签名验证

我试图在微芯片pic控制器上实现证书签名验证（证书是使用OpenSSL生成和签名的）。Microchip PIC控制器不支持OpenSSL库，但它具有加密/解密功能。我成功地在PIC控制器和web服务器之间建立了SSL连接。我的下一步是在PIC控制器上设置签名验证

阅读PKCS#1 V2.1 RSA加密标准（）后 我意识到加密本质上与签名验证相同，而解密与签名相同。更具体地说，加密和验证都使用公钥和以下公式：

m=s^e模n

其中s是签名或消息，e是公共指数，n是模，m是加密消息或解码签名。因此，我尝试使用提供的加密算法来执行签名验证

为了验证证书，我生成了证书的SHA1散列；使用CA的公钥和加密算法解码签名。如果删除已解码签名中的填充，则结果哈希值应等于证书的SHA1哈希值

但是，我无法使这两个散列值相等。我尝试使用OpenSSL命令行验证我的假设和PIC控制器结果

这是我从OpenSSL命令行和PIC控制器获得的哈希值

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

这是我从使用OpenSSL的签名验证中得到的。在删除“ff”填充之后，我将以asn1格式的证书哈希结束

openssl rsautl-verify-in signature.txt-inkey pubkey.pem-pubin -原始数据转储
00 01 ff ff ff ff ff ff 00 30 21 30
09 06 05 2b 0e 03 02 1a-05 00 04 14db e8 c6 cb
78 19 3c 0f fd 96 1c 4f ed bd b2 34 45 60 bf 65

然而，这是我从PIC控制器得到的，它与上面的有很大不同

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

这是我的签名

7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4
0f66 db3a a3c1 a254 5be5 11d3 a691 63ef
0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6

这是我的公钥（我使用一个非常小的密钥只是为了测试，一旦一切正常，它会变大）

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
指数是01 00 01

---

我想知道我的假设是否错误，我不能使用加密算法来解码签名？还是我做错了什么

结果证明我上面描述的方法是正确的。我能够通过对证书进行哈希运算并使用加密取消签名来获得匹配结果

---

导致我之前尝试失败的问题是微芯片Pic控制器使用的耐久性。他们使用小的尾数而不是大尾数。我没有注意指数的端点，因为01 00 01在两种格式中都是相同的。然而我错了，结果证明Microchip将4字节的值作为指数（RSA标准？？）。因此，它将00垫在前面，从而产生0001。因此，endianness现在很重要，因为00 01 00 01与01 00 01 00不同。而01 00 01 00是Microchip Pic使用的小端格式。

结果证明我上面描述的方法是正确的。我能够通过对证书进行哈希运算并使用加密取消签名来获得匹配结果

导致我之前尝试失败的问题是微芯片Pic控制器使用的耐久性。他们使用小的尾数而不是大尾数。我没有注意指数的端点，因为01 00 01在两种格式中都是相同的。然而我错了，结果证明Microchip将4字节的值作为指数（RSA标准？？）。因此，它将00垫在前面，从而产生0001。因此，endianness现在很重要，因为00 01 00 01与01 00 01 00不同。而01 00是Microchip Pic使用的小端格式