加密与签名技术之应用场景与选择

Stream
48 阅读10分钟

概述

本文档提供各种应用场景下的加密和签名技术选择指南，包括决策树、替代方案和选择建议。

目录

  1. 数据存储加密
  2. 网络传输加密
  3. 身份认证
  4. API安全
  5. 数据完整性验证
  6. 密码存储
  7. 区块链与加密货币
  8. 文件加密
  9. 数据库加密
  10. 移动应用安全

数据存储加密

场景描述

需要加密存储在磁盘、数据库或云存储中的敏感数据。

推荐方案

方案1：AES-256-GCM（推荐）

优势：

  • 加密和认证一体化
  • 性能优秀（硬件加速）
  • 广泛支持

适用场景：

  • 文件系统加密
  • 数据库字段加密
  • 云存储加密

Java示例：

// 参考"对称加密算法"文档中的AES-GCM示例
AESExample.encryptGCM(plaintext, key);

方案2：ChaCha20-Poly1305

优势：

  • 软件实现性能好
  • 无硬件依赖
  • 移动设备友好

适用场景：

  • 移动应用
  • 无AES硬件加速的设备
  • 高性能需求

方案3：SM4（国密合规）

适用场景：

  • 需要符合国密标准
  • 政府、金融等敏感行业

替代方案对比

方案性能安全性兼容性推荐度
AES-256-GCM⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
ChaCha20-Poly1305⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
AES-256-CBC⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
SM4⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

选择决策树

数据存储加密
├─ 需要国密合规？→ SM4
├─ 有AES硬件加速？→ AES-256-GCM
├─ 移动/无硬件加速？→ ChaCha20-Poly1305
└─ 兼容性优先？→ AES-256-CBC

密钥管理

关键要点：

  1. 密钥必须与数据分开存储
  2. 使用密钥管理服务（KMS）
  3. 实施密钥轮换策略
  4. 加密密钥本身（密钥加密密钥）

网络传输加密

场景描述

保护网络通信中的数据，防止窃听和篡改。

推荐方案

方案1：TLS 1.3（HTTPS）

优势：

  • 行业标准
  • 提供加密和认证
  • 性能优化

加密套件推荐：

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256

证书要求：

  • RSA-2048或ECDSA P-256
  • 有效CA签名

方案2：应用层加密

适用场景：

  • TLS之外的额外加密层
  • 端到端加密
  • 敏感数据传输

实现方式：

  • AES-256-GCM + RSA/ECC密钥交换
  • 混合加密方案

替代方案对比

方案安全性性能易用性推荐度
TLS 1.3⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
TLS 1.2⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
VPN (IPSec)⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
应用层加密⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

选择决策树

网络传输加密
├─ Web应用？→ TLS/HTTPS
├─ 需要VPN？→ IPSec或OpenVPN
├─ 端到端加密？→ 应用层加密
└─ 高安全需求？→ TLS + 应用层加密

安全建议

  1. 禁用旧协议：TLS 1.0/1.1
  2. 强密码套件：避免RC4、DES
  3. 证书管理：及时更新过期证书
  4. HSTS：强制HTTPS

身份认证

场景描述

验证用户身份，防止未授权访问。

推荐方案

方案1：JWT + HMAC-SHA256

优势：

  • 无状态
  • 性能好
  • 易于实现

适用场景：

  • API认证
  • 微服务认证
  • 移动应用

示例：

// JWT签名
String token = JWT.create()
    .withSubject(userId)
    .withExpiresAt(expiration)
    .sign(Algorithm.HMAC256(secret));

方案2：JWT + RSA签名

优势：

  • 公钥验证
  • 适合分布式系统

适用场景：

  • 多服务认证
  • 需要公钥验证的场景

方案3：OAuth 2.0 + JWT

适用场景：

  • 第三方登录
  • 单点登录（SSO）

替代方案对比

方案性能安全性可扩展性推荐度
JWT + HMAC⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
JWT + RSA⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
OAuth 2.0⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Session + Cookie⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

选择决策树

身份认证
├─ 单服务/简单场景？→ JWT + HMAC
├─ 多服务/分布式？→ JWT + RSA/ECDSA
├─ 第三方登录？→ OAuth 2.0
└─ 高安全需求？→ OAuth 2.0 + 2FA

