Spring Boot 企业级 RSA + AES-GCM 混合加密自动解密中间件设计与实战

1. 项目背景与真实业务场景
2. 混合加密整体原理
3. 通信流程与架构图

4. 基础实现版本

   • 4.1 依赖
   • 4.2 RSA 工具类
   • 4.3 AES-CBC 工具类
   • 4.4 请求模型
   • 4.5 AutoDecrypt 注解
   • 4.6 RequestWrapper
   • 4.7 Interceptor 解密
   • 4.8 Controller 示例
   • 4.9 Client 示例

5. 基础实现的安全缺陷分析

6. 企业级增强方案

   • 6.1 AES-GCM 替代 CBC
   • 6.2 Filter 全链路加解密
   • 6.3 防重放：timestamp + nonce + Redis
   • 6.4 防篡改：GCM 认证
   • 6.5 RSA Key 版本管理
   • 6.6 异常统一加密返回
   • 6.7 密钥安全管理（Secret / KMS）

7. 金融级安全算法组合标准

8. 性能优化与高并发实践

9. 真实业务案例

   • 金融支付
   • 政务接口
   • 物联网通信
   • 微服务零信任

10. 总结与工程落地建议

第 1 章 项目背景与真实业务场景

在多数 Web 项目中，接口安全通常被简单理解为“只要上了 HTTPS 就安全了”。 但在企业级系统，尤其是金融、政务、物联网、内部核心系统中，这种理解是严重不足的。

HTTPS 只能解决“链路传输安全”问题：

在真实企业环境中，攻击往往发生在 HTTPS 之后：

• App 被反编译，密钥被提取
• 内部接口被抓包复用
• 接口被批量重放制造资金损失
• 请求体被替换绕过风控
• 微服务之间互相“裸奔”通信

这类问题在安全审计中会被直接判定为：

仅 HTTPS，不具备应用层安全能力

1.1 为什么必须引入“应用层加密”

企业级接口通常要求做到：

1. 数据内容不可被明文获取
2. 请求不可被篡改
3. 请求不可被重放
4. 响应数据同样加密
5. 密钥可以平滑轮换
6. 系统对业务代码无侵入

因此形成标准模式：

HTTPS + 应用层加密

而应用层加密的经典组合是：

RSA + AES

职责划分：

最终通信模型：

客户端 → AES 加密数据 客户端 → RSA 加密 AES Key 服务端 → RSA 解密 AES Key 服务端 → AES 解密业务数据

1.2 真实业务场景一：金融支付接口

金融系统接口的典型安全要求：

• 订单金额、银行卡号、身份证号不能明文传输
• 同一笔请求只能处理一次（防重放）
• 请求内容必须可校验是否被篡改
• 异常信息不能明文返回

典型流程：

客户端： 生成 AES Key AES-GCM 加密业务参数 RSA 公钥加密 AES Key 发送请求 服务端： RSA 私钥解密 AES Key AES-GCM 解密请求体 处理业务 AES-GCM 加密响应

这类设计在：

• 银行支付
• 资金托管
• 清结算系统

都是强制规范。

1.3 真实业务场景二：政务数据接口

政务系统常见数据：

• 身份证
• 户籍信息
• 企业法人信息
• 社保、税务数据

特点：

• 数据极度敏感
• 系统多为多部门对接
• API 经常被外部系统调用

如果只靠 HTTPS，一旦某个合作系统被攻破：

全量数据直接裸奔泄露

引入应用层加密后：

• 即使 HTTPS 被代理
• 即使流量被拦截
• 即使请求被复制

没有私钥，也无法解密真实业务数据。

1.4 真实业务场景三：物联网设备通信

IoT 设备特点：

• 容易被拆解
• 固件可被逆向
• 通信协议容易被仿造

如果设备通信不做应用层加密：

• 任意设备可伪造指令
• 可远程控制设备
• 可刷爆业务系统

标准做法：

设备端： 固定 RSA 公钥 每次通信生成 AES Key 所有数据 AES-GCM 加密

1.5 真实业务场景四：微服务零信任

在 Kubernetes、Service Mesh 架构中：

• 内网不再是“安全区”
• 任意 Pod 被攻破都可能横向攻击

传统：

内网 HTTP 明文

企业级要求：

内网 HTTPS + 应用层加密

实现真正意义上的：

零信任微服务通信

1.6 本文目标

本文目标不是“写一个能跑的 Demo”，而是：

构建一个可以通过企业安全审计、可直接用于生产的 Spring Boot 应用层加密中间件体系

最终效果：

第 2 章 混合加密整体原理（RSA + AES）

混合加密的核心思想是： 用非对称加密解决密钥安全问题，用对称加密解决性能问题。

如果只用 RSA 加密业务数据：

• 性能极差
• 加密数据长度受限
• 高并发下几乎不可用

如果只用 AES：

• AES 密钥必须安全传输
• 一旦被抓包泄露，所有数据全部暴露

所以在企业级系统中，必然采用：

RSA + AES 混合加密模型

2.1 整体交互时序图

┌──────────┐ ┌──────────┐ │ Client │ │ Server │ └────┬─────┘ └────┬─────┘ │ 1. 生成 AES Key + IV │ │------------------------------------->│ │ 2. AES 加密业务数据 │ │------------------------------------->│ │ 3. RSA 公钥加密 AES Key │ │------------------------------------->│ │ 4. 发送 {encryptedData, encryptedKey, iv} │------------------------------------->│ │ │ 5. RSA 私钥解密 AES Key │ │ 6. AES 解密业务数据 │ │ 7. 执行业务逻辑 │ │ 8. AES 加密响应数据 │ │ 9. RSA 公钥加密新 AES Key（可选） │<-------------------------------------│ │ 10. 接收加密响应数据 │

2.2 请求体结构设计

@Data public class EncryptedRequest { /** * AES 加密后的业务数据（Base64） */ private String encryptedData; /** * RSA 加密后的 AES Key（Base64） */ private String encryptedKey; /** * AES IV（Base64） */ private String iv; }

从安全角度看，它承担三层责任：

2.3 为什么 AES Key 不能直接明文传

假设你直接传：

{ "encryptedData": "...", "aesKey": "abcd1234..." }

那么任何抓包工具都能：

• 直接解密请求体
• 完全绕过 HTTPS
• 导致所有业务数据泄露

所以 AES Key 必须：

只能被 RSA 公钥加密传输

2.4 RSA 在这里的真实职责

很多人误解 RSA 是“数据加密算法”，在企业级架构中它只做一件事：

保护 AES Key

RSA 不直接加密大数据，只加密小而关键的数据：

• AES 密钥
• 时间戳
• 随机数
• 签名数据

2.5 AES 在这里的真实职责

AES 负责：

AES/CBC/PKCS5Padding

这是教学级可用，但在金融级系统中我们后面会升级为：

AES/GCM/NoPadding

原因：

2.6 混合加密完整生命周期

一次请求完整生命周期：

1. 客户端生成 AES Key + IV
2. 客户端 AES 加密业务数据
3. 客户端 RSA 加密 AES Key
4. 发送加密请求
5. 服务端 RSA 解密 AES Key
6. 服务端 AES 解密业务数据
7. 服务端执行业务逻辑
8. 服务端 AES 加密响应数据
9. 返回给客户端
10. 客户端 AES 解密响应

2.7 企业级加密目标拆解

2.8 与 HTTPS 的关系说明

必须强调：

应用层加密不是替代 HTTPS，而是叠加

最终安全层级：

TLS（传输层） + RSA + AES（应用层）

任何一