Deciphering Malware‘s use of TLS (without Decryption)阅读笔记


前言

本文是关于个人阅读Deciphering Malware’s use of TLS (without Decryption)时的个人阅读笔记,原文点击此处

一、简介

Deciphering Malware’s use of TLS (without Decryption)是Anderson等人于2016年发表的关于采用机器学习进行恶意加密流量检测的论文,该论文以特征提取和特征设计为主要内容,最后将提取的特征分为四个特征子集,然后采用逻辑斯蒂二分类模型和多分类模型进行训练,得到可用于区分恶意加密流量和正常加密流量的二分类器及用于进一步找出恶意加密流量所属恶意软件家族的多分类器。该论文通过对不同特征子集训练所得的分类器进行验证,得出特征设计对于采用机器学习的方法进行恶意加密流量检测的重要性。

二、数据集

数据集包括恶意加密流量和正常加密流量,恶意加密流量是通过沙箱运行恶意软件采集的通过TLS协议加密流量,共含18种恶意软件家族,详见图1。正常加密流量是通过截获公司内部流量所得。由于进行沙箱模拟的操作系统中也有可能额外发出一些加密流量,所以对通过沙箱模拟的恶意流量安装其TLS握手包中采用的密码套件列表是否与操作系统提供的密码套件列表进行进行了筛选。
图1 文章中使用到的18类恶意软件家族

三、特征提取

图2-a 恶意TLS流量(红)与正常TLS流量(蓝)客户端提供的密码套件对比
图2-b 恶意TLS流量(红)与正常TLS流量(蓝)客户端公钥长度对比
图2-c 恶意TLS流量(红)与正常TLS流量(蓝)采用的客户端对比
图2-d 恶意TLS流量(红)与正常TLS流量(蓝)客户端提供的TLS扩展件对比
图2 恶意TLS流量与正常TLS流量客户端提供的密码套件、公钥长度、TLS扩展件、采用的客户端共四种特征数据对比图,其中红色代表恶意加密流量,蓝色代表正常加密流量,且为方便展示已对各密码

图3-a 恶意TLS流量(红)与正常TLS流量(蓝)服务器端选择的密码套件对比
图3-b 恶意TLS流量(红)与正常TLS流量(蓝)证书有效时长对比
图3-c 恶意TLS流量(红)与正常TLS流量(蓝)SAN证书数量对比
图3-d 恶意TLS流量(红)与正常TLS流量(蓝)服务器端采用的TLS扩展件对比
图3 恶意TLS流量与正常TLS流量服务器端采用的密码套件、证书有效时长、SAN证书数量、服务器端选择的TLS扩展件四种特征数据对比图,其中红色代表恶意加密流量,蓝色代表正常加密流量,且为方便展示已对各密码套件和TLS扩展件进行编号
图4 不同恶意软件家族所用的TLS客户端、提供的密码套件、TLS扩展项和客户端公钥长度
图4 不同恶意软件家族所用的TLS客户端、提供的密码套件、TLS扩展项和客户端公钥长度
图5 不同恶意软件家族服务器端特有IP地址、自签证书数量、选择的密码套件及证书类别对比图5 不同恶意软件家族服务器端特有IP地址、自签证书数量、选择的密码套件及证书类别对比

该论文对恶意加密流量与正常加密流量之间及不同恶意软件家族产生的恶意加密流量之间的各方面数据进行了分析,分析结果如图2、3、4、5。最后根据分析结果提取了五种特征,包括Metadata、SPLT、BD、Unencrypted TLS Header Information、SS

Metadata:即加密流量元数据,包括输入数据长度、输出数据长度、输入包数量、输出包数量、源端口、目的端口、流量传播的时长。
SPLT:Sequence of Packet Lengths and Times,即数据包差昂达度和到达间隔时长序列。
BD:Byte distribution,即字节分布,是用于记录字节分布情况且长度为256的数组。
Unencrypted TLS Header Information:即处于握手阶段还未进行加密的TLS协议的头部信息,包括客户端提供的密码套件列表和TLS扩展项、服务端选择的密码套件和TLS扩展项、签名证书、客户端公钥长度、记录的长度和时间和类型序列。
SS:Self-Signed,即TLS协议中使用的证书是否为自签证书(采用SS代表该特征)。

