第六章实用安全系统_第1页
第六章实用安全系统_第2页
第六章实用安全系统_第3页
第六章实用安全系统_第4页
第六章实用安全系统_第5页
已阅读5页,还剩72页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第六章实用安全系统目录6.1PGP6.2S/MIME6.3SecureShell6.4SFTP6.1PGP

PGP是美国菲利普·齐默曼(PhilipR.Zimmermann)提出来的。他创造性地把RSA公钥体系的方便和传统加密体系的高速度结合起来,并且在数字签名和密钥认证管理机制上进行巧妙的设计,从而使PGP成为流行的公钥加密软件包。PGP是一个基于RSA公钥加密体系的邮件加密软件,可以用于邮件保密,防止非授权者阅读,还能对邮件加上数字签名,从而使收信人可以确信邮件是谁发来的。它让用户可以安全地和用户从未见过的人通信,事先并不需要任何保密的渠道来传递密钥。6.1.1PGP原理PGP加密由一系列散列、数据压缩、对称密钥加密,以及公钥加密的算法组合而成。每个步骤支持几种算法,可以选择其中一种使用。基本上包含了4个密码单元:单钥密码IDEA、双钥密码RSA、单向散列算法MD5、一个随机数生成算法。这些密码单元在本书第2章中都有相关介绍。

需要注意的是,随机数生成是指PGP提供两个伪随机数发生器(PRNG):一个是ANSIX9.17发生器,采用IDEA算法,以CFB(密码反馈模式)生成;另一个是从用户击键的时间和序列中计算熵值,从而引入随机性。PGP在安全上的业务有:认证、加密、压缩、Base-64变换、分段和重组。

1.认证PGP可以只签名而不加密。这适用于公开发表声明、声明人为了证实自己的身份,可以用自己的私钥签名,这样就可以让收件人确认发信人的身份,也可以防止发信人抵赖自己的声明。PGP认证流程如图6.1所示。

图6.1PGP认证流程

送信人编制消息M准备发出,用MD5算法产生一个128位的散列值H,并且用送信人的RSA密钥对H签字,然后将M和H合成压缩发送出去,接收端对收到的数据进行解压,并用发送人公钥解出H,用接收的M计算散列值得H',与H值进行比较签字。2.加密

加密过程如图6.2所示,密钥管理模块根据用户输入的收信人标识信息,找到收件人的公钥。随机数生成器产生仅使用一次的128位会话密钥,IDEA算法利用这个会话密钥对经压缩后的明文信件进行加密,生成密文信件。同时,RSA算法模块利用收件人的公钥对会话密钥再加密。最后,PGP把RSA加密后的会话密钥与IDEA加密后的密文信件合并在一起,形成一个新的文件并输出在磁盘中。由于PGP在调用IDEA算法模块加密文件之前,已对文件做了压缩处理,因此,输出的文件的容量不会增大。图6.2加密过程

由于PGP每次加密都使用一个随机的128位会话密钥,因此同一个文件两次加密后的结果是截然不同的。图6.2中的randseed.bin文件就是用来构造这个随机会话密钥的。由于每次使用不同的会话密钥,因此,进一步增加了PGP加密的可靠性,也防止了窃取者获悉双方是否在传送同一内容的文件的可能性。

如图6.3所示是PGP接收加密邮件之后的解密过程。

首先,PGP把接收到的密文分成两部分:第一部分是经RSA算法加密的会话密钥,另一部分是经IDEA算法和会话密钥加密的原文件内容。接着,PGP接收来自用户的口令。口令经过SHA-1报文分解函数产生一个128位的IDEA解密密钥。PGP的密钥管理模块取出密钥环文件中经加密的RSA解密密钥,用IDEA解密钥匙和IDEA解密算法恢复出明文的RSA秘密密钥。最后,PGP用RSA秘密密钥和RSA解密模块恢复出明文的会话密钥,再用会话密钥和IDEA解密算法一起解密加密的原文件内容。此外,PGP需要恢复被压缩的文件。图6.3解密过程3.压缩

