【网络安全技术】电子邮件安全PGP,SMIME
一、PGP(Pretty Good Privacy)
PGP是一种邮件加密手段,他在发邮件一方加密,然后发给发送方邮件服务器,发送方邮件服务器再发送给接收方邮件服务器,然后接收方再从接收方邮件服务器pop出来,这整个过程都是pgp加密过的,接收方拿到之后才会解密。
所以整体走的发邮件流程还是先前提到的SMTP那套,只不过在源加了密,在接收方解了密。
1.PGP加密流程
这个流程包括了Authentication 和?Confidentiality,看看他是怎么做的
首先邮件消息哈希之后用A的私钥签名,连接到原来的消息上,这一步做了认证。
然后刚才的消息加签名过压缩。
然后A自己生成一个session key,这个是对称加密,用来加密消息的,他用这个session key加密刚刚压缩完的东西,同时,他也需要把这个session key告诉B啊,他用B的公钥加密session key,然后把他连接到刚才用session key加密过的东西上,这一步提供了机密性。
然后这就是最终加过密的消息了。
所以说整个过程不管是认证还是加密,都是基于双方非对称密钥的安全的,因为如果非对称密钥被妥协了,那么整个流程就不安全了。
在考虑一个问题,压缩的目的是什么,为什么要在加签名之后,加密之前压缩?
首先压缩最根本的是为了减少传输的字节,其次,压缩同时消除了原文的统计特性,减少了被crypto analysis的风险。
在签名之后压缩,是基于签名的意义,那就是对数据完整性提供认证,而如果对压缩过后的信息签名,那虽然也能达到同样的效果,但是丢失了原本的含义。同时我认为这是某种设计理念,但是目前还不是很能理解。
在加密之前压缩,一方面是可以减少加密和解密的时间,另一方面就是刚才说的,如果压缩在加密,黑客拿到的是加密的压缩文件,是没法进行crypto analysis从而进行唯密文攻击的,而如果是先加密再压缩,黑客拿到了压缩的加密文件,那他只要解压缩之后,就可以进行crypto analysis从而进行唯密文攻击了。
还有一个比较扯淡的说法,是说,如果是先压缩再签名,那么接收方就需要存压缩文件来验证签名,尽管我看不出来这有什么问题。他还说,如果想不存压缩文件的话,那就需要解压缩之后再压缩,这更是扯淡,如果先压缩在签名,对称解密完就是签名和压缩文件,直接验证就好了,哪还需要重复压缩。
2.PGP解密
那就是刚才,拿到用公钥加密的session key和加密消息的连接,那就先拿自己的私钥把session key解出来。
然后就可以拿session key解密加密的压缩文件了。
然后再解压缩,拿到签名和原文,用A的公钥解签名,对原文做哈希,比对来验证签名,也就是数据完整性。
3.PGP提供的邮件适应性
因为之前说了,SMTP只传7-bit ASCII码,所以刚才那一套认证、加密走完之后的8-bit octets stream,也就是字节流,要想进SMTP,他需要转换成7-bit ASCII码。
它采用的是Radix-64 algorithm,他把原来的字节流的每6bit,映射成一个Radix-64的ASCII字符,包括26个大写字母(A-Z)、26个小写字母(a-z)、10个数字(0-9),以及两个额外的符号(通常是+
和/
),或者从字节角度理解,就是把每3字节(24bit)映射成4个Radix-64的ASCII字符。
他还增加CRC。
所以看下面整体的PGP发送的格式,从下往上看,数据部分,签名部分,这两部分是对称加密的,然后上面就是对称加密的session key。整体的消息会过一遍64-radix。
这里的两个公钥上面都有一个id,这涉及下面要说的PGP的公钥管理。
4.PGP公钥管理
从上面的PGP流程可以看出,非对称密钥安全是整个加密安全的保障,因为对称密钥也要通过非对称加密来传。
PGP用户没人维护两个表,一个私钥表(Private-key ring)一个公钥表(Public-key ring),私钥表存自己的公私钥对,公钥表存别人的公钥id和公钥。
PGP每个用户可能有多个公私钥对。
私钥表比较好理解,每个entry如下,主要就是这个公私钥对的id,公钥,以及使用passphrase key加密的私钥。
这个passphrase key就相当于是对自己的私钥提供了一层额外的保障,黑客只有同时妥协了passphrase key和私钥表,才能有他的私钥。
公钥表较复杂,
除了key id,公钥,所有者id以外,还有一堆trust什么的,传统的对称密钥通过一个公认的CA签名来确保公钥的合法性,PGP系统里使用这些信任来确定,这里一个一个看。
Owner trust就是我是否相信这个人给别人签的名,当然这里是一个degree。
signature就是某个人给这个公钥签的名,signature trust就是我是否相信这个签名。
key legitimacy是PGP系统算出来的,就是通过所有拥有这个公钥对应签名的人的signature trust来算出来的。
5.总结
总结以上内容,再来看一版完整版的PGP发送和接收流程。
发送的时候,还是先hash,这里签名之前,先要找到私钥,那就是先选择key id,然后去私钥表里找到加密过的私钥,用Passphrase key来解出来私钥,再来签名,签完名再把这个id和签名一起连接到原来的消息上。
然后还是压缩。
然后生成session key,对压缩文件进行加密,之后要用B的公钥加密session key,首先要找到B的公钥,他选择一个B的公钥id,去公钥表里找到B的公钥,加密session key,再把这个公钥id和加密的session key以及加密后的消息连接,这就是最终的发送的东西了。
再来看解密,拿到之后,先拆开,处理session key部分,用这个公钥id去自己的私钥表里找到对应的加密过的私钥,然后用Passphrase key解密出来私钥,再用私钥来解密session key。
有了session key就可以解密了,解出来是压缩文件。
解压缩,出来是签名部分和原文部分。
先处理签名部分,根据这个A的key id,去自己的公钥表里找对应的A的公钥,然后解签名出来一个哈希值,同时自己在对原文做一遍哈希,对比是否一致。
以上就是完整的流程了。
二、SMIME
这个比较简单,和PGP类似,但没有那么复杂的钥匙管理。
发送方就是哈希出来一个消息摘要,私钥签名,然后生成一个content-encryption key,对称加密,AES-128加CBC,然后再用对方的公钥加密这个对称密钥,附上一起传过去。
解密就是先拆出来对称密钥,用自己的私钥解密,然后把用对称密钥解密消息,然后拆出来签名,用对方的公钥验证签名。
公钥管理采用X.509 v3公钥证书。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!