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

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

引言：为什么 IM 需要端到端加密？

即时通讯内容往往包含个人隐私或商业机密。传统的 HTTPS 只能保证传输链路安全，一旦服务器被攻破或管理员作恶，明文数据依然可能泄露。端到端加密（E2EE）的核心在于：消息在发送方客户端加密，直到到达接收方客户端才解密。这意味着服务提供商也无法窥探内容。

我们主要关注四个安全目标：保密性、完整性、身份验证和不可否认性。

核心密码学概念与工具

在动手之前，得先理清几个基础概念：

1. 对称加密：如 AES，速度快但密钥分发难。
2. 非对称加密：如 RSA，解决了密钥分发问题，但速度慢。
3. 混合加密：结合两者优点，用非对称交换密钥，用对称加密数据。这是 TLS 等现代协议的基础。
4. 数字签名：用于验证来源和完整性，防止篡改。
5. 前端库选择：本文选用 node-forge，它在 Node.js 和浏览器中表现均衡，API 友好。生产环境也可考虑 libsodium.js。

---

方案一：静态非对称加密（基础方案）

这是最直观的方案。每个用户拥有一对固定的长期密钥。发送者直接用接收者的公钥加密每一条消息。

流程简述

1. 注册时生成 RSA 密钥对，私钥本地存，公钥上传。
2. A 发消息给 B，A 获取 B 的公钥。
3. A 用 B 的公钥加密消息，服务器仅做转发。
4. B 收到后用私钥解密。

前端 Vue 实现

我们需要安装依赖并封装工具类。

npm install node-forge

核心工具类 crypto.js 负责密钥生成与加解密：

// utils/crypto.js
import forge from 'node-forge';

// 生成 RSA 密钥对
export function generateRSAKeyPair() {
  return new Promise((resolve, reject) => {
    forge.pki.rsa.generateKeyPair({ bits: 2048, workers: 2 }, (err, keypair) => {
      if (err) { reject(err); return; }
      const publicKey = forge.pki.publicKeyToPem(keypair.publicKey);
      const privateKey = forge.pki.privateKeyToPem(keypair.privateKey);
      resolve({ publicKey, privateKey });
    });
  });
}

// 使用公钥加密消息 (RSA-OAEP padding)
export function encryptMessageWithPublicKey(publicKeyPem, message) {
  try {
    const publicKey = forge.pki.publicKeyFromPem(publicKeyPem);
    const encodedMessage = forge.util.encodeUtf8(message);
    // OAEP 比 PKCS#1 更安全
    const encrypted = publicKey.encrypt(encodedMessage, 'RSA-OAEP', {
      md: forge.md.sha256.create(),
    });
    return forge.util.encode64(encrypted);
  } catch (error) {
    console.error('加密失败:', error);
    throw new Error('消息加密失败');
  }
}

// 使用私钥解密消息
export function decryptMessageWithPrivateKey(privateKeyPem, encryptedMessageBase64) {
  try {
    const privateKey = forge.pki.privateKeyFromPem(privateKeyPem);
    const encryptedData = forge.util.decode64(encryptedMessageBase64);
    const decrypted = privateKey.decrypt(encryptedData, 'RSA-OAEP', {
      md: forge.md.sha256.create(),
    });
    return forge.util.decodeUtf8(decrypted);
  } catch (error) {
    console.error('解密失败:', error);
    throw new Error('消息解密失败，可能是密钥不匹配或消息已损坏');
  }
}

// 注意：生产环境不要直接存 localStorage，建议用用户密码派生密钥二次加密
export function savePrivateKeySecurely(userId, privateKey) {
  localStorage.setItem(`im_private_key_${userId}`, privateKey);
}

export function getPrivateKey(userId) {
  return localStorage.getItem(`im_private_key_${userId}`);
}

在 Chat 组件中使用这些方法。这里要注意，发送前获取公钥，接收后点击解密。为了用户体验，可以加入乐观更新 UI 的逻辑。

后端 Java 实现

后端在此方案中主要负责公钥存储和消息中继，逻辑相对简单。

// User 实体，增加公钥字段
@Entity
@Table(name = "im_users")
@Data
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String username;
    
    @Column(columnDefinition = "TEXT")
    private String rsaPublicKey; // PEM 格式
}

