Java分块上传与加密存储实战：AES/GCM与密钥管理详解

我先泼个冷水：分块上传这件事，网上教程一抓一大把，但能把“加密存储”和“分块上传”真正揉在一起讲清楚的，少之又少。大多数方案是先把整个文件塞进内存，加密完再分块，遇到大文件直接内存爆炸；要么就是分块上传做完了，落盘文件却是明文，加密成了摆设。

这篇文章我想从实际项目出发，聊聊在 JAVA 生态下，怎么把“分块上传”和“加密存储”这两件事优雅地结合起来。先给结论：核心在于解决三个问题——分块边界与加密算法的兼容、密钥如何安全管理、已上传分块如何校验与合并。适合正在做文件系统、网盘服务、OSS 中间层的后端同学参考，也适合准备面试时被问到“大文件上传怎么做”时拿出来当谈资。

1. 整体设计与思路拆解

1.1 为什么分块上传必须搭配加密存储

很多人在做文件上传时有个误区：以为分块上传只是解决了“大文件传输超时”和“断点续传”这两个问题。实际上，分块上传更大的价值在于——它给了你一个在服务端执行加密、校验、落盘策略的完整控制窗口。

我见过不少项目，文件上传用的是分块，但文件在服务端临时目录里躺着的却是明文。这就导致一个问题：分块临时文件的安全窗口期太长。攻击者如果拿到了临时目录的读取权限，就能在文件合并之前把内容全部捞走。更麻烦的是，如果某个分块上传失败又被重传，前后两个分块是同一段数据的不同密文，很容易被用来做密文分析。

所以我在设计分块上传方案时，坚持一个原则：分块到达服务端的那一刻，立即加密，明文分块只在内存中存活，不落盘。这样整个生命周期里，明文暴露的时间被压缩到最短。

1.2 技术选型的核心矛盾：分块与加密引擎的配合

这里就得说一个很多人踩过的坑：AES 这类分组加密算法，天然有“块”的概念（AES 是 16 字节一组），但分块上传的“块”是业务概念（比如每块 5MB），两者根本不是一回事。

如果直接拿加密算法去加密每一个 5MB 的业务分块，会带来两个问题：

• 每个分块独立加密，会引入额外的初始向量（IV）存储成本，而且分块之间的加密上下文断裂，攻击者可以尝试重放、替换分块。
• 如果为了保持加密上下文的连续性而把所有分块拼起来再加密，那分块上传就失去了意义——你还是要等在内存里凑齐整个文件。

我的做法是对每个业务分块做独立加密，但密钥体系用密钥派生树（Key Derivation Tree）串联起来。具体来说：

• 每个文件上传任务生成一个“文件主密钥”（File Master Key），用主密钥加密每个分块时，使用不同的 IV，IV 由分块序号和时间戳做 HMAC 派生。
• 分块密文落盘时，存储的是“密文 + IV + 分块校验码”，但这个校验码不是普通 MD5，而是基于主密钥的 HMAC-SHA256，防止分块被篡改或替换。
• 文件合并时，从所有分块密文恢复明文，再对完整明文做一次整体校验。校验通过后，重新用一个“最终存储密钥”加密整个文件，写入正式存储区，并删除临时密文分块。

这个方案的好处是：临时存储区里即使被拖库，攻击者拿到的也只是孤立的分块密文和密文校验码，没有主密钥就无法还原文件，更无法伪造分块。

2. 核心细节解析与实操要点

2.1 加密算法选型：别再纠结 AES/CBC 还是 AES/GCM 了

关于加密算法，我在项目里吃过亏。早期图省事用 AES/CBC，结果每次加密都要处理填充（Padding）问题，还得自己维护 IV 的随机性和完整性，稍不注意就写出“IV 固定”这种致命漏洞。后来切到 AES/GCM（Galois/Counter Mode），一下子清爽了。

AES/GCM 是 AEAD（Authenticated Encryption with Associated Data）算法，它同时提供加密和完整性校验。也就是说，你加密完拿到的不仅是密文，还有一个认证标签（Auth Tag），解密的时候如果数据被篡改，认证会直接失败。这对分块上传场景尤其重要——因为分块在临时存储区、网络传输、合并过程中多次流转，被篡改的风险面很大。

参数上我建议：

• 密钥长度：AES-256。不要省，性能差距可以忽略，但安全边界提升明显。
• IV 长度：GCM 模式下 IV 固定 96 位（12 字节）。
• Auth Tag 长度：128 位（16 字节）。
• Additional Authenticated Data（AAD）：可以把分块序号、上传任务 ID 塞进去，绑定分块的上下文，防止分块被跨任务复用。

