《A Graduate Course in Applied Cryptography》Chapter 13 Digital Signatures(4)

原文教材 与 参考资料:

        Boneh Dan , Shoup Victor . A Graduate Course in Applied Cryptography[J].

        该书项目地址(可以免费获取):http://toc.cryptobook.us/

        博客为对该书的学习笔记,并非原创知识,仅帮助理解,整理思路。

13.7.3 Constructions: encrypt-then-sign and sign-then-encrypt

本节介绍两种自然的签密构造:

    (1)先加密,后签名,此处简称EtS.

EtS 首先使用接收者的公钥以及发送者的ID,对明文进行加密,并对(密文,接收者ID)进行签名。解密时,首先使用发送者的公钥进行签名验证,如果验证通过,则进一步进行解密。

     (2)先签名,后加密,此处简称为StE:

StE 首先使用发送者的私钥对(消息,接收者ID)进行签名,然后使用接收者的公钥对发送者的ID,消息,签名。解密时,使用接收者私钥对密文进行解密,如果密文合法,则进一步,对签名进行验证。这里假设,签名是一个比特字符串其长度仅仅依赖于明文消息m的长度。(因为这里的签名有泄露明文可能,而EtS不会泄露明文)

AE可认证加密 和 SE签密的对比

首先给出一张,二者类比关系及其构造的图:

        对于签密SE来说,其两种构造方式都是安全的,但是类似的MAC构造可认证加密却不是,对称加密-MAC可构造 可认证的加密,但是MAC-对称加密 不能提供可认证的安全属性(见该书第9章)。在公钥的签密构造中,这两种构造方法都是安全的。原因是StE是安全的,因为使用了一个CCA安全的公钥加密系统,而MAC-enc是使用的CPA安全加密系统,如果Mac-enc构造能够使用一个CCA的对称加密方案,那么该构造也可以提供可认证加密性质。因此EtS也是安全的。

        EtS系统要求使用一个CCA安全加密方案,而不是CPA方案,这点与encryp-then-mac是不同的,因为该方案使用的对称加密算法是CPA的,具有延展性,且任何人都可生成一个新密文的验证码,这也是CCA加密方案要求的动机之一。

       EtS构造要求一个强安全签名协议,在这个构造中,如果没有一个强安全的签名协议,将会导致一个对密文的CCA攻击,如果一个敌手获得一个挑战密文(c,s), 敌手可以针对同样的密文伪造一个签名s1。那么,敌手就可以使用挑战密文(c,s1)进行一次解密询问,并赢得该次CCA游戏,在签密模型中,解密请求是允许这个解密请求的,如果想要规避这个问题,在后文中有两个具体的方法,但是都伴随一定的安全性牺牲。为了防止签名不安全导致CCA被攻破,要求签名方案必须是具有很强的安全性。相反,StE就不需要这样一个强安全数字签名。

下面给出两个构造的安全性定理:

定理13.8 指出一个EtS协议是安全的签密,如果使用一个CCA安全的公钥加密协议和一个强安全的数字签名协议。

对于任意的密文完整性敌手Aci, 该敌手运行攻击游戏13.5(签密完整性攻击游戏),那么存在一个伪造签名敌手Bsig可以调用Aci, 赢得攻击游戏13.2,该敌手的优势描述如下:

                         

另外,对于任意的CCA敌手针对EtS方案运行攻击游戏13.6,那么存在一个CCA敌手Bcca, 和一个强签名敌手Bsig, 这两个敌手可以调用Acca赢得各自的挑战游戏,该敌手的优势描述如下:

                 

 定理13.8 证明:

       密文完整性证明:

       存在一个签名敌手Bsig与签密中的S挑战者进行交互,并且该Bsig敌手扮演攻击游戏13.5中敌手Aci的挑战者角色,Bsig 首先从自己的S签名挑战者处获得一个签名公钥Pk*,此时注意,该签名私钥Bsig是不知道的,该签名私钥是由S签名挑战者保存的,给出下图来描述这个过程:

       下一步,敌手Aci 选择两个身份IDS 和 IDR。Bsig 为这个两个身份生成签名公私钥对和加密公私钥对。其中IDS的签名密钥是由Bsig之前从其挑战者处获得的,Bsig期望攻击这个公钥对应的签名方案,过程如下图所示:

PKS 和 PKR的具体内容描述如下:

                       

Bsig这里是知道所有的公钥-私钥的,除了PK* 对应的私钥不知道。

然后Aci 向 Bsig 发出以下加密与解密请求,具体过程如下图所示(此处聚焦B和A的交互,暂时不看Signature-challenger的情况)

   

