网络认证技术2024-复习

网络认证技术2024-复习

​#国科大#​

​#复习#​

​#网络认证技术#​

过，肯定够用？

不过下一届开始改革，应该没这么多了。。。

‍

‍

一 导言

• 鉴别：

  证明一个实体是所声明的实体

• 区分口令和密码

  • 口令：Password，一串字符，人可记住的
  • 密码：在学术场合，密码是Cryptography，通常狭义地指加密算法；广义的Cryptography包括更多类型的算法

• 基于口令的鉴别：

  口令是最常用的身份认证方式，也最好理解。在“口令”帮助下，确认它是谁的过程

• 口令与密码的关系:

  • 密码算法可以在没有口令的情况下使用

  • 口令，基本上不能在没有密码算法的情况下、安全地使用。除非是极其简单的系统中

‍

二 密码学知识

sm2 非对称 基于椭圆曲线

sm3 hash

sm4 对称

‍

密码分析攻击

• 唯密文攻击：有一个或更多个用同一个密钥加密的密文
• 已知明文攻击：除待解的密文外，有一些明文和用同一个密钥加密这些明文对应的密文
• 选择明文攻击：可得到所需要的任何明文所对应的密文，这些密文和待解的密文是用同一个密钥加密的
• 选择密文攻击：可得到所需要的任何密文所对应的明文，解密这些密文所使用的密钥和解密待解的密文所需要的密钥是一样的

‍

对称密码

加密和解密的密钥Key是一样的，或者说，一个密钥能（很容易）从另一个密钥中导出

算法例子：

• 古典：

  • 代换技术：移位密码、字母代换密码
  • 置换技术

• 现代：

  • DES算法，三重DES

  • RC2, RC4, RC5, RC6

  • IDEA

  • AES

  • 国产密码算法

    • 祖冲之（ZUC）算法
    • SM4算法

‍

SM4分组密码算法

分组长度为128比特，密钥长度为128比特

‍

雪崩效应

雪崩效应：明文或密钥的一点小的变动，使密文发生一个大的变化。

Des 具有很好的雪崩效应

‍

重点：对称密码的优缺点

• 优点：

  • 运行占用空间小，加/解密速度快

• 缺点：

  • 需要事先共享密钥：通过安全通道共享密钥；N方通信，共需N×(N－1) 个密钥：数量太大
  • 密钥分配中心（Key Distribution Center，KDC） ：成为安全和性能的瓶颈
  • 无法完成数字签名：验证者，无法生成数字签名

‍

快问：

两个不同的明文用同一个密钥加密能否得到相同的密文？

现代加密算法设计时考虑了雪崩效应，即明文中的微小变化会导致密文发生显著变化，从而确保不同的明文加密后几乎不可能产生相同的密文。

在理想的安全加密算法（如AES、DES等）下，两个不同的明文使用同一个密钥加密通常不会得到相同的密文。

• 如果加密算法设计有缺陷，可能会出现两个不同的明文用同一个密钥加密得到相同密文的情况。例如，一些早期的简单加密算法或者自制的、未经充分验证的加密算法，可能存在某种规律，使得不同的明文在加密后出现相同的结果。
• 另外，如果加密过程中某些参数设置不合理，也可能导致这种情况。比如在使用分组密码的某些模式（如密码分组链接模式CBC）时，如果初始化向量（IV）没有正确设置，而是使用了固定的值，那么对于某些特定的明文组合，可能会出现相同的密文。不过这是因为使用方式错误，而不是加密算法本身的问题。正确使用CBC模式要求每次加密都使用不同的、随机的初始化向量，以保证加密的安全性和密文的唯一性。

‍

‍

非对称密码

• 非对称密码算法是基于数学函数，而不是基于代换和置换

• 非对称密码算法使用2个独立的密钥，对称密码使用1个密钥

• 加密密钥和解密密钥相关，但完全不同

  • 仅仅知道密码算法和加密密钥/Public Key，要确定解密密钥/Private Key在计算上是不可行的。

‍

解决对称密码学中的两个难题

• 密钥分配
• 数字签名

‍

• 公钥加密，私钥解密
• 私钥加签，公钥验签

‍

‍

避免几种误解！！！

• 非对称密码学比对称密码学更安全？错误

  • 加密方法的安全性依赖于密钥的长度和破译密文所需的计算量

• 对称密码学已过时？错误

  • 非对称密码学通常所需计算量较大，常用于密钥管理与签名

‍

名词：公钥密码Public Key Cryptography

• 也称为，非对称密码 Asymmetric Cryptography

‍

名词：公钥Public Key

• 公开的密钥，记为 PubK

• 加密密钥 Encryption Key

‍

名词：秘密保存的密钥，记为PriK

• 解密密钥 Decryption Key

• 签名密钥 Sign Key

‍

‍

重点：优缺点

• 不需要事先“秘密地”共享密钥

• 和多个人通信，可用相同的公开密钥

• 可用于数字签名

• 因为私钥和公钥是不一样的，验证者并不能伪造签名。

• 计算效率低

• 密钥长度较长

• 实现复杂

• 非对称算法的速度远远慢于对称算法

• RSA算法的加密比解密快，签名验证比签名快

  • 这是因为e的选择，导致了d远远大于e；并不是RSA算法本身的特点

• ECC相对RSA算法，使用较短的密钥，达到相同的安全程度，计算量远小于RSA算法

• 不等于“ECC算法比RSA算法安全”（错误的说法）

• 中国发布SM2公钥算法，基于椭圆曲线

‍

几种非对称密码算法

• RSA算法
• ElGamal
• ECC算法：椭圆曲线加密
• 中国发布SM2公钥算法，基于椭圆曲线

‍

‍

杂凑密码 HASH

‍

Hash函数

• 将任意长度的消息压缩到固定长度的消息摘要（Message Digest）的函数

• 散列函数，也称为消息摘要算法、杂凑算法

• Hash函数表示为h=H(M)

• 消息摘要（Message Digest）: Hash函数的输出

• 用途

  • 数字签名
  • 消息鉴别码（MAC）的构造，也就是HMAC

‍

‍

几种常见的Hash算法

• MD4、MD5
  输出16字节
• SHA-1，Standard Hash Algorithm
  输出20字节
• SHA-256、SHA-384、SHA-512
  输出摘要长度分别为256、384、512bits
• SHA3
  2015年由美国NIST发布成为FIPS标准
• 中国自主标准SM3算法
  输出32字节

‍

分组密码的工作模式

中国国家标准： GB/T 17964-2008

• ECB、CBC、CFB、OFB、CTR、BC、OFBNLF 7个
• ECB (Electronic Codebook, 电子密码本模式)
  将明文分成固定大小的块，每个块独立加密。简单但安全性较低，容易暴露模式。
• CBC (Cipher Block Chaining, 密码分组链接模式)
  每个明文块与前一个密文块进行异或操作后再加密，提高了安全性。
• CFB (Cipher Feedback, 密码反馈模式)
  将分组密码转换为流密码，适用于实时数据加密。
• OFB (Output Feedback, 输出反馈模式)
  类似于CFB，但更适用于需要抗噪声的环境。
• CTR (Counter, 计数器模式)
  使用计数器生成密钥流，与明文异或得到密文，支持并行加密。
• BC (Block Chaining, 分组链接模式)
  一种较少使用的模式，通常指类似CBC的链接方式。
• OFBNLF (Output Feedback with Non-linear Function, 带非线性函数的输出反馈模式)
  对OFB的改进，增加了非线性函数以增强安全性。

‍

国际标准： ISO/IEC 10116:2017 Information technology

• ECB、CBC、CFB、OFB、CTR 5个
• ECB
  与GB/T 17964-2008中的ECB相同。
• CBC
  与GB/T 17964-2008中的CBC相同。
• CFB
  与GB/T 17964-2008中的CFB相同。
• OFB
  与GB/T 17964-2008中的OFB相同。
• CTR
  与GB/T 17964-2008中的CTR相同。

‍

‍

三 口令鉴别

常见的攻击方式

• 被动攻击 Passive Attack

  • 被动攻击是指攻击者无法直接与加密系统中的任何一方进行交互，而是通过监听或观察通信数据来获取信息。攻击者的目标是通过分析这些数据来破解系统或获取敏感信息。

• 主动攻击（Active Attack）

  • 主动攻击是指攻击者能够直接干预通信过程，通过篡改、伪造、删除或重定向消息来破坏系统的安全性或获取非法利益。

• 暴力破解攻击（Brute-force Attack）、

  • 暴力破解攻击是一种通过穷举所有可能的组合来尝试破解密码的攻击方式。攻击者会系统地尝试每一种可能的字符组合，直到找到正确的密码。

• 字典攻击（Dictionary Attack）

  • 字典攻击是一种通过尝试常见密码或字典中的单词来破解密码的攻击方式。与暴力破解不同，字典攻击只尝试那些被认为最有可能成功的组合。
  • 常见设备弱口令
  • 系统/设备 默认口令

• 重放攻击/回放攻击 Replay attack/Playback attack

  • 有效的数据传输被恶意或欺诈性地重复或延迟。

• 中间人攻击 Man-in-the-middle attack

  • 攻击者秘密中继并可能改变双方之间的通信，双方认为他们正在直接通信。

• 并行会话攻击 Parallel Session Attack

  • 同时执行两个或多个协议会话，来自一个的消息用于在另一个中形成消息。

‍

可行的解决方案

• 防御针对口令本身的攻击

  • 增加口令复杂度，同时兼顾易用性

    • 如，图片口令、声音口令
      工程实现的防御方式(服务器端)
    • 增加口令尝试次数的限制，如输入错误X次锁定账号

• 防御针对协议过程中传输内容的攻击

  • 可证明安全性的安全协议设计与分析
  • One-time协议

