嵌入式固件的代码签名:加密固件时,CRC是否足够?

时间:2019-06-13 10:21:45

标签: encryption embedded code-signing firmware

我正在为嵌入式系统(微控制器)编写固件。固件可以由引导加载程序(也由我编写)进行更新。

现在,需要采取措施来防止固件被篡改,因此,只有在具有某种有效签名的情况下,系统才必须执行已下载的固件。

固件文件已加密。它由引导加载程序(在微控制器中)解密,然后编程到闪存中。

由于固件已加密,因此我认为对闪存内容进行简单的CRC检查就足以证明固件的有效性。但是我不是网络安全专家,所以...我需要更多吗?

我认为加密足够强大,无法读取闪存。

1 个答案:

答案 0 :(得分:3)

  

由于固件已加密,因此我认为是简单的CRC检查   闪存上的内容应足以证明固件   有效性。但是我不是网络安全专家,所以...我还需要更多吗?

如果您选择了一种声音加密方法,并正确地保护了加密密钥,并且还保证了固件在传输后无法读出,并且引导加载程序在无法成功解密的情况下拒绝了固件,那么您已经保证固件的有效性。除非违反上述假设之一,否则只有拥有用于加密固件的密钥的人才可以生产将由引导加载程序接受的固件。

正如其他人指出的那样,CRC不能用于防止故意修改,因为您可以将垃圾数据附加到任何文件中以产生所需的CRC。但是,我仍然建议至少在固件升级过程的两个阶段使用CRC:

  • 在传输过程中最好对每个传输的数据包进行CRC加密,因此您可以重新传输单个数据包而无需重新启动整个过程(即对256字节的加密数据块进行CRC校验)
  • 在固件(减去引导加载程序)所占用的闪存区域中,第二个是针对成功解密后由引导加载程序生成的解密固件的CRC(或静态固定CRC,某些µC-IDE支持此内置功能) ,以确保没有发生flash-write-errors。通常的做法是将此CRC值保护到不属于CRC的某个闪存区域中,以便引导加载程序可以在每次设备复位时验证应用程序的完整性。