烏魚子

Twofish 加密演算法深度解析 1998 年， Bruce Schneier 率隊提交 Twofish，進入 AES 競選決賽五強，最終敗於 Rijndael。儘管未獲選，Twofish 至今仍是 最受信任的對稱式分組加密演算法 之一，開源、免費、無已知後門。 核心架構：Feistel 網路與金鑰排程 Twofish 採用 128-bit 固定區塊長度 ，支援 128、192、256-bit 三種金鑰長度。其底層為 16 輪 Feistel 網路 ，每輪使用四個依金鑰生成的 8×8-bit S-Box，再經 MDS 矩陣混合，達到高度擴散效果。最具特色的設計是 金鑰預先白化（Key Whitening） ：明文在進入 Feistel 輪次前後，分別與子金鑰進行 XOR，有效抵禦差分與線性密碼分析。金鑰排程採 Reed-Solomon 碼強化子金鑰生成，使暴力破解幾乎不可行。 安全特性與現代應用場景 Twofish 至今 無任何公開的實際破解紀錄 ，理論最佳攻擊僅能對 7 輪（完整 16 輪的一半）造成影響，安全邊際極高。由於完全開放授權，它被廣泛整合至 GPG、VeraCrypt、KeePass 等主流開源安全工具。與 AES 相比，Twofish 的金鑰排程更耗時，在低功耗裝置上略遜，但在 金鑰切換頻率低、資料量大 的加密場景（如磁碟全加密）中，效能表現依然出色。 💡 重點整理 區塊與金鑰規格： 128-bit 區塊，支援 128/192/256-bit 金鑰。 核心設計： 16 輪 Feistel + 動態 S-Box + MDS 矩陣 + 金鑰白化。 授權完全開放： 無專利限制，可自由用於商業或開源專案。 現實安全性： 至今零已知實際攻擊，常見於磁碟加密與密碼管理工具。 Twofish 雖未成為 AES 標準，卻以 嚴謹設計、透明授權與長期零破解紀錄 證明了自身價值。在需要高度信任且不依賴標準制定機構背書的場景，Twofish 依然是首選之一。 📚 參考文獻 Schneier, B. et al. (1998). Twofish: A 128-Bit Block Cipher — 原始演算法論文，Counter...

在雲端服務盛行的今日，企業如何向客戶證明資訊系統的可信賴性？ TSCs（信賴服務準則） 正是 AICPA 為此設計的 SOC 2 稽核框架，提供一套客觀、標準化的評估基準。 什麼是 TSCs？五大核心領域一次看懂 TSCs 由 AICPA 制定，用於評估服務組織資訊系統的控制有效性。框架共涵蓋 五大核心領域 ，其中 安全性（Security）為唯一必選項目 ，其餘四項可依業務需求選擇納入稽核範疇。 安全性（Security） ：防止未授權存取，涵蓋邏輯與實體控制，必選。 可用性（Availability） ：確保系統在約定時間內正常運作與存取。 機密性（Confidentiality） ：保護機密資訊從蒐集到銷毀的全生命週期。 處理完整性（Processing Integrity） ：確保系統處理過程完整、正確、及時。 隱私性（Privacy） ：個人識別資訊（PII）的蒐集、使用與保留符合規範。 SOC 2 稽核實務：控制設計與評估重點 SOC 2 稽核分為 Type I （特定時間點的控制設計適切性）與 Type II （通常 6–12 個月的控制運作有效性）兩種報告形式。稽核師依據每個 TSC 對應的 通用標準（CC 系列） 逐項檢核，例如 CC6 涵蓋邏輯存取控制，CC7 涵蓋系統異常監控。 實務上，組織需準備 控制矩陣（Control Matrix） ，將內部控制措施對應至各 TSC 標準，並佐以存取日誌、變更記錄、事件回應紀錄等證據文件。 差距分析（Gap Analysis） 是準備稽核的關鍵前置步驟，能有效識別不符合項目並排定修補優先順序。 💡 重點整理 安全性是 TSCs 唯一強制選項，其餘四項依業務情境彈性選擇。 Type II 報告因涵蓋運作期間，客戶信任度高於 Type I。 控制矩陣是連結內部措施與稽核標準的核心工具。 差距分析應在稽核啟動前至少 3–6 個月完成。 TSCs 不只是稽核合規的文件工程，更是組織建立系統性資安治理的基石。選擇適合的準則範疇、持續維護控制措施，才能讓 SOC 2 報告真正發揮對客戶的信任背書價值。 📚 參考文獻 AICPA， Trust Services Cri...

