ssl协商与秘钥交换

一、SSL协商

由于非对称加密的速度比较慢,所以它一般用于密钥交换,双方通过公钥算法协商出一份密钥,然后通过对称加密来通信,当然,为了保证数据的完整性,在加密前要先经过HMAC的处理。

SSL缺省只进行server端的认证,客户端的认证是可选的。以下是其流程图(摘自TLS协议)。

Client                                              Server

ClientHello                  -------->

ServerHello

Certificate*

ServerKeyExchange*

CertificateRequest*

<--------     ServerHelloDone

Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished                      -------->

[ChangeCipherSpec]

<--------      Finished

Application Data

<------->    Application Data

简单的说便是:SSL客户端(也是TCP的客户端)在TCP链接建立之后,发出一个ClientHello来发起握手,这个消息里面包含了自己可实现的算法列表和其它一些需要的消息,SSL的服务器端会回应一个ServerHello,这里面确定了这次通信所需要的算法,然后发过去自己的证书(里面包含了身份和自己的公钥)。Client在收到这个消息后会生成一个秘密消息,用SSL服务器的公钥加密后传过去,SSL服务器端用自己的私钥解密后,会话密钥协商成功,双方可以用同一份会话密钥来通信了。

密钥协商的形象化比喻:

如果上面的说明不够清晰,这里我们用个形象的比喻,我们假设A与B通信,A是SSL客户端,B是SSL服务器端,加密后的消息放在方括号[]里,以突出明文消息的区别。双方的处理动作的说明用圆括号()括起。

A:我想和你安全的通话,我这里的对称加密算法有DES,RC5,密钥交换算法有RSA和DH,摘要算法有MD5和SHA。

B:我们用DES-RSA-SHA这对组合好了。

这是我的证书,里面有我的名字和公钥,你拿去验证一下我的身份(把证书发给A)。

目前没有别的可说的了。

A:(查看证书上B的名字是否无误,并通过手头早已有的CA的证书验证了B的证书的真实性,如果其中一项有误,发出警告并断开连接,这一步保证了B的公钥的真实性)

(产生一份秘密消息,这份秘密消息处理后将用作加密密钥,加密初始化向量和hmac的密钥。将这份秘密消息-协议中称为

per_master_secret-用B的公钥加密,封装成称作ClientKeyExchange的消息。由于用了B的公钥,保证了第三方无法窃听)

我生成了一份秘密消息,并用你的公钥加密了,给你(把ClientKeyExchange发给B)

注意,下面我就要用加密的办法给你发消息了!

(将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥)

[我说完了]

B:(用自己的私钥将ClientKeyExchange中的秘密消息解密出来,然后将秘密消息进行处理,生成加密密钥,加密初始化向量和hmac的密钥,这时双方已经安全的协商出一套加密办法了)

注意,我也要开始用加密的办法给你发消息了!

[我说完了]

A: [我的秘密是...]

B: [其它人不会听到的...]

加密的计算

上一步讲了密钥的协商,但是还没有阐明是如何利用加密密钥,加密初始化向量和hmac的密钥来加密消息的。

其实其过程不过如此:

1 借助hmac的密钥,对明文的消息做安全的摘要处理,然后和明文放到一起。

2 借助加密密钥,加密初始化向量加密上面的消息。

二、秘钥交换

ssl3_send_client_key_exchange是openssl中客户端确定密钥的函数,同时也发送了“一部分”数据给服务器,这一部分数据就是所谓的pre_master,不管是客户端还是服务器都根据对端传过来的pre_master和自己计算出来的另一部分数据来生成最终的对称密钥,生成过程中需要hello消息中的随机数,这样生成的密钥才不会每次都一样。由于ssl协议中dh份额来源于证书,而证书又是静态的,因此十分有必要引入一种随机因素来保证通过静态证书导出的密钥份额协商出来的密钥的随机性。同时这也是pre_master的意义,那就是随机,对于rsa密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥,但是对于dh,包括ecdh算法(不考虑匿名dh和瞬时dh),就只有hello消息中的两个随机数因子了。

