专栏首页包罗万想GCAC68 13.7.5 forward secrecy and non-repudiation

GCAC68 13.7.5 forward secrecy and non-repudiation

13.7.5 Additional desirable properties: forward secrecy and non-repudiation

13.7.3讨论了encrypt-then-sign 和 sign-then-encrypt两种方案,13.7.4讨论了DH方案。都满足下面的定义。

接下来讨论两个性质前向安全性和不可抵赖性。

13.7.5.1 Property I: forward secrecy (security in case of a sender corruption)

(Perfect)Forward secrecy的大致意思是:用来产生会话密钥(session key)的长期密钥(long-term key)泄露出去,不会造成之前通讯时使用的会话密钥(session key)的泄露,也就不会暴漏以前的通讯内容。简单的说,当你丢了这个long-term key之后,你以后的行为的安全性无法保证,但是你之前的行为是保证安全的。 之所以Perfect加上括号,是因为这个词蕴含了无条件安全的性质,大部分的forward secrecy方案是无法达到Perfect的。 而forward security的保证的是:敌手获取到了你当前的密钥,但是也无法成功伪造一个过去的签名。 简单的说,这两个概念是用在不同的环境中,但是其意图是一样的:保证密钥丢失之前的消息安全性或签名的不可伪造性。 一般而言,满足Forward secrecy的公钥环境下的(签名、密钥交换或加密)方案,其公钥是固定的,而密钥则随着时间进行更新。这个更新过程是单向的,因此也就保证了拿到当前的密钥,是无法恢复出以前的密钥,从而保证了“前向安全”。

参考资料:https://www.zhihu.com/question/45203206/answer/98980606

假设Alice加密一条消息给Bob,并将结果密文c发送给Bob。一周后,对手破坏了Alice并窃取了她的私钥。Bob的密钥保持不变,只有Bob知道。有人可能会合理地期望对手不能使用Alice的私钥解密c。我们将此属性称为发件人腐败正向保密或简称为正向保密。

让我们更精确地定义对签密方案提供发件人伪造的前向保密性意味着什么。目的是即使对手获得了发件人的密钥也要确保CCA的安全性。为此,我们对CCA安全游戏(攻击游戏13.6)进行了一些小的调整。

方案一的前向安全性:Forward secrecy for sign-then-encrypt

“sign-then-encrypt”结构提供了前向机密性:密钥skS仅用于签名消息,无助于解密任何内容。确实,从定理13.9中给出的具体安全范围,可以看到SCCA优势的范围完全不依赖于签名方案的安全性。

方案二的前向安全性:Forward secrecy for encrypt-then-sign.

有人可能会对encrypt-then-sign说同样的话。但是,通常情况并非如此。可以看到,在定理13.8中的具体安全范围内,SCCA优势的范围取决于签名方案和加密方案的安全性。确实,正如我们已经针对强安全签名方案的需求所讨论的那样,如果对手响应于S→R加密查询而获得密文(c,σ),并且可以计算出有效签名σ' !=σ 在(c,idR)上,然后按照CCA攻击游戏的规则,对手可以自由地以S→R解密查询的形式提交(c,σ'),从而完全破坏了CCA的安全性。

现在,如果没有发件人的签名密钥,这种攻击将是不可行的。但是使用签名密钥,如果签名算法是概率性的就很容易(我们将在以后看到这样的签名方案):对手可以使用发件人的签名密钥在内部S→R密文上生成不同的签名,并获得新的“encrypt-then-sign”密文,然后将其提交给解密Oracle。

但是,一切并没有丢失。有两种方法可以挽救encrypt-then-sign的前向安全性。解决这种情况的一种方法是采用具有唯一签名的签名方案(即,对于每个公钥和消息,最多有一个有效签名——全域哈希就是这样的方案)。这样,即使使用签名密钥,也无法进行上述攻击。另请参阅练习13.19,其中讨论了encrypt-then-sign的修改,该修改可以更一般地实现前向保密性。

