本文目標：精度論文 “CRYLOGGER: Detecting Crypto Misuses Dynamically” 。

針對密碼算法的 API 誤用，本文算是對上一篇 CryptoGuard 的改進版，實現了一個開源的動態和靜態結合的自動檢測工具。該論文發布于 2020 年的 S&P ，點擊即可免費獲取該工具，基準測試工具同 CryptoGuard 使用的論文相同，這里就放 CryptoGuard 實現的基準測試工具鏈接吧！研究就是層層遞進的過程，我們都站在巨人的肩膀上，下一步該向哪兒爬，全在我們一念之間~

一念之間：現在的密碼算法怎么樣了？

對于一個密碼算法來說，能保證系統安全最重要的一點就是保證密鑰的安全。從算法角度上講，要保障系統機密性的話，就得關注加密算法；要保障系統完整性的話，就得關注加密 Hash 函數。

當然，研究這些基礎加密算法的學者有很多，但至今也沒能找到一個完全安全的加密算法。即便能夠確保一個算法完全正確且安全，我們也無法保證這個算法的實現過程毫無漏洞，比如說誤用。

舉個具體的例子?吧：橢圓曲線加密算法的理論似乎很強悍，像我們的身份證就使用了這種算法去做加密，但早在 2012 年，就有學者利用 OpenSSL 的算法 bug 獲取到了橢圓曲線加密算法的完整私鑰。連密鑰都拿到了，系統估計也就沒啥安全性可言了。

拋開算法的理論層面，從上述提到的算法實現上探究，一些伴隨著加密的新問題便顯現了出來。2013 年就有學者調研出：從 Google Play Store 上下載的 88% 個 Android apps 至少有一種加密誤用。具體而言，在保障系統機密性的層面上，一些 apps 使用硬編碼密鑰進行加密，而不是真正的隨機密鑰；在保障系統完整性的層面上，一些 Android apps 的哈希函數可能發生沖突，例如 SHA1 。

近年來，研究者們致力于分析各種情況下的密碼誤用。
① 堆棧溢出獲取的代碼片段不安全。通過堆棧溢出，有研究者獲取了一些 Android apps 98%的代碼片段，并分析發現它們大多存在嚴重的加密問題。
② 應用程序編程接口(API)太過復雜，這是 Java 中加密誤用的主要根源。因為 API 復雜，所以開發人員不得不關注一些低級決策——比如選擇加密算法的填充類型——而不是專注于高級任務。
③ 一些 Python 的加密庫不夠完善。研究者們發現 Python 加密庫的文檔不清不楚、代碼示例不足、API 中默認配置也有誤。
④ 第三方庫不安全。Android 中 90% 的加密誤用源自第三方庫。

解決問題的前提是，要找到問題，所以檢測工具就是這么產生的。由于上一篇的 CryptoGuard 自稱是第一個最好的靜態分析工具，因此，作者大概是讀過 CryptoGuard 之后產生了新的 idea ，立刻反手做了第一個動態檢測工具。接下來，作者從密碼算法的 API 誤用著手，針對一些常量，改進了 CryptoGuard 靜態分析工具。

具體來說，CRYLOGGER 就是在 CryptoGuard 的基礎上做了動態分析方法和靜態分析方法相結合的策略，在線記錄log文件，離線檢測分析，使得整個工具更加完善。下面我們一點一點來分析 CRYLOGGER ~

二念之間：熱門的 “自動檢測”

自動化越來越流行，檢測工具也不例外，在介紹動態 CRYLOGGER 之前，讓我們先談一談熱門的 “自動檢測” 吧！這是設計 CRYLOGGER 工具的關鍵步驟。

一般來說， “自動檢測” 的思想主要是這么兩個方面：（1）定義一組加密規則；（2）通過驗證加密 API 的傳參，檢查 apps 是否遵守了這些規則。

?定規則 （依據）
? 論文里的 加密算法或其錯誤配置 造成的漏洞。
? NIST、IETF 等組織和機構定義的加密相關標準。

可以舉個例子?：① 設置用于加密的最小密鑰大小，例如 RSA 是 2048 位；② 設置用于密鑰推導的最小迭代次數，例如 PKCS#5 是 1000 次。