• 防御针对服务器端存储的攻击

  • Verifier-based口令鉴别协议
  • 设计存储在服务器端存储的口令、用户名相关信息的形式：加密、Hash等

LGSN：第一个被提出的基于口令的鉴别协议方案

​​

‍

‍

四 基于密码技术的鉴别

ISO/IEC 9798-2协议

1. 标准编号：ISO/IEC 9798-2:2019，这是信息安全技术领域中关于实体认证的第二部分，专注于使用认证加密的机制。
2. 历史版本：之前的版本使用的是对称加密算法。
3. 协议数量：共有六个使用对称加密算法的协议。
4. 单向认证：其中四个协议仅提供实体认证，即单向认证（Unilateral authentication） 。
5. 双向认证：另外两个协议旨在提供密钥建立以及实体认证，即双向认证（Mutual authentication） 。
6. 协议分析：在介绍这些协议时，首先会省略一些可选的文本字段。
7. 涉及双方的认证协议：这些协议涉及两个参与方的认证过程。

‍

‍

‍

UNI.TS 单向认证协议

​​

令牌生成：令牌（Token_AB）是通过加密算法生成的，公式为：

$$
Token_{AB}= e_{K_{AB}}(SID_{UNI.TS}|| TN_{A}|| II_{B})
$$

其中：

实体A是签名方

实体B是验证方

• $e_{K_{AB}}$ 表示使用共享密钥 $K_{AB}$ 进行加密。

• $SID_{UNI.TS}$ 是协议的标识符。

  • 用于标识所使用的认证协议。这有助于接收方识别和正确处理认证令牌。

• $TN_{A}$ 是一个时间变化的参数，可以是时间戳或序列号，用于确保令牌的时效性。

  • 提供动态元素以防止重放攻击。通过使用时间戳或序列号，每次生成的令牌都是唯一的，即使在相同的密钥下。

• $I_{B}$ 是实体B的标识符，这个字段是可选的。

  • 如果包含，可以提供额外的认证信息，确保令牌是为特定的接收方生成的。

‍

‍

MUT.TS 双向认证协议

令牌生成：

• Token_AB：由实体A生成并发送给实体B，公式为 $Token_{AB}= e_{K_{AB}}(SID_{MUT.TS}|| TN_{A}|| I_{B})$。
• Token_BA：由实体B生成并发送回实体A，公式为 $Token_{BA}= e_{K_{AB}}(SID_{MUT.TS}|| TN_{A}|| TN_{B}|| I_{A})$。

‍

参数解释：

• $SID_{MUT.TS}$：协议标识符，用于识别所使用的认证协议。
• $TN_{A}$ 和 $TN_{B}$：时间变化参数，可以是时间戳或序列号，用于确保令牌的时效性和防止重放攻击。
• $I_{A}$ 和 $I_{B}$：实体A和实体B的标识符，这些字段是可选的，用于防止令牌被对手重用。

‍

为什么Token_BA的生成还要带上TN_A？

1. 绑定两个消息：TN_A在Token_BA中的存在可以将两个消息（Token_AB和Token_BA）绑定在一起，作为双向认证的一部分。这样，实体A可以通过验证Token_BA中的TN_A是否与之前发送的Token_AB中的TN_A相匹配，来确认Token_BA是由实体B生成并发送的。
2. 防止重用：TN_A的包含可以防止Token_AB被对手重用。如果攻击者试图冒充实体B向实体A发送Token_AB，Token_BA中的TN_A可以防止这种重用，因为攻击者无法生成一个包含正确TN_A的Token_BA。

‍

ISO/IEC 9798-2: UNI.CR

​​

Rb 是一个随机数

​​

‍

Three Pass ISO/IEC 9798-2: MUT.CR

1. 协议名称：MUT.CR，代表Three-pass mutual authentication（三步通过双向认证）。

2. 认证过程：在这个协议中，实体A和实体B通过三个步骤来相互认证对方的身份。

3. 令牌生成：

   • Token_AB：由实体A生成并发送给实体B，公式为 $Token_{AB}= e_{K_{AB}}(SID_{MUT.CR}|| R_{A}|| R_{B}|| I_{B})$。
   • Token_BA：由实体B生成并发送回实体A，公式为 $Token_{BA}= e_{K_{AB}}(SID_{MUT.CR}|| R_{A}|| I_{A})$。

4. 参数解释：

   • $SID_{MUT.CR}$​：协议标识符，用于识别所使用的认证协议。
   • $R_A$ 和 $R_B$​：分别是实体A和实体B发送的随机数，用于确保令牌的唯一性，防止重放攻击。
   • $II_A$ 和 $II_B$​：实体A和实体B的标识符，这些字段是可选的。

5. 认证流程：

   • 实体B发送 $R_B$ 给实体A。
   • 实体A接收 $R_B$ 并生成 $Token_{AB}$ 发送回实体B。
   • 实体B接收 $Token_{AB}$ 并验证，然后生成 $Token_{BA}$ 发送回实体A。
   • 实体A接收 $Token_{BA}$ 并验证。

​​

‍

区分单向/双向认证的概念

单向认证：

• 在这种认证机制中，只有一个实体需要证明其身份给另一个实体。
• 通常用于客户端-服务器模型，其中客户端需要向服务器证明其身份，但服务器不需要向客户端证明其身份。
• 单向认证可以是一次性通过（如UNI.TS协议）或两步通过（如UNI.CR协议），具体取决于协议的设计。
• 单向认证的目的是确保一个方向上的安全通信，即确保客户端或请求方的身份是真实的。

双向认证：

• 在双向认证中，通信的两个实体都需要向对方证明其身份。
• 这种机制提供了更高级别的安全性，因为它确保了双方都不是假冒的。
• 双向认证可以是两步通过（如MUT.TS协议）或三步通过（如MUT.CR协议），具体取决于协议的设计。
• 双向认证的目的是确保两个方向上的安全通信，即确保通信双方的身份都是真实的。

‍

区分one pass/two pass/three pass 的概念

1. One-pass（单次通过）：

   • 在单次通过认证中，只需要一次消息交换来完成认证过程。

2. Two-pass（两步通过）：

   • 两步通过认证涉及两次消息交换来完成认证。

3. Three-pass（三步通过）：

   • 三步通过认证涉及三次消息交换来完成认证。

‍

‍

后面太多了，没看

‍

‍

五 PKI的基本结构

CA - Certification Authority

1. 签发证书（Certificate）：

   • 证书由认证机构（CA）签发，包含订户的公钥及其他相关信息。

2. 数字签名：

   • CA使用自己的私钥对证书进行数字签名，确保证书的真实性和完整性。

3. 发布订户（Subscriber）的公钥：

   • 证书中包含了订户的公钥，供其他用户使用。

4. 订户：证书的持有者：订户是证书的持有者，拥有与证书中公钥对应的私钥。

5. CA要有自己的证书和私钥：

   • CA必须拥有自己的证书和私钥，用于对订户证书进行数字签名。

6. 用户拿到CA发布的证书，也有数据源鉴别、完整性的要求，要验证“证书是否被篡改、是否来自权威的CA”

‍

最简单的PKI结构——只有CA和订户

工作流程：

初始化

1. CA产生自己的公私钥对、自签名证书

服务流程

1. 订户产生公私密钥对
2. 将自己的公钥和信息交给CA
3. CA签发订户证书交给订户，并自己留有备份
4. CA随时响应用户的证书查询

‍

区分订户和用户

订户

拥有公私密钥对和相应证书的通信方，可以是人、设备、进程等等。通常，也称为证书持有者Certificate Holder

用户

享受PKI服务的实体，PKI订户同时也肯定是PKI用户

‍

RA（Registration Authority）-CA验证订户的逻辑

• 注册机构
• 负责进行各种信息审查
• RA可以有多个，并行地处理
• 审核之后，交给CA，由CA签发证书

此时PKI结构变化：

单CA 多RA

​​

流程变化：

初始化

1. CA产生自己的公私钥对、自签名证书

服务流程

1. 订户产生公私密钥对
2. 将自己的公钥和信息交给CA
3. CA签发订户证书交给订户，并自己留有备份
4. CA随时响应用户的证书查询

初始化

1. CA产生自己的密钥对和自签名证书

2. 创建RA（新增步骤）

   1. CA给RA管理员签发证书
   2. RA管理员添加“RA录入员、审核员”
   3. CA给RA录入员、审核员签发证书

3. 创建RA的步骤可以是多次的

   1. 一个CA可支持多个RA

服务流程

1. 订户向RA提出证书申请

2. 订户产生公私密钥对

3. 将自己的公钥和信息交给RA录入员

4. RA授理订户申请，向CA提交订户申请

5. RA录入员将订户信息录入RA系统

6. RA审核员审核订户信息的正确性及真实性

7. 发送证书请求给CA：由RA或者RA操作员的数字证书来保证通信的安全性

8. CA签发证书，并返回给订户

   • CA可直接返回给订户
   • CA发送给RA，由RA返回给订户

9. CA随时响应用户的查询

‍

分层CA

1. 在各地区建立Subordinate CA，由统一的CA给这些Subordinate CA签发证书
2. 每个Sub CA维护自己的系统和用户
3. 根CA签发了Sub CA的证书之后，二者之间的业务数据通信就很少了

​​

• 将签发“自签名证书”的CA，称为根CARoot CA
• 下级，都称为子CASubordinate CA（Sub CA）

‍

‍

资料库（Repository） —— CA的负担问题

CA的负担：

1. 24小时在线，可能带来的安全威胁
2. CA面向RA在线，但是不希望面向所有的用户在线
3. 保持在内部网络的在线
4. 支持多种服务接口
5. CA功能过于庞大、复杂
6. 使用专门功能的资料库来进行发布
7. 引入Repository

‍

