news 2026/4/18 11:26:54

# 非对称(PKC)与对称(SBK)加密算法全指南

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
# 非对称(PKC)与对称(SBK)加密算法全指南

📺B站视频讲解(Bilibili):https://www.bilibili.com/video/BV1k1C9BYEAB/

📘《Yocto项目实战教程》京东购买链接:Yocto项目实战教程


非对称(PKC)与对称(SBK)加密算法全指南

在现代计算系统(尤其是嵌入式设备、移动设备、安全启动场景)中,加密算法的核心作用可以总结为两类:

① 真实性与完整性 —— 通过非对称密码(PKC)实现签名与验证
② 机密性 —— 通过对称加密(SBK)保护数据不被读取

这两类算法不是竞争关系,而是互补关系。很多系统(包括 NVIDIA Jetson、Android Verified Boot、Linux 内核模块签名、TLS 协议等)都同时使用 PKC + 对称密钥来实现完整的安全体系。

本文将用系统化、逻辑清晰的方式,从算法本质讲起,再通过示例、流程图、表格等方式解释它们的用途与差异,帮助你从根本上掌握两类加密算法的核心价值。

1. 密码学的两大支柱:PKC 与对称加密


几乎所有现代加密系统,都可以用一个极简的逻辑图表示:

┌─────────────────────────┐ │ 非对称密码(PKC) │ │ Signature Sign/Verify │ │ 用于验证“是否被篡改?” │ └─────────────────────────┘ │ ▼ ┌─────────────────────────┐ │ 对称加密(SBK) │ │ Encryption/Decryption │ │ 用于保护“是否会被读到?”│ └─────────────────────────┘
  • PKC 解决完整性 & 身份真实性(数据没有被改、来自可信方)。
  • SBK 解决机密性(数据不能被别人看到)。

两类算法分别解决不同的安全目标,因此在 Secure Boot、磁盘加密、通信安全中一起出现十分正常。


2. 非对称密码(PKC)


PKC = Public Key Cryptography,即“公钥密码学”。它最大的特点是:

两把不同的钥匙:公钥 & 私钥

一个负责签名(或解密),另一个负责验证(或加密)。

以下是最常见 PKC 算法:

算法类型特点典型用途
RSA非对称成熟稳定、密钥大、速度较慢数字签名、密钥交换、证书体系
ECDSA非对称(椭圆曲线)密钥短、速度快、非常适合嵌入式设备Secure Boot、内核模块签名
Ed25519新型椭圆曲线高速、高安全性、实现简单应用签名、SSH

在 Secure Boot 体系中(例如 Jetson、Android Verified Boot、UEFI Secure Boot):

PKC 负责“签名 → 验证”,确保执行的镜像一定来自可信方。


2.1 PKC 的核心能力:数字签名


数字签名回答的问题只有一个:

“这份数据有没有被篡改?是不是真的是某人发的?”

数字签名不是“加密”,因为签名后的数据一般仍然可以被任何人读取,它的作用是:

  • 确保数据的完整性(内容没有被修改)
  • 确保数据的来源可信(确实是某个私钥持有者签的)

接下来用一个具体示例讲解整个流程。


2.1.1 PKC 签名验证流程(示例)


假设你要给一个镜像bootloader.bin签名。

流程图(简化版)

私钥持有者(厂家) 公钥持有者(设备) ────────────────────────────────────────────────────── │ │ │ 1. 对镜像做哈希(SHA256) │ │ hash = SHA256(image) │ │ │ │ 2. 使用私钥对 hash 做签名 │ │ signature = Sign(hash, PrivateKey) │ │ │ ├── 将 image + signature 发送给设备 ────────▶│ │ │ 3. 设备计算同样的 hash │ hash2 = SHA256(received_image) │ │ 4. 使用公钥验证签名 │ Verify(signature, hash2, PublicKey) │ │ 如果验证成功 → 镜像可信 │ 如果失败 → 镜像被篡改 or 来源不可信

示例(伪代码)

# 厂家端(用于签名)image=load("bootloader.bin")h=sha256(image)signature=sign_with_private_key(h,privkey)bundle=image+signature
# 设备端(用于验证)image,signature=extract(bundle)h1=sha256(image)t=verify_with_public_key(signature,h1,pubkey)ift:print("OK: image is trusted")else:print("ERROR: tampered or invalid signature")

至此你可以看到:

PKC 并不加密镜像内容,它只是保证镜像没有被篡改且来源可信。


2.2 PKC 典型应用


场景为什么必须使用 PKC?
Secure Boot必须保证 bootloader 未被篡改,否则攻击者可替换恶意镜像
OTA 升级包签名防止中间人攻击替换升级包
Linux 内核模块签名防止加载恶意模块
TLS、HTTPS验证服务器身份
软件分发(APK、deb、rpm)确保软件包来自官方

一句话总结:

PKC 负责“不允许别人改”。


3. 对称加密(SBK)


对称加密(Symmetric Encryption)指的是同一把密钥用于加密/解密

加密:ciphertext = Encrypt(plaintext, Key) 解密:plaintext = Decrypt(ciphertext, Key)