压缩可以节省通信时间和存储空间,而且在加密前进行压缩可以降低明文的冗余度,增强机密效果。PGP中采用ZIP算法进行压缩。4.Base64编码变换Base64编码变换是为了提高电子邮件的兼容性而设置的。因为许多电子邮件系统只允许使用ASCII文本串,所以PGP提供了将8位组串转换为ASCII字符的功能。转换方法是将每3个8位组串的二元数据映射为4个ACSII字符。虽然转换后消息长度有所扩展,但压缩的效果足以弥补扩展带来的影响。实例表明,总体压缩和扩展抵消后大约仍有1/3的压缩。

同时它还具有以下特点:不限于某一特定的字符集编码;字符集有65个可以打印的字符,每个字符表示6位输入,一个字符作为填充;字符集中不含控制字符,故可通行于E-mail系统;不要使用“_”符号,此符号在RFC832中有特定意义,应避免使用。5.分段和重组E-mail对消息长度都有限制。当消息大于长度限度时,PGP将对其自动分段。分段是在所有处理之后进行的,故会话密钥和签字只在第一段开始部分出现。在接收端,PGP将各段自动重组为原来的消息。

PGP的开发是密码学应用的一个重要的里程碑,它是第一个将公钥密码服务于大众的工具。PGP主要针对电子邮件加密,从计算角度来看,PGP是足够安全的,但是不恰当的信任假设往往是PGP的隐患,最终导致秘密的泄露。理解PGP的信任模型,正当使用软件,是获得PGP安全性的重要前提。6.1.2PGP信任模型信任模型是指建立在信任关系和验证证书时寻找和遍历信任路径的模型。信任模型分为三种:1、直接信任(DirectTrust):

指两个实体之间曾经有过直接的交易,它们之间建立了一种直接信任关系,信任值来源于根据双方的交易情况得出的直接经验。2、等级信任(HierarchicalTrust):

又称推荐信任,指两个实体之间没有进行直接的交易,而是根据其他实体的推荐建立的一种信任关系,它们之间的信任值是根据其他实体的评估得出的结果。在PGP中,等级信任分为4个等级:绝对信任(用户本人)、完全信任、一般信任以及不信任。3、网络信任(AWebofTrust):

网络信任模型是PGP所用到的信任模型,它包含了其他两种模型,另外增加了第三方监督者的概念。

在PGP中,存在两种密钥环:私钥环和公钥环。其中,公钥环为PGP信任模型提供了实现方式,形成了信任网(WebofTrust)结构。在信任网中,没有大家都信任的中心权威机构,而是用户以各自为中心,相互认证公钥,相互签名公钥证书。这些签名使得用户的公钥彼此相连,形成自然的网状结构,就是信任网[4]。为了更好地理解信任网,我们假设Alice和Bob是两个同事,他们彼此熟悉,通过某种方式,Alice获得了Bob的公钥,并且确认Bob的公钥是真实的,因此,Alice就在Bob的公钥证书上签名。此时,Alice认为Bob的公钥是有效的,并可以利用Bob的公钥将加密后的信息传给Bob,加密后的信息只有Bob能够解读。这种信任关系用实线箭头表示,如图6.4所示。相互信任的用户之间分别为对方的公钥签名,使他们之间建立了某种联系,这种联系就是信任网的基础结构。图6.4信任网的基础结构

假设David和Bob并不认识,David想与Bob进行安全通信,必须要解决的问题是:David如何获得Bob的有效公钥?在PGP中是这样解决的:假设David知道Alice,并有Alice的有效公钥。David相信Alice不会欺骗她,就将Alice设为可信介绍人,并从Alice那里得到Bob的公钥(或者由Bob传给David)。因为Bob的公钥证书中有Alice的签名,所以David可以相信Bob的公钥是有效的。图6.4中用虚线箭头来表示David对Alice的信任。

