Introduction to Modern Cryptography-Key Management and the Public-Key Revolution(密钥管理与公钥改革)

1.Key Distribution and Key Management(密钥分配与管理)

How can the parties share a secret key in the first place?

        显然,密钥不能简单地通过不安全的信道发送。由于窃听对手将能够观察到密钥,必须使用一些其他机制。

        在一些情况下,各方可以访问可靠地共享秘密密钥的安全信道。一个常见的示例是各方能够使用受信任的信使服务作为安全通道,但这样通信更慢,成本更高。该方法已经被用于在政府、外交和军事设置中共享密钥。例如,20世纪60年代连接莫斯科和华盛顿的“红色电话”是用一次性密码本加密的,从一个国家飞往另一个国家的信使携带装满打印件的公文包共享密钥。

        假设N个员工能够以某种方式安全地彼此共享密钥,一个显著的缺点是每个员工必须管理和存储N-1个密钥(公司中每个其他员工一个)。事实上,所有这些密钥都必须安全存储。密钥越多,就越难保护它们,并且某些密钥被攻击者窃取的可能性就越高。计算机系统经常被病毒、蠕虫和其他形式的恶意软件感染,这些恶意软件可以窃取密钥并通过网络悄悄地将它们发送给攻击者。因此,将密钥存储在员工的个人计算机上并不总是安全的解决方案。

        需要明确的是,无论各方持有多少密钥,密钥的潜在泄露始终是一个问题。然而,当只需要存储几个密钥时,有很好的解决方案可用于处理这种威胁。一个典型解决方案是将密钥存储在安全硬件上,例如闪存盘。加密器可以使用存储的密钥进行加密计算,确保这些密钥永远不会进入用户的个人计算机。如果设计得当,智能卡比个人电脑更能抵御攻击,例如,它通常不会被恶意软件感染,因此提供了一种保护用户密钥的好方法。不幸的是,智能卡通常在内存中非常有限,因此不能存储数百(或数千)个密钥;它们也可能有点昂贵,并且如果丢失则难以更换。

        上面列出的问题都可以在原则上解决,即使不是在实践中,在“封闭”的组织组成的一个定义明确的人口的用户,他们都愿意遵循相同的政策来分配和存储密钥。然而,在“开放系统”中,用户有短暂的交互,甚至可能在他们第一次想要交流之前都不知道对方的存在。更常见的情况:将信用卡信息发送给您以前从未购买过任何东西的互联网商家,或者向您从未见过面的人发送电子邮件。在这种情况下,单独的私钥加密根本无法提供解决方案,我们必须进一步寻找适当的解决方案。

        总而言之,至少存在三个与使用私钥加密相关的不同问题:

密钥分发的问题;存储和管理大量密钥的问题;私钥加密不适用于开放系统