?守規則
? 靜態方法：主要利用程序切片檢查加密 API 的傳參，例：CrySL、CryptoLint、 CryptoGuard、MalloDroid、 CogniCrypt、CMA等。
優勢：不需執行，代碼全分析，可擴展；
劣勢：誤報。
像上一篇提到的 CryptoGuard 就有很多誤報因素，如分支過早被修剪(大概是上一篇提到的控制裁剪深度問題)、遺漏需動態加載的部分代碼(大概是上一篇提到的幻想庫問題)。
? 動態方法：
優勢：需在運行時觸發加密 API ，少誤報；
劣勢：難以使用，不支持靜態方法的加密規則。

總之，現狀就是探索靜態分析方法的人多，而探索動態分析方法的人少，這也是作者發現的研究缺口。

來看看 CRYLOGGER 怎么運用自動檢測的吧：

還是上面說的兩個方面：定規則、守規則。

1. logger 定規則：擴展 Java 加密庫 ═? 跟蹤(檢測)加密算法的 API 調用 ═? log 文件記錄(存儲)必須用于檢查加密規則的相關參數值。
   例如：上圖中的 logger 保存 apps 代碼的 消息摘要(SHA1) 和 對稱加密(AES) 的算法名;
2. checker 守規則：在線執行后 ═? 離線分析 log 文件 ═? 生成 apps 違規的規則列表。
   需要一組檢查過程，每個檢查過程包含很多加密規則，例如上圖中的(紅色感嘆號)， checker 發現 apps 使用了不安全的 Hash 函數 (SHA1) 作為消息摘要算法。

為什么要分離成上述的兩個過程？
(1) 加密庫的參數穩定，即不太可能添加新參數，就比如說，密鑰推導算法的關鍵參數只是 鹽值(salt) 、密碼(password) 以及 迭代次數；
(2) 加密規則不確定，新規則針對新漏洞，那么當前規則就需要更新，比如 RSA 的最小 key 的大小會有變數；
(3) 加密規則上下文相關，但一些規則可能與該系統的上下文無關；
(4) 在線檢查規則可能會影響性能，而離線不會，這在某些 apps 的關鍵響應上非常重要。

現在我們已經清楚這個工具要從哪里入手了，接下來就把這兩個過程了解得更清楚一點吧！

三念之間：給通用加密庫定規則

先上圖：

圖中指示了經典密碼庫中的七大安全點：(1)消息摘要；(2)對稱加密；(3)非對稱加密；(4)密鑰派生；(5)隨機數生成；(6)密鑰存儲；(7) SSL/TLS/Certif 。

當然，這里僅包含了現存的靜態工具使用的類及其在Java和Android中實現的相應類，它們是誤用情況最嚴重的，但這個庫仍不夠完整。因此，作者加強了規則的可擴展性，使用者可以任意添加其需要的檢測規則。

現在來解釋這個圖的具體含義：

(1)消息摘要 —— 用于檢查數據完整性

【輸入】(任意長)data   ↓Hash函數   ↓【輸出】(固定長)Hash  = 摘要

【重點參數】
alg ：用作Hash函數的算法，例如， SHA1 、 SHA256 。不同的庫支持不同的算法。

(2)對稱加密的分組密碼

【輸入】(固定長)分組數據 = size + (算法定義長短)key   ↓分組加密   ↓【輸出】分組數據  = (加密)密文 or (解密)明文

【重點參數】
alg ：用作加密和解密的算法，例如 AES。
key ：密鑰。
#block ：固定大小的分組數據。
mode ：一些操作模式，用于處理多個分組數據，例如 電子密碼本模式 (ECB) 使得分組數據獨立加解密；密碼分組鏈接模式 (CBC) 使得每個明文分組都與前面的密文分組異或；密碼反饋模式 (CFB) ；輸出反饋模式 (OFB) ；Galois/counter (GCM) 。
iv ：初始化向量，定義第一個需要異或的分組數據。
pad ：用于補足分組大小的填充算法，例如 最后一個分組填充 0 的 ZEROPADDING 、PKCS#5 、 PKCS#7 。

(3)非對稱加密的公鑰加密算法

【發送方】				【發送方】			|	【發送方】				【發送方】   ↓						↑				|		↓						↑		用接收方的公鑰加密		用接收方的私鑰解密	|	用發送方的私鑰簽名		用發送方的公鑰驗簽		   ↓						↑				|		↓						↑		【接收方】				【接收方】			|	【接收方】				【接收方】

