安全調試的前世今生

對于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中的簽名，若證書與簽名都驗證通過，且請求的調試權限符合芯片的設置，芯片將會開放相應的權限。其大致流程如下所示：

可以看出，這種Debug authentication機制解決了調試接口的安全問題，也滿足了調試權限靈活管理的需求。

小結

相對來說，Debug authentication需要做的準備工作比較多，本文簡單描述了Debug authentication的基本機制，并未提供詳細的操作步驟。

如何生成DC/DAR、如何對芯片進行預處理、如何完成一次Debug authentication，請參考應用筆記AN13037 ，并且NXP提供了開源的工具，參考應用筆記就能夠利用工具完成所有工作。

責任編輯：haq