JAVA 里使用 AES/GCM 的代码很直接：Cipher.getInstance("AES/GCM/NoPadding")。

2.2 分块大小怎么定：不是越大越好，也不是越小越稳

分块大小是分块上传里最容易被拍脑袋决定的参数。我见过有人图省事直接定 10MB，结果上传到一半网络抖动，客户端在重连时发现服务端已经把 10MB 临时文件写过磁盘，又要重新传；也有人定 512KB，结果分块数量爆炸，元数据管理开销比数据本身还大。

我的经验公式有三个约束条件：

• 内存约束：服务端并发处理的分块数量 × 分块大小 ≤ 堆内存安全余量。比如 JVM 堆给了 2GB，并发上传 20 个任务，每个任务同时处理 2 个分块，那你单个分块就不能超过 2GB / 40 = 50MB。实际还要留出加密缓冲区和对象开销，我一般再打个对折。
• 网络约束：分块大小要能让 TCP 拥塞窗口充分展开。1MB 以上的分块在网络传输时表现差异不大，但 512KB 以下经常出现带宽利用率不足的问题。
• 重传代价：分块越大，失败重传的成本越高；分块越小，元数据越碎。这里要找一个平衡点。

我目前的默认配置是 5MB 每块，同时在服务端做限制：允许客户端上报分块大小，但只能在 1MB ~ 20MB 之间选择，超出范围直接拒绝上传请求。

2.3 密钥管理的三种方案，按项目阶段选

密钥管理是加密存储里最容易被“简化”的部分。很多人图省事，把密钥写死在配置文件里，或者用固定的字符串当密钥。这种做法等于把保险柜的钥匙挂在保险柜门口。

我按项目复杂度整理了三种方案：

对于绝大多数 JAVA 分块上传项目，我建议直接上 KMS，哪怕用的是云厂商的简单版 KMS。原因很简单：分块上传天然是多节点协作的场景，密钥如果存放在应用本地，那每个应用节点都需要有密钥访问权限，权限边界一多，泄露面就大。KMS 模式下，应用节点只持有对 KMS 的访问凭证，不持有明文密钥。

对了，如果你处在项目早期，确实不想引入 KMS，那至少做到一点：不要把密钥硬编码在代码里，用环境变量或独立的密钥文件，并且和代码仓库严格隔离。

3. 实操过程与核心环节实现

3.1 上传前的初始化会话：密钥前缀与元数据登记

在实际编码前，先得想清楚一件事：服务端怎么知道一个分块属于哪个文件？怎么知道第 3 块在重传时和第 5 块用的是不是同一把密钥？

我的做法是，客户端先调用一个初始化接口，服务端返回一个 uploadId，同时内部生成文件主密钥并暂存在内存缓存或 Redis 中（设置合理的过期时间，比如 24 小时）。这个阶段的核心代码大致长这样：

java复制// UploadSession.java
public class UploadSession {
    private String uploadId;
    private byte[] fileMasterKey;       // AES-256 主密钥
    private String fileName;
    private long fileSize;
    private int chunkSize;
    private int totalChunks;
    private Set<Integer> uploadedChunks; // 已上传的分块序号集合
    private long createdAt;
}

初始化接口的关键点是：不要在响应中透出任何密钥材料。uploadId 可以返回给客户端，fileMasterKey 只存在于服务端内存。客户端后续上传分块时，只需要携带 uploadId 和分块序号即可。

3.2 分块加密落盘：AES/GCM 的实际用法

分块上传的接口收到每个分块后，按下面的链路处理：

1. 校验 uploadId 和分块序号是否合法。
2. 从会话中取出文件主密钥。
3. 根据分块序号派生 IV：iv = HMAC-SHA256(fileMasterKey, uploadId + chunkIndex) 取前 12 字节。注意 IV 的随机性来源是伪随机函数，而不是直接用序号，避免可预测 IV 的安全问题。
4. 用 AES/GCM 加密分块明文，得到密文和认证标签。
5. 落盘到临时目录，文件命名为 {uploadId}_{chunkIndex}.enc。
6. 更新 Redis 中的分块状态，标记第 chunkIndex 块已完成。

核心代码大致如下：

java复制// ChunkCipher.java
public class ChunkCipher {
    private static final int GCM_IV_LENGTH = 12;
    private static final int GCM_TAG_LENGTH = 128;

