安全基础：数字信封、数字签名、数字证书（加签&验签）

总览

• 数字签名的作用：完整性  没有被篡改；不可抵赖性，用自己私钥 签名的明文（签名是独有的 私自的），只有用自己的公钥才能解密。
• 数字信封的作用：用接收方的公钥加密形成信封（信封的内容是公开的）；保证数据传输的真实性和不可窥探性（确保客户端随机生成的对称秘钥 加密安全传输）

 

 

在互联网安全通信中，“非对称加密和数字签名”以及“数字信封和对称密钥”都是非常常见的安全技术，它们各自在保护数据的机密性、完整性和认证性方面发挥着关键作用，但是否能称为“最常见”的，可能需要根据不同的应用场景来判断。

1. 非对称加密和数字签名：

   • 非对称加密使用一对公钥和私钥，其中公钥用于加密信息，私钥用于解密。这种方式确保了信息只能被拥有对应私钥的接收者解密，保护了信息的机密性。
   • 数字签名则利用私钥对消息进行签名，任何持有公钥的人可以验证该签名以确认信息的来源和完整性，增强了信息的不可否认性和真实性。
   • 这一组合广泛应用于HTTPS、SSL/TLS协议、电子邮件加密（如PGP）、软件签名等领域，确保了网络通信的安全性。

2. 数字信封和对称密钥：

   • 数字信封是一种结合了非对称加密和对称密钥加密的方法。首先，使用接收者的公钥加密一个随机生成的对称密钥，然后用这个对称密钥加密实际的数据内容。这样，只有拥有私钥的接收者才能打开“信封”，获取到对称密钥并进一步解密数据，既保证了数据的机密性，又解决了非对称加密处理大量数据效率低的问题。
     • 混合加密系统中，即首先使用非对称加密来安全地交换对称密钥，然后利用对称密钥进行高效的数据加密和解密

     • 该场景（混合加密系统）是对称密钥使用的一个非常典型且广泛的应用实例。在混合加密系统（也称为公钥基础设施PKI和对称密钥加密的结合）中，非对称加密算法（如RSA、ECC等）因其计算效率相对较低但能提供密钥交换的安全性而被用于安全地传输对称密钥。一旦对称密钥被安全地交换，双方就可以使用这个对称密钥进行快速的数据加密和解密，因为对称加密算法（如AES、DES等）在处理大量数据时效率更高。

       这样的混合模式结合了两种加密方法的优点：

       1. 非对称加密确保了密钥交换的安全性，解决了密钥分发的问题，即如何在不安全的通道上安全地共享密钥。
       2. 对称加密则因为其加密和解密速度快，适合于实际数据的加解密过程，提高了数据传输或存储的效率。

       因此，您提到的确实是对称密钥一个非常常见且重要的应用场景，在很多现代安全通信协议和系统中都有应用，比如HTTPS、SSL/TLS协议、IPSec以及各种端到端加密通讯应用中。

   • 对称密钥加密因其加解密速度快，常用于大量数据的快速加密，如文件加密、数据库加密等场景。
   • 这种方式在云存储、大数据传输、即时通讯等需要高效加密大量数据的场景中非常常见。

综上所述，这两种技术都是现代互联网安全通信的基础，广泛应用于各种场景中，可以说是极为重要且常见的安全措施。不过，是否能冠以“最常见”还需依据具体统计数据和应用领域来定，但它们的重要性无可置疑。

非对称加密和数字签名（加签和验签）

如果需要保护报文的机密性，通常会在加签之前先对原始报文进行加密。也就是说，先加密（使用接收方的公钥），再对加密后的密文进行哈希并加签。这样，接收方需要先用自己的私钥解密，再验证签名，以确保内容的完整性和来源的真实性——请详细描述一下这个case的具体流程

 

在这个场景中，我们使用非对称加密和数字签名技术来确保报文的机密性、完整性和来源的真实性。具体流程如下：

1. 发送方准备报文

• 原始报文准备：发送方首先准备好需要发送的信息，即原始报文。

2. 加密报文

• 使用接收方公钥加密：发送方查找接收方的公钥（这通常通过安全的渠道事先获取或通过公钥基础设施PKI获得）。使用接收方的公钥，发送方对原始报文进行加密。这一过程保证了只有拥有相应私钥的接收方才能解密信息，确保了报文的机密性。

3. 对加密后密文进行哈希并加签

• 计算哈希值：在加密之后，发送方对加密后的密文计算一个哈希值。这个哈希值是对加密文本的数字指纹，可以确保数据的完整性。

