當前位置:
首頁 > 新聞 > 使用DFA攻擊硬體的AES演算法,並從PlayStation Vita中提取硬體密鑰

使用DFA攻擊硬體的AES演算法,並從PlayStation Vita中提取硬體密鑰

在過去的幾個月里,我一直試圖從PlayStation Vita中提取硬體密鑰。為此我還專門寫了一篇論文,裡面詳細介紹了我所使用過的所有的技術細節和理論依據,感興趣的讀者可以點此詳細了解。本文是對具體的操作過程進行講解,為大家提供一個直觀地理解。

註:PlayStationVITA是索尼的一代掌機,簡稱PS Vita、Vita或PSV,以下我會將PlayStation Vita統稱為PSV。

DFA

DFA全稱為:Deterministic Finite Automaton,即確定有窮自動機。其特徵為:有一個有限狀態集合和一些從一個狀態通向另一個狀態的邊,每條邊上標記有一個符號,其中一個狀態是初態,某些狀態是終態。但不同於不確定的有限自動機,DFA中不會有從同一狀態出發的兩條邊標誌有相同的符號。

高級加密標準(AES)演算法具有抗差分和線性攻擊能力,卻容易受到故障攻擊,該攻擊對密碼系統破壞較大。

DFA的主要思想是:我們可以像在處理器上一樣對AES硬體使用故障攻擊,但是我們不使用它來控制代碼執行,而是使用它來使用正確的密鑰進行錯誤的AES加密。由於AES是一種脆弱的演算法,稍作修改會導致它以非正常的方式泄露有關密鑰的信息,而我們正是利用了這一演算法的弱點。

不過,目前除了學術界對「針對AES解密的DFA攻擊方法」有研究外。實際的應用案例並不多,在我們對Github進行了搜索後,我們只發現了兩個嚴重的AES DFA攻擊實現示例。 dfa-aes是2009年一個實現示例,其中經過8個周期和2的32次暴力破解,可以產生準確的AES-128密鑰。 2002年至2016年期間,雖然有很多人發表了許多相關的論文,描述了相關的故障攻擊。但是,我們無法找到這些論文附帶的任何源代碼示例。最後,我們從phoenixAES中找到了相應的源代碼,儘管它們不是最先進的(文獻中的大多數代碼在實踐中並沒有多大意義)。因為編寫代碼很無聊且需要花費很長時間,所以這個示例是很有意義的。

撇開這個問題不談,完成攻擊的主要的工作是完善我們的故障設置,以便在8周期的暴力破解中向AES引擎(AES engine )注入精確故障,比如故障不超過一個位元組。一旦我們的故障設置完成,我們就可以將收集到的樣本置入phoenixAES或dfa-aes。使用DFA攻擊硬體的AES演算法,並從PlayStation Vita中提取硬體密鑰

DPA

在介紹我們如何布置DFA故障的設置之前,我們有必要向介紹一下對PSV的DPA攻擊。差分功耗分析(Differential power analysis)是一種邊信道攻擊,如果攻擊者在使用密鑰操作時觀察AES引擎的功耗,就可能找到泄漏的密鑰。首先,攻擊者會假設一個密鑰值。然後,他們定義AES引擎的功耗使用模型,以預測密鑰值在假設正確的情況下會消耗多少功耗。最後,使用該密鑰值運行引擎並測量實際功耗以查看預測的準確性。通過多次重複,就可可以找到整個密鑰。 Chipwhisperer wiki對差分功耗分析的運行過程進行了很好的介紹,你可以點此查看。

為了在要攻擊的目標上執行DPA,你需要能夠精確測量晶元中的電流(current)。一種方法是應用法拉第定律:變化的磁場會產生電壓。你可以使用「磁探針」測量電流.Colin O"Flynn在Blackhat中描述了如何構建自己的磁探針,我按照他的辦法構建了一個,使在其上運行ChipWhisperer示例。

不幸的是,上圖所示工具的環狀大小決定了測量的精確程度,且一個好的工具非常昂貴。而測量電流的另一種方法是應用歐姆定律:通過電阻的電流變化等於通過電阻的電壓變化。這需要修改電路,以在電源和目標晶元之間引入小的電阻器。

