Android学习总结之网络加密算法篇

一、HTTP 协议（Hypertext Transfer Protocol）

1. 核心特性

• 应用层协议：基于 TCP/IP，用于客户端（如浏览器、Android 应用）与服务器间的超文本传输。
• 无状态：默认每次请求独立，需通过 Cookie、Session 或 Token 实现状态管理（如登录认证）。
• 默认端口：80（明文传输，不安全），HTTPS 基于 443 端口（加密传输）。

2. 版本演进

• HTTP/1.0：短连接（每次请求新建 TCP 连接，效率低）。
• HTTP/1.1：
  • 长连接（Persistent Connection）：通过Connection: keep-alive复用 TCP 连接，减少握手开销。
  • 管道化（Pipelining）：客户端可连续发送多个请求，无需等待响应，但因队头阻塞问题未广泛应用。
• HTTP/2.0（Android 5.0 + 支持）：
  • 二进制分帧：将数据拆分为二进制帧，实现多路复用（多个请求在同一连接并行处理，解决队头阻塞）。
  • 头部压缩（HPACK）：减少重复 HTTP 头部传输，提升效率。
  • 服务器推送：主动向客户端推送资源（如 HTML 引用的 CSS/JS），优化加载速度。

3. HTTPS（HTTP over TLS/SSL）

• 本质：HTTP + TLS/SSL 加密层，确保数据传输的机密性、完整性、认证性。
• 工作流程（面试高频问题）：
  1. 客户端发起 HTTPS 请求，服务器返回证书（含公钥）。
  2. 客户端验证证书有效性（CA 签名、域名匹配、有效期）。
  3. 客户端生成随机对称密钥（如 AES 密钥），用服务器公钥加密后发送。
  4. 双方使用对称密钥加密通信（后续数据通过高效的对称加密传输）。

二、常见加密协议

1. SSL（Secure Sockets Layer）

• 历史：Netscape 开发，已淘汰（SSL 3.0 存在 POODLE 等漏洞）。
• 作用：在传输层对数据加密，提供连接安全。

2. TLS（Transport Layer Security）

• SSL 的继任者，当前主流版本为 TLS 1.2（Android 4.1 + 支持）和 TLS 1.3（Android 10 + 支持）。
• 核心功能：
  • 加密算法协商：客户端与服务器通过 “握手” 确定使用的加密套件（如 ECDHE-RSA-AES256-GCM-SHA384）。
  • 解决的问题：
    • 机密性：对称加密算法（如 AES）加密数据。
    • 完整性：哈希算法（如 SHA-256）生成消息摘要，防止篡改。
    • 认证性：非对称加密算法（如 RSA）验证服务器身份（通过 CA 证书），可选客户端认证。
• Android 中的应用：
  • 网络请求库（OkHttp、Volley）默认支持 TLS，需注意兼容旧版本时的漏洞风险（如禁用 TLS 1.0/1.1）。
  • 可通过SSLSocketFactory或TrustManager自定义证书校验（如 SSL Pinning，防止中间人攻击）。

三、加密算法分类与对比

1. 对称加密算法（Symmetric Encryption）

• 核心原理：加密和解密使用同一密钥，基于 “混淆”（Confusion）和 “扩散”（Diffusion）理论，通过复杂的非线性变换打乱数据。
• 典型算法：
  • AES（高级加密标准）：
    • 分组加密（Block Cipher），支持 128/192/256 位密钥，安全性和效率俱佳，是 Android 平台首选。
    • 分组模式（影响安全性和性能）：
      • CBC（需初始化向量 IV，支持数据认证但不支持并行）
      • GCM（推荐！结合认证功能，支持 AEAD 模式，提供完整性校验和抗重放攻击，Android 中Cipher.getInstance("AES/GCM/NoPadding")）
      • CTR（计数器模式，适合高速场景，如流媒体）
  • 3DES：三重 DES，通过 3 次加密提高安全性，但密钥长度仅 168 位（实际有效 112 位），性能差，已被 AES 取代。
• 优缺点：
  • 优点：速度极快（比非对称快 1000 倍 +），适合大量数据加密（如文件、网络传输载荷）。
  • 缺点：密钥需安全传输和存储（核心痛点！Android 中常用 Keystore 配合密钥库加密密钥）。