什麼是系統可信賴性（Trustworthiness）？ 在現代系統工程中， Trustworthiness（可信賴性） 不只是「不被駭客入侵」這麼簡單。NIST SP 800-160 將其定義為：系統能在預期條件下如期運作、且不產生不可接受風險的整體品質。這個定義涵蓋三個互相支撐的支柱： 安全性（Security） 、 韌性（Resilience） 與 可靠性（Reliability） ，缺一不可。 許多組織誤以為部署防火牆或加密就等於可信賴系統。然而，若系統在遭受攻擊後無法快速恢復，或在正常負載下頻繁當機，信賴性依然不足。 三大支柱必須整體設計、同步評估 ，而非各自為政。 三大支柱的核心角色與相互關係 安全性（Security） 關注如何保護系統資產免於惡意威脅，是可信賴性的防禦基礎。 韌性（Resilience） 則聚焦於系統在遭受攻擊或故障後，能否維持關鍵功能並迅速恢復正常狀態。 可靠性（Reliability） 確保系統在一般操作條件下，持續穩定地提供預期服務，不發生非預期中斷。 三者在 NIST SP 800-160 Vol. 2 的框架中形成閉環：安全性降低威脅發生機率，韌性減少威脅造成的衝擊，可靠性則維持日常運作基線。 任一支柱薄弱，整體可信賴性即告瓦解。 工程團隊應在系統生命週期的每個階段（設計、建置、測試、維運）同步納入三大支柱的評估指標。 💡 重點整理 Trustworthiness 是 NIST SP 800-160 的核心評估維度，代表系統的整體可信賴品質。 安全性 防止威脅發生， 韌性 吸收衝擊並恢復， 可靠性 維持穩定運作。 三大支柱必須 貫穿系統生命週期 ，從需求分析到退役均需納入評估。 單靠資安控制無法達成可信賴性，需同時兼顧 故障容忍與穩定性設計 。 可信賴性不是一次性達成的目標，而是持續工程實踐的結果。 將安全性、韌性與可靠性內建於系統設計 ，而非事後補強，才是 NIST SP 800-160 所倡導的根本精神，也是現代關鍵系統工程的必要路徑。 📚 參考文獻 NIST SP 800-160 Vol. 1 Rev. 1 — Engineering Trustworthy Secure System...

在多因素驗證（MFA）的世界裡， TOTP 與 HOTP 是兩種最主流的一次性密碼規範。兩者同樣基於 HMAC 雜湊與共享對稱金鑰，卻因動態因子的不同，在安全特性與應用場景上各有取捨。 HOTP：計數器驅動的一次性密碼 HOTP（HMAC-Based OTP，RFC 4226） 以一個遞增計數器作為動態因子。每次產生 OTP，計數器加一；伺服器驗證成功後，同步更新自身計數器。由於不依賴時間， 無需裝置與伺服器的時鐘同步 ，離線環境也能正常運作。然而，若使用者多次產生 OTP 卻未驗證，則客戶端與伺服器計數器將產生 失步（Desynchronization） 。規範允許伺服器在一定容差窗口（Look-ahead Window）內向前比對，以補救失步問題。此外，已使用的 OTP 若未被伺服器及時消費，存在重放攻擊風險。 TOTP：時間驅動的一次性密碼 TOTP（Time-Based OTP，RFC 6238） 是 HOTP 的延伸，以當前 Unix 時間戳除以時間步長（預設 30 秒 ）作為計數器。兩端各自獨立計算，毋須通訊即可對齊。時間步長結束後 OTP 自動失效， 抗重放攻擊能力顯著優於 HOTP 。代價是要求客戶端與伺服器的時鐘誤差不超過一個步長；實務上伺服器通常允許前後各一個窗口的容差（±30 秒）。Google Authenticator、Microsoft Authenticator 等主流應用均採用此規範。 import pyotp secret = pyotp.random_base32() totp = pyotp.TOTP(secret) # TOTP（時間驅動） hotp = pyotp.HOTP(secret) # HOTP（計數器驅動） print(totp.now()) # 當前 30 秒內有效的 OTP print(hotp.at(0)) # 計數器為 0 時的 OTP 💡 重點整理：TOTP vs HOTP 動態因子 ：TOTP 用時間步長，HOTP 用遞增計數器。 抗重放攻擊 ：TOTP 的 OTP 30 秒後自動失效，安全性更高。 同步需求 ：TOTP 需時鐘對齊；HOTP 需管理計數器失步問題。 ...