如果David在Bob传给他的公钥中找不到一个可信的介绍人,则不能相信Bob的公钥,Bob的公钥将被认为是无效的。因此,为了使他们之间能够相互信任,Bob必须找到David的一个可信介绍人为其证书签名。其中,PGP证书由以下三部分组成:①用户ID:由用户名及其邮箱地址组成。②公钥:由公钥ID(全局唯一)、公钥数据和创建时间组成。③若干签名:由一些对前两项关系认同的中间人的签名组成。PGP为公钥附加信任和开发信任信息提供了一种方便的方法来使用信任。公钥环的每个实体都是一个公钥证书。与每个实体相联系的是密钥合法性字段,用来指示PGP信任“这是这个用户合法的公钥”的程度。信任程度越高,这个用户ID与这个密钥的绑定越紧密。这个字段由PGP计算。与每个实体相联系的还有用户收集的多个签名。反过来,每个签名都带有签名信任字段,用来指示该PGP用户信任签名者对这个公钥证书的程度。PGP公钥环结构如图6.5所示。图6.5PGP公钥环结构图6.5说明如下:TimeStamp:公钥生成的时间。KeyID:用户公钥标识,它由公钥的最低64位组成(KUimod264),这个长度足以使密钥ID的重复概率非常小。PublicKey:公钥值。UserID:用户标识。二元组(KeyID、UserID)唯一确定一个公钥项。Signature:用户收集的对该PGP公钥进行的一个或多个签名。OwnerTrust、SignatureTrust、KeyLegitimacy:与用户公钥相关的三个信任指示字段。每个信任指示字段用一个TrustFlag字节表示,分别为OWNER-TRUSTField、SIGTRUSTField、KEYLEGITField,并加上1位警示位。这三个指示字段共同决定一种PGP信任关系。OwnerTrust字段表明PGP用户对“公钥主人对其他公钥签名”的信任程度。信任程度越高,该公钥主人签名的密钥越可信。这个信任程度是由用户给出的。SignatureTrust字段表明PGP用户信任签名者对这个公开密钥证明的程度。信任程度越高,该公钥越可信。

而KeyLegitimacy字段用来指示PGP信任“这是这个用户合法的公钥”的程度。信任程度越高,这个用户ID(UserID)与这个密钥的绑定越紧密。这个字段值由PGP计算出来。假定正在处理用户YOU的公钥环,上述三个指示字段的值按如下方式确定:

(1)OwnerTrust字段:当YOU向公钥环中插入一个新公钥时,如果公钥主人是YOU,则OwnerTrust字段对应的OWNER-TRUSTField的值为终极信任(UltimateTrust)。否则,PGP询问用户,让用户给出信任级别:未知(Unknown)、不可信任(Untrusted)、通常可信(UsuallyTrusted)和总是可信(AlwaysTrusted)等。

(2)SignatureTrust字段:当新公钥有一个或多个签名时,以后的多个签名需要逐个加入。当插入一个签名时,PGP将查找公钥环,看该签名人是否是已知公钥的主人。如果是,则该签名对应的SIGTRUSTField的值为该已知公钥主人对应的OWNER-TRUSTField的值。否则,为UnknownUser,表示PGP不认识签名人。因此可以把SignatureTrust字段看成是来自于其他OwnerTrust字段的副本。

(3)KeyLegitimacy字段:KEYLEGITField的值基于该条目中SignatureTrust字段来计算。如果至少一个Signature对应的SIGTRUSTField的值为UltimateTrust,则KEYLEGITField的值设为CompleteTrust。否则,PGP计算SIGTRUSTField的值的加权和。

假设对于AlwaysTrusted值的签名赋以权值1/x,对于UsuallyTrusted值的签名赋以权值1/y,当密钥用户ID绑定的权重总和达到1时,绑定被认为是值得信任的,则KEYLEGITField的值被设置为CompleteTrust。因此,在没有UltimateTrust的情况下,需要至少有x个SignatureTrust字段为AlwaysTrusted,或者至少有y个SignatureTrust字段为UsuallyTrusted,或者是上述两种情况的某种组合。PGP信任模型图如图6.6所示。图6.6PGP信任模型图

