@zhongdao
2024-09-14T22:44:33.000000Z
字数 10843
阅读 3800
密码学算法应用机制
密码学算法 图示
0. 前言
一般人往往认为"保密的密码算法比较安全", 然而密码界的常识却是"不要使用保密的密码算法".
本文的插图主要来自图解密码技术一书, 也有google里搜索到的相关图片. 因为内容比较多,虽然都是图片和示范,适合产品了解相关的产品流程图细节,但是不容易短时间内把内容串起来理解.
推荐一个简单易懂的应用介绍:
What is a Digital Signature?
http://www.youdzone.com/signature.html
看完之后对整体概念有介绍, 然后再把下面的内容作为逐个的细节进行深入的了解.
1. 对称密码(共享秘钥密码)
对称密码(symmetric cryptography)是指在加密和解密时使用同一秘钥的方式.
1.1 对称秘钥
加解密展示:
加解密过程:
1.2 中间人攻击引发的对称秘钥配送问题
如果要在2个不同的人之间进行加密的通讯,那么秘钥配送就是一个问题,会引发中间人的窃取.
秘钥配送问题
公钥的意义在于,解决了中间人攻击,共享秘钥的配送问题.
2. 公钥密码
公钥密码(public-key cryptography)是指再加密和解密时使用不同秘钥的方式. 因此又称为非对称密码(asymmetric cryptography).
加解密展示:
加解密过程:
通过公钥加密发送消息过程:
2.1 RSA
RSA的加密解密
RSA密钥对的生成
2.1.1 RSA密钥对生成, 加密,解密的过程实例
...
2.1.2 RSA与质数
质数会不会用光呢?
512比特能容纳的质数数量比整个宇宙的原子还多, 生成质数组合撞车的可能性可以认为是没有的.
2.2 针对公钥的中间人攻击
公钥没有被破译, 但是仅靠公钥无法防御中间人攻击.
所以需要认证对方的公钥来确认身份.
3. 单向散列（哈希）函数
单向散列函数可以获取消息数据的指纹,通过对比指纹,就可以知道两条消息是否一致.
特点:
1. 根据任意长度的消息计算出固定长度的散列值.
2. 计算时间必须要短.
3. 消息不同,散列值不同.哪怕只有1比特的变化,也要有很高的概率产生不同的散列值. (抗碰撞性, collision resistance).
4. 单向性, 无法通过散列值反算出消息的性质.
散列函数展示:
散列函数应用于密码验证图示:
散列函数应用于软件未篡改验证图示:
4. 数字签名
4.1 公钥密码与数字签名的关系
4.1.1 回顾公钥密码的机制:
4.1.2 数字签名的机制:
加密相当于生成签名,解密相当于验证签名.
数字签名的应用:
4.1.3 签名和验证过程:
签名与验证展示:
签名与验证过程:
对消息的散列值进行签名:
公钥密码算法比较慢, 通过生成消息的散列值,然后再签名, 比较轻松.
对消息的散列值签名和验证的时间过程:
4.2 用RSA实现数字签名
针对公钥密码的中间人攻击(man-in-the-middle attack)对数字签名也颇具威胁.
5. 混合密码
用于加密内容的秘钥和用于加密秘钥的秘钥:
混合密码加解密示意:
用混合密码加密过程:
用混合密码解密过程:
基于口令的秘钥(password based encryption):
PBE加密:
PBE解密:
其中盐Salt是用于防止字典攻击的.
6. CA 与 PKI
6.1 CA认证机构协助完成认证与加密通讯的机制
认证机构必须是可信的.
6.2 PKI
PKI的组成要素与证书注册下载
7. PGP
PGP的加密过程:
PGP的解密过程:
PGP的签名过程:
PGP的验证签名过程:
签名并加密过程:
解密并验证签名过程:
8. SSL/TLS 安全通信
9. 密码技术与现代社会
9.1 密码学家的工具箱汇总
9.2 密码技术就是压缩:
9.3 量子密码
总结
解决问题链:
| 问题: | 机密性 | 秘钥配送 | 防止公钥伪造 | 证书本身合法 | CA可信 |
|---|---|---|---|---|---|
| 解决办法: | 秘钥 | 公钥私钥密码 | 证书证明 | 建立CA中心 | 对根CA的信任 |
最后追溯到对根CA的信任问题.
资料链接:
图解密码技术, 结城浩, 人民邮电出版社
google image
深入揭秘HTTPS安全问题&连接建立全过程
https://zhuanlan.zhihu.com/p/22142170
：非对称加密算法（公钥和私钥）交换对称密钥+数字证书验证身份（验证公钥是否是伪造的）+利用对称密钥加解密后续传输的数据=安全
前言
不同PKI系统之间的对接集成时，需要从PKI的角度出发，考虑安全和有效的集成方案。而不同PKI系统的对接涉及到应用层研发的模式，PKI之间的信任关系建立，不同算法证书的对接，证书状态数据的共享，不同集成方案的优劣势对比选择等环节。所以从基本概念，实际应用等出发，编写了本技术说明。
李军
2024-09-02
PKI之间信任及应用层方案对比
交叉认证
交叉认证(Cross-Certification)是PKI(公钥基础设施)中的一个重要概念。它允许两个独立的PKI系统之间建立信任关系,从而实现跨域的安全通信。
交叉证书颁发机构（Cross Certification Authority，Cross-CA）是指两个或多个证书颁发机构之间相互信任并签署对方证书的关系。 通过交叉认证，用户可以使用任一证书颁发机构颁发的证书与另一个证书颁发机构下的资源进行通信和认证。
原理:
交叉认证的核心原理是通过互相签发证书来建立PKI之间的信任。
实现通常涉及以下几个步骤：
- 协商信任关系：两个证书颁发机构需要协商建立信任关系，以确保彼此的证书可以被双方信任。这通常涉及到签署相互信任的根证书或者交换信任列表。
- 签署证书：一旦建立了信任关系，每个证书颁发机构可以签署对方颁发的证书，以表示对彼此的信任。这通常是通过交换证书签名请求（CSR）来完成的，然后使用私钥签署对方的证书。
- 发布证书：签署完成后，颁发机构会发布包含对方证书的信任链，以供用户和系统使用。这些证书可以通过在线目录、证书颁发机构的网站或其他渠道进行获取。
- 验证证书：在使用交叉认证的系统中，需要验证与另一个颁发机构签署的证书。验证过程通常包括检查证书链中的签名是否有效、证书是否在有效期内、是否被吊销等。
作用:
扩展信任域:允许不同组织或地区的PKI系统互相认可,扩大了证书的适用范围。
保持独立性:各PKI系统可以保持独立运营,不需要合并成单一系统。
提高互操作性:不同系统的用户可以安全地进行跨域通信。
降低成本:避免了建立单一大型PKI的复杂性和成本。
交叉认证步骤
两个PKI之间的根证书交叉认证
为了让PKI2的用户证书也得到PKI1的信任，CA1生成一包含CA2公钥的证书cert2.1这时候cert2和cert2.1具体相同的主题及公钥，cert2.2 (User 2)就有了两条合法的证书链："cert2.2 → cert2" and "cert2.2 → cert2.1 → cert1"。
CA2也可以生成类似的包含有CA1公钥的证书cert1.1，以便PKI1的用户(比如User 1)的证书能在PKI2得到认证。
证书链
颁发证书的关系
Subject: CA1] CA1 -->|issues| Cert2.1[cert2.1
Subject: CA2] Cert1.1 -.->|cross-certifies| CA1 Cert2.1 -.->|cross-certifies| CA2 classDef pki2 fill:#fff0e6,stroke:#cc6600,stroke-width:2px; classDef pki1 fill:#e6f3ff,stroke:#0066cc,stroke-width:2px; class CA2,User2,Cert1.1 pki2; class CA1,User1,Cert2.1 pki1;
不同PKI体系下的交叉证书身份认证
涉及角色：CA1, CA2, server1,user1, server2,user2，CA2_signedby_CA1 （server1,user1代表1个或多个）
定义：server1指CA1系统里的服务端，例如针对播放器的视频密钥分发服务器，user1指CA1系统里与server1交互的终端，例如播放器终端；server2,user2则是对应CA2系统里的。CA2_signedby_CA1 指CA1签发的CA2根证书，用于交叉信任。
功能：CA2颁发的证书，如何在CA1颁发证书的系统里获得认可，server1可以给user2颁发播放密钥？
前提：
- 各自CA都公开且可信，彼此认可;
- CA2获得CA1的交叉认证之后，交叉证书公开到CA1域的证书链中，并分发到CA1域下server1,user1的信任存储中;
- server1,user1的原身份验证程序修改为可以验证CA2颁发的证书(如果是CA验证要支持新的证书链验证，如果是数据库形式，user2的证书状态要能被server1访问到，就需要user2的证书全部导入server1的数据库中)；
- CA1的的证书吊销CRL或ocsp查询可以响应CA2颁发的证书的状态查询（需要有同步机制）；
如果是非身份认证的程序，而是tls/ssl的浏览器服务，只需要加入本机信任存储库即可。
过程：CA2的根证书发给CA1进行签名，获得CA2_signedby_CA1的证书，基于证书链，CA2所颁发的所有证书也获得CA1的认可。原先，server1通过CA1验证user1的证书，进而可以对user1在CA1里获得的证书进行验签从而认可user1的注册身份；交叉认证之后，server1通过CA1，CA2_signedby_CA1验证CA2所颁发的证书，进而验证user2的身份,从而可以进行商业逻辑的操作例如分发播放视频的密钥给user2。
要素说明：相当于CA2成为了CA1下的受信任CA，通过新的证书链进而认可CA2颁发的叶子证书。证书链验证路径：user2 -> CA2 -> CA2_signedby_CA1 -> CA1
备注：只是在PKI的体系下完成了安全的设计，具体商业和具体实现上，因为各自的商业逻辑和数据结构不同，仍需要适配转换。
图示：
交叉认证的信任层次结构:
交叉认证时CA1系统里的修改步骤时序图：
CA1和CA2系统实现应用交叉认证时CA1系统里的修改步骤时序图：
添加到CA1域的证书链中 CA1->>Server1: 4a. 发布并分发新的证书链 CA1->>User1: 4b. 发布并分发新的证书链 CA1->>AdaptationLayer: 4c. 发布并分发新的证书链 CA2->>CA1: 5. 同步CRL和OCSP数据 Note over CA1: 6. 更新CRL/OCSP服务
响应CA2证书状态查询 Note over Server1: 7. 修改身份验证程序 alt 基于注册证书数据库 Note over Server1: 7a. 将User2证书重新注册到数据库 else 基于CA验证 Note over Server1: 7b. 支持User2的密钥算法 end Note over AdaptationLayer: 8. 实现适配层
转换User2到Server1的数据结构和请求 User2->>AdaptationLayer: 9. 使用CA2颁发的证书请求服务 AdaptationLayer->>Server1: 10. 转换并转发请求 Note over Server1: 12. 验证证书链: User2->CA2->CA2_signedby_CA1->CA1 Server1->>CA1: 13. 查询证书状态 Note over Server1: 14. 验证商业逻辑许可 Server1->>AdaptationLayer: 15. 返回服务响应（如分发内容密钥） AdaptationLayer->>User2: 16. 转换并转发响应 Note over CA1,User2: 备注：实际商业逻辑和数据结构差异由适配层处理
CA1系统里的整体修改步骤：
CA1里签发CA2的交叉证书
CA1发布新的证书链,分发到服务器Server1和客户端User1（若user1逻辑不改无需分发新证书链)
CA1同步CA2的CRL和OCSP数据
Server1修改user1的身份验证程序，支持新证书链
增加适配层转换user2到server1的数据结构和请求。
测试验证：
- 签发交叉证书 2. 新证书链验证 3. 同步CA2证书状态数据到CA1(crl) 4. server1编程实现验证证书链
备注：
身份验证程序的修改取决于原来是怎么实现的，如果原来是user1发自身证书给server1, server1基于CA1验证user1证书，则无需修改程序框架，只需要支持user2的密钥算法即可; 如果原来基于注册证书数据库，则需要将user2的证书重新注册一遍, 或者直接新增一个接口改为证书链验证方式。
适配层的实现方式
在交叉认证和重新注册2种方案情况下，适配层也有不同的实现方案，要么模拟成一个server1的终端，要么转发user2的请求给server1.
A: 如果没有交叉认证，不修改Server1, 那么需要在适配层保存所有user2的证书和Server1所需对应证书的映射数据库，并且到CA1和Server1注册所有的user2证书；或者将适配层模拟成一个user1,但是仍需保存所有user2和user1之间的一个映射关系和请求记录，然后再向server1发起请求，server1只会看到一个设备的多次播放请求。需要到适配层查看对账记录和实际各user2终端的播放记录。 适配层已经不是一个简单的适配数据结构的后台服务，而是包含对账数据查看、数据结构适配和多映射的服务平台。
B: 如果交叉认证，server1修改身份验证功能，那么user2的证书无需到server1和ca1注册，保持原有证书,可以直接获得信任，用于申请播放请求，user2证书的撤销引发的状态改变数据需要在PKI层面从CA2同步到CA1即可。
Server1通过新的CA证书链验证，并且支持到user2的证书密钥算法，对于分发的内容密钥，采用user2的公钥密钥算法进行加密，user2直接解密。此时适配层只需要改动数据请求和返回结构，再加上Server发的密钥即可。
C: 在交叉认证的基础上， 如果Server1验证了user2客户端的证书，也可以采用自定义和适配层沟通好的加密通讯协议如tls，或者把适配层当做一个PKI1里的一个客户端对待，分发原有PKI1系统里的内容密钥，适配层解密后重新将内容密钥再次用user2的公钥加密，再传回给user2。 每次通讯，适配层都需要记录user2的证书请求或公钥，然后在server1返回时先解密，再加上user2的公钥加密再传回user2.
B、C都可以满足 server1记录所有user2播放记录的情况。同时也无需user2重新注册。 因server1与适配层的协议不同而实现不同。
3个方案里，
A. 可以无需修改原PKI1的应用系统，完全由PKI2来实现适配层做映射，且重新在PKI1里注册一遍证书, 适配层复杂
B. 交叉认证，PKI1里应用服务基于原有实现方式不修改或稍作修改，PKI层面进行数据同步，PKI1和PKI2实现了保持各自独立的情况下能够互相信任，适配层相对简单
C. 交叉认证，适配层实现类似A和B方案的结合体。
其中，密钥适配层/网关起到转换格式连接2个不同pki体系应用的作用，有2种方案:
模拟pki1里的一个终端设备，接收pki2体系里所有终端的请求，然后发送给pki1里的服务器.实际播放记录和对账记录需要到适配网关里查，或者同步到pki1的服务器里。
按照pki2里的所有终端数量，记录其所有证书，模拟成pki1对应的终端，转化格式和响应，发送给pki1里的服务器。（同时也需要在pki1里注册所有的终端证书)， 实际播放记录也会在pki1服务器里。
采用方案1时，pki1的播放记录是假的，需要到适配网关里查询。
采用方案2时，pki2的所有终端证书需要在网关和pki1服务器里都注册或记录一遍。
交叉认证方案的特点：满足了 server1可以在自己平台看到所有终端播放记录； user2无需到pki1和server1系统里重新注册；适配层根据交叉认证的情况，修改和转发user2的请求，修改和转发server1返回的加密密钥。
| 特征 | 方案A（无交叉认证） | 方案B（交叉认证，Server1修改） | 方案C（交叉认证，自定义协议） |
|---|---|---|---|
| 交叉认证 | 不需要 | 需要 | 需要 |
| Server1修改 | 不需要 | 需要修改身份验证功能 | 需要修改身份验证功能 |
| User2证书注册 | 需要在PKI1和Server1重新注册 | 不需要重新注册 | 不需要重新注册 |
| 适配层复杂度 | 高 | 低 | 中 |
| 适配层功能 |
- 模拟User1设备 - 对账数据查看 - 数据结构适配 - 多映射服务 |
- 传递Server1加密的密钥 |
- 解密Server1密钥 - 用User2公钥重新加密密钥 |
| 证书状态同步 | 不需要 | 需要CA2同步到CA1 | 需要CA2同步到CA1 |
| Server1记录播放 | 根据适配层实现方案有关 | 可以看到所有User2播放记录 | 可以看到所有User2播放记录 |
| User2证书使用 | 使用在PKI1注册的新证书 | 使用原有PKI2证书 | 使用原有PKI2证书 |
| 密钥分发流程 | 适配层接收并转发 | Server1直接用User2公钥加密 | 适配层解密后用User2公钥重新加密 |
| PKI独立性 | 完全独立，但需要重新注册证书 | 保持独立，实现互相信任 | 保持独立，实现互相信任 |
| 适用场景 | 不想修改PKI1系统时 | 愿意修改Server1，追求简单适配层 | 对通信协议有特殊要求时 |
备注：对于证书算法不同，server1 也可以添加一个新接口，用于处理新算法如sm2证书终端的请求，验证证书链，实现商业上许可内容加密。
PKI1系统信任PKI2系统证书时方法/方案对比
2个pki系统PKI1,PKI2交叉认证时，PKI2里的终端需要被PKI1里的服务器获得身份信任时，有大致2种方法，
一, PKI2无需注册新证书，交叉认证即可，改动主要发生在PKI层面（更新本地信任存储同时也同步2个PKI的CRL,OCSP的证书状态查询）。
二、 PKI2需要在PKI1里注册新证书。PKI2的终端需要有2个证书，完全兼容PKI1的原有体系和逻辑。
PKI1里应用层服务的具体修改范围与身份认证服务的实现方法有关，
如果PKI1里应用层服务的身份认证是通过标准证书链的验证来确认终端证书身份，更新信任存储即可。
如果PKI1里身份认证是通过查询本地数据库的证书公钥来验证终端证书身份，可能需要将所有证书批量定期导入， 也可能需要终端在原有pki体系里注册新的第2个证书。本质上差别不大。
对比表格：
| 特征 | 方法一：交叉认证 | 方法二：PKI2在PKI1注册新证书 |
|---|---|---|
| PKI2终端证书 | 使用原有证书 | 需要新增PKI1颁发的证书 |
| 主要改动位置 | PKI层面 | 应用层和终端 |
| PKI1本地信任存储 | 需要更新 | 不需要更新 |
| CRL/OCSP同步 | 需要同步两个PKI系统 | 不需要同步，使用PKI1原有机制 |
| PKI2终端操作 | 无需额外操作 | 需要申请和安装新证书 |
| PKI系统独立性 | 保持各自独立 | PKI2部分依赖于PKI1 |
| 适用场景 | PKI1应用层使用标准证书链验证 | PKI1应用层使用本地数据库验证 |
| 实施复杂度 | 中等（主要在PKI层面） | 高（涉及终端和应用层） |
| 维护成本 | 较低（集中在PKI层面） | 较高（需要管理额外的证书） |
| 扩展性 | 好（易于添加新的PKI系统） | 一般（每个新PKI系统都需要注册） |
方法一：交叉认证
- 优点：PKI2终端无需变更，维护成本低，扩展性好。
- 缺点：需要同步CRL/OCSP数据，PKI层面改动较大。
- 适用于：PKI1应用层服务使用标准证书链验证的情况。
方法二：PKI2在PKI1注册新证书
- 优点：与PKI1原有系统高度兼容，无需改变验证逻辑。
- 缺点：PKI2终端需要管理额外证书，实施和维护成本较高。
- 适用于：PKI1应用层服务使用本地数据库验证证书的情况。
PKI1应用层服务的修改
- 对于使用标准证书链验证的服务，方法一（交叉认证）只需更新信任存储。
- 对于使用本地数据库验证的服务，方法二更适合。
- 也可以通过新增接口来采用交叉认证的方案，来直接支持PKI2的终端
如果PKIA和PKIB的密钥算法和应用服务结构不同，应用服务层仍需做与密钥算法相关的修改
身份认证的目的是为了颁发应用层许可密钥，而许可密钥与证书有关，如果采用方法一，证书的公私钥加密算法不同，则应用层服务也需要针对PKIB的密钥算法，添加针对对方证书算法所需要的许可密钥。
PKIB里采用的身份认证的相关许可密钥格式不同时，如果采用方法二，则需要有适配层对PKIA里颁发的许可密钥进行转化。例如将RSA转为SM2, KDM转成自定义license等。
这里许可密钥指的是用于应用层的，例如视频播放密钥格式，电影行业是kdm, 在线视频有自定义的格式
不同pki体系下的交叉证书身份认证的实际方案思考与设计
在 不同pki体系下的交叉证书身份认证 的前提下：
涉及角色：CA1, CA2, server1,user1, server2,user2，（server1,user1代表1个或多个）
情况说明：
CA1体系里采用的是电影行业的播放许可密钥kdm形式，设备采用的是RSA的证书；提供公共的crl和ocsp服务。
CA2体系里采用的是华为视频自定义的播放密钥许可license形式，播放设备采用的是SM2的证书。crl一周更新一次。ocsp查询在DRM服务中实现。
两者互不兼容，而且CA1和CA2是各自独立的pki体系。
如何能让CA1体系里的kdm distribution可以分发密钥给CA2体系里的终端设备播放影片呢？
在近可能减少pki1体系里应用层逻辑修改的前提下：
pki1无需改动的方案是: 适配网关(记录所有pki2里证书映射或者直接转发)+ 适配网关在pki1里注册所有pki2里证书+转换kdm为license, 对pki2的影响改动较大，
pki1较小改动的最优方案是: PKI交叉认证 + 适配网关(转换kdm为license后转发给user2)， 特点是修改pki层，无需双证书, PKI服务较小修改.
