WEBVTT

1
00:00:00.000 --> 00:00:03.820
簽章有效只證明某把信任金鑰簽過這些位元；

2
00:00:03.820 --> 00:00:10.100
它不自動證明版本可接受、量測的是即將執行的映像，或金鑰會在正確 lifecycle 釋出。

3
00:00:10.100 --> 00:00:14.100
倉庫收貨時，封條、批號與箱內物必須對得上；

4
00:00:14.100 --> 00:00:17.140
只驗封條不能證明搬運途中沒有換箱。

5
00:00:17.140 --> 00:00:24.140
Secure Boot 也要把簽章者、映像摘要、硬體目標、security version、載入位置及最終取指綁在同一

6
00:00:24.140 --> 00:00:28.540
筆交易。類比不包含雜湊碰撞假設、DMA競爭與微架構快取。

7
00:00:28.840 --> 00:00:36.640
典型路徑是 immutable/ROM root 取得公鑰或 keyidentifier，驗證 manifest 與簽章，

8
00:00:36.640 --> 00:00:41.180
再檢查版本下限，最後鎖住相關設定並交接執行。

9
00:00:41.180 --> 00:00:47.540
若驗證後可寫記憶體被 DMA 改動，先前的 pass不再代表當前 bytes。

10
00:00:47.540 --> 00:00:54.480
把驗證摘要與不可變 buffer/受保護載入區域關聯，並在接受端記錄 commit。

11
00:00:54.480 --> 00:01:01.340
OpenTitan key manager 文件將軟體 binding、版本與 sideload outputs 分成明確控制；

12
00:01:01.340 --> 00:01:03.920
產品仍須按實際整合判讀。

13
00:01:03.920 --> 00:01:11.980
最常漏掉的是「檢查完成」與「使用」之間的時間差：rollback counter 若只在軟體端讀一次，

14
00:01:11.980 --> 00:01:19.200
並發更新可能換掉版本；key release 若只看boot_done sticky，可能沿用前一映像的授權。

15
00:01:19.200 --> 00:01:25.100
將 transaction ID、digest、version、lifecycle與目的 key slot 綁定，

16
00:01:25.100 --> 00:01:30.940
失敗時採拒絕釋出；安全拒絕仍需避免永久不可恢復的拒絕服務。

17
00:01:31.257 --> 00:01:36.757
把資產邊界定為「第一個取指」及「第一個sideload key 使用」。

18
00:01:36.757 --> 00:01:43.737
First fetch 要確認簽章、版本、摘要與transaction ID 都來自同一筆交易。

19
00:01:43.737 --> 00:01:47.997
Key release 還要符合 lifecycle 與目的 keyslot 政策。

20
00:01:47.997 --> 00:01:52.917
RTL/SVA 示意不是產品 assertion，尚未接線或編譯。

21
00:01:52.917 --> 00:01:57.697
依序比較：合法新映像；簽章正確但版本低；

22
00:01:57.697 --> 00:02:01.677
簽署摘要為映像 A、取指卻來自映像 B；

23
00:02:01.677 --> 00:02:04.157
前次啟動的 boot_done sticky；

24
00:02:04.157 --> 00:02:07.277
debug lifecycle 下請求 production key。

25
00:02:07.277 --> 00:02:10.897
每種都要保留第一個違規接受邊緣及拒絕理由。

26
00:02:11.257 --> 00:02:17.857
以下為性質草案：先定義 harness 的transaction、reset 與 oracle，並確認取樣邊界，

27
00:02:17.857 --> 00:02:20.977
再接入設計；尚未編譯或證明。

28
00:02:20.977 --> 00:02:25.517
此片段不證明 CDC、timing、side-channel 或實體注入；

29
00:02:25.517 --> 00:02:28.477
需由各自工具與測量提供證據。

30
00:02:28.477 --> 00:02:32.017
可以把每次開機想成一筆不可拆散的交易。

31
00:02:32.017 --> 00:02:37.117
交易開始時記下映像摘要、版本、lifecycle與目的key slot；

32
00:02:37.117 --> 00:02:43.017
驗證完成後，載入內容仍可能被DMA改寫，所以不能只保存一個pass旗標。

33
00:02:43.017 --> 00:02:49.457
到第一次取指或釋出key時，接受端要重新確認目前內容仍屬於同一筆交易。

34
00:02:49.457 --> 00:02:55.617
測試時分別換掉摘要、版本、lifecycle或keyslot，並保留第一個違規接受點。

35
00:02:55.617 --> 00:02:59.417
這些是待測設計性質，本套件沒有接線或證明它們。

36
00:02:59.715 --> 00:03:07.215
一筆啟動交易把映像摘要、簽章結果和版本下限綁在一起，也要記錄 lifecycle 與 key slot。

37
00:03:07.215 --> 00:03:11.135
第一次取指與第一次釋出金鑰是兩個資產邊界。

38
00:03:11.135 --> 00:03:19.135
驗證結果若和後續使用的對象脫鉤，rollback 或前次 sticky 狀態就可能讓過期授權沿用。

39
00:03:19.135 --> 00:03:26.755
把位元組、版本、lifecycle 和 key slot 綁在不可變的 transaction context，失敗時預設拒絕，

40
00:03:26.755 --> 00:03:34.095
並保護接受端。逐案檢查合法、過期、篡改、映像替換與 lifecycle 不符的輸入。

41
00:03:34.095 --> 00:03:38.475
本課尚未實測 RTL、簽章及記憶體整合；

42
00:03:38.475 --> 00:03:45.355
產品的金鑰管理、供應鏈根信任、側通道、實體key vault 與 recovery image 細節也未涵蓋。

43
00:03:45.355 --> 00:03:48.995
現在加入 rollback counter 更新與並發 DMA。

44
00:03:48.995 --> 00:03:53.075
內容在哪裡必須鎖定，sideload key 何時才可釋出？

45
00:03:53.075 --> 00:03:59.215
回到第一次取指或釋出金鑰的時刻，確認接受端使用的仍是已驗證的那份內容。

46
00:03:59.215 --> 00:04:02.395
把驗證與使用之間的時間差寫進測試。

47
00:04:02.395 --> 00:04:07.755
每次啟動都重新確認 transaction，並查內容在使用前是否再次改變。