保证公钥的真实有效,是正确应用PGP的基础。证书为保证公钥的真实性提供了一种有效的机制,而在PGP中缺乏有效的证书管理体系,证书的管理完全由用户自己完成。错误的信任假设和管理的不当,会影响到PGP的安全性。PGP推荐用两种方式来保证证书的有效性:一是直接从所有者那里获得磁盘拷贝,二是通过中间人获取。磁盘拷贝的方式不适用于地理范围较大的场合,对中间人没有任何信任等级认定,很容易造成安全隐患。在公钥系统中,证书吊销是使公钥无效的有效方式。

在PGP中提供了两种吊销证书的方式:中间人吊销和拥有者自行吊销,二者具有同等的效力,均被认为使相关的密钥对无效。但证书吊销问题的真正难点不在于吊销本身,而在于将吊销信息通知每个潜在的使用者。用户使用被吊销的证书是一件很危险的事情,很有可能造成泄密,

因此在每次使用证书前都应该确信该证书没有被吊销。PGP中虽然提供了吊销证书的功能,但没有提供任何将吊销信息通知其他用户的方式,这是PGP的一个致命弱点。

通过PGP的介绍,可以看出PGP在信息加密之前都会进行数据压缩,这样可以大大减少数据的冗余度和加/解密所花费的时间。PGP不是去推广一个全局的PKI,而是让用户自己建立自己的信任网,即在PGP系统中,信任是双方直接的关系,或者是通过第三方、第四方的间接关系,但任意两方之间是对等的,整个信任关系构成网状结构。这样的结构既有利于系统的扩展,又有利于其他系统安全模式的兼容并存。

但这种信任模型中,没有建立完备的信任体系,不存在完全意义上的信任权威,缺乏有效的信任表达方式,所以它只适合小规模的用户群体。当用户数量逐渐增多时,管理将变得非常困难,用户也会发现其不易使用的一面。6.1.3PGP安全分析PGP也有其固有的缺点,从保密强度来看,PGP的安全薄弱环节是对加密算法IDEA的加密密钥的保护,对其采用邮件接收方的公钥加密、私钥解密的方法。所以,整个邮件内容的保密完全依赖于邮件接收方私钥的安全,而非发送方所能控制。一旦其他人得到此加密密钥,就可以得到邮件明文。另外,已经有人发现一种欺诈手段,即截获邮件后,对邮件重新包装并发给收件人,收件人得到的是一堆乱码,当收件人携带原件回信询问时,就可以破译加密的电子邮件。应对的方法是避免在回信询问时包含完整的原邮件。6.2S/MIME

目前,主流的电子邮件加密技术除了PGP外,还有S/MIME,两者都沿用IETF的标准,但彼此不兼容。下面详细介绍S/MIME。6.2.1MIME简介

早期的Internet电子邮件有两个核心协议:由RFC821定义的简单邮件传输协议(SMTP)和由RFC822定义的邮件格式文件。SMTP是一种TCP协议支持的提供可靠且有效电子邮件传输的应用层协议。SMTP是建立在TCP协议上的一种邮件服务,主要用于传输系统之间的邮件信息并提供来信有关的通知,并且独立于特定的传输子系统,只需要可靠有序的数据流信道支持。SMTP的重要特性之一是,其能跨越网络传输邮件,即“SMTP邮件中继”。SMTP规定了在Internet节点间的传送或接力传送电子邮件的协议,TCP端口25就是为此保留的。SMTP简单而且高效,从1982年RFC821发布至今,不曾有任何改动。RFC822定义了一种十分简单的邮件格式,这种格式的邮件只能包含纯文本信息,而且只能是ASCII字符,这显然影响了电子邮件的用途。

