三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

从CTF实战看密钥安全：Diffie-Hellman弱随机数漏洞分析与防御

发布时间：2026/8/15 11:19:27 三亩地 编程学习日记
从CTF实战看密钥安全：Diffie-Hellman弱随机数漏洞分析与防御

1. 从一道CTF题看现代密码学实战：BSidesSF 2020 decrypto-2深度复盘

最近在整理历年CTF比赛的密码学题目时，我又翻出了BSidesSF 2020的这道decrypto-2。这道题在当年算是一个小热点，它没有用那些花里胡哨的复杂密码体系，而是把焦点放在了现代密码学中一个非常基础但又至关重要的环节上——密钥的生成与管理。很多刚入门密码学的朋友，包括当年的我，都容易把注意力全放在加密算法本身，比如AES的轮函数、RSA的大数分解，却忽略了“密钥”这个看似简单、实则暗藏玄机的核心要素。decrypto-2这道题，恰恰就是用一个精巧的设计，给我们上了一堂生动的“密钥安全”实践课。它模拟了一个看似标准的加密通信场景，但最终的突破口却落在了密钥派生过程中一个极易被忽视的细节上。今天，我就带大家完整复盘这道题的解题思路，不仅是为了解出这道题，更是为了深入理解在实际开发和渗透测试中，我们应该如何审视和审计密钥相关的安全实现。

2. 题目场景还原与初步分析：一个标准的加密通信模型

首先，我们得把题目给的场景还原出来。通常，这类题目会提供一个网络服务地址、一个端口，或者直接给出一段通信的流量数据包（pcap文件）以及服务端的源代码片段。对于decrypto-2，根据BSidesSF比赛的一贯风格，它很可能提供了一个可以连接的TCP服务。连接上去之后，服务端会模拟一个简单的加密通信协议。

2.1 协议交互流程拆解

典型的交互流程是这样的：

  1. 客户端连接：我们使用netcat或编写脚本连接到目标服务器。
  2. 服务端问候与参数传递：服务端首先会发送一段欢迎信息，并很可能附带一些加密所需的公共参数。例如，如果使用的是基于Diffie-Hellman的密钥交换，那么这里会发送素数p和生成元g。
  3. 密钥协商阶段：客户端和服务端根据协议交换必要的消息，最终各自计算出一个共享的“会话密钥”。这是后续加密通信的基础。
  4. 标志（Flag）传输：服务端使用协商出的会话密钥，加密真正的目标——也就是比赛的Flag，然后将密文发送给客户端。
  5. 挑战：我们的任务就是解密这段密文，拿到Flag。

题目名称decrypto-2暗示这是解密挑战，且很可能有一个decrypto-1作为前置引导题。-2通常意味着难度增加，可能引入了更多的混淆或更隐蔽的漏洞点。

2.2 初始思路与常见陷阱

面对这样一个场景，一个常规的解题思路是：

  1. 理解加密算法：首先通过分析服务端代码（如果提供）或逆向工程客户端程序，确定使用了哪种对称加密算法（如AES、DES）或流密码。
  2. 分析密钥交换：重点分析密钥是如何生成的。是静态硬编码？还是通过某种密钥交换协议动态生成？动态生成的话，随机数质量如何？
  3. 寻找漏洞：在算法实现或参数使用中寻找漏洞。例如：
    • 弱随机数：密钥或随机数IV（初始化向量）的生成使用了可预测的伪随机数生成器，如rand()函数（在没有正确设置种子的情况下）。
    • 密钥派生函数（KDF）误用：从共享秘密（如Diffie-Hellman交换的结果）派生密钥时，使用了不安全的哈希函数或省略了必要的步骤。
    • 算法配置错误：例如使用ECB模式、弱IV（如全零）、或过短的密钥长度。
    • 侧信道或数学漏洞：在某些特定算法（如RSA、ElGamal）中，参数选择不当可能导致数学上的攻击。

对于decrypto-2，许多队伍一开始可能会直奔加密算法本身，试图寻找算法实现上的缓冲区溢出或逻辑错误。但根据这道题在社区中的讨论热度来看，它的关键点并不在算法实现，而在于密钥派生过程的一个“一致性”问题。

3. 核心漏洞定位：密钥派生过程中的“非随机”熵源

经过对题目附件（通常是server.py或challenge.py）的仔细审计，问题的核心逐渐浮出水面。漏洞出现在从共享秘密到最终加密密钥的转换步骤中。

让我们构建一个简化的漏洞模型。假设服务端代码中密钥派生的部分如下所示（这是基于常见漏洞模式的还原）：

import hashlib import os # 假设通过DH交换，客户端和服务端计算出了相同的共享秘密 shared_secret # shared_secret 是一个大整数 def derive_key(shared_secret): # 将共享秘密转换为字节串 secret_bytes = shared_secret.to_bytes((shared_secret.bit_length() + 7) // 8, 'big') # 使用哈希函数派生密钥 # 注意：这里直接使用了共享秘密的字节表示，没有添加任何随机盐（salt）或上下文信息 key = hashlib.sha256(secret_bytes).digest() return key