開場引言 當資安事件頻傳， 由上而下的安全策略（Top-down Security Strategy） 成為企業最有效的防線起點。董事會主動定調，讓資安從治理層落地至每一個執行環節。 什麼是 Top-down Security Strategy？ Top-down Security Strategy 指由 董事會、CEO 或 CISO 發起並主導的資安治理模式。高階主管負責定義風險容忍度、核准資安預算，並將政策貫徹至各業務單位。這與「由下而上」的零散修補截然不同，它確保資安優先順序 與企業策略目標一致 ，而非僅由 IT 部門單打獨鬥。此模式的核心在於 責任鏈明確 ：董事會監督、管理層執行、員工遵循，三層架構形成完整的治理閉環。 如何在組織內落地實施？ 實施 Top-down 模式需從 三個層面同步推進 。第一，董事會層級應定期審視資安風險報告，並將資安 KPI 納入企業績效指標。第二，管理層須將資安政策轉化為具體的 部門操作程序（SOP） ，並分配明確的資安負責人（Security Owner）。第三，透過 全員資安意識培訓 確保基層理解並遵循政策。參考框架可採用 NIST CSF 或 ISO 27001，兩者皆提供由治理到操作的完整層級架構，協助組織系統性地對應控制措施。 💡 重點整理 治理優先： 董事會設定風險容忍度，資安策略才具有組織授權。 預算保障： 高階主管核准資安預算，防止資源被業務需求排擠。 責任明確： 每層級指定 Security Owner，避免責任模糊地帶。 框架對齊： 採用 NIST CSF 或 ISO 27001 作為通用語言，統一全組織標準。 結語 資安不能只靠技術團隊獨力支撐。 當董事會真正主導資安治理 ，政策才有執行力，預算才有保障，文化才能真正改變。由上而下，才是組織韌性的根本。 📚 參考文獻 NIST Cybersecurity Framework (CSF) 2.0 — 美國國家標準局官方資安治理框架： https://www.nist.gov/cyberframework ISO/IEC 27001:2022 — 國際資訊安全管理系統標準，涵蓋治理層級要求： https://www.iso...

在多執行緒與並發環境中， time of check to time of use（TOCTOU） 是最容易被忽視卻危害深遠的漏洞類型。攻擊者只需掌握那一瞬間的時間差，就能讓系統執行完全非預期的操作。 什麼是 TOCTOU 競態條件？ TOCTOU 的核心在於「 檢查（Check） 」與「 使用（Use） 」兩個動作之間存在時間窗口。程式先確認某資源的狀態是否符合條件，隨後才對其進行操作；而攻擊者正是在這段窗口期內，悄悄置換或竄改該資源。最典型的案例是檔案系統攻擊：程式用 access() 確認檔案權限後，攻擊者迅速以 符號連結（Symlink） 替換目標路徑，使後續的 open() 實際操作到不同的敏感檔案。此漏洞同樣廣泛出現於身份驗證流程與資料庫事務中。 防禦策略：縮短或消除時間窗口 防禦 TOCTOU 的核心思路是 將「檢查」與「使用」合併為不可分割的原子操作 。在檔案系統層面，應使用 O_NOFOLLOW 旗標避免跟隨符號連結，或改以 檔案描述符（File Descriptor） 取代路徑名稱進行後續操作，確保檢查對象與操作對象為同一實體。在並發程式設計中，應透過 互斥鎖（Mutex） 或資料庫的 SELECT FOR UPDATE 鎖定機制，保障檢查至使用期間資源不被他方修改。從根本上消除窗口，遠比縮短窗口更為可靠。 // ❌ 易受 TOCTOU 攻擊的寫法 if (access("target.txt", W_OK) == 0) { // 檢查 fd = open("target.txt", O_WRONLY); // 使用（窗口在此） } // ✅ 安全寫法：直接開啟並檢查結果 fd = open("target.txt", O_WRONLY | O_NOFOLLOW); if (fd 💡 重點整理 核心成因： 檢查與使用之間的非原子性時間窗口是漏洞根源。 常見場景： 檔案權限驗證、登入流程、並發資料庫讀寫皆為高風險區域。 最佳防禦： 使用原子操作或鎖定機制，讓檢查與使用不可被中斷。 避免路徑操作： 優先使用檔案描述符而非路徑字串，防止 Symlink 攻擊。 TOCTOU 漏...

