小白入门一文通-安全专题1-加解密、DID、VC&VP验证技术详细解读

随着人工智能的不断发展，涉及各种新型实体或者虚拟Agent接入到网络，但关于Agent身份、能力的定义包括真实性，是首先要解决的问题，本文就介绍了可能涉及的安全基础知识，包括加解密方式、DID原理、VC&VP验证技术，作详细解读，方便大家理解Agent交互的相关理念。

wxjoe201314

1325人浏览 · 2025-07-03 20:17:07

wxjoe201314 · 2025-07-03 20:17:07 发布

系列文章目录

《小白入门一文通》为一个技术专题频道，目的旨在通过尽量入门基础的语言，描述业界的基础理论，方便小白快速上手理解，初步规划：安全、网络、编码等专题，可通过标题快速筛选浏览，希望我们可以一起从小白快速成长为高手！

一、基础知识

1、对称与非对称加密

（1）对称加密：加密解密使用同一个密钥，被黑客拦截不安全
（2）非对称加密：公钥加密，私钥解密。公钥可以公开给别人进行加密，私钥永远在自己手里，非常安全，黑客拦截也没用，因为私钥尚未公开。 著名的RSA加密算法就是用的非对称加密。

简单理解：
对称加密： A和B传输数据，使用同一个密钥，不安全
非对称加密: A和B传输数据， A具有自己的公私钥，B具有自己的公私钥。
(公钥是在公网上公开的，任何人都能看见，私钥自己保留)

典型应用场景举例（混合使用对称与非对称加密来解决的关键问题）：浏览器B与服务器A二者交互用的对称加密的密钥如何在网络中安全传递？

网站服务器A用浏览器B的公钥加密敏感数据（后续二者交互用的对称加密的密钥），发送给浏览器B，浏览器B用自己的私钥解密数据。
（1）先使用非对称加密，B的公钥完全可公开，公网可见，A获取后保留在本地，A用B的公钥加密后续对称加密的密钥X，并发送给B；
（2）B私钥解密后，获取A和B后续对称加密的密钥X；
（3）后续A和B之间直接使用X互传，解决对称加密的密钥X易泄露问题，并提高数据发送的性能

2、公钥与私钥

首先必须明白公钥和私钥的定义和应用场景：本质上公钥和私钥只存在于非对称加密的定义和使用中，如上对称加密只有一个密钥且是通用的，双方都可以用同一个密钥来进行加解密。

（1）明确公钥和私钥在非对称加密中使用的原则：

公钥和私钥在非对称加密体系中也均可参与加解密过程，但其应用场景和目的存在本质差异。私钥的核心作用是 身份绑定（生成数字签名）和 解密原文内容，而不是加密传输（这是公钥的核心作用，也就是 验证身份（读取数字签名）与加密原文内容）

（2）核心原理与功能差异
公钥加密 + 私钥解密（保密性保障）
流程：发送方用接收方的公钥加密数据 → 接收方用自己的私钥解密。
目的：确保数据传输的机密性，仅私钥持有者可解密。
私钥加密 + 公钥解密（身份认证保障）
流程：发送方用自己的私钥加密数据（这里的数据指的是比如原文内容计算得到的sha256值，也叫摘要值，摘要值加密后就是我们常说的数字签名） → 接收方用发送方的公钥解密。
目的：验证数据来源的真实性（数字签名），而非保密数据。
案例：
软件开发者D发布程序更新---D用私钥生成更新包的哈希签名；用户下载后用D的公钥验证签名；
若验证通过，证明更新包未被篡改且来源可信。

PS⚠️ 为何不推荐“私钥加密敏感数据”？
安全风险：公钥是公开的，若用私钥加密敏感数据，任何持有公钥的人均可解密，失去保密意义。也就是开头说的公钥和私钥在非对称加密体系中原则上均可参与加解密过程，但实际应用场景和目的存在本质差异。

公私钥配合的核心优势：
功能公钥作用私钥作用
加密传输加密数据（确保只有私钥持有者可读）解密数据（私钥必须保密）
数字签名验证签名（确保数据来源和完整性）生成签名（签名不可伪造）

总结就记住一个原则：

公钥：公开分发，用于加密数据或验证签名。
私钥：严格保密，用于解密数据或生成签名。

📌 关键结论：
虽然数学上支持双向操作（如私钥加密公钥解密），但实际应用中需遵循功能设计：

