我需要防止我们产品的用户下载与他们尝试下载的硬件版本不兼容的固件。我将描述现在存在的东西以及我正在寻找的东西。
我们有一个字母数字硬件部件号和修订版存储在EEPROM中，只能在工厂编程。当客户尝试下载固件文件时，他必须输入随固件版本一起分发的密码。现有固件需要能够使用此密码来验证新固件是否与当前硬件版本兼容。请记住，多个硬件版本可能与单个已发布的固件版本兼容。
是否存在某种形式的公钥加密，可用于验证固件构建过程中生成的密钥的多个硬件版本号？硬件版本号将作为私钥，而客户输入的解锁下载机制的密码将是公钥。
嵌入式固件是用C语言编写的，如果加密算法相同则会很好。它可以是C ++，只要它有一个可以从C函数调用的接口。
野外有一些硬件修订，但我们现在可以忽略它们。假设将发布包含此功能的全新产品，因此它将是版本0.
密码将从客户端的计算机传输到嵌入式硬件，无需任何修改。因此，解密和密码匹配需要在嵌入式固件中进行，然后嵌入式固件将成功/失败报告给客户端。这样做的原因是它可能并不总是用于下载固件的笔记本电脑。它更可能是一个手持式下载工具，因此执行自定义软件的选项有限。
答案 0 :(得分：6)
忘记密码。
最简单的方法是在固件文件中，在已知位置包含兼容硬件ID列表。这可以存储为长度前缀数组。当要将新固件加载到设备中时，设备会在列表中查找自己的硬件ID，如果固件不存在则拒绝该固件。
这样的系统功能强大，易于理解且易于调试。如果空间是一个问题，那么您可以将列表存储为一个位集，每个硬件版本分配一点。
如果您希望防止主动篡改，您可以使用普通公钥签名算法（如DSA或RSA）进一步签署整个固件文件，包括兼容硬件ID列表。
答案 1 :(得分：1)
所以我们假设这是一个全新的设计：
我并不是真正想要/需要多少安全性以及设备的处理能力......
我会让固件包由两部分组成 - 标题和“真实的东西”。 两者都应以不同方式加密，然后单独签名加一起（这是公钥加密部分）。
首先检查外签名
然后检查标题的签名（必须根据标题，标题长度加密码计算）
标头使用您分发的密码进行加密，并包含兼容硬件版本的哈希列表（这些哈希值是根据硬件版本+密码计算得出的）。 设备解密标头，相应地从EEPROM中散列自己的修订版（再次修订版+密码）并尝试在列表中找到匹配项。 如果找到匹配，则它会在标题中获取列表的哈希值。
使用列表的哈希检查“真实的东西”的签名（根据加密内容加上长度加上密码加上列表的哈希计算）
如果签名有效，则继续解密“真实的东西”（密钥将是密码+列表的哈希）
对于您创建证书的签名部分，使用您的根证书签署该证书...派生的证书将嵌入到设备中...因此您使用该证书的私钥创建签名并检查它们具有公钥的设备。
以上并非100％安全，但提供了几个方面：
如果这是两次计算等，你可以随时简化方案......至少我会保留外部签名和密码......
编辑 - 经过一番讨论（见评论）：
创建“密码”的基本算法我建议由两部分组成 - 散列算法和加密算法：
散列算法
应对相应的固件进行哈希处理（“好”算法为SHA-512，SHA-384，SHA-256，MD5 - “非常弱”算法为CRC32）
加密算法
密码将使用非对称算法（如RSA，EC等）或对称算法加密（“强”算法是AES，Blowfisch等 - “弱”的是例如DES - “非常弱”是例如XOR）
该计划包括以下步骤：
使用上述任何散列算法散列固件
构建一个由部件号/修订号+固件哈希
使用上述任何加密算法加密字符串（不对称意味着您使用私钥，symetric意味着您使用相同的密钥进行加密/解密）
设备需要包含一个密钥（如果使用非对称加密，则为公钥，或者是对称加密时的密钥）和部件号/修订号。
根据密码检查固件意味着解密密码，散列固件并比较部件号/修订号和固件哈希......
安全方面与处理要求：
一些相关链接：