MCU的调试接口——怎么堵住这个后门？

安全调试的前世今生

对于MCU的开发工程师来说，MCU的调试接口是必不可少的开发利器。透过调试接口，我们可以监视MCU的运行状态，查看或修改寄存器的数值，观察内存中的数据变化，通过IDE、调试器等开发工具配合，方便地排查各种棘手的问题。

我们需要了解的一切信息，调试接口都知无不言，言无不尽。

那么问题来了，在产品出厂后，黑客、攻击者就可以利用强大的调试接口对设备进行各种攻击，窃取产品中的敏感信息；黑色产业链也可以通过调试接口，轻而易举地读取出设备的固件，从而生产制造廉价的“破解版”。

正是由于调试接口功能强大，这个开发过程中的利器，也给产品带来了安全的漏洞和知识产权泄露的隐患。

针对这个问题，很多高附加值或安全敏感的产品，会选择在生产过程的最后一步，通过修改OTP Fuse等方式，将调试接口永久地禁掉。产品出厂后，调试接口已被封死，简单粗暴地解决调试接口带来的风险。

但是，产品的售后、维护往往不是一帆风顺的。产品在客户现场，也许会出现各种各样奇奇怪怪的问题。此时，由于调试接口被封掉，留给我们的调试排查手段捉襟见肘，产品出现问题后，难以定位更难以解决。

有没有一种方法，只能让开发者合法地调试芯片，而不会被攻击者利用呢？

Secure Debug安全调试

传统的手段，是将调试接口永远的封死，那么Secure Debug就像是给调试接口加了一把坚固的锁，只有能打开这把锁的人才能使用调试功能。

毫无疑问，“锁”比“封”要更加灵活。那么，我们应该选择使用一把什么样的锁呢？

密码锁

这是一种简单有效的方案，适用于绝大多数芯片。其大致流程如下所示：

在产品的生产过程中，“解锁密码”提前烧录至芯片的OTP内，然后将调试功能“上锁”，此时调试功能是不可用的。

当需要调试芯片时，芯片会通过JTAG接口发送UUID，这时调试主机根据UUID发送相应的解锁密码，若解锁密码与芯片中预存的密码一致，芯片将会开放调试功能。

可以看到，按照上图的机制，基本可以解决我们上文中提出的问题，这也是目前i.MX RT10xx原生支持的Secure JTAG机制（详情请参考应用笔记AN12419）。

认证锁(Debug authentication)

MCU功能越来越丰富，越来越多的MCU拥有不止一个内核，其中的内核有可能还支持Trustzone。例如LPC5500家族的LPC55S69，拥有Core 0和Core 1两个Cortex M33内核，其中Core 0还支持Trustzone技术。

这同时也对我们的调试安全提出了更多的需求，我们不仅需要一把调试锁控制调试功能的开与关，还需要这把锁足够“聪明”，能够提供更细粒度的权限管理。

例如，我们希望外部攻击者不能调试LPC55S69；某些内部人员只能调试LPC55S69的Core 1，不能调试LPC55S69的Core 0，某些内部人员只能够调试Core 0的非安全区域，某些内部人员可以调试整个LPC55S69……

为了满足灵活的调试权限管理需求，LPC5500提供了一种全新的机制：Debug authentication，利用非对称加密机制(RSA2048/RSA4096)，通过证书(DC：Debug Credential Certificate)来授予不同的权限，ODM或设计部门为不同的人员颁发不同的证书，证书中将会明确其所拥有的调试权限。

在调试认证时，芯片会根据某一个人员所持有的证书，对其进行Challenge-Response验证，首先将Response（即DAR：Debug AuthenticationResponse）中的DC与芯片中预置的信息进行匹配，当验证DC为合法后，验证Response中的签名，若证书与签名都验证通过，且请求的调试权限符合芯片的设置，芯片将会开放相应的权限。其大致流程如下所示：