• Android 应用：
  • 数据存储加密：SharedPreferences 加密、文件加密（FileInputStream+AES-GCM）。
  • 网络通信：HTTPS 传输层用 AES 加密 HTTP 载荷（TLS 1.2 + 默认 AES-GCM）。

2. 非对称加密算法（Asymmetric Encryption）

• 核心原理：基于数学难题（如大数分解、离散对数），生成公钥（加密）和私钥（解密），私钥不可从公钥推导。
• 典型算法：
  • RSA：
    • 基于大整数分解困难性，密钥长度需≥2048 位（1024 位已不安全）。
    • 应用：数字签名（私钥签名，公钥验证）、密钥交换（如 HTTPS 中用服务器公钥加密 AES 会话密钥）。
    • 缺点：速度慢，仅适合小数据（如密钥、摘要）加密，Android 中KeyPairGenerator.getInstance("RSA")生成密钥对。
  • DSA（DSS）：
    • 仅用于数字签名，不支持加密，安全性基于离散对数问题，密钥长度≥2048 位。
  • ECC（椭圆曲线加密）：
    • 更短密钥实现同等安全性（如 256 位 ECC≈3072 位 RSA），Android 从 API 18 开始支持，TLS 1.3 首选（减少握手开销）。
• 核心应用：
  • 密钥交换：HTTPS 中客户端生成随机 AES 密钥，用服务器公钥加密后传输（解决对称密钥传输问题）。
  • 数字签名：服务器用私钥对证书摘要签名，客户端用公钥验证（确保证书未被篡改，如 Android 的 APK 签名）。
• 安全性关键：私钥必须绝对安全（Android 建议用AndroidKeystore硬件保护，如 KeyMaster 模块）。

3. 哈希算法（Hash Function）

• 核心特性：
  • 单向性（无法逆向还原原文）、定长输出、抗碰撞（不同输入几乎不会得到相同哈希值）。
• 典型算法：
  • SHA-256（SHA-2 子集）：
    • 输出 256 位哈希值，抗碰撞能力强，Android 中推荐用于校验文件完整性（如 APK 校验）、生成 HMAC 密钥。
    • 实现：MessageDigest.getInstance("SHA-256")。
  • MD5/SHA-1：
    • MD5 已被证明可碰撞（存在恶意构造相同哈希的文件），SHA-1 在 2017 年被攻破，Android P（API 28）后禁止在 TLS 中使用，仅允许内部校验（需配合盐值）。
• 扩展应用：
  • HMAC（密钥哈希）：结合密钥和哈希，用于消息认证（如 Android 网络请求签名）。
  • PBKDF2：密钥派生函数（Key Derivation Function），用于密码加密（如用户密码存储前需用 PBKDF2 + 盐值多次迭代）。
• 安全性陷阱：哈希值不可直接存储密码！必须加盐（Salt）+ 迭代（如 Android 的KeyStore自动处理）。

二、混合加密方案（工程核心）

1. HTTPS 中的经典组合

1. 握手阶段：
   • 客户端与服务器用非对称加密（RSA/ECC）交换 AES 会话密钥（解决对称密钥传输问题）。
   • 服务器发送数字证书（含公钥），客户端验证证书签名（用 CA 公钥，防止中间人伪造公钥）。
2. 数据传输：
   • 用 AES-GCM 对称加密实际数据（高效），同时用 SHA-256 生成哈希校验完整性（防篡改）。

2. Android 数据存储最佳实践