• 使用发送方私钥加签：然后，发送方使用自己的私钥 对计算出的哈希值进行数字签名。这个步骤验证了报文的来源和完整性，因为只有拥有对应私钥的发送方才可能生成有效的签名，且任何对密文的篡改都会导致接收方验证签名时失败。

4. 发送报文及签名

• 打包发送：发送方将加密后的密文和数字签名一起发送给接收方。

5. 接收方处理报文

• 使用私钥解密：接收方首先使用自己的私钥（与发送方用于加密的公钥配对）解密接收到的密文，恢复出原始报文的加密形式。

• 验证签名

  • 计算接收到的密文的哈希值：接收方对接收到的已解密的密文再次计算哈希值。

  • 使用发送方公钥验证签名：接着，接收方使用发送方的公钥（通常也是通过安全渠道事先获得）来验证随报文一同收到的数字签名。这包括检查签名是否与根据接收到的密文重新计算的哈希值匹配。如果匹配，说明报文在传输过程中没有被篡改，并且确实来自拥有对应私钥的发送方。

6. 解析原始报文

• 如果上述所有验证步骤都成功，接收方就可以确信报文的机密性、完整性和来源的真实性，进而安全地解析和使用原始报文中的信息。

整个过程结合了非对称加密的保密性和数字签名的认证性，为数据通信提供了高级别的安全保障。

 

https://cloud.tencent.com/developer/article/1665989

假设现在有A公司，要接入C公司的转账系统。在一开始呢，C公司把自己的公钥寄给A公司，自己收藏好私钥；A把自己的公钥寄给C公司，自己藏好私钥。

• A公司这边的商户，发起转账时，A公司先用C公司的公钥，对请求报文加密；
• A公司：「加签」：
  • 用Hash函数（如MD5）把加密的报文生成报文摘要，
  • 然后用A的私钥对这个摘要进行加密，就得到这个报文对应的数字签名（A的私钥加密 得到A的签名）。
  • 通常来说呢，请求方会把「数字签名和加密的报文」一并发送给接收方C公司。
• C公司：接收方C拿到加密的报文和数字签名后
  • 用C的公钥对 「加密的报文」进行解密得到原始报文
  • 用「同一个Hash函数」从报文中生成摘要Z1。另外，用对方提供的公钥对数字签名进行解密，得到摘要Z2，对比Z1和Z2是否相同，就可以得知报文有没有被篡改过。

• C公司收到报文后，对数字签名 拿A的公钥进行验签（解密）得到摘要，如果原始报文的摘要和数字签名的摘要内容不一致，那就是报文被篡改啦
• 公司C公钥与私钥是用来加密与加密的，「加签与验签是用来证明身份」，以免被篡改的。

 

 Web认证

Web认证机制的一个演变过程，从基本的验证方法到更加安全和高效的认证技术。下面是对您概述的三个阶段的简要总结和补充：

阶段一：基础验证

在这个初始阶段，每次用户与服务器交互时（通常是每个HTTP请求），用户凭据（如用户名和密码）都会被发送到服务器进行验证。这种方法简单直接，但确实存在几个问题：

• 安全性问题：频繁地在网络中传输敏感信息增加了信息被截获的风险。
• 效率低下：服务器需要为每次请求验证用户身份，这对资源是一种浪费。

阶段二：Cookie-Based Session认证

为了解决上述问题，引入了Session机制：

• 用户登录后，服务器创建一个Session对象存储用户信息，并生成一个唯一的Session ID。
• 这个Session ID通过Cookie存储在用户的浏览器中。
• 之后的每个请求，浏览器都会自动附带这个Session ID，服务器用它来查找Session数据，从而识别用户身份和权限。
  这种方法提高了效率，因为验证信息只需在登录时传递一次。但也有其局限性，包括：
• 扩展性问题：由于Session数据存储在服务器端，当用户量增大时，可能会导致服务器压力增大，且跨域访问变得复杂。
• 安全性考虑：虽然比每次都传输密码安全，但如果Cookie被盗，仍可能导致会话劫持。

阶段三：Token-Based认证

Token技术进一步提升了认证系统的安全性和可扩展性：

• 服务器在用户验证成功后，生成一个JWT（JSON Web Token）或其他类型的Token，这个Token包含了用户的身份信息，并通过服务器的私钥进行签名。
• Token被发送给客户端（通常也是通过Cookie或者更常见的HTTP Authorization Header），客户端在后续请求中携带此Token。
• 服务器无需存储Token对应的信息，仅需验证Token的签名（服务器可以通过公钥验证Token的签名，确认其真实性，防止Token被恶意篡改或伪造）和过期时间即可确认用户身份，这使得系统更加可扩展且减轻了服务器存储负担。
• Token的使用还支持跨域认证，提高了应用的灵活性。