API安全

场景描述

保护API接口，防止未授权访问和数据篡改。

推荐方案

方案1：HMAC请求签名

签名流程：

  1. 构造签名字符串（方法+路径+参数+时间戳）
  2. 使用HMAC-SHA256签名
  3. 将签名和时间戳加入请求头

优势：

  • 防止重放攻击（时间戳）
  • 防止篡改
  • 性能好

示例：

String signString = method + "\n" + path + "\n" + params + "\n" + timestamp;
String signature = HMACExample.hmacSHA256(signString, apiKey);

方案2：API Key + JWT

适用场景：

  • RESTful API
  • 需要长期访问令牌

方案3：OAuth 2.0

适用场景：

  • 第三方API访问
  • 需要细粒度权限控制

替代方案对比

方案安全性性能实现复杂度推荐度
HMAC签名⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
JWT⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
OAuth 2.0⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
Basic Auth⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

选择决策树

API安全
├─ 需要防重放？→ HMAC签名 + 时间戳
├─ 需要长期令牌？→ JWT
├─ 第三方访问？→ OAuth 2.0
└─ 简单场景？→ API Key + HTTPS

安全建议

  1. HTTPS必须：所有API必须使用HTTPS
  2. 时间戳验证：防止重放攻击（±5分钟）
  3. 速率限制：防止暴力破解
  4. 日志审计：记录所有API调用

数据完整性验证

场景描述

验证数据在传输或存储过程中未被篡改。

推荐方案

方案1：HMAC-SHA256

优势：

  • 性能好
  • 实现简单
  • 广泛支持

适用场景：

  • 文件传输完整性
  • API请求完整性
  • 消息完整性

方案2：数字签名（ECDSA/RSA）

优势：

  • 提供不可否认性
  • 公钥验证

适用场景：

  • 软件分发
  • 文档签名
  • 需要身份验证的场景

方案3：哈希值（SHA-256）

适用场景：

  • 文件校验
  • 不需要密钥的完整性验证

替代方案对比

方案防篡改身份验证不可否认推荐度
HMAC⭐⭐⭐⭐⭐⭐⭐⭐⭐❌⭐⭐⭐⭐⭐
数字签名⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
哈希值⭐⭐⭐⭐❌❌⭐⭐⭐

选择决策树

数据完整性验证
├─ 需要身份验证？→ HMAC或数字签名
├─ 需要不可否认？→ 数字签名
├─ 简单校验？→ SHA-256哈希
└─ API请求？→ HMAC-SHA256

密码存储

场景描述

安全存储用户密码，防止泄露后被破解。

推荐方案

方案1：Argon2id（推荐）

优势：

  • 抗GPU/ASIC攻击
  • 抗侧信道攻击
  • 最新标准

配置建议：

  • 内存：64MB
  • 迭代：3
  • 并行度：4

示例：

// 参考"密钥派生与随机数"文档
Argon2Hash hash = Argon2Example.hashPassword(password, 65536, 3, 4);

方案2：bcrypt

优势：

  • 成熟稳定
  • 广泛支持
  • 易实现

配置建议：

  • 成本因子：12-14

方案3：scrypt

优势：

  • 抗GPU攻击
  • 内存硬化

替代方案对比

方案抗暴力破解抗GPU性能推荐度
Argon2id⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
scrypt⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
bcrypt⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
PBKDF2⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐

选择决策树

密码存储
├─ 新项目？→ Argon2id
├─ 现有项目？→ bcrypt（逐步迁移）
├─ 高安全需求？→ Argon2id或scrypt
└─ 资源受限？→ PBKDF2

安全建议

⚠️ 禁止：

  • ❌ MD5、SHA-1等纯哈希
  • ❌ 无Salt的哈希
  • ❌ 固定Salt

✅ 必须：

  • ✓ 使用专门密码哈希算法
  • ✓ 每个密码唯一Salt
  • ✓ 足够迭代次数/成本因子

区块链与加密货币

场景描述

区块链应用中的加密和签名需求。

推荐方案

加密算法

