vault backup: 2026-11-07 16:33:44

2026-11-07 16:33:55 +08:00
commit 7015312702
1208 changed files with 132432 additions and 0 deletions
@@ -0,0 +1,38 @@
+[NIST 后量子密码标准征集提案 - Ding Key Exchange](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/NIST+%E5%90%8E%E9%87%8F%E5%AD%90%E5%AF%86%E7%A0%81%E6%A0%87%E5%87%86%E5%BE%81%E9%9B%86%E6%8F%90%E6%A1%88+-+Ding+Key+Exchange%20fde331e3-7eb2-497e-996a-7a719f2ed50c.md)
+
+[国内算法标准介绍](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BD%E5%86%85%E7%AE%97%E6%B3%95%E6%A0%87%E5%87%86%E4%BB%8B%E7%BB%8D%20f0c4456b-c391-4d50-9032-8c5f43b0d25d.md)
+
+[SSL VPN产品常见问题问答](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/SSL+VPN%E4%BA%A7%E5%93%81%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98%E9%97%AE%E7%AD%94%203f2724eb-6212-4ddc-90a1-d904676fb2d7.md)
+
+[PKI技术规范](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83%20abf96506-5c16-4a03-ac32-1839f6dcc2a3.md)
+
+[LDAP模型简介](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/LDAP%E6%A8%A1%E5%9E%8B%E7%AE%80%E4%BB%8B%202ea0c61c-1e7f-48d4-8a4e-43a790113dd1.md)
+
+[PKCS](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/PKCS%20183e00f5-5a58-4754-921c-b52c536ec7ba.md)
+
+[图解 ECDHE 密钥交换算法](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BE%E8%A7%A3+ECDHE+%E5%AF%86%E9%92%A5%E4%BA%A4%E6%8D%A2%E7%AE%97%E6%B3%95%20118cb81b-7cb1-471e-9fc2-ccfd0897265d.md)
+
+
+
+[RFC PKCS](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/RFC+PKCS%204eb23dea-bc96-4397-badb-08fd3a4b4d3b.md)
+
+[项目管理](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E9%A1%B9%E7%9B%AE%E7%AE%A1%E7%90%86%200577dadf-ecb3-4551-b005-8502d52e9076.md)
+
+[国密及PKCS7的OID](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BD%E5%AF%86%E5%8F%8APKCS7%E7%9A%84OID%20cea170ba-032d-4330-99b9-883d6a4b9f53.md)
+
+[[开源+免费] 一款释放数据价值的项目，开源隐私计算平台](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%5B%E5%BC%80%E6%BA%90+%E5%85%8D%E8%B4%B9%5D+%E4%B8%80%E6%AC%BE%E9%87%8A%E6%94%BE%E6%95%B0%E6%8D%AE%E4%BB%B7%E5%80%BC%E7%9A%84%E9%A1%B9%E7%9B%AE%EF%BC%8C%E5%BC%80%E6%BA%90%E9%9A%90%E7%A7%81%E8%AE%A1%E7%AE%97%E5%B9%B3%E5%8F%B0%20cdc79c72-d449-49ec-b9e7-cea4a9a1654c.md)
+
+[0028 密码模块安全技术要求](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/0028+%E5%AF%86%E7%A0%81%E6%A8%A1%E5%9D%97%E5%AE%89%E5%85%A8%E6%8A%80%E6%9C%AF%E8%A6%81%E6%B1%82%205b0b1d2f-cdfd-4c9e-9f10-aba05fe594b8.md)
+
+[国密规范整理](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%9B%BD%E5%AF%86%E8%A7%84%E8%8C%83%E6%95%B4%E7%90%86%2055695b92-a4a1-4cd2-a924-7f447f0e60c7.md)
+
+[常见密码算法整理](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%B8%B8%E8%A7%81%E5%AF%86%E7%A0%81%E7%AE%97%E6%B3%95%E6%95%B4%E7%90%86%2096365711-a286-4773-b41b-6952a0b919d3.md)
+
+[公网服务](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E5%85%AC%E7%BD%91%E6%9C%8D%E5%8A%A1%2034fc074a-f3e4-45d3-ac3f-0d8ba86bbf04.md)
+
+[网关](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E7%BD%91%E5%85%B3%20c8d457aa-67b3-4082-979d-a34fe5b23ae2.md)
+
+[算法模式-GCM模式](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E7%AE%97%E6%B3%95%E6%A8%A1%E5%BC%8F-GCM%E6%A8%A1%E5%BC%8F%207ea48eed-5208-4455-a689-327346ac4fc6.md)
+
+[消息认证中容易混淆的概念（Hash，Mac，Hmac，CMAC，GMAC，GCM，AEAD, Mac-Tag, Nonce）](%E4%BF%A1%E5%AE%89+c5006103-ca4f-4a85-95c4-a6af67150bdc/%E6%B6%88%E6%81%AF%E8%AE%A4%E8%AF%81%E4%B8%AD%E5%AE%B9%E6%98%93%E6%B7%B7%E6%B7%86%E7%9A%84%E6%A6%82%E5%BF%B5%EF%BC%88Hash%EF%BC%8CMac%EF%BC%8CHmac%EF%BC%8CCMAC%EF%BC%8CGMAC%EF%BC%8CGCM%EF%BC%8CAEAD,+Mac-Tag,+Nonce%EF%BC%89%20cd82dca5-b108-4403-ba78-4c5a175a5960.md)
+
@@ -0,0 +1,10 @@
+4 个安全等级：
+
+- 安全一级
+
+    
+
+    
+
+
+
@@ -0,0 +1,112 @@
+LDAP模型是从X.500协议中继承而来的，是LDAP的一个组成部分，用于指导客户如何使用目录服务。LDAP定义了4个模型，包括信息模型(Information Model)、命名模型(Naming Model)、功能模型(Functional Model)、安全模型(Security Model)。
+
+**1.信息模型**
+
+LDAP信息模型用于描述LDAP中信息的表达方式，包含3部分：条目（Entries）、属性（Attribute）、值(Values)。LDAP使用专有逻辑格式存储信息，这种模型既不是关系的，也不是完全面向对象的。简单概括为：
+
+① LDAP中信息逻辑上表示为条目。
+
+② 条目包含一到多个对象类。
+
+③ 每个对象类由多个属性组成。
+
+④ 每个属性包含一到多个同一类型的数值。
+
+⑤ 对象类和属性的类型定义构成了schema。
+
+条目是目录中最基本的信息单元，可以理解为目录树中的一个节点。LDAP客户和服务器使用条目共享信息，条目是LDAP服务器的基本元素。执行搜索时服务器返回一组匹配条目，但修改时一次只能影响服务器中的一个条目。条目可以被任何支持LDAP的客户端创建，或通过使用服务器工具导入，也可由应用程序基于非LDAP数据或用户信息创建。
+
+在目录中添加一个条目时，该条目必须包含一个或者多个对象类（objectClass），每一个对象类规定了该条目中的必选属性和可选属性。图6-1展示了一个典型目录的一部分，它反映了现实世界中一个组织的管理对象。
+
+![http://scanywhere.com/images/technology/LDAP-1.jpg](http://scanywhere.com/images/technology/LDAP-1.jpg)
+
+**图6-1 组织结构目录树**
+
+每一个条目都有一个DN（distinguished name，辨别名），用于唯一标识条目在目录中的位置，本书将在命名模型中详细介绍DN。
+
+每个条目都是由多个属性组成的，每一个属性描述了对象的一个约束。每个属性具有一个类型和一个或多个值。该类型描述了包含在属性中的信息类型，其值中包含实际数据。
+
+例如，表6-1描述了一个人员条目，属性包括全称、名、姓、电话号码、电子邮件地址。
+
+|||
+|-|-|
+|属性类型|属性值|
+|cn|张三|
+|telephoneNumber|5804669062300098|
+|mail|zs@163.com|
+
+**表6-1人员属性**
+
+属性有与之关联的语法和匹配规则，属性语法指定可以在属性中存放的数据格式，如INTEGER语法允许值中只包含数字，不能包含非数字字符。
+
+匹配规则作用有二：第一，比较值是否相等；第二，对值进行排序。
+
+**2．命名模型**
+
+LDAP命名模型定义了如何在目录系统中组织数据以及如何从目录系统中查找数据命名模型的灵活性可以使你很方便地以想要的方式组织数据。例如，可以把组织中所有员放在一个容器下，所有组放在一个容器下，或按组织结构的地理分布组织目录结构。
+
+LDAP命名模型指定将条目按类似倒立的树结构进行规划，非常类似于UNIX系统的文件系统，如图6-2和图6-3所示。
+
+![http://scanywhere.com/images/technology/LDAP-2.jpg](http://scanywhere.com/images/technology/LDAP-2.jpg)
+
+**图6-2 目录树结构**
+
+![http://scanywhere.com/images/technology/LDAP-3.jpg](http://scanywhere.com/images/technology/LDAP-3.jpg)
+
+**图6-3 UNIX 文件系统**
+
+
+
+在LDAP目录中任何一个节点都可以包含信息，同时也可以是一个容器，也就是说任何一个LDAP条目都可以有子节点。图6-4表示了一个典型的目录结构，在目录树中，条目ou-People，dc-example，dc=com和条目ou=Devices，dc=example，dc=com都既包含属性又包含子节点。
+
+通过命名模型，可以给出目录中任何条目的唯一名称，从而可以毫无歧义地引用任一个条目。在LDAP中使用DN来引用条目。
+
+在目录中，按目录树从下到上对条目进行命名，如图6-4中的灰色条同的DN名称为uid=bjensen，ou=people，dc=example，dc=com。因为这种树形结构决定了从根节点到其他任何节点的路径是唯一的，所以说每一个条目的DN是唯一的。
+
+![http://scanywhere.com/images/technology/LDAP-4.jpg](http://scanywhere.com/images/technology/LDAP-4.jpg)
+
+**图6-4 典型目录结构**
+
+在DN中最左边的内容称为相对辨别名（RDN，Relative Distinguished Name）。如ou=People，dc=example，dc=com的RDN为ou=People。对于共享同一个父节点的所有节点的RDN必须是唯一的。如果不属于同一个父节点，则节点的RDN可以相同。当特殊字符出现在DN中时，必须进行转义，如表6-2所示。
+
+||||
+|-|-|-|
+|字符|数值|转义序列|
+|在DN或RDN开始或结尾的空格|32|\空格|
+|在DN或RDN开始的#|35|\#|
+|逗号（，）|44|\，|
+|加号（+）|43|\+|
+|双引号（“）|34|\”|
+|反斜线（\）|92|\\|
+|小于符（<）|60|\<|
+|大于符（>）|62|\>|
+|分号（;）|59|\;|
+
+表6-2 特殊字符转义表
+
+**3.功能模型**
+
+LDAP功能模型描述了LDAP协议可以采用的相关操作，以访问存储在目录树中的数据。在LDAP中共有4类10种操作。
+
+①查询类操作，如搜索、比较。
+
+②更新类操作，如添加条目、删除条目、修改条目、修改条目名。
+
+③认证类操作，如绑定、解绑定。
+
+④其他操作，如放弃和扩展操作。
+
+除了扩展操作，另外9种是LDAP的标准操作。扩展操作是LDAP中为了增加新的功能提供的一种标准的扩展框架，当前已经成为LDAP标准的扩展操作，有修改密码和StartTLS扩展，在新的RFC标准和草案中正在增加一些新的扩展操作，不同的LDAP厂商也均定义了自己的扩展操作。
+
+**4．安全模型**
+
+安全模型提供一个安全框架，保护目录中的信息不被非法访问。LDAP中的安全模型主要通过身份认证、安全通道和访问控制(ACL)实现。
+
+LDAP是一个面向连接的协议，在能够对LDAP目录进行任何操作之前，LDAP客户端必须获得一个到LDAP服务端的连接，在这个过程中需要对LDAP客户端的身份进行验证，这一过程可以理解为用户绑定。
+
+LDAP v2只支持简单的密码验证。LDAP v3实现了SASL安全框架，SASL为多种验证协议提供了一种标准的验证方法，对于不同的验证系统，可以实现特定的SASL机制。
+
+在LDAP中提供了基于SSL/TLS的通信安全保障。SSL/TLS基于PKI信息安全技术，LDAP通过StartTLS方式启动TLS服务，可以提供通信中的数据保密性、完整性保护；通过强制客户端证书认证的TLS服务，同时可以实现对客户端身份和服务器端身份的双向验证。
+
+在用户通过验证之后，可以为该用户分配附加的权限。比如，一些用户只能查看特定的条目，而不能修改；一些用户可以查看并且修改所有的条目等。这一过程可以理解为访问控制。
+
@@ -0,0 +1,22 @@
+## 后量子密码 (Post-quantum Cryptography) 及背景
+
+1994 年，Peter Shor 提出了著名的量子算法。Shor 的量子算法可以实现：当足够大的量子计算机存在时，一些数论中的困难问题可以被有效解决，例如：离散对数问题（及其椭圆曲线版本），并可以被用于分解大整数。注意到离散对数问题（及其椭圆曲线版本）和大整数分解问题是目前广泛应用的公钥密码学算法（[Diffie-Hellman 密钥交换协议](https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B)、[RSA](https://zh.wikipedia.org/wiki/RSA%E5%8A%A0%E5%AF%86%E6%BC%94%E7%AE%97%E6%B3%95)、[椭圆曲线 (ECC)](https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6) 等）的困难性的基础。在没有量子计算机和对应的算法时，现有的经典公钥密码算法配合较为合适的参数（例如 2048 比特的 RSA）可以被认为在一定时间内是安全的。但是，一旦大型的量子计算机成功建造，Shor 的算法被认为可以快速且完全攻破大多数目前使用的公钥密码算法，即使参数被显著增大 $^{[1]}$。
+
+*[1] 这里的“参数被显著增大”指的是在计算和通信开销可接受范围内的情况。当参数被“急剧增大”时，RSA 算法被认为可以“抵抗”量子计算机攻击。但此时，公钥的尺寸已经接近几百 M 甚至大于 1 GB。*
+
+在真实世界中，广泛应用于各类安全应用、协议中的密码学原语包括且不仅限于：公钥加密、数字签名、密钥交换等。基于所有的互联网服务都依赖于密码学算法，包括且不仅限于 TLS、HTTPS、SSH、邮件、电子商务、移动支付、数字货币等。所有网络、软件、系统、应用安全等所有现代互联网的应用都将受到严峻的挑战。
+
+后量子密码学 (Post-quantum Cryptography) 的任务是构造可以抵抗经典和量子计算机攻击的新的密码学算法，以应对量子计算机对于密码学的威胁。主要的后量子密码学实现技术有：基于格 (Lattice-based)、基于哈希 (Hash-based) 、基于编码 (Code-based) 、基于多变量 (Multivariate-based) 、基于格 (Lattice-based) 等。这四种方法各有其利弊。目前认为，在上述四种实现后量子密码算法的技术中，基于格的密码算法可以实现最强的安全性、最小的总通信开销、最快的计算速度和最多样化的密码算法设计。
+
+截至目前，Google 已对后量子密码学算法的实用性进行[实际测试](https://security.googleblog.com/2016/07/experimenting-with-post-quantum.html)。Google 将后量子密钥交换协议应用于 TLS 中，并在 Google Chrome 浏览器的 Canary 分支和部分 Google Play 服务器上成功进行了测试。
+
+您可以参考后量子密码学的 [Wikipedia 页面](https://en.wikipedia.org/wiki/Post-quantum_cryptography)、[Nature 上的文章](https://www.nature.com/articles/nature23461)或[较为系统的介绍后量子密码学的书](https://www.springer.com/us/book/9783540887010)等资源对后量子密码学进行更多的了解。您还可以参考这两篇较为详细的后量子密码学中文介绍：[“从量子计算到量子安全”](http://www.knowfar.org.cn/html/zhanlue/201612/22/641.htm)和[“后量子密码技术发展分析”](http://www.knowfar.org.cn/html/zhanlue/201701/13/657.htm)。
+
+# [https://if2007.github.io/2018/04/06/nist_pqc/#NIST-后量子密码标准征集工作](https://if2007.github.io/2018/04/06/nist_pqc/#NIST-后量子密码标准征集工作)NIST 后量子密码标准征集工作
+
+2016 年 12 月 20 日，美国国家标准技术研究所 (National Institute of Standards and Technology, NIST) [正式宣布](https://csrc.nist.gov/news/2016/public-key-post-quantum-cryptographic-algorithms)启动全世界范围内的后量子密码算法标准征集竞赛，旨在征集新一代的可以抵抗量子计算机攻击的公钥加密、数字签名和密钥交换协议。此竞赛欢迎全球范围内所有个人/组织向 NIST 提交密码算法的文档、工程实现。NIST 公开所有符合初步筛选标准的候选算法，供所有人进行分析和评论，利用所有人的力量共同制定新一代的密码学算法标准。
+
+候选算法的征集工作已于 2017 年 11 月 30 日截止，共有来自 25 个国家的 82 个候选算法被提交，其中 69 个符合 NIST 的初步筛选标准。全部 69 个候选算法涵盖了基于格、多变量、编码和哈希等的后量子密码学算法构造。所有候选算法的文档已于 2017 年 12 月[公布于 NIST 网站](https://csrc.nist.gov/projects/post-quantum-cryptography/round-1-submissions)。
+
+NIST 的后量子密码学专家 Dustin Moody 在 AsiaCrypt 2017 会议上对 NIST 的后量子密码标准征集竞赛和现状进行了详细的介绍。报告的 Slide 可以在[这里下载](https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/asiacrypt-2017-moody-pqc.pdf)。
+
@@ -0,0 +1,35 @@
+RSA定义的 PKCS 各版本，用途各不相同；
+
+PKCS #1 定义私钥签名运算的填充方式， v1.5 是 PKCS1_PADDING, v2.1 是 PKCS1_PSS_PADING；
+
+PKCS#2：涉及了RSA的消息摘要加密，这已被并入PKCS#1中。
+
+PKCS#3：Diffie-Hellman密钥协议标准。PKCS#3描述了一种实现Diffie- Hellman密钥协议的方法。
+
+PKCS#4：最初是规定RSA密钥语法的，现已经被包含进PKCS#1中。
+
+PKCS #5  基于口令的加密标准。PKCS#5描述了使用由口令生成的密钥来加密8位位组串并产生一个加密的8位位组串的方法。PKCS#5可以用于加密私钥，以便于密钥的安全传输（这在PKCS#8中描述）。定义了加密运算的填充方式，8字节填充，Java标准接口支持；例如，串0x56在经过PKCS5填充之后会成为0x56 0x07 0x07 0x07 0x07 0x07 0x07 0x07因为需要填充7字节，因此填充的内容就是7。当然特殊情况下，如果已经满足了8的整倍数，按照PKCS5的规则，仍然需要在尾部填充8个字节，并且内容是0x08,目的是为了加解密时统一处理填充。
+
+PKCS#6：扩展证书语法标准。PKCS#6定义了提供附加实体信息的X.509证书属性扩展的语法（当PKCS#6第一次发布时，X.509还不支持扩展。这些扩展因此被包括在X.509中）。
+
+PKCS #7   密码消息语法标准。PKCS#7为使用密码算法的数据规定了通用语法，比如数字签名和数字信封。PKCS#7提供了许多格式选项，包括未加密或签名的格式化消息、已封装（加密）消息、已签名消息和既经过签名又经过加密的消息。 填充算法扩充了PKCS#5 的限制，填充长度可以是1-255字节；通过第三方库可以在Java中支持 PKCS#7 填充；
+
+PKCS#8：私钥信息语法标准。PKCS#8定义了私钥信息语法和加密私钥语法，其中私钥加密使用了PKCS#5标准；
+
+PKCS#9：可选属性类型。PKCS#9定义了PKCS#6扩展证书、PKCS#7数字签名消息、PKCS#8私钥信息和PKCS#10证书签名请求中要用到的可选属性类型。已定义的证书属性包括E-mail地址、无格式姓名、内容类型、消息摘要、签名时间、签名副本（counter signature）、质询口令字和扩展证书属性。
+
+PKCS#10：证书请求语法标准。PKCS#10定义了证书请求的语法。证书请求包含了一个唯一识别名、公钥和可选的一组属性，它们一起被请求证书的实体签名（证书管理协议中的PKIX证书请求消息就是一个PKCS#10）。
+
+PKCS#11：密码令牌接口标准。PKCS#11或“Cryptoki”为拥有密码信息（如加密密钥和证书）和执行密码学函数的单用户设备定义了一个应用程序接口（API）。智能卡就是实现Cryptoki的典型设备。注意：Cryptoki定义了密码函数接口，但并未指明设备具体如何实现这些函数。而且Cryptoki只说明了密码接口，并未定义对设备来说可能有用的其他接口，如访问设备的文件系统接口。
+
+PKCS#12：个人信息交换语法标准。PKCS#12定义了个人身份信息（包括私钥、证书、各种秘密和扩展字段）的格式。PKCS#12有助于传输证书及对应的私钥，于是用户可以在不同设备间移动他们的个人身份信息。
+
+PKCS#13：椭圆曲线密码标准。PKCS#13标准当前正在完善之中。它包括椭圆曲线参数的生成和验证、密钥生成和验证、数字签名和公钥加密，还有密钥协定，以及参数、密钥和方案标识的ASN.1语法。
+
+PKCS#14：伪随机数产生标准。PKCS#14标准当前正在完善之中。为什么随机数生成也需要建立自己的标准呢？PKI中用到的许多基本的密码学函数，如密钥生成和Diffie-Hellman共享密钥协商，都需要使用随机数。然而，如果“随机数”不是随机的，而是取自一个可预测的取值集合，那么密码学函数就不再是绝对安全了，因为它的取值被限于一个缩小了的值域中。因此，安全伪随机数的生成对于PKI的安全极为关键。
+
+PKCS#15：密码令牌信息语法标准。PKCS#15通过定义令牌上存储的密码对象的通用格式来增进密码令牌的互操作性。在实现PKCS#15的设备上存储的数据对于使用该设备的所有应用程序来说都是一样的，尽管实际上在内部实现时可能所用的格式不同。PKCS#15的实现扮演了翻译家的角色，它在卡的内部格式与应用程序支持的数据格式间进行转换。
+————————————————
+版权声明：本文为CSDN博主「zhbpd」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
+原文链接：[https://blog.csdn.net/zhbpd/article/details/107732995](https://blog.csdn.net/zhbpd/article/details/107732995)
+
@@ -0,0 +1,8 @@
+
+
+[PKI体系框架](PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83+abf96506-5c16-4a03-ac32-1839f6dcc2a3/PKI%E4%BD%93%E7%B3%BB%E6%A1%86%E6%9E%B6%20ed780626-80e7-461a-8b12-81290718f525.md)
+
+[PKI/数字证书与私钥](PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83+abf96506-5c16-4a03-ac32-1839f6dcc2a3/PKI+%E6%95%B0%E5%AD%97%E8%AF%81%E4%B9%A6%E4%B8%8E%E7%A7%81%E9%92%A5%20e89e4605-b474-4bc8-963d-ecdc5999a2ea.md)
+
+[PKI/CA与KMC](PKI%E6%8A%80%E6%9C%AF%E8%A7%84%E8%8C%83+abf96506-5c16-4a03-ac32-1839f6dcc2a3/PKI+CA%E4%B8%8EKMC%20dfb166ae-f52a-4cdb-90b6-499293b1f684.md)
+
@@ -0,0 +1,82 @@
+**1．CA最初目的是签发数字证书**
+
+为解决数字证书的签发问题，PKI引入CA．用于对数字证书进行集中签发。CA是Certificate Authority昀缩写，字面含义是证书权威，也称作CA中心、认证中心。CA中心拥有自己的公钥和私钥，使用其私钥给用户（包含CA巾心自己）签发数字证书，具体签发过程如下：
+
+(1)将用户身份信息和用户公钥信息，按照特定格式组成数据D。
+
+(2)选择摘要算法对数据D进行计算得到摘要H。
+
+(3)使用CA私钥对摘要H进行加密得到数字签名S。
+
+(4)将用户身份信息、用户公钥信息和数字签名S，按照特定格式就可组成数字证书。
+
+**2．CA应对数字证书的全生命周期进行管理**
+
+CA实际是一种特殊的公钥管理中心，为实现数字证书的安全性，应对数字证书的全生命周期进行管理，主要包括：
+
+(1)数字证书的签发和更新。证书签发主要针对新用户；证书更新主要针对已有证书用户，更新时公钥可以改变，也可以不变。
+
+(2)数字证书的作废（注销、撤销或吊销）。证书作废后将成无效证书，永远不能使用。
+
+(3)数字证书的冻结（挂失）和解冻。证书冻结后将成无效证书，但可以通过解冻恢复成有效状态。
+
+(4)数字证书的查询或下载。应提供公开服务方式，允许用户根据条件随时查询证书并下载。常用服务方式有HTTP和LDAP。
+
+(5)数字证书状态查询。应提供公开服务方式，允许用户随时查询证书状态，以便判断该证书是否处于有效状态。常用服务方式有CRL和OCSP。
+
+**3．KMC用于管理私钥**
+
+如果使用公钥（数字证书）对数据进行加密，则只有与公钥对应的私钥才能进行解密，从而可实现用户数据的保密性。当私钥丢失时，如果没有备份和恢复机制，将导致公钥加密的所有数据都无法解密，可能给用户带来损失。
+
+为解决私钥的备份与恢复问题，PKI引入了KMC，用于对私钥的全生命周期进行管理。KMC是Key Management Center的缩写。
+
+用户公私钥对可由KMC产生，提交CA签发数字证书后，将私钥和数字证书同时安全移交给用户，而KMC将私钥留作备份，可按需要给用户恢复。用户公私钥对也可由用户自己产生（使用软件或密码设备），在向CA中心申请数字证书时，可将私钥安全提交KMC留作备份。
+
+**4．双证书机制**
+
+为防止用户身份被冒用，应保证用户私钥的唯一性，不允许备份恢复。为防止公钥加密后的数据无法解密，应提供用户私钥的备份恢复机制。
+
+为解决这两种矛盾的应用需求，PKI引入双证书机制：签名证书和加密证书。
+
+签名证书及私钥只用于签名验签，不能用于加密解密；为保证签名私钥的唯一性，该公私钥对必须由用户自己产生，同时采用硬件技术（如只允许在硬件密码设备内产生公私钥对、私钥不允许导出等）保证无法复制，在证书签发过程中CA中心并不知道该私钥，只对其公钥进行操作。该私钥没有备份，因此永远不能恢复。
+
+加密证书及私钥只用于加密解密，不能用于签名验签。为实现解密私钥的备份恢复机制，该公私钥对必须由KMC产生，由CA签发完数字证书后安全移交给用户，用户应采用硬件技术保证该私钥的安全性。KMC可根据需要恢复该私钥。
+
+**5．LDAP**
+
+CA中心存储着所有数字证书，并通过公开服务形式供用户随时查询或下载。为解决数字证书查询或下载的性能问题，避免CA中心成为性能瓶颈，PKI引入了LDAP技术，通过LDAP方式对外提供高速证书查询或下载服务。
+
+专业的关系型数据库管理系统（如Oracle、DB2等）专门对结构化数据进行管理，应用系统只需通过SQL语句（报文协议）发送各种数据管理指令，而具体管理工作完全由数据库管理系统负责。尽管这种数据管理方式大大简化了应用系统的复杂度，但由于其读写功能相对均衡，很难满足高性能的查询服务。为获得高性能的查询服务，需要对数据管理的读取功能进行特殊优化，于是出现了目录服务技术（DAP，Directory Access Protocol）。目录服务技术对查询功能进行优化，比修改操作快10倍以上，适合快速响应和大容量查询服务。DAP技术通过目录树方式对数据进行管理，应用系统只需通过x.500协议就能对数据进行快速查询。
+
+由于X.500协议过于复杂，实现成本很高，于是国际组织对X.500进行了简化，形成LDAP标准，而且LDAP支持TCP/IP协议，更适合于互联网领域使用。LDAP为轻量目录访问协议，是Light-weight Directory Access Protocol的缩写。
+
+由于数字证书是可以公开的，CA中心也可以将其签发的数字证书存储到其他地方，供用户查询或下载。
+
+**6．CRL和OCSP**
+
+当用户私钥泄露后，CA中心有责任将该用户的证书标记为失效。但用户如何获得对方证书足否失效的状态呢？为方便用户获得证书状态，PKI引入了CRL和OCSP技术。
+
+(1) CRL(Certificate Revocation List)
+
+CRL为证书作废列表，是Certificate Revocation List的缩写，也称作证书黑名单，是一种特殊的文件格式，包含所有失效的证书清单、下次CRL生成时间和CA中心私钥的签名。
+
+CA中心定期生成CRL．并将下次生成时问写入CRL中，方便用户按时定期下载CRL。跟数字证书类似，CRL也是通过CA中心私钥的签名来保证CRL无法被篡改的。用户只需定期获取CRL后，就可在本地脱机验证证书是否失效，在下次CRL生成时间之前无需联系CA中心。
+
+由于CRL是可以公开的，CA中心也可以将其链发的CRL存储到其他地方，供用户查询或下载。CRL也可以发布到LDAP中，提供高速下载服务。
+
+(2) OCSP (Online Certificate Status Protocol)
+
+当CA中心将私钥已泄露的用户证书标记为失效后，如果还未到下次CRL生成时间，此时其他用户通过最新CRL并不知道该用户证书已经失效，依然将该用户当作有效用户继续进行各种保密通信和合法交易，因此可能会造成一定的损失。
+
+为解决CRL滞后的缺陷，避免给高实时性或高风险交易造成重大损失，PKI引入了OCSP，对用户提供实时的证书状态查询服务。OCSP为在线证书状态协议，是Online Certificate Status Protocol的缩写。当用户需要实时查询对方证书是否有效时，可通过OCSP协议实时访问CA中心获得对方证书的当前状态。
+
+**7．RA**
+
+在保证CA系统安全性的前提下，为方便证书业务远程办理、方便证书管理流程与应用系统结合，PKI引入了RA，专门用于对用户提供面对面的证书业务服务，负责用户证书办理／作废申请、用户身份审核、制作证书并移交用户等功能，而涉及证书签发时则提交CA系统集中处理。RA是Registry Authority的缩写，又称作RA中心、注册中心。有时候，证书管理流程会与应用业务流程结合，并不单独体现出来，如对于网上银行，证书管理流程就会融合到网银业务流程中。
+
+RA可以部署多个，既可以单独部署，也可以与应用系统集成。
+
+CA主要模块组成如下图所示。
+
+![http://scanywhere.com/images/technology/PKI-CA-KMC.jpg](http://scanywhere.com/images/technology/PKI-CA-KMC.jpg)
+
@@ -0,0 +1,70 @@
+**1．数字证书的最初目的是建立公钥与用户之间的对应关系**
+
+由于公钥是随机产生的，从公钥无法直接判断属于哪个用户。为解决公钥与用户映射关系问题，PKI引入数字证书，用于建立公钥与用户之间的对应关系。
+
+数字证书实际是一种特殊的文件格式，包含用户身份信息、用户公钥信息和CA私钥的数字签名。用户身份信息由姓名或名称、单位、城市、国家等组成。X.509标准规定了数字证书的具体格式。
+
+由于数字证书中包含用户身份信息和公钥信息，根据数字证书就可直接判断该公钥属于哪个用户。如某数字证书包含用户信息“诸葛亮”和公钥PK，则可判断公钥PK就是诸葛亮的。
+
+由于数字证书中包含CA私钥的数字签名，使用CA公钥对数字证书中CA私钥的数字签名进行解密处理后，就可立刻判断该数字证书是否被篡改，因此数字证书具有防伪性，于是，数字证书中公钥和用户之间对应关系也值得可信。当然，数字证书防伪性的前提是公钥算法和CA私钥都是安全的。
+
+由于数字证书中不包含秘密信息，因此数字证书可公开发布。
+
+数字证书主要内容显示如图2-2所示，其中，“使用者”为用户身份信息，“公钥”为用户公钥信息，“有效期”属于附加策略。
+
+![http://scanywhere.com/images/technology/pki-signature-privatekey.jpg](http://scanywhere.com/images/technology/pki-signature-privatekey.jpg)
+
+                                                        **图2-2 数字证书主要内容显示**
+
+**2．数字证书可作为网络身份证**
+
+现实生活中，公安部为每人颁发一张二代身份证，身份证上包含姓名、性别、出生日期、省份、身份证号、照片等信息。当购票、住店、坐飞机时，身份证持有人（或持证人）只需出示身份证即可证明自己的身份。只有通过以下四个方面的合法性验证，才能完全确认持证人的合法身份：
+
+(1)验证身份证是否伪造。需要专门的二代身份证读写设备来验证。
+
+(2)验证身份证信息是否正确。需要查询身份证数据库，需要公安部门提供；也可由公安部门在发放身份证时保证。
+
+(3)验证身份证是否与持证人一致。需要对比身份证上照片与持证人的长相。
+
+(4)验证身份证是否在黑名单上。需要查询黑名单数据库，如公安部通缉犯清单，需要公安部门提供。
+
+既然数字证书包含用户身份信息，而且具有防伪性且可以公开，那么数字证书持有人（或持证人）在网络世界中能否也像现实生活中一样，只需出示数字证书即可证明自己身份呢？答案是肯定的。如果能通过类似二代身份证的四个方面合法性验证，数字证书就可作为网络身份证。下面来确认一下，数字证书能否通过四个方面的合法性验证：
+
+(1)验证数字证书是否伪造。可通过CA公钥验证。
+
+(2)验证数字证书中信息是否正确。可由CA中心在签发数字证书时保证。
+
+(3)验证数字证书是否与持证人一致。可要求持证人使用私钥对特定数据进行加密或签名，然后使用数字证书中的公钥来解密该数据或验签，从而可验证持证人是否持有与数字证书中的公钥对应的私钥。
+
+(4)验证数字证书是否在黑名单上。可通过查询黑名单数据库来实现，但需要CA中心提供黑名单。
+
+因此，数字证书作为网络身份证，可有效解决网络世界中“你是谁”的问题。由于数字证书采用公钥密码技术实现，从技术上保证了每个人“钥匙”的唯一性，既不重复也无法复制，所以数字证书比现实生活中的各种钥匙安全很多。
+
+**3．数字证书可附加很多策略**
+
+由于数字证书具有防伪性和公开性，因此数字证书中不仅可包含用户身份信息和用户公钥信息，而且还可以附加其他策略信息，这些信息同样具有防伪性和公开性。
+
+X.509数字证书标准中规定常用策略信息主要包括：
+
+(1)有效期。包括起始时间和终止时问。
+
+(2)密钥用途。表示该公钥和私钥用于什么目的，如数据签名、数据加密、签发证书、用于安全电子邮件等。
+
+(3)别名。包括持证人别名和CA中心别名。
+
+(4)黑名单地址。
+
+(5)是否CA中心的数字证书。如果是CA中心的数字证书，则规定能签发几级证书。
+
+**4．CA中心的数字证书**
+
+用户在验证数字证书是否被篡改时，必须首先获得CA中心的公钥。为方便用户识别CA中心的公钥，CA中心也为自己签发数字证书。该证书包含CA中心公钥、CA中心身份信息和CA中心私钥的签名。CA中心的数字证书有时也称作CA证书。
+
+由于CA证书是验证其他证书合法性的前提和基础，所以CA证书的正确性至关重要。尽管可通过网络直接下载获取CA证书，但为避免被欺骗，需要通过其他方式验证CA证书的正确性。可通过电话方式、官方报纸或官方电视公布CA证书的摘要值，用户通过核对该摘要值即可确认该证书的正确性。
+
+**5．私钥**
+
+对于公钥密码技术，公钥和私钥是成对出现的。公钥以数字证书形式存在，可以公开，但私钥必须保密。为保证私钥的安全性，一般将私钥保存在硬件密码设备中（如个人的私钥可保存在USB Key或lC卡中，系统的私钥可保存在加密机或加密卡中），而且不允许私钥导出硬件密码设备：通过口令、指纹等方式来访问控制该硬件密码没备。如果将私钥保存在硬盘文件中，则需要通过口令进行加密保护，但私钥文件容易被复制。
+
+为保证私钥的唯一性，可只允许在硬件密码设备内产生公私钥对，通过硬件技术保证私钥无法导出，然后只导出公钥提交CA中心签发数字证节。
+
@@ -0,0 +1,44 @@
+PKI是Public Key Infrastructure的缩写，其主要功能是绑定证书持有者的身份和相关的密钥对（通过为公钥及相关的用户身份信息签发数字证书），为用户提供方便的证书申请、证书作废、证书获取、证书状态查询的途径，并利用数字证书及相关的各种服务（证书发布，黑名单发布，时间戳服务等）实现通信中各实体的身份认证、完整性、抗抵赖性和保密性。
+
+根据数字证书格式及密钥管理方式的不同，PKI也包括多种模式，如X.509模式、PGP模式、IBE/CPK模式、EMV模式等。X.509模式的PKI也称作PKIX。由于X.509标准已经成为数字证书格式的事实标准，因此大部分情况下PKI特指PKIX。如非特殊说明，本文中PKI均指PKIX。
+
+PKI体系框架主要包括三部分内容。
+
+**1．数字证书与私钥**
+
+用户或系统只有拥有自己的公钥和私钥后，才能实现数字签名和加解密功能。由于公钥是随机产生的，因此从公钥无法直接判断属于哪个用户。
+
+为解决公钥与用户映射关系问题，PKI引入了数字证书，用于建立公钥与用户之间的对应关系。数字证书实际上是一种特殊的文件格式，包含用户身份信息、用户公钥信息和CA私钥的数字签名。X.509标准规定了数字证书的具体格式。数字证书中只包含公钥，并不包括私钥。由于数字证书中包含CA私钥的数字签名，因此数字证书具有防伪性。由于数字证书中不包含秘密信息，因此数字证书具有公开性。数字证书作为网络身份证，可有效解决网络世界中“你是谁”的问题。
+
+为保证私钥的安全性，一般将私钥保存在硬件密码设备中（如个人的私钥可保存在USBKey或lC卡中，系统的私钥可保存在加密机或加密卡中），而且不允许私钥导出硬件密码设备：通过口令、指纹等方式来访问控制该硬件密码设备。如果将私钥保存在硬盘文件中，则需要通过口令进行加密保护，但私钥文件容易被复制。
+
+**2．数字证书的管理**
+
+为解决数字证书的签发问题，PKI引入CA，对数字证书进行集中签发。CA是Certificate Authority的缩写，字面含义是证书权威，也称作CA中心、认证中心。CA中心拥有自己的公钥和私钥，使用其私钥给用户（包含CA中心自己）签发数字证书。
+
+CA实际是一种特殊的公钥管理中心，为实现数字证书的安全性，对数字证书的全生命周期进行管理，主要包括：数字证书的签发和更新、数字证书的作废（注销、撤销或吊销）、数字证书的冻结（挂失）和解冻、数字证书的查询或下载、数字证书状态查询等。当私钥丢失时，如果没有备份和恢复机制，将导致公钥加密的所有数据都无法解密，可能给用户带来损失。为解决私钥的备份与恢复问题，PKI引入了KMC，用于对私钥的全生命周期进行管理。KMC是Key Management Center的缩写。用户公私钥对可由KMC产生，提交CA签发数字证书后，将私钥和数字证书同时安全移交给用户，而KMC将私钥留作备份，可按需要给用户恢复。用户公私钥对也可由用户自己产生（使用软件或密码设备），在向CA中心申请数字证书时，可将私钥安全提交KMC留作备份。
+
+为防止用户身份被冒用，应保证用户私钥的唯一性，不允许备份恢复。为防止公钥加密后的数据无法解密，应提供用户私钥的备份恢复机制。为解决这两种矛盾的应用需求，PKI引入双证书机制：签名证书和加密证书。签名证书及私钥只用于签名验签，不能用于加密解密，该公私钥对必须由用户自己产生，KMC不备份签名私钥。加密证书及私钥只用于加密解密，不能用于签名验签，该公私钥对必须由KMC产生，且KMC对加密私钥进行备份。
+
+CA中心存储着所有数字证书，并通过公开服务形式供用户随时查询或下载。为解决数字证书查询或下载的性能问题．避免CA中心成为性能瓶颈，PKI引入了LDAP技术，通过LDAP方式对外提供高速证书查询或下载服务。LDAP为轻量目录访问协议，是Light-weight Directory Access Protocol的缩写。
+
+当用户私钥泄露后，CA中心有责任将该用户的证书标记为失效。但用户如何获得对方证书是否失效的状态呢？为方便用户获得证书状态，PKI引入了CRL和OCSP技术。CRL为证书作废列表，是Certificate Revocation List的缩写，也称作证书黑名单。OCSP为在线证书状态协议，是Online Certificate Status Protocol的缩写。
+
+在保证CA系统安全性的前提下，为方便证书业务远程办理、方便证书管理流程与应用系统结合，PKI引入了RA，专门用RA对用户提供面对面的证书业务服务，负责用户证书办理／作废申请、用户身份审核、制作证书并移交用户等功能，而涉及证书签发时则提交CA系统集中处理。RA是Registry Authority的缩写，又称作RA中心、注册中心。有时候，证书管理流程会与应用业务流程结合，并不单独体现出来，如对于网上银行，证书管理流程就会融合到网银业务流程中。
+
+为保证CA系统在数字证书管理方面的规范性、合规性和安全性，PKI引入电子认证服务机构，以第三方运营的方式对外提供数字证书相关服务。《电子签名法》规定：“电子签名需要第三方认证的，由依法设立的电子认证服务提供者提供认证服务。”显然，电子签名法不仅赋予了电子签名的法律效力，而且明确了电子认证服务提供者的法律地位。电子认证服务提供者，又称作电子认证服务机构或CA中心，需要独立运营，不仅需要满足政策法规的各项要求，而且需要满足业务运营的业务需求。
+
+**3．数字证书的应用**
+
+基于数字证书可实现四种基本安全功能：身份认证、保密性、完整性和抗抵赖性。
+
+基于证书接口中间件（模块或组件），应用系统可以很方便地使用数字证书技术，从而提高应用系统的身份认证强度、保证应用系统中各种敏感数据的保密性、保证应用系统中各种敏感数据和交易记录的完整性、用户各种操作或交易的不可否认性（抗抵赖性）。
+
+PKI技术经过30多年的发展历程，已经形成比较完善的标准规范体系，几乎覆盖应用系统的各个方面，目前很多软件都已经支持数字证书技术，如操作系统、数据库系统、Web服务器、应用服务器等。由于受应用环境多样性和应用技术复杂性的影响或限制，在不同的应用环境和应用技术下，数字证书技术应用的方式可能差异很大。
+
+网上报税和网上银行是数字证书应用的典型案例。国内大部分省份上千万家企业已经通过数字证书在进行网上报税。数字证书（俗称U盾）已经成为国内网上银行的标准配置。如果没有数字证书，企业用户将不允许使用网上银行。上亿个人用户已经通过数字证书访问网上银行实现转账或汇款等资金操作。
+
+PKI体系框架如下图：
+
+![http://scanywhere.com/images/technology/pki-framework.jpg](http://scanywhere.com/images/technology/pki-framework.jpg)
+
@@ -0,0 +1,18 @@
+||名称|RFC|
+|-|-|-|
+|PKCS #1|RSA Cryptography Standard (RSA密码标准)|RFC 3447|
+|PKCS #2|已撤销，用以规范RSA加密摘要的转换方式，已并入PKCS #1|-|
+|PKCS #3|Diffie–Hellman Key Agreement Standard (DH秘钥协商标准)|-|
+|PKCS #4|已撤销，用以定义RSA秘钥的格式，已并入PKCS #1|-|
+|PKCS #5|Password-based Encryption Standard (基于口令的密码标准)|RFC 2898|
+|PKCS #6|Extended-Certificate Syntax Standard (扩展的证书语法标准)|-|
+|PKCS #7|Cryptographic Message Syntax Standard (密码消息语法标准)|RFC 2315|
+|PKCS #8|Private-Key Information Syntax Standard (私钥信息语法标准)|RFC 5958|
+|PKCS #9|Selected Attribute Types (可供选择的属性类型)|RFC 2985|
+|PKCS #10|Certification Request Standard (证书请求语法标准)|RFC 2986|
+|PKCS #11|Cryptographic Token Interface (密码Token接口标准)|-|
+|PKCS #12|Personal Information Exchange Syntax Standar (个人信息交换语法标准)|RFC 7292|
+|PKCS #13|Elliptic Curve Cryptography Standard (椭圆曲线密码标准)，正在制定中||
+|PKCS #14|Pseudo-random Number Generation (伪随机数生成算法PRNG)，正在制定中||
+|PKCS #15|Cryptographic Token Information Format Standard (密码Token信息格式标准)||
+
@@ -0,0 +1,18 @@
+**Q1：什么是VPN？**
+A1：VPN的英文全称是“Virtual Private Network”，翻译过来就是“虚拟专用网络”。顾名思义，虚拟专用网络我们可以把它理解成是虚拟出来的企业内部专线。
+　　虚拟专用网（VPN）被定义为通过一个公用网络（通常是因特网）建立一个临时的、安全的连接，是一条穿过混乱的公用网络的安全、稳定的隧道。虚拟专用网是对企业内部网的扩展。虚拟专用网可以帮助远程用户、公司分支机构、商业伙伴及供应商同公司的内部网建立可信的安全连接，并保证数据的安全传输。虚拟专用网可用于不断增长的移动用户的全球因特网接入，以实现安全连接；可用于实现企业网站之间安全通信的虚拟专用线路，用于经济有效地连接到商业伙伴和用户的安全外联网虚拟专用网。
+
+**Q2：什么是SSLVPN？**
+A2：从概念角度来说，SSL VPN即指采用SSL （Security Socket Layer）协议来实现远程接入的一种新型VPN技术。SSL协议是网景公司提出的基于WEB应用的安全协议，它包括：服务器认证、客户认证（可选）、SSL链路上的数据完整性和SSL链路上的数据保密性。对于内、外部应用来说，使用SSL可保证信息的真实性、完整性和保密性。目前SSL 协议被广泛应用于各种浏览器应用，也可以应用于Outlook等使用TCP协议传输数据的C/S应用。正因为SSL 协议被内置于IE等浏览器中，使用SSL 协议进行认证和数据加密的SSL VPN就可以免于安装客户端。相对于传统的IPSEC VPN而言，SSL VPN具有部署简单，无客户端，维护成本低，网络适应强等特点。
+
+**Q3：我们的SSL VPN设备支持的认证方式？**
+A3：我们的SSL VPN设备支持的认证方式：
+　　　本地数据库认证
+　　　AD域认证
+　　　LDAP认证
+　　　RADIUS认证
+　　　RSA SecurID认证
+　　　SSL 双向认证
+　　　MAC地址认证
+　　　手机动态密码认证
+
@@ -0,0 +1,182 @@
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173019683-350983077.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173019683-350983077.png)
+
+在大数据和 AI 的时代背景下，数据已经成为了重要财富，大到政务数据、企业核心数据，小到个人信息、银行卡余额，**这些数据无一例外都是“隐私数据”，如果在使用和流转时发生泄漏都会造成巨大的损失。**
+
+那有没有什么方法，可以在不暴露数据隐私的前提下，让数据流动起来发挥更大的价值呢？在这个问题的驱使下我们找到了今天的主角——隐私计算。
+
+## 一、什么是隐私计算？
+
+隐私计算是指**在不泄露数据本身的情况下，实现数据分析和计算的技术，具有“数据可用不可见”的特点，让数据安全合规地流动起来。**
+
+下面用一个经典的百万富翁问题，来帮助理解什么是“数据可用不见”。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173037042-1565994367.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173037042-1565994367.png)
+
+假设有两个百万富翁，他们都想知道谁更富有，但又不想让对方或者第三方，知道自己具体有多少钱。
+
+- **数据本身**：具体的财富值（数据）
+
+- **计算**：比大小（可用）
+
+- **不泄露**：对方或第三方（不可见）
+
+按照常理，**进行比大小的计算是需要知道两个数是多少，才能比较大小，但这里不知道具体的数字**。所以上面这个问题在普通人看来是无解的，但其实这是一个密码学问题，也被称为“多方安全计算”（ MPC ）问题，由姚期智院士在 1982 提出，并给出了解决方案——混淆电路（篇幅有限这里不做详解），实现了数据的可用不可见。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230913003503828-1699821043.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230913003503828-1699821043.png)
+
+从隐私计算的技术发展时间线，我们不难看出隐私计算还是一个比较“新”的技术。随着零知识证明、差分隐私、全同态加密、联邦学习等技术的相继问世，目前已形成**三大应用技术路线多方安全计算（ MPC ）、联邦学习（ FL ）、可信执行环境（ TEE ），**隐私计算作为数据流通的重要技术已应用于金融、医疗、政务、广告等领域。
+
+- 金融：联合反洗钱、银(行)证(券)数据共享等
+
+- 医疗和健康：流行病接触者追踪等
+
+- 政务：案件调查、人口普查等
+
+随着欧盟 2018 年生效的《通用数据保护法案》，Google 、Facebook 等科技巨头都收到了巨额罚单。近两年，我国也相继出台了 **《数据安全法》** 和 **《个人信息保护法》**。因此，**如何让数据安全地流通起来，已经不再是一道附加题而是一道必答题。**
+
+如果我们把上面的“百万富翁”换成企业/机构的话，就可以很容易得出**隐私计算技术就是数据安全流通的答案 🔑。**
+
+## 二、PrimiHub
+
+那么，对于没有隐私计算技术背景的程序员、或是没有相关研发团队的企业/机构，**如何才能快速用上隐私计算技术，让数据流通起来创造更大的价值呢？**
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173100017-1094826619.jpg](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173100017-1094826619.jpg)
+
+今天，HelloGitHub 给大家带来一款**由密码学专家团队打造的开源隐私计算平台——PrimiHub**，它开箱即用、支持 CLI 和可视化 Web 界面，让你无需具备隐私计算技术背景，就能上手发起隐私计算任务。
+
+> GitHub 地址：[https://github.com/primihub/primihub](https://github.com/primihub/primihub)
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173108533-648540079.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173108533-648540079.png)
+
+下面，我将先介绍如何快速上手 PrimiHub ，最后通过演示一个完整的应用案例，让你能够真正的入门 PrimiHub ，并将隐私计算应用到实际的业务中。
+
+## 三、快速上手
+
+PrimiHub 是在隐私计算应用技术之上构建的隐私计算平台，封装了底层的密码学协议让开发者专注于业务、更容易上手。下面就让我们实际上手体验一下，让数据流动起来吧！
+
+### 3.1 安装
+
+虽然 PrimiHub 提供了 Docker 、可执行文件、本地编译的安装方式，但是如果你只是想在本地体验一下，我强烈推荐 Docker 一键安装，因为真的是太 easy 了 ～
+
+```Python
+# 第一步：下载
+git clone https://github.com/primihub/primihub.git
+# 第二步：进入目录
+cd primihub
+# 第三步：启动
+docker-compose up -d
+```
+
+### 3.2 发起任务
+
+PrimiHub 将复杂的隐私计算技术封装成了一个个任务，只需要修改配置文件，然后执行命令发起任务即可。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173118353-885693980.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173118353-885693980.png)
+
+PrimiHub 目前支持联合统计、隐私求交、匿踪查询、联邦学习等功能。
+
+- **联合统计**：多个参与方在不暴露私有数据的情况下，共同完成均值(AVG)、求和(SUM)、最大值(MAX)、最小值(MIN) 等计算
+
+- **隐私求交**：在不暴露参与方私有数据的情况下，实现两个或多个参与方之间的数据交集计算。
+
+- **匿踪查询**：保证用户向数据源方提交查询请求时，在数据源方不知道用户查询条件和结果的前提下完成查询。
+
+- **联邦学习**：一种分布式模型训练技术，在数据不动、模型出域的前提下完成全局模型的训练。
+
+下面是通过命令行发起一个「隐私求交」任务的全过程，`task_config_file` 参数指定配置文件。
+
+```Python
+# 1. 进入容器
+docker exec -it primihub-node0 bash
+# 2. 发起隐私求交任务
+./primihub-cli --task_config_file="example/psi_ecdh_task_conf.json"
+I20230616 13:40:10.683375    28 cli.cc:524] all node has finished
+I20230616 13:40:10.683745    28 cli.cc:598] SubmitTask time cost(ms): 1419
+# 3. 查看结果
+cat data/result/psi_result.csv
+"intersection_row"
+X3
+...
+```
+
+### 3.3 更多配置示例
+
+为了方便用户上手，PrimiHub 在 `example` 目录下，提供了 50 多种隐私计算任务的配置文件，可作为模板快速配置自己的数据源发起任务。
+
+|文件|任务|
+|-|-|
+|[mpc_statistics_sum_task_conf.json](https://github.com/primihub/primihub/blob/develop/example/mpc_statistics_sum_task_conf.json)|联合统计三方求和(SUM)任务|
+|[psi_ecdh_task_conf.json](https://github.com/primihub/primihub/blob/develop/example/psi_ecdh_task_conf.json)|隐私求交求两个集合的交集|
+|[keyword_pir_task_conf.json](https://github.com/primihub/primihub/blob/develop/example/keyword_pir_task_conf.json)|匿踪查询|
+|[hfl_plaintext.json](https://github.com/primihub/primihub/blob/develop/example/FL/linear_regression/hfl_plaintext.json)|线性回归横向联邦明文模式训练|
+|[hfl_paillier.json](https://github.com/primihub/primihub/blob/develop/example/FL/linear_regression/hfl_paillier.json)|线性回归横向联邦同态模式训练|
+|......|[更多配置示例](https://github.com/primihub/primihub/tree/develop/example)|
+
+## 四、应用案例
+
+这里我们将通过在 PrimiHub 管理平台模拟演示一个匿踪查询（隐匿查询）的应用案例：检察院要向公安机关查询张三（身份证号）是否有涉毒记录，但是公安机关不想把全量数据提供给检察院查询，检察院也不想暴露他们当前正在侦查的对象。
+
+上面的场景，双方可以通过 PrimiHub 的**隐匿查询功能**来满足双方需求，实现公安机关看不到检察院的查询，检察院也不用拿到公安机关的全量数据，下面开始操作。
+
+### 4.1 注册并登陆
+
+匿踪查询需要两方以上进行协同，所以需要选择「节点 1：模拟检察院」和「节点 2：模拟公安机关」进行注册。
+
+> 节点 1：[https://node1.primihub.com/#/register](https://node1.primihub.com/#/register)
+
+节点 2：[https://node2.primihub.com/#/register](https://node2.primihub.com/#/register)
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173134375-447872231.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173134375-447872231.png)
+
+注册完成后打开两个网页分别登陆，刚模拟注册的检察院和公安机关的账号。
+
+### 4.2 匿踪查询
+
+#### 4.2.1 准备工作
+
+本地准备好待查询的数据如下表，以及查询条件身份证号：110221xxxxx
+
+|姓名|身份证号|籍贯|出生日期|涉赌时间|
+|-|-|-|-|-|
+|张三|110221xxxxx|北京市|...|...|
+|李四|1102211xxxx|北京市|...|...|
+|王二|11022119xxx|北京市|...|...|
+
+#### 4.2.2 上传数据资源
+
+打开「节点 2 」网页（公安机关账号）在「我的资源」点击「添加资源」按钮，将上面表格作为数据资源上传（实际场景中可通过配置数据库进行查询），最后点击保存。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173142667-532651808.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173142667-532651808.png)
+
+#### 4.2.3 新建匿踪查询任务
+
+打开「节点 1 」网页（检查院）在「隐匿查询」发起一次查询任务，在「选择查询资源」处选择上一步模拟公安机关上传的数据资源，最后点击「查询」按钮。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173149146-1332073375.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173149146-1332073375.png)
+
+#### 4.2.4 查看结果
+
+在「节点 1 」网页（检查院）的「隐匿查询」下可以查看上一步创建的「匿踪查询」任务状态，任务运行结束后，点击「导出结果」即可下载结果文件，查看匿踪查询返回的记录。
+
+![https://img2023.cnblogs.com/blog/759200/202309/759200-20230912173158702-715125436.png](7%20信安/标准/[开源+免费]+一款释放数据价值的项目，开源隐私计算平台+cdc79c72-d449-49ec-b9e7-cea4a9a1654c/759200-20230912173158702-715125436.png)
+
+至此，我们就用 PrimiHub 管理平台完成了一次完整的「匿踪查询」任务。模拟了检察院在公安机关提供的涉赌记录数据中，查询目标对象（ 110221xxxxx ）的涉赌信息。**在查询过程中，检察院仅获得查询对象的信息，公安机关也看不到检察院的查询记录，保证了检察院的办案独立性**。
+
+## 五、最后
+
+PrimiHub 是由原语科技开源的隐私计算平台，具有开箱即用、功能丰富、容易上手、灵活配置等特点。
+
+- **开箱即用**：拥有 [Web 界面](https://github.com/primihub/primihub-platform)、[命令行](https://docs.primihub.com/docs/category/%E5%88%9B%E5%BB%BA%E4%BB%BB%E5%8A%A1) 和 [Python SDK](https://docs.primihub.com/docs/category/python-sdk-client) 多种使用方式
+
+- **功能丰富**：支持匿踪查询、隐私求交、联合统计、联合建模、数据资源管理等功能
+
+- **灵活配置**：支持自定义扩展语法、语义、安全协议等
+
+- **自主研发**：多方安全计算、联邦学习、同态加密、可信计算等隐私计算技术
+
+隐私计算作为前沿技术，其开发难度可想而知，开源不易如果体验后觉得 PrimiHub 还不错，就点一个 Star✨ 吧！
+
+> GitHub 地址：[https://github.com/primihub/primihub](https://github.com/primihub/primihub)
+
+在国内外科技巨头纷纷布局隐私计算产业的当下，**花些时间学习一下「隐私计算」属实是波只赚不亏的技术投资**。虽然目前隐私计算受限于性能等因素还远没到普及的程度，但从各国对于隐私保护的重视程度，隐私数据安全合规的使用和流动注定是未来的趋势。相信待时机成熟之时，隐私计算会和现在的大模型一样，迎来属于自己的时代。
+
@@ -0,0 +1,14 @@
+目前透给公网的服务只有一台签名验签服务器。
+
+也有收到协同平台和密码平台透到公网的需求。主要是考虑到以下原因都没有做。
+
+1. 公司网络安全原因，网管不再开放端口，需要施总审批。
+
+2. 缺少应用防火墙，容易被攻击。
+
+3. 网络上行带宽较窄，页面载入缓慢，体验不佳。
+
+4. UKey 模式登录，客户手上没有 UKey 也用不了。
+
+5. 设备资源不足，无常备演示环境服务器/加密机资源。
+
@@ -0,0 +1,85 @@
+**1．祖冲之序列密码算法（GM/T 0001）**
+
+**GM/T 0001-2012《祖冲之序列密码算法》**
+
+本规范包含3个部分：算法描述、基于祖冲之算法的机密件算法、基于祖冲之算法的完整性算法。
+
+第1部分为算法描述，描述了祖冲之序列密码算法，可用于指导祖冲之算法相关产品的研制、检测和使用。本部分主要包括算法整体结构、线性反馈移位寄存器LFSR、比特重组BR、非线性函数F、密钥装入和算法运行内容，并在附录中给出了算法计算实例。
+
+第2部分为基于祖冲之算法的机密性算法，可适用于3GPP LTE通信中的加密和解密，可用于指导基于祖冲之算法的机密性算法的相关产品的研制、检测和使用。本部分主要包括算法输入与输出和算法工作流程内容，并在附录中给出了算法计算实例。
+
+第3部分为基于祖冲之算法的完整性算法，可适用于3GPP LTE通信中消息的完整性保护，可用于指导基于祖冲之算法的完整性算法的相关产品的研制、检测和使用。本部分主要包括算法输入与输出和算法工作流程内容，并在附录中给了算法计算实例。
+
+**2．SM4分组密码算法(GM/T 0002)**
+
+**GM/T 0002-2012 《SM4分组密码算法》**
+
+本规范规定了SM4分组密码算法（原SMS4）的算法结构和算法描述，并给出了运算示例，适用于密码应用中使用分组密码的需求。SM4密码算法是一个分组算法，分组长度为128比特，密钥长度为128比特。加密算法与密钥扩展算法都采用32轮非线性迭代结构，数据解密和数据加密的算法结构相同，只是轮密钥的使用顺序相反，解密轮密钥是加密轮密钥的逆序。
+
+本规范对轮函数F和算法进行了详细的介绍。轮函数F包括轮函数结构和合成置换T，算法描述包括加密算法、解密算法和密钥扩展算法，并在附录中给出了运算示例。
+
+**3．SM2椭圆曲线公钥密码算法（GM/T 0003）**
+
+**GM/T 0003-2012 《SM2椭圈曲线公钥密码算法》**
+
+本规范包括5个部分：总则、数字签名算法、密钥交换协议、公钥加密算法、参数定义。
+
+第1部分为总则，给出了SM2椭圆曲线公钥密码算法涉及的必要数学基础知识与相关密码技术，以帮助实现其他各部分所规定的密码机制，适用于基域为素域和二元扩域的椭圆曲线公钥密码算法。本部分主要包括域和椭圆曲线、数据类型及其转换、椭圆曲线系统参数及其验证、密钥对的生成、公钥的验证等内容，并在附录中给出了椭圆曲线的背景知识、数论算法、曲线示例和椭圆曲线方程参数的拟随机生成及验证。
+
+第2部分为数字签名算法，规定了SM2椭圆曲线公钥密码算法的数字签名算法，包括数字签名生成算法和验证算法，并给出了数字签名与验证示例及其相应的流程，适用于商用密码应用中的数字签名和验证，可满足多种密码应用中的身份认证和数据完整性、真实性的安全需求。本部分主要包括数字签名算法、数字签名的生成算法及流程、数字签名的验证算法及流程等内容，并在附录中给出了数字签名与验证的示例。
+
+第3部分为密钥交换协议，规定了SM2椭圆曲线公钥密码算法的密钥交换协议，并给出了密钥交换与验证示例及其相应的流程。适用于商用密码应用中的密钥交换，可满足通信双方经过两次或三次信息传递过程，计算获取一个由双方共同决定的共享密钥（会话密钥）。本部分主要包括参数与辅助参数、密钥交换协议及流程内容，并在附录中给出了密钥交换及验证示例。
+
+第4部分为公钥加密算法，规定了SM2椭网曲线公钥密码算法的公钥加密算法，并给出了消息加解密示例和相应的流程。适用于国家商用密码应用中的消息加解密，消息发送者可以利用接收者的公钥对消息进行加密，接收者用对应的私钥进行解密，获取消息。本部分主要包括算法参数与辅助函数、加密算法及流程、解密算法及流程等内容并在附录中给出了消息加解密示例。
+
+第5部分为参数定义，规定了SM2椭圆曲线公钥密码算法的曲线参数，并在附录中给出了数字签名签名验签、密钥交换与验证、消息加解密示例。
+
+**4．SM3密码杂凑算法（GM/T 0004）**
+
+**GM/T 0004-2012 《SM3密码杂凑算法》**
+
+该规范规定了SM3密码杂凑算法的计算方法和计算步骤，并给出了运算示
+
+例，适用于商用密码应用中的数字签名和验证、消息认证码的生成与验证以及随机数的生成，可满足多种密码应用的安全需求。同时，本规范还可为安全产品生产商提供产品和技术的标准定位以及标准化的参考，提高安全产品的可信性与互操作性。
+
+SM3算法可概述为：对长度为n(n<2^64)位的消息m，SM3杂凑算法经过填充和迭代压缩，生成杂凑值，杂凑值长度为256位。本规范从算法概述、迭代演练等方式对SM3算法进行描述，并通过具体示例进行剖析展示。
+
+**5．SM2密码算法使用规范（GM/T 0009）**
+
+**GM/T 0009-2012 《SM2密码算法使用规范》**
+
+本规范定义了 SM2密码算法的使用方法，以及密钥、加密与签名等数据格式，适用于SM2密码算法的使用，以及支持SM2密码算法的设备和系统的研发和检测。
+
+本规范介绍了SM2公钥和私钥的数学本质。SM2私钥是一个大于或等于1且小于n-1的整数（n为SM2算法的阶，其值参见GM/T 0003）．简记为k，长度为256位；SM2公钥是SM2曲线上的一个点，由横坐标和纵坐标两个分量来表示，记为(x，y)，简记为Q，每个分量的长度为256位。
+
+本规范介绍了8位字节串和位串之问的转换，包括位串到8位字节串的转换、8位字节串到位串的转换、整数到8位字节串的转换、8位字节串到整数的转换。
+
+本规范介绍了SM2算法的数据格式，包括密钥数据格式、加密数据格式、签名数据格式、密钥对保护数据格式。
+
+本规范还介绍了预处理和计算过程，包括生成密钥、加密、解密、签名、验签和密钥协商。
+
+**6．SM2密码算法加密签名消息语法规范(GM/T 0010)**
+
+**GM/T 0010-2012 (SM2密码算法加密签名消息语法规范)**
+
+本规范定义了使用SM2密码算法的加密签名消息语法，适用于使用SM2算法进行加密和签名操作时对操作结果的标准化封装。
+
+本规范对6类对象 data，signedData，envelopedData，encryptedData，
+
+keyAgreementInfo和SignedAndEnvelopedData的标识符进行了定义。
+
+
+
+|||
+|-|-|
+|对象标识符OID|对象标识符定义|
+|1.2.156.10197.6.1.4.2|SM2密码算法加密签名消息语法规范|
+|1.2.156.10197.6.1.4.2.1|数据类型data|
+|1.2.156.10197.6.1.4.2.2|签名数据类型signedData|
+|1.2.156.10197.6.1.4.2.3|数字信封数据类型envelopedData|
+|1.2.156.10197.6.1.4.2.4|签名及数字信封数据类型signedAndEnvelopedData|
+|1.2.156.10197.6.1.4.2.5|加密数据类型encryptedData|
+|1.2.156.10197.6.1.4.2.6|密钥协商类型keyAgreementInfo|
+
+1.2.156.10197.1.301 (sm4-cbc)
+1.2.156.10197.1.301.1
@@ -0,0 +1,34 @@
+RFC定义的oid如下：
+
+数据类型data 1 2 840 113549 1 7 1
+
+签名数据类型signedData 1 2 840 113549 1 7 2
+
+数字信封数据类型envelopedData 1 2 840 113549 1 7 3
+
+签名及数字信封数据类型signedAndEnvelopedData 1 2 840 113549 1 7 4
+
+摘要数据类型digestData 1 2 840 113549 1 7 5
+
+加密数据类型encryptedData 1 2 840 113549 1 7 6
+
+
+
+
+
+
+
+国密标准GM/T 0010定义的oid如下：
+
+数据类型data 1.2.156.10197.6.1.4.2.1
+
+签名数据类型signedData 1.2.156.10197.6.1.4.2.2
+
+数字信封数据类型envelopedData 1.2.156.10197.6.1.4.2.3
+
+签名及数字信封数据类型signedAndEnvelopedData 1.2.156.10197.6.1.4.2.4
+
+加密数据类型encryptedData 1.2.156.10197.6.1.4.2.5
+
+密钥协商类型keyAgreementInfo 1.2.156.10197.6.1.4.2.6
+
@@ -0,0 +1,2 @@
+
+
@@ -0,0 +1,212 @@
+[https://blog.csdn.net/m0_50180963/article/details/113061162](https://blog.csdn.net/m0_50180963/article/details/113061162)
+
+HTTPS 常用的密钥交换算法有两种，分别是 RSA 和 ECDHE 算法。
+
+其中，RSA 是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用的。而 ECDHE 算法具有前向安全，所以被广泛使用。
+
+我在上一篇已经介绍了 RSA 握手的过程，今天这一篇就「从理论再到实战抓包」介绍 **ECDHE 算法**。
+
+![475ad007571fec673a9712a7c865849d.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/475ad007571fec673a9712a7c865849d.png)
+
+---
+
+# 离散对数
+
+ECDHE 密钥协商算法是 DH 算法演进过来的，所以我们先从 DH 算法说起。
+
+DH 算法是非对称加密算法， 因此它可以用于密钥交换，该算法的核心数学思想是**离散对数**。
+
+是不是听到这个数学概念就怂了？不怕，这次不会说离散对数推到的过程，只简单提一下它的数学公式。
+
+离散对数是「离散 + 对数」的两个数学概念的组合，所以我们先来复习一遍对数。
+
+要说起对数，必然要说指数，因为它们是互为反函数，指数就是幂运算，对数是指数的逆运算。
+
+举个栗子，如果以 2 作为底数，那么指数和对数运算公式，如下图所示：
+
+![12b51d7318811cd137dfca72ae5923b4.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/12b51d7318811cd137dfca72ae5923b4.png)
+
+那么对于底数为 2 的时候， 32 的对数是 5，64 的对数是 6，计算过程如下：
+
+![0eebc01157e5458afb98b84162f89ee6.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/0eebc01157e5458afb98b84162f89ee6.png)
+
+对数运算的取值是可以连续的，而离散对数的取值是不能连续的，因此也以「离散」得名，
+
+离散对数是在对数运算的基础上加了「模运算」，也就说取余数，对应编程语言的操作符是「%」，也可以用 mod 表示。离散对数的概念如下图：
+
+![2cd0c0fbd0a759611b4abad5fe414922.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/2cd0c0fbd0a759611b4abad5fe414922.png)
+
+上图的，底数 a 和模数 p 是离散对数的公共参数，也就说是公开的，b 是真数，i 是对数。知道了对数，就可以用上面的公式计算出真数。但反过来，知道真数却很难推算出对数。
+
+**特别是当模数 p 是一个很大的质数，即使知道底数 a 和真数 b ，在现有的计算机的计算水平是几乎无法算出离散对数的，这就是 DH 算法的数学基础。**
+
+---
+
+# DH 算法
+
+认识了离散对数，我们来看看 DH 算法是如何密钥交换的。
+
+现假设小红和小明约定使用 DH 算法来交换密钥，那么基于离散对数，小红和小明需要先确定模数和底数作为算法的参数，这两个参数是公开的，用 P 和 G 来代称。
+
+然后小红和小明各自生成一个随机整数作为**私钥**，双方的[私钥](https://so.csdn.net/so/search?q=%E7%A7%81%E9%92%A5&spm=1001.2101.3001.7020)要各自严格保管，不能泄漏，小红的私钥用 a 代称，小明的私钥用 b 代称。
+
+现在小红和小明双方都有了 P 和 G 以及各自的私钥，于是就可以计算出**公钥**：
+
+- 小红的公钥记作 A，A = G ^ a ( mod P )；
+
+- 小明的公钥记作 B，B = G ^ b ( mod P )；
+
+A 和 B 也是公开的，因为根据离散对数的原理，从真数（A 和 B）反向计算对数 a 和 b 是非常困难的，至少在现有计算机的计算能力是无法破解的，如果量子计算机出来了，那就有可能被破解，当然如果量子计算机真的出来了，那么密钥协商算法就要做大的升级了。
+
+双方交换各自 DH 公钥后，小红手上共有 5 个数：P、G、a、A、B，小明手上也同样共有 5 个数：P、G、b、B、A。
+
+然后小红执行运算： B ^ a ( mod P )，其结果为 K，因为离散对数的幂运算有交换律，所以小明执行运算： A ^ b ( mod P )，得到的结果也是 K。
+
+![b5caa905be6878ae9583f5a1e1d4f3e7.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/b5caa905be6878ae9583f5a1e1d4f3e7.png)
+
+这个 K 就是小红和小明之间用的**对称加密密钥**，可以作为会话密钥使用。
+
+可以看到，整个密钥协商过程中，小红和小明公开了 4 个信息：P、G、A、B，其中 P、G 是算法的参数，A 和 B 是公钥，而 a、b 是双方各自保管的私钥，黑客无法获取这 2 个私钥，因此黑客只能从公开的 P、G、A、B 入手，计算出离散对数（私钥）。
+
+前面也多次强调， 根据离散对数的原理，如果 P 是一个大数，在现有的计算机的计算能力是很难破解出 私钥 a、b 的，破解不出私钥，也就无法计算出会话密钥，因此 DH 密钥交换是安全的。
+
+---
+
+# DHE 算法
+
+根据私钥生成的方式，DH 算法分为两种实现：
+
+- static DH 算法，这个是已经被废弃了；
+
+- DHE 算法，现在常用的；
+
+static DH 算法里有一方的私钥是静态的，也就说每次密钥协商的时候有一方的私钥都是一样的，一般是服务器方固定，即 a 不变，客户端的私钥则是随机生成的。
+
+于是，DH 交换密钥时就只有客户端的公钥是变化，而服务端公钥是不变的，那么随着时间延长，黑客就会截获海量的密钥协商过程的数据，因为密钥协商的过程有些数据是公开的，黑客就可以依据这些数据暴力破解出服务器的私钥，然后就可以计算出会话密钥了，于是之前截获的加密数据会被破解，所以 **static DH 算法不具备前向安全性**。
+
+既然固定一方的私钥有被破解的风险，那么干脆就让双方的私钥在每次密钥交换通信时，都是随机生成的、临时的，这个方式也就是 DHE 算法，E 全称是 ephemeral（临时性的）。
+
+所以，即使有个牛逼的黑客破解了某一次通信过程的私钥，其他通信过程的私钥仍然是安全的，因为**每个通信过程的私钥都是没有任何关系的，都是独立的，这样就保证了「前向安全」**。
+
+---
+
+# ECDHE 算法
+
+DHE 算法由于计算性能不佳，因为需要做大量的乘法，为了提升 DHE 算法的性能，所以就出现了现在广泛用于密钥交换算法 —— **ECDHE 算法**。
+
+ECDHE 算法是在 DHE 算法的基础上利用了 ECC 椭圆曲线特性，可以用更少的计算量计算出公钥，以及最终的会话密钥。
+
+小红和小明使用 ECDHE 密钥交换算法的过程：
+
+- 双方事先确定好使用哪种椭圆曲线，和曲线上的基点 G，这两个参数都是公开的；
+
+- 双方各自随机生成一个随机数作为**私钥d**，并与基点 G相乘得到**公钥Q**（Q = dG），此时小红的公私钥为 Q1 和 d1，小明的公私钥为 Q2 和 d2；
+
+- 双方交换各自的公钥，最后小红计算点（x1，y1） = d1Q2，小明计算点（x2，y2） = d2Q1，由于椭圆曲线上是可以满足乘法交换和结合律，所以 d1Q2 = d1d2G = d2d1G = d2Q1 ，因此**双方的 x 坐标是一样的，所以它是共享密钥，也就是会话密钥**。
+
+这个过程中，双方的私钥都是随机、临时生成的，都是不公开的，即使根据公开的信息（椭圆曲线、公钥、基点 G）也是很难计算出椭圆曲线上的离散对数（私钥）。
+
+---
+
+# ECDHE 握手过程
+
+知道了 ECDHE 算法基本原理后，我们就结合实际的情况来看看。
+
+我用 Wireshark 工具抓了用 ECDHE 密钥协商算法的 TSL 握手过程，可以看到是四次握手：
+
+![1388d63cad1194b30265d7d580c8bcbe.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/1388d63cad1194b30265d7d580c8bcbe.png)
+
+细心的小伙伴应该发现了，**使用了 ECDHE，在 TLS 第四次握手前，客户端就已经发送了加密的 HTTP 数据**，而对于 RSA 握手过程，必须要完成 TLS 四次握手，才能传输应用数据。
+
+所以，**ECDHE 相比 RSA 握手过程省去了一个消息往返的时间**，这个有点「抢跑」的意思，它被称为是「*TLS False Start*」，跟「*TCP Fast Open*」有点像，都是在还没连接完全建立前，就发送了应用数据，这样便提高了传输的效率。
+
+接下来，分析每一个 ECDHE 握手过程。
+
+# TLS 第一次握手
+
+客户端首先会发一个「**Client Hello**」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的**随机数（*Client Random*）**。
+
+![bb4702545feaa89e55d8cfc6b92f6257.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/bb4702545feaa89e55d8cfc6b92f6257.png)
+
+# TLS 第二次握手
+
+服务端收到客户端的「打招呼」，同样也要回礼，会返回「**Server Hello**」消息，消息面有服务器确认的 TLS 版本号，也给出了一个**随机数（*Server Random*）**，然后从客户端的密码套件列表选择了一个合适的密码套件。
+
+![a025211621416e7ad174fd54bb0fa3ca.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/a025211621416e7ad174fd54bb0fa3ca.png)
+
+不过，这次选择的密码套件就和 RSA 不一样了，我们来分析一下这次的密码套件的意思。
+
+「 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
+
+- 密钥协商算法使用 ECDHE；
+
+- 签名算法使用 RSA；
+
+- 握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM；
+
+- 摘要算法使用 SHA384；
+
+接着，服务端为了证明自己的身份，发送「**Certificate**」消息，会把证书也发给客户端。
+
+![d1537dfb240125c2cf088cda12cb7f16.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/d1537dfb240125c2cf088cda12cb7f16.png)
+
+这一步就和 RSA 握手过程有很大到区别了，因为服务端选择了 ECDHE 密钥协商算法，所以会在发送完证书后，发送「**Server Key Exchange**」消息。
+
+![ac636d19c58867ecbfe341739f2212de.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/ac636d19c58867ecbfe341739f2212de.png)
+
+这个过程服务器做了三件事：
+
+- 选择了**名为 named_curve 的椭圆曲线**，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；
+
+- 生成随机数作为服务端椭圆曲线的私钥，保留到本地；
+
+- 根据基点 G 和私钥计算出**服务端的椭圆曲线公钥**，这个会公开给客户端。
+
+为了保证这个椭圆曲线的公钥不被第三方篡改，服务端会用 RSA 签名算法给服务端的椭圆曲线公钥做个签名。
+
+随后，就是「**Server Hello Done**」消息，服务端跟客户端表明：“这些就是我提供的信息，打招呼完毕”。
+
+![f4be9207366b4c5260d2fccd4c749cf3.png](f4be9207366b4c5260d2fccd4c749cf3.png)
+
+至此，TLS 两次握手就已经完成了，目前客户端和服务端通过明文共享了这几个信息：**Client Random、Server Random 、使用的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥**，这几个信息很重要，是后续生成会话密钥的材料。
+
+# TLS 第三次握手
+
+客户端收到了服务端的证书后，自然要校验证书是否合法，如果证书合法，那么服务端到身份就是没问题的。校验证书到过程，会走证书链逐级验证，确认证书的真实性，再用证书的公钥验证签名，这样就能确认服务端的身份了，确认无误后，就可以继续往下走。
+
+客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成**客户端的椭圆曲线公钥**，然后用「**Client Key Exchange**」消息发给服务端。
+
+![c1bd87df595152b55b29e12befb6d689.png](7%20信安/标准/图解+ECDHE+密钥交换算法+118cb81b-7cb1-471e-9fc2-ccfd0897265d/c1bd87df595152b55b29e12befb6d689.png)
+
+至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都就计算出点（x，y），其中 x 坐标值双方都是一样的，前面说 ECDHE 算法时候，说 x 是会话密钥，**但实际应用中，x 还不是最终的会话密钥**。
+
+还记得 TLS 握手阶段，客户端和服务端都会生成了一个随机数传递给对方吗？
+
+**最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的**。
+
+之所以这么麻烦，是因为 TLS 设计者不信任客户端或服务器「伪随机数」的可靠性，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么「随机」的程度就非常高了，足够让黑客计算出最终的会话密钥，安全性更高。
+
+算好会话密钥后，客户端会发一个「**Change Cipher Spec**」消息，告诉服务端后续改用对称算法加密通信。
+
+![380f119a8b73e5dbbed2c477eacec61b.png](380f119a8b73e5dbbed2c477eacec61b.png)
+
+接着，客户端会发「**Encrypted Handshake Message**」消息，把之前发送的数据做一个摘要，再用对称密钥加密一下，让服务端做个验证，验证下本次生成的对称密钥是否可以正常使用。
+
+![7e28bf39c00923ed3d5fe6f4a67bc796.png](7e28bf39c00923ed3d5fe6f4a67bc796.png)
+
+# TLS 第四次握手
+
+最后，服务端也会有一个同样的操作，发「**Change Cipher Spec**」和「**Encrypted Handshake Message**」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。
+
+---
+
+# 总结
+
+RSA 和 ECDHE 握手过程的区别：
+
+- RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
+
+- 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；
+
+- 使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息；
+
@@ -0,0 +1,24 @@
+*AES*-*GCM* 是基于 AES-CTR
+
+[https://zhuanlan.zhihu.com/p/376692295](https://zhuanlan.zhihu.com/p/376692295)
+
+
+
+
+
+高可用计算公式
+
+可用性
+
+故障率
+
+
+
+项目遇阻
+
+
+
+
+
+
+
@@ -0,0 +1,2 @@
+
+
@@ -0,0 +1,4 @@
+GCM 是在 CTR 模式的基础上，增加了认证操作的分组模式。
+
+
+
@@ -0,0 +1,4 @@
+- 缺乏专业人员。人力缺少导致设计、开发、文档工作量压缩，以及质量下降。改进措施：安排对应的支持岗位，培训专业支持人员。
+
+- 测试不足。缺少人力和环境导致测试不足，现场调整耗时。改进措施：搭建对应的测试环境，以及自动化测试工具，提高人效。
+
@@ -0,0 +1,22 @@
+风险应对办法：规避、减轻、转嫁、接受
+
+
+
+测试方面需要 ： 功能测试、压力测试、安全测试和场景对比测试
+
+
+
+安全测试包括：身份认证安全、口令安全、访问权限安全、会话管理安全、通信安全、业务逻辑安全、输入数据安全、存储数据安全、提示信息安全、日志数据安全、算法安全、安全审计、配置安全、拒绝服务、源代码数据安全、架构安全、运行环境安全、安全卸载安全、组件安全、权限安全、第三方库安全（若涉及）等。
+
+
+
+场景对比测试：对比改造前后的使用体验、延迟变化，分析和评估对用户应用操作和实际体验的影响。
+
+
+
+上线方案需要有这些要素：测试方案、上线策略、部署方案、上线实施和回退方案
+
+
+
+
+
				`@@ -0,0 +1,4 @@`
				`GCM 是在 CTR 模式的基础上，增加了认证操作的分组模式。`