根据之前的签密模型,这里给出具体的细节,敌手可以询问S发送给R,S发送给其他人Y,R发送给其他人的加密信息,这里的两个S-Y并不是写错,X可以指代S或者R是两种情况。其中,S发送的签名都是由Bsig 对应的挑战者代为签名的,因为Bsig并不掌握S的签名私钥,这是其想要攻破的签名算法实例。

Bsig 回复Aci的解密询问通过直接调用EtS的解密算法,因为此时Bsig掌握所有的加密的私钥和所有的验证公钥,这里直接给出一个简单的描述图。

 Bsig掌握所有的签名公钥和解密私钥,所以此处仅仅按照流程正确运行解密算法即可。

如图,在多次询问后,敌手最终输出一个伪造的密文,这个密文对应的明文是不能在S->R中进行过加密询问的(对应签名定义中,挑战签名是不能进行签名询问的)。那么,这个输出就是针对签名协议S的一个强伪造。这种情况失败的唯一可能为,敌手对C`进行过一次签名询问,并最终获得了签名内容,特别是签名内容包括了IDR,这更是一个关键性证据。该签名询问被实现在了上述签密的S->R加密询问中。我们可以得到,挑战者不能生成该伪造签名,因为伪造的密文应当与所有S-R中由Bsig 做过加密询问的结果不同。所以,这里得到该伪造是一个合法的强存在性伪造。换句话说,(1)该消息的签名没有询问过,意味着伪造签名对应的消息是新的。(2)伪造的签名和之前任何询问过的明文签名都不同,不存在一个明文对应两个签名的情况。故而,本质上就是在要求此处的签名协议组件必须是强安全的。也就是,如果存在强安全的数字签名协议,EtS的方案密文完整性可以得到保证。

       选择密文安全性:

       首先定义Game0 作为原始的签密CCA游戏,该游戏由EtS挑战者和一个CCA敌手组成,接着定义游戏Game 1. Game 1 和 Game 0 表现是完全相同的,除了增加了一个“特殊拒绝条件”在挑战者的S->R解密请求的逻辑中。也就是,如果给与一个S-》R的解密请求,该请求中签名是之前在S-R加密请求中出现过的,那么挑战者直接拒绝解密。模型如下图所示:

       不难看出,这两个游戏运行起来后表现是相同的,除非挑战者在Game1中拒绝某个解密,而在Game 0中没有拒绝。(注意,这是会发生事件,因为在Game 0中没有对签名是否询问的特殊性检测)如果这里的解密询问时一个强存在性伪造。那么我们可以构造一个敌手Bsig`其优势等于在Game1中被检测出来的概率。

        现在构造一个敌手Bcca, 其优势等于Acca的优势在Game 1中的优势,和往常一样,Bcca与自己的CCA挑战者进行交互,并在Game1中扮演Acca的挑战者在游戏1中。

 敌手Bcca 首先从自己的CCA挑战者处获取公钥,然后,选择两个身份IDS和IDR,

公钥内容为:

        这里将R的公钥设置为挑战者生成是合理的,因为S在模型中是发送消息的一方,解密请求显然是询问R的,所以R就是CCA的关键询问对象。

加密请求:

       除了不知道私钥的那部分密文需要由标准CCA挑战者生成,剩下的任何加密内容BCCA都可以自主完成。

 