该论文将以上五种特征划分了四个特征子集,特征子集1仅包括Meta、SPLT、BD三种特征,特征子集2仅包括Unencrypted TLS Header Information这一种特征,特征子集3包括Meta、SPLT、BD、Unencrypted TLS Header Information四种特征,特征子集4包括Meta、SPLT、BD、Unencrypted TLS Header Information、SS五种特征。再采用逻辑斯蒂二分类模型和多分类模型分别对以上四个特征子集进行了训练,共获得八个分类器,包括四个二分类器和四个多分类器。二分类器用于区分恶意加密流量和正常加密流量,多分类器用于找出恶意加密流量所属的恶意软件家族。

四、实验结果

实验结果如图6、7,可见包括Meta、SPLT、BD、Unencrypted TLS Header Information、SS五种特征的特征子集4所训练的分类器效果最佳。由五种特征共同训练所得二分类器准确率可达99.6%,多分类器准确率对于多数恶意软件家族可达100%,其余恶意软件家族准确率均在96%以上。同时,仅采用TLS协议中的参数作为特征时,对恶意加密流量与正常加密流量分类的准确率为98.2%,且恶意软件家族Deshacop的分类准确率仅63.6%,由此可见特征设计对于该类方法的重要性。
图6 采用不同特征子集训练二分类器的准确率,All Data指恶意加密流量中含由底层操作系统发出的TLS流量,No SChannel指不含由底层操作系统发出的TLS流量
图6 采用不同特征子集训练二分类器的准确率,All Data指恶意加密流量中含由底层操作系统发出的TLS流量,No SChannel指不含由底层操作系统发出的TLS流量
图7 采用不同特征子集训练多分类器的准确率
图7 采用不同特征子集训练多分类器的准确率