隨著晶元消耗更多功耗,它將需要更大的電流,這導致電阻器兩端的電壓下降更大。為了利用並聯電阻測量,我們需要先將PCB中從電源到目標晶元的線切斷。然後我們將目標晶元連接到我們的定製電路板,該電路板有一個分流電阻和測量探針埠。我們使用外部電源為電路板供電,其實我們可以使用Vita自帶的電源,但它更容易連接外部電源。

自定義設計的psvcw板有一個分流電阻,一個濾波電容器,以及用於差分探針和CW glitcher的埠,頂部還有探測eMMC信號到目標晶元的電線。我們使用它們將有效載荷快閃記憶體到eMMC,並觸發電壓故障以獲得代碼執行。

外部電源連接到psvcw

然而,即使使用並聯電阻法,我們也無法獲得良好的信噪比(SNR或S/N,是指一個電子設備或者電子系統中信號與雜訊的比例)。我們觀察到,在AES加密期間,SRAM讀寫操作在功耗跟蹤中佔主導地位(涉及多個幅度),因此很難找到跟蹤和密鑰之間的任何相關性。由於PSV的SoC是為低功耗而設計,所以我們確定DPA有確切設置,如果要獲得提高信噪比所需的正確設備,成本將會太高。

在0-50個周期內,會開啟觸發GPIO信號,在250-350個周期內,進行AES操作。到第600個周期時, GPIO會關閉,整個過程中的小幅度下降可能是F00D處理器操作引起的。

儘管名稱相似,但DPA和DFA完全不相似。 DPA是(被動)側通道攻擊,而DFA是(主動)故障攻擊。然而,所有嘗試DPA的工作都沒有白費。首先,我們獲得了關於AES操作發生時間的寶貴信息。通過將單個AES操作的跟蹤與我們收集的其他跟蹤(即沒有AES操作或有多個AES操作)進行比較,我們可以得出結論,AES操作發生在觸發後功耗在250-350個周期下降的地方。為此我們對PCB進行了修改,在測量中插入了一個並聯電阻並降低了信噪比,這也同時滿足了我們更精確的對故障進行設置的目的。這一點很重要,因為在以前,我們的攻擊目標是在安全處理器出現故障時,獲得代碼執行。為了到達這個效果,可以在多個周期中出現故障。由於AES引擎在每個周期執行4次操作,且都引起了電壓高峰,為了不被目標設備的配電網路過濾掉,插入了一個並聯電阻是很有必要的。

PlayStation Vita的安全架構

為什麼攻擊者會對來PSV如此有興趣呢?因為PSV是一種非常獨特的設備,可以獨立實現許多安全功能。且該設備於2012年發布,要知道當時大多數Android手機還沒有基本的漏洞利用緩解措施,例如啟用地址隨機化,而它的直接競爭對手(3DS)在硬體和軟體安全方面都與它差幾個等級。

PSV操作系統是完全專有的,其中一些代碼來自NetBSD(一個完全開放源代碼的類UNIX系統),另一些代碼來自索尼PSP。在大多數設備運行BSD,Linux或某些RTOS的世界中,作為一名逆向工程師,看到新的操作系統總是令人興奮的。但專有並不意味著安全,雖然很難找到轉儲內核的原始漏洞,但我們在2013年利用了幾個NetBSD衍生模塊進行了嘗試分析,發現其中的代碼並不是安全的,而是晦澀難懂的。然而,值得稱讚的是,整整一年都沒有人能夠攻破這些內核,即使在我們分析了它之後,也沒有人能夠在接下來的三年里做到這一點(直到我們發布了一個越獄版本)。內核本身具有所有針對緩衝區溢出攻擊的標準緩解和針對泄漏地址的保護,另外,它還有一些在當時看來非標準的緩解措施,如SMAP和系統調用防火牆。 PSV也使用了ARM TrustZone,但在Android手機將所有秘密存儲在TrustZone中的時候,PSV只使用TrustZone作為緩衝區來連接F00D安全處理器。只有TrustZone可以直接與F00D處理器通信,但TrustZone本身沒有秘密,事後看來這是一個好的安全措施。

