【信息保护论】Ch9. 防止抵赖:数字签名

数字签名

否认(repudiation):发信方否定自己发送该信息的事实。

1.邮件本身谁都可以编造,A的借条邮件写了借B多少钱。
2.即便A发了借条给B,但是事后A抵赖,说这个邮件不是他发的,又没有证据能证明这邮件是他发的,则会吃哑巴亏。因为邮箱可以被盗号、电脑可能被其他人使用。
3.使用MAC可以检查出邮件本身是否被篡改内容,但是并不能防止否认。

从而引出的新技术——数字签名。数字签名是通过[鉴证用密钥]和[签名用密钥]两种密钥来实现对数据出处的确认。在利用公钥加密技术的情况下,将个人的私钥当做[签名用密钥]加密某消息,该消息被称作签名。任何接收该信息的人,不管是黑客还是合法用户,收到该签名后,用发信者的公钥尝试解密,公钥是[鉴证用密钥]且谁都可以持有,因此只要能够解密,就说明发信来源毫无疑问是私钥拥有者。这一个签名与鉴证的过程就是数字签名的过程。

-私钥公钥
公钥加密收信人解密用发信人加密用
数字签名发信人签名用收信人鉴证用
持有者个人私有可以被任何人持有,一般通过一般途径共享给有需要的用户

就是公钥加密的密钥反转过程。公钥加密技术是任何人都可以使用某人的公钥进行加密,而数字签名是任何人都可以对某签名进行鉴证。

数字签名的特征:

  • 不可伪造(Unforgeable):只有签名者可能生成签名
  • 签名者认证(Authentic):所有人都可以鉴证某签名
  • 不可重复使用(Not Reusable):签名无法被其他明文签名使用
  • 不可篡改(Unalterable):签名后的密文无法被篡改
  • 防止抵赖/否认(Nonrepudiation):签名后签名者不能对其行为否认或抵赖

数字签名需要的条件:

  • 签名需要明文以bit形式存在
  • 为了保证防止伪造和抵赖,发信人要求使用表达唯一信息的比特数据
  • 签名过程尽可能简单
  • 签名的鉴证与辨识尽可能简单
  • 伪造签名要从算术上不可能
  • 在签名保存到存储介质的过程中,签名的副本应该更实用的保存

数字签名过程图解:
在这里插入图片描述


数字签名的实现技术不仅仅局限于公钥,也可以使用其他技术实现,比如单方向哈希函数。下面再简单说明一下哈希函数实现数字签名的例子。
在这里插入图片描述

与公钥技术相似的是,为了保证来源的唯一性,仍然使用公钥加密签名,只不过传输的明文多了一步计算哈希值的过程。

应用场景

鉴于数字签名的特性,目的不是为了保证机密性,而是为了对来源的确认。举例生活中的例子往往更容易理解。

  • 党中央下发给地方的政令,这些内容并不是机密,允许以明文的形式上传下达,但是要求该文件中的每一个字和标点符号都不能被更改。此时中央以签名与明文与对应公钥发给地方,地方用公钥进行签名鉴证,确保内容无误。
  • 企业合作,A公司向B公司订购某货物一万吨,每吨售价一万元。合同签订后,B公司开始生产,当两个月后,生产完毕,此时发现该货物市值降低,市场价每吨只要8000元,此时A公司想要以市场价收购货物,而抵赖合同不是它签的。此时B公司拿出其签名,令其无法否认自己的行为,令其按照合同价收购货物。这个过程中,合同可以是纸质合同也可以是电子合同,都需要用签名来防止抵赖。

关于数字签名的常见疑问Q&A

  1. 为什么密文可以当做签名来使用?
    A):这里加密密文不是为了实现机密性,而是为了实现可鉴证性,必须有某种手段能够防止抵赖,而在加密通信中,这种私钥加密的方式就能够满足需求。
  2. 该过程中不需要维持机密性吗?
    A)是的,该过程不需要维持机密性,即任何人都允许被获取这条信息。这是用来鉴证来源的信息,该信息被鉴证后,证明发信者是真正的发信者无误后,再使用公钥加密、对称加密等加密明文的通信手段来交换需要维持机密性的信息。
  3. 签名本身也是比特流,那么就有被复制的可能,如果被复制不会被恶用吗?
    A):确实签名可以被复制和保留。但是即便复制该签名,也无法变更两点——该签名是谁签署的和签名内容是什么。也就说,如果签名者变更了签署内容的明文,则保留的签名将在此次以外的通信中失效。签名的意义在于鉴定发信人是否是对应用户,只要不知道发信人的私钥就无法伪装成对应的用户。因此仅持有签名是无意义的。
  4. 是否能篡改签名?
    A):当然可以,签名与明文都可以被篡改,但是没有意义。因为只要被篡改就会鉴证失败,鉴证人就能发现被篡改的事实。
  5. 是否可以同时修改签名与明文让他们两者能够恰好满足加密与解密关系?
    A):现实角度上不可能。
  6. 签名是否可以被再次利用?
    A)确实可以将签名单独裁剪掉并附加到其他信息中,但是没有意义。因为鉴证内容一旦改变,则签名鉴证将失败。
  7. 如果数字签名被删除,那么签名效果是否就失效了?
    A):不会。只要签名鉴证成功就证明了发信人是真正的发信人。该状态不会改变。即便签名本身被删除 ,在需要的时候可以生成一个文件,对于该文件可以要求对方进行重新签名。
  8. 如何实现防止否认(防止抵赖)?
    A):私钥只有发信人本人持有,如果其对应公钥可以解密某密文,则说明生成该密文使用的密钥一定是其对应的私钥。

