【网络安全技术】电子邮件安全PGP,SMIME

2023-12-13 14:59:57

一、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公钥证书。

文章来源:https://blog.csdn.net/TheSysy/article/details/134968718
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。