深入解析 The Sudoers File：Linux 權限管理與最小權限原則實踐指南 在 Linux 系統中， the sudoers file（/etc/sudoers） 是控制特權執行的核心樞紐。錯誤的設定可能導致系統全面淪陷，正確的設定則能精準落實最小權限原則。 Sudoers 檔案的結構與語法 The sudoers file 的每一條規則遵循固定語法： WHO WHERE=(AS_WHOM) WHAT 。 WHO 指定使用者或群組， WHERE 限制主機範圍， AS_WHOM 定義切換身份， WHAT 則列舉允許的指令。此檔案 嚴禁直接用文字編輯器修改 ，必須透過 visudo 指令操作，以確保語法驗證並防止設定錯誤鎖死系統。群組授權使用 %groupname 語法，模組化設定則建議置於 /etc/sudoers.d/ 目錄下分檔管理。 最小權限原則的實踐策略 最小權限原則（Least Privilege） 的核心是：只授予完成任務所需的最低權限。在 sudoers 設定中，應避免無限制的 ALL=(ALL:ALL) ALL 授權，改以 精確指定指令路徑 取代。善用 NOPASSWD 時須特別謹慎，建議搭配 Cmnd_Alias 將允許的指令群組化，提升可維護性。此外， Defaults 區段可設定 logfile 、 timestamp_timeout 等安全參數，強化稽核與會話控制。 # 定義允許的指令別名 Cmnd_Alias WEBOPS = /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx # 授予 deploy 群組僅執行 WEBOPS 指令，且需輸入密碼 %deploy ALL=(root) WEBOPS 💡 重點整理 唯一編輯入口： 永遠使用 visudo 修改，語法錯誤將即時攔截。 精準授權優於通用授權： 以完整指令路徑取代 ALL，縮小攻擊面。 模組化管理： 將不同服務的授權拆分至 /etc/sudoers.d/ ，降低變更風險。 稽核不可少： 啟用 Defaults logfile 記錄所有 sudo 操作，滿足合規要求。 ...

為什麼系統分解是威脅建模的第一步？ 在執行 STRIDE 威脅分析之前， 系統分解（Decomposition） 是不可省略的前置作業。唯有將架構拆解清楚，才能系統性地識別攻擊面，避免遺漏潛在弱點。 五大安全核心概念解析 ① 信任邊界（Trust Boundaries） 定義不同信任等級的分界線，例如外部網路與內部服務之間的邊界。跨越信任邊界的資料流是重點審查對象，攻擊者通常從低信任區滲透至高信任區。 ② 資料流向路徑（Data Flow Paths） 追蹤資料在系統中的完整流動軌跡，包含儲存、傳輸與處理三個環節。每條路徑都是潛在的攔截或竄改目標，應對應至 DFD（資料流程圖）進行可視化分析。 ③ 輸入點（Entry Points） 所有系統對外接受輸入的位置，包含 API 端點、表單、檔案上傳、環境變數等。輸入點是注入攻擊、緩衝區溢位等威脅的主要入口，需完整清查。 ④ 特權操作（Privileged Operations） 需要提升權限才能執行的操作，例如資料庫寫入、系統設定變更、金鑰存取。這類操作若遭濫用，影響範圍最廣，是提權攻擊（Privilege Escalation）的核心目標。 ⑤ 安全態勢細節（Security Profile Details） 包含現有安全控制措施的盤點，例如身份驗證機制、加密配置、日誌記錄範圍。此步驟揭露已知防禦的覆蓋缺口，為後續威脅優先排序提供依據。 💡 重點整理 信任邊界 是識別橫向移動風險的關鍵切入點。 資料流向路徑 需配合 DFD 圖進行視覺化追蹤。 輸入點清查 可直接對應 STRIDE 中的竄改（Tampering）威脅。 安全態勢盤點 幫助團隊快速定位防禦缺口，優化修補優先序。 掌握這五大概念後，威脅建模團隊能夠以結構化方式拆解任何規模的系統。 完整的系統分解不只是技術文件，更是安全溝通的共同語言 ，讓開發、架構與安全三方達成一致認知，有效降低疏漏風險。 📚 參考文獻 Microsoft — Threat Modeling Tool Getting Started ：涵蓋系統分解與 STRIDE 方法論的官方入門指南。 OWASP — Threat Modeling Cheat...