资料库（Repository）

用于发布CA系统的各种公开信息：

1. 证书
2. CRL
3. CP
4. CPS
5. OCSP
6. 通知公告等

注意：资料库需要为“PKI用户”提供服务，而不仅仅是“PKI订户”
前者的数量远远大于后者

有可能超出资料库的负载能力，有可能需要进行分布式的设计，带来数据同步和一致性的问题

​​

‍

CRL Issuer —— 解决证书撤销问题

CRL Issuer被设计出来专门负责签发CRL

现有的很多PKI系统中，并没有CRL Issuer

1. 由新增加的CRL Issuer来负责接收和处理RA发送来的撤销信息

2. 定期签发CRL

   1. 可以更加频繁
   2. 缩短撤销信息的延迟

​​

‍

OCSP —— 解决证书状态变化的延迟问题

1. Online Certificate Status Protocol（OCSP）

   • 一种通信协议，专门用于检查证书是否已经被撤销
   • 相应的服务器称为OCSP Server

2. OCSP的基本流程

   • PKI User向服务器发出查询请求：“序列号为896623的证书的状态是什么？”

   • OCSP服务器的响应可能是：Good、Revoked、Unknown

     • Good：未撤销
     • Revoked：已经撤销
     • Unknown：未知

‍

1. 有同样的安全需要

   • 数据源鉴别、完整性

2. 在OCSP响应消息中，应有数字签名

3. 重放攻击

   • 在证书被撤销后，伪装旧的“Good”响应

4. 在OCSP响应消息中，应有时间

‍

因为OCSP提供的也是证书的撤销信息，所以，一般将其归入资料库的一部分。但是，它是比较特殊的、PKI专有的，并非类似通用得到http、ftp等

最终结构：

​​

‍

重点：证书包含的信息

1. 证书持有者名称
2. CA名称
3. 证书持有者公钥
4. CA签名结果
5. 证书有效期

‍

证书基本结构

1. 版本－为了更好地升级、扩展

2. 证书序列号－唯一标识

3. 签发者（颁发者）Issuer－CA DN

4. 有效期

5. 证书主体（使用者）Subject－证书持有者DN

6. 公钥信息

   • 算法标识
   • 算法参数

7. CA签名

   • 算法标识
   • 签名结果

‍

六 PKI 数字证书编码

基本数据类型

1. INTEGER

2. BOOLEAN

3. NULL

   • 普通RSA签名算法的参数就是NULL

4. OCTET STRING

5. OBJECT IDENTIFIER

6. BIT STRING

7. UTCTime

8. GeneralizedTime

‍

关键字

1. SEQUENCE

   1. SEQUENCE OF
   2. SEQUENCE SIZE () OF

2. SET

   1. SET OF
   2. SET SIZE () OF

3. ANY DEFINED BY

4. OPTIONAL

5. CHOICE

6. DEFAULT

‍

编码 —— 将数据结构对应到二进制串中

Der 编码

编码由TLV组成

• Type类型－1字节

  • 例如：INTEGER, BIT STRING, BOOLEAN
  • 给出了规定的Type标识

• Length长度－有多个字节（至少1个）

  • Value的长度，in bytes

• Value－共有Length个字节

  • 真实的内容

‍

Tag —— 解决编码中的各种混乱问题

optional？

‍

explicit tag 显式标签

1. 类型保留：显式标签在编码时保留字段的原始类型信息，即使在复杂的数据结构中，也能确保字段的类型被正确识别。
2. 灵活性：允许在不改变标签的情况下更改字段的类型，这对于向后兼容性和数据结构的演化非常重要。

implicit tag 隐式标签

1. 简化编码：隐式标签不包含数据类型的信息，这可以减少编码的字节长度，特别是在已知所有字段类型的情况下。
2. 类型依赖：字段的类型与标签紧密相关，如果字段的类型发生变化，标签也需要相应地改变。

implicit tag 会破坏原有数据的类型，但可以减少传输的字节长度。

‍

七 证书拓展

关键拓展项目与非关键拓展项目

关键拓展：

• 如果是很重要的信息，要求使用者非看不可的信息，就要设置为关键。
• 当系统不知道如何解析关键拓展项时，直接认为是非法证书

‍

非关键拓展

• 如果是可有可无的信息，最好设置为非关键。使得证书的使用范围更加大。
• 当系统不知道如何解析非关键拓展项时，选择直接跳过该条项目

‍

证书拓展解析

• 验证时，需要构建证书认证路径

• CA证书可以是在路径的起点、中间、终点

• 订户证书只能是路径的起点

‍

1. Basic Constraints

​​

1. OID: 2.5.29.19

   • cA：用于区分是否是CA证书：TRUE/FALSE
   • 以及路径的深度，说明CA可以有多少层次的下级，以整数说明

2. 在Basic Constraints中，非负整数n表示说，在本CA证书与最终订户证书之间，最多可以有的证书数目

   • pathLenConstraint仅仅对于CA证书才有效

   • pathLenConstraint=0表示，该CA只能直接给订户发证，不能再有下级。

   • 也可以说明不限制层次

   • OPTIONAL

     • 不存在，表示不限制路径深度，可以无限制地增加下级CA

3. 对于pathLenConstraint=2的CA证书，可以是：

   • 该CA可以有最多两层下级CA

4. 对于pathLenConstraint=0的CA证书，就只能是：

   • 该CA只能直接给订户发证，不能再有下级CA

​​

限制子CA的权力

‍

2. Authority Key Identifier

证书中的Issuer可以帮助你唯一地找到一个CA，但是不会告诉CA使用哪个公钥/证书来进行验证。

而CA拥有的公钥/证书太多了，如何快速进行验证？

Authority Key Identifier扩展应该标明是使用了哪一个密钥来签发的，便于用户验证

如何标识CA的某一个密钥/证书对

• 用“Issuer + 证书序列号”

• 用相应公钥的唯一标号

  • 一般直接公钥信息的HASH结果
  • 标准推荐：SHA1 HASH结果

‍

3. Subject Key Identifier

用于区分某个订户的多个不同的证书

标准推荐：SHA1 HASH结果

‍

‍

4. Key Usage

用于区分/限制密钥的用途

‍

5. Private Key Usage Period

限制数字签名的有效期

‍

6. Issuer Alternative Name

在证书中，对于各种不同的命名系统，也应该有所体现

专门放置签发者的各种不同的命名

‍

7. Subject Alternative Name

对于证书订户，也有各种命名的情况。

用户也可能需要公开自己的信息

同样，也有定义了Subject Alternative Name扩展

‍

8. Subject Directory Attributes

X.509证书是来源自于X.500目录，自然，可能希望在证书中带有某些X.500目录的属性信息

例如，民族、生日等
以Attribute的形式给出
包括了Attribute Type和Attribute Value
此种形式，可以给出订户所对应的Entry的很多信息

‍

9. Name Constraints

限制CA所能够签发证书的订户的名字空间

根CA用来限制子CA的签发范围（如单位、地域、类别等等）

命名限制同时对Subject和Subject Alternative Name起作用

注：

Name Constraints只是出现在CA证书中
并不是出现在订户证书中

‍

10. Certificate Policies

证书策略就是用来区分不同证书的安全等级的

简称CP

以OID的形式

Any-Policy：对于该CA所签发的订户证书的CP没有限制，相当于没有CP

1. CP出现在CA证书

   • 如，CA证书中有5个CP（ABCDE）
   • 表示该CA可以签发包含这几种CP的订户证书

2. CP出现在订户证书

   • Bob证书中的CP是A级
   • 就说明了Bob证书的安全等级和可使用的范围

3. 1个CA能否具有几种不同的CP？

   • YES
   • 1个CA可以支持多种不同的证书签发流程
   • 签发的证书可用于多种安全等级的范围

4. 1个订户证书，能否具有几种不同的CP？

   • YES
   • 签发流程自然只有1种
   • 但可用于多种安全等级的范围
   • 应用系统检查的需要

Any-Policy的管理：

1. 对应用系统而言，希望CA管理更加严格

   • 不希望出现Any-Policy
   • 出现Any-Policy就说明CA的行为具有一定的不可预测性
   • CA说：我也不知道我签发的证书的安全级别能达到什么样的地步

2. 层次越多、证书路径越长、上下级的管理越疏远

   • 就越不可预测

‍

11. Inhibit Any-Policy

仅用于CA证书

1. 应用系统会对CA提出要求

   • 在完全可控的范围内使用Any-Policy，是勉强可以
   • 在很不可控的范围内使用Any-Policy，不能使用

2. 有了Inhibit Any-Policy扩展

   • 要对Any-Policy的使用，提出一些限制

‍

‍

12. Policy Mappings

Policy Mappings扩展仅仅存在于交叉证书中

说明了不同CA域之间的CP等级的相互映射关系

​​

‍

13. Policy Constraints

​​

‍

14. Extended Key Usage

以OID的形式，给出了证书/密钥可用的用途

比key usage限制更细

‍

15. CRL Distribution Points

证书撤销状态的重要途径就是CRL
后面有专门章节讲解证书撤销
那么，应该系统在检查证书的时候，如何才能得到合适的CRL呢？

​​

以证书扩展的形式，给出了“检查本证书所需要的CRL文件，到什么地方获取”

‍

16. Freshest CRL

与CRL Distribution Points类似，用在增量CRL情况下，获取最新的增量CRL的地址

‍

17. IETF PKIX还定义了2种拓展

Authority Information Access

1. 如何在Internet上面，访问一些CA的信息

   • 目前，只定义

     • CA Issuers：证书签发者的上级CA的情况
     • OCSP：OCSP服务器的情况

Subject Information Access

1. 如何在Internet上面，访问一些用户的信息

   • 目前，只定义

     • caRepository：仅对CA证书，给出资料库的地址
     • timeStamping：仅对TSA服务器，给出TSA服务地址

