等保2.0接口加解密：RSA+AES混合加密与签名验签实现

2. 等保2.0接口加解密方案的整体设计思路

2.1 为什么要用"RSA+AES"混合加密，而不是只用一种

很多刚接触接口安全的朋友会有一个直觉：既然要做加密，那直接上RSA不就行了？前端拿公钥加密，后端拿私钥解密，简单又对称。真这么做，不用等上线，压测第一轮你就想骂人了。

RSA属于非对称加密，安全强度高，但性能瓶颈非常明显。2048位密钥的RSA加密，单次操作耗时通常在毫秒级甚至更高，如果业务接口的请求体是个几百KB的JSON，用RSA去加密，耗时和资源消耗都是灾难级的。而且RSA对明文长度有硬性限制，采用PKCS1Padding时最多只能加密密钥长度减11个字节，2048位密钥也就244字节左右，根本承载不了业务数据。

AES则是对称加密，加解密速度极快，单条数据加密耗时才几十微秒，且没有明文长度限制。但AES的问题是密钥分发——通信双方必须共享同一个密钥，如果直接把这个密钥放在请求头里传输，等于是把保险柜钥匙贴在保险柜门上。

所以业界标准的解法就是"混合加密"：

• 用RSA加密AES密钥，解决密钥分发问题；
• 用AES加密业务报文，解决性能和长度限制问题。

这两者组合起来，既拿到了RSA的安全性，又保留了AES的高效。整套方案在等保2.0三级系统的实践里是主流选择，很多省级政务平台和金融类系统都是这个套路。

等保2.0中的"通信传输完整性"与"通信传输保密性"是两个独立测评项，前者要求对通信报文进行完整性校验（对应防篡改），后者要求加密传输（对应保密性）。签名验签解决的是前者，加解密解决的是后者，缺一个都过不了。这也是为什么标题里三样东西一个都不能少——RSA和AES是为了保密性，签名验签是为了完整性和防抵赖。

2.2 整体架构与一次完整请求的生命周期

先把我常用的这套方案的整体流程画在脑子里，然后再谈代码实现。

一次性完整请求的流程拆解如下：

• 客户端在初始化时向后端请求一次公钥，后端将RSA公钥发给客户端，私钥保存在服务端；
• 客户端本地随机生成一个AES密钥（每次请求都可以换一个新的，或者复用一段时间，看业务取舍）；
• 客户端用后端公钥对AES密钥进行RSA加密，得到密文密钥；
• 客户端用AES密钥对业务报文进行AES加密，得到密文报文；
• 客户端对（AES密钥密文 + 报文密文 + 时间戳 + 随机数）拼接后的字符串做签名，签名用的私钥是客户端的RSA私钥；
• 请求到达服务端，服务端先验签，再解密AES密钥，最后解密报文；
• 响应流程反向执行：服务端生成响应的AES密钥（可与请求密钥一致，也可以独立），用客户端公钥加密，再用AES加密响应体，最后服务端私钥签名；
• 客户端收到响应后验签、解密，整个链路闭环。

这套流程里，最关键的一个设计决策是：签名和加密必须分开用密钥。前面提到的"前端拿公钥加密"有一个安全隐患——如果别人拿到了你的公钥，他可以伪装成客户端给你发加密数据，因为加密是公钥操作，不需要私钥。所以必须引入客户端签名机制，服务端用客户端的公钥去验签，从密码学意义上确认"这条数据确实来自声称的那个客户端"。

等保2.0里面有一项叫做"通信实体身份鉴别"，恰恰就需要这种双向的密钥机制来支撑。单纯做加解密只能满足保密性，无法满足身份真实性验证，这是不少团队在测评时被打回的原因之一。

2.3 防篡改设计的核心：签名原文的规范化

很多第一次做签名验签的团队都会踩同一个坑：签名的时候拼接的字符串和服务端验签时拼接的字符串不一致，导致验签永远失败。这个问题的根子在于"签名原文规范化"做得不好。

签名原文的确定规则必须在对接文档里定死。我常用的规则是：

• 对需要签名的字段先做字典序排序（按字段名的ASCII码升序）；
• 所有字段值不允许包含null，空串用空字符串表示；
• 各字段用&连接，格式为key1=value1&key2=value2；
• 最后拼接固定的signType=RSA2之类的标识字段（如果有的话）。