Bigmac

如果我們想要了解內容(遊戲、數據、固件、更新等)是如何解密的,我們必須查看F00D處理器,它是一個處理所有加密和關鍵安全任務的處理器。 F00D運行在一個基本上沒有文檔的架構上,但我們能夠在適當的時候破解它。然而,即使是攻擊F00D也不足以完全破解這個系統。 F00D代碼中有許多加密密鑰,其中最重要的密鑰(包括引導載入程序的密鑰)隱藏在晶元中,只能通過我們稱之為Bigmac的硬體AES引擎才能訪問它們,其中有250個這樣的密鑰槽(keyslot)。這些密鑰中有30個被稱為「元密鑰」或「主密鑰」,因為Bigmac只允許使用它們將數據加密到另一個密鑰槽即導出密鑰,無法直接使用主密鑰加密數據並查看密鑰。

在執行引導載入程序之前,大多數密鑰槽(包括所有主鍵)都被鎖定,這意味著只有啟動ROM才能在Bigmac中使用它們。因此,總結一下,要對AES進行攻擊,我們必須要逐一完成以下過程:

1.讓WebKit(一個開源的瀏覽器引擎)獲得初始執行許可權;

2. 破解ARM內核;

3. 破解ARM TrustZone;

4. 破解F00D內核;

5.利用F00D引導ROM;

為此,我們從頭開始研究,除了利用F00D引導ROM(這個過程得依賴軟體漏洞)之外,用了六年的時間來完成整個過程。利用這些知識,黑客足以入侵ARM內核,運行自製程序和mods,以及盜版遊戲。6年前,我為自己設定了一個任意目標:獲取引導載入程序的解密密鑰。當時我的想法是,如果我們能夠解密第一個可載入的代碼,那麼索尼就無法在未來的更新中隱藏代碼。後來,這個密鑰還專門獲得了一個名稱:slot 0x208(一個元密鑰)。

故障攻擊和DFA

之前,我討論了如何使用電壓故障在F00D安全處理器上獲得啟動時代碼執行。這和 DFA有什麼關係呢?因為大多數密鑰槽在引導ROM退出到引導載入程序之前被鎖定,所以我們需要在接管引導ROM之後執行DFA攻擊。為此,我們必須使用我們之前發現的相同故障參數重複F00D上的電壓故障攻擊。之前,我們執行的有效載荷只是轉儲引導ROM,但現在已經被RPC取代,所以我們可以通過ChipWhisperer的串列介面從PC控制Bigmac。一旦這個RPC有效載荷運行,我們就可以使用不同的觸發信號和不同的參數執行第二個故障攻擊,從而導致Bigmac AES出現故障。這裡的主要任務是找到第二組參數,一旦我們擁有它們,就可以通過使用RPC發送Bigmac命令、觸發故障、下載由故障泄露的密鑰。有了足夠的密鑰,就可以執行DFA攻擊來提取密鑰。

psvemmc板會收集來自PSV PCB的所有必需信號,包括用於eMMC觸發(電路板背面)、時鐘(取代PSV自己的時鐘合成器晶元),UART,電源,複位和GPIO觸發(重新路由LED信號)。它還有一個開關,可以啟用eMMC快閃記憶體模式,該模式使用USB2244和一個電平轉換器來支持通過USB的1.8V eMMC快閃記憶體。

現在,提取密鑰的一切準備工作都完成了。

分析由故障泄露的密鑰

為了將故障注入AES操作,我們使用RPC來切換GPIO引腳並立即啟動Bigmac。 GPIO切換設置參考點並用作glitcher的觸發器。在執行第二個故障之前,我們需要在觸發後等待幾個周期。從上面的功耗跟蹤中,我們可以了解到,在250到350個周期之間會發生AES加密。當我們嘗試在偏移240-280處引入故障時,我們會得到由故障導出的密鑰。但是,我們並能確切知道經過多少個周期,且有多少位元組被破壞。回想一下,為了使用phoenixAES,我們需要兩個由故障而導出的密鑰,且每個密鑰在第8個周期都有一個位元組被破壞,但他們卻是不一樣的。

