[参考译文] CCS/CC3220SF-LAUNCHXL：ECC 密钥

尊敬的 Kobi：

感谢你的答复。 你过得怎么样？

在这里、我读取了公钥、但这是未压缩的、且长度为130字节。 如何压缩公钥 ？

正如我提到的、我必须使用 HTTPS 将签名数据发送到云、此发送过程很好、但如何使用 index0公钥将数据单独发送到云。 我必须使用哪种方法在云端进行验证。

尊敬的 kobi：

我没有寻找证书签名方法、因为我 没有找到使用该 CSR 证书进行签名和验证的任何示例。

因此、我更改这里的逻辑。 我在这里解释了该方法  

1.使用 key index0读取公钥

2.将此公钥以未压缩的形式发送到云。

使用有效载荷并向其发送签名数据(签名数据由 TI 以十六进制格式生成)

4.云端，使用 nodjs 脚本，使用共享设备公钥(步骤2)验证签名数据

这是我现在执行的步骤、但如果我在器件中执行 Sing 和验证、则没关系、但当我使用 node.js 脚本执行云端操作时、由于签名数据长度、我无法进行验证。  

此处、我的签名长度大约为140字节、但预期仅为64字节。 我不知道这里的问题是什么。  

CSR 需要由外部公司(证书颁发机构)签名。 检查中的自述文件 \tools\cc32xx_tools\certificate-catalog\、获取支持的根 CA 的完整列表。 此部分不能通过示例引入、因为它取决于所选的证书颁发机构(并且有成本)。 同样、如果您控制云端(即验证器)、则可以使用您自己的证书从 CSR 生成证书。

签名应该是可以的。 ii 认为(二进制)大小为~70B 而不是140B (我想您是指十六进制表示法)。 这已经多次验证。 确保正确使用脚本。

BR、

Kobi

尊敬的先生：

感谢你的答复。

在这里、正如您所说的、签名将具有 ANSI1标头、因此与标头一起、它将成为周围的140字节。 如何删除 ANSI 标题。 ？

140B 很奇怪。 它应该是一半。

当 sl_NetUtilCmd 返回时、签名长度输出参数是这样吗？

尊敬的先生：

查看签名输出  

configVal = sing_buffer_using_index (0、(uint8_t*)"QU1BTktFVEFO"、strlen ((const char*)"QU1BTktFVEFO")、(uint8_t*) signatureBuffer、(uint16_t*)&Len)；

如果(RetVal < 0)
｛
ASSERT_ON_ERROR (RetVal、"sing_buffer_using_index（) failed")；
｝
其他
｛

WMDebugInfo (NO_CRLF、"\r\n\r\n")；

WMDebugInfo (no_CRLF、"签名结果：")；


memset ((uint8_t*)&rawValueBuffer、0x00、sizeof (rawValueBuffer))；

对于(i = 0；i < configLen；i++)
｛
sprintf (&rawValueBuffer[i]、"%x"、signatureBuffer[i])；

WMDebugInfo (NO_CRLF、"%02x"、signatureBuffer[i])；
｝

WMDebugInfo (NO_CRLF、"\r\n\r\n")；

WMDebugInfo (NO_CRLF、"签名结果：%s"、rawValueBuffer)；

WMDebugInfo (NO_CRLF、"\r\n\r\n")；
｝

这是我的签名，我将打印为%02x 格式。 请看一下

[3045022100ad534a20925997179e84894bc69e1c379f02553adc3523c2c5f72588828dbe502203f85c3e0bdd3745adc486a679a1a42eff5ef259f8e03144d0334bf03332] 


这是我的 sprintf 格式字符串格式、只需查看一次即可。 

[34220a54295919884c9139ddac532537582de2238ceb534ac8a7aa2f5f35fe31419b4d32] 

正如我看到的、该签名采用 DER 格式

尊敬的 Kobi：

感谢你的答复。

在这里、我解码了签名数据的 DER 格式。 这里我对签名数据输出有疑问。

首先是签名组件 R 和 S 的查找代码

= 0x21)
｛
offset += 1；//如果找到零

//检查第4个索引包含0x00

if (hex_str[offset]== 0x00)
｛
offset += 1；//如果

(i =0)
memcpy (initreger_rbuf、&memstr[offset]、32)、则从下一个字节开始复制

(initrgr_buff、initrgr[offset]、 32)；
｝

｝否则
｛
offset += 1；//如果

(i =0)
memcpy (initreger_rbuf、&hex_str[offset]、32)；
否则
memcpy (initreger_sbuf、&hex_str[offset]、 32)；
｝

offset += 32；

对于(j = 0；j < 32；j++)
｛
if (i = 0)
｛
WMDebugInfo (NO_CRLF、"%02x"、initreger_rbuf[j])；

｝否则
｛
WMDebugInfo (NO_CRLF、"%02x"、"%02x"、initreger_rf[j])；｝initr_r_debugInfo



(n_rf)



返回偏移量；
｝

/> 

根据谷歌搜索器、数据格式将具有序列号和长度、正如我在函数中作为注释解释的那样、但现在正在添加一些额外的字节。 请向下看。

[304502201de3662e573be7aaf850a467a15b8862090e8d5e6df93652239a79e2ebf022100d775faccf0d1b09acff528aab3839620dfcc67880d55e7d693d9] 

上面的签名、我得到了一些额外的字节作为0x00。 根据格式、它应该是签名末尾的 HT 字符(最后一个字节)、但我将从 R 和 S 开始  

[3046022100a567c52ce770bd03db6e85eb1472f21990492c7041201237ccd96d14cc28ed022100c84352d29c0ea582dcdb4278714c9b3457bfaf0f2e76f15163e76327d480] 

我不确定您的担忧是什么。 两个签名似乎都满足 DER 格式定义。 您提到的"00"是签名的一部分。 。

问题出在哪里？

BR、

Kobi

尊敬的先生。

如果不删除0x00、则无法使用脚本验证签名、因为包含0x00将变为65字节、但预期为64字节。 那么、为什么这个0x00字节正在按照 格式添加最后一个字节的 R 和 S 组件 staring。？？。

如果我要从签名中删除此0x00字节、则会导致任何问题。 ？

您可以尝试(删除前导00)。

我不确定。

大多数工具/TLS 堆栈都可以获取 DER 格式、我以前没有遇到过这样的问题。

我对此进行了快速搜索、并找到了以下内容：  

https://stackoverflow.com/questions/34063694/fixed-length-64-bytes-ec-p-256-signature-with-jce

BR、

Kobi