在移动端与360后端AI服务通信时，需要传输模型参数或用户数据。请设计一个安全的通信方案，考虑HTTPS、加密、认证，以及如何处理跨域请求（如果使用跨端框架）。

360移动开发工程师(跨端)-AI应用方向难度：中等

答案

1) 【一句话结论】

采用TLS 1.3加密的HTTPS作为基础，结合客户端证书验证（TLS pinning）确保服务器身份真实，通过JWT实现客户端认证，对敏感数据（模型参数、用户数据）用AES-256-CBC加密（IV随机生成并传输），配合CORS策略处理跨域，构建端到端安全通信链路。

2) 【原理/概念讲解】

HTTPS与TLS 1.3：HTTPS是HTTP+TLS（传输层安全协议），TLS 1.3相比旧版本，支持前向保密性（即使密钥泄露，旧密文也无法解密），减少中间人攻击后密文泄露风险，是移动端安全传输的基石。
客户端证书验证（TLS pinning）：类似“锁的钥匙只能用指定的，防止换锁后用旧钥匙开”。客户端预先存储服务器的公钥或证书指纹，连接时验证服务器的证书是否匹配，避免中间人用伪造证书冒充后端。
加密套件选择：优先使用ECDSA（椭圆曲线数字签名算法，如P-256）或强RSA（2048位），避免弱算法（如RSA 1024位），确保TLS握手阶段的安全。
密钥轮换策略：加密密钥每90天更换一次，传输密钥用非对称加密（如RSA）或Diffie-Hellman密钥交换，避免密钥长期使用导致安全风险。
AES-256的IV处理：IV（初始化向量）需随机生成（如用/dev/urandom），附在请求头（如X-AES-IV: base64(IV)），避免IV重复导致加密失败或泄露，确保加密强度。

3) 【对比与适用场景】

对比项	TLS 1.3（HTTPS）	TLS 1.2（旧版本）
优势	前向保密性（密钥泄露不影响旧密文）、握手效率高、支持0-RTT（零往返时间）	无前向保密性（密钥泄露导致旧密文可解密）、握手效率较低
加密算法	优先ECDSA（P-256）、RSA 2048位，支持AES-256-GCM（推荐，带认证）	优先RSA 1024位、AES-128-GCM，支持弱算法（如RSA 1024位）
认证方式	可结合客户端证书（TLS pinning）、JWT、OAuth2.0令牌	仅支持服务器证书验证（易被中间人伪造）
使用场景	敏感数据传输（模型参数、用户数据、API密钥）	非敏感数据传输（如静态资源）
注意点	需配置完整证书链（CA验证），客户端需实现TLS pinning	证书过期或弱算法可能导致安全漏洞

4) 【示例】

请求示例（用curl模拟，含加密与认证）

请求URL：https://api.360ai.com/v1/predict
请求头：
- Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyI6I...（JWT，包含用户ID、exp、签名）
- X-TLS-Pinning: base64(服务器证书指纹)（客户端证书验证）
- Content-Type: application/json
- X-AES-IV: base64(随机IV)（AES-256的IV）

请求体（加密后）：

{
  "model_params": "base64(AES-256-CBC加密后的模型参数)",
  "user_data": "base64(AES-256-CBC加密后的用户数据)"
}

后端处理流程：
1. 验证JWT签名（确认用户身份）；
2. 检查X-TLS-Pinning是否匹配服务器证书（防止中间人）；
3. 解密model_params和user_data（用AES-256-CBC，IV来自请求头）；
4. 处理预测请求。

5) 【面试口播版答案】

在移动端与360后端AI服务通信时，核心方案是采用TLS 1.3的HTTPS加密传输，确保数据传输安全。首先，通过客户端证书验证（TLS pinning）确保服务器身份真实，避免中间人攻击。然后，用JWT实现客户端认证，后端验证签名后确认用户身份。对于敏感数据（如模型参数、用户数据），用AES-256-CBC对称加密，IV随机生成并附在请求头，确保加密强度。跨域请求通过CORS策略，允许指定域的请求，通过响应头控制。这样全链路安全，既保护数据隐私，又符合跨域要求。

6) 【追问清单】

问：如何管理加密密钥？
答：密钥存储在设备安全存储（如iOS Keychain、Android Keystore），定期（每90天）轮换，避免明文存储。
问：TLS pinning如何实现？
答：客户端预先获取服务器的公钥或证书指纹，连接时验证服务器的证书是否匹配，防止中间人用伪造证书。
问：跨域时，如果后端允许所有域访问，有什么风险？
答：可能导致CSRF攻击，应严格限制，只允许360的域名，并设置Access-Control-Allow-Credentials。
问：HTTPS证书如何选择？
答：使用Let's Encrypt或企业CA，确保证书链完整，浏览器验证通过，避免中间人用自签名证书。
问：AES-256加密时，IV泄露有什么风险？
答：IV重复可能导致加密数据被破解，必须随机生成并传输。

7) 【常见坑/雷区】

忽略客户端证书验证（TLS pinning）：未检查证书颁发机构（CA），导致中间人攻击，应验证证书链完整性。
密钥存储在明文文件：导致密钥泄露，应使用设备安全存储（如Keychain/Keystore）。
IV未随机生成或未传输：导致加密失败或IV泄露，应使用/dev/urandom生成IV并附在请求头。
JWT使用HS256但密钥泄露：导致令牌伪造，应使用HS384/512或RSA签名。
跨域配置错误：如允许所有域访问但未设置Access-Control-Allow-Credentials，导致带cookie的请求失败。