"阶段三：Token-Based认证" 和 "阶段二：Cookie-Based Session认证" 是两种不同的用户认证方式，在Web应用中被广泛使用。理解它们的安全性差异，需要从几个方面进行比较：

1. 数据存储位置：

   • Cookie-Based Session认证：用户会话信息（session ID）通常存储在客户端的Cookie中，而实际的会话数据则存储在服务器端。这意味着每次请求时，都会携带这个标识回服务器查询对应的会话信息。
   • Token-Based认证：采用的是无状态设计，认证信息（包括用户身份、权限等）被打包进一个Token（如JWT），这个Token既可以在客户端存储（如LocalStorage或SessionStorage），也可以在某些场景下通过URL、Authorization header等方式传递。关键在于，Token包含了验证用户所需的所有信息。

2. 传输安全性：

   • Cookie-Based：虽然可以设置Secure标志确保HTTPS下传输，以及HttpOnly防止JavaScript访问减少XSS攻击风险，但Cookie仍可能遭受中间人攻击（如果未使用HTTPS）或跨站请求伪造（CSRF）攻击。
   • Token-Based：Token可以设计为在传输过程中使用HTTPS加密，减少中间人攻击的风险。同时，由于不依赖Cookie，天然具有对CSRF更好的防护能力，但需要应用程序实现额外的逻辑来防范重放攻击。

3. 扩展性和可伸缩性：

   • Cookie-Based：因为会话数据存储在服务器端，随着用户量增加，会增加服务器的存储和查询负担，影响系统的扩展性和伸缩性。
   • Token-Based：由于Token是自包含的，服务器无需存储会话状态，这使得系统更加容易扩展和分布部署，提升了系统的可伸缩性。

4. 安全性控制：

   • Cookie-Based：服务器难以控制或撤销已发出的Session ID，一旦泄露，可能需要用户重新登录或服务器端手动清理相关会话。
   • Token-Based：尤其是使用JWT时，可以通过设置Token的有效期、使用刷新Token机制等方法增强安全性，并且在Token被泄露时，理论上可以通过撤销相关的密钥来使Token失效（尽管JWT本身不支持撤销，但可以通过其他机制间接实现）。

综上所述，Token-Based认证相比Cookie-Based Session认证，在减少服务器存储负担、提高扩展性、减少特定类型的安全威胁（如CSRF）方面表现更优。当然，每种方式都有其适用场景，选择哪种认证方式还需根据具体的应用需求和安全考量来决定。

 

用户会话信息（Session ID）存储在客户端Cookie中被认为不够安全，而Token存储在客户端的LocalStorage或SessionStorage中相对更安全的原因有以下几点：

1. 跨站脚本攻击（XSS）的防护：

   • Cookie可以被JavaScript脚本访问（除非设置了HttpOnly属性），这意味着如果网站存在XSS漏洞，攻击者可以通过恶意脚本轻易地获取到Cookie中的Session ID，进而冒充用户进行操作。
   • 相比之下，LocalStorage和SessionStorage虽然也能通过JavaScript访问，但它们不会随HTTP请求自动发送到服务器，因此减少了XSS攻击直接利用存储的信息进行未授权访问的风险。不过，XSS攻击者仍能在同一源下访问LocalStorage和SessionStorage，所以开发人员需要采取其他措施防范XSS，如内容安全策略（CSP）。

2. 跨站请求伪造（CSRF）的防护：

   • 由于浏览器会自动携带Cookie发起请求，即使在第三方站点上，如果攻击者诱导用户点击恶意链接，可能会触发带着有效Session ID的请求到目标站点，造成CSRF攻击。
   • 使用Token并在API请求中通过HTTP头部（如Authorization）传递，而不是依赖Cookie，可以更有效地防止CSRF，因为这要求攻击者不仅要知道Token，还要有能力在非浏览器环境下构造带自定义头部的请求。

3. 控制粒度和可扩展性：

   • Token通常包含了用户的身份验证信息，可以设计为JWT（JSON Web Tokens）形式，内含签发时间、过期时间等，服务器无需查询数据库即可验证其有效性，提高了效率和可扩展性。
   • Token还可以更容易地实现无状态服务，服务器不需要维护Session存储，每个请求都携带了必要的认证信息，这对于分布式系统尤其有利。

4. 透明性和可撤销性：

   • 如果Session ID泄露，很难立即察觉或撤销，可能需要用户登出或服务器端干预。
   • 而Token机制支持即时吊销和更新，例如使用刷新Token的机制，一旦发现Token泄露，可以通过拒绝旧Token来迅速降低风险。

