Authentication II
Authentication II
Challenge-Response
产生的原因：中间人也许会复制一份通信的内容，比如密码 Hash 值，以便自己在伪装成 Client 在以后使用。
Replay Attack
重放攻击（Replay Attack）是一种网络攻击，攻击者在这种攻击中截获合法用户之间的通信数据，并在稍后的时间里重新发送这些数据，以欺骗接收方。
这可能导致接收方将攻击者误认为是合法用户，从而允许攻击者获得未授权的访问权限或执行非法操作。
挑战（Challenge）是一种用于防止重放攻击的方法。挑战的核心思想是在身份验证过程中引入随机性。
- 当接收方（如 Bob）收到来自发送方（如 Alice）的身份验证请求时，他会生成一个随机数或字符串作为挑战。
- 发送方需要对这个挑战进行响应，例如对其进行加密或签名。
- 接收方会验证响应是否合法。
以下是挑战如何阻止重放攻击的原因：
- 随机性：由于挑战是随机生成的，每次身份验证过程都将产生不同的挑战。这使得攻击者无法预测下一次身份验证过程中的挑战。
- 时效性：挑战通常具有时效性。接收方会为挑战设定一个有效期，超过有效期的挑战将被视为无效。这意味着攻击者即使截获了之前的挑战和响应，也无法在稍后的时间里重放这些数据，因为它们已经过期。
- 一次性：挑战在每次身份验证过程中都是唯一的。一旦接收方验证了发送方的响应，该挑战将不再使用。这使得攻击者无法通过重放之前的挑战和响应来绕过身份验证。
因此，通过使用挑战，可以增加身份验证过程的随机性和时效性，从而防止重放攻击。这种方法要求通信双方在每次身份验证过程中都生成新的挑战和响应，以确保安全性。
Potential Problem
中间人攻击（Man-in-the-middle attack）：攻击者可以在双方之间截取挑战和响应，然后伪装成受信任的一方进行通信。为了防止此类攻击，需要使用额外的安全措施，如 SSL/TLS 加密。
Lamport’s Hash
Lamport's Hash，也被称为 S/Key，是一种一次性密码（One-Time Password, OTP）身份验证方案。
潜在问题:
- 不支持多设备：Lamport's Hash（S/Key）不适用于多设备同步登录的场景，因为不同设备之间需要同步哈希链的状态。
- 有限的使用次数：由于每次登录都消耗一个哈希链中的元素，因此用户只能登录 N 次。在哈希链耗尽之后，需要重新生成和存储一个新的哈希链。
- 初始密码泄露：如果用户在生成哈希链时使用的初始密码被泄露，攻击者可以计算整个哈希链，从而绕过身份验证。
- 用户侧存储：用户需要在本地存储哈希链，以便在每次登录时提供对应的哈希值。这可能导致存储管理和安全性问题。
注意
哈希函数的选择应具有抗碰撞性和单向性，例如 SHA-256。
Authentication Protocols
身份验证协议是两方之间的消息交换，以便至少对其中一方进行身份验证
Encryption-with-Password
这是一个基于 Encryption-with-Password（对称加密）的简单身份验证过程的演示。在这个例子中，Alice 和 Bob 都共享一个低强度的密码，他们使用这个密码生成一个共享密钥 W，其中 f(pwd) 表示从密码中派生密钥的函数。接下来，他们通过以下步骤进行身份验证：
- 首先，Alice 和 Bob 通过某种方式（可能是线下或安全通道）共享一个弱密码，他们使用函数 f(pwd) 从这个密码生成密钥 W。这个密钥将用于加密和解密数据。
- Alice 向 Bob 发送一个包含自己名字的明文消息 "Alice"，告诉 Bob 她希望与他建立安全通信。
- 接收到 Alice 的请求后，Bob 生成一个随机数作为挑战（challenge）R，并将其发送给 Alice。挑战通常是一个随机生成的数值或字符串，用于确保身份验证过程具有一定的随机性，防止重放攻击。
- Alice 收到挑战 R 后，使用密钥 W 和对称加密算法（如 AES）对 R 进行加密，将加密后的数据 Enc_w(R) 发送回 Bob。
- Bob 收到加密后的数据 Enc_w(R) 后，也使用密钥 W 对其进行解密。如果解密后的结果与他最初发送的挑战 R 相匹配，那么 Bob 可以确认 Alice 知道共享密码，从而验证了 Alice 的身份。
Encryption-with-Password + PKC
这是一个基于 Encryption-with-Password（对称加密）和公钥加密（PKC，Public Key Cryptography）的混合身份验证过程的演示。在这个例子中，Alice 和 Bob 都共享一个低强度的密码，他们使用这个密码生成一个共享密钥 W，其中 f(pwd) 表示从密码中派生密钥的函数。接下来，他们通过以下步骤进行身份验证：
- 首先，Alice 和 Bob 通过某种方式（可能是线下或安全通道）共享一个弱密码，他们使用函数 f(pwd) 从这个密码生成密钥 W。这个密钥将用于加密和解密数据。
- Alice 向 Bob 发送一个包含自己名字的明文消息 "Alice" 和她的公钥加密密钥（PKE，Public Key Encryption）。这表明 Alice 希望与 Bob 建立安全通信，并提供了她的公钥，以便 Bob 可以使用公钥加密技术与她通信。
- 接收到 Alice 的请求后，Bob 生成一个随机数作为挑战（challenge）R，并使用 Alice 提供的公钥加密密钥 PKE 对挑战 R 进行加密，将加密后的挑战 PKE(R) 发送给 Alice。
- Alice 收到加密后的挑战 PKE(R) 后，使用她的私钥解密得到原始的挑战 R。然后，Alice 使用密钥 W 和对称加密算法（如 AES）对 R 进行加密，将加密后的数据 Enc_w(R) 发送回 Bob。
- Bob 收到加密后的数据 Enc_w(R) 后，也使用密钥 W 对其进行解密。如果解密后的结果与他最初发送的挑战 R 相匹配，那么 Bob 可以确认 Alice 知道共享密码，并且持有匹配的私钥，从而验证了 Alice 的身份。
这个例子展示了一个基于对称加密和公钥加密技术的混合身份验证过程。这种方法结合了两种加密技术的优点，既可以防止密码在网络上明文传输，又可以确保通信双方使用正确的密钥进行加密和解密。
An Improved Version
这是一个改进版本的基于 Encryption-with-Password（对称加密）和公钥加密（PKC，Public Key Cryptography）的混合身份验证过程的演示。在这个例子中，Alice 和 Bob 都共享一个低强度的密码，他们使用这个密码生成一个共享密钥 W，其中 f(pwd) 表示从密码中派生密钥的函数。接下来，他们通过以下步骤进行身份验证：
- 首先，Alice 和 Bob 通过某种方式（可能是线下或安全通道）共享一个弱密码，他们使用函数 f(pwd) 从这个密码生成密钥 W。这个密钥将用于加密和解密数据。
- Alice 向 Bob 发送一个包含自己名字的明文消息 "Alice"，并使用密钥 W 对自己的公钥加密密钥（PKE，Public Key Encryption）进行加密，将加密后的公钥 Enc_w(PKE) 发送给 Bob。这样，只有知道共享密码的 Bob 才能解密 Alice 的公钥。
- 接收到 Alice 的请求后，Bob 使用密钥 W 对 Enc_w(PKE) 进行解密，得到 Alice 的公钥加密密钥 PKE。然后，Bob 生成一个随机数作为挑战（challenge）R，并使用 Alice 的公钥加密密钥 PKE 对挑战 R 进行加密。接着，Bob 使用密钥 W 对加密后的挑战进行二次加密，将二次加密后的挑战 Enc_w(PKE(R)) 发送给 Alice。
- Alice 收到加密后的挑战 Enc_w(PKE(R)) 后，首先使用密钥 W 解密得到加密后的挑战 PKE(R)。然后，Alice 使用自己的私钥解密 PKE(R)，得到原始挑战 R。最后，Alice 将原始挑战 R 发送回 Bob。
- Bob 收到 Alice 发送回来的挑战 R，并将其与最初发送的挑战进行比较。如果两者相匹配，那么 Bob 可以确认 Alice 知道共享密码，并且持有匹配的私钥，从而验证了 Alice 的身份。
这个改进版本的身份验证过程增强了通信的安全性，因为 Alice 的公钥和挑战都使用共享密钥 W 进行了加密。这可以防止中间人攻击者获取到 Alice 的公钥和挑战，从而增强了身份验证过程的安全性。
Encrypted Key Exchange (EKE)
这是一个基于 Encrypted Key Exchange（EKE）的身份验证和密钥交换过程的演示。EKE 是一种安全协议，它结合了密码加密和公钥加密技术，以实现安全的身份验证和密钥交换。在这个例子中，Alice 和 Bob 都共享一个弱密码，他们使用这个密码生成一个共享密钥 W。接下来，他们通过以下步骤进行身份验证和密钥交换：
- Alice 向 Bob 发送一个包含自己名字的明文消息 "Alice"，并使用密钥 W 对自己的公钥加密密钥（PKE，Public Key Encryption）进行加密，将加密后的公钥 Enc_w(PKE) 发送给 Bob。这样，只有知道共享密码的 Bob 才能解密 Alice 的公钥。
- Bob 使用密钥 W 解密收到的 Enc_w(PKE)，得到 Alice 的公钥加密密钥 PKE。然后，Bob 生成一个新的会话密钥 K，并使用 Alice 的公钥 PKE 对其进行加密。接着，Bob 使用密钥 W 对加密后的会话密钥 PKE({K}) 进行二次加密，将二次加密后的数据 Enc_w(PKE({K})) 发送给 Alice。
- Alice 收到 Enc_w(PKE({K})) 后，首先使用密钥 W 进行解密，得到加密后的会话密钥 PKE({K})。然后，Alice 使用自己的私钥解密 PKE({K})，得到会话密钥 K。Alice 生成一个随机数 R_A，并使用会话密钥 K 对 R_A 进行加密，将加密后的数据 Enc_k(R_A) 发送给 Bob。
- Bob 使用会话密钥 K 解密收到的 Enc_k(R_A)，得到原始的随机数 R_A。然后，Bob 生成自己的随机数 R_B，并使用会话密钥 K 对 R_A 和 R_B 进行加密，将加密后的数据 Enc_k(R_A, R_B) 发送给 Alice。
- Alice 使用会话密钥 K 解密收到的 Enc_k(R_A, R_B)，得到原始的随机数 R_A 和 R_B。Alice 确认收到的 R_A 与自己最初发送的 R_A 相同。然后，Alice 使用会话密钥 K 对 R_B 进行加密，将加密后的数据 Enc_k(R_B) 发送回 Bob。
- Bob 使用会话密钥 K 解密收到的 Enc_k(R_B)，并将其与自己最初生成的 R_B 进行比较。如果两者相匹配，那么 Bob 可以确认 Alice 知道共享密码，并且持有匹配的私钥，从而验证了 Alice 的身份。
这个 EKE 的示例展示了如何通过结合密码加密和公钥加密技术实现安全的身份验证和密钥交换。在这个过程中，Alice 和 Bob 使用弱密码生成共享密钥 W，并通过加密和解密各种消息来验证彼此的身份。同时，他们通过安全地交换会话密钥 K，实现了安全的密钥交换。
EKE 协议的优势在于，它能有效抵抗中间人攻击、字典攻击和重放攻击。这是因为公钥和会话密钥都使用共享密钥 W 进行了加密，而且双方交换的挑战（随机数 R_A 和 R_B）确保了每次通信过程都是唯一的。这种方法结合了对称加密和非对称加密的优势，实现了安全的身份验证和密钥交换。
尽管 EKE 提供了较高的安全性，但在实际应用中仍需要注意一些潜在的安全风险。例如，密钥生成和管理需要特别关注，以确保密钥的安全和可靠。此外，实现 EKE 协议的密码库和应用程序也需要确保安全和无漏洞。总之，EKE 是一种高效且安全的身份验证和密钥交换协议，但仍需要与其他安全措施结合使用，以确保整体通信的安全。
Strong Password Protocols
EKE 是强密码协议的一个例子
- 防止窃听者「eavesdropper」：没有可用于字典攻击的 明文-密文 对
- 防止假冒「impersonation」：恶意软件「Malice」必须猜出正确的 W 才能在第一个消息流中冒充 Bob。这样就实现了相互认证。
- Bob 必须知道 W 才能正确加密 PKE(K)
- Alice 必须知道 W（和她的私钥）才能恢复 K 并使用 K 正确加密 RA
注意
这里说的强密码不是表面含义，而是一个能满足上述安全要求的认证协议。
Master Password
与其记住几十个密码，然后选择非常简单和弱的密码，或者重复使用密码，我们可以使用主密码。
The idea：您将主密码设置为一个好密码，应用适当的规则来维护其安全性，并且永远不要记住从中派生出的任何其他密码
Single Sign-On
单点登录 (SSO) 旨在减少身份验证信息量，换句话说，就是减少需要记住的密码数量。集中式认证产生一个 "令牌"，可用于认证访问独立的系统。
Google Identity uses OAuth protocol：授权框架使第三方应用程序能够代表资源所有者获得对HTTP服务的有限访问权，这可以是
- 通过协调资源所有者和HTTP服务之间的批准互动，或
- 通过允许第三方应用程序以自己的名义获得访问权
过程如下
- 当你的应用程序将浏览器重定向到一个谷歌的URL时，授权顺序就开始了；
- URL包括查询参数，表明所请求的访问类型。
- Google 处理用户身份验证、会话选择和用户同意
- 结果是一个 authorization code，应用程序可以用它来交换 access token
- The application uses the access token to access a Google API
Digital Certificate
「证书颁发机构 (CA) 和数字证书」
- 认证机构（CA）是一个向所有参与者（包括自己）颁发数字证书的实体。
- 数字证书是一个数据对象，它将一组相关信息绑定在一起
- 这组信息包括证书所有者的身份和他的公开密钥
- CA通过对数据进行（数字）签名来证明约束
- 一个数字证书有以下组成部分：
- 所有者ID 和公钥：分别是标识符（名称）和证书所有者的公开密钥。
- 其他信息：签发CA的名称、证书序列号、所有者的电子邮件地址和其他相关信息（如她的组织、地址等）。
- 签名：CA的数字签名 -> CA 使用其私钥对证书中的其他数据进行签名。
提示
- 由公钥加密的文字可以用私钥解密
- 用私钥加密的内容可以用公钥解密
Trusting CA
- 通过签署该证书，CA
- 证明证书中包含的信息的有效性。具体来说，它证明证书中包含的公开密钥属于由所有者-ID识别的参与者。
- 确保数据的完整性得到维护（通过签名）。
- 我们对CA的信任是基于它的
- 有一个明确的和严格遵守的程序来验证证书中所有者的身份和相关信息；
- 使用一个安全的系统来履行其职能；
- 对其责任有足够的负责程度
- 足够知名
CA公布了其认证业务声明（CPS），其中包括政策和责任
Digital Certificate Standard
为了促进互操作性，ITU-T（一个联合国标准组织）定义了X.509标准，其中包括数字证书的格式。
X.509证书中的主要字段是：
- 主体（所有者）的身份
- 认证的有效时间（开始和到期日期）
- 主体的公钥（以及使用的公钥算法和密钥长度）；
- 签发CA的名称；
- 证书的序列号（由发证CA分配）；
- 该证书上的CA的签名（以及使用的签名算法）
Certificate Revocation
在某些情况下，证书必须在其有效期前失效。
例如，当一个雇员离开一个组织，或者当参与者的私钥被破坏时。
证书吊销列表（CRL）
- CA应定期或根据需要发布CRL（由CA签署），列出已被废止的证书的序列号。
- 使用证书的参与者应检查CA的最新CRL，以确定证书是否仍然有效。
Public-Key Infrastructure
公钥基础设施（PKI）包括安全使用公钥加密技术所需的所有部分
- 密钥生成和管理
- 证书颁发机构、数字证书
- 证书吊销列表（CRL）
为什么数字证书还没有普及？
- 数字证书的概念对一般人来说很复杂
- 使用/存储证书及其私钥不方便。
- 大多数在线服务通常不需要数字证书
- 选择其他身份验证方式，例如密码和单点登录