一、GPG 的核心原理
GPG 基于 混合加密体系：
- 非对称加密（公钥/私钥对）：
- 公钥可公开，用于加密或验证签名。
- 私钥严格保密，用于解密或生成签名。
- 对称加密（会话密钥）：
- 实际数据使用 AES 等高效算法加密。
- 会话密钥则用接收方公钥加密后一同传输。
在数字签名场景中：
- 对原始数据计算哈希（如 SHA-256）；
- 用私钥加密该哈希值，生成数字签名；
- 接收方用公钥解密签名，得到原始哈希；
- 自己重新计算数据哈希，比对是否一致。
二、GPG 基本用法速览
| 功能 | 命令示例 |
|---|---|
| 生成密钥对 | gpg --full-generate-key |
| 导出公钥 | gpg --export --armor user@domain.com > public.key |
| 导入密钥 | gpg --import public.key |
| 加密文件 | gpg --encrypt --recipient user@domain.com file |
| 解密文件 | gpg --decrypt file.gpg > file |
| 分离式签名 | gpg --detach-sign package.tar.gz |
| 验证签名 | gpg --verify package.tar.gz.sig package.tar.gz |
| 查看指纹 | gpg --fingerprint user@domain.com |
三、GPG在系统升级场景中的应用
在系统升级应用场景中，系统升级包若被篡改或伪造，将导致严重安全风险。因此，升级机制必须满足：
- 机密性：升级包内容不能明文传输；
- 完整性：任何修改都能被检测；
- 身份认证：仅官方签名的包才可安装；
- 不可抵赖性：签名行为可追溯。
GPG 正好能同时解决后三项（完整性、认证、不可抵赖），配合加密可实现机密性。
四、基于 GPG 的安全升级流程
5.1 官方构建阶段
📌 签名必须作用于原始明文包，而非加密后的文件。
5.2 公钥信任问题：如何确保“官方”？
这是整个机制的安全基石。解决方案：
- 出厂预置：设备固件中内置官方公钥；
- HTTPS 分发 + 指纹校验：首次升级时从 HTTPS 站点下载公钥，并人工/自动核对其指纹；
- 硬编码指纹：在升级脚本中写死官方公钥指纹，拒绝其他任何签名。
⚠️ 切记：
Good signature不等于“来自官方”！必须验证公钥指纹。
五、常见误区与最佳实践
| 误区 | 正确做法 |
|---|---|
认为 .sig 包含公钥 | 公钥必须提前导入本地密钥环 |
| 只检查“Good signature” | 必须校验签名者指纹或 Key ID |
| 使用短 Key ID（8位） | 使用完整 16 位或 40 位指纹，避免碰撞攻击 |
| 私钥无密码保护 | 为私钥设置强密码，防止泄露后滥用 |
| 在脚本中明文写私钥密码 | 使用 gpg-agent 或硬件密钥（如 YubiKey）管理私钥 |
六、结语
GPG 不仅是一个命令行工具，更是一套完整的信任基础设施。在软件供应链安全日益重要的今天，合理运用 GPG 进行代码签名、固件验证、配置加密，已成为保障系统可信的必备手段。
对于系统设计者而言，理解 GPG 的工作原理、掌握其安全边界、并在实践中严格验证公钥来源，是构建真正安全升级机制的关键。正如一句安全格言所说：
“加密不难，信任才难。”
唯有将技术工具与信任管理相结合，才能构筑坚不可摧的数字防线。
发表回复