你可以看到,对称加密不像 PKC 那样使用两把钥匙,而是:

一把密钥决定一切。泄露 = 全盘泄露。

在嵌入式系统中,常见对称算法包括:

算法类型用途
AES-128/256分组加密最常用的块加密算法,广泛用于 SBK
ChaCha20流加密移动设备、TLS 中常用
GCM 模式AEAD 加密同时保证加密与完整性

3.1 SBK 的安全目标


SBK 解决的问题与 PKC 完全不同,它回答的是:

“别人能不能看到内容?”

对称加密的核心价值:

  • 保护机密性(Confidentiality)
  • 防止逆向工程与敏感数据泄露
  • 阻止固件被攻击者直接分析

在安全启动体系中:

SBK 负责对镜像进行加密,防止攻击者读取其中的内容(如关键算法、AI 模型、商业逻辑)。


3.2 SBK 对称加密流程(示例)


假设有一个关键二进制文件:

initrd.img

厂家使用 SBK 对其加密:

cipher = AES_Encrypt(initrd_img, SBK)

设备启动时,BootROM 或 Bootloader 持有同一把密钥 SBK,可以解密:

initrd = AES_Decrypt(cipher, SBK)

流程图

厂家端 设备端 ──────────────────────────────────────────────────────────── │ │ │ plaintext = initrd.img │ │ │ │ 1. 使用 SBK 加密 │ │ ciphertext = AES128(plaintext, SBK) │ │ │ ├── 将 ciphertext 烧录到设备 ─────────────▶│ │ │ 2. 设备读取密文 │ plaintext = AES128_Decrypt(ciphertext, SBK) │ │ plaintext 才能被执行

3.3 示例(伪代码)


# 加密fromCrypto.CipherimportAES cipher=AES.new(SBK,AES.MODE_CBC,iv)encrypted=cipher.encrypt(pad(data))
# 解密cipher=AES.new(SBK,AES.MODE_CBC,iv)decrypted=unpad(cipher.decrypt(encrypted))

SBK 非常简单,但安全性高度依赖:

  • 密钥是否泄露?
  • 密钥是否存放在硬件安全区域?(如 eFuse、TrustZone、TEE)
  • 是否使用安全的模式(如 GCM 而不是 ECB)

一句话总结:

SBK 负责“不允许别人看”。


4. PKC vs SBK:对比总结


项目PKC(非对称)SBK(对称)
目标完整性、身份认证机密性
密钥数量一对公钥/私钥一把密钥
密钥泄露影响私钥泄露非常严重;公钥泄露无影响密钥泄露 = 全部内容可被解密
速度较慢很快(适合大文件)
常见用途Secure Boot、签名、证书固件加密、数据保护
是否可逆签名不可逆,验证可行加密可逆(解密)

一个系统中通常两者同时出现:

PKC 确保镜像不能被改 SBK 确保镜像不能被读

5. PKC + SBK 在实际系统中的组合应用


以 Secure Boot 为例,一个完整的启动过程通常包含两个步骤:

① 使用 PKC 验证是否被篡改

  • Bootloader 是否来自厂家
  • Kernel 是否来自厂家
  • Rootfs 是否来自厂家

攻击者无法修改内容,否则签名验证失败。

② 使用 SBK 加密关键镜像(可选)

  • 防止攻击者 dump 出 AI 模型
  • 防止分析 bootloader 内部逻辑
  • 防止商业逻辑泄露

攻击者即使得到固件,也无法解密。


6. 实战视角:如何选择 PKC 或 SBK?


场景使用 PKC?使用 SBK?原因
Secure Boot✔ 必须可选必须验证完整性
OTA 升级包✔ 必须可选必须防篡改
AI 模型保护可选✔ 强烈推荐防止被复制
商业逻辑/算法保护可选✔ 强烈推荐防止逆向工程
文件系统保护可选防止数据泄露

一句话总结:

  • PKC:不让别人改
  • SBK:不让别人看

7. 整体总结(一页 PPT 可用)


┌────────────────────┐ │ 非对称密码 (PKC) │ │ - 公钥/私钥 │ │ - 签名验证 │ │ - 防篡改、防伪造 │ └────────────────────┘ │ ▼ ┌────────────────────┐ │ 对称加密 (SBK) │ │ - 单一密钥 │ │ - 加密/解密 │ │ - 防读取、防逆向 │ └────────────────────┘ PKC 用于验证完整性(是否被改) SBK 用于保护机密性(是否被读)

8. 结束语


非对称加密与对称加密并不是替代关系,而是构成现代安全体系的基础组合:

  • PKC 提供信任根(Root of Trust)
  • SBK 保护数据机密性
  • 二者结合构成现代系统安全链

理解它们的本质,你就能理解 Secure Boot、TLS、磁盘加密、应用签名等所有现代安全机制背后的逻辑。


📺B站视频讲解(Bilibili):https://www.bilibili.com/video/BV1k1C9BYEAB/

📘《Yocto项目实战教程》京东购买链接:Yocto项目实战教程


版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!