尽管如此，将Token存储在LocalStorage或SessionStorage中也并非绝对安全，开发者仍需结合其他安全实践，如使用HTTPS、实施严格的输入验证、采用内容安全策略等，以构建全面的安全防御体系。

总的来说，这三个阶段反映了Web认证技术从简单到复杂、从低效到高效、从不那么安全到相对安全的发展历程。每一步进化都是为了更好地平衡安全、性能和用户体验之间的关系。

对称加密和数字信封

数字信封和对称密钥是加密技术中两种非常重要的概念，常用于保证数据的安全传输。下面我将通过一个具体的例子来说明它们的使用场景及流程。

场景描述

假设Alice想要通过不安全的网络向Bob发送一条机密信息。为了确保信息的安全性，他们决定采用数字信封和对称密钥加密技术。

具体流程

1. 对称密钥生成

• 步骤1: Alice首先使用一个随机数生成器生成一个对称密钥（例如AES密钥）。这个对称密钥将用于加密原始消息。对称密钥的特点是加密和解密使用的是同一个密钥。

2. 消息加密

• 步骤2: Alice使用刚才生成的对称密钥对她的机密信息进行加密。加密后的信息只有拥有相同对称密钥的人才能解密。

3. 数字信封创建

• 步骤3: 为了安全地将这个对称密钥传递给Bob，Alice需要对对称密钥本身进行保护。她选择使用Bob的公钥（假设之前已通过安全渠道获得）来加密对称密钥。这一步骤形成的加密后的对称密钥加上加密后的消息就构成了“数字信封”。这样，即使中间人截获了信息，没有Bob的私钥也无法获取到对称密钥，保证了密钥的安全传输。

4. 发送信息

• 步骤4: Alice将加密后的消息（用对称密钥加密的结果）和数字信封（用Bob的公钥加密的对称密钥）一起通过不安全的网络发送给Bob。

5. 解密信息

• 步骤5: Bob接收到信息后，首先使用自己的私钥来解密数字信封，从而得到Alice用来加密消息的对称密钥。
• 步骤6: 接着，Bob使用这个对称密钥来解密加密的消息，恢复出原始的机密信息。

总结

通过上述流程，数字信封结合对称密钥加密技术，既保证了消息内容的安全传输（通过对称密钥加密），又解决了密钥分发的安全问题（通过非对称加密保护对称密钥），是一种在实际应用中广泛采用的混合加密方案。

数字证书

数字证书是一种用于验证公钥持有者身份的电子文档，它在非对称加密、数字签名、数字信封和对称密钥的应用场景中扮演着核心角色，确保了数据的安全传输、来源的可信度以及信息的机密性。下面分别说明其在这两个场景中的作用：

非对称加密和数字签名

1. 身份验证：在非对称加密中，发送方使用接收方的公钥对信息进行加密，以确保只有拥有对应私钥的接收方能解密。但如何确信公钥确实是接收方的呢？这就需要数字证书。数字证书由可信赖的第三方机构（称为证书权威机构，CA）签发，包含了公钥及公钥持有者的身份信息，并且经过CA的数字签名，任何收到该证书的用户都可以通过验证CA的签名来确认公钥的真实性及其与声明身份的绑定关系。

2. 数字签名：发送方使用自己的私钥对消息摘要（即消息的哈希值）进行加密生成数字签名，接收方则用发送方的公钥（通常通过发送方的数字证书获得）来验证签名，确保消息未被篡改且确实来自声称的发送方。这里，数字证书确保了公钥的真实性和发送方的身份认证。

数字信封和对称密钥

1. 安全传输对称密钥：在数字信封技术中，首先使用接收方的公钥（通过数字证书获取）加密对称密钥，然后将加密后的对称密钥和用此对称密钥加密的数据一起发送。由于接收方的公钥是通过其数字证书得到的，这保证了即便在公开渠道传递加密的对称密钥，也只有拥有相应私钥的接收方能够解密并访问到实际的对称密钥，进而解密数据，确保了对称密钥分发过程的安全性。

2. 增强信任：数字证书在数字信封的应用中不仅提供了技术上的安全保障，还增加了通信双方的信任度。因为每个证书都经过了CA的严格验证，确保了参与通信的双方或多方的身份是可信的，这对于商业交易、政府通信等高安全需求的场景尤为重要。

综上所述，数字证书在这些场景中起到了验证身份、确保数据完整性、保护通信安全的关键作用，是现代信息安全体系中不可或缺的一环。

"数字证书"的实例：HTTPS协议

演化理解1

演化理解2

 

 