CCA解密请求如上图描述,S-R阶段,需要进行一个签名是否出现过的验证,如果存在一个强伪造敌手,在此处也会被侦测到,从而拒绝解密。所以说,如果此处不加这个签名的验证,那么CCA将会被直接自然的攻破,在该攻击游戏中,(c,\sigma) 和 (c,{\sigma }')视为不同的询问,如果存在一个强伪造性敌手,那么这两个请求都会被解密询问接受,那么CCA游戏将被攻破。如果对C加以甄别,那么就可以过滤掉这种情况,CCA模拟将是完备的,故得到:

 类似的给出StE方案的安全性定理:

 13.7.4  A construction based on Diffie-Hellman key exchange

 这里给出一个不需要使用签名的签密方案。这里使用一个非交互式的DH密钥协商方案。

方案构造如下:

这里需要考虑一个问题,结合签密的模型,ICDH假设在这里将不在适用,这里给出一个符合安全模型的新攻击游戏:

 进一步,给出安全定理:

 这个定理的安全性证明从DH方案是一个安全的NIKE得到其安全性。

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

前向安全,如果发送者被腐化,那么之前会话内容将受到威胁,Alice向Bob发送了一条密文,过了一段时间,Alice遭到盗用,其私钥被敌手盗走。那么我们期望,即使在这种情况下,敌手也无法使用盗用的私钥解密之前的加密消息。也就是说CCA安全依然存在,即使敌手获得了发送者的私钥。那么针对之前的签密的CCA攻击游戏,就需要进行一定的改动,仅仅修改set up阶段即可。这里给出修改后的签密攻击游戏如下: 

Forward secrecy for sign-then-encrypt:

        对于StE构造,发送者的私钥仅仅用来签名,并不会帮助敌手进行解密,所以这个构造是支持前向安全的。从安全定理13.9可以看出,这个方案的SCCA安全性完全不依赖于数字签名,仅仅依赖于最终使用的公钥签名方案的安全性。

Forward secrecy for encrypt-then-sign:

       在EtS方案中,最终的签密CCA安全性既依赖于数字签名的强安全,也依赖于方案中使用的公钥加密方案安全性。如果敌手具备强伪造性,那么根据签密CCA攻击游戏的规则,敌手可以直接进行CCA询问,攻破该CCA安全性(尽管并非敌手真的具有CCA攻击能力,利用了签密模型中的规则漏洞)。

        那么,在敌手不掌握签名私钥的情况下,只要使用了强安全的数字签名方案,亦是安全的,但是,如果此时敌手掌握强安全的签名的私钥。那么,由于签名是概率的,敌手可以任意重新对密文c进行签名,任意的发动上述CCA攻击。

        然而,这里并非没有办法抵抗这种情况,这里有两种方法抵抗这种攻击:

         (1)使用确定性签名(unique signatures),即使掌握密钥也不行,因为确定性签名必然只有一个合法的签名内容。

         (2)降低一定的安全性,在攻击游戏中不允许敌手提交这种解密询问,因为任何人都可以比较容易的检测到两种请求 虽然签名不同(都合法),但是加密的是同样的东西,这符合一种被称为gCCA安全的定义,并且在实际的应用中是相对可以接受的。

Forward secrecy for DH:

      DH签密方案在这里是不满足前向安全的,因为敌手一旦掌握发送者的私钥,那么他就获得了整个方案的会话密钥,这是显然的,因为通信双方都是使用同样的对称密钥加密消息。然而,如果进行一定的改造,那么该方案将在一定程度上保障前向安全。

改造的DH方案,加密时给与一个随机数,使用一个临时密钥解决问题:

但是这里需要注意一个问题,随机数Bata在这里是假定不能丢失的,要及时擦除内存中的临时数据,这在AKE协议中是一个非常重要的安全属性。下面给出该方案的安全性定理:

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

假设Alice加密一个消息给Bob,该消息定义为c。此时仅仅依靠 Bob的私钥和c 是否能够有足够的证据表明,该消息就是Alice发送的?这个属性称之为“不可抵赖性”,即发送发不可抵赖发送的消息非自身发出。然而,这是本章方案的一个固有限制,假设Alice宣称自己的密钥被偷窃或者其主动泄露,从而否认消息是来自于自己。由于不可抵赖性在某些条件下是必须的,所以这里定义这个属性,并展示如何构造提供该属性的方案。不可抵赖性也是一个有用的属性,作为一个实用的抵抗Bob私钥被盗用的攻击,否则,敌手可以获得Bob的私钥,然后假装ALice给Bob发送消息,这称之为key compromise impersonation or KCI. 不可抵赖性去报了Bob的秘钥不能被用来模拟Alice,因此KCI攻击是不可能的。

不可抵赖性定义与攻击游戏:

 Non-repudiation for encrypt-then-sign.

       EtS方案提供了不可伪造性,因为接收者的私钥仅仅用来解密,不会帮助敌手进行签名,所以敌手腐化接收者也无法伪装发送者给别人发送消息。

Non-repudiation for sign-then-encrypt.

       在StE方案密文完整性既依赖于签名也依赖于加密,实际上无法提供不可抵赖性。敌手获得了接收者的私钥,总是可以先解密获得明文然后再重新加密,则得到一个新的密文(概率性加密),这个密文依然是合法的,那么敌手就相当于可以假装Alice向Bob发送消息。那么,实际上其满足的是一种更弱的安全属性,即明文完整性,而不是密文完整性。可以通过修改完整性攻击游戏实现这个定义,即要求伪造的密文解密的明文不能是在S-R加密中请求过加密的明文。

总结

首先给出本章所以提方案的一个安全属性总结图示:

 

       前向安全是一个非常有用的属性在真实的世界中,而不可抵赖属性往往是根据上下文,不一定总是需要。满足前向安全但是不满足不可可抵赖性,修改版DH方案是满足的。从这两个需求来看,EtS 方案相对较好一些,尽管只提供了一个比较弱一点的CCA安全。一些ETS的方案变体可以同时满足上述两种属性。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值