活用数字签名的例子:

  • 安全公告Clearsign:不加密消息而是签名消息。利用哈希函数与公钥加密,当要发布某条安全警告时,需要验证信息的真实性,因此网络侵害事故对应资源中心会用哈希函数生成警告的哈希值并进行数字签名,签名结果与警告明文本身一起传输给下级部门。下级部分会将签名解密成哈希值,并计算明文的哈希值,如果二者相同则说明警告来源为真,拉响警报。
  • 软件下载:下载软件时,将软件本身进行签名,下载后再对比网站上的软件与签名解密后的软件的哈希值,来判断黑客是否对其有操作。
  • 公钥认证书:将数字签名附加到公钥上,可以判断由此判断获得的公钥来源是否是真正的拥有者。
  • SSL/TLS:将服务器的公钥进行签名,确定服务器的签名是真正对应服务器的。
  • RSA签名:签名=信息D mod N,(D,N)是签名者的私钥。信息=签名E mod N,(E,N)是签名者的公钥。
  • 其他数字签名: ElGamal、DSA(Digital Signature Algorithm)、 Rabin、Schnorr、 GQ、SIGN 、Fiat Shamir、KCDSA、 ECDSA、EC-KCDSA等不同的公钥加密方法为基础的数字签名。

数字签名面临的攻击

  1. MIMT中间者攻击:是的,数字签名仍然面临该攻击。黑客接入发信人和收信人之间,对发信人伪装成收信人,对收信人伪装成发信人,则对两名合法用户看来,他们数字签名环节都没有任何问题,都可以将签名解密到对应明文,然而实际上是黑客已经操作后的结果。
  2. 对单向哈希函数攻击:如果哈希函数抗碰撞性不够强,则容易被黑客将哈希值相同的消息偷换成其他消息。
  3. 利用数字签名反向解密公钥加密:黑客将A发给B的密文以其他身份发给B,并告诉他这一个密文是一个随机生成数,他正在进行数字签名实验,希望B给他做一份数字签名发给他。然后B对这个随机数(实际上是A个B的密文)进行数字签名,在RSA算法中其实就是对该消息进行解密。
    签名=信息D mod N
    信息=签名E mod N
    对签密文进行数字签名,得到是信息本身。
    (密文)D mod N=(信息E mod N)D mod N=信息。因此不知道意义的数据绝对不要随意进行数字签名。
  4. 潜在风险:即便毫无意义的数据(乱码)只要能生成正确的签名,则签名算法本身就不安全。即便是无意义的数据,也可能通过数字签名鉴证。这就数字签名算法的固有威胁之一。
  5. RSA潜在风险:随机数列S是RSA将M加密后的结果,S是M正确数字签名的逆,因此公钥可以被攻击者计算出,这也是数字签名的潜在威胁之一。
    对策:RSA-PSS(Probabilistic Signature Scheme):不是使用明文加密,而是明文的哈希函数值加密,在通过哈希函数之前,附加填充则会相对更加安全。
  6. 其他攻击:所有针对公钥加密的攻击都大部分都可以针对数字签名,包括对私钥的暴力解码和RSA中N的因数分解等。
-对称加密公钥加密
公钥加密收信人解密用发信人加密用
数字签名发信人签名用收信人鉴证用
密钥配送问题存在存在,公钥需要配送
机密性保证保证
-信息认证代码MAC数字签名
发信人共享密钥计算MAC值私钥签名
收信人共享密钥计算MAC值公钥鉴证
密钥配送问题存在存在,公钥需要配送
完整性保证保证
认证仅可认证通信对象可认证通信对象以及第三者
防止抵赖不可以可以

既然我们了解了数字签名无法确认收信来源真假,但是却可以对通信对象进行包括多个合法用户在内的认证。为了解决入手公钥可能是伪操作的问题,我们需要使用认证书技术。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Chahot

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值