本文目標(biāo)：精度論文 “CRYLOGGER: Detecting Crypto Misuses Dynamically” 。

針對(duì)密碼算法的 API 誤用，本文算是對(duì)上一篇 CryptoGuard 的改進(jìn)版，實(shí)現(xiàn)了一個(gè)開(kāi)源的動(dòng)態(tài)和靜態(tài)結(jié)合的自動(dòng)檢測(cè)工具。該論文發(fā)布于 2020 年的 S&P ，點(diǎn)擊即可免費(fèi)獲取該工具，基準(zhǔn)測(cè)試工具同 CryptoGuard 使用的論文相同，這里就放 CryptoGuard 實(shí)現(xiàn)的基準(zhǔn)測(cè)試工具鏈接吧！研究就是層層遞進(jìn)的過(guò)程，我們都站在巨人的肩膀上，下一步該向哪兒爬，全在我們一念之間~

一念之間：現(xiàn)在的密碼算法怎么樣了？

對(duì)于一個(gè)密碼算法來(lái)說(shuō)，能保證系統(tǒng)安全最重要的一點(diǎn)就是保證密鑰的安全。從算法角度上講，要保障系統(tǒng)機(jī)密性的話(huà)，就得關(guān)注加密算法；要保障系統(tǒng)完整性的話(huà)，就得關(guān)注加密 Hash 函數(shù)。

當(dāng)然，研究這些基礎(chǔ)加密算法的學(xué)者有很多，但至今也沒(méi)能找到一個(gè)完全安全的加密算法。即便能夠確保一個(gè)算法完全正確且安全，我們也無(wú)法保證這個(gè)算法的實(shí)現(xiàn)過(guò)程毫無(wú)漏洞，比如說(shuō)誤用。

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

拋開(kāi)算法的理論層面，從上述提到的算法實(shí)現(xiàn)上探究，一些伴隨著加密的新問(wèn)題便顯現(xiàn)了出來(lái)。2013 年就有學(xué)者調(diào)研出：從 Google Play Store 上下載的 88% 個(gè) Android apps 至少有一種加密誤用。具體而言，在保障系統(tǒng)機(jī)密性的層面上，一些 apps 使用硬編碼密鑰進(jìn)行加密，而不是真正的隨機(jī)密鑰；在保障系統(tǒng)完整性的層面上，一些 Android apps 的哈希函數(shù)可能發(fā)生沖突，例如 SHA1 。

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

解決問(wèn)題的前提是，要找到問(wèn)題，所以檢測(cè)工具就是這么產(chǎn)生的。由于上一篇的 CryptoGuard 自稱(chēng)是第一個(gè)最好的靜態(tài)分析工具，因此，作者大概是讀過(guò) CryptoGuard 之后產(chǎn)生了新的 idea ，立刻反手做了第一個(gè)動(dòng)態(tài)檢測(cè)工具。接下來(lái)，作者從密碼算法的 API 誤用著手，針對(duì)一些常量，改進(jìn)了 CryptoGuard 靜態(tài)分析工具。

具體來(lái)說(shuō)，CRYLOGGER 就是在 CryptoGuard 的基礎(chǔ)上做了動(dòng)態(tài)分析方法和靜態(tài)分析方法相結(jié)合的策略，在線(xiàn)記錄log文件，離線(xiàn)檢測(cè)分析，使得整個(gè)工具更加完善。下面我們一點(diǎn)一點(diǎn)來(lái)分析 CRYLOGGER ~

二念之間：熱門(mén)的 “自動(dòng)檢測(cè)”

自動(dòng)化越來(lái)越流行，檢測(cè)工具也不例外，在介紹動(dòng)態(tài) CRYLOGGER 之前，讓我們先談一談熱門(mén)的 “自動(dòng)檢測(cè)” 吧！這是設(shè)計(jì) CRYLOGGER 工具的關(guān)鍵步驟。

一般來(lái)說(shuō)， “自動(dòng)檢測(cè)” 的思想主要是這么兩個(gè)方面：（1）定義一組加密規(guī)則；（2）通過(guò)驗(yàn)證加密 API 的傳參，檢查 apps 是否遵守了這些規(guī)則。

?定規(guī)則 （依據(jù)）
? 論文里的 加密算法或其錯(cuò)誤配置 造成的漏洞。
? NIST、IETF 等組織和機(jī)構(gòu)定義的加密相關(guān)標(biāo)準(zhǔn)。

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

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

總之，現(xiàn)狀就是探索靜態(tài)分析方法的人多，而探索動(dòng)態(tài)分析方法的人少，這也是作者發(fā)現(xiàn)的研究缺口。

來(lái)看看 CRYLOGGER 怎么運(yùn)用自動(dòng)檢測(cè)的吧：

還是上面說(shuō)的兩個(gè)方面：定規(guī)則、守規(guī)則。

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

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

現(xiàn)在我們已經(jīng)清楚這個(gè)工具要從哪里入手了，接下來(lái)就把這兩個(gè)過(guò)程了解得更清楚一點(diǎn)吧！

三念之間：給通用加密庫(kù)定規(guī)則

先上圖：

圖中指示了經(jīng)典密碼庫(kù)中的七大安全點(diǎn)：(1)消息摘要；(2)對(duì)稱(chēng)加密；(3)非對(duì)稱(chēng)加密；(4)密鑰派生；(5)隨機(jī)數(shù)生成；(6)密鑰存儲(chǔ)；(7) SSL/TLS/Certif 。