‍

‍

八 PKI信任体系

POP —— 解决CA确认订户拥有对应的私钥，而不是出现了混淆事故

Proof of Possession (POP) of Private Key： 私钥的拥有证明

1. 证明订户拥有“其提交的公钥相对应的私钥”的证据

   • 注意：

     • 该证据不能泄漏私钥信息
     • 该证据不能损坏订户利益

2. CA在签发、发布证书之前，应该进行POP检查

   • 前提是：CA不允许知道用户的私钥

‍

各种POP的方式（密钥用途不同）

1. 签名密钥Signature Key

   1. 要求安全信道，会遭到中间人攻击

2. 加密密钥Encryption Key

   1. 直接方式，利用公钥加密并发送挑战给订户，要求解密

   2. 间接方式

      1. CA不做检验，直接签发订户证书
      2. 使用订户公钥，对证书加密，发送给订户
      3. 订户响应明文形式的、自己的证书
      4. RA/CA在资料库上发布订户证书

3. 密钥协商密钥Key Agreement Key

   1. 如下过程

      • 订户提交证书请求
      • RA/CA使用证书请求中的公钥，与订户协商Session Key，然后进行通信
      • 也就是验证了订户是否有私钥

   2. 特点

      • 要求双方都在线，才能够进行协商

‍

一般，需要在RA或者CA处进行POP检查。
或者BOTH，都要检查。

‍

根CA引入

根CA就是信任传递的起点

‍

信任传递

指的是实体A因为信任B，进而会信任其他的实体C
Bob因为信任根CA，而且根CA说Sub CA可信，进而Bob信任了Sub CA

‍

信任锚

1. Trust Anchor

   • 在信任传递（也就是建立证书路径）的过程中，需要有信任的起点，称为信任锚
   • 根CA在证书验证过程中，就是Trust Anchor

2. Trust Anchor指的是如下的实体：

   • 对该实体的信任并不是由于PKI中的信任传递而得到，而是以其他方式得到

3. 信任锚以何种方式引入？

   • 信任锚通常通过预配置或手动导入的方式引入，例如操作系统、浏览器或应用程序中预先内置的根证书。

‍

信任锚的引入

• 安全可靠的方式
• 依赖于用户自身的判断
• 不能依赖于PKI系统本身

‍

信任模型（Trust Model） —— PKI系统互认

我们知道，信任的传递应该受到控制的，无限制的信任传递会导致问题

通过信任模型，我们希望：PKI User能够可控地、与更多的人建立联系

信任模型与CA拓扑结构是一一对应的

例如，使用双层CA拓扑结构——也就决定了信任的传递次数。另一方面，如果希望信任传递受限，就不应该有太多级的CA层次。二者相辅相成，相互影响。

‍

多根CA的情况

每个国家/区域可能都有一个根CA

多个根CA体系如何互相认证

‍

多根CA下的验证者情况

1. 单根CA

   • 所有验证者的配置都是一样的
   • 验证系统中的信任锚一样，都是同1个根CA证书

2. 多根CA

   • 验证者的配置是否一样？

     • 2种情况

       • 各验证者都有“相同的”多个信任锚（多个根证书）

       • 各验证者的信任锚配置是不一样

         • 可能每个验证者都只有1个信任锚，但各不相同

‍

多根CA的几种情况

• 证书信任列表(CTL) Certificate Trust List —— 不改变Trust Anchor

  • 权威发布和非权威发布

• 交叉认证 Cross Certification —— 不改变Trust Anchor

  • 改变CA之间的证书互联关系

• 鉴定证书 ACA Accreditation Certificate —— 改变Trust Anchor

• 网状 Mesh —— 不改变Trust Anchor

• 桥CA BCA Bridge CA —— 不改变Trust Anchor

‍

‍

CTL 方式 （Certificate Trust List）

用户自主处理（最简单的方式）：

类似于我们现在的IE浏览器，我们可以自主地再安装新的根CA证书

每个用户要自主地处理信任锚，对于某些用户难以接受

‍

权威发布方式：

由权威机构统一地发布1个可信的信任锚列表

也就是Certificate Trust List

可能是以各种方式发布
网页文字说明（例如中国的信息产业部）
数字签名的文件（例如欧洲桥CA）

如：中国的信任列表（网页文字发布）

​​

‍

鉴定证书 ACA Accreditation Certificate

ACA有自签名证书，给其他根CA签发Accreditation Certificate

​​

信任锚发生变动

‍

交叉认证Cross Certification

本域的CA给其他域的CA签发证书，使得信任传递的范围扩大

​​

验证时，相当于将对方CA，视为我方的SubCA

​​

1. 因为交叉认证的各种优点

   • 由CA统一完成
   • 不需要每个用户独立地配置
   • 信任扩大是可控的
   • 使用各种证书扩展
   • 没有改变信任锚（非常重要的优点）
   • 可以随时撤销

2. 因为交叉认证的各种优点

   • 得到了很多应用，下面的各种信任模型都是基于交叉认证的

‍

网状Mesh

网状模型并不是一种专门的模型

多次交叉认证，就形成网状，可能是单向或双向

相当于是N个CA之间，进行了交叉认证

• N≥3
• 如下图，最多时是N×(N-1)

​​

由于关系多，考察对方的CP/CPS、研究策略映射、签发交叉证书，负担很大

认证路径自动构造

可能进入死循环
CA2－CA6－CA5－CA2－CA6－CA5……

会找到多条路径
CA2－CA3－CA1－CA4
CA2－CA4

因为多个CA之间，都要各自为政地相互进行交叉认证，所以，就会出现了上面的问题

解决方法
进行分工，由单独的机构解决CA互联的问题
然后，所有CA统一地与该机构进行交叉认证

‍

BCA 桥CA 解决CA网状交叉验证乱象

BCA与每个CA进行双向交叉认证，从而能够连通所有的CA

​​

通过桥CA传递信任

控制BCA的无限权力？

• 可以使用命名限制来控制
• 命名限制扩展中，写明BCA只能给CA3、CA4签发证书
• 那么，BCA给CA2、CA5签发的交叉证书，在CA1的用户看来是无效

‍

现实中不存在单根CA

‍

九 证书撤销

CRL 过程

撤销过程如下

• 用户/或者其他方向RA提出撤销请求

  • RA审查撤销请求
  • 通过后，RA将撤销请求发给CA或者CRL Issuer
  • CA或者CRL Issuer修改证书状态

• CA或者CRL Issuer定期签发CRL

‍

1. 构造证书路径

   • 一系列证书，从订户证书到信任锚

2. 对于证书路径中的每个证书

   • 验证是否处于有效期
   • 验证CA签名是否有效
   • 有了证书撤销，就需要检查撤销状态

‍

仅仅对于证书有效性的最基本检查，还要检查各种证书扩展

​​

除了CRL，还有其他证书撤销状态的处理方法

• CRL

• OCSP

• CRT

  • 注意：OCSP、CRT仍然可能依赖于CRL，后面说明

• 短周期证书

‍

CRL 中的基本内容

1. 版本

2. Issuer

3. 时间

   • thisUpdate：签发本CRL的时间
   • nextUpdate：下一次签发的时间（相当于本CRL的失效时间）

4. 扩展

5. 对于每一个被撤销的证书

   • 序列号
   • 撤销时间

​​

完全CRL（Complete CRL）

• 特点：包含所有被撤销证书的序列号。

• 问题：

  • 文件可能很大，因为需要下载完整的被撤销列表。
  • 信息更新频繁，通常24小时内或更短时间就需要更新，导致频繁下载。

增量CRL（Delta CRL）

• 特点：相对于某次完全CRL，只包含撤销列表的变化量。
• Base CRL：增量CRL的参照基准。Base 的CRL不同，增量CRL的内容也不同
• 优点：减少了每次下载的数据量，因为只包含变化的部分。

直接CRL（Direct CRL）

• 特点：证书的签发者（CA）同时也是CRL的签发者。
• 优点：对于用户的证书验证过程较为简单。
• 问题：给CA带来较大负担，因为CA需要处理所有的CRL签发工作。

间接CRL（Indirect CRL）

• 特点：使用专门的CRL Issuer签发CRL。
• 优点：细化分工，减轻CA的负担，CRL Issuer可以专注于CRL的签发和管理。
• 问题：用户的证书验证过程更复杂，需要额外验证CRL Issuer的证书。

CRL分发点（CRL Distribution Point）

• 作用：提供获取CRL的地址，这些地址由CA或CRL Issuer公布。
• 特点：可以出现在证书的扩展中，指导用户如何获取CRL。

存在的问题

• 文件大小：如果CRL中包含大量被撤销的证书序列号，文件会很大，不利于用户下载。

重点：总结

• 完全CRL适合小型PKI环境，但文件大且更新频繁。
• 增量CRL通过减少下载量来优化CRL管理。
• 直接CRL简化了用户验证过程，但增加了CA的负担。
• 间接CRL通过引入专门的CRL Issuer来分担CA的负担，但增加了验证的复杂性。
• CRL分发点提供了一种机制，使得用户可以方便地获取最新的CRL信息。

‍

CRL Distribution Point

CRL Distribution Point 可以使用CA自己决定的依据对CRL文件进行拆分

‍

特殊CRL

1. 特殊拆分的CRL文件

   • CRL的发送信息长度不定。
   • 被撤销证书的序列号排序后，签发n-1个CRL，每个包含相邻两个序列号。
   • 包含两个特殊序号的CRL。

2. 重定向CRL（RCRL）

   • 在CRL分发点基础上，动态变化证书对应的CRL文件。
   • 将CDP（CRL分发点）信息以CRL文件形式发布。

‍

应用方式：