pre master的存在在于ssl协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。

迪菲-赫尔曼密钥交换(Diffie–Hellman key exchange,简称“D–H”) 是一种安全协议。

它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道建立起一个密钥。这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容

(1)、算法描述

离散对数的概念:

原根:如果a是素数p的一个原根,那么数值:

amodpa^2modp,…,a^(p-1)modp

是各不相同的整数,且以某种排列方式组成了从1p-1的所有整数。

离散对数:如果对于一个整数b和素数p的一个原根a,可以找到一个唯一的指数i,使得:

b=(a的i次方)modp其中0ip-1

那么指数i称为b的以a为基数的模p的离散对数。

Diffie-Hellman算法的有效性依赖于计算离散对数的难度,其含义是:当已知大素数p和它的一个原根a后,对给定的b,要计算i,被认为是很困难的,而给定i计算b却相对容易。

Diffie-Hellman算法:

假如用户A和用户B希望交换一个密钥。

取素数p和整数aap的一个原根,公开a和p。

A选择随机数XA<p,并计算YA=a^XA mod p。

B选择随机数XB<p,并计算YB=a^XB mod p。

每一方都将X保密而将Y公开让另一方得到。

A计算密钥的方式是:K=(YB) ^XA modp

B计算密钥的方式是:K=(YA) ^XB modp

证明:

(YB)^ XA modp= (a^XB modp)^ XA modp

= (a^XB)^ XA modp= (a^XA) ^XB modp(<-- 密钥即为 a^(XA*XB) modp)

=(a^XA modp)^ XB modp= (YA) ^XB modp

由于XA和XB是保密的,而第三方只有pa、YB、YA可以利用,只有通过取离散对数来确定密钥,但对于大的素数p,计算离散对数是十分困难的。

例子:

假如用户Alice和用户Bob希望交换一个密钥。

取一个素数p=97和97的一个原根a=5。

Alice和Bob分别选择秘密密钥XA=36和XB=58,并计算各自的公开密钥:

YA=a^XA modp=5^36 mod 97=50

YB=a^XB modp=5^58 mod 97=44

Alice和Bob交换了公开密钥之后,计算共享密钥如下:

Alice:K=(YB) ^XA modp=44^36 mod 97=75

Bob:K=(YA) ^XB modp=50^58 mod 97=75

(2)、安全性

当然,为了使这个例子变得安全,必须使用非常大的XA, XB 以及p, 否则可以实验所有的可能取值。(总共有最多97个这样的值, 就算XA和XB很大也无济于事)。

如果p是一个至少 300 位的质数,并且XA和XB至少有100位长, 那么即使使用全人类所有的计算资源和当今最好的算法也不可能从a,p和a^(XA*XB) modp中计算出 XA*XB。

这个问题就是著名的离散对数问题。注意g则不需要很大, 并且在一般的实践中通常是2或者5。

在最初的描述中,迪菲-赫尔曼密钥交换本身并没有提供通讯双方的身份验证服务,因此它很容易受到中间人攻击。

一个中间人在信道的中央进行两次迪菲-赫尔曼密钥交换,一次和Alice另一次和Bob,就能够成功的向Alice假装自己是Bob,反之亦然。

而攻击者可以解密(读取和存储)任何一个人的信息并重新加密信息,然后传递给另一个人。因此通常都需要一个能够验证通讯双方身份的机制来防止这类攻击。

有很多种安全身份验证解决方案使用到了迪菲-赫尔曼密钥交换。例如当Alice和Bob共有一个公钥基础设施时,他们可以将他们的返回密钥进行签名。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,511评论 1 330
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,495评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,595评论 0 225
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,558评论 0 190
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,715评论 3 270
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,672评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,112评论 2 291
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,837评论 0 181
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,417评论 0 228
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,928评论 2 232
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,316评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,773评论 2 234
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,253评论 3 220
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,827评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,440评论 0 180
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,523评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,583评论 2 249

推荐阅读更多精彩内容