加密敏感数据 → 必须用公钥

生成身份签名 → 必须用私钥
错误使用将导致安全机制失效。

（3）为方便理解，整理常用摘要生成、数字证书、数字签名等常用安全概念理解：

a. 加密过程如上图，可以分步骤、分层级实现安全需要，数字签名非必须生成；

b. 收到消息后先用对外发布的公钥解开数字签名（如果数字签名被窃取修改，公钥一定解不开），获取对应的摘要值（md5或者sha值等）和原文内容，接收方先按照之前传递约定好的摘要算法计算原文内容的摘要值，并和消息中携带的摘要值比对，确认有无篡改（摘要算法保证了“数字摘要”和原文是完全等价的。所以只要在原文后附上它的摘要并进行校验，就能够保证数据的完整性）

c. 数字证书是为了解决黑客冒充某网站给客户端一个假的公钥，如果你拿到了假的公钥，加密后传递就被窃取了。所以，为了解决公钥的信任问题，需要引入“数字证书”。

数字证书就是可信任的权威机构（CA）颁发的服务器相关信息和其公钥。服务器通过向客户端提供证书来证明自己确实是某某网站。CA的公钥是公开的，客户端拿到证书后用CA公钥解开就可以拿到服务器公钥了。

操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的内容，就能够确定证书是可信的，从而里面的公钥也是可信的，本质上数字证书也是数字签名的一种，只是加密的内容和颁发机构不一样。

3、传输层TLS加密

引用至站内文章，写的很好：Https工作原理＆TLS握手机制-CSDN博客

http 是超文本传输协议，信息是明文传输，https 则是具有安全性的加密传输协议；http 基于 tcp 协议，tcp 三次握手之后即可开始 http 通信；https 是在 http 与 tcp 之间加了一个 SSL/TLS 安全层，在 tcp 握手之后，还要进行 TLS 握手，才可以开始通信（https 使用证书系统来进行身份认证，使用 https 的网站需要到 CA 申请证书，一般免费证书较少，因而需要一定费用）。

HTTPS的基本概念：
SSL：安全套接层，在 OSI 模型中处于第 5 层（会话层）；TLS：1999年，SSL被改名为TLS（传输层安全），正式标准化，所以 TLS1.0 实际上就是 SSLv3.1，目前应用的最广泛的 TLS 是 1.2。

TLS 综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”。

TLS 的密码套件命名：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法。
如：ECDHE-RSA-AES256（GCM）-SHA384
含义：握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。

详细解释具体的使用方式为：

（1）加密：TLS握手首先使用非对称加密算法ECDHE传递服务器与浏览器后续交互使用对称加密密钥（对称加密实现更简单、传输效率更高，也就是这里例子说的AES加密算法）；对称加密的密钥内容作为原文内容先通过SHA384摘要算法生成摘要，再通过RSA非对称加密算法的私钥加密生成数字签名，多重保障统一在消息传递前完成。

（2）解密：浏览器接受到消息首先通过RSA算法的公钥解开数字签名（确保原文内容和摘要值都没有被篡改），并通过SHA384算法计算比较摘要值，来确认对称加密的密钥内容（原文内容）没有篡改，最终获取AES对称加密的密钥，进行后续浏览器与服务器之间的消息传递。

二、DID定义

1.定义

（1）分布式数字身份标识符是一种去中心化的可验证的数字标识符，具有分布式、自主可控、跨链复用等特点。

（2）它是由字符串组成的标识符，用来代表一个数字身份，不需要中央注册机构就可以实现全球唯一性。

（3）通常一个实体可以拥有多个身份，每个身份被分配唯一的DID值，以及与之关联的非对称密钥（颁发者提供，不同的颁发者提供不同的密钥），实体可自主完成DID的注册、解析、更新或者撤销操作。

（4）不同的身份之间没有关联信息，从而有效地避免了所有者身份信息的归集。

（5）DID本质上是一个全球唯一的地址标识符URL，在W3C的DID标准化文档中，将DID标识符的规范格式定义为：

前缀did是固定的，表示这个字符串是一个did标识字符串。中间的example被称为DID方法，就是用来表示这个DID标识是用哪一套方案（方法）来进行定义和操作的。这个DID方法我们可以自定义，并且注册到W3C的网站中。最后面的部分是在该DID方法下的唯一标识字符串。