    public EncryptedChunk encrypt(byte[] plainChunk, byte[] masterKey, 
                                  String uploadId, int chunkIndex) throws Exception {
        // 1. 派生本分块的 IV
        Mac mac = Mac.getInstance("HmacSHA256");
        mac.init(new SecretKeySpec(masterKey, "HmacSHA256"));
        mac.update(uploadId.getBytes(StandardCharsets.UTF_8));
        mac.update((byte) (chunkIndex >> 24));
        mac.update((byte) (chunkIndex >> 16));
        mac.update((byte) (chunkIndex >> 8));
        mac.update((byte) chunkIndex);
        byte[] iv = Arrays.copyOf(mac.doFinal(), GCM_IV_LENGTH);

        // 2. AES/GCM 加密
        Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
        SecretKeySpec keySpec = new SecretKeySpec(masterKey, "AES");
        GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH, iv);
        cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec);
        cipher.updateAAD(uploadId.getBytes(StandardCharsets.UTF_8));

        byte[] ciphertext = cipher.doFinal(plainChunk);
        return new EncryptedChunk(ciphertext, iv);
    }
}

这里有个细节值得注意：cipher.updateAAD(uploadId.getBytes(...)) 把 uploadId 绑定到了认证数据里。这样即使攻击者把一个分块的密文搬到另一个 uploadId 会话下尝试合并，认证也会失败。这个细节用极小的成本换来了很强的语义安全性。

3.3 分块合并与最终存储：二次加密还是直接搬移

所有分块上传完成后，需要把分块密文合并成完整的文件。这里我想讨论一个很多人没考虑到的设计选择：合并后的完整文件，是直接用各分块的密文拼接，还是重新加密一遍？

如果直接把分块密文拼接，节省了 CPU 开销，但存在一个问题：分块边界的密文模式是可知的。因为每个分块的长度是固定的（比如 5MB），攻击者拿到合并文件后，可以推断出原始文件的分块位置，进而利用分块之间的统计特征做分析。对于某些敏感数据，这是不可接受的。

我的建议是：合并后的文件用最终存储密钥重新加密一次。这个“最终存储密钥”是独立生成的，和上传会话的文件主密钥完全不同。重新加密的代价是 CPU 会增加一部分，但换来的是：存储层的数据密文和传输层的分块密文在密码学上是完全独立的，两者的密钥体系互不关联，即使存储区泄露也无法追溯到临时分块。

合并和最终加密的流程：

1. 从 Redis 或数据库中校验所有分块是否已完整上传。
2. 按分块序号顺序读取密文，逐个 AES/GCM 解密，拿到明文流。
3. 同时计算完整明文的 SHA-256 指纹（这也就是“秒传”功能的基础）。
4. 用最终存储密钥重新加密整个明文流，写入正式存储区。
5. 删除临时分块文件，清除 Redis 中的上传会话。

这里要注意，合并时不能直接把所有分块一次性读入内存，否则分块上传节省的内存优势就废了。正确做法是用流式读取：CipherInputStream + ChunkedInputStream 逐段处理。

java复制// FileMerger.java 核心片段
public void mergeAndEncrypt(UploadSession session, OutputStream finalStorageStream) throws Exception {
    // 用最终存储密钥（可以从KMS获取）加密整个文件流
    Cipher finalCipher = Cipher.getInstance("AES/GCM/NoPadding");
    finalCipher.init(Cipher.ENCRYPT_MODE, finalStorageKeySpec, finalGcmSpec);
    
    try (CipherOutputStream cipherOut = new CipherOutputStream(finalStorageStream, finalCipher)) {
        for (int i = 0; i < session.getTotalChunks(); i++) {
            byte[] encryptedChunk = readChunk(session.getUploadId(), i);
            byte[] plainChunk = chunkCipher.decrypt(encryptedChunk, session.getFileMasterKey(),
                                                     session.getUploadId(), i);
            cipherOut.write(plainChunk);  // 流式写入，不驻留内存
        }
    }
}

3.4 并发分块上传：顺序怎么保证

分块上传和并发是两个高频组合词。但加密存储场景下，我建议并发控制在客户端并发、服务端串行校验这个粒度。也就是说，客户端可以同时上传多个分块，但服务端在写入临时目录和更新分块状态时，要保证同一分块序号不会被重复写。

实现上，用 Redis 的 SETNX（Set if Not Exists）做分块序号的幂等控制：客户端上传分块时带上 uploadId + chunkIndex 的 key，服务端先尝试写入这个 key，如果成功则继续处理，失败则说明已上传过，直接返回重传忽略。

