Web 版 IM 聊天信息加密的三种实现方案

在 Chat 组件中，发送前先获取目标用户的公钥，加密后再通过 WebSocket 发送。接收到的消息需要手动点击解密，或者在后台静默解密后展示。

后端角色

后端在此方案中主要充当'公钥仓库'和'消息中继'。Spring Boot 的 Controller 负责查询公钥和转发密文，无需接触明文。

// ChatController.java
@RestController
@RequestMapping("/api/chat")
public class ChatController {
    @Autowired private UserRepository userRepository;

    // 获取指定用户的公钥
    @GetMapping("/user/{userId}/public-key")
    public ResponseEntity<?> getUserPublicKey(@PathVariable Long userId) {
        User user = userRepository.findById(userId).orElseThrow();
        if (user.getRsaPublicKey() == null) {
            return ResponseEntity.badRequest().body("User does not have a public key");
        }
        return ResponseEntity.ok().body(Collections.singletonMap("publicKey", user.getRsaPublicKey()));
    }

    // 转发加密消息
    @PostMapping("/message")
    public ResponseEntity<Void> sendEncryptedMessage(@RequestBody EncryptedMessageRequest request) {
        // 保存密文到数据库
        ChatMessage message = new ChatMessage();
        message.setSenderId(request.getSenderId());
        message.setReceiverId(request.getReceiverId());
        message.setContent(request.getContent()); // 密文
        message.setIsEncrypted(true);
        messageRepository.save(message);

        // WebSocket 实时转发
        messagingTemplate.convertAndSendToUser(
            request.getReceiverId().toString(),
            "/queue/messages",
            new MessageDeliveryDto(...)
        );
        return ResponseEntity.ok().build();
    }
}

尽管实现了端到端加密，但由于性能瓶颈和无法解决私钥泄露后的历史数据安全，此方案仅适合学习原理或极低频场景，不建议生产使用。

方案二：非对称加密 + 数字签名

方案一解决了保密性，但无法确认发送者身份。方案二引入了数字签名，增加了身份验证和完整性校验。

流程变化：

1. A 用 B 的公钥加密消息得到密文 C。
2. A 用自己的私钥对消息（或密文）进行签名得到 S。
3. 发送 {C, S} 给服务器，服务器转发给 B。
4. B 先用 A 的公钥验证签名 S，验证通过后再用 B 的私钥解密 C。

这样即使消息被篡改，签名验证也会失败。不过，每次发送都需要两次昂贵的非对称运算（加密 + 签名），性能进一步下降，且依然没有前向保密性。

前端增强

在 crypto.js 中增加签名和验签函数。注意签名通常是对消息哈希值进行的，这样效率更高。

// 使用私钥对消息进行签名
export function signMessageWithPrivateKey(privateKeyPem, message) {
  try {
    const privateKey = forge.pki.privateKeyFromPem(privateKeyPem);
    const md = forge.md.sha256.create();
    md.update(message, 'utf8');
    const signature = privateKey.sign(md);
    return forge.util.encode64(signature);
  } catch (error) {
    throw new Error('消息签名失败');
  }
}

// 使用公钥验证签名
export function verifySignatureWithPublicKey(publicKeyPem, message, signatureBase64) {
  try {
    const publicKey = forge.pki.publicKeyFromPem(publicKeyPem);
    const md = forge.md.sha256.create();
    md.update(message, 'utf8');
    const signature = forge.util.decode64(signatureBase64);
    return publicKey.verify(md.digest().getBytes(), signature);
  } catch (error) {
    return false;
  }
}

在 Chat 组件中，发送时附加签名字段，接收时先验签再解密。如果验签失败，应提示用户消息可能不可信。

后端调整

后端实体类需增加 signature 字段存储签名，DTO 同步更新。原则上后端不验证签名（因为它是密文），验证工作主要在客户端完成，但后端可以记录日志以便审计。

此方案虽然增强了信任机制，但性能和密钥管理问题依旧，仍不是生产环境的最佳选择。

方案三：混合加密系统（推荐生产方案）

这是现代安全通信的标准模型，也是唯一推荐用于生产环境的方案。核心思想是：用非对称加密交换临时对称密钥，后续通信全部使用对称加密。

核心优势：前向保密

每次会话生成独立的临时对称密钥（会话密钥）。即使攻击者将来窃取了用户的长期私钥，由于过去的会话密钥已销毁且未保存，历史通信记录依然无法解密。这就是完美前向保密（Perfect Forward Secrecy, PFS）。