在數位安全領域中， 電磁輻射洩密 是一種常被忽視卻極度危險的攻擊向量。TEMPEST 標準正是為了對抗這類無形威脅而生，是國家級機密保護的核心防線。 什麼是 TEMPEST？電磁洩密的核心威脅 TEMPEST 是 NSA（美國國家安全局）制定的機密標準，全名為「Telecommunications Electronics Material Protected from Emanating Spurious Transmissions」。其核心研究對象是電子設備在正常運作時， 無意間向外輻射的電磁信號（EM Emanations） 。這些信號可能攜帶螢幕畫面、鍵盤輸入或網路封包等敏感資料，被具備特殊設備的攻擊者在數十公尺外截獲還原。著名的 Van Eck Phreaking 攻擊即是利用此原理，從電磁輻射重建 CRT 螢幕影像，驗證了這類威脅的實際可行性。 EMSEC 框架與 TEMPEST 防護等級 TEMPEST 隸屬於更廣泛的 EMSEC（Emanations Security） 框架，專注於控制所有形式的訊號洩漏。NSA 將 TEMPEST 防護設備分為三個等級： Level A（最高） 適用於高威脅戰場環境； Level B 適用於受控機密設施； Level C 適用於低威脅的商業機密場所。對應的防護措施包含法拉第籠屏蔽室（SCIF）、電源線濾波器、設備間距規範（RED/BLACK 隔離原則），以及通過 TEMPEST 認證的硬體設備。 💡 重點整理 EM Emanations 無處不在： 任何通電設備皆會輻射電磁信號，無法完全消除。 RED/BLACK 隔離原則： 明文（RED）與加密（BLACK）電路必須物理分離，防止交叉干擾。 SCIF 是最高等級防護： 法拉第屏蔽機房可阻斷幾乎所有電磁洩漏路徑。 認證硬體不可或缺： 通過 NSA TEMPEST 認證的設備，輻射量符合嚴格的洩漏上限規範。 TEMPEST 與 EMSEC 框架提醒我們，資訊安全的戰場不僅在網路層，更延伸至 物理電磁空間 。對於處理國家機密或高度敏感資料的組織，理解並落實 TEMPEST 防護標準，是不可忽視的安全基礎建設。 📚 參考文獻 NSA/CSS — TEM...

Teardrop 攻擊出現於 1990 年代末期，曾讓無數 Windows 與 Linux 系統直接藍屏崩潰。它的武器只有一樣： 精心錯位的 IP 封包片段 ，足以讓作業系統的重組邏輯徹底失控。 IP 分段重疊：攻擊的核心原理 IP 協定允許將大型封包切割成多個片段（Fragment），透過 Fragment Offset 欄位 標記每個片段在原始資料中的起始位置，接收端再依序重組。Teardrop 的手法是偽造多個片段的 Offset 值，使第二個片段的起始位置落在第一個片段的範圍 之內 ，造成重疊（Overlap）。當系統計算重組長度時，會出現負數或非預期的記憶體寫入範圍，觸發核心層的緩衝區錯誤，最終導致 BSOD（藍屏當機） 或系統掛起。受影響的系統包括 Windows 3.1、95、NT，以及 Linux kernel 2.1.63 以前的版本。 攻擊封包結構解析 一次典型的 Teardrop 攻擊至少發送 兩個惡意片段 。第一個片段 Offset 為 0，長度正常；第二個片段的 Offset 被設為小於第一個片段結尾的值，例如第一片段涵蓋 byte 0–35，第二片段 Offset 卻宣告從 byte 24 開始，實際資料卻只有 4 bytes。重組演算法在計算「需填入的位置」時，會得到 負數長度（Negative Length） ，直接引發核心記憶體操作錯誤。攻擊者可用原始 Socket（Raw Socket）持續大量發送此類封包，即便單次流量極低，仍能穩定觸發崩潰，使防禦難度提升。 # Teardrop 概念示意（Scapy，僅供學術研究） from scapy.all import * # 片段1：offset=0，正常資料 frag1 = IP(dst="目標IP", flags="MF", frag=0) / ("A" * 36) # 片段2：offset 刻意重疊，觸發負數長度計算 frag2 = IP(dst="目標IP", frag=3) / ("B" * 4) send([frag1, frag2]) 💡 重點整理 攻擊核心 ：偽造 Fragment Offset 製造片段重疊，使重組長度為負...