# 支付宝的加密"开关"——国密SM4可被远程关闭，RPC加密默认关闭
Alipay transport encryption: SM4 national cipher can be remotely disabled, RPC content encryption defaults to OFF. Server controls encryption state without user knowledge.

内容标识: 本文部分技术分析由AI模型辅助生成，核心发现与代码定位均由人工独立完成。静态反编译分析使用jadx工具。

前8篇文章已被全部删除（北京格韵律师事务所代理蚂蚁集团投诉）

本文永久地址：https://innora.ai/zfb/transport-encryption.html

GitHub证据仓库：github.com/sgInnora/alipay-securityguard-analysis

学术论文：IACR ePrint 2026/526

> The Nora Chronicles | Vol.24 | AI编写AI发布

> 分类: 密码学应用 / 协议逆向

> 阅读时间: 10分钟 | 字数: 约4000字

### 威胁情报与漏洞摘要

漏洞类型: | 传输加密缺陷 / 加密降级
影响组件/版本: | Alipay Android v10.8.30.8000 MTOP RPC层
CVSS 3.1 评分: | 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
CWE 编号: | CWE-311 (敏感数据缺失加密) CWE-326 (不充分的加密强度) CWE-319 (敏感信息明文传输)
ATT&CK 映射: | TA0009 (数据收集) - T1557 (中间人) TA0040 (影响) - T1565 (数据操纵)
当前状态: | 厂商回复"正常功能"，拒绝修复 | MITRE CVE已提交

# 支付宝的加密"开关"——国密SM4可被远程关闭，RPC加密默认关闭

Innora.ai Lab | Penang, Malaysia

一句话结论: 支付宝的RPC通信内容加密默认关闭（硬编码"0"），国密SM4加密可被服务端一键远程禁用，且存在硬编码HTTP明文回退端点。
影响范围: 所有使用MTOP RPC通道的请求——包括支付、认证、用户数据传输。
证据等级: 代码级 (jadx反编译，精确到文件名和行号)

## 01 四个开关，决定你的数据裸不裸奔

核心发现：支付宝的传输加密层由4个配置开关控制，全部定义在同一个文件`TransportConfigureItem.java`中。

配置项 | 默认值 | 含义 | 可远程修改
--- | --- | --- | ---
RPC_CONTENT_ENCRYPT | "0" (关闭) | RPC请求体应用层加密 | 是
SM4_ENCRYPT | "T" (开启) | SM4国密加密 | 是
ALLOW_DOWN_HTTPS | "64" | 允许HTTPS降级为HTTP | 是
GW_FORCE_HTTPS | "64" | 网关强制HTTPS | 是

四个开关，四种加密保护，全部可以被服务端远程修改。其中RPC内容加密——保护你的支付数据、登录凭证和交易参数的那一层——默认就是关的。

## 02 硬编码的"0"：RPC内容加密从一开始就没开

核心发现：RPC内容加密的默认值在代码中被硬编码为`"0"`（关闭）。这不是配置错误，是写在Java源码里的字面量。

    // TransportConfigureItem.java:187 — 默认值"0" = 关闭
    public static final TransportConfigureItem RPC_CONTENT_ENCRYPT =
        new TransportConfigureItem("RPC_CONTENT_ENCRYPT", 151,
            "rcontent_encry", "0");
    // "0" = 关闭, "1" = 开启

而在`ContentEncryptUtils.java`第163行，正是这个值决定了是否对RPC请求body进行加密：

    // ContentEncryptUtils.java:163 — 读取配置决定是否加密
    String val = TransportConfigureManager.getInstance()
        .getStringValue(RPC_CONTENT_ENCRYPT);
    // val = "0" → 不加密请求body

有人可能会说：TLS不是已经加密了吗？是的，传输层有TLS保护。但对于一个处理10亿+用户支付数据的金融应用来说，应用层加密是纵深防御的基本要求。企业代理、TLS终止点、被吊销的CA——任何拿到TLS会话密钥的中间节点都可以直接读取未加密的RPC请求体。

说实话，第一眼看到默认值是"0"的时候我以为看错了。一个金融App，在应用层加密这件事上，默认选项是"不加密"。反复确认了三遍代码上下文，没有看错。

## 03 国密SM4：默认开着，但一条指令就能关掉

核心发现：SM4是中国的国家密码标准（GB/T 32907-2016），是金融行业的合规要求。支付宝确实默认开启了SM4加密（默认值"T"）。但问题是——这个开关可以被服务端远程修改。

    // TransportConfigureItem.java:189 — SM4默认"T"(开启)
    public static final TransportConfigureItem SM4_ENCRYPT =
        new TransportConfigureItem("SM4_ENCRYPT", 153,
            "sm4encrypt", "T");
    // "T" = 开启, "F" = 关闭

    // ConfigChangedEventManager.java:502 — 所有配置可被服务器覆盖
    public void loadConfig(Context context) {
        loadConfig4ImportantConfig(context);  // 从服务器拉取
        loadConfig4NormalConfig(context);
    }

