Kinetis 加密等级分析（转）

好好先森

原作者：FSL_FAE_ConstYu      出处： https://www.eefocus.com/constyu/blog

Kinetis的加密锁定问题在论坛和客户那里经常被问到，而Kinetis的加密章节零散分布在Chip Configuration/Security/Flash章节，此处做一个简单的总结。提到Kinetis的加密其实本质上来说都是围绕FTFx_SEC和FTFx_FPROT这两个寄存器的：





粗略来说，Kinetis的加密主要分为以下几个等级：
1)  SEC加密状态：这种状态会禁止所有的外部调试接口（JTAG/SWD/EZPORT）对芯片内部Flash的访问，此时JLINK/BDM/Cyclone就无法再读写芯片内部程序了，只能使用Mass erase全擦命令擦除掉芯片内部所有的程序，解除Flash配置字节0x40C地址中FSEC位配置，从而实现了知识产权的保护。但是对于CPU本身可以正常读写操作Flash，这种加密方式是大部分的加密应用中最常采用的方式。


此处补充一些SEC加密的原理和过程：如下图所示，Kinetis在0x400-0x40C地址区间 有一个独立的16byte Flash 配置区域用来存储Flash加密和MCU启动的一些配置信息。在芯片复位完成前位于0x40C的FSEC字节会被自动加载Kinetis的加密寄存器FTFL_FSEC寄存器中，如果FSEC字节不等于0b10，芯片就会被加密。这就意味着两个方面：首先，即便在芯片运行过程中修改Flash 配置区域的值，如果没有经过复位，也不会起作用。其次，即便通过其他方式（Backdoor key）的方式在MCU工作过程中解除了Flash的加密，如果Flash配置字节0x40C地址没被修改，芯片复位后，Flash依然处于加密状态。


2) SEC加密+MEEN Disable状态：这种状态是在状态1的基础上，去使能了芯片的mass erase 功能，此时外部的调试接口就再也通过无法执行mass erase 命令解除芯片的加密状态。所以使用这种方式加密需要特别注意，容易导致芯片代码再也无法重新编程或修改。
3) SEC加密+KEYEN disable状态: 前面的两种状态都是芯片处于加密状态，并且除了Flash内容全擦外，永远无法解除SEC状态。那有没有一种办法可以不全部擦除Flash的内容，解除Flash的锁定状态呢？答案就是Backdoor 后门验证，当然前提是用户使能了FSEC的KEYEN位，并且设置了正确的backdoor key。 既然是后门，那就需要用户添加一段程序去接收外部的验证KEY，例如一段串口程序等。当Backdoor key验证通过后，会临时解除MCU的加密状态，在芯片重新复位后，如果0X40C地址的FSEC位没做修改，芯片会重新恢复到加密状态。 相反，如果Disable了KEYEN，只能通过全擦Flash才能实现解除加密。
4)  SEC加密+FSLACC disable状态：这种状态是和Freescale 工厂访问相关的一种加密状态。前面提到，以上的三种情况中MCU加密状态第三方无法直接读取MCU内部的Flash 内容，然而考虑到客户的失效分析，芯片测试工厂留了一个途径，依然可以读取到芯片内部Flash的内容（这点有点类似超级用户的概念）。芯片用户可以Disable FSLACC来防止飞思卡尔原厂读到芯片内部Flash内容，当然，这样会对后续可能的芯片失效分析带来影响。
5)  FPROT 状态：上面四种状态主要是限制恶意用户通过仿真器等工具，通过JTAG/SWD/BDM等调试接口访问到芯片内部的Flash内容，而MCU本身则不受以上设置的限制。在有些对安全性要求比较高的应用中，为了防止程序跑飞，MCU对内部Flash中一些配置参数的误操作等情况，Kinetis还提供了另外一种机制----Flash保护，以K60为例，Kinetis把内部的Flash等分成32份，用户可以选择对其中的某一些区域进行选择性保护，这样MCU只有读权限，可以一定程度上减少误操作。



至于FPORT保护的过程，类似于SEC加密的过程，会在芯片复位完成前会把16byte Flash 配置区域的配置信息加载Kinetis的加密寄存器FTFL_FPROTn中。但是和FTFL_FSEC的区别是，FTFL_FSEC寄存器时只读的，FTFL_FPROTn寄存器是可读可写的，在使用过程中可以更改其内部的配置。
尽管该FTFL_FPROTn寄存器是可读可写，但是使用过程中还是有所限制，和NVM的模式有一定关系。如在NVM 的Normal mode，当前稳保护的区域可以被设置成Protected，而Protected区域却不能修改为unprotected。而在NVM Special mode下，则没有以上限制。


总的来说，FSEC的设置主要是防止恶意者通过JLINK/BDM/Cyclone等仿真调试工具通过芯片的JTAG/SWD/EZPORT等接口对芯片内部Flash的读写操作，MCU依然可以正常操作读写MCU内部Flash。FPORT的主要目的是防止MCU对内部Flash的误操作。根据不同的组合，罗列如下表：


6)      UID加密：以上提到的5种不同加密方式都是通过配置芯片Security特定的的Flash配置字节或者寄存器实现的，我们可以称其为硬件机制，那能否通过软件机制呢？答案当然是肯定的，目前比较常用的方法就是利用Kinetis的UID（Unique Identification）特性。
所谓UID，可以理解成每个芯片的“身份证”，对于Kinetis K系列来说有128bit的UID和KL系列有80bit的UID，从而保证每个MCU芯片都有独立的唯一的编号，下图是K10的UID相关的寄存器。









那UID实现加密的机制是什么呢？常规的思路是：把序列号读出来，写进程序里，再使用程序来校验。但是这样的话每个Hex文件都不一样，无疑会给工程师带来无穷无尽的代码调试工作量，而且会生成N个软件版本，对于大批量生产而言，非常不利于生产及后面的维护。
那具体实现机制是什么呢？答案是：编程烧录器（需要相应的的烧录器支持这个功能）。此处为方便理解，如下图，此处引用网上的一个流程图解释整个过程。其基本思路是：使用上位机软件通过编程器读取芯片的 UID，经加密算法运算后生成密钥， 下载程序的同时向MCU 的Flash 中某个地址写入密钥。MCU 上电后，首先读取芯片的UID， 再通过与上位机相同的加密算法运算后计算出密钥，并与之前写入Flash 中的密钥比较，若相同则继续执行用户程序，否则跳入死循环或执行程序开发者指定的代码。


以上介绍的6种不同加密方式，用户可以针对自己项目的需要选择使用，而且还可以组合起来使用，从而实现最大程度的保护用户的代码安全的需要。对于一些更高阶的Kinetis加密，如加密Flexbus 总线，加密Debug接口（禁止Mass Erase命令）等加密设置，但由于这些方法不太常用，此处不再深入阐述。

我知道答案 目前已有2人回答

阅读全文

nothingness

谢谢分享

451506709

分析得不错，赞