1. 类似于OCSP服务器

   • 响应特定证书序列号x的查询，返回CRL=Sign(R1, R2)。
   • 条件：R1 < x < R2 或 R1=x 或 R2=x。
   • 持有有效证书的用户需递交CRL=Sign(R1, R2)，满足R1 < x < R2。

2. 重定向CRL

   • 特殊拆分CRL文件不能使用CRL分发点。
   • 证书对应的CRL文件不能事先确定，信息会变动。
   • 例如，证书x和y可能最初使用同一CRL文件，但随着时间变化，应使用不同CRL文件。

‍

OCSP

在第五章讲过OCSP

在线证书状态协议

‍

OCSP的数据来源

1. 最新的CRL（证书撤销列表）

   • 可以解决OCSP的延迟问题。
   • 响应消息中的时间戳可以与CRL文件一致。
   • 可以缓存重用，减少签名次数。

2. 内部数据库

   • 没有延迟，响应消息的时间戳更短。
   • 难以重用，签名次数更多。
   • 可能需要对每次查询重新签名。

OCSP的讨论

1. OCSP服务器的响应需要进行数字签名

   • 同样需要验证OCSP服务器的证书。
   • 无法完全解决问题，需要CRL的协助。
   • 直接使用CA在线提供OCSP服务存在安全问题。

2. OCSP服务器的响应效率问题

   • 效率难以保证，数字签名所需资源较大。
   • 可能造成拒绝服务攻击（DDoS/DoS）。

‍

‍

CRT | Certificate Revocation Tree证书撤销树

CRL和OCSP的比较

1. CRL的特点：

   • 列表长、数据量大，尤其是完全CRL。
   • 对所有撤销证书的序列号进行签名，组织无结构，序列号直接排列。

2. OCSP的特点：

   • 需要服务器不断地对每个请求消息进行签名。
   • 响应数据较短，但需要服务器频繁地签名。

​​

‍

CRT作为折中方案

1. CRT的特点：

   • 基于2叉HASH树的方式，由Kocher提出。
   • 只需要服务器进行1次签名，计算量与CRL类似。
   • 针对某个特定的证书进行查询，采用请求-应答的方式。
   • 应答消息不像CRL那么庞大，通信量与OCSP类似。

2. CRT的签名方式：

   • 对于各证书序列号进行一定的结构化，形成HASH链。

​​

CRL 无结构

CRT 有结构

‍

‍

CRT的优势

• CRT提供了一种折中方案，它结合了CRL和OCSP的优点，减少了服务器的签名负担，同时保持了较短的响应数据。
• CRT的HASH链结构使得证书撤销信息的管理和查询更加高效。

总结

• CRL和OCSP各有优缺点，CRL在数据量和更新频率上可能较大，而OCSP则在实时性和签名效率上可能存在问题。
• CRT作为一种折中方案，通过结构化证书序列号并形成HASH链，减少了服务器的签名次数，同时保持了较短的响应数据，提高了效率。
• CRT的提出，为证书撤销信息的管理和查询提供了一种新的、更高效的解决方案。

‍

​​

CRT的产生：

​​

‍

短周期证书（Short-lived Certificate）

1. 定义：将证书的周期设定为与CRL（证书撤销列表）的更新期一致。

2. 优点：

   • 回避了用户检查证书撤销状态的问题。
   • 减少了对CRL的依赖。

3. 缺点：

   • 给证书颁发机构（CA）带来了巨大的工作量，需要每天不断地发证。
   • 新证书的信息除了有效期外，其他都不变化。
   • 如果证书发生问题，就不再发新证书。

短周期证书的特点

1. 用户行为：要求公钥基础设施（PKI）用户每天都去查询下载新的证书。
2. 证书使用：短周期证书要求PKI用户随时到服务器查询下载证书，才能使用。
3. 问题解决：没有CRL/OCSP/CRT的问题，撤销的操作仅在下载服务器上进行。

短周期证书的撤销问题

1. 私钥泄露：出现订阅者私钥泄露等情况时，同样需要撤销证书。
2. CRL缺失：没有CRL来发布撤销信息。
3. 撤销流程：RA（注册机构）接收订阅者的撤销请求，提交给CA，CA为订阅者签发下一个有效期证书。

​​

‍

证书撤销验证存在的问题

1. 实时性问题：实时应用中，证书撤销状态查询可能不及时。
2. 网络延迟：受网络延迟影响。
3. 服务在线情况：受证书撤销服务在线情况影响。
4. 默认假设：当证书撤销状态不可获得时，一般认为证书未被撤销。

证书撤销状态检查的新方案（Push-Based）

1. CRLSet-Google：Google自定义的一部分证书。
2. OneCRL-Mozilla：中间CA证书撤销。
3. CRLite-S&P 2017：针对互联网上所有证书。
4. Let's Revoke-NDSS 2020：针对互联网上所有证书。

‍

十.1 SSL协议

基于TCP实现

一共两层

​​

协议分层

Record层

• 对于数据，究竟是如何处理的
• 机密性、数据完整性

Handshake层

• 双方身份鉴别、协商对称秘密
• 利用公钥算法
• 攻击者不能窃听获得
• 各种秘密，用到Record层

‍

Record 层 | 起到保护作用

当TLS协商之后、无错误地运行、传输Application Data时，主要就是Record层在起安全保护作用

Record层的作用

• 安全保护：在TLS协商（通过handshake建立安全信道）之后，当应用程序数据（Application Data）无误地运行和传输时，Record层负责提供安全保护。

Record Protocol操作

• 发送方处理步骤：

  1. 分块（Fragment） ：将应用程序数据分割成可管理的块。
  2. 压缩（Compress） ：可选步骤，实际中通常不使用。
  3. 计算MAC（Add MAC） ：一次性完成计算，使用认证加密（authenticated encryption）。
  4. 加密（Encrypt） ：对数据进行加密处理。
  5. 附加SSL记录头（Append SSL Record Header） ：将记录头附加到加密数据上，准备传输。

• 接收方处理步骤：

  1. 解密（Decryption） ：接收数据并进行解密。
  2. 验证（Verification） ：验证MAC以确保数据完整性和真实性。
  3. 解压缩（Decompression） ：如果发送方进行了压缩，则在此步骤解压缩。
  4. 重组（Reassembly） ：将数据块重新组装成原始消息。
  5. 交付（Delivery to apps） ：将数据传递给应用程序。

Record层的特点

• 发送方步骤：分块、压缩（实际中通常不使用）、计算MAC、加密。
• 实际处理步骤：分块、计算MAC和加密。压缩步骤在实际应用中通常被省略。

Record 协商过程

1. Record层的各种密码运算参数，都是由Handshake协议协商得到的

2. 协商过程，大致如下

   • Client/Server相互发送随机数（明文）
   • 选定算法
   • Server发送自己的公钥证书
   • Client验证证书
   • Client产生premaster secret，用Server公钥加密，发送
   • Server解密，双方共享相同的premaster secret和随机数
   • 由此计算产生，从而得到R/W Key/IV/MAC_Secret

‍

‍

Handshake 层

Handshake层的作用

Handshake层是TLS协议的一部分，负责在两个通信实体（客户端和服务器）之间建立安全连接。它通过协商加密算法、生成共享密钥，并进行身份验证，确保双方的身份和通信的安全性。

Handshake Protocol的具体过程

1. 可选步骤：Handshake过程中包含一些可选步骤，这些步骤可能因安全需求或协议版本而异。
2. 客户端鉴别：在Handshake过程中，客户端可以进行服务器的鉴别，确保它正在与正确的服务器通信。
3. DH与RSA算法协商：使用不同算法（如Diffie-Hellman（DH）或RSA）进行密钥交换时，鉴别过程可能有所不同。DH算法协商的鉴别过程与RSA算法协商不一致，因为它们基于不同的数学原理。
4. 基本过程：从最简单的Handshake过程开始，客户端鉴别服务器，服务器拥有RSA密钥或证书对。
5. 改进：讨论基本过程的不足之处，以及如何通过改进来满足特殊需求，最终形成一个完整的Handshake过程。

Handshake层的特点

• 安全性：Handshake层通过协商加密算法和密钥，确保通信的安全性。
• 身份验证：通过证书和公钥基础设施（PKI），Handshake层允许双方验证对方的身份。
• 灵活性：支持多种加密算法和协议版本，可以根据需要选择最合适的配置。
• 完整性：Handshake过程中还包括消息完整性检查，以防止数据在传输过程中被篡改。

Handshake层与Record层的关系

Handshake层负责建立安全连接，而Record层则在Handshake完成后，利用Handshake过程中协商的参数来保护数据的传输。Record层通过分块、压缩（可选）、计算MAC、加密和附加SSL记录头等步骤，确保数据的完整性、保密性和真实性。

‍

完整流程 P53

​​

​​

HeartBleed攻击

1. OpenSSL软件包中的安全漏洞

   • 由于TLS协议中的Heartbeat Extension实现有问题，导致向攻击者泄露秘密信息

2. Heartbeat Extension

   • 安全漏洞
   • 可能是第一个有名字的漏洞
   • 之前，很多漏洞都是称为CVE-XXXXXXX
   • 后来的漏洞，都有类似的趋势

‍

1. TLS协议的扩展

   • RFC 6520
   • 定义了TLS Heartbeat Protocol，运行在Record层之上

2. 心跳消息

   • 确认对方在线、维护TLS会话
   • 与上层传输的Application Data无关
   • 数据包不会交到上层

Heartbleed攻击，与协议无关、是OpenSSL软件实现的问题

‍

TLS 1.3

1. 与TLS1.2协议流程的主要区别

   • 身份鉴别支持Pre-shared key（PSK）模式
   • 在ServerHello之后的消息都被加密
   • 取消了ChangeCipherSpec消息功能