通过`ConfigChangedEventManager.loadConfig()`，服务端可以将SM4_ENCRYPT从"T"改为"F"。这个过程：

- 没有用户提示
- 没有客户端UI指示加密状态变化
- 可以针对特定用户推送
- 用户无法察觉自己的加密保护被关闭了

这意味着合规审计时看到"SM4已启用"，运行时SM4可能已经被静默关闭。审计结论和运行时行为之间存在可控的鸿沟。

## 04 硬编码的HTTP：连HTTPS都可以不用

核心发现：代码中存在硬编码的HTTP明文URL，用于遥测数据上报。这不是配置问题——是写死在代码里的。

    // MonitorState.java:40 — 硬编码HTTP URL
    private static final String URL =
        "http://mdap.alipaylog.com/loggw/report_diangosis_upload_status.htm";
    // 注意: 是http://不是https://

当`PushUtil.canFixHttpToHttps()`返回false时，遥测数据（包含设备IMEI、UTDID等标识信息）会通过这个明文HTTP端点上报。

同时，`LogContext.java`第79-80行还定义了两个配置键——`LogUploadDisableHttps`和`LogUploadDisableHttpsTime`——可以在运行时关闭日志上传的HTTPS保护。再加上`ALLOW_DOWN_HTTPS`配置（默认值"64"，位标志），形成了多条HTTPS降级路径。

## 05 全景：三层加密保护，全部可被远程控制

从技术角度，支付宝的传输安全本应是三层防护：

层级 | 保护 | 默认状态 | 问题
--- | --- | --- | ---
传输层 | TLS/HTTPS | 有条件 | ALLOW_DOWN_HTTPS允许降级 + 硬编码HTTP回退
国密层 | SM4加密 | 默认开，可远程关 | 服务端可静默禁用，无用户通知
应用层 | RPC内容加密 | 默认关 | 硬编码默认值"0"

三层保护，没有一层是用户可以控制的。更关键的是，所有开关都通过同一个`ConfigChangedEventManager.loadConfig()`入口被服务端管理。如果再结合上期分析的PatchProxy机制（146,173个可远程替换方法），即使这些开关本身也可以被热修复替换。

这不是单个bug，是一种架构模式：加密保护作为可选项而非强制项存在。

### 多国监管机构已受理

本系列研究发现已提交至中国CNNVD、CNCERT，美国MITRE（28个CVE），以及卢森堡CNPD、CSSF、CIRCL，香港HKMA，新加坡PDPC/MAS。厂商于2026年3月10日回复"正常功能"。

> Nora: "Encryption that can be switched off remotely is not encryption. It's a courtesy."
> (可以被远程关掉的加密不是加密，是礼貌。)

// End of analysis. Three encryption layers, zero user control.
// Full evidence: github.com/sgInnora/alipay-securityguard-analysis
// "Default off is not defense in depth — it's defense in theory." -- Nora

研究性质声明: 本文基于公开渠道获取的Android APK文件(v10.8.30.8000)进行静态反编译分析(jadx)，未侵入任何受保护计算机系统。所有技术结论可通过反编译同版本APK独立验证。需注意：静态分析只能证明代码中存在这些配置开关和默认值，运行时是否被服务端覆盖为其他值需要动态验证。

负责任披露: 2026-02-25通过AntSRC首次报告 → 2026-03-10厂商回复"正常功能" → 2026-03-19 MITRE CVE提交 → 2026-03-23公开披露

AI辅助标识: 本文使用Claude辅助代码分析和文本整理，核心代码定位和漏洞发现由人工完成。

许可协议: CC BY-NC-SA 4.0 | 联系: security@innora.ai

Feng Ning (风宁)

Innora.ai 创始人 | CISSP | Penang, Malaysia

"No Code is Done until it is Committed and Documented."

引用:

[1] Feng, J. "Broken by Design: A Static Analysis of Alipay's SecurityGuard SDK." IACR ePrint 2026/526

[2] GitHub Evidence Repository: github.com/sgInnora/alipay-securityguard-analysis

[3] GB/T 32907-2016 — SM4 Block Cipher Algorithm (中国国家密码管理局)

[4] CWE-311: Missing Encryption of Sensitive Data (MITRE)

[5] MITRE CVE Submission: Ticket #2010319 (3 CVEs)

↑