RFC822明确地把邮件分为两部分:第一部分为邮件头,其作用是标识邮件;第二部分是邮件体。邮件头中包含若干数据字段,可以在需要附加信息时使用。邮件头字段应出现在邮件体之前,两部分之间使用一个空行分隔。

邮件头最常用的字段是:From、To、Subject和Date。From标识发信人的电子邮箱地址,To标识收信人的电子邮箱地址,Subject标识邮件的主题,Date用来给邮件加上时间戳。如图6.7所示为一封RFC822兼容邮件的格式。图6.7RFC822兼容邮件的格式

由于SMTP和RFC822模式都只能传输ASCII文本信息,因此在运用时存在一定的局限性,MIME(MultipurposeInternetMailExtensions,多用途互联网邮件扩展)就是针对这一点对RFC822进行扩充,并且约定二进制数据进行编码的协议。

表6.1可以看出关于RFC822邮件和MIME邮件的对比。

RFC822邮件MIME邮件可以携带的内容纯文本信息HTML、图像、声音、文件可采用的字符US-ASCII多种字符集其他应用场合无可应用于HTTP协议表6.1RFC822邮件和MIME邮件的对比MIME协议定义了5个新的可以包含在RFC822报文首部的字段,分别是:MIME-Version、Content-Type、Content-Transfer-Encoding、Content-ID和Content-Description。MIME-Version(MIME版本):其值必须为1.0,表明该消息符合RFC2045和RFC2046。Content-Type(内容类型):描述正文中包含的数据类型,使得接收方代理可以选择合适的代理或机制来表示数据或正确处理数据。Content-Transfer-Encoding(内容转换编码):描述将消息正文转换为可以传输的类型转换方式。Content-ID(内容ID):在多重上下文中唯一地标识MIME实体。Content-Description(内容描述):正文对象的文本描述,在该对象不可读时使用(如音频数据)。图6.8显示了新的字段同标准邮件中RFC822字段是如何结合在一起的。

图6.8新的字段同标准邮件中RFC822字段结合在一起

同时,MIME中有大量关于内容类型定义的说明,体现了在多媒体环境下需要提供多种信息表示方法的需求,表6.2列出了RFC2046中说明的内容类型,主要有7种不同类型和15种子类型。一般来说,用内容类型来描述数据的通用类型,用子类型描述该数据类型的特殊格式。类

型子

型描

述TextPlain无格式文本,为ASCII码或ISO8859码Enriched提供丰富的文档信息MultipartMixed各部分相互独立但一起传送。接收方看到的形式与邮件消息中的形式相同Parallel除了在传送时各部分无序外,其余与Mixed相同Alternative不同部分是同一消息的不同表现形式,按增序排列,接收方系统将按照最佳方式显示Digest与Mixed相似,但每部分默认的类型/子类型为Message/rfc822Messagerfc822封装消息的正文与RFC822一致Partial允许按接收方透明的方式对大邮件分段Extended-body包含指向存在于某个其他地方对象的指针ImagejpegJFIF编码的JPEG图像gif图像为GIF格式VideompegMPEG格式的视频AudioBasic单通道8bitISDN编码的音频,采样率为8kHzApplicationPostScriptAdobePostScriptOctet-stream一般8bit组成的二进制数据表6.2RFC2046中说明的内容类型

对于报文主体的Text(正文)类型,除了需要对指定字符集的支持外,不需要专门的软件来获得正文的含义。主要的子类型是Plain(纯文本),就是简单的由ASCII字符或ISO8859字符组成的字符串。Enriched子类型允许更大的格式灵活性。

Multipart类型指示报文主体包含多个独立的部分。content-type首部字段包含称为boundary(边界)的参数,定义了在报文的不同部分之间的分隔符,这个边界不应该出现在报文的任何一个部分内。每个边界开始于一个新行,由两个字符后跟着一个分隔符组成,用于指示最后一个部分结束的最后一个边界还有两个连字符作为后缀。在报文主体的每个部分,可以存在可选的普通的MIME首部。