當(dāng)然，這里僅包含了現(xiàn)存的靜態(tài)工具使用的類(lèi)及其在Java和Android中實(shí)現(xiàn)的相應(yīng)類(lèi)，它們是誤用情況最嚴(yán)重的，但這個(gè)庫(kù)仍不夠完整。因此，作者加強(qiáng)了規(guī)則的可擴(kuò)展性，使用者可以任意添加其需要的檢測(cè)規(guī)則。

現(xiàn)在來(lái)解釋這個(gè)圖的具體含義：

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

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

【重點(diǎn)參數(shù)】
alg ：用作Hash函數(shù)的算法，例如， SHA1 、 SHA256 。不同的庫(kù)支持不同的算法。

(2)對(duì)稱(chēng)加密的分組密碼

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

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

(3)非對(duì)稱(chēng)加密的公鑰加密算法

【發(fā)送方】				【發(fā)送方】			|	【發(fā)送方】				【發(fā)送方】   ↓						↑				|		↓						↑		用接收方的公鑰加密		用接收方的私鑰解密	|	用發(fā)送方的私鑰簽名		用發(fā)送方的公鑰驗(yàn)簽		   ↓						↑				|		↓						↑		【接收方】				【接收方】			|	【接收方】				【接收方】

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

(4)密鑰派生

【輸入】password or passphrase   ↓加 salt    ↓Hash函數(shù)   ↓經(jīng)固定迭代次數(shù)   ↓【輸出】密鑰

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

(5)隨機(jī)數(shù)生成
本文只假設(shè)兩類(lèi)算法：Secure 和 NotSecure

【重點(diǎn)參數(shù)】
alg ：如果生成適合加密的隨機(jī)數(shù)，則使用 Secure 算法，否則使用 NotSecure 算法。
out ：生成隨機(jī)數(shù)的字節(jié)。
seed ：生成的種子。

(6)密鑰存儲(chǔ) —— 存儲(chǔ)加密密鑰、證書(shū)等敏感內(nèi)容

【重點(diǎn)參數(shù)】
pass ：輸入的密碼或密碼短語(yǔ)。

(7) SSL/TLS/Certif 。

【重點(diǎn)參數(shù)】
urlprot ：HTTP 或 HTTPS 連接。
allhost ：驗(yàn)證是否接受所有的主機(jī)名。
allcert ：驗(yàn)證證書(shū)是否可信。
sethost ：SSL/TLS 連接的主機(jī)名驗(yàn)證。

以上便是針對(duì)加密算法所需要關(guān)注的脆弱點(diǎn)。

?等等，圖中的圓圈還沒(méi)介紹?

別急，我們上一”念“中提到過(guò)，定規(guī)則有兩大依據(jù)：論文里的 加密算法或其錯(cuò)誤配置 造成的漏洞；NIST、IETF 等組織和機(jī)構(gòu)定義的加密相關(guān)標(biāo)準(zhǔn)。

作者從論文和 NIST 和 IETF的 官方發(fā)布文檔中搜集 CRYLOGGER 應(yīng)支持的規(guī)則，并制成下表。

具體地：

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

? R-02 禁止使用不安全的對(duì)稱(chēng)加密 算法 ，比如 Blowfish 、 DES 等；

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

? R-05和R-06 限制 密鑰的生成 。對(duì)稱(chēng)加密的密鑰是由 apps 隨機(jī)生成的，而非硬編碼常量；密鑰的隨機(jī)生成器應(yīng)安全；

? R-07和R-08 與上一條類(lèi)似。對(duì)稱(chēng)加密中應(yīng)使用的 IV ，而非密鑰。作者認(rèn)為當(dāng) IV 與某些操作模式 (如GCM) 匹配時(shí)， IV 始終隨機(jī)且非常數(shù)。作者認(rèn)為使用 IV 可以加強(qiáng)數(shù)據(jù)的保密性;

? R-09 不允許 重用 相同的 (密鑰/ IV)對(duì) 加密不同的消息。因?yàn)橹赜每深A(yù)測(cè)；

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

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

? R-12 禁止 重用 相同鹽值，因?yàn)樗`背了向相應(yīng)密碼中添加隨機(jī)性的目的；

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

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

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

? R-17 要求 偽隨機(jī)數(shù)生成器(PRNG) 的 seed 使用隨機(jī)值，而非常量值。因?yàn)槌Ａ?seed 生成的數(shù)字序列可預(yù)測(cè)；

? R-18 不允許 apps 使用未經(jīng)批準(zhǔn)的 PRNG ，比如 java.util.Random ；

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

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

? R-23 禁止使用 靜態(tài)密碼 存儲(chǔ)密鑰;

? R-24和R-25 要求 正確驗(yàn)證 主機(jī)名和證書(shū)，比如不允許接受所有主機(jī)名或所有證書(shū)；

? R-26 禁止修改 標(biāo)準(zhǔn)主機(jī)名驗(yàn)證器 ，因?yàn)樾薷目赡軐?dǎo)致不安全的 SSL/TLS 通信。

以上，規(guī)則全部闡述完畢。下面開(kāi)始檢測(cè)！

四念之間：檢測(cè)詳情 —— 長(zhǎng)篇代碼預(yù)警！

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

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

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