实现流程

1. 会话初始化：A 生成随机对称密钥 SK 和 IV。获取 B 的长期公钥，用其加密 (SK, IV) 形成'密钥信封'。将信封发送给 B。
2. 消息传输：A 使用 SK 和 AES 算法加密实际消息。B 收到信封后，用私钥解密出 SK，再用 SK 解密消息。
3. 密钥轮换：定期更换会话密钥，进一步降低风险。

前端实现

我们需要在 Vuex Store 中维护一个会话密钥库，按目标用户 ID 索引。

// store/modules/chatSession.js
const state = {
  sessionKeys: {} // { [userId]: { key: '...', iv: '...' } }
};

const mutations = {
  SET_SESSION_KEY(state, { userId, keyData }) {
    state.sessionKeys[userId] = { ...keyData, timestamp: Date.now() };
  },
  CLEAR_ALL_SESSIONS(state) {
    state.sessionKeys = {};
  }
};

const actions = {
  async establishSession({ commit, rootState }, targetUserId) {
    // 1. 生成对称密钥
    const symmetricKey = generateSymmetricKey();
    // 2. 获取对方公钥
    const publicKeyResponse = await apiGetUserPublicKey(targetUserId);
    const receiverPublicKey = publicKeyResponse.data.publicKey;
    // 3. 加密对称密钥（创建信封）
    const encryptedEnvelope = encryptSymmetricKeyWithPublicKey(receiverPublicKey, symmetricKey);
    // 4. 发送密钥交换请求
    await apiSendKeyExchange({ receiverId: targetUserId, encryptedEnvelope });
    // 5. 本地缓存
    commit('SET_SESSION_KEY', { userId: targetUserId, keyData: symmetricKey });
    return symmetricKey;
  }
};

发送消息时，优先检查是否有会话密钥，如果没有则触发建立会话。加密过程变为快速的 AES 操作。

// components/Chat.vue - sendMessage
async sendMessage() {
  // 获取或创建会话密钥
  const sessionKeyData = await this.$store.dispatch('chatSession/getOrCreateSessionKey', this.targetUser.id);
  // 使用对称密钥加密（非常快）
  const encryptedContent = encryptWithSymmetricKey(
    sessionKeyData.key,
    sessionKeyData.iv,
    this.newMessage.trim()
  );
  // 发送...
}

高级特性：ECDH 协商

为了达到更高的安全性，可以使用椭圆曲线 Diffie-Hellman (ECDH) 协议进行双工密钥协商。双方各自生成临时密钥对，交换公钥后计算出相同的共享密钥。这种方式下，即使长期私钥泄露，只要临时私钥已销毁，会话依然安全。实现上可借助 libsodium.js 等成熟库。

优缺点总结

• 优点：高性能（AES）、前向保密、安全性高。
• 缺点：实现复杂，需管理会话状态和密钥生命周期。

对于任何严肃的 Web IM 应用，请务必选择此方案。它在安全性和用户体验之间取得了最佳平衡。

部署与安全最佳实践

密钥存储

• 长期私钥：严禁明文存储在 localStorage 中，极易受 XSS 攻击。建议使用用户密码通过 KDF（如 PBKDF2）派生密钥，对私钥加密后再存储。或者利用浏览器 window.crypto.subtle API 的非提取式密钥。
• 会话密钥：建议存储在内存（Vuex）中，页面刷新即失效，强制重新协商以增强前向保密。如需持久化，请加密后存入 IndexedDB。

传输安全

必须全程使用 HTTPS 和 WSS 协议，防止中间人攻击窃取公钥或密文。

测试策略

• 单元测试覆盖加解密逻辑的正确性。
• 集成测试验证两端能否成功完成密钥交换和消息收发。
• 负载测试模拟高频加密消息，观察前端 CPU 占用情况。

常见问题

• 无法解密：检查是否使用了正确的私钥，或引导用户重新登录建立新会话。
• 签名无效：明确告知用户消息可能被篡改，建议通过其他渠道核实。
• 新设备登录：设计清晰的引导流程，告知用户新设备无法解密旧消息，需重新生成密钥。

总结

综上所述，虽然方案三的实现复杂度最高，但它提供了必要的性能和安全特性。对于面向用户的 Web 版 IM 应用，混合加密系统是唯一的正确选择。