这段代码看起来没什么问题，它使用了密码学安全的哈希函数SHA-256。然而，问题可能出在shared_secret的来源上。

3.1 漏洞根因：可预测或弱熵的Diffie-Hellman参数

在标准的、安全的Diffie-Hellman（DH）密钥交换中：

  1. 双方协商一个大素数p和一个生成元g。
  2. 各方各自生成一个随机的大私钥（例如，客户端的私钥a，服务端的私钥b）。
  3. 各方计算并交换公钥：g^a mod p和g^b mod p。
  4. 各方利用对方的公钥和自己的私钥计算共享秘密：(g^b)^a mod p = g^(ab) mod p。

安全的核心在于私钥a和b必须是随机且不可预测的。如果其中一方的私钥不是随机生成的，或者生成随机数的熵源不足（例如，使用了当前时间戳、进程ID等低熵值作为“随机数”），那么共享秘密就可能被攻击者推算或穷举。

在decrypto-2的设定中，经过代码审计，发现服务端在生成自己的DH私钥b时，使用了一个固定的值，或者一个基于简单时间戳、连接数等可预测变量计算出的值，而不是一个密码学安全的随机数。

例如，可能存在的错误代码：

# 错误示例：使用固定值或低熵源 server_private_key = 12345 # 固定值，灾难！ # 或 server_private_key = int(time.time()) % 10000 # 基于时间戳，可预测！ # 或 server_private_key = os.getpid() # 进程ID，范围有限且可猜测！

3.2 为什么这会成为漏洞？

因为DH交换中，p,g, 以及服务端的公钥g^b mod p是公开的（会在通信开始时发送给客户端）。如果攻击者（我们）能够猜测或穷举出服务端的私钥b，那么我们就可以：

  1. 利用公开的p和g。
  2. 利用服务端发来的公钥B = g^b mod p。
  3. 对我们猜测的每一个可能的b_candidate，计算B_candidate = g^(b_candidate) mod p。
  4. 比较B_candidate是否等于服务端发来的真实公钥B。如果相等，则我们找到了正确的b。
  5. 一旦获得b，我们就可以用客户端发来的公钥A = g^a mod p（这在网络流量中也能捕获到）计算出真正的共享秘密：shared_secret = A^b mod p = g^(ab) mod p。
  6. 使用与服务器完全相同的密钥派生函数derive_key，计算出最终的会话密钥。
  7. 用这个密钥解密服务端发送的Flag密文。

由于服务端私钥b的熵非常低（可能只有几万或几十万种可能性），在现代计算机上，穷举攻击在几秒甚至几毫秒内就能完成。这使得整个加密体系形同虚设。

4. 完整攻击链路的实战复现

理解了原理，我们来一步步还原攻击过程。假设我们拿到了题目的流量包capture.pcap和服务器源码server.py。

4.1 第一步：信息收集与参数提取

首先，分析server.py，找到以下关键信息：

  1. 使用的密码学库和函数：确认是自定义实现还是使用了cryptography、PyCrypto等库。
  2. DH参数：找到素数p和生成元g的值。它们通常是硬编码在代码里的十六进制或十进制大数。
  3. 密钥派生函数：精确找到derive_key函数的实现，确认哈希算法（如SHA256）以及是否有加盐等操作。
  4. 加密算法：确认最终使用什么算法加密Flag（如AES-256-CBC）。同时记录IV（初始化向量）的生成方式或获取位置（IV可能随密文一起发送）。

接着，用Wireshark打开capture.pcap，过滤出TCP流，追踪完整的通信过程。我们需要从中提取：

  • 服务端发送的DH公钥B（可能被编码为Base64或十六进制）。
  • 客户端发送的DH公钥A。
  • 服务端发送的Flag密文ciphertext和 IV（如果适用）。

4.2 第二步：分析私钥生成漏洞

回到server.py，重点审查服务端私钥b的生成代码。这才是本题的“题眼”。例如，我们可能发现如下代码：

def generate_private_key(): # 模拟一个低熵生成：使用连接计数器的平方，再取模一个不大的数 global connection_counter connection_counter += 1 return (connection_counter ** 2) % 31337

或者更隐蔽的，使用了random.randint(0, 1000)，但随机数种子被固定了：

import random random.seed(2020) # BSidesSF 2020 的年份被用作种子！ server_private_key = random.randint(0, 10000)

关键点：一旦确定私钥的生成空间很小（比如小于100万），或者生成逻辑可预测，那么穷举攻击就变得可行。

4.3 第三步：编写穷举脚本

我们需要编写一个脚本，模拟攻击者的视角。这个脚本的逻辑如下：