2.A Partial Solution: Key-Distribution Centers

       可以使用密钥分发中心(KDC)来建立共享密钥。一个大公司中所有成对的雇员必须能够安全地通信。在这样的设置中,我们可以利用这样一个事实,即所有员工都可能信任某个实体,比如系统管理员,至少在与工作相关的信息的安全性方面是这样。然后,这个可信实体可以充当KDC,帮助所有员工共享成对密钥。

       当两个员工希望安全通信时,以在线方式利用KDC“按需”生成密钥,从而避免要求员工存储和管理多个密钥。和以前一样,KDC将与每个员工共享一个不同的密钥,这可以在每个员工工作的第一天安全地完成。假设KDC与雇员Alice共享密钥kA,与雇员Bob共享密钥kB。在稍后的某个时间,当Alice希望与Bob安全地通信时,她可以简单地向KDC发送消息“我,Alice,想要与Bob通话”。(If如果需要,可以使用Alice和KDC共享的密钥对该消息进行身份验证。然后KDC选择一个新的随机密钥(称为会话密钥),并将此密钥k发送给使用kA加密的Alice,并发送给使用kB加密的Bob。(This协议过于简单,无法在实践中使用;参见下面的进一步讨论。)一旦Alice和Bob都恢复了这个会话密钥,他们就可以使用它来安全地通信。当他们完成对话时,他们可以(并且应该)擦除会话密钥,因为如果他们希望在以后的某个时间进行通信,他们总是可以再次联系KDC。

the advantages of this approach:

1.每个员工只需存储一个长期密钥(即与KDC共享的密钥)。当一个员工加入组织时,所要做的就是在这个员工和KDC之间建立一个密钥。其他员工不需要更新他们持有的密钥集。

2.KDC需要存储许多长期密钥。但是,KDC可以保存在一个安全的位置,并被赋予最高可能的保护,防止网络攻击。

some drawbacks to relying on KDCs:

1.对KDC的成功攻击将导致系统的完全破坏

2.KDC是一个单点故障:如果KDC关闭,安全通信将暂时无法进行。


Protocols for key distribution using a KDC

        在文献中存在用于使用KDC的安全密钥分发的许多协议。Needham-Schroeder协议,它构成了Kerberos的核心,Kerberos是一种重要且广泛使用的服务,用于执行身份验证和支持安全通信。我们只强调这个协议的一个特点。当Alice联系KDC并请求与Bob通信时,KDC不会像我们前面描述的那样将加密的会话密钥发送给Alice和Bob。相反,除了在Bob的密钥下加密的会话密钥之外,KDC还向Alice发送在Alice的密钥下加密的会话密钥。然后,Alice将第二个密文转发给Bob。如下图所示,第二个密文有时被称为票据,并且可以被视为允许Alice与Bob交谈的凭证(并且允许Bob确信他正在与Alice交谈)。

        基于KDC的方法也可以提供执行身份验证的有用手段。还需要注意的是,Alice和Bob不需要都是用户; Alice可以是用户,Bob可以是资源,例如远程服务器、数据库或打印机。该协议以这种方式设计,以减少KDC上的负载。在所描述的协议中,KDC不需要向Bob发起第二连接,并且当Alice发起协议时不需要担心Bob是否在线。此外,如果Alice保留了票据(以及她的会话密钥副本),那么她可以通过简单地将票据重新发送给Bob来重新发起与Bob的安全通信,而根本不需要KDC的参与。(实践中,门票到期,最终需要续订。但是可以在某个可接受的时间段内重新建立会话。)最后,我们注意到,在实践中,Alice与KDC共享的密钥可能是一个简短的、易于记忆的密码。在这种情况下,出现了许多必须处理的附加安全问题。


3.Key Exchange and the Diffie–Hellman Protocol

        KDC和像Kerberos这样的协议在实践中被使用。但在某些时候,解决密钥分发问题的这些方法仍然需要一个私有的、经过身份验证的通道来共享密钥。(特别是,我们假设在员工第一天上班时,KDC和员工之间存在这样一个渠道。)

        为了在不通过私有信道进行通信的情况下实现私有通信,需要一种完全不同的方法。1976年,Whitfield Diffie和Martin Hellman发表了一篇论文。在这项工作中,他们观察到世界上经常存在不对称性;特别是,有些行为可以很容易地执行,但不容易逆转。例如,挂锁可以在没有钥匙的情况下被锁定(即,很容易),但无法重新打开。更引人注目的是,打碎一个玻璃花瓶很容易,但要把它重新组装起来却极其困难。

        在算法上,将两个大素数相乘很容易,但很难从它们的乘积中恢复这些素数。(因子分解问题)Diffie和Hellman意识到,这种现象可以用于导出安全密钥交换的交互式协议,该协议允许双方通过公共信道上的通信来共享密钥,方法是让双方执行窃听者无法逆转的操作。

        安全密钥交换协议的存在是相当惊人的。这意味着你和一个朋友可以通过简单地在房间里大喊大叫(并执行一些局部计算)来达成共识;这个秘密对其他任何人来说都是未知的,即使他们听到了所说的一切。事实上,直到1976年,人们普遍认为,如果不首先使用私人信道共享一些秘密信息,就无法进行安全通信。迪菲和赫尔曼的论文的影响是巨大的。除了引入了一种全新的密码学方法之外,它还是将密码学从私人领域转移到公共领域的第一步。


The setting and definition of security

        我们考虑一个设置与两个当事人-传统上称为爱丽丝和鲍勃-谁运行的概率协议,以生成一个共享的、秘密的密钥,可以被视为一组指令的爱丽丝和鲍勃在协议。Alice和Bob开始时持有安全参数1 n;然后他们使用(独立的)随机位来运行加密。在协议结束时,Alice和Bob分别输出密钥kA、kB ∈ {0,1}^n。基本的正确性要求是kA = kB。由于我们将只处理满足这个要求的协议,我们将简单地说在Π的一些诚实执行中生成的密钥k = kA = kB。(由于密钥是随机化的,因此通常每次运行密钥时密钥都会不同。)

        我们现在转向定义安全性。直观地说,如果Alice和Bob输出的密钥对窃听对手完全隐藏,则密钥交换协议是安全的。这是通过要求窃听协议执行的对手应该无法区分由该执行生成的密钥k(并且现在由Alice和Bob共享)与长度为n的统一密钥来正式定义的。这比简单地要求对手不能准确地猜测k强得多,并且如果各方随后将使用k用于一些加密应用(例如,作为私钥加密方案的密钥)。将上述形式化,设Π是密钥交换协议,A是对手,并且n是安全参数。我们有以下实验:

        密钥交换协议Π在存在窃听者的情况下是安全的,如果对于所有概率多项式时间对手A,存在可忽略的函数negl,使得


The Diffie–Hellman key-exchange protocol


Diffie–Hellman key exchange in practice

        对手在与另一方交互时冒充一方,及中间人攻击,其中诚实的双方都在执行协议,而对手正在拦截和修改从一方发送到另一方的消息。然而,值得注意的是,Diffie-Hellman协议对于中间人攻击是完全不安全的。事实上,中间人攻击者可以以这样的方式行动,即Alice和Bob使用对手都已知的不同密钥kA和kB终止协议,然而Alice和Bob都不能检测到进行了任何攻击。

        如上所述,由于Diffie-Hellman协议对中间人攻击的不安全性,其基本形式的Diffie-Hellman协议通常在实践中不使用。这丝毫无损于它的重要性。Diffie-Hellman协议首次证明了非对称技术(和数论问题)可以用来缓解密码学中的密钥分发问题。此外,Diffie-Hellman协议是标准化密钥交换协议的核心,该协议对中间人攻击具有弹性且目前被广泛使用。一个值得注意的例子是TLS。


4.The Public-Key Revolution

        除了密钥交换之外,Diffie和Hellman还在他们的开创性工作中引入了公钥(或非对称)密码学的概念。在公钥设置中,希望安全通信的一方生成一对密钥:一个广泛传播的公钥和一个保密的私钥。生成这些密钥后,一方可以使用它们来确保使用公钥加密方案接收的消息的保密性,或使用数字签名方案发送的消息的完整性。

        在公钥加密方案中,由某方生成的公钥用作加密密钥;任何知道公钥的人都可以使用它来加密消息并生成相应的密文。私钥用作解密密钥,并由知道它的一方使用,以从使用匹配公钥生成的任何密文中恢复原始消息。更令人惊讶的是,这样的东西存在!即使对于知道公钥(但不知道私钥)的对手,也能保持加密消息的保密性。

        为了允许秘密通信,接收者可以简单地将她的公钥发送给潜在的发送者(而不必担心窃听者观察到它),或者在她的网页或一些中央数据库中公开她的公钥。因此,公用钥匙加密方案能够使私人通信不依赖私人渠道分发钥匙。

        数字签字方案中,私钥用作“身份验证密钥”(称为签名密钥),使知道此密钥的一方能够为其发送的消息生成“身份验证标签”(又名签名)。公钥充当验证密钥,允许知道它的任何人验证发送方发出的签名。与MAC一样,数字签名方案可用于防止对消息进行未被检测到的篡改;然而,在这里,即使对手知道公钥,也能保持安全性。验证是公开的(即,可以由任何知道发送者公钥的人完成)具有深远的影响,因为它可以将Alice签名的文档提交给第三方(例如,法官)进行验证。该属性被称为不可否认性,并且在电子商务中具有广泛的应用(例如,签署法律的文件)。数字签名也用于安全分发公钥,作为公钥基础设施的一部分。

最后总结一下公钥密码学如何解决私钥设置的局限性:

1.公钥加密允许通过公共(但经过验证的)通道进行密钥分发。这可以简化共享密钥的分发和更新。

2.公钥加密减少了用户存储许多秘密密钥的需要。使用公钥加密,每个员工只需存储一个私钥(他们自己的)和所有其他员工的公钥。重要的是,后面这些密钥不需要保密;它们甚至可以存储在某个公共存储库中。

3.最后,公钥加密更适合于开放环境,在这种环境中,以前从未交互过的各方希望能够安全地进行通信。作为一个常见的例子,公司可以在线发布其公钥;当用户需要加密其信用卡信息以发送给该公司时,可以根据需要购买该公司的公钥。


为什么要研究私钥加密?

        显然,公钥加密比私钥加密严格更强;特别是,任何公钥加密方案都可以用作私钥加密方案。(通信用户可以简单地共享公钥和私钥。如果加密消息的保密性即使在窃听者知道公钥的情况下也成立,那么当公钥被保密时,它显然也成立!)那么,我们为什么还要费心去研究私钥密码学呢?答案很简单:私钥加密比公钥加密有效得多,应该在适当的环境中使用。也就是说,在通信各方有可能共用一把钥匙的情况下,应当使用专用钥匙加密法。这包括小规模、封闭的用户系统以及磁盘加密等应用程序。此外,在公钥设置中使用私钥加密以获得更好的效率。

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值