另外，必须将时间戳和随机数（Nonce）纳入签名原文。时间戳用于防止重放攻击——服务端只接受2~5分钟内的请求；Nonce则防止同一时间内完全相同的请求被多次提交。服务端可以简单存一个最近5分钟内的Nonce集合，收到请求后先检查Nonce是否重复，重复直接拒绝。这两者都能撑起等保2.0测评项中关于"抗重放"的要求，光做加密不做抗重放，测评专家照样会提整改项。

3. 核心代码实现：RSA密钥对管理、AES加解密、签名验签

3.1 RSA密钥对生成与加载：别在代码里写死私钥

第一步是RSA密钥对的管理。在很多现成的"RSA加密解决方案"里，人们习惯把公私钥直接写在配置文件的字符串常量里。这样做开发调试没有问题，但到了生产环境就埋了大雷——私钥一旦泄露，整个系统加密体系就等于全部公开。等保2.0整改意见里明确要求"密钥全生命周期管理"，从生成、分发、存储、更新到销毁都要有制度和技术手段支撑。

我通常的做法是：

• 用KeyPairGenerator在系统初始化时生成RSA密钥对；
• 生成后将私钥用PKCS12格式存储到服务端安全目录（或密钥管理服务KMS），文件权限设为600；
• 公钥通过HTTP接口明文下发，公钥不需要保护，泄露了也没关系；
• 私钥定期轮换，旧密钥保留一段时间的解密能力（用于兼容旧客户端），新密钥发布后新请求全部使用新密钥。

核心生成代码如下：