挽救局势的另一种方法是通过简单地不允许对手在攻击游戏中提交对密文(c,σ')的解密查询来稍微削弱安全性定义。这合理吗?可以说是这样,因为如果σ和σ'都是c上的有效签名,那么任何人都可以很容易地看出(c,σ)和(c,σ')解密为同一事物。实际上,对对手的这种限制与练习12.2中讨论的gCCA安全性概念相对应,并且实际上对于大多数应用都是可以接受的。

方案三的前向安全性:DH方案

SCDH签密系统不是前向安全的:给定发送者的密钥,对手可以解密发送者生成的任何密文。幸运的是,我们可以增强SCDH来提供对发件人腐败行为的保密性。

多了随机值β和v,w

------------之前的DH版本-----------

------------之前的DH版本-----------

13.7.5.2 Property II: non-repudiation (security in case of a recipient corruption)

不可否认性(Non-repudiation)也称不可抵赖性,是指在网络信息系统的信息交互过程中,确信参与者的真实同一性。即,所有参与者都不可能否认或抵赖曾经完成的操作和承诺。利用信息源证据可以防止发送方否认已发送过的信息,而利用递交接收证据可以防止接收方事后否认已经接收过的信息。

假设Alice对发给Bob的消息m进行加密,并获得密文c。问题是,c与Bob的密钥一起提供给Bob足以说服第三方Alice实际上将消息m发送给了Bob吗?我们将此属性称为不可否认性。

我们在本章开始时就解释说,这种证据本身的说服力是有限的:Alice可以简单地声称她的私钥是从她那里偷来的,并且有人生产了c,或者她可以故意泄露她的私钥以作废c。但是,由于在某些情况下可能需要不可否认性,因此我们定义了不可否认性,并说明了如何构建提供不可否认性的签密方案。

不可否认性还可以用作部分防御Bob的密钥泄露的防御措施。如果签密方案不提供不可否认性,则攻击者可以使用Bob的受泄露密钥向假装来自Alice的Bob发送消息。这种攻击称为密钥泄露模拟或KCI。不可否认性可确保Bob的密钥不能用于模仿Alice,因此不可能进行KCI攻击。

方案一的不可抵赖性:encrypt-then-sign

encrypt-then-sign的构造提供了不可否认性:密钥skR仅用于解密密文,无助于签名。确实,在定理13.8中给出的具体安全范围内,可以看到SCI优势的范围完全不依赖于签名方案的安全性。

方案二的不可抵赖性:sign-then-encrypt

对于sign-then-encrypt的构造,不能使用相同的参数。请注意,在定理13.9中给出的具体安全范围内,SCCI优势的范围取决于加密方案和签名方案的安全性。实际上,很容易看出该方案无法像我们定义的那样提供不可否认性。确实,给定了解密密钥,人们总是可以解密密文加密(m,σ),然后简单地对其进行重新加密,从而获得另一种但仍然有效的密文。

尽管sign-then-encrypt不满足我们对不可否认性的定义,但它确实满足了一个较弱的概念,该概念对应于纯文本完整性,而不是密文完整性。粗略地说,此属性对应于Attack Game 13.9的修改,其中更改了获胜条件:要赢得游戏,其候选伪造cˆ必须解密为从未提交为S→R加密查询的消息。我们将它留给读者来充实此定义的细节,并表明“sign-then-encrypt”满足了这种较弱的不可否认性概念。另请参阅练习9.15。

方案三的不可抵赖性:SCDH

在很强的意义上,SCDH方案不提供不可否认性:接收者可以像发送者一样加密任何消息。SCDH’也是如此。由于具有此属性,这两种方案都提供了完全的可否认性-发送方始终可以(正确地)声明其生成的任何密文都可能是由接收方生成的。在实际设置中,可否认性属性可能被视为功能而非错误。

总结

在现实世界的系统中,向前保密显然是理想的属性。在签密的情况下,并非总是不可否认的。在需要向前保密但又不可否认的情况下,SC'DH方案是一种非常有效的解决方案。如上所述,在同时需要两个属性的情况下,“encrypt-then-sign”比“sign-then-encrypt”是一个更安全的选择,尽管仅提供了较弱的CCA安全性概念。练习13.19是encrypt-then-sign的一种变体,它也是确保向前保密和不可否认性的一种有吸引力的选择。

本文分享自微信公众号 - 包罗万想(An-mind),作者:安包

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-01-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Secure Messaging综述(1)

    论文:SoK: Secure Messaging 作者:Nik Unger, Sergej Dechand, Joseph Bonneau, Sascha Fa...

    安包
  • Dan Boneh密码学笔记8

    3.Deterministic Encryption Constructions:SIV and wide PRP

    安包
  • GCAC74 11.6 Threshold decryption

    11.6.1 Shamir’s secret sharing scheme

    安包
  • iptables系列教程(二)| iptables语法规则

    用来指明使用的表,有三种选项: filter,nat,mangle。若未指定,则默认使用filter表。

    山月
  • C++字符串处理小结

    常用的C++的字符串类型主要是std::string。它是模板std::basic_string的一个实例化。另外还有三个实例化std::wstring、std...

    linjinhe
  • 技术分析 | 谁是终极大Boss?一张图看懂《长安十二时辰 》人物关系

    豆瓣评分高达8.6的国产剧《长安十二时辰》,终于在今晚迎来大结局——幕后BOSS究竟是谁?张小敬和李必命运如何,都一一揭开谜底。该剧改编自以“脑洞大”著称的作家...

    逸迅科技
  • 你会和比你学历低的人谈恋爱吗?

    你会和比你学历低的人谈恋爱吗?先不要着急回答这个问题,下面这些答案,或许能给你一些启发,我们先一起来看一看。

    夏末浅笑
  • OpenPetra 以及CentOS Mono 3.0 部署包

    OpenPetra,是一款为非盈利及其他慈善组织提供的管理软件。该软件具有很好的灵活性和可定制化,可以帮助志愿者和非盈利机构进行任务管理。OpenPetra目...

    张善友
  • 自定义Drawable实现圆角图片和圆形图片

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/gdutxiaoxu/article/details/...

    用户2965908
  • 大厂面试必备之设计模式:漫画单例模式

    饿汉模式中的类实例是当类被加载时就被初始化出来的,所以在应用初始化时,会占用不必要的内存。同时,由于该实例在类被加载的时候就创建出来了,所以他是线程安全的。因为...

    天才少年

扫码关注云+社区

领取腾讯云代金券