Message类型提供了MIME的一个重要功能。Message/rfc822子类型指示报文主体是完整的报文,包括首部和主体。尽管使用了这种子类型名,但包装的报文可以不仅仅是简单的RFC822报文,而是任何MIME报文。

Application类型指的是其他类型的数据,典型的是邮件应用程序不理解的二进制数据或信息。S/MIME(SecureMultipurposeInternetMailExtension,安全的多用途互联网邮件扩展)是基于RSA数据安全技术的MIMEInternet电子邮件格式的安全扩展,是一种用于发送和接收安全MIME数据的协议。

在MIME协议的基础上,S/MIME增加了以下两类安全特性:

①通过数字签名,可以验证数据来源的真实性、检查数据的完整性,并且签名具有不可抵赖的特点。

②通过加密,可以保证数据的保密性。S/MIME也支持以上两种安全特性的复合。6.2.2S/MIME基本概念S/MIME是通过在RFC1847中定义的多部件媒体类型在MIME中打包安全服务的一种技术,可以提供验证、信息完整性、数字签名和加密服务。S/MIME是在PEM(PrivacyEnhancedMail,保密增强邮件)的基础上建立起来的,它选择RSA实验室开发的PKCS(Public-keyCryptographyStandard,公共密钥加密标准)作为它的数据加密和签名的基础,它使用PKCS#7数据格式作为数据报文,并使用X.509v3的数字证书。MIME允许对其content-type进行扩充,而S/MIME在其基础上增加了三种新的MIME子类型[5]:multipart/signed、application/x-pkcs7-signature、application/x-pkcs7-mime。前两种类型的组合支持签名邮件,后一种类型支持加密邮件。如果将签名邮件再进行一次加密,封装成后一种类型,就生成了签名加密邮件,理论上这种封装是没有限制的。因此,仅依靠这种对MIME类型的简单扩充,便可以实现复杂的安全应用。MIME协议的良好扩展性使得新特性的引入对原有结构的影响很小,事实上,虽然不支持S/MIME的系统不能处理安全电子邮件,但是MIME协议要求它的实现能够预见到可能出现的新的MIME类型,并且在处理时应尽量灵活。因此,当使用旧的邮件系统处理S/MIME邮件时,如签名电子邮件,虽然无法验证签名,但是被签名的内容还是可以阅读的。

图6.9是加密和签名的S/MIME电子邮件的格式示意图。当MIME类型为application/x-pkcs7-mime;mime-type=enveloped-data时,表示加密邮件;当MIME类型为multipart/signed时,表示签名邮件。

需要说明的是,上述安全电子邮件的格式并不是S/MIME给出的唯一格式,实际上S/MIME定义了一种加密邮件的格式,以及多种签名和加密签名邮件的格式。例如签名邮件的另一种格式是使用参数为smime-type=signed-data的application/x-pkcs7-mime类型,不过更普遍的情况使用multipart/signed类型。两者的区别是,在使用非S/MIME系统处理邮件时,前一种完全无法识别,后一种至少可以识别出被签名的内容,尽管系统不知道加在后面的签名是什么东西。这就是S/MIME系统喜欢采用这两种格式的原因。图6.9加密和签名的S/MIME电子邮件的格式S/MIME提供了以下的功能:

加密数据:这一功能允许用对称密码加密一个MIME消息中的任何内容类型,从而支持保密性服务,然后用一个或多个接收者的公钥加密对称密钥,接着将加密的数据和加密后的对称密钥以及任何必要的接收者标识符和算法标识符一起附加在数据结构的后面。

签名数据:这一功能提供完整性服务。发送者对选定的内容计算消息摘要,然后用签名者的私钥加密,初始的内容以及它的相应签名用Base64编码。

透明签名的数据:和签名数据一样形成内容的数字签名。但是这种情况只有数字签名部分使用Base64进行编码,因此没有S/MIME功能的接收者也可以看到报文的内容,尽管他不能验证签名。

