**110020015劉祐瑋 Hardware Security PA3- Hardware Trojan Detection**
Hackmd link: https://hackmd.io/IJCukOBSTfO1VHxzTfveFQ?view
完成度:100%
- [x] Write a Makefile
- [x] HT1
- [x] nHT
- [x] improveHT
- [x] HT2
- [x] nHT
- [x] improveHT
- [x] HT3
- [x] nHT
- [x] improveHT

目錄:
[TOC]
# Makefile 解釋
## com:

com:
	vcs -full64 -R \
		-debug_access+all \
		+v2k \
		-f sim.f \
		-l sim.log \
		-cm line+branch+cond+fsm+tgl \
		-cm_line contassign \
		-cm_cond std+allops \
		-cm_noconst \
		-cm_fsmopt report2StateFsms \

- vcs -full64 -R:
- vcs: Command to invoke the VCS (Verilog Compiled Simulator).
- full64: Enables compilation and simulation in 64 bit mode.
- R: Runs the executable file immediately after VCS links together the executable file.
- debug_access+all:
- debug_access: Sets the debugging mode.
- +all: Allows all forms of debug access, providing deeper insights.
- +v2k:Enables new language features in the proposed IEEE 1364-2001 standard.
- -f sim.f:
- -f: Specifies a list file.
- sim.f: A file containing the files and options needed for compilation.
- -l sim.log:
- -l: Specifies the name of the output log file.
- sim.log: The name of the simulation log file.
- -cm line+branch+cond+fsm+tgl:
- -cm: Specifies compiling for the specified type or types of coverage.
- line: Compile for line or statement coverage.
- branch: Compile for branch coverage
- cond: Compile for condition coverage.
- fsm: Compile for FSM coverage.
- tgl: Compile for toggle coverage
- -cm_line contassign:
- contassign: Specified enabling line coverage for Verilog continuous assignments
- -cm_cond std+allops: Modifies condition coverage as specified by the argument or arguments:
- std: The default: only logical, multiple, sensitized conditions.
- allops: Logical and non-logical conditions.
- -cm_noconst: Tells VCS not to monitor for conditions that can never be met or lines that can never execute because a signal is permanently at a 1 0r 0 value.
- -cm_fsmopt report2StateFsms:
- report2StateFsms: By default VCS does not extract two state FSMs. This keyword tells VCS to extract them.
## sim:

sim:
    ./simv

After using VCS (Verilog Compiled Simulator) for simulation, a compiled executable file named simv is usually produced. This file is generated by the VCS compiler based on the Verilog or SystemVerilog source code you provided.

./simv: This command is used to execute the executable file named simv located in the current directory.

## cov:

cov:
    verdi -cov -covdir ./simv.vdb &

- -cov: This option tells Verdi to enable coverage analysis. Coverage analysis is used to measure how thoroughly the testbench exercises the design under test.

- -covdir: This option specifies the directory where the coverage data is located.

- ./simv.vdb: This path is the directory specified by -covdir and contains the coverage database generated during simulation by VCS. The .vdb extension refers to a Verdi DataBase which stores various forms of data including coverage data.
## clean:

clean:
    rm -rf simv* csrc* *.log *.key ucli.key novas* vdCovLog .fsm.sch.verilog.xml

Delete the files generated by com.

# HT1- HT_Tri and HT_TSC
## nHT:
我們先看未移除前的各個module的coverage report如下圖:
可以發現有很多module的Score分數並不高，所以我們可以針對分數不高的module下手。首先，我們先看到HT_Tri module:



我們由上面可以發現HT_Tri module中toggle report 有兩條線的wire分數過低，第一條是Tj_trig，第二條是state，那我們設計testbench state是只給0-1000所以也只有[8:0]會有切換的動作，所以蠻正常的，但另一條Tj_trig就顯得不正常，可以觀察他的design，可以發現他可能是一個惡意電路的trigger。我們可以再進一步去觀察他output的線連到哪裡，


由上圖可以發現它連線到HT_TSC這個module，所以我們可以去觀察這個module的report看有沒有甚麼異常:



我們可以觀察toggle report發現，HT_tri是因為上一個HT_Tri module的緣故才這麼低，而key是因為tb只有給0-1000才這麼低，所以我們在進一步分析branch report發現 out 為50%而其中一條為0%使用率，這時可以懷疑它應該是個惡意電路，我們再去看design可以發現這個MUX是一個payload。所以HT_Tri以及HT_TSC是一組trojan。
- Triger design is:
- Payload design is:

現在我們要直接把這個module移除，所以aes_top module 會變成下圖:


這時再跑一次make com，並且利用make sim 確認功能正常(確認最後一組OUT data是否一致):

(最後一段模擬截圖)

最後利用make cov打開report，發現確實把第一組trojan 給拿掉了:


且同時我們利用Hierarchy來看的話的確發現整體coverage分數提高了:


## ImproveHT:
根據[Defeating UCI: Building Stealthy and Malicious Hardware](https://www.cs.unc.edu/~csturton/papers/defeating-uci-oak11.pdf)這篇paper內容來improve我們的circuit，論文中說明UCI是利用判斷output wire 是否跟input wire有所關聯，來判斷是否是惡意電路。


然而論文提到"by converting MUX gates to their AND and OR gate representation and treating them as pure data flow elements"，這樣可以提高coverage report 的score分數。因為AND and OR gate這可能會導致在邏輯模擬中觸發更多的分支和條件路徑。因此在進行覆蓋率測試時可能會檢測到更多的細節。

所以我們修改HT1中的?:邏輯寫法:


第一種寫法可能有助於提高程式碼覆蓋率，因為它涉及多個邏輯操作（位元擴展、位元與、位元或），這可能會導致觸發更多的分支和條件路徑。特別是在位元操作層面，每個操作都可能被視為一個獨立的邏輯單元，因此在進行覆蓋率測試時可能會檢測到更多的細節。

第二種寫法雖然在寫法和理解上較為簡單直接，但在覆蓋率測試中不如第一種方法表現出多的邏輯路徑。因為它直接表達了一個高層次的邏輯決策，而沒有涉及更多的中間步驟或細節操作。

Result:

首先，我們先check simulation的正確性(這部分原本有規定，要模擬trigger啟動的結果，但因為我並沒有改trigger condition，所以這部分應該是跟助教設計是一樣的，我就沒有特別模擬)

(最後一段模擬截圖)

同時我們利用Hierarchy來看的話的確發現整體coverage分數並沒有提高，反而降低，這可能是因為我們改進了下層級module提高其覆蓋率，但是，這些修改可能導致整個層級結構中的資料流或控制流發生變化，影響其他模組的執行路徑，使得某些先前被覆蓋的路徑不再被觸發。即使單一模組的測試覆蓋率提高，如果這些測試不夠有效，無法觸發上層或下層模組的關鍵邏輯路徑，整體層級結構的覆蓋率可能因此受到影響。通常在層級結構中，上層模組的行為通常依賴下層模組的輸出。如果下層模組的邏輯或行為被修改，可能會影響上層模組的覆蓋率，即使下層模組本身的覆蓋率有所提高。但我們這裡的重點應該是放在target module的分數而不整個Design，因為UCI檢測是判斷每個module來判斷是否為trogan。所以觀看module發現確實有提高分數。(之後在HT2、HT3我只會針對module 來說明)

DUT:

HT_TSC module:
# HT2- HT_dynamic_key
## nHT
我們先看未移除前的各個module的coverage report如下圖:


可以發現有很多module的Score分數並不高，所以我們可以針對分數不高的module下手。在HT1中我們討論過了HT_Tri和HT_TSC module，現在我們專注於HT_dynamic_key:


我們由上面可以發現HT_dynamic_key module中toggle report 有兩條線的wire分數過低，第一條是HT_key，第二條是key，那我們設計testbench key是只給0-1000所以也只有[8:0]會有切換的動作，所以蠻正常的，但另一條HT_key就顯得不正常，可以觀察他的design，可以發現他可能是一個惡意電路。我們可以再進一步去觀察他output的線連到哪裡，


由上圖可以發現它並沒有連線到其他module，所以這可能是個多餘的design，並不會影響到其他功能，那它就很可能是惡意電路，這時我們在去研究這部分的design。


由上圖可以發現，這其實它的效果類似oscillator，當如果今天key不為0時，它每個cycle 時HT_key會從0變成key，下一個cycle再從key變成0如此循環。這其實是一種消耗功耗的惡意電路。其實這部分trigger跟payload並不好說明，我會認為trigger 是對 HT_key 的值判斷是否為0(但其實我們應該也可以說是否是key的值為0)，而 payload 則是對HT_key的賦值。

現在我們要直接把這個module移除，所以aes_128 module 會變成下圖:


這時再跑一次make com，並且利用make sim 確認功能正常(確認最後一組OUT data是否一致):

(最後一段模擬截圖)

最後利用make cov打開report，發現確實把第二組trojan 給拿掉了:


且同時我們利用Hierarchy來看的話的確發現整體coverage分數提高了:


## improveHT
我們先看到未improve 前的 module report:

由上圖可以發現這部分design並沒有branch，也就是沒有了MUX，所以我們無法利用HT1相同的方法來提高我們的Score，但我們一樣可以根據論文的論點也就是讓output wire 竟可能的跟input wire 有關係。那這邊report可以看出可以改進的部分為toggle report的部分，那因為toggle 是代表一個bit 是否有switch，那因為剛好我tb key只有[10:0]有在改變進一步影響這部分HT_key也只有[10:0]在改變，剛剛好的被我利用這種test pattern測試出來，所以我們設計的時候可以想到如果別人test pattern 只動key[10:0]就可能被偵測到，所以我們要讓HT_key竟可能的跟不同的bit有所關連而不是一一對應，所以我設計了一個counter來盡可能的提高在可能遇到不同的test pattern 都有較好的表現。


Result:

首先，我們先check simulation的正確性(因為這部分並沒有接線接出來，所以無法模擬出來被trigger。)

(最後一段模擬截圖)

觀查module report發現確實有提高分數:


# HT3- HT_Comp
## nHT
我們先看未移除前的各個module的coverage report如下圖:


可以發現有很多module的Score分數並不高，所以我們可以針對分數不高的module下手。在HT1中我們討論過了HT_Tri和HT_TSC module，以及在HT2中我們討論過了HT_dynamic_key，現在我們專注於aes_128:


我們由上面可以發現aes_128 module中toggle report，有好幾條線分數都過低，但細看那些其實要不是tb的因素就是HT2中所導致的，所以由toggle report並找不出甚麼有用的資訊。


我們在進一步分析branch report發現 out 為50%而其中一條為0%使用率，這時可以懷疑它應該是個惡意電路，我們再去看design可以發現這個MUX可能是一個payload。而它的可能的trigger 為HT_cond，這時我們需要進一步的判斷HT_cond到底有沒有必要。




由上面我們可以發現其實，HT_cond是藉由one_round所產生，然而由one_round中的HT_Comp產生，而我們可以發現其one_round不包含HT_Comp這個module就已經是符合aes128的design，所以這是個多餘的電路，更是惡意電路，是一個trigger。所以這組的trigger是由HT_Comp中state_in1與state_in2 XOR產生。

現在我們要直接把這整組trojan移除，所以aes_128 module 以及 round module會變成如下圖(同時移除HT_Comp module):



這時再跑一次make com，並且利用make sim 確認功能正常(確認最後一組OUT data是否一致):

(最後一段模擬截圖)

最後利用make cov打開report，發現確實把第三組trojan 給拿掉了:


且同時我們利用Hierarchy來看的話的確發現整體coverage分數並沒有提高，反而降低，但可能在刪除module時有更改部分wire接線影響到了baseline，所以可能計算的基底不一樣，導致整體分數沒有判斷價值。除此之外，其實我們在test的時候並不是在意整體的分數，而是每個module的分數，才來判斷那個module是否為正常(在HT1 HT2中是因為把整個拿掉了，所以我們以整個DUT為compared)，所以我們現在只focus分析aes_128 module 發現確實score分數提高，代表我們使用率提高，也消除了不必要的惡意電路。



## improveHT
我們先觀察HT3的aes_128 module(因為payload在aes_128 module)，可以發現他有branch代表我們可以利用HT1所提供的方法來improve這個設計。

所以更改地方如下:

Result:
首先，我們先check simulation的正確性(這部分原本有規定，要模擬trigger啟動的結果，但因為我並沒有改trigger condition，所以這部分應該是跟助教設計是一樣的，我就沒有特別模擬)

(最後一段模擬截圖)

觀查module report發現確實有提高Score:


# Hardness of this assignment:
我認為這篇困難的點是要improve trojan逃過UCI檢測，最後我讀了很多的paper才找到一種最簡單最適合我的方法來完成這次的design。