要注意的是，分块合并阶段必须串行。并发合并会带来灾难性的结果：多个线程同时读取同样的分块密文，解密后拼接顺序错乱，最终文件损坏，而且这种损坏在加密存储模式下排查起来极其痛苦——因为报错不是“文件字节不对”，而是“解密认证失败”或“最终文件指纹不匹配”。

4. 常见问题与排查技巧实录

4.1 解密报错 javax.crypto.AEADBadTagException：绝大部分是数据被篡改

这个异常可以说是 AES/GCM 场景下的“老朋友”了。出现 AEADBadTagException（或者在较老的 JDK 版本里表现为 BadPaddingException），基本可以断定是下面三个原因之一：

• 分块的密文内容在传输或存储过程中被修改过。
• IV 和加密时不一致。注意我这里说的不一致，不只是“内容变了”，还包括“字节序错了”。比如在序列化时把 IV 里的 12 个字节拆开用了，或者做了 Base64 编解码时少了个等号。
• AAD 数据不一致。这个最容易忽略，比如加密时 AAD 是字符串 uploadId 的 UTF-8 字节，解密时却用了 uploadId.getBytes() 但 JVM 默认字符集不是 UTF-8，在 Windows 上有小概率出问题。所以我在代码里一律显式指定 StandardCharsets.UTF_8。

排查思路：先手动对比加密和解密时的 IV 字节、AAD 字节、密钥字节，用 Arrays.equals 逐个验证，通常能迅速定位。不要一上来就怀疑算法实现，JDK 的 AES/GCM 实现已经非常成熟。

4.2 分块上传一半，服务端重启了怎么办

服务端进程在分块上传过程中崩溃或重启，会出现一个尴尬的局面：内存里的 UploadSession 对象丢了，文件主密钥也没了，客户端后续上传的分块服务端根本不认识。

这个问题没有绝对完美的解，但有工程上可接受的方案：在初始化上传会话时，就把必要元数据持久化到数据库或 Redis。具体来说，uploadId、文件名、文件大小、分块大小、总分块数、文件主密钥的密文形式（用另一把“服务端主密钥”加密后存储），都要在初始化接口返回前落库。

这样服务端重启后，可以根据 uploadId 恢复会话对象，解密出文件主密钥，继续接收未完成的分块。至于文件主密钥用谁加密，建议用独立的“服务端主密钥”，存在配置中心或 KMS 里，不要把服务端主密钥和应用进程绑死。

4.3 分块上传和秒传的兼容

很多网盘类产品都有“秒传”功能：客户端算好文件指纹，服务端发现已存在相同文件，直接返回上传成功。在加密存储模式下，秒传有一个天然的矛盾：相同内容的文件，经过不同密钥加密后，密文完全不同。

解决思路有两种：

• 方案一：文件内容和密文解耦。存储层保存的是“明文指纹 → 文件内容索引”的映射，多个用户引用同一个底层文件，但每个用户有自己的加密密钥和密文副本。这种方式存储成本高，但隔离性最强。
• 方案二：内容寻址存储（CAS）。底层存储区用文件内容做地址，也就是内容哈希决定存储位置，这样相同内容的文件天然去重。但这种方案下，存储区并不区分用户，适合非强隔离场景。

我做项目时，如果客户明确要求加密存储，一般直接推荐方案一。理由很简单：加密存储的核心价值就是用户数据隔离，如果为了秒传而放弃了隔离，等于因小失大。秒传可以做成“逻辑秒传”——客户端提交指纹，服务端生成一个文件引用，但实际底层无论是否已有相同文件，都会为这个用户重新生成一份密文。如果相同文件确实存在，则直接复制底层密文并重新封装元数据，成本远低于重新上传。

4.4 分块合并后的文件完整性校验：SHA-256 冗余表

加密存储模式下，常规的文件校验有个陷阱：MD5 只校验文件内容，不校验解密过程。也就是说，即使你校验了合并后的密文文件的 MD5，最多只能证明“合并的密文文件字节和原始密文一致”，无法证明“解密后的明文是完整且在逻辑上正确的”。

我自己的项目里，在合并阶段会额外生成一份“分块 SHA-256 冗余表”，也就是在分块上传时，客户端除了传明文分块，还必须带上本地计算的明文分块 SHA-256。服务端在解密分块后，会重新计算一次 SHA-256，两者比对，不一致的直接标记该分块上传失败。

合并后的完整文件，再用整体 SHA-256 做最终校验。之所以做双层校验，是因为分块是客户端剪切的，残留在各分块边界的数据问题（比如某块多了一个字节，另一块少了一个字节），单靠最终文件的 SHA-256 往往能通过，但分块级校验能在合并之前就发现异常，节省了大量故障排查时间。

