之前对接一个银行系统的时候，对方要求导出的电子回单PDF必须设置所有者密码，禁止打印和复制文本。当时用iText折腾了半天，发现PDF加密这套机制比想象中复杂——不只是设个密码那么简单，它涉及两套密码体系、一个权限位掩码、以及从RC4到AES-256的加密算法演进。

周末把PDF 2.0规范里关于安全的部分重新捋了一遍，写下来当笔记。

PDF规范定义了标准安全处理程序，经历了四次迭代：

实际开发中，如果不需要兼容十年前的阅读器，直接用修订版4或修订版6就行。修订版2和3只在对兼容性有极致要求时才考虑。

PDF的权限管理不是简单的一个密码锁住整个文件，它设计了两套密码：

这个设计很巧妙。假设你是文档作者，你可以把用户密码告诉读者让他们看，但只有你知道所有者密码，所以读者不能修改权限设置。如果两个密码一样，那就退化成单密码模式。

每个加密的PDF文件里都有一个加密字典对象，挂在文件尾部的trailer字典里。以修订版4为例，加密字典的结构大致如下：

/Encrypt 15 0 R
  /Filter /Standard
  /V 4
  /Length 128
  /CF
    /StdCF
      /CFM /AESV2
      /Length 16
      /AuthEvent /DocOpen
  /StmF /StdCF
  /StrF /StdCF
  /O <...所有者密码验证数据...>
  /U <...用户密码验证数据...>
  /OE <...AES-256的所有者加密密钥...>
  /UE <...AES-256的用户加密密钥...>
  /Perms <...加密的权限位...>

V是版本号，CFM是加密算法标识，O和U是密码验证用的哈希值。阅读器打开文件时，拿用户输入的密码去计算一个哈希值，和U比对，匹配上了就允许打开。

PDF的权限控制不是一个个布尔值分别存储，而是用了一个32位整数做位掩码。每位代表一个权限：

计算权限值的时候，把这些位的值按位或运算就行。比如允许打印和复制，但不允许修改，权限值就是 

0b...1111 1111 1111 1111 1111 1111 1111 0100

，转换成十进制存到加密字典里。

这个设计的巧妙之处在于，阅读器拿到权限值后只需要做位与运算就能判断某个操作是否被允许，效率很高。而且因为是32位整数，扩展性好，规范后续版本可以定义新的权限位。

文件打开后，阅读器用用户密码推导出加密密钥，然后用这个密钥解密所有的字符串和流对象。PDF的加密粒度是对象级别的，不是文件级别的。这意味着：

加密算法的具体实现，以AES-128为例，用的是CBC模式，初始化向量随机生成并嵌入到加密数据的前16字节。解密时先取出IV，再用密钥解密剩余部分。

所有者密码的验证链路比用户密码复杂。大致流程是：

这就解释了为什么知道所有者密码就可以重置用户密码——因为所有者密码可以推导出加密所有用户相关字段的密钥。

实际开发中处理加密PDF，有几个容易踩的坑：

第一个坑是密钥长度和算法版本的对应关系。修订版3用RC4-128，修订版4用AES-128，修订版6用AES-256。如果代码里写死了某种算法，碰到其他版本就会报错。正确的做法是先读加密字典的V字段，按版本号走不同的解密分支。

第二个坑是权限位的字节序。规范里权限位用32位整数存储，但没有明确指定是big-endian还是little-endian。实际测试发现不同厂商的实现不一样，有的用大端有的用小端。做权限判断的时候最好同时尝试两种字节序。

第三个坑是加密流和非加密流的混合。一个PDF文件里可以有部分流加密、部分流不加密。比如元数据流可以选择不加密，以便搜索引擎索引。解密的时候要判断每个流的加密状态，不能全部一刀切。

第四个坑是空用户密码的处理。有些PDF设置了权限但不设用户密码，允许任何人打开但不能复制或打印。这时候加密字典里的U字段是根据空字符串计算的哈希值，处理逻辑和无加密的PDF完全不同，需要注意区分。

如果不想从零实现，有几个开源库已经封装好了加密解密逻辑：

不过这些库的使用各有门槛。pikepdf的安装需要编译C扩展，在某些云函数环境里比较麻烦。iText的许可证问题需要注意。qpdf是目前兼容性最好的命令行方案，可以直接集成到后端脚本里。

PDF加密这套机制从RC4-40到AES-256，演化了几十年。两套密码体系的设计在当时看是挺先进的，让文档作者可以灵活控制阅读权限和修改权限。权限位掩码的方案也很优雅，用最少的存储空间表达了多维度的权限组合。

现在回过头看，这套体系的最大局限在于阅读器的实现——权限位说到底只是一个建议，阅读器如果不遵守，作者也没办法。所以敏感文档的防护不能只靠PDF权限设置，还得配合其他手段。

(周末看PDF安全规范写的技术笔记，供参考。)

PDF加密的技术细节：RC4、AES与权限字典的设计逻辑

编程语言

开发工具

"深度解析PDF加密机制：从RC4到AES-256的演进历程。详解PDF两套密码体系、权限位掩码设计及加密流程，分析开发中常见问题与解决方案。涵盖PDF2.0安全规范的四种修订版本特点，提供主流编程语言实现方案，帮助开发者正确处理PDF权限管理。"

命令行工具

云函数

数据流

Python

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

PDF加密的技术细节：RC4、AES与权限字典的设计逻辑

PDF加密的技术细节：RC4、AES与权限字典的设计逻辑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