工具与软件:
你(们)好
到目前为止、我在 e2e.ti.com/.../processor-sdk-am64x-using-hsm-to-build-opt-keywriter-application 上的问题没有得到令人满意的答案。 但是线程被简单地锁定了。 可能这是由系统自动完成的。 即使回复表明 TI 不愿意再进行任何调查、我们也会非常感谢您的回复。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
工具与软件:
你(们)好
到目前为止、我在 e2e.ti.com/.../processor-sdk-am64x-using-hsm-to-build-opt-keywriter-application 上的问题没有得到令人满意的答案。 但是线程被简单地锁定了。 可能这是由系统自动完成的。 即使回复表明 TI 不愿意再进行任何调查、我们也会非常感谢您的回复。
您好、Walter、
我们得出了与您相同的结论。 将 SMEK/BMEK 始终保存在 HSM 是不可行的、因为在换行操作期间附加32字节的随机数据不是标准 HSM 通常可以提供的。
据我了解、这32个字节用于验证解密是否成功。 解密后、最后32个字节与嵌入在 rs 证书扩展值中的32个字节进行比较。
直接将 SMEK/BMEK 包装到 TIFIEK (公共)可以使密钥不可导出。 但是、我担心这是一个重大变更、而 TI 不愿意实施。
此致
Raimar
大家好、Raimer、Walter、
我一直听从 Walter 的建议、修补 OTP_Keywriter 脚本以成功访问 HSM、但我们只将 SMPK 和 BMPK 密钥存储在 HSM 中。
因为我们不是"主动"使用 SMEK 或 BMEK 在我们的使用,我承认,我没有担心这些特定的钥匙。 如果我们对代码加密、那会有所不同-但今天的默认 Yocto 构建不支持这种加密、这使得选择有些不切实际
我还设法通过我们的 Yocto 编译来修补 binman 以支持 HSM 访问、但我发现 openssl -> PKCS11 -> HSM 器件路径在运行时非常错误;我"经常"遇到在 HSM 中访问密钥的首次故障、 重复编译只是正常工作(没有更改、只是重新编译)。
此致、
David