选择：

  • 一般不直接加密交易数据
  • 使用哈希函数（SHA-256, SHA-3）
  • 使用密钥派生（PBKDF2, scrypt）

签名算法

比特币： ECDSA (secp256k1) 以太坊： ECDSA (secp256k1) 新项目： Ed25519

替代方案对比

应用签名算法哈希算法说明
比特币ECDSA (secp256k1)SHA-256 (双SHA)行业标准
以太坊ECDSA (secp256k1)Keccak-256使用SHA-3变体
新项目Ed25519BLAKE2/SHA-3性能更好

选择决策树

区块链应用
├─ 兼容比特币？→ ECDSA secp256k1
├─ 新项目？→ Ed25519
└─ 哈希算法？→ SHA-256或BLAKE2

文件加密

场景描述

加密文件，保护敏感文档。

推荐方案

方案1：AES-256-GCM

优势：

  • 高性能
  • 自动认证
  • 广泛支持

方案2：混合加密

流程：

  1. 生成随机AES密钥
  2. 使用AES加密文件
  3. 使用RSA/ECC加密AES密钥
  4. 存储加密文件和加密密钥

优势：

  • 支持多接收者
  • 密钥管理灵活

选择决策树

文件加密
├─ 单个接收者？→ AES-256-GCM
├─ 多个接收者？→ 混合加密
└─ 需要密钥轮换？→ 混合加密

数据库加密

场景描述

加密数据库中的敏感字段。

推荐方案

字段级加密：AES-256-CBC或AES-256-GCM

考虑因素：

  • 索引：加密字段无法直接索引
  • 查询：加密后无法模糊查询
  • 性能：加密/解密开销

方案选择：

  • 透明加密（TDE） ：数据库层面自动加密
  • 应用层加密：应用代码中加密
  • 字段加密：敏感字段单独加密

替代方案对比

方案性能安全性查询能力推荐度
TDE⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
应用层加密⭐⭐⭐⭐⭐⭐⭐⭐❌⭐⭐⭐
字段加密⭐⭐⭐⭐⭐⭐⭐⭐❌⭐⭐⭐

选择决策树

数据库加密
├─ 需要查询能力？→ TDE
├─ 最高安全？→ 应用层加密
└─ 平衡方案？→ 字段加密

移动应用安全

场景描述

移动应用中的加密和签名需求。

推荐方案

加密算法

首选： ChaCha20-Poly1305

  • 无硬件依赖
  • 软件实现性能好

备选： AES-128-GCM

  • 现代设备有硬件加速

签名算法

首选： ECDSA P-256

  • 密钥小
  • 性能好
  • 电池友好

替代方案对比

场景推荐方案原因
数据传输ChaCha20-Poly1305软件性能好
本地存储AES-256-GCM安全性高
API签名HMAC-SHA256性能好
应用签名ECDSA P-256证书小

综合选择指南

快速决策矩阵

场景加密签名MAC哈希
数据存储AES-256-GCM--SHA-256
网络传输TLS 1.3ECDSA/RSA-SHA-256
API安全HTTPS-HMAC-SHA256SHA-256
密码存储---Argon2id
文件加密AES-256-GCMRSA/ECC-SHA-256
数据库加密AES-256-CBC/GCM--SHA-256
移动应用ChaCha20-Poly1305ECDSAHMACSHA-256

通用原则

  1. 新项目优先使用现代算法
  2. 根据场景选择，不要过度设计
  3. 性能与安全性平衡
  4. 考虑合规要求
  5. 密钥管理是关键

总结

关键要点

  1. 数据存储：AES-256-GCM或ChaCha20-Poly1305
  2. 网络传输：TLS 1.3
  3. API安全：HMAC-SHA256签名
  4. 密码存储：Argon2id
  5. 数字签名：ECDSA或Ed25519
  6. 移动应用：ChaCha20-Poly1305 + ECDSA

避免使用

  • ❌ MD5、SHA-1（已不安全）
  • ❌ DES、3DES（已过时）
  • ❌ RSA-1024（密钥过短）
  • ❌ ECB模式（不安全）
  • ❌ 纯哈希存储密码（不安全）
avatar
文章
阅读
粉丝