java复制// 分块校验片段
byte[] plainChunk = chunkCipher.decrypt(encryptedChunk, masterKey, uploadId, index);
String serverSideSha = DigestUtils.sha256Hex(plainChunk);
if (!serverSideSha.equals(clientSideSha)) {
    // 记录日志并上报分块异常，拒绝该分块
}

4.5 临时文件清理：定时任务不能少

加密存储方案中，临时目录里躺着的不是明文，但依然是密文分块，而且这些密文分块携带了 IV、认证标签和部分元数据。如果不及时清理，会积累大量半成品文件，既占用磁盘，也扩大了被攻击面。

我建议在服务端部署一个定时任务，扫描临时目录中超过 N 小时未更新的 .enc 文件，同时检查 Redis 中对应的上传会话是否已过期或已完成。如果已过期，立即删除临时密文。注意不要只删文件不删 Redis 中的会话元数据，否则 uploadId 会永远占用内存空间。

5. 几个实战中的额外建议

5.1 不要自己写加密算法，但可以自己搭加密框架

这句话听起来像废话，但实际操作中我见过很多人越过边界：明明是 JAVA 标准库 Cipher 就能解决的问题，非要引一个第三方的加密库，或者干脆自己写一个 XOR 加密类。前者的问题是依赖膨胀和供应链风险，后者的问题更严重——XOR 加密在 AES/GCM 面前相当于没有加密。

我的建议是：加密算法本身用 JAVA JCE（Java Cryptography Extension）标准库，AES/GCM/NoPadding 完全够用。需要自己搭的，是密钥管理、分块校验、会话生命周期管理这套“业务框架”，这些才是和你的业务场景强耦合的部分。

5.2 日志中严禁打印密钥和明文分块

这个提醒听起来低级，但在实际生产中，我排查过不下三次因为日志打印导致的密钥泄露。最典型的场景：开发环境 debug 日志中打出了 EncryptedChunk 对象，而这个类的 toString() 方法直接拼接了密文字节数组和 IV。密文泄露问题不大，但如果把密钥对象也打在日志里，比如：

java复制log.debug("MasterKey: {}", Arrays.toString(masterKey));

那整个加密体系就形同虚设。我一般会在开发规范里强制要求：所有密钥相关对象一律禁止重写 toString()，并且在日志输出的包装类里做脱敏处理。

5.3 分块上传 + 加密存储的性能测试怎么做

加密存储带来的 CPU 开销是实打实的：AES-256/GCM 加解密在我们常用的云服务器上，单线程吞吐大概在 200MB/s 到 500MB/s 之间，具体取决于 CPU 是否支持 AES-NI 指令集。如果机器不支持 AES-NI，性能可能掉到几十 MB/s，分块合并阶段会成为明显瓶颈。

性能测试时，建议分别测三个阶段的吞吐：分块加密落盘、分块解密合并、最终文件加密。然后根据业务峰值并发量，评估是否需要多线程并行处理不同分块的解密和加密。注意 GCM 模式的加解密是流式安全的，同一个 Cipher 实例不能并行用于多个分块，但 不同的分块可以并行使用各自的 Cipher 实例，前提是 IV 已经正确派生，互不重叠。

6. 最后分享两个小经验

分块上传和加密存储组合在一起，坑是真的多，但收益也大。我个人实际做项目时最深的体会是：架构上要有“密钥分离”的意识。文件主密钥负责上传会话内的分块加解密，最终存储密钥负责正式存储区文件的整体加密，两者不能复用，也不能由同一个密钥派生出来。一旦其中一把密钥泄露，另一把还能保住文件的一部分安全性，给后续的应急响应留出窗口。

另一个经验是：加密存储模式下，错误排查成本会比纯明文存储高一个量级，所以一定要把分块状态的元数据管理做好。哪个分块上传成功了、哪个分块还在路上、哪个分块校验失败，这些信息必须在数据库或 Redis 中清晰可见。不要只依赖内存里的 Set<Integer>，进程一重启就全没了。数据可靠性从来不是靠一个内存集合撑起来的。

如果后续有条件，这个方案还可以往两个方向扩展：一是支持服务端对已存储的密文做定期轮换密钥重加密，进一步降低长期存储的密钥泄露风险；二是接入对象存储的服务器端加密（SSE）能力，把最终存储层的加密下沉到基础设施，应用层只负责传输层的安全和业务逻辑，这样运维成本和加密管理负担都会小很多。说到底，加密存储不是简单地在文件前面加个“加密函数”，而是要在整个上传链路上建立一套前后呼应的信任体系。