為了弄清周期偏移與AES故障之間的關係,我們可以將已知密鑰注入給Bigmac並嘗試加密一個已知的明文,然後我們再使用已知密鑰解密由故障導出的密鑰。在解密的每一步中,我們都可以將狀態矩陣與解密正確密鑰的相同步驟進行區分。我們可以假設,在翻轉的狀態下,位數最少的步驟就是我們設法進行故障攻擊的步驟。為什麼?因為AES在設計上確保了一種稱為擴散的特性。這意味著,平均而言,輸入中的一個位翻轉將導致輸出中的半個位翻轉。 AES中的每個步驟都嘗試將狀態的微小變化傳播到儘可能多的位置。例如,假設我們設法在第5個周期的MixColumns之後立即注入故障,以便在位元組0中翻轉一個位,將0xAA更改為0xAB。在第6周期SubBytes中,位元組0傳遞到S-Box,其中0xAA的輸入產生0xAC的輸出,但0xAB的輸入產生0x62的輸出。請注意,我們現在已經進行了5個翻轉,繼續第6個MixColumns,我們看到每個列都被加擾,這意味著4個位元組現在是不同的。然後在第7周期ShiftRows中,將這4個位元組中的每一個重新定位到不同的列,另一個MixColumns將對每個列進行更多的加擾。現在, 16個位元組都不同。依此類推,我們很容易看出,當我們經歷更多周期時,一個周期狀態的微小變化將導致整個狀態的巨大變化。

利用這種方法,我們可以在每個偏移量上收集許多有漏洞的密文樣本,並查看每個偏移量對哪一周期的影響最大。這裡的視頻展示了這一工作原理:我們改變故障偏移量並觸發故障,然後立即分析故障,以查看哪些周期受到影響,以及狀態中的哪些位被翻轉。

此外,我們還發現無論偏移量如何,我們的大多數故障只能影響一位或兩位,這比所要求的(損壞一個位元組)要好。

提取密鑰

使用正確的偏移量,我們可以在第8個周期發現故障。很有可能,我們得到1-2位翻轉,這符合phoenixAES的要求。但是,如果我們運氣不好而且我們碰巧收集了兩個由故障引發的密鑰,其中已損壞的位元組大於一位,我們怎麼辦?最好的解決方案是更改故障模型,我們正在使用的是Piret在2003年首次提出並在phoenixAES中實現的模型。但是,後來的模型允許最多12個位元組的損壞(儘管有一些限制)。由於我們很懶,並且不想編寫大量代碼,因此不想更換新的模型。

提取AES-256密鑰

到目前為止,我們只提到了提取AES-128密鑰的方法。但是,將這個方法擴展到AES-256並不太難。經過測試,我們經過12周期的攻擊就可以獲得密鑰。

完整的設置:psvemmc由USB供電,通過20針連接器連接到ChipWhisperer。 CW故障埠連接到psvcw,膠合在電路板底部,其中裝有併流電阻。紅色和藍色線將外部1.1V電源連接到psvcw。最後,電池和USB連接器都是可以為PSV供電。

提取主密鑰

到目前為止,所描述的一切都適用於非主密鑰。回想一下,我們在前面說過主密鑰不能用於直接加密內容,因為該過程涉及使用Bigmac將一些明文加密到另一個密鑰槽。當然,解決此問題的一種方法是執行兩級DFA攻擊,但是,我們沒有使用這個方法,因為我們已經知道Bigmac中有一個公開從密鑰的硬體漏洞。Davee寫了一篇關於這個漏洞如何運作的帖子,你可以看一下。簡而言之,因為Bigmac在加密成功後沒有清除內部狀態,如果執行第二個加密大小

總結

我們已經使用本文的辦法恢復了30個主密鑰,包括插槽0x208(插槽)密鑰。


喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 嘶吼RoarTalk 的精彩文章:

Linux容器安全探索
漏洞預警信息:Verifications.io和Facebook Messenger均發生致命漏洞

TAG:嘶吼RoarTalk |