签名且加密的数据:这一功能允许签名已加密的数据或者加密已签名的数据来提供保密性和完整性服务。

6.2.3S/MIME功能S/MIME中使用表6.3中列出的术语(来源于RFC2119)来说明需求级别。功

能要

求创建用于数字签名的数字摘要必须支持SHA-1,接收方应该支持MD5,以便以后兼容加密数字摘要形成数字签名发送代理和接收代理必须支持DSS发送代理应该支持RSA加密接收代理应该支持验证密钥大小在512~1024位之间的RSA签名为传送消息加密会话密钥发送代理和接收代理必须支持Diffie-Hellman发送代理应该支持密钥大小在512~1024位之间的加密接收代理应该支持RSA解密用一次性会话密钥加密消息发送代理应该支持3DES和RC2/40加密接收代理必须支持用3DES解密,应该支持RC2/40解密表6.3S/MIME中的需求级别MUST:在规格说明书中表示一定要满足的需求。实现时,必须包括其修饰的特性或与规格说明中的功能一致。SHOULD:如果在特定条件下有合理的理由,则可以忽略其修饰的特性或功能,但推荐其实现包含其特性或功能。S/MIME组合三种公钥算法。DSS(DigitalSignatureStandard)是其推荐的数字签名算法。Diffie-Hellman是其推荐的密钥交换算法,实际上,在S/MIME中使用的是其能加密/解密的变体ElGamal。RSA既可以用作签名,也可以加密回话密钥。规格说明推荐使用160位的SHA-1算法作为数字签名的Hash函数,但要求接收方能支持128位的MD5算法。S/MIME规格说明包括如何决定采用何种加密算法。从本质上说,一个发送方代理需要进行如下两个抉择:发送方代理必须确定接收方代理是否能够解密该加密算法。如果接收方代理只能接收弱加密的内容,那么发送方代理必须确定弱加密方式是否可以接受。

为达到上述要求,发送方代理可以在它发送消息之前先宣布它的解密能力,由接收方代理将该消息存储,留给将来使用。

发送方代理必须按照如下顺序遵守如下规则:

如果发送方代理有一个接收方解密性能表,则它应该选择表中的第一个(即优先级最高的)性能。

如果发送方代理没有接收方的解密性能表,但曾经接收到一个或多个来自于接收方的消息,则应该使用与最近接收到的消息一样的加密算法,对将要发送给接收方的消息进行加密。

如果发送方代理没有接收方的任何解密性能方面的知识,并且想冒险一试(接收方可能无法解密消息),则应该选择3DES。

如果发送方代理没有接收方的任何解密性能方面的知识,并且不想冒险,则发送方代理必须使用RC2/40。

如果消息需要发给多个接收方,并且它们没有一个可以接受的、共同的加密算法,则发送方代理需要发送两条消息。此时,该消息的安全性将由于安全性低的一份拷贝而易受到攻击。S/MIME使用符合X.509版本3标准的公开密钥证书。S/MIME使用的密钥管理方法是严格的X.509证明层次和PGP的信任网络的混合。S/MIME的管理者必须为用户配置可信任的密钥表和废除证书的列表。证书是由认证机构签名的。

6.2.4S/MIME证书的处理S/MIME用户可以完成如下密钥管理功能:

①密钥的生成:与管理有关的使用程序的用户必须能够生成单独的Diffie-Hellman和DSS密钥对,并且应该能够生成RSA密钥对。每个密钥对必须从一个好的不确定的随机输入源生成并且采用安全的方式进行保护。用户代理应该生成768~1024位之间的密钥对,并且一定不能生成小于512位的密钥对。

②注册:用户的公开密钥和认证一起注册获得X.509公开密钥证书。