import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.NoSuchAlgorithmException; import java.security.SecureRandom; import java.util.Base64; public class RsaKeyGenerator { public static KeyPair generateRsaKeyPair(int keySize) throws NoSuchAlgorithmException { KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA"); // SecureRandom 提供加密强随机数，避免使用 new Random() 这种弱随机源 SecureRandom secureRandom = new SecureRandom(); generator.initialize(keySize, secureRandom); return generator.generateKeyPair(); } public static void main(String[] args) throws NoSuchAlgorithmException { KeyPair keyPair = generateRsaKeyPair(2048); // 生成后请将私钥放到安全存储，不要打印在日志里 String publicKey = Base64.getEncoder().encodeToString(keyPair.getPublic().getEncoded()); String privateKey = Base64.getEncoder().encodeToString(keyPair.getPrivate().getEncoded()); System.out.println("Public Key: " + publicKey); System.out.println("Private Key: " + privateKey); } }

密钥位数方面，实测下来2048位是生产环境的最低门槛。1024位在今天的算力下已经不安全，等保测评里专家看到1024位会直接给你挂个高风险；4096位虽然更安全，但加解密耗时大约是2048位的3~5倍，对高并发接口来说代价有点大。2024年开始有些金融客户要求必须支持3088位以上的曲线（SM2），但传统RSA 2048在大多数合规场景里依然够用。

私钥加载的核心代码：

import java.io.FileInputStream; import java.security.KeyStore; import java.security.PrivateKey; import java.security.PublicKey; public class KeyStoreLoader { public static PrivateKey loadPrivateKey(String pfxPath, String password) throws Exception { try (FileInputStream fis = new FileInputStream(pfxPath)) { KeyStore keyStore = KeyStore.getInstance("PKCS12"); keyStore.load(fis, password.toCharArray()); // 别名默认取第一个，生产环境建议在生成时指定别名 String alias = keyStore.aliases().nextElement(); return (PrivateKey) keyStore.getKey(alias, password.toCharArray()); } } public static PublicKey loadPublicKey(String certPath) throws Exception { // 从X509证书中提取公钥，或者直接从Base64字符串构建 // 以Base64字符串为例 byte[] keyBytes = Base64.getDecoder().decode(certPath); X509EncodedKeySpec spec = new X509EncodedKeySpec(keyBytes); KeyFactory factory = KeyFactory.getInstance("RSA"); return factory.generatePublic(spec); } }

注意一点：千万不要把私钥以纯文本形式放在src/main/resources目录下然后打进JAR包。很多人为了图省事这么干，结果就是代码仓库泄露等于私钥泄露。JAR包是可以被反编译提取资源的，生产环境私钥一定要落在容器外部挂载的加密卷或专门的密钥管理服务里。

3.2 AES加解密工具类：GCM模式比CBC更省心

AES加密的模式选择是个容易踩坑的点。最常见的是CBC模式，但它有一个让人头疼的问题——需要单独处理IV（初始向量），而且CBC模式不提供完整性校验，攻击者对密文做位翻转（Bit Flipping）时解密结果可控地变化，配合某些场景甚至能绕过鉴权逻辑。

我更推荐用AES/GCM/NoPadding。GCM是AEAD（认证加密）模式，密文里自带认证标签（Auth Tag），解密时会同时校验完整性，密文只要被改动任何一个比特，解密直接抛异常。这天然就给防篡改加了一道保险。

import javax.crypto.Cipher; import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import javax.crypto.spec.GCMParameterSpec; import javax.crypto.spec.SecretKeySpec; import java.security.SecureRandom; import java.util.Base64; public class AesGcmUtil { private static final int GCM_TAG_BITS = 128; private static final int IV_LENGTH = 12; // GCM推荐12字节 public static SecretKey generateAesKey() throws Exception { KeyGenerator generator = KeyGenerator.getInstance("AES"); generator.init(256, new SecureRandom()); return generator.generateKey(); } public static String encrypt(String plainText, SecretKey key) throws Exception { byte[] iv = new byte[IV_LENGTH]; new SecureRandom().nextBytes(iv); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); cipher.init(Cipher.ENCRYPT_MODE, key, new GCMParameterSpec(GCM_TAG_BITS, iv)); byte[] cipherBytes = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); // 输出格式：IV + 密文 + tag，方便解密时直接切分 byte[] result = new byte[iv.length + cipherBytes.length]; System.arraycopy(iv, 0, result, 0, iv.length); System.arraycopy(cipherBytes, 0, result, iv.length, cipherBytes.length); return Base64.getEncoder().encodeToString(result); } public static String decrypt(String base64Data, SecretKey key) throws Exception { byte[] data = Base64.getDecoder().decode(base64Data); byte[] iv = new byte[IV_LENGTH]; byte[] cipherBytes = new byte[data.length - IV_LENGTH]; System.arraycopy(data, 0, iv, 0, IV_LENGTH); System.arraycopy(data, IV_LENGTH, cipherBytes, 0, cipherBytes.length); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); cipher.init(Cipher.DECRYPT_MODE, key, new GCMParameterSpec(GCM_TAG_BITS, iv)); byte[] plainBytes = cipher.doFinal(cipherBytes); return new String(plainBytes, StandardCharsets.UTF_8); } }

AES密钥长度用256位，这里面没有什么纠结的余地。128位在当前算力下虽未被公开破解，但等保2.0的测评要求中明确提到"采用密码技术保证通信数据保密性时，应使用满足国家密码主管部门要求的密钥管理机制"，实际执行中测评机构普遍会认256位AES。另外Java默认的JDK如果没有装Java Cryptography Extension（JCE）的无限强度策略文件，256位AES可能无法使用，不过JDK 8u161之后这个限制已经解除了，Spring Boot 3.4自带JDK 17+，完全不需要关心这个旧问题。

3.3 签名验签：SHA256withRSA的正确用法

签名的意义在于"证明这段数据确实来自声称的发送方，且没有被中途改动过"。RSA签名验签使用的是私钥签名、公钥验签，这和加密正好相反。每个客户端也维护自己的RSA密钥对，客户端的公钥注册到服务端，客户端拿私钥签名，服务端拿注册过的公钥验签——这就是前面提到的"通信实体身份鉴别"的技术基础。

import java.security.*; import java.security.spec.PKCS8EncodedKeySpec; import java.security.spec.X509EncodedKeySpec; import java.util.Base64; public class SignUtil { public static String sign(String content, PrivateKey privateKey) throws Exception { Signature signature = Signature.getInstance("SHA256withRSA"); signature.initSign(privateKey); signature.update(content.getBytes(StandardCharsets.UTF_8)); byte[] signed = signature.sign(); return Base64.getEncoder().encodeToString(signed); } public static boolean verify(String content, String signBase64, PublicKey publicKey) throws Exception { Signature signature = Signature.getInstance("SHA256withRSA"); signature.initVerify(publicKey); signature.update(content.getBytes(StandardCharsets.UTF_8)); byte[] signed = Base64.getDecoder().decode(signBase64); return signature.verify(signed); } }

算法选择上，"SHA256withRSA"是主流标配。MD5withRSA已经被攻破，SHA1withRSA在等保测评中也会被标记为弱算法。有些安全性要求更高的场景会选择SHA384withRSA甚至SHA512withRSA，但带来的签名长度和计算量增长并不是很划算，目前实际项目里SHA256withRSA是使用最广泛的。

签名原文的拼接，我会单独抽一个方法来做，保证客户端和服务端的拼接逻辑完全一致：

public static String buildSignContent(Map<String, String> params) { // TreeMap 自动按 Key 的字典序排序，保证签名与验签双方字段顺序一致 TreeMap<String, String> sortedParams = new TreeMap<>(params); StringBuilder content = new StringBuilder(); for (Map.Entry<String, String> entry : sortedParams.entrySet()) { if (entry.getValue() != null && !entry.getValue().isEmpty()) { content.append(entry.getKey()).append("=").append(entry.getValue()).append("&"); } } if (content.length() > 0) { content.deleteCharAt(content.length() - 1); } return content.toString(); }

这个方法里有几个容易被忽略的细节：过滤空值、按字典序排序、结尾不残留多余的&。如果两端有一端加了空值拼接而另一端没加，验签就会失败。排查这类问题的时候耗掉的时间，比写整个工具类的时间都多。

4. Spring Boot 3.4 实战集成：拦截器、注解与配置

4.1 自定义注解：声明式接口加解密

我建议用注解的方式声明哪些接口需要加解密，而不是全部接口统一处理。原因很实际：有些接口比如图片验证码获取、文件下载，响应体是二进制流或图片Base64，做统一加密处理反而会引入不必要的性能损耗和兼容性问题。用注解可以灵活控制加解密范围。

需要定义三个注解：

@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) public @interface EncryptResponse { } @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) public @interface DecryptRequest { } @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface IgnoreCrypto { }

类上打了@EncryptResponse的Controller，响应的JSON会自动被AES加密后包装；打了@DecryptRequest的Controller，请求体会先解密再进入业务方法。某些方法（如健康检查、公钥获取）可以直接用@IgnoreCrypto跳过处理，非常灵活。

4.2 拦截器核心逻辑：解密请求体与加密响应体

Spring Boot里实现这个需求有几种路子：Filter、HandlerInterceptor、AOP。我实测下来，HandlerInterceptor是最好用的，因为它能拿到HandlerMethod，可以方便地读取注解信息，而且可以在Controller方法执行前解密、执行后加密。Filter虽然优先级更高，但要自行解析Handler和注解，代码写起来麻烦不少。

先看拦截器的主体结构：

public class CryptoInterceptor implements HandlerInterceptor { private final CryptoService cryptoService; public CryptoInterceptor(CryptoService cryptoService) { this.cryptoService = cryptoService; } @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { if (!(handler instanceof HandlerMethod handlerMethod)) { return true; } boolean needDecrypt = handlerMethod.getBeanType().isAnnotationPresent(DecryptRequest.class) && !handlerMethod.hasMethodAnnotation(IgnoreCrypto.class); boolean needEncrypt = handlerMethod.getBeanType().isAnnotationPresent(EncryptResponse.class) && !handlerMethod.hasMethodAnnotation(IgnoreCrypto.class); if (!needDecrypt && !needEncrypt) { return true; } // 解密通常是包装Request，加密则是包装Response CryptoRequestWrapper requestWrapper = null; CryptoResponseWrapper responseWrapper = null; if (needDecrypt) { String timestamp = request.getHeader("X-Timestamp"); String nonce = request.getHeader("X-Nonce"); String sign = request.getHeader("X-Sign"); String encryptedKey = request.getHeader("X-Key"); // 验签逻辑，保证请求在传输过程中没有被篡改 String contentType = request.getContentType(); if (contentType == null || !contentType.contains("application/crypto")) { throw new IllegalStateException("Content-Type must be application/crypto"); } String cipherBody = new String(request.getInputStream().readAllBytes(), StandardCharsets.UTF_8); boolean valid = cryptoService.verifyRequestSign(encryptedKey, cipherBody, timestamp, nonce, sign); if (!valid) { throw new SecurityException("签名验证失败，请求可能被篡改"); } // 防重放 if (!cryptoService.checkNonce(nonce, timestamp)) { throw new SecurityException("重放请求被拒绝"); } String plainBody = cryptoService.decryptRequest(encryptedKey, cipherBody); requestWrapper = new CryptoRequestWrapper(request, plainBody); } if (needEncrypt) { responseWrapper = new CryptoResponseWrapper(response); } if (requestWrapper != null) { // 替换请求流，让Controller读到的已经是解密后的明文 request = requestWrapper; } if (responseWrapper != null) { response = responseWrapper; } return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception { // 响应体加密操作放在response.getOutputStream()被调用之后的finally块比较稳妥 // 但是如果使用ResponseWrapper，可以在afterCompletion里统一处理 if (response instanceof CryptoResponseWrapper wrapper) { cryptoService.encryptResponse(wrapper); } } }

这里有一个我在项目中踩过的坑：拦截器里如果直接把解密后的字符串重新包装成HttpServletRequest，需要注意request.getReader()和request.getInputStream()只能读取一次的问题。自定义的CryptoRequestWrapper必须重写这两个方法，让它们基于缓存中的解密后字符串来读取，并且要保证Controller参数以@RequestBody形式接收时走的是InputStream。

核心的CryptoService服务类实现：

@Service public class CryptoService { private RSAKeyProperties rsaKeyProperties; private ClientKeyStore clientKeyStore; public String decryptRequest(String encryptedKey, String cipherBody) throws Exception { // 1. 用服务端RSA私钥解密AES密钥 byte[] aesKeyBytes = rsaDecrypt(Base64.getDecoder().decode(encryptedKey)); SecretKey aesKey = new SecretKeySpec(aesKeyBytes, "AES"); // 2. 用AES密钥解密请求体 return AesGcmUtil.decrypt(cipherBody, aesKey); } public void encryptResponse(CryptoResponseWrapper responseWrapper) throws Exception { String plainBody = responseWrapper.getCapturedResponseBody(); // 1. 生成新的AES密钥 SecretKey aesKey = AesGcmUtil.generateAesKey(); // 2. AES加密响应体 String encryptedBody = AesGcmUtil.encrypt(plainBody, aesKey); // 3. 用客户端公钥加密AES密钥 String encryptedAesKey = rsaEncrypt(aesKey.getEncoded(), clientKeyStore.getClientPublicKey()); // 4. 服务端私钥签名 String signContent = buildSignContent(Map.of( "key", encryptedAesKey, "body", encryptedBody, "timestamp", String.valueOf(System.currentTimeMillis()) )); String sign = SignUtil.sign(signContent, rsaKeyProperties.getPrivateKey()); // 5. 组装响应JSON String cryptoResponse = objectMapper.writeValueAsString(Map.of( "key", encryptedAesKey, "body", encryptedBody, "sign", sign )); responseWrapper.setFinalBody(cryptoResponse); } }

这里有两个细节值得说。第一个是响应里的key和body的时间戳不一致问题——我上面的代码里，timestamp用的System.currentTimeMillis()，而AES密钥生成时间其实也就在几毫秒前，这个时间差可以忽略。但如果要求严格，应该用一个事务内的统一时间戳。第二个是响应体加密用的AES密钥，我每次响应都新生成一个——虽然服务端和客户端各维护一个长期AES密钥也可以，但每次请求都生成新密钥可以降低密钥泄露后的影响范围，代价仅仅是多一次RSA加密的耗时，对整体性能影响微乎其微。

4.3 注册拦截器与可配置化

Spring Boot 3.4里注册拦截器通过WebMvcConfigurer完成：

@Configuration public class WebConfig implements WebMvcConfigurer { @Resource private CryptoInterceptor cryptoInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(cryptoInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/public/**", "/actuator/health"); } }

配置项我用自定义属性类管理：

@ConfigurationProperties(prefix = "crypto") public class CryptoProperties { /** RSA私钥文件路径，生产环境通过环境变量注入 */ private String privateKeyPath; /** RSA私钥密码 */ private String privateKeyPassword; /** 允许的最大时间偏差，单位毫秒 */ private long timestampTolerance = 300000; /** 白名单请求头签名开关 */ private boolean signEnabled = true; }

在application.yml里做配置绑定：

crypto: private-key-path: ${CRYPTO_PRIVATE_KEY_PATH:/etc/crypto/server.p12} private-key-password: ${CRYPTO_PRIVATE_KEY_PASSWORD:} timestamp-tolerance: 300000 sign-enabled: true

我习惯把私钥地址和密码都用环境变量注入，而不是写在yaml里。Spring Boot 3.4支持${ENV_VAR:default}这种占位语法，这样即使代码仓库被拉取，敏感信息也不会泄露。

4.4 前端对接要点：签名与加密的JS侧实现

服务端做完了，前端对接也得给一套方案。现在的前端主流是axios加一个拦截器，在发送请求前对data做加密和签名，响应回来后做验签和解密。用Node.js的crypto模块可以很方便地实现RSA和AES加解密。

import CryptoJS from 'crypto-js'; import JSEncrypt from 'jsencrypt'; function buildRequestPayload(data: object, serverPublicKey: string, clientPrivateKey: string) { // 1. 生成临时AES密钥 const aesKey = CryptoJS.lib.WordArray.random(32); // 256位 // 2. AES加密业务数据 const encryptedData = CryptoJS.AES.encrypt(JSON.stringify(data), aesKey, { mode: CryptoJS.mode.GCM, iv: CryptoJS.lib.WordArray.random(12) }).toString(); // 3. RSA加密AES密钥（使用服务端公钥） const encryptor = new JSEncrypt(); encryptor.setPublicKey(serverPublicKey); const encryptedKey = encryptor.encrypt(aesKey.toString()); // 4. 拼接签名原文 const timestamp = String(Date.now()); const nonce = crypto.randomUUID(); const signSource = `body=${encryptedData}&key=${encryptedKey}&nonce=${nonce}&timestamp=${timestamp}`; // 5. 客户端私钥签名 const signer = new JSEncrypt(); signer.setPrivateKey(clientPrivateKey); const sign = signer.sign(signSource, crypto.SHA256, 'sha256'); return { headers: { 'Content-Type': 'application/crypto', 'X-Key': encryptedKey, 'X-Timestamp': timestamp, 'X-Nonce': nonce, 'X-Sign': sign }, body: encryptedData }; }

前端这套方案里最需要注意的是密钥管理：客户端的私钥绝不能放在前端代码包或公开CDN上，正确的做法是把私钥存到端内的安全存储（如iOS的Keychain、Android的Keystore），Web端可以考虑WebCrypto的IndexedDB非导出私钥，或者由后端签名后临时签发一次性签名凭据。实在要兼顾Web场景，可以退化为"服务端集中托管签名密钥，前端请求服务端完成签名"，虽然多了一次网络往返，但安全性有保障。

5. 常见问题与排查技巧实录

5.1 问题速查表

我把实际项目中遇到的高频问题整理一下，按现象、原因、解决方案三列给出速查表，方便你直接对号入座。

5.2 一次真实的排查过程分享

有次对接第三方平台，对方说我们用POST提交的数据他们验签总是失败。排查了整整三天，最后发现原因的细节特别让人无语：对方的签名规则里把所有参与签名的字段值先做了URL编码，而我们用的是原始值。如果字段里恰好有中文字符或特殊符号，两边拼接后的字节流不一致，签名自然验证不过。

从那以后，我在签名的对接文档里一定会加一句话："所有参与签名的字段值使用原始字符串，签名验签前不进行URL编码、HTML转义或任何形式的内容转换，如有特殊字符需在签名前由双方约定统一处理。"这种文档约定比代码里的任何防御都重要。

另一个高频坑是响应体加密后用ObjectMapper序列化时，如果响应里包含了HttpServletResponse自身（有时候错误处理机制会塞入），Jackson序列化会无限递归导致栈溢出。解决方式是只对Controller返回的DTO做加密，全局异常处理器里的错误响应单独走一个不加密的格式或轻量加密格式。我倾向于在全局异常处理里直接返回加密格式的失败信息，保证客户端解密逻辑统一。

5.3 性能优化与并发控制经验

加解密操作比普通JSON读写要慢，尤其RSA。压测数据可以参考一下：我在一台4核8G的普通云服务器上，用JMeter模拟50并发请求，纯AES加解密接口QPS大约在5000+，而每次请求带上RSA解密AES密钥之后，QPS掉到1200左右。这个损耗主要来自RSA私钥解密那一次操作。

优化的三板斧：

1. RSA密钥不每次解析：将PrivateKey对象在服务启动时加载一次，放入内存缓存。别看这个细节，有些代码每次请求都从密钥字符串解析一次PrivateKey对象，性能直接再砍一半。
2. 减少RSA操作次数：在会话级或客户端级复用AES密钥。每次请求都重新生成AES密钥并用RSA加密，是一种编码上的惰性实现。如果业务允许，可以建立一个AES密钥池，客户端每10分钟或每100次请求轮换一次密钥，这样RSA操作频率大幅下降，整体性能能回到AES直加解密的八九成。
3. 异步解密：对于非敏感业务或可以容忍短时间延迟的场景，用线程池异步处理加解密操作，把耗时从请求链路里摘出去。不过这会增加代码复杂度，不是必要场景别用。

再补充一个安全细节：日志打印。很多团队做完加解密之后，代码里随手log.info("request body: {}", requestBody)，明文报文直接进了日志文件。等保2.0里面有一项是"日志信息完整性"，如果日志里存在大量明文敏感数据，这本身就是一条高危整改项。对加解密接口涉及到的请求响应内容，要么不打日志，要么只打印脱敏后的摘要和请求ID。我做了一个AOP切面，对所有标注了加解密注解的Controller方法，日志里只记录方法名、耗时、HTTP状态码和请求ID，绝不打印请求体和响应体。

5.4 密钥轮换与灰度发布实战

密钥轮换是等保2.0里"密钥定期更换"的直接落地。比较稳妥的做法是引入"当前密钥版本"和"历史密钥版本"两个概念。服务端维持一个密钥版本号，每次轮换时新密钥成为当前版本，旧密钥进入历史列表保留一段时间（比如7天）。请求头里携带X-Key-Version，服务端根据版本号选择对应的私钥解密。这样旧客户端在过渡期内依然可以正常通信，等所有客户端升级后再将旧密钥从历史列表里移除。

代码层面的实现不复杂，用一个ConcurrentHashMap存版本号和私钥的映射，配合一个定时任务在本地缓存中清理过期密钥即可。真正麻烦的是"客户端如何感知密钥轮换"。我的经验是提供一个/api/crypto/key接口，响应当前版本号和服务端RSA公钥，客户端在启动时和每次请求收到密钥版本不一致时重新拉取。当服务端返回"密钥版本失效"错误码时，客户端自动重新拉取公钥并重放一次请求，这样业务侧无感知。

这套流程我在一个日活百万级的中型系统上稳定跑了一年多，最长的无故障运行周期超过200天，除了两次例行密钥轮换做过灰度发布外，没有因为密钥管理引发过线上事故。等保2.0三级测评时，加解密、完整性、身份鉴别、防重放这几项测评项全部一次性通过，这也是我个人对这套方案最有信心的地方。

6. 实操中的关键决策要回过头再想想

做成了一整套方案之后，我回过来看，有几个关键决策如果重新做一遍我仍然会坚持。第一是坚持用GCM而不是CBC，GCM自带完整性校验，让防篡改在密码学层面有了双重保障。第二是坚持将签名和加密分离，这种"双密钥体系"虽然在联调阶段多花了不少时间，但安全收益在测评和线上对抗测试中都有验证。第三是坚持密钥轮换和版本管理，这让系统在面对密钥泄露风险时能快速响应，而不是束手无策地重发版本。

最后分享一个小经验：接口加解密这类功能，建议不管业务复杂度高低，都把请求报文体的顶层JSON结构固定成{ "key": "...", "body": "...", "sign": "..." }这种统一格式。这样前后端联调时的心智负担会小很多，后续要加新接口也是纯配置工作，不需要重复沟通协议。这个格式在Restful接口、消息队列投递、异步回调等多个场景里都能复用，一劳永逸。