流程

下面，我们看一个应用"数字证书"的实例：https协议。这个协议主要用于网页加密。

1.

首先，客户端向服务器发出加密请求（如上图的：https://www.baidu.com）。

2.

服务器响应请求，会携带数字证书（包含  服务器的公钥A），一起发送给客户端。

3.

客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。

PS：任何正版操作系统都会将所有主流CA机构的公钥内置到操作系统当中，所以我们不用额外获取，解密时只需遍历系统中所有内置的CA机构的公钥，只要有任何一个公钥能够正常解密出数据，就说明它是合法的

4.

如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。

5.

如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。

6.

数字证书如果是可靠的，客户端就可以使用证书中的服务器公钥A，对信息进行加密（客户端随机生成的对称加密秘钥Key），然后发送给服务器，服务器可以用服务器私钥A对其进行解密，得到对称加密秘钥Key

7.

之后，客户端和服务器之间 就可以通过 对称加密秘钥Key，进行加解密通信

JWT

网站注册时输入邮箱信息，用户需要登录邮箱完成最终的确认，一般会用到JWT技术。

• • 整体内容包括三个部分

  • 头部Header：通信协议（通信包）都会有头部做一些基本内容的描述；如头部约定了算法，你就知道载荷部分用什么算法做接码
  • 载荷Payload：信息主体
  • 签名Signature：核实信息完整性、真实性的机制（如数字签名）

在网站注册过程中使用JWT（JSON Web Token）进行邮箱验证是一种常见的做法。这个过程涉及到几个关键步骤，包括生成JWT、发送验证邮件、用户点击链接完成验证等。下面我将详细解释这些步骤中的技术细节。

1. 用户注册

当用户填写完注册表单并提交后，服务器会收到用户的注册信息，其中包括电子邮件地址。此时，系统不会立即创建一个完全激活的账户，而是准备一个未激活状态的账户记录，并开始处理邮箱验证流程。

2. 生成JWT

• 创建Payload：服务器首先为即将生成的JWT构建payload部分。这部分通常包含一些关于该次验证请求的基本信息，如用户ID、邮箱地址以及过期时间等。例如：

 

{ "userId": "123456", "email": "user@example.com", "exp": 1672531200 // Unix时间戳，表示令牌过期的时间 }

注意exp字段用于设置令牌的有效期限，超过此时间后，该JWT将被视为无效。

• 签名JWT：接下来，使用预设的密钥对上述payload进行签名。这一步骤保证了数据的完整性和来源的真实性。常用的算法有HMAC SHA256或RSA。假设我们使用HMAC SHA256，则最终生成的JWT看起来像这样：

 

  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOiIxMjM0NTYiLCJlbWFpbCI6InVzZXJAZXhhbXBsZS5jb20iLCJleHAiOjE2NzI1MzEyMDB9.5l8kx8yC7tQfDn4pFvLr4e5aWgAq7BdR1PmXhKuT

3. 发送验证邮件

• 将生成的JWT编码为URL安全格式，并将其作为参数附加到特定的URL上，比如https://example.com/verify-email?token=...。然后通过SMTP服务向用户提供的邮箱地址发送一封包含此链接的邮件。
• 邮件内容中应清晰说明这是一个账号激活链接，并鼓励用户尽快访问以完成注册过程。

4. 用户确认

• 用户打开邮件并通过点击链接访问指定网页。浏览器自动将URL中的参数传递给服务器。
• 服务器接收到请求后，解析出JWT，并检查其是否有效（包括但不限于检查签名是否正确、令牌是否已过期等）。如果一切正常，服务器则根据JWT中的信息来查找对应的用户记录，并将其状态更新为“已验证”。

5. 完成注册

一旦用户的邮箱被成功验证，系统就可以认为该用户已经完成了整个注册流程。此时可以允许用户登录系统或者执行其他相关操作。

总结

通过这种方式使用JWT来进行邮箱验证不仅简化了传统基于数据库查询的验证方式，同时也增强了安全性，因为它减少了直接暴露敏感信息的风险。不过需要注意的是，为了确保系统的安全，必须妥善保管好用于签署和验证JWT的密钥。此外，合理设置JWT的有效期也是很重要的，太短可能导致用户体验不佳，而太长则可能增加安全风险。

参考文献：

https://blog.csdn.net/xianzongtanxun/article/details/111960461
http://zh-cjh.com/xinxianquan/2406.html
https://www.51cto.com/article/287971.html
https://www.zhaohuabing.com/post/2020-03-19-pki/

https://segmentfault.com/a/1190000021494676

https://blog.csdn.net/guolin_blog/article/details/104546558