• 密钥管理：
  • 对称密钥用AndroidKeystore存储（硬件级保护，私钥不可导出），例如：

    KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
    keyStore.load(null);
    if (!keyStore.containsAlias("aes_key")) {
        KeyGenerator keyGenerator = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
        keyGenerator.init(new KeyGenParameterSpec.Builder(
                "aes_key",
                KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
                .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
                .setKeySize(256)
                .setUserAuthenticationRequired(true) // 指纹/密码验证
                .build());
        keyGenerator.generateKey();
    }
    

• 数据加密：
  • 用 AES-GCM 加密文件或 SharedPreferences，确保 IV 每次随机生成并与密文一起存储。

三、安全性对比与选型建议

算法类型	代表算法	密钥长度	核心应用场景	Android 中禁用 / 推荐情况
对称加密	AES-GCM	128/192/256	大量数据加密（网络 / 存储）	推荐，TLS 1.3 默认
对称加密	3DES	168	遗留系统兼容	不推荐，已过时
非对称加密	RSA	2048/4096	密钥交换、数字签名	推荐（2048 位 +），ECC 更高效
非对称加密	ECC	256/384	移动设备（低功耗、短密钥）	Android 6.0 + 支持，TLS 1.3 首选
哈希算法	SHA-256	-	完整性校验、HMAC	推荐
哈希算法	MD5/SHA-1	-	仅内部测试（需加盐）	Android P 后 TLS 禁用

四、面试高频问题拆解

1. “为什么 HTTPS 同时使用对称和非对称加密？”

   • 答：对称加密速度快，适合加密大量数据；非对称加密解决对称密钥的安全传输问题（公钥可公开，私钥仅服务器持有）。两者结合兼顾效率和安全性。

2. “AES 的 GCM 模式相比 CBC 有什么优势？”

   • 答：GCM 是 AEAD 模式，提供认证加密（加密同时校验完整性和真实性），抗重放攻击，无需额外 HMAC，性能和安全性均优于 CBC（CBC 仅加密，需单独实现 MAC）。

3. “为什么不建议在 Android 中使用 MD5？”

   • 答：MD5 已被证明存在碰撞攻击（可构造不同文件生成相同 MD5 值），无法保证数据完整性，Android 从 API 28 开始禁止在 TLS 中使用，推荐用 SHA-256 及以上。

4. “如何在 Android 中安全存储加密密钥？”

   • 答：使用AndroidKeystore（硬件支持时存储在可信执行环境 TEE），配合生物认证（如指纹）和密钥用途限制（仅加密 / 解密），避免硬编码或明文存储。
5. Android 中如何处理证书校验？如何实现 SSL Pinning？

        基础校验：系统默认通过 CA 证书链验证服务器证书有效性。

        SSL Pinning：自定义TrustManager，将服务器公钥 / 证书固定在客户端（如 OkHttp 的CertificatePinner），防止中间人伪造证书。

       为什么 SHA-256 比 MD5 更安全？

摘要长度更长，碰撞难度呈指数级增长（MD5 碰撞可在数小时内完成，SHA-256 理论上需万亿年），且 MD5 存在已知的构造碰撞方法。

     在 Android 中存储密钥时需要注意什么？

       避免硬编码在代码或明文存储在文件 / SharedPreferences 中。

        应使用AndroidKeystore（支持硬件安全模块，密钥不可导出），结合加密文件（如 AES 加密 SharedPreferences）。

面试扩展追问：

一、原理类高频问题：HTTPS 如何保证数据安全？（必考题）

回答要点：

1. 加密协议栈：
   HTTPS = HTTP + TLS/SSL，核心通过 TLS 握手过程 结合对称加密与非对称加密：

   • 非对称加密（RSA/ECDSA）：客户端向服务端请求公钥，客户端生成随机对称密钥（如 AES 密钥），用公钥加密后传输给服务端，服务端用私钥解密。
   • 对称加密（AES-GCM/ChaCha20）：握手后用对称密钥加密所有数据传输，解决非对称加密效率低的问题。
   • 哈希算法（SHA-256）：对传输数据生成摘要，结合 HMAC 进行完整性校验，防止篡改。

2. Android 特殊点：

   • 需处理证书校验（避免默认信任所有证书，防止中间人攻击），可通过HostnameVerifier和自定义TrustManager实现严格校验。
   • 适配 TLS 版本（Android 5.0 + 默认支持 TLS 1.2，需兼容旧版本时注意安全性降级风险）。

二、对比类问题：对称加密 vs 非对称加密，为何 HTTPS 要结合使用？（经典对比题）

回答要点：

特性	对称加密（AES/3DES）	非对称加密（RSA/ECC）
密钥数量	单密钥（加密 / 解密同一密钥）	密钥对（公钥公开，私钥私密）
效率	高（适合大量数据加密）	低（仅适合小数据，如密钥传输）
安全性	密钥传输不安全（需提前共享）	私钥安全则整体安全（依赖密钥对生成强度）
Android 应用	本地存储敏感数据（如用户令牌、配置文件）	网络传输中加密对称密钥、数字签名（如 APK 签名验证）

延伸追问：

• 为何不直接用非对称加密传输所有数据？
  答：非对称加密的计算复杂度高（RSA-2048 加密速度约为 AES 的 1/1000），大量数据传输会导致性能瓶颈，因此仅用于 “保护对称密钥的传输”，形成优势互补。

三、应用类问题：Android 中如何安全存储密钥？（实操题）

回答要点：

1. 避免硬编码：

   • 禁止将密钥直接写在代码或配置文件中（可被逆向工程获取）。
   • 正确做法：使用 Android 官方提供的 Keystore（AndroidKeystoreProvider）存储密钥，密钥生成后无法导出，且支持硬件安全模块（如 TrustZone）。

2. 密钥生成策略：

   • 对称密钥：使用KeyGenerator.getInstance("AES")生成，配合KeyProperties设置密钥用途（如仅限加密 / 解密）。
   • 非对称密钥：通过KeyPairGenerator生成 RSA/ECC 密钥对，私钥默认存储在可信执行环境（TEE）中，无法被应用层直接读取。

3. 实战案例（面试常问）：

   • 场景：存储用户登录令牌（Token）。
   • 方案：
     1. 用 AES 生成对称密钥，存储在 Keystore 中；
     2. 令牌用 AES 加密后存储在 SharedPreferences / 文件中；
     3. 解密时从 Keystore 获取密钥，避免明文存储风险。

四、安全风险类问题：MD5/SHA1 为何不安全？Android 中如何替代？（陷阱题）

回答要点：

1. 哈希算法缺陷：

   • MD5：已被证明可快速构造碰撞（2017 年 Google 宣布禁用 MD5 签名），Android 中若用于文件校验或密码加密，存在被伪造风险。
   • SHA1：2018 年 CA/B 论坛要求 HTTPS 禁用 SHA1，Android 9.0（API 28）后默认禁止使用 SHA1 证书，需升级至 SHA-256 及以上。

2. 正确实践：

   • 文件校验 / 摘要：使用SHA-256/SHA-512，配合 HMAC（如 HmacSHA256）增强安全性。
   • 密码存储：禁止直接存储哈希值，需加盐（Salt）+ 迭代（如 PBKDF2、BCrypt），Android Jetpack Security 组件提供EncryptedSharedPreferences可简化安全存储。

3. 面试陷阱：

   • 问：“APK 签名用的是哪种算法？能否用 MD5？”
     答：APK 签名使用非对称加密（RSA/ECC）+ 哈希（SHA-256），Android 7.0 后要求 v2 签名必须使用 SHA-256，MD5 仅用于兼容性，不推荐新应用使用。

五、扩展问题：如何防止 Android 应用中的中间人攻击？（高阶题）

回答要点：

1. 证书锁定（Certificate Pinning）：

   • 原理：在应用中固定服务端公钥 / 证书，验证时不依赖系统 CA 证书，防止伪造证书攻击。
   • 实现：通过 OkHttp 的CertificatePinner或 TrustManager 自定义校验逻辑，如：

     CertificatePinner certificatePinner = new CertificatePinner.Builder()
         .add("yourdomain.com", "sha256/...") // 固定证书的SHA-256指纹
         .build();
     OkHttpClient client = new OkHttpClient.Builder()
         .certificatePinner(certificatePinner)
         .build();
     

2. HTTPS 严格传输（HSTS）：

   • 服务端返回Strict-Transport-Security头，告知客户端后续仅通过 HTTPS 通信，避免降级到 HTTP。

3. Android 安全配置：

   • 在AndroidManifest.xml中设置android:usesCleartextTraffic="false"（Android 9.0 + 强制 HTTPS），配合android:networkSecurityConfig自定义证书策略。

五、总结

加密算法的选择需平衡安全性、性能、应用场景：

• 大量数据加密用AES-GCM（首选），密钥交换用ECC/RSA（ECC 更适合移动设备），完整性校验用SHA-256。
• Android 开发中，始终遵循官方最佳实践（如AndroidKeystore、TLS 1.2+），避免使用过时算法（MD5/SHA-1/3DES），并关注密钥管理的全生命周期（生成、存储、更新、销毁）。