安全調試的前世今生
對於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提供了開源的工具，參考應用筆記就能夠利用工具完成所有工作。
免責聲明：本文系網絡轉載，版權歸原作者所有。如涉及作品版權問題，請與我們聯繫，我們將根據您提供的版權證明材料確認版權並支付稿酬或者刪除內容。