OpenSSL FIPS 完整性檢查
據我所知，FIPS 需要一組自檢 (POST) 來驗證允許的加密算法和模組的完整性。
這些測試在執行時執行，因此 OpenSSL 對載入到記憶體中的程式碼執行 HMAC-SHA1，並將其輸出與建構時計算的 HMAC-SHA1 進行比較。
我認為攻擊者可以修改原始碼編譯它，然後兩個雜湊也會匹配。此外，由於 OpenSSL 是開源軟體，因此公開了 HMAC 密鑰。
這裡的保安在哪裡？對 HMAC 密鑰保密？滿足此 FIPS 要求的最常用方法是什麼？
事實上，FIPS 140-2 需要一個模組來驗證自身，而這並沒有安全優勢。
為了使程式碼完整性檢查具有安全優勢，執行驗證的程式碼和它使用的數據（雜湊的雜湊值、MAC 的 MAC 值和密鑰、簽名的公鑰）都需要受到完整性保護（對於 MAC，密鑰也需要受到機密性保護）。由於驗證碼是模組的一部分，因此程式碼完整性驗證不會提供任何安全優勢。它在不破壞模組完整性的假設下保證模組的完整性。
據我所知，這最初是對硬體模組的要求，它必須執行某種自檢，如果模組的物理完整性受到損害，這種自檢通常會失敗。基本上，一種物理篡改檢測機制：確保在打開盒子後密鑰無法使用。這並不能很好地轉化為軟體，但該要求已被保留並已演變為需要密碼學，部分原因是慣性，部分原因是幻想應該做點什麼。
當執行檢查的模組比被檢查的模組受到更好的保護時，完整性（或真實性）檢查很有用。例如，某些設備從 ROM 啟動（如物理 ROM，只能通過完全拆開設備來修改），然後將控制權轉移到可更新的、物理暴露的儲存設備（例如硬碟或快閃記憶體）。如果 ROM 包含簽名驗證碼和根公鑰，並且 ROM 程式碼在將控制權轉移給外部儲存之前驗證了外部儲存的完整性或真實性，則有一個真正的安全優勢：它可以確保設備只會執行受信任的程式碼. 根據您的要求，這稱為安全啟動或受信任啟動。通常有一個安全啟動鏈，從 ROM 到韌體引導載入程序到作業系統引導載入程序到作業系統核心到使用者空間實用程序。該鏈依賴於第一個元素的物理完整性保護，以及將信任擴展到後續元素的密碼學。
適用於特定類型設備（例如 PC、智能手機、智能卡等）的一些安全標準對安全啟動有特定要求。但是 FIPS 140 太通用了。
因此，將 FIPS 140 完整性檢查視為合規要求，而不是安全要求。這是您需要跳過的眾多箍之一。在進行任何動態連結或隨機化之前，擺弄作業系統的低級介面以弄清楚如何讀取記憶體中的程式碼。計算預期的 MAC 值並將其儲存在不屬於驗證的位置（因為無法找到 $ v $ 這樣 $ \mathsf{MAC}(m) = v $ 和 $ v $ 是一個子串 $ m $ ）。安排程式碼的初始化序列，以根據儲存在其旁邊的參考值驗證程式碼的 MAC。這是獲得 FIPS 印章成本的一部分。