当前标准上定义的方式有四种主流DID方法（BTCR、ETHR、WEB、KEY，已在W3C注册的有100多种）的标识生成过程，不同方法只是DID Method生成具体id值得方法差异，id在各自体系内唯一即可，当前很多Method是基于明确的用户信息进行二次加密处理，再对外呈现，比如对于人身份证号的处理，再在网络中分享，以此达到不透露任何信息的目的。

以web方法举例：did:web 的本质是将传统域名系统（DNS）升级为去中心化身份载体，通过 HTTPS 协议托管 DID 文档，实现身份绑定与验证，关键设计特点：

去中心化依赖：无需区块链，依赖现有 Web 基础设施（域名 + HTTPS）
即时更新：DID 文档实时更新，无需链上交易延迟
成本低廉：仅需标准 Web 服务器即可部署

（5）在应用过程中，DID标识将具体解析为写有与用户身份关联的属性信息的DID文档，这个文档就是一个JSON字符串，与DID标识符形成键值对，两者是一一对应打的，描述的是与被识别对象进行密码验证交互所必须的DID主体标识、公钥、验证协议、服务端点等，如下是W3C官方提供的一个具体的DID文档示例：

{
// 代表的是该JSON-LD格式结构上下文含义，含义定义的标准格式描述
"@context": "https://w3id.org/did/v1",
// DID唯一标识，123456789abcdefghi通常是加密处理后的值，method方法里保证唯一性即可。
"id": "did:example:123456789abcdefghi",
// authentication字段用于确认用户对该DID的控制权，包含了与DID相关的公钥信息，用于验证该DID的身份和控制权。
"authentication": [{
// 本DID文档对应的DID标识---表示描述的DID主体信息
"id": "did:example:123456789abcdefghi#keys-1", --- keys-1表示第一个公钥ID，后面VC验证部分会有详细说明用途
"type": "RsaVerificationKey2018", --- 公钥使用的加密算法为RSA
"controller": "did:example:123456789abcdefghi", --- 该公钥的控制发行者
//本DID对应的公钥信息
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n" --- 具体的公钥信息
}],
"service": [{
// 获取本DID对应的VC的服务端点---表示要到这个地址去进行身份验证、授权或交互的去中心化身份管理服务地址信息，后面样例会有详细的使用方式说明
"id":"did:example:123456789abcdefghi#vcs",
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}
DID文档中最重要的就是公钥信息，这是我们接下来要进行VC和VP验证的基础。我们一般是把DID标识作为Key，把DID文档作为Value存储到区块链中，利用区块链不可篡改、共享数据访问的特点，实现接下来在验证身份时能快速访问获取可信数据。

三、VC、VP的定义及验证原理

1、VC和VP的定义

（1）VC（Verifiable Claims 或 Verifiable Credentials，可验证凭证/可验证声明）是一个 DID 给另一个 DID 的某些属性做背书而发出的描述性声明，并附加自己的数字签名，用以证明这些属性的真实性，可以认为是一种数字证书（重点理解，是整个VC验证机制的核心思想）。传统的PKI数字证书体系需要CA来颁发，而在DID中也是分为颁发者、持有者、验证者、DID注册系统（也就是区块链），具体关系如图：

如下内容重点参考博客：去中心化数字身份DID简介——一、基本概念 - 深蓝 - 博客园

颁发者Issuer就是证书的颁发机构，比如身份证就是公安机关作为颁发者，毕业证书就是大学作为颁发者。
持有者Holder就是证书的持有人，就是我们这些普通人。
验证者Verifier就是在我们使用证书时查看我们证书的人或者机构。比如我们入住酒店，前台要验证我们的身份证，那么酒店前台就是验证者；再比如我们入职新公司时需要提供大学毕业证书，新公司HR就是验证者。
DID注册系统Verifiable Data Registry就是我们存储了DID标识和DID文档的地方，通过DID标识可以查询到对应的DID文档。

当公安机关给我颁发了身份证，在DID中，这个身份证就是VC。

一个VC也是一个JSON字符串，包含如下信息：

UntitledImage

VC元数据，主要就是发行人、发行日期、声明的类型等信息。
声明，一个或者多个关于主体的说明。比如身份证作为公安机关颁发给我的VC，在声明中会包含：姓名、性别、出生日期、民族、住址等信息。
证明，通常就是颁发者的数字签名，保证了本VC能够被验证，防止VC内容被篡改以及验证VC的颁发者。

下面是官方给出的一个VC的具体样例：

因为VC中具有用户的隐私信息，所以VC一般保存在私有的存储中，比如用户自己的手机中，或者需要授权的网络地址中。除了前面示例中给出的数据外，我们的VC还可以有失效日期，比如我们的身份证一般10年有效，过期后就需要重新向颁发者申请新的VC。

（2）Verifiable presentation简称VP，可验证表达是VC持有者向验证者表名自己身份的数据。一般情况下，我们直接出示VC全文即可，但是在某些情况下，出于隐私保护的需要，我们并不需要出示完整的VC内容，只希望选择性披露某些属性，或者不披露任何属性，只需要证明某个断言即可。
比如一个求职者要进入某写字楼面试，写字楼的保安要求登记身份证号码和姓名，但是我们的VC中还包含了民族、住址等信息，我们的求职者不希望将自己的住址暴露给保安，所以他提供给保安的VP中应该只选择性的披露的身份证号码和姓名，其他信息都不披露。
再比如我们规定必须年满18岁才有资格购买香烟，所以一个消费者在购买香烟时必须证明自己已经年满18岁，但是直接出示身份证给收银员又会暴露太多隐私信息，就算选择性披露生日属性，也会让收银员知道了消费者具体的年龄和生日日期，这种情况下消费者只希望在VP中证明自己大于18岁，其他什么信息都不能暴露。

UntitledImage

VP元数据，主要包含了版本，本JSON对象的类型等信息
VC列表，要对外展示的VC的内容，如果是选择性披露或者隐私保护的情形，可能就不包含任何VC。
证明，主要就是持有者对本VP的签名信息

2、验证流程及实现原理

重点参考该篇博客：去中心化数字身份DID简介——二、一个完整的DID使用流程 - 深蓝 - 博客园

（1）场景描述

小明是一个刚刚从大学毕业的应届毕业生，在毕业当天学校颁发了毕业证给小明对应的数字身份，小明拿到毕业证后第二天去公司入职，其中一个环节，公司HR要求验证小明的学历信息，验证完成，小明入职成功。

（2） Holder小明生成DID标识和DID文档

小明要想获得学校颁发的毕业证，那么他必须要有自己的DID，所以他先下载一个数字身份的手机APP，然后创建账号。创建账号的过程就是在手机中生成一个随机的私钥和对应的公钥。这里我们假设我们的DID标识的规则是“did:cid:身份证号”，所以小明在APP中输入自己的身份证号码，生成了一个DID标识：did:cid:511112200001010015 （这里对应的cid具体值保证在cid体系下的唯一性即可，对外发布的也不是身份证号本身）

这里我们为该DID设置了两个公钥，一个是小明自己的，用于认证签名等，Key2是系统托管的，用于手机丢失或者系统崩溃导致用户私钥丢失的情况下，帮忙小明找回自己的DID，绑定成一个新的公钥。

Proof部分是小明自己用自己APP里面的私钥对该DID文档的签名。如果我们想进一步增强安全性，可以将proof部分改为由公安机关进行签名。（当前包括未来业务场景会优先使用CA机构来背书，确保安全性）

DID文档生成完成后，APP会将该DID和文档上链到区块链存证，一旦上链完成，所有人都能够查询到小明的这个DID和文档。这里的区块链我们一般都是一个联盟链，并不是任意数据都可以随意写入的，所以小明必须是使用自己的身份证号经过验证确实是本人后才会上链，防止其他人冒用小明身份证号的情况。

（3）Issuer学校颁发毕业证VC给小明

学校本身也有自己的DID，由于学校是教育系统里面颁发的DID，所以规则和小明作为中国公民的DID规则不一样，比如学校的DID标识是：did:cedu:uestc

这个DID不是学校自己签名的，而是被教育部签名的(教育部的DID是did:corg:moe)，我们在区块链中可以找到该DID对应的DID文档如下：（同样的逻辑，每个VC都要有一个proof来背书，确保他是可信的）

所有认证过的高校的DID都是由did:corg:moe这个DID创建的，所以这相当于传统的根CA，我们只需要信任这个DID创建的DID，就可以认为是正规的高校。

继续说回颁发毕业证VC，学校根据小明的学习情况（入学时间、毕业时间、专业、是否结业等信息）以及小明提交的自己的DID，生成VC如下：

这里最主要的就是credentialSubject证书的内容和proof颁发学校给出的证明。这个VC生成后会传给小明，小明可以选择将这个内容存储到自己的手机APP中，也可以选择存储到云上，以后需要使用时再读取。

（4）Holder小明提交学历证明VP给Verifier公司HR

接下来小明来到新公司入职，入职当天需要提交学历证明给公司HR，于是小明基于上一步骤生成的VC再封装一下，生成VP，VP的内容如下：

这里比较简单，只是简单的提交整个毕业证全部内容（当前也可以选择部分内容，也就是我们常说的选择性披露），所以VP中只需要把VC签入进去，最后proof的地方小明用自己APP里面的私钥进行签名，表名这个VP是小明自己生成的即可。这个VP生成后小明需要将整个VP的内容提交给新入职公司HR。

（5）Verifier公司HR验证通过小明的VP

公司HR作为验证者在收到小明提交的VP后首先验证Proof字段，保证VP是小明提交的（可以去DID注册系统查询获取其个人公钥，如前所述，因为Verifiable Data Registry就是我们存储了DID标识和DID文档的地方，通过DID标识可以查询到对应的DID文档，KV键值对存储在Verifiable Data Registry，通常是区块链架构方式存储），而且没有被篡改。

接下来提取出其中的VC内容，对VC进行解析验证，验证过程如下：

1. 【验证学校的可信性】从VC的proof对应的creator中获得颁发者的DID：did:cedu:uestc

2. 【验证学校的可信性】通过区块链查询到该DID---did:cedu:uestc对应的的文档，在文档中有其创建人和公钥列表，其中我们取keys-1对应的公钥：

"id": “did:cedu:uestc#keys-1", "type": "Secp256k1", "publicKeyHex": "3053ba33b235d7116a3e3080168ee293053ba33b235d7116a33053ba33b235d7116a3" },

3.【验证教育局的可信性】创建人是did:corg:moe，是可信的DID（通过公共的CA证书验证），所以它创建的DID都是可信的。

4.【验证学校的可信性】我们进一步的再用did:corg:moe去区块链读取DID文档，并获得其中的公钥，使用该公钥对did:cedu:uestc对应的文档进行签名验证，确保其没有被篡改。

5.【验证小明个人信息的可信性】验证通过，我们再用did:cedu:uestc的公钥对小明提交的VC进行签名验证，验证通过，则说明这个证书确实是可信的UESTC颁发的。

6.【公司比对确认信息一致性】HR检查VC中提供的内容，与小明提交的履历上是否一致，检查完成，进行下一步的入职手续。

以上验证过程中我们至少需要进行三次签名验证，逐层验证。一是验证VP是小明提交的，二是验证VC是UESTC高校颁发的，三是验证UESTC的DID是MOE教育局创建的，而MOE是在验证方系统可信列表（CA证书）中的，所以整个就保证了小明提交的证书的可信（重点理解）。

（6）小结

以上只是简化版的DID从生成到申请VC再到验证VP的过程，概括为：

a. VC或VP的生成过程:
颁发者根据需要收集主体的信息，并将其转换为VC 格式，提供给持有者（对于自己的VC内容可见）；VC 可以存储在持有者的数字钱包中，例如 Microsoft Authenticator 应用程序，也可以存储在其他安全的地方。

颁发者使用非对称加密的私钥对VC进行数字签名（颁发者的公钥对外发布），确保其真实性和完整性，同时通过私钥签名并上链存证。

b. VC或VP的验证过程：
（1）持有者（对于自己的VC内容可见）提取VC的部分或者全部必要信息，通过自己的私钥（如数字钱包）加密生成VP并提供给验证方；

（2）验证方首先用对外发布的持有者公钥验证VP（对于部分披露的场景）持有者数字签名，确保没有更改---用于验证当前持有者身份合法（证明此VP没有被篡改过，一般使用持有者私钥进行签名）。

（3）同理，验证方也可以利用颁发者发布的公钥验证VC的数字签名，确保没有更改，如果没有更改验证通过，则说明是目标验证方提供的VC，验证通过。---用于验证VC的完整性。

（4）【进一步确认，非必需】颁发者将持有者提供的私钥加密的VC发送给第三方身份注册机构（具有颁发者的通过DID数据链）进行验证，返回提供的VC的真实性结果

验证可以通过多种方式进行，例如直接验证VC 的数字签名，或者通过可信的第三方服务来验证VC 的真实性。