2. 支持的密钥协商模式

   • (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
   • PSK-only
   • PSK with (EC)DHE

‍

‍

‍

十.2 WIFI-无线认证技术

1. Wi-Fi是构建无线局域网最广泛使用的技术方案

   • 由Wi-Fi联盟提出
   • IEEE 802.11系列国际标准

2. WLAN的参与方

   • AP(Access Point)：无线接入点
   • STA(Station)：工作站，无线终端设备，如手机、平板、笔记本电脑等
   • AS(Authentication Server)：鉴别服务器，完成对于STA的身份鉴别，特定方案中使用

‍

wifi的接入方式

• 基于共享口令的鉴别与接入授权

• 基于用户身份的鉴别与授权

• 专用客户端或网页鉴别

  • 通信链路不加密
  • Open System：任何用户都可接入
  • 无线传输数据无保护

• 基于用户注册方式授权

  • 例如，通过微信账号、短信
  • 使用场景：火车站、酒店、UCAS

‍

‍

十二 PKI系统安全增强

1. PKI系统安全需求

   • CA能提供可靠的服务

   • 避免出现单点失效

     • CA不工作
     • CA未按安全策略提供服务

‍

1. 入侵容忍的CA系统

   • 允许系统存在一定的攻击或不可用的情况
   • CA仍可以正常提供服务

2. 信任增强的PKI体系

   • CA主动打破安全策略约束
   • CA被攻击导致服务不受控执行
   • 直观的影响：签发虚假证书

‍

入侵容忍 Intrusion Tolerance

入侵容忍CA系统方案

1. ITTC：由斯坦福大学Dan Boneh提出，更多从机密性（Confidentiality）出发，适用于传统网络。
2. ICNP 2001方案：由UCLA大学提出，更多从可用性（Availability）出发，适用于移动网络。

密码算法基础 —— 秘密分享（Secret Sharing）

• 场景：n个人分享1个秘密的消息，其中f+1个人能够恢复得到该消息，少于f+1则不能。
• Shamir's Secret Sharing：对于f阶多项式曲线，如果得到f+1个点坐标，可以恢复出完整的曲线。

基于Access structure的方案（基础是秘密分享）

• 智力竞赛问题：给大门上锁，并将钥匙分给n个人，使得f+1个人能够合作开锁。
• 答案：门上同时上L个锁，每把锁都有若干个钥匙，确保f+1个人有足够多的钥匙。

实际使用

• 快速计算公式：使用LaGrange插值公式在素域F_p上进行计算，适用于秘密数据定长。

‍

信任增强的PKI体系

PKI应用的重要性

1. HTTPS的安全基础：PKI是HTTPS协议的核心，确保数据传输的安全性。
2. 防止访问不安全的网站：通过证书验证，防止用户访问使用无效或伪造证书的网站。
3. 确保客户端与服务器之间的安全通信：使用PKI加密技术保障数据在传输过程中的安全性。
4. 浏览器中逐渐加强对HTTPS的使用要求：现代浏览器鼓励或强制使用HTTPS，以提高用户上网安全。

HSTS (HTTP Strict Transport Security)

1. 定义：HSTS是一种Web安全策略机制，强制浏览器只通过HTTPS与服务器通信。
2. RFC6797：HSTS的正式标准文档。
3. 服务器支持HSTS：服务器通过设置HSTS头，告知浏览器仅通过HTTPS访问。
4. STS header field：服务器在HTTP响应中声明是否支持HSTS及相应的策略。
5. 浏览器端处理：浏览器存储支持HSTS的域名信息，并在访问时自动转换为HTTPS。

PKI信任机制的基本形式

1. 证书有效性验证：客户端需验证通信对方（如TLS服务器）的证书有效性。
2. 证书链构建：客户端通过构建证书链，验证证书是否由信任的根CA签发。
3. 根CA信任：客户端对服务器证书的信任基于对根CA的完全信任。

PKI信任机制的安全问题

1. CA数量增长：随着HTTPS的广泛应用，需要验证的证书和信任的CA数量不断增加。
2. 根CA和中间CA：存在多个根CA和大量的中间CA，增加了管理复杂性。
3. CA的可信度问题：CA可能发布虚假证书，原因包括审查不严、操作失误、系统入侵等。
4. 虚假证书风险：虚假证书可能通过验证，但私钥被他人持有，存在安全风险。

相信一个不值得信任的恶意CA事实上可以打破整个PKI系统的安全

任何一个CA的安全漏洞就可能破坏被其他所有CA保护的站点的安全

‍

‍

安全增强的基本思路

1. 客户端检测

• Pinning: 浏览器自动记录TLS服务器的证书信息，并在后续访问中进行比较。

  • 记录TLS服务器公钥。
  • 记录TLS服务器证书。
  • 记录CA证书（中间CA或根CA）。
  • 发现不一致时，发出警告。

• Perspectives: 通过第三方服务Notary Server公证服务器，存储和查询TLS服务器的证书情况。

  • 建立Notary Server，自动化存储TLS服务器证书。
  • 客户端查询Notary Server，判断是否信任接收到的证书。

2. 限制CA权力

• Certlock: 假定TLS服务器只向同一国家的CA申请证书。

  • 首次访问时，浏览器检查证书来源。
  • 再次访问时，比较新旧证书的CA，不同国家则警告。

• CAge: 限定CA签发证书的顶级域名范围。

  • CA需在相应TLD中至少签发过一个证书。
  • 未签发过则警告用户。

• DANE和CAA: 将权力转给域名拥有者（TLS网站）。

• Sovereign Key: TLS服务器的再次确认。

3. 证书透明化 (Certificate Transparency)

• 记录CA的证书签发行为，要求透明公开。
• 快速发现错误，Google已大量实施。

4. Notary-based方案

• Perspectives: 比较多个TLS链接的服务器证书是否一致。
• The ICSI Certificate Notary: 从网络流量中被动收集数据。
• EFF SSL Observatory: 浏览器群体上传证书。
• Doublecheck: 通过TOR比较证书，效率低但保护隐私。

5. DNS中的PKI安全增强

• DNS系统作为域名数据库，提供域名证书相关信息。
• DNSSEC保证消息完整性和来源验证性。

‍

‍

十三 证书透明化

证书透明化方案是为了防止域名持有者在传统CA体系中，不知情的被签发CA证书的情况出现

1. Google提出CT方案，RFC6962 Certificate Transparency（2013）

   • 帮助发现虚假证书，帮助发现发布虚假证书的恶意CA
   • 提供一个公开的系统，使得任何一个域名所有者或者CA可以观察、探测到虚假证书的存在
   • 使得一个CA很难在真正的域名所有者不知情的情况下，发布相关的虚假证书

2. 增强证书验证过程

   • 降低用户被虚假证书欺骗
   • 从而减少虚假证书带来的后续攻击

‍

1. 证书透明化系统在传统PKI体系下增加以下角色

   • 公开日志服务器（Public Log Server）

     • 保存和维护记录证书的公开日志（Public Log）

   • 监视员（Monitor）

     • 周期性的访问公开日志服务器，寻找和发现可疑的证书

   • 审计员（Auditor）

     • 审计公开日志的行为

​​

增强的信息验证

收到证书并验证通过后，公开日志服务器会向提交者返回一个凭据（SCT）

Chrome浏览器，要求在TLS握手过程中至少2个SCT

1. 凭据：签名的证书时间戳（Signed Certificate Timestamp, SCT）

   • id：公开日志服务器用以签名的公钥的散列值

   • timestamp：凭据生成的时间

   • extensions：暂时无

   • entry_type：

     • x509_entry：最终证书
     • precert_entry：预证书（下详）

用户不仅需要验证证书，还需要验证相应的SCT

‍

SCT的引入

简化在SSL/TLS过程中，浏览器的工作

不是实时地连接Log Server、进行查找，避免网络延迟

‍

1. 用户如何得到SCT？

   • 从X.509证书扩展项获得SCT
   • 从连接建立时TLS扩展项获得SCT（目前主要使用的方式）
   • 从OCSP stapling的扩展项获得SCT

‍

‍

十四 隐式证书

1. 隐式证书（Implicit Certificate）

   • 公钥证书的一种“变体”

   • 典型方案是基于ECC算法的ECQV隐式证书方案

     • SEC 4: Elliptic Curve Qu-Vanstone Implicit Certificate Scheme

   • 有一定的适用范围

     • 在带宽、计算能力、存储资源有限制的环境下，是传统X.509证书的一种高效替代

‍

1. 证书内容：

   • X.509证书：包含订户身份信息、公钥数据和CA的数字签名，用于显式认证。
   • 隐式证书：省去了CA的数字签名，将CA的认证隐含在其他格式数据中，通过计算得出最终的公钥。

2. 密钥对生成：

   • X.509证书：密钥对的生成与证书的颁发是两个独立的过程，用户需要先向CA证明拥有私钥。
   • 隐式证书：证书颁发和密钥对的生成是互相依赖的过程，用户在证书颁发前不知道自己最终的公私钥对的值。

3. 计算量：

   • X.509证书：在验证过程中需要对订户证书链进行验证，包括各级CA对下层证书的签名和订户对消息的签名。
   • 隐式证书：需要重构出订户公钥，没有对CA数字签名的验证，在对消息的验签时同时完成对证书本身的验证，计算量相对较小。

‍

1. 证书类型: X.509证书
   计算过程:

   • 1. 提取CA公钥（不涉及耗时的密码操作）
   • 2. 验证订户证书（验签计算）
   • 3. 提取订户公钥（不涉及耗时的密码操作）
   • 4. 验证消息签名（验签计算）
   • 计算代价 (次): 2 (次验签计算)

2. 证书类型: 隐式证书
   计算过程:

   • 1. 提取CA公钥（不涉及耗时的密码操作）
   • 2. 计算订户公钥（专门的计算）
   • 3. 验证消息签名（验签计算）
   • 计算代价 (次): 1 (次专门的计算) + 1 (次验签计算)

‍

‍

隐式证书典型应用

车联网V2X通信

主要包括V2V（车车）、V2I（车路）、V2N（车网）和 V2P（车人）

1. V2X : Vehicle-to-Everything

   • V2V（车车）：车辆间传递速度、距离等信息
   • V2I（车路）：车辆与路边设备如红绿灯等路边设备的通信
   • V2N（车网）：车辆与网络或云服务等的通信
   • V2P（车人）：车辆与行人的通信，可通过行人身上的可穿戴设备、手机、电脑等方式，也有的称为V2D

‍

1. 两种通信技术路线

   • Dedicated Short Range Communication: 专用短程通信
   • Cellular-V2X技术: 蜂窝车联网技术

2. 技术要求

   • 主要针对V2V/V2I
   • 高速、频繁、隐私

‍

‍

隐私要求

1. 匿名

   • 数字证书上的身份标识，与真实身份无关

     • 车牌、车主等等

   • 广播通信

   • 不可关联（Unlinkability）

     • 若直接使用同一张匿名证书 ⟹ 可以关联轨迹

     • 每一车辆拥有多张假名证书，随时切换使用

       • 几分钟

     • 切断多张假名证书之间的关联关系

   • 可监管（或者说，Unlinkability => Linkability）

     • 特定条件的匿名解除和假名关联

‍

十五 Kerberos

1. Kerberos是网络通信的鉴别协议

   • 由MIT设计：最早是保护Project Athena的网络服务
   • 针对client/server模型
   • 提供集中的授权服务器，实现client与server之间的鉴别

​​

Kerberos特点

1. A trusted third-party authentication service by using conventional (shared secret key) cryptography

   • 提供可信的第三方鉴别服务
   • 基于对称密码学
   • 也可支持部分协议过程中使用非对称密码技术

2. 提供相当的安全性

   • 在每个Client和Server之间建立了共享密钥
   • 可以保护网络实体免受窃听和重放攻击

3. 支持SSO(Single Sign On)

   • 用户只需输入一次身份验证信息就可以凭借此验证获得的票据(TGT)访问多个服务
   • 注意：有效期

4. 支持一段时间内，同一用户

   • 对不同应用的访问
   • 或同一应用多次访问
   • 无需用户进行重复的身份鉴别操作（如输入口令）

‍

Kerberos原理

1. Kerberos实际上是一个基于Ticket的鉴别方式

   • 鉴别的先决条件是Client向Server提供从KDC获得的一个由Server的主密钥进行加密的Session Ticket(ST)

   • ST包含Session Key和Client Info

   • Session Ticket是Client进入Server领域的一张门票

   • 这张门票必须从一个合法的Ticket颁发机构获得

     • Client和Server双方信任的KDC

   • 同时这张Ticket具有超强的防伪标识：被Server的主密钥加密

   • 对Client来说，获得ST是整个鉴别过程中最为关键的部分

‍

存在的问题

1. 长期密钥的网络传输问题：

   • 长期密钥加密的数据在网络中传输存在风险。
   • 加密算法无法保证绝对安全，解密只是时间问题。
   • 建议使用短期密钥（会话密钥）代替长期密钥进行数据加密，以减少密钥泄露的风险。

2. 字典攻击问题：

   • 用户的长期密钥是从口令派生的，短口令容易受到字典攻击。
   • AS请求在第一步中是明文的，攻击者可以通过请求AS获取加密信息。
   • 攻击者可以进行离线字典攻击，通过预先制作的字典来破解密钥。
   • 预认证可以减慢攻击者破解速度，但不能完全防止攻击。

改进方案：

• 使用短期密钥加密数据，避免长期密钥在网络中传输。
• 增加User2User子协议，增强服务器的保护。
• 对客户端而言，长期密钥实际上是口令，用于加密AK。
• PKINIT作为解决方案之一，通过公钥基础设施增强安全性。

总结：

• Kerberos协议在设计上存在长期密钥传输和字典攻击的风险。
• 通过使用短期密钥和预认证机制，可以提高安全性。
• PKINIT提供了一种增强安全性的替代方案，利用公钥基础设施来保护认证过程。

‍

‍

十六 OAuth

1. Pseudo-SSO

   • 优点：原有SP（Service Provider）不需要改动
   • 不足：简化用户、不简化管理

2. SSO

   • 优点：同时简化用户和简化管理
   • 不足：需要系统改动

‍

单点登录

1. 优点：2个方面

   • 简化用户操作

   • 简化管理

     • 集中式的、统一安全策略
     • 重置口令的请求，大量减少

‍

Oauth出现的背景

方法一：用户下载后上传

• 优点：安全性较高，因为数据传输过程相对安全，避免了数据在传输过程中被截获的风险.
• 缺点：效率低下，用户操作繁琐，需要先从服务A下载图片到本地，再上传到服务B，尤其在处理大量或大文件数据时，整个过程耗时且不便.

方法二：共享用户名和口令

• 优点：效率提高，服务B可以直接访问服务A上的用户账户获取图片，省去了用户下载和上传的步骤，使用户能够快速完成打印任务.
• 缺点：安全性大大降低，服务B获得了用户的用户名和口令，可以以用户身份登录服务A，查看甚至篡改用户在服务A上的所有资源，存在极大的隐私泄露和数据滥用风险.

更好的方法：使用OAuth授权机制

• 安全性保障：用户无需共享用户名和口令，通过OAuth授权服务B访问其在服务A上的特定资源，确保服务B只能在授权范围内访问数据，不能查看或修改其他资源.
• 效率提升：简化了操作流程，用户只需进行一次授权操作，服务B即可直接访问服务A上的图片资源进行打印，无需用户手动下载和上传.
• 细粒度权限控制：支持对授权范围进行细粒度的控制，用户可以根据需要选择授予服务B哪些权限，更好地保护隐私和数据安全.
• 可随时撤销授权：用户可以随时撤销对服务B的授权，增强对数据访问的控制能力.
• 标准化和广泛支持：OAuth是开放的授权标准，具有良好的兼容性和可扩展性，便于服务A和B之间的集成和协作，已被广泛应用于各种互联网服务和应用程序中.

‍

SAML

1. SAML 是 OASIS 制定的一种安全性断言标记语言

   • 它用于在复杂的环境下交换用户的身份识别信息
   • SAML主要是用来实现联邦鉴别（federated authentication）和联邦身份管理

2. 联邦身份

   • 是在同一个用户的两个身份之间建立一个逻辑连接
   • 而这两个身份是分别由两个不同的身份提供商/应用服务管理的

‍

OAuth2.0

​​

‍

OpenID | OpenID Connect(OIDC)

​​

OpenID的优势包括单点登录（SSO）、去中心化认证、增强的隐私和安全、用户控制以及减少密码疲劳。

OpenID的工作原理涉及三个主要角色：用户、OpenID提供者（OP）和依赖方（RP）。

​​

OpenID的创建基于通过URI（URL或网站地址）来认证网站的唯一身份的概念，同样的方式也用于用户的身份认证。

​​

1. 依赖方构造一个鉴别请求，该请求包含所需的所有参数
2. 依赖方将请求发送到授权服务器
3. 授权服务器鉴别终端用户
4. 授权服务器获得终端用户许可/授权
5. 授权服务器将终端用户重定向到依赖方，此重定向消息包含一个授权码
6. 依赖方使用第5步中获取的授权码向令牌端点发起请求
7. 依赖方收到一个包含ID令牌和访问令牌的响应
8. 依赖方验证ID令牌并提取终端用户的主体标识符。

‍

依赖方可以使用访问令牌从用户信息端点（UserInfo Endpoint）获取更多用户信息

1. 获取终端用户信息:

   • 依赖方如何从用户信息端点获取资源。
   • 用户信息端点是OAuth 2.0保护的资源，返回关于已认证终端用户的声明（Claims）。

‍

‍

十七 FIDO

FIDO（Fast Identity Online）是一种安全认证系统，旨在提供一种无需密码且具有多因素认证的在线服务访问方式：

1. UAF（Universal Authentication Framework） ：这是FIDO的一个组成部分，允许在线服务提供无需密码的多因素安全认证。
2. 设备注册：用户通过选择本地认证机制将他们的设备注册到在线服务。
3. 本地认证机制：这可能包括指纹扫描、面部识别、语音识别、输入个人识别码（PIN）等。
4. 重复认证动作：用户在需要对服务进行认证时，只需重复他们之前选择的本地认证动作。
5. 多因素认证：UAF支持结合多种认证机制的体验，例如指纹加PIN码，以增强安全性。

FIDO的目标是通过简化认证过程并减少对传统密码的依赖，提高在线服务的安全性和用户体验。

‍

fido 流程

FIDO（Fast Identity Online）认证流程包括注册（Registration）和登录（Login）两个主要步骤，具体如下：

注册流程（Registration）：

1. 注册开始（Registration Begins） ：用户在网站上开始注册过程。
2. 用户选择认证器（User Approval） ：用户被提示选择一个符合在线服务接受政策的FIDO认证器。
3. 创建新密钥（New Key Created） ：用户的设备为本地设备、在线服务和用户账户创建一对新的公钥/私钥。
4. 密钥注册（Key Registered） ：公钥被发送到在线服务，并与用户账户关联。私钥和任何关于本地认证方法的信息（如生物测量数据或模板）永远不会离开本地设备。

登录流程（Login）：

1. 登录挑战（Login Challenge） ：在线服务挑战用户，要求使用之前注册的设备登录，该设备符合服务的接受政策。
2. 用户解锁认证器（User Approval） ：用户使用与注册时相同的方法解锁FIDO认证器，例如指纹、第二因素设备上的按钮、安全输入的PIN或其他方法。
3. 选择密钥（Key Selected） ：设备使用服务提供的用户名来选择正确的密钥，并签署服务的挑战。
4. 登录响应（Login Response） ：客户端设备将签名后的挑战发送回服务，服务使用存储的公钥验证并登录用户。

‍

‍

UAF（Universal Authentication Framework，通用认证框架）

UAF是FIDO（Fast Identity Online）联盟的一部分，旨在提供一种无需密码的多因素认证方法。

​​

1. UAF Architecture:

   • 展示了FIDO用户设备（FIDO USER DEVICE）和依赖方（RELYING PARTY）之间的交互。
   • FIDO用户设备包括浏览器/应用（BROWSER/APP）、FIDO客户端（FIDO CLIENT）、ASM（Authenticator Specific Module，特定认证器模块）、FIDO认证器（FIDO AUTHENTICATOR）。
   • 依赖方包括网络服务器（WEB SERVER）、FIDO服务器（FIDO SERVER）和FIDO元数据服务（FIDO METADATA SERVICE）。
   • 通过TLS协议和UAF协议进行通信。

2. Secure Communication:

   • 强调了FIDO UAF客户端和FIDO服务器之间必须使用受保护的TLS通道来保护数据通信。

3. UAF Server (FIDO Server) :

   • 描述了UAF服务器的功能，包括实现FIDO UAF协议的服务器端、与依赖方网络服务器交互、管理注册的FIDO UAF认证器与依赖方用户账户的关联、评估用户认证和交易确认响应的有效性。

4. UAF Client:

   • 解释了UAF客户端是处理UAF协议消息的软件实体，与特定的FIDO UAF认证器和设备上的用户代理（如移动应用或浏览器）交互。
   • 提供了两种形式：一种是集成在用户代理中的软件组件，另一种是多个用户代理共享的独立软件。

5. ASM / Authenticator Specific Module:

   • 描述了ASM是与FIDO认证器相关联的软件，提供硬件与FIDO客户端软件之间的统一接口。

‍

‍

十八 Wifi

1. Wi-Fi是构建无线局域网最广泛使用的技术方案

   • 由Wi-Fi联盟提出
   • IEEE 802.11系列国际标准

2. WLAN的参与方

   • AP(Access Point)：无线接入点
   • STA(Station)：工作站，无线终端设备，如手机、平板、笔记本电脑等
   • AS(Authentication Server)：鉴别服务器，完成对于STA的身份鉴别，特定方案中使用

‍

wifi的接入方式

• 基于共享口令的鉴别与接入授权

• 基于用户身份的鉴别与授权

• 专用客户端或网页鉴别

  • 通信链路不加密
  • Open System：任何用户都可接入
  • 无线传输数据无保护

• 基于用户注册方式授权

  • 例如，通过微信账号、短信
  • 使用场景：火车站、酒店、UCAS

‍

Wi-Fi安全标准

• WEP、WPA、WPA2、WPA3：Wi-Fi联盟推出的系列安全协议，WEP、WPA因安全性不足已不再使用.
• WEP缺陷：单向鉴别、共享密钥缺陷、RC4加密算法和CRC-32校验的不足.
• WPA特点：基于IEEE 802.11i标准，采用TKIP+MIC加密和校验，支持WPA-PSK和WPA-802.1X两种身份鉴别方式.
• WPA2特点：采用CCMP加密和MIC校验，安全性更高，兼容WPA设备.
• WPA3特点：引入SAE协议和192-bit安全模式，提供更强的密码保护和前向安全性，但不兼容旧设备.

802.11密钥层次与安全网络

• 密钥类型：成对密钥（Pairwise Key）和组播密钥（Group Key），分别用于AP与STA之间的成对通信和AP广播通信.
• 基于WPA/WPA2的安全网络建立过程：包括IEEE 802.11关联、IEEE 802.1X EAP认证和4-Way Handshake等步骤，协商产生PTK和GTK密钥.
• 802.11管理帧：如Association、Reassociation、Dissassociation、Authentication、Deauthentication、Probe、Beacon等，用于管理控制网络状态.

4-Way Handshake过程

• Message 1：AP生成Anonce并发送给STA，STA生成Snonce并计算PTK.
• Message 2：STA发送SNonce并计算MIC值发送给AP，AP验证MIC并安装PTK.
• Message 3：AP发送加密的GTK和MIC给STA，STA验证MIC并安装PTK和GTK.
• Message 4：STA发送确认包ACK给AP，完成四次握手，建立安全通信.

PMK（成对主密钥）获取方式

• WPA-PSK模式：PMK=PSK，PSK通过PBKDF2算法由passphrase和ssid生成.
• WPA-802.1X模式：PMK为802.1X EAP认证完成后生成的MSK的前32字节，EAP类型包括EAP-TLS、EAP-TTLS、EAP-PEAP等.

Eduroam无线漫游认证服务

• Eduroam概念：为科研院所和学校开发的全球无线漫游认证服务.
• 工作原理：采用分层的RADIUS服务器网络，通过RADIUS代理层次结构将用户身份转发到所属机构进行验证.
• 信任结构：基于RADIUS协议的共享密钥或TLS协议的数字证书指纹建立信任关系.

KRACK Attack（密钥重载攻击）

• 攻击原理：攻击4-way handshake，导致nonce重用，进而重用密钥流解密数据，或使客户端使用全零加密密钥.
• 攻击过程：MITM阻塞客户端对消息3的回复，导致AP重传消息3，客户端重装PTK并重置nonce.
• 缓解方法：STA在接收到重传的Msg3时，应答Msg4但不重装PTK，及时更新设备补丁.

WPA3新特性与安全问题

• WPA3-SAE：采用SAE协议，通过Commit Exchange和Confirm Exchange派生PMK，缓解字典攻击和提供前向安全.
• WPA3安全问题：存在降级攻击、组降级攻击、基于cache和时间的侧信道攻击等，需进一步优化和改进.

‍

十九 多种类型的身份鉴别机制

身份鉴别技术分类

• What you know：口令（字符型口令、非字符型口令）、基于图片选择的口令认证、基于图像点击的口令认证等.
• What you have：USB Key、Token（动态口令）、手机验证（手机验证码、手机APP验证）、门禁卡/RFID标签等.
• What you are：生物信息特征（指纹识别、人脸识别、声纹识别、虹膜识别等）、基于用户行为的身份鉴别（如键盘敲击模式）.
• Mixed：多因素身份鉴别（如Password+动态口令、Password+USBKey、Password+生物特征等）.

多因素身份鉴别

• 攻击者必须同时攻击多种机制才能成功，大大降低了攻击成功的概率.
• 常见组合：Password+动态口令、Password+USBKey、Password+生物特征等.
• 注意USB Key+PIN不是多因素鉴别，PIN用于访问USBKey中存储的私钥，而非验证用户身份.

紧急身份鉴别

• 不可用性分析：多因素鉴别提高了安全性，但也增加了“不可用”的可能性，如忘记口令、丢失Token等.

• Emergency Authentication要求：其安全性不能低于通常情况下的鉴别机制，否则攻击者会直接利用它来进入系统.

• 常见紧急鉴别方式：

  • Email：存在传输无加密、易被窃听等问题，安全性较低.
  • 安全提问：答案容易被猜测，信息熵有限，安全性有限.
  • 人工台Help Desk：投入大、响应慢或安全性有限，管理员操作前需与用户进行人工方式的鉴别.

Somebody you know（第四因素身份鉴别）

• 基本想法：当用户无法进行正常鉴别时，由其认识的合法用户（Helper）帮助完成鉴别.
• 安全要求：不泄露秘密信息，鉴别过程的安全强度不低于普通的鉴别过程.
• 过程：用户Alice联系Helper Harry，Harry鉴别Alice后登录系统，Server检查Harry与Alice的关系并产生vouchcode，Harry将vouchcode告诉Alice，Alice输入vouchcode和PIN通过鉴别.
• 安全性讨论：攻击者假冒Alice或Helper的成功概率没有降低，但Helper发起攻击时，攻击难度下降为猜测PIN的难度，因此Helper应是可靠的用户.
• Helper集合设定：用户应事先设定好自己的Helper集合，选择有能力鉴别自己的可靠用户.
• 可能面临的社会工程攻击：Helper与用户之间的关系、PIN问题、依赖于vouchcode等.

‍

零信任架构（ZTA）

• 定义：提供了一组概念、思想和组件关系，旨在消除在信息系统和服务中执行正确访问决策时的不确定性.

• 基本原则：

  • 所有数据源和计算服务被视为资源.
  • 所有通信都要以安全方式进行，网络位置不再预示着可信.
  • 访问企业资源时，基于每个连接进行授权，对资源A的访问授权不能用来访问资源B.
  • 对资源的访问由策略决定，应用最小特权原则.
  • 企业确保其所有系统都处于最安全的状态，监视系统则确保它们保持在最安全的状态.
  • 用户身份验证是动态的，在允许访问之前必须严格执行.

• 网络假设：

  • 企业的专用网络是不可靠的，网络上的设备可能并不由企业所拥有或配置，没有任何一个设备本身是可信的.
  • 非企业拥有的网络基础设施上可能有企业资源，远程企业用户不能信任本地网络连接.

• 逻辑组件：

  • Policy Decision Point (PDP)：策略决策点，包括Policy Engine (PE)和Policy Administrator (PA).
  • Policy Enforcement Point (PEP)：策略执行点，用于建立、监视、终止主体和企业资源之间的连接.

• 抽象部署架构：包括Device Agent/Gateway-Based Deployment、Microperimeter-Based Deployment、Resource Portal-Based Deployment、System Application Sandboxing等演变模型.