数据签名验签依赖非对称加密体系的数学陷门特性。算法生成一对数学上相关联的密钥:私钥由所有者严格保密,用于生成签名;公钥可以公开分发,用于验证签名。用私钥加密的内容只能由对应的公钥解密,这一特性构成了身份认证的基础。主流算法包括基于大整数分解难题的 RSA、基于椭圆曲线离散对数问题的 ECDSA 和 SM2,以及基于爱德华兹曲线的 Ed25519 等。
哈希函数将任意长度的输入数据转换为固定长度的哈希值(摘要),具备单向性、抗碰撞性和确定性三大核心特性。相同输入永远生成相同输出,微小的输入变化会导致输出巨大变化(雪崩效应),且无法从哈希值反推原始数据。在数字签名中,先对原始数据计算哈希值,再对哈希值进行签名,而非直接对原始数据签名,大幅提升运算效率。
签名与验签是一对互逆的操作。签名过程中,发送方使用私钥对数据哈希值进行密码运算,生成唯一对应的数字签名串。验签过程中,接收方使用发送方公开的公钥对签名进行解密(或验证运算),得到原始哈希值,同时重新计算收到数据的哈希值,两次结果一致则验签通过。只有持有对应私钥的人才能生成可用该公钥验证通过的签名,从而实现身份认证和不可否认性。
数字签名验签同时解决信息安全的三大核心问题:一是数据完整性,通过比对哈希值确认数据在传输过程中未被篡改;二是身份认证,通过私钥签名的不可伪造性确认数据确实来自声称的发送方;三是不可否认性,发送方无法事后否认曾对数据进行了签名,因为其私钥是唯一能生成该签名的密钥。
发送方签名由三个步骤组成。第一步,对原始数据(如合同文件、API 请求参数、交易信息)使用约定的哈希算法(如 SHA-256、SM3)计算摘要,得到固定长度的哈希值。第二步,使用发送方自己的私钥对该哈希值进行签名运算,生成数字签名串。第三步,将原始数据与数字签名一同发送给接收方,在某些场景下还会附上包含公钥的数字证书,以便接收方验证公钥的合法性。
接收方验签同样是三个核心步骤。第一步,接收原始数据和数字签名,若附带数字证书则先验证证书链的有效性。第二步,使用发送方公开的公钥对数字签名进行验证运算,得到发送方声称的原始哈希值。第三步,使用与发送方完全相同的哈希算法,对收到的原始数据重新计算哈希值,将两次得到的哈希值进行比对,若完全一致则验签成功。
签名与验签必须使用相同的哈希算法,否则验签必然失败。发送方使用 SHA-256 计算摘要,接收方也必须使用 SHA-256 重新计算,若误用 SHA-1 或 SM3,计算结果将完全不同。在实践中,哈希算法标识通常随签名数据一同传输,接收方据此选择对应的哈希算法,部分签名标准(如 RSA-PSS)还将哈希算法标识嵌入签名结构中,进一步降低算法不匹配的风险。
在实际应用中,接收方需要确认用于验签的公钥确实属于声称的发送方,这一确认过程由数字证书完成。数字证书是由权威证书颁发机构(CA)签发的电子身份凭证,将发送方身份信息与公钥绑定。接收方通过验证证书的数字签名(由 CA 私钥签署)来确认公钥的合法性,再沿证书链向上追溯至受信任的根证书,建立完整的信任链。
哈希函数生成的哈希值被称为数据的"数字指纹",是验证数据完整性的核心依据。哈希函数的雪崩效应保证了一旦数据发生任何微小改动(哪怕仅修改一个比特),重新计算的哈希值都会发生巨大变化,接收方通过比对哈希值即可精确判断数据是否被篡改。这一机制是数字签名能够检测数据篡改的根本原因。
直接对原始数据进行签名运算在技术和效率上均不可行。非对称加密算法的输入长度通常有限制,且对长数据进行运算的计算开销极高。通过对原始数据先计算哈希值(固定长度,如 SHA-256 输出 256 位),再对哈希值进行签名,将签名运算的输入固定为短且长度一致的摘要,大幅提升了签名和验签的效率,同时不影响安全性。
目前主流的哈希算法包括 SHA-256(国际标准,广泛应用)、SHA-3(新一代标准,抗攻击能力更强)、SM3(中国国密标准,输出 256 位,安全强度与 SHA-256 相当)。MD5 和 SHA-1 已被证明存在严重安全漏洞,不应再用于任何安全相关的签名场景。在国内金融、政务、军工等领域,SM3 是合规要求的哈希算法。
哈希算法的输出长度直接影响签名的安全性和效率。256 位的哈希输出(如 SHA-256、SM3)为签名算法提供了充足的安全空间,使其能充分发挥密钥长度对应的安全强度。在算法选型时,需确保哈希算法的抗碰撞强度不低于签名算法的安全强度,否则哈希层会成为整个签名体系的短板。
RSA 是最早广泛使用的数字签名算法,基于大整数分解数学难题。签名时使用私钥对哈希值进行模幂运算,验签时使用公钥进行逆运算。RSA 签名的主要变体包括 PKCS#1 v1.5(传统方案,兼容性好)和 RSA-PSS(概率签名方案,安全性更高)。RSA-2048 提供约 112 位安全强度,RSA-3072 提供约 128 位安全强度。RSA 的优势在于生态成熟、兼容性极佳,但签名速度较慢,密钥和签名长度较大。
ECDSA 基于椭圆曲线密码学(ECC),使用远短于 RSA 的密钥提供同等安全强度。ECDSA P-256 使用 256 位密钥,安全强度与 RSA-3072 相当,签名长度仅约 70 字节(DER 编码),远小于 RSA-3072 的 384 字节。ECDSA 签名速度较快,验签速度也优于 RSA,特别适合移动设备、物联网终端等资源受限环境。ECDSA 已被纳入 NIST 标准,在 TLS 证书、加密货币(如比特币、以太坊)中广泛应用。
SM2 是中国国家密码管理局发布的椭圆曲线数字签名标准,基于国产椭圆曲线参数,安全强度与 ECDSA P-256 相当(约 128 位)。在相同安全强度的基准测试环境下,SM2 签名速度通常比 RSA-2048 快 3 至 5 倍,签名长度 64 字节(512 位),在密钥长度、传输开销和存储效率上均优于 RSA。在国内金融、政务、电力、医疗等需通过密评认证的场景中,SM2 是强制或优先推荐的签名算法。SM2 通常与国密哈希算法 SM3 配套使用。
Ed25519 是基于 Curve25519 椭圆曲线的数字签名算法,属于 EdDSA 家族,以高性能和强安全性著称。Ed25519 提供约 128 位安全强度,签名和验签速度均极快(显著快于 ECDSA P-256),签名长度 64 字节,公钥长度仅 32 字节。Ed25519 的设计天然抗多种侧信道攻击,实现相对简单,不易引入实现层漏洞。该算法广泛应用于现代 TLS 配置、区块链技术(如 Stellar、Cardano)、SSH 认证等高性能场景。
随着量子计算技术的发展,基于大整数分解和离散对数难题的传统签名算法面临量子攻击威胁。美国国家标准与技术研究院(NIST)已于 2024 年公布后量子数字签名标准 ML-DSA(核心算法为 Dilithium),基于格密码学构建,可抵抗量子计算攻击。目前 ML-DSA 等后量子签名算法已进入商用验证阶段,在对长期安全性有极高要求的场景中开始试点部署。
数据完整性的保证源于哈希函数的确定性和抗碰撞性。签名时,发送方对原始数据计算哈希值 H1,并对 H1 进行签名。验签时,接收方对收到的原始数据用相同哈希算法重新计算,得到哈希值 H2。若数据在传输过程中被篡改,H2 将与 H1 完全不同,验签失败。由于哈希函数的抗碰撞性,攻击者很难构造出两个不同的数据使其哈希值相同,从而无法在不被发现的情况下篡改数据。
哈希函数对输入数据的任何改动都极为敏感,无论是修改文件内容、替换交易金额、还是插入恶意代码,都会导致重新计算的哈希值与原始哈希值不匹配。这一特性使数字签名验签能够检测出数据中的任何篡改行为,包括非常微小的改动。在某些增强方案中,还会对数据的元数据(如时间戳、序列号)一并计算哈希,防止攻击者替换整个数据包或重放旧数据。
数据完整性的密码学保障最终依赖于哈希算法的抗碰撞能力。目前 SHA-256、SM3、SHA-3 等主流哈希算法的抗碰撞强度均在 2^128 量级或以上,意味着找到两个不同输入使其输出相同哈希值的概率在计算上不可行。MD5 和 SHA-1 的抗碰撞能力已被攻破,使用这些弱哈希算法会使完整性保障失效,因此在安全场景中必须禁用 MD5 和 SHA-1。
身份认证的核心在于:只有持有特定私钥的人才能生成可用对应公钥验证通过的签名。私钥由所有者唯一持有且不对外泄露,任何其他人无法伪造出合法的签名。当接收方用某公钥成功验证签名时,即可确认该签名必然由持有对应私钥的发送方生成,从而实现身份认证。这一机制不依赖密码、不依赖生物特征,仅依赖密码学数学原理。
仅凭公钥验签成功只能确认"持有对应私钥的人签署了数据",但无法直接确认"这个公钥属于谁"。数字证书由权威 CA 机构签发,将持有者的身份信息(如域名、企业名称、个人身份标识)与其公钥绑定,并用 CA 的私钥对证书内容进行签名。接收方通过验证证书链,确认公钥的合法性及其与发送方身份的对应关系,从而完成完整的身份认证。
在高安全等级场景中,数字签名常与多因子认证结合使用。例如,在移动端签名操作中,用户需先通过生物特征(指纹、面容)或 PIN 码解锁私钥存储区,才能进行签名操作。这防止了私钥文件被盗后攻击者直接冒充合法用户签署数据。在企业场景中,还会结合 USB Key、HSM(硬件安全模块)等物理设备存储私钥,进一步提升身份认证的安全性。
数字签名是对特定数据的哈希值进行运算生成的,与原始数据紧密绑定。攻击者若篡改原始数据,接收方重新计算的哈希值将发生变化,与签名中保护的原始哈希值不一致,验签直接失败。攻击者若试图在篡改数据后重新生成合法签名,则必须持有发送方的私钥,而私钥的保密性正是整个签名体系的安全基石。因此,在没有私钥的前提下,任何数据篡改行为都会被发现。
攻击者可能试图将合法签名从一个文件"平移"到另一个篡改后的文件上,使验签通过。这一攻击之所以失败,是因为签名保护的是特定数据的哈希值,不同数据的哈希值不同,用 A 文件的签名无法通过 B 文件的验签。某些签名标准(如 RSA-PSS)还在签名结构中引入随机化因子,使同一数据每次签名的结果不同,进一步防止签名被重复利用或平移。
除防止内容篡改外,数字签名体系还通过时间戳和序列号防止"重放攻击"(攻击者截获合法签名数据后重复发送)。发送方在签名数据中嵌入当前时间戳或递增序列号,接收方验签时检查时间戳是否在合理范围内、序列号是否已被使用,从而识别并拒绝重放的数据包。这一机制常结合 nonce(一次性随机数)使用,确保每次签名都是唯一的。
不可否认性的核心逻辑是:合法签名的生成需要发送方私钥的参与,而私钥由发送方唯一控制,且生成签名的行为只能通过私钥完成。当接收方用发送方公钥成功验证签名时,在法律和技术两个层面均证明该签名确由发送方生成。发送方无法声称"签名是别人伪造的",因为攻击者在没有私钥的情况下无法生成可通过公钥验证的合法签名。
在电子合同、电子票据等具有法律效力的场景中,仅凭技术层面的不可否认性还不够,还需满足法律对电子签名效力的要求。通过引入权威第三方 CA 签发的数字证书,以及可信时间戳服务机构(TSA)签发的时间戳,为签名附加了法律认可的时空证据,使签名在司法实践中具备更强的不可否认性和证据效力。中国《电子签名法》明确规定,符合法律条件的电子签名与手写签名或盖章具有同等法律效力。
为进一步增强不可否认性,实际系统通常还会记录完整的签名操作审计日志,包括操作时间、操作人身份、操作终端信息等,并将签名操作的哈希值同步上链存证。当发生纠纷时,这些辅助证据与数字签名本身形成完整的证据链,使发送方更难成功抵赖。在司法实践中,结合区块链存证的电子签名证据已被广泛采信。
电子合同签署是数字签名最典型的应用场景。签署双方使用各自的数字证书对合同文件进行签名,确保合同内容不可篡改、签署身份不可抵赖。在司法层面,采用符合《电子签名法》要求的数字签名技术签署的电子合同,与纸质合同具有同等法律效力。目前,国内电子合同平台已广泛集成区块链技术,将签署过程的哈希值上链存证,进一步提升证据效力。司法实践中,符合《电子签名法》可靠性要件的电子签名证据,已被人民法院广泛采信为有效证据。
在开放 API 和支付系统中,签名验签是保障接口安全的核心手段。服务端在返回数据时使用私钥签名,客户端用公钥验签确认数据来源合法;客户端在发送请求时也使用私钥签名,服务端验签确认请求方身份。在主流支付平台的通知回调机制中,平台使用私钥对通知数据进行签名,商户系统用平台公钥验签,防止攻击者伪造支付通知实施欺诈。对于大规模 API 签名验签场景,可结合腾讯云 KMS(密钥管理服务)提供的托管密钥能力,将签名运算卸载到专用硬件安全模块中,兼顾高并发性能与私钥安全。
区块链系统的核心安全机制之一就是数字签名。在比特币、以太坊等公链中,用户使用私钥对交易数据进行签名,网络节点用用户的公钥验签,确认交易确实由合法持有者发起。数字签名保证了区块链上资产的转移只能由私钥持有者发起,是实现去中心化信任的基础。不同区块链采用的签名算法有所不同,比特币使用 ECDSA Secp256k1,部分新兴链则开始采用 Ed25519 或后量子签名方案。
代码签名通过对软件可执行文件、安装包进行数字签名,确保用户下载的软件未被篡改且确实来自声称的发布者。操作系统(如 Windows、macOS、Linux)内置了代码签名验证机制,对未签名或签名验证失败的软件给出安全警告。这一机制有效防止了供应链攻击——攻击者在合法软件中植入恶意代码后分发,若没有代码签名保护,用户很难辨别软件是否被篡改。
在物联网场景中,海量设备需要安全地与云平台或其他设备通信,数字签名提供了轻量级的设备身份认证机制。每个物联网设备在出厂时预置唯一私钥,在通信过程中通过对消息签名来证明自身身份。考虑到物联网设备的计算能力有限,通常采用 ECDSA 或 SM2 等签名长度短、运算速度快的算法,部分场景还结合 HSM 或 TEE(可信执行环境)保护设备私钥安全。
数字签名的安全性建立在经过长期密码分析的公开数学难题之上(如大整数分解、椭圆曲线离散对数),其安全强度可通过密钥长度进行量化评估。相较于依赖口令或生物特征认证的方案,数字签名不依赖人类记忆或生物特征采集设备,且不存在口令泄露、指纹被复制等风险。在正确使用的前提下,目前主流的数字签名算法(RSA-3072、ECDSA P-256、SM2、Ed25519)均能抵抗已知的各种密码学攻击。
传统的对称加密认证方案需要通信双方预先共享同一密钥,密钥分发和管理在大规模系统中极为困难。数字签名采用非对称机制,签名方仅需妥善保管自己的私钥,验签方只需获取公开的公钥,双方无需事先协商共享任何秘密信息。这一特性使数字签名特别适合开放网络环境中的应用,如互联网 HTTPS 证书验证、开放 API 调用等场景。
数字签名验签过程可由计算机程序全自动执行,无需人工参与,适合高并发、高频次的自动化系统。在现代服务器硬件上,单次 ECDSA P-256 验签可在 0.2 至 0.35 毫秒内完成,RSA-2048 验签也仅需约 1 至 2.5 毫秒。通过硬件加速(如 Intel SHA 扩展指令、HSM 专用芯片)和软件优化,单一服务器可实现每秒数万次签名验证,满足大规模系统的性能需求。
数字签名技术在法律层面已获得广泛认可。中国《电子签名法》、美国 ESIGN 法案、欧盟 eIDAS 条例等均明确了符合技术标准的电子签名的法律效力。同时,数字签名相关算法和协议已高度标准化(如 PKCS、X.509、GM/T 系列国密标准),不同厂商、不同平台之间的互操作性良好,有利于构建跨系统、跨机构的信任体系。
算法选择的首要依据是应用场景的合规性要求。在国内金融、政务、医疗等需通过密码应用安全性评估(密评)的系统中,必须采用国密算法(SM2 签名 + SM3 哈希),使用 RSA 或 ECDSA 等非国密算法将导致合规不通过。在面向国际的场景或对国密无强制要求的系统中,RSA、ECDSA、Ed25519 均为可接受的选择。出口系统还需注意目标国家/地区对密码算法的进出口管制要求。
选择算法时需确保密钥长度提供足够的安全强度。目前,128 位安全强度是大多数场景的推荐基准,对应 RSA-3072、ECDSA P-256、SM2-256、Ed25519。对安全强度要求更高的场景(如根证书签名、长期有效合同签署)可选用 192 位或 256 位安全强度(对应 ECDSA P-384/P-521、RSA-4096)。需注意 RSA-2048 的 112 位安全强度已不再被部分标准推荐,NIST 已宣布将于 2030 年弃用 RSA-2048。
在性能敏感或资源受限场景中,算法效率是关键考量因素。ECDSA 和 SM2 的密钥长度短、签名长度小、运算速度快,特别适合移动端、物联网设备和大规模 TLS 握手场景。Ed25519 在签名和验签速度上均优于 ECDSA P-256,是对性能有极高要求的新系统的优先选择。RSA 的优势在于验签速度极快(因公钥指数 e 通常取小值如 65537),适合签名少、验签多的场景。
对于需要长期安全保障的数据(如需保护 10 年以上的存档文件、长期有效的数字证书),需考虑量子计算发展对传统签名算法的威胁。目前,NIST 已标准化的后量子签名算法 ML-DSA 可抵抗量子攻击,但性能和签名长度相较传统算法仍有劣势。实际选型中,可关注 NIST 后量子标准化进展,在需要长期安全的场景中试点部署混合签名方案(同时使用传统算法和后量子算法),实现平滑过渡。
选用更高效的签名算法是最直接的性能优化手段。将 RSA-2048 替换为 ECDSA P-256 或 SM2,可将签名速度提升 3 至 5 倍,同时缩短密钥和签名长度,降低网络传输开销。在 TLS 场景中,将证书链从 RSA 切换为 ECDSA,可将完整证书链大小从约 3000 字节缩减至约 1500 至 1900 字节,减少 TLS 握手过程中的数据包数量和 TCP 重传概率,在高延迟移动网络中可将握手时间缩短 10 至 40 毫秒。
现代 CPU 提供了针对密码学运算的硬件加速指令,可大幅提升签名验签性能。Intel SHA 扩展指令集(Intel SHA-NI)可加速 SHA-1、SHA-256 等哈希算法的计算;AES-NI 指令集虽主要面向对称加密,但在部分基于 AES 的哈希模式(如 SHA-256 的 AES 硬件实现)中也有加速效果。在服务器端,采用 HSM(硬件安全模块)卸载签名运算,既能提升性能,又能将私钥保护在专用硬件中,符合高安全等级要求。腾讯云 KMS 等托管密钥管理服务提供了经过安全认证的 HSM 硬件支撑,可在不自行维护物理 HSM 设备的前提下获得同等安全等级的签名运算能力。
在需要频繁验签的场景(如 API 网关、区块链节点)中,可通过缓存已验证证书的公钥和验证结果来避免重复运算。对于同一 CA 签发的证书,其公钥和大部分验证信息在证书有效期内保持不变,首次验签后将关键信息缓存,后续验签可直接使用缓存数据。在批量数据处理场景中,还可采用批量验签技术(如 ECDSA 批量验证算法),将多次独立验签合并为一次运算,显著提升总体吞吐量。
针对后量子签名算法(如 ML-DSA/Dilithium)运算复杂度较高的特点,目前业界正积极探索 FPGA、ASIC 等专用硬件加速方案。基于 FPGA 的格基数字签名硬件优化方案,通过设计可配置参数的多功能脉动阵列运算单元、专用型多项式并行采样模块等架构创新,可实现签名运算效率数倍提升,为后量子时代的高性能签名验签系统提供硬件基础。