import hashlib from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import base64 # 从server.py和pcap中提取的已知参数 p = 0xabcdef... # 大素数p g = 2 # 常见的生成元 B_server = 0x123456... # 服务端的公钥 A_client = 0x789abc... # 客户端的公钥 ciphertext_b64 = "..." iv_b64 = "..." # 从server.py中复制的密钥派生函数 def derive_key(shared_secret_int): secret_bytes = shared_secret_int.to_bytes((shared_secret_int.bit_length() + 7) // 8, 'big') return hashlib.sha256(secret_bytes).digest() # 返回32字节的AES-256密钥 # 穷举服务端私钥 b 的可能范围 # 根据对漏洞的分析，这个范围可能很小 for b_candidate in range(1, 1000000): # 假设私钥范围在1到100万之间 # 计算候选公钥 B_candidate = pow(g, b_candidate, p) if B_candidate == B_server: print(f"[+] Found server private key b = {b_candidate}") # 计算共享秘密 shared_secret = pow(A_client, b_candidate, p) # 派生密钥 key = derive_key(shared_secret) # 解密Flag ciphertext = base64.b64decode(ciphertext_b64) iv = base64.b64decode(iv_b64) cipher = AES.new(key, AES.MODE_CBC, iv) try: # 尝试解密，使用PKCS7填充 plaintext = unpad(cipher.decrypt(ciphertext), AES.block_size) if plaintext.startswith(b"CTF{") or plaintext.startswith(b"flag{"): # 常见Flag格式 print(f"[+] Flag found: {plaintext.decode()}") break except (ValueError, KeyError): # 解密失败或填充错误，继续尝试 continue print("[*] Exhaustive search finished.")

4.4 第四步：执行与获取Flag

运行脚本，由于私钥空间很小，程序通常会在很短时间内（几秒内）找到正确的b_candidate，计算出共享秘密和密钥，并成功解密出Flag。Flag的内容通常是一个符合CTF格式的字符串，如CTF{weak_dh_parameters_are_bad}或flag{crypto_is_easy_when_you_make_mistakes}。

5. 从CTF到实战：密钥安全的设计原则与审计要点

解出这道题固然令人兴奋，但它的价值更在于其警示意义。decrypto-2模拟的正是现实世界中因密钥管理不当而导致系统被攻破的典型案例。

5.1 密钥生成的安全准则

  1. 使用密码学安全的随机数生成器（CSPRNG）：在任何安全相关的场景中生成随机数（密钥、Nonce、盐值、IV等），必须使用操作系统提供的密码学安全随机源。

    • Python：使用os.urandom()或secrets模块（Python 3.6+），绝对不要使用random模块。
    • Linux/Unix：使用/dev/urandom。
    • 其他语言：使用标准库中的安全接口，如Java的SecureRandom，Go的crypto/rand。

  2. 确保足够的熵：密钥空间必须足够大，使得暴力破解在计算上不可行。例如，AES-128的密钥是128位，这意味着有2^128种可能，是安全的。而像题目中仅用几万种可能性的“密钥”，是绝对致命的。

  3. 为密钥派生引入随机盐（Salt）：在从共享秘密（或密码）派生密钥时，必须使用一个随机生成的、唯一的盐值。盐值不需要保密，但必须随机且唯一。这可以防止彩虹表攻击，并确保即使共享秘密相同，派生出的密钥也不同。安全的密钥派生应使用PBKDF2、Scrypt或Argon2等专门的密钥派生函数（KDF）。

    # 正确示例：使用带盐的KDF import os, hashlib salt = os.urandom(16) # 随机盐 # 使用HMAC或专门的KDF库，这里用HKDF简化示意 key = hashlib.pbkdf2_hmac('sha256', shared_secret_bytes, salt, 100000)

5.2 代码审计时的关注点

在进行安全审计或代码Review时，对于涉及密码学的部分，应像解这道CTF题一样，带着怀疑的眼光去审视：

  1. 搜索随机数生成：在代码库中全局搜索random、rand、srand等关键字。检查它们是否被用于生成密钥、IV、Nonce或盐值。
  2. 审查密钥派生逻辑：找到所有生成密钥的函数。检查是否使用了简单的哈希（如sha256(secret)），而没有加盐或迭代。优先寻找是否使用了标准的、经过验证的KDF。
  3. 检查硬编码凭证：搜索代码中是否直接硬编码了密钥、密码等敏感信息。
  4. 验证算法和模式：确认使用的加密算法（如AES）和模式（如GCM、CBC）是否是当前推荐的安全选项。警惕ECB模式或CBC模式中使用固定IV。
  5. 分析密钥交换协议：如果使用了自定义的密钥交换协议，必须仔细审查其数学正确性和安全性证明。尽量使用标准化的协议（如TLS、Signal协议）。

decrypto-2这道题就像一记警钟，它提醒我们，在密码学应用中，算法本身往往不是最薄弱的环节，密钥的生命周期管理——生成、存储、交换、使用和销毁——才是安全链条上最容易出问题的一环。一个在别处坚不可摧的AES-256算法，如果搭配了一个用时间戳生成的密钥，其安全性便瞬间归零。在实际开发中，务必使用经过严格审计的密码学库（如Python的cryptography），并遵循其官方文档和最佳实践，避免自己动手实现核心的密码学逻辑，这才是规避此类风险的根本之道。

编程学习 学习日记 实战经验
← 返回列表