本卡屬 FR-076（母卡 CM-1566），掃 License 鏈的第 1 棒：License 驗章核心（密碼學層）（jedi-license-runtime）。只掃不修。

這一棒在做什麼（白話）

用 Claude Code 的 claude-security plugin，掃 jedi-license-runtime 的「License 驗章核心（密碼學層）」這一塊（約 10 個檔），找出資安問題並產出報告。只找問題、不修問題——修正是後續另外開卡的事。

為什麼掃這一塊

這 10 個檔決定「一張 license 是真是假」。驗章寫錯，整套授權機制歸零——攻擊者自簽一張無限期全模組的照就能免費用整個產品。範圍最小但密度最高，所以第一棒跑它，順便驗證「Opus 1M ＋ 小範圍」這個組合可行。

重點看什麼

這些是給你的思考起點，不是檢查清單——掃描工具會自己找，這裡列的是首腦讀過程式碼後認為最容易出事的地方：

• 兩種信封格式共存：verify_payload 同時收 v2（format_version: 2，驗 packed payload 的 canonical bytes）與 v1（明文 dict 扣掉 signature/alg 後驗）。兩條路徑共存就是降級攻擊的典型場景——能不能構造一張 v1 的照，讓它繞過 v2 才有的檢查？兩條路徑對 kid、alg、payload_type 的檢查是否等價？
• payload_type 的預設值：docstring 明說「payload 缺該鍵時視為 license」。license／manifest／unlock_token 三種憑證共用同一組公鑰與同一支驗章——缺鍵即當 license，會不會讓一張 manifest 或 unlock_token 被當成 license 使用（型別混淆）？
• canonical JSON 的一致性：簽章對象是 payload 的 canonical bytes。簽發端（license_center）與驗證端算出來的 canonical 形式若有任何差異（key 排序、unicode 轉義、浮點數表示、重複 key），就可能出現「同一份語意、兩種 bytes」——攻擊者能否利用差異讓驗章通過但解析出不同內容？
• 時鐘回撥判定 is_clock_rollback：浮水印是「系統見過的最大 issued_at」。浮水印存哪、誰能寫、能不能被清掉或往回改？clock_watermark=None 是明文的降級行為（不檢查），哪些呼叫端會傳 None？
• 機器指紋的 fallback：讀不到 /etc/machine-id 就用 uuid.getnode()（MAC 推導）。攻擊者能否讓指紋變成自己可控或可預測的值？（已知事故：容器內 /etc/machine-id 是空檔會退回隨機 MAC 導致指紋漂移）
• 硬編公鑰：public_keys.py 同時放 DEV／STG／POC 三把公鑰，意味著用 DEV 私鑰簽的照，POC 機器也會認。這是刻意的設計還是疏漏？判斷並說明理由。
• 解析錯誤的訊息會不會洩漏可用於構造攻擊的資訊（例如區分「kid 不存在」與「簽章不符」）

已知背景

（本套件從未被掃過。相關背景：FR-064 曾發生容器 machine-id 空檔導致指紋漂移；FR-062 曾因 passphrase 遺失重產 STG 簽發鑰）

怎麼做

第一步：確認 plugin 在，並讀掃描 job 的作業書，照它的步驟走：

ls /Users/chouraymond/.claude/plugins/cache/claude-plugins-official/claude-security/0.10.2.3/skills/claude-security/
cat /Users/chouraymond/.claude/plugins/cache/claude-plugins-official/claude-security/0.10.2.3/skills/claude-security/jobs/scan-codebase.md

第二步：驗 scope 檔數，對上 10 才啟動（避免整包誤掃）：