③证书的存储和查询:用户需要访问证书的本地列表来验证进入的签名和输出的报文加密,这张表可以让用户进行维护。X.509是一个重要的标准,基于公开密钥加密和数字签名,这个标准没有专门指定使用的加密算法,但推荐使用RSA。其核心部分是与每个用户联系的公开密钥证书,实际上X.509证书是一种有发布者数字签名的用于绑定某种公开密钥和其持有者身份的数据结构。证书、数字证书、电子证书等都是X.509证书的同义词,有时也称为公钥证书,是一种权威性的电子文档,由具有权威性、可信任性及公正性的第三方机构(CA)颁发。

目前,可以使用三种可选的增强的安全服务来扩展当前的S/MIMEv3安全以及证书处理服务。

1.签名收据

签名收据是一种可选的服务,它考虑的是消息发送的证明。收据为发送者提供了一种向第三方出示证明的手段:接收者不仅收到了消息,而且验证了初始消息的数字签名。最后,接收者对整个消息以及相应的签名进行签名作为接收的证明。该服务仅仅用于签名的数据。6.2.5S/MIME增强的安全服务2.安全标签

安全标签可以通过两种方式来使用。第一种方式,也可能是最容易识别的方式,就是描述数据的敏感级。这可以使用一个分级的标签列表(机密、秘密,限制等)。第二种方式是使用标签来控制授权和访问,描述哪类接收者可以访问数据。

3.安全邮件列表

当S/MIME协议提供它的服务时,发送代理必须为每个接收者创建特定于接收者的数据结构。随着某个特定消息的接收者的数目的增加,这一处理可能会削弱发送消息的性能。这样,邮件列表代理可以接收一个单独的消息并针对每个接收者完成特定于接收者的加密。

通过这两节的学习,可以大致了解PGP和S/MIME这两种保护电子邮件的协议,它们也是目前电子邮件加密的两大主流技术,都沿用IETF的标准,但两者不兼容。PGP采用分布式的认证模式,使用比较方便,适合于公众领域和内部网络用户之间的安全信息交流;而S/MIME则采用基于CA的集中式认证模式,更适合于电子商务、政府机关、公司企业之间等对身份认证要求比较高的领域。PGP保留了用户的个人电子邮件安全服务的选择。国际电子邮件标准管理组织(IMC)希望形成安全邮件的统一标准,但IMC的成员意见并不一致,因此IMC只好同时发展这两种标准,直到大家有了统一的迫切要求时,再考虑统一标准。6.2.6PGP和S/MIME的比较

但从实际应用情况来看,S/MIME几乎是电子邮件厂商的首选协议,许多产品支持S/MIME,它能让用户很容易地发送和接收安全电子邮件。支持S/MIME的产品包括Microsoft的OutlookExpress、NetscapeCommunicator中的Messager邮件程序,Lotus开发的LotusDomino同样支持S/MIME,它还能存储数字证书,Notes客户端可以发送和接收加密或签过名的邮件等。因此S/MIME协议可能作为商业和组织使用的工业标准而出现。

相对来说,支持PGP的电子邮件厂商少一些。但PGP被广大的个人用户所支持和信赖,尤其是它的网状信任模型,具有很大的灵活性和适应性,大大简化了部署操作,因此对许多用户来说仍然具有很大的吸引力。6.3SecureShell

为了克服传统的Telnet、FTP、Rlogin等远程服务存在的各种严重安全缺陷,SSH(SecureShell,安全外壳)协议1995年由TatuYlonen正式提出。2006年,RFC4250~RFC4254一系列文档的推出标志着SSH成为标准化的网络安全协议。SSH是一种应用层的安全通信协议。它通过建立一个加密的、安全的底层通道完成对双方交互数据的保护,通过其认证协议提供的若干种认证方式,增加防止非授权用户登录的能力,并通过连接协议为各种应用层协议提供安全性保护,使得SSH加密的口令及数据可以在不安全的网络中透明地提供强认证和安全通信。相对于Telnet而言,SSH提供的安全性服务主要包括以下几个方面:

①密文传输:在SSH连接建立初期,双方会通过协商的方式得出双方通信的加密算法和会话密钥,此后双方

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论