【重點參數】
alg ：用于加密的算法，例如 RSA、橢圓曲線(EC)、數字簽名算法(DSA) 。
key ：用到的公私鑰對。
pad ：算法，例如 NOPADDING、PKCS1-v1.5、PSS。

(4)密鑰派生

【輸入】password or passphrase   ↓加 salt    ↓Hash函數   ↓經固定迭代次數   ↓【輸出】密鑰

【重點參數】
pass ：輸入的密碼或密碼短語。
salt ：鹽值，即隨機值。
iter ：用于生成密鑰的固定迭代次數，迭代次數越多，越不易被暴力攻擊。

(5)隨機數生成
本文只假設兩類算法：Secure 和 NotSecure

【重點參數】
alg ：如果生成適合加密的隨機數，則使用 Secure 算法，否則使用 NotSecure 算法。
out ：生成隨機數的字節。
seed ：生成的種子。

(6)密鑰存儲 —— 存儲加密密鑰、證書等敏感內容

【重點參數】
pass ：輸入的密碼或密碼短語。

(7) SSL/TLS/Certif 。

【重點參數】
urlprot ：HTTP 或 HTTPS 連接。
allhost ：驗證是否接受所有的主機名。
allcert ：驗證證書是否可信。
sethost ：SSL/TLS 連接的主機名驗證。

以上便是針對加密算法所需要關注的脆弱點。

?等等，圖中的圓圈還沒介紹?

別急，我們上一”念“中提到過，定規則有兩大依據：論文里的 加密算法或其錯誤配置 造成的漏洞；NIST、IETF 等組織和機構定義的加密相關標準。

作者從論文和 NIST 和 IETF的 官方發布文檔中搜集 CRYLOGGER 應支持的規則，并制成下表。

具體地：

? R-01 不允許 apps 使用不安全的 哈希函數 ，也就是那些可以產生沖突的函數，比如 SHA1 ；

? R-02 禁止使用不安全的對稱加密 算法 ，比如 Blowfish 、 DES 等；

? R-03和R-04 不允許 apps 使用 ECB 、CBC 操作模式 。因為 ECB 將相同的明文加密形式不變，這打破了語義安全的屬性，容易受到攻擊；而 CBC 在 C/S 中易受 padding oracle 攻擊；

? R-05和R-06 限制 密鑰的生成 。對稱加密的密鑰是由 apps 隨機生成的，而非硬編碼常量；密鑰的隨機生成器應安全；

? R-07和R-08 與上一條類似。對稱加密中應使用的 IV ，而非密鑰。作者認為當 IV 與某些操作模式 (如GCM) 匹配時， IV 始終隨機且非常數。作者認為使用 IV 可以加強數據的保密性;

? R-09 不允許 重用 相同的 (密鑰/ IV)對 加密不同的消息。因為重用可預測；

? R-10和R-05 是一樣的，這里針對密鑰生成中使用的 鹽值 ；

? R-11 要求 鹽值足夠大 (≥64位);

? R-12 禁止 重用 相同鹽值，因為它違背了向相應密碼中添加隨機性的目的；

? R-13 密鑰生成算法的 迭代足夠多 ，防暴力攻擊;

? R-14和R-15 不允許使用列入 黑名單的密碼 ，增大密碼破解難度；

? R-16 禁止使用 固定密碼 ;

? R-17 要求 偽隨機數生成器(PRNG) 的 seed 使用隨機值，而非常量值。因為常量 seed 生成的數字序列可預測；

? R-18 不允許 apps 使用未經批準的 PRNG ，比如 java.util.Random ；

? R-19、R-20和R-21 禁止 RSA算法 的某些配置。密鑰應該 ≥2048位 ，加/解密時必須使用不同于 NOPADDING 和 PKCS1-v1.5 的填充算法；

? R-22 禁止使用 HTTP ，要求使用 更安全的 HTTPS ；

? R-23 禁止使用 靜態密碼 存儲密鑰;

? R-24和R-25 要求 正確驗證 主機名和證書，比如不允許接受所有主機名或所有證書；

? R-26 禁止修改 標準主機名驗證器 ，因為修改可能導致不安全的 SSL/TLS 通信。

以上，規則全部闡述完畢。下面開始檢測！

四念之間：檢測詳情 —— 長篇代碼預警！

五念之間：這工具好用不？

六念之間：涉及到的逆向工程

七念之間：還是有局限性的…