<think>嗯,用户遇到了建行参数解密失败且为空的问题,需要找出解决方案。首先,我需要理解错误信息的具体含义。“ccbParam deciphering fail is null”可能意味着在解密过程中,某个参数的值是空的,或者解密算法出现了问题。接下来,我应该考虑可能的原因,比如参数缺失、加密方式不一致、密钥错误、编码问题或者网络传输中的异常。 根据用户提供的引用内容,特别是引用[2]提到的Java加密和C语言解密的问题,这可能涉及到不同编程语言间加密解密的不兼容性。比如,Java和C可能在实现DES加密时使用不同的填充方式或加密模式,导致解密失败。另外,引用[1]中的URL参数处理可能存在字符串拼接或截断的问题,比如参数顺序、特殊字符处理不当,导致解密时获取的参数不完整或格式错误。 然后,用户需要检查参数是否完整。例如,ORDERID、PAYMENT等参数是否在传输过程中丢失或为空。可以查看日志确认参数是否正确传递。接着,确认加密方式是否一致,比如是否双方都使用相同的算法(如DES、AES)、模式(如ECB、CBC)、填充方式(如PKCS5Padding)以及密钥。例如,Java的DES实现默认使用ECB模式和PKCS5Padding,而C语言可能需要显式设置这些参数,否则会导致解密失败。 编码问题也是一个常见原因。比如,参数在传输过程中可能被错误地编码(如URL编码、Base64),需要确保加密后的数据正确编码,并在解密前进行解码。此外,特殊字符如“&”可能被截断,需要检查参数拼接是否正确,避免使用会干扰参数解析的字符。 密钥管理方面,需要确认双方使用的密钥是否完全一致,包括大小写和特殊字符。同时,网络传输中的异常可能导致参数值被截断或篡改,可以通过日志对比发送和接收的参数值是否一致。 调试建议包括分步验证加密解密流程,使用相同的测试数据在双方环境中测试,确保加解密结果一致。另外,查看解密函数的错误处理,确认是否有异常被捕获但未正确抛出,导致返回空值。 如果以上步骤无法解决,可能需要联系建行技术支持,确认接口文档中的加密要求是否有更新,或者是否存在服务器端的问题。例如,引用[3]中提到的预训练数据对模型的影响,虽然不直接相关,但提醒我们需要确保使用的加密方法和数据符合最新的规范。 总结解决方案步骤:检查参数完整性→核对加密配置→处理编码问题→验证密钥→排查传输问题→分步调试→联系技术支持。同时,用户可能需要参考建行的官方文档或技术支持提供的示例代码,确保加密解密实现符合规范。</think>### 建行参数解密失败且为空问题解决方案 #### 问题分析 错误提示`ccbParam deciphering fail is null`表明以下可能性: 1. **参数缺失或为空**:关键参数未正确传递或解密后为空值。 2. **加密方式不一致**:加密/解密算法、模式或填充方式不匹配[^2]。 3. **编码问题**:参数传输时编码格式(如Base64、URL编码)未正确处理。 4. **密钥错误**:双方使用的密钥不一致或格式错误。 --- #### 分步解决方案 ##### 1. **检查参数完整性** - **验证参数列表**:确认接收的`ORDERID`、`PAYMENT`、`CURCODE`等参数是否完整且非空。 - **日志追踪**:记录请求原始数据,对比建行接口文档的参数要求,例如: ```python # 示例:Python中打印接收参数 print("Received params:", this.Request) ``` - **特殊字符处理**:检查参数是否包含`&`或`=`等符号导致截断,需使用URL编码转义[^1]。 ##### 2. **核对加密配置** - **算法一致性**:确认双方使用相同的加密算法(如DES、AES)、模式(如ECB、CBC)和填充方式(如PKCS5Padding)。 - *Java与C语言差异*:Java默认使用`DES/ECB/PKCS5Padding`,而C需手动配置[^2]。 - **密钥验证**:检查密钥长度和内容是否完全一致(包括大小写、特殊字符)。 ##### 3. 处理编码问题 - **Base64编码**:若加密数据通过Base64传输,需在解密前先解码: ```java // Java示例:Base64解码 byte[] encryptedData = Base64.getDecoder().decode(encryptedString); ``` - **字符集统一**:确保加密/解密双方使用相同字符集(如UTF-8)。 ##### 4. 验证密钥与数据流 - **密钥硬编码测试**:临时使用固定密钥测试,排除动态生成错误。 - **数据流对比**: - 加密端输出密文的Hex/Bytes格式。 - 解密端输入前打印密文,确认两者一致。 ##### 5. 排查网络传输问题 - **参数截断**:检查接收参数的字符串长度是否与发送端一致。 - **HTTPS干扰**:部分代理可能修改参数,需关闭代理调试。 ##### 6. 分步调试解密函数 ```java // Java示例:解密函数调试 public static String decrypt(String data, String key) { try { Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding"); cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key.getBytes(), "DES")); return new String(cipher.doFinal(Base64.getDecoder().decode(data))); } catch (Exception e) { e.printStackTrace(); // 打印具体异常信息 return null; } } ``` - 若返回`null`,检查`doFinal`输入的密文是否有效。 ##### 7. 联系建行技术支持 - **接口文档**:确认加密要求是否有更新(如算法升级为AES)。 - **错误码查询**:提供`SUCCESS`字段和交易流水号(`ORDERID`)请求建行排查。 --- #### 相关问题§§ 1. 如何在不同编程语言间实现兼容的DES加密解密? 2. HTTPS传输中如何处理特殊字符避免参数丢失? 3. 建行支付接口常见错误码有哪些及解决方案? --- #### 引用说明 - 加解密算法需严格对齐参数,如Java与C的库实现差异可能导致失败。 - URL参数拼接时需注意符号转义,避免截断问题[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值