// Controller 层示例
@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()));
    }
}

方案一优缺点总结

• 优点：概念简单，符合 E2EE 基本定义。
• 缺点：性能极差（RSA 慢），无前向保密性（私钥泄露则历史消息全暴露），密钥管理复杂（换设备无法同步）。仅适合学习原理，不推荐生产。

---

方案二：非对称加密 + 数字签名（增强身份验证）

方案一无法确认发送者身份。方案二增加了数字签名，解决身份验证和防篡改问题。

核心流程

1. A 用 B 的公钥加密消息得到密文 C。
2. A 用自己的私钥对消息哈希进行签名 S。
3. 发送 {cipherText: C, signature: S}。
4. B 先用 A 的公钥验证签名，再用自己的私钥解密。

前端增强

在 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;
  }
}

方案二优缺点总结

• 优点：提供了身份验证和不可否认性。
• 缺点：性能进一步下降（两次非对称操作），依然没有前向保密性。

---

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

这是现代安全通信的标准模型。核心思想是：用非对称加密安全地交换一个临时的对称密钥，然后用这个对称密钥加密实际的消息。

关键特性：前向保密 (Forward Secrecy)

每次会话使用独立的临时密钥。即使长期私钥泄露，攻击者也无法解密过去的通信记录，因为会话密钥早已丢弃。

前端 Vue 实现

我们需要管理会话密钥（Session Key）。

// utils/crypto.js (新增混合加密函数)

// 生成随机的对称密钥和 IV (AES-CBC)
export function generateSymmetricKey() {
  const key = forge.random.getBytesSync(32); // AES-256
  const iv = forge.random.getBytesSync(16);
  return {
    key: forge.util.encode64(key),
    iv: forge.util.encode64(iv)
  };
}

// 使用对称密钥加密消息 (非常快)
export function encryptWithSymmetricKey(keyBase64, ivBase64, message) {
  try {
    const key = forge.util.decode64(keyBase64);
    const iv = forge.util.decode64(ivBase64);
    const cipher = forge.cipher.createCipher('AES-CBC', key);
    cipher.start({ iv: iv });
    cipher.update(forge.util.createBuffer(message, 'utf8'));
    cipher.finish();
    return forge.util.encode64(cipher.output.data);
  } catch (error) {
    throw new Error('消息加密失败');
  }
}

// 使用公钥加密对称密钥（信封）
export function encryptSymmetricKeyWithPublicKey(publicKeyPem, symmetricKeyObj) {
  const keyDataStr = JSON.stringify(symmetricKeyObj);
  return encryptMessageWithPublicKey(publicKeyPem, keyDataStr);
}

在 Vuex Store 中维护会话密钥状态，避免每次发送都重新协商，同时支持过期策略。

高级特性：ECDH 双工协商

更安全的做法是使用 Diffie-Hellman 协议协商共享密钥。双方各自生成临时 ECC 密钥对，交换公钥后计算共享密钥。这样即使长期私钥泄露，过去会话依然安全。这需要引入 libsodium.js 等库来实现。

方案三优缺点总结

• 优点：高性能（对称加密），具备前向保密性，安全性高。
• 缺点：实现复杂度最高，需管理密钥生命周期。

结论：方案三是唯一推荐用于生产环境的方案。

---

部署与安全最佳实践

密钥安全存储

• 长期私钥：严禁明文存储在 localStorage。建议使用用户密码通过 KDF（如 PBKDF2）派生密钥后再加密存储。
• 会话密钥：可存在内存中，刷新即丢失以增强前向保密；若需持久化，请加密后存入 IndexedDB。

传输安全

• 必须使用 HTTPS 和 WSS 协议。
• 所有 API 调用需严格身份验证（如 JWT）。

常见问题处理

• 无法解密：检查是否换了设备导致私钥丢失，引导用户重新建立会话。
• 签名无效：提示用户消息可能被篡改，建议通过其他渠道核实。

---

总结与方案选择

特性	方案一：静态非对称	方案二：静态 + 签名	方案三：混合加密
安全性	低	中	高
性能	极差	非常差	优秀
前向保密	无	无	有
推荐场景	学习原型	低频验证	生产环境

对于任何严肃的 Web IM 应用，请务必选择方案三。它虽然实现复杂，但能同时满足安全性、性能和用户体验的要求。