安全调试的前世今生
对于MCU的开发工程师来说,MCU的调试接口是必不可少的开发利器。透过调试接口,我们可以监视MCU的运行状态,查看或修改寄存器的数值,观察内存中的数据变化,通过IDE、调试器等开发工具配合,方便地排查各种棘手的问题。
我们需要了解的一切信息,调试接口都知无不言,言无不尽。
那么问题来了,在产品出厂后,黑客、攻击者就可以利用强大的调试接口对设备进行各种攻击,窃取产品中的敏感信息;黑色产业链也可以通过调试接口,轻而易举地读取出设备的固件,从而生产制造廉价的“破解版”。
正是由于调试接口功能强大,这个开发过程中的利器,也给产品带来了安全的漏洞和知识产权泄露的隐患。
针对这个问题,很多高附加值或安全敏感的产品,会选择在生产过程的最后一步,通过修改OTP Fuse等方式,将调试接口永久地禁掉。产品出厂后,调试接口已被封死,简单粗暴地解决调试接口带来的风险。
但是,产品的售后、维护往往不是一帆风顺的。产品在客户现场,也许会出现各种各样奇奇怪怪的问题。此时,由于调试接口被封掉,留给我们的调试排查手段捉襟见肘,产品出现问题后,难以定位更难以解决。
有没有一种方法,只能让开发者合法地调试芯片,而不会被攻击者利用呢?
Secure Debug安全调试
传统的手段,是将调试接口永远的封死,那么Secure Debug就像是给调试接口加了一把坚固的锁,只有能打开这把锁的人才能使用调试功能。
毫无疑问,“锁”比“封”要更加灵活。那么,我们应该选择使用一把什么样的锁呢?
密码锁
这是一种简单有效的方案,适用于绝大多数芯片。其大致流程如下所示:
在产品的生产过程中,“解锁密码”提前烧录至芯片的OTP内,然后将调试功能“上锁”,此时调试功能是不可用的。
当需要调试芯片时,芯片会通过JTAG接口发送UUID,这时调试主机根据UUID发送相应的解锁密码,若解锁密码与芯片中预存的密码一致,芯片将会开放调试功能。
可以看到,按照上图的机制,基本可以解决我们上文中提出的问题,这也是目前i.MX RT10xx原生支持的Secure JTAG机制(详情请参考应用笔记AN12419)。
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中的签名,若证书与签名都验证通过,且请求的调试权限符合芯片的设置,芯片将会开放相应的权限。其大致流程如下所示:
可以看出,这种Debug authentication机制解决了调试接口的安全问题,也满足了调试权限灵活管理的需求。
小结
相对来说,Debug authentication需要做的准备工作比较多,本文简单描述了Debug authentication的基本机制,并未提供详细的操作步骤。
如何生成DC/DAR、如何对芯片进行预处理、如何完成一次Debug authentication,请参考应用笔记AN13037,并且NXP提供了开源的工具,参考应用笔记就能够利用工具完成
来源:恩智浦MCU加油站
审核编辑:汤梓红
-
芯片
+关注
关注
453文章
50378浏览量
421678 -
mcu
+关注
关注
146文章
16984浏览量
350234 -
接口
+关注
关注
33文章
8491浏览量
150809
发布评论请先 登录
相关推荐
评论