游子的博客
慈母手中线,游子身上衣, 临行密密缝,意恐迟迟归, 谁言寸草心,报得三春晖。 数据读取中,请稍候......
posts - 336,  comments - 546,  trackbacks - 0

安全套接层 (SSL) 协议

19808016

常欣

 

一.协议的起源

随着计算机网络技术向整个经济社会各层次延伸,整个社会表现对 Internet Intranet Extranet 等使用的更大的依赖性。随着企业间信息交互的不断增加,任何一种网络应用和增值服务的使用程度将取决于所使用网络的信息安全有无保障,网络安全已成为现代计算机网络应用的最大障碍,也是急需解决的难题之一。

由于 Web 上有时要传输重要或敏感的数据,因此 Netscape 公司在推出 Web 浏览器首版的同时,提出了安全通信协议 SSL(Secure Socket Layer), 目前已有 2.0 3.0 版本。 SSL 采用公开密钥技术。其目标是保证两个应用间通信的保密性和可靠性 , 可在服务器和客户机两端同时实现支持。目前,利用公开密钥技术的 SSL 协议,并已成为 Internet 上保密通讯的工业标准。现行 Web 浏览器普遍将 HTTP SSL 相结合,从而实现安全通信。

二.协议概述

安全套接层协议 (SSL) 是在 Internet 基础上提供的一种保证私密性的安全协议。它能使客户 / 服务器应用之间的通信不被攻击者窃听,并且始终对服务器进行认证,还可选择对客户进行认证。 SSL 协议要求建立在可靠的传输层协议 ( 例如: TCP) 之上。 SSL 协议的优势在于它是与应用层协议独立无关的。高层的应用层协议 ( 例如: HTTP FTP TELNET 。。。。。。 ) 能透明的建立于 SSL 协议之上。 SSL 协议在应用层协议通信之前就已经完成加密算法、通信密钥的协商以及服务器认证工作。在此之后应用层协议所传送的数据都会被加密,从而保证通信的私密性。

通过以上叙述, SSL 协议提供的安全信道有以下三个特性:

?        私密性。因为在握手协议定义了会话密钥后,所有的消息都被加密。

?        确认性。因为尽管会话的客户端认证是可选的,但是服务器端始终是被认证的。

?        可靠性。因为传送的消息包括消息完整性检查 ( 使用 MAC)

 

三.协议规范

SSL 协议由 SSL 记录协议和 SSL 握手协议两部分组成。

1.         SSL 记录协议:

SSL 协议中,所有的传输数据都被封装在记录中。记录是由记录头和长度不为 0 的记录数据组成的。所有的 SSL 通信包括握手消息、安全空白记录和应用数据都使用 SSL 记录层。 SSL 记录协议包括了记录头和记录数据格式的规定。

1)        SSL 记录头格式:

SSL 的记录头可以是两个或三个字节长的编码。 SSL 记录头的包含的信息包括:记录头的长度、记录数据的长度、记录数据中是否有粘贴数据。其中粘贴数据是在使用块加密算法时,填充实际数据,使其长度恰好是块的整数倍。最高位为 1 时,不含有粘贴数据,记录头的长度为两个字节,记录数据的最大长度为 32767 个字节;最高位为 0 时,含有粘贴数据,记录头的长度为三个字节,记录数据的最大长度为 16383 个字节。

当数据头长度是三个字节时,次高位有特殊的含义。次高位为 1 时,标识所传输的记录是普通的数据记录;次高位为 0 时,标识所传输的记录是安全空白记录 ( 被保留用于将来协议的扩展)。

记录头中数据长度编码不包括数据头所占用的字节长度。记录头长度为两个字节的记录长度的计算公式:记录长度= ((byte[0] & 0x7f) << 8)) | byte[1] 。其中 byte[0] byte[1] 分别表示传输的第一个、第二个字节。记录头长度为三个字节的记录长度的计算公式:记录长度= ((byte[0] & 0x3f) << 8)) | byte[1] 。其中 byte[0] byte[1] 的含义同上。判断是否是安全空白记录的计算公式: (byte[0] & 0x40) != 0 。粘贴数据的长度为传输的第三个字节。

2)        SSL 记录数据的格式:

SSL 的记录数据包含三个部分: MAC 数据、实际数据和粘贴数据。

MAC 数据用于数据完整性检查。计算 MAC 所用的散列函数由握手协议中的 CIPHER CHOICE 消息确定。若使用 MD2 MD5 算法,则 MAC 数据长度是 16 个字节。 MAC 的计算公式: MAC 数据= HASH[ 密钥,实际数据,粘贴数据,序号 ] 。当会话的客户端发送数据时,密钥是客户的写密钥 ( 服务器用读密钥来验证 MAC 数据 ) ;而当会话的客户端接收数据时,密钥是客户的读密钥 ( 服务器用写密钥来产生 MAC 数据 ) 。序号是一个可以被发送和接收双方递增的计数器。每个通信方向都会建立一对计数器,分别被发送者和接收者拥有。计数器有 32 位,计数值循环使用,每发送一个记录计数值递增一次,序号的初始值为 0

 

2.         SSL 握手协议:

SSL 握手协议包含两个阶段,第一个阶段用于建立私密性通信信道,第二个阶段用于客户认证。

1)        第一阶段:

第一阶段是通信的初始化阶段,通信双方都发出 HELLO 消息。当双方都接收到 HELLO 消息时,就有足够的信息确定是否需要一个新的密钥。若不需要新的密钥,双方立即进入握手协议的第二阶段。否则,此时服务器方的 SERVER HELLO 消息将包含足够的信息使客户方产生一个新的密钥。这些信息包括服务器所持有的证书、加密规约和连接标识。若密钥产生成功,客户方发出 CLIENT MASTER KEY 消息,否则发出错误消息。最终当密钥确定以后,服务器方向客户方发出 SERVER VERIFY 消息。因为只有拥有合适的公钥的服务器才能解开密钥。下图为第一阶段的流程:

客户方

发出 CLIENT HELLO 消息

需要新密钥?

Y

产生新的密钥

发出 CLIENT MASTER KEY 消息

等待 SERVER HELLO 消息

等待 SERVER VERIFY 消息

第二阶段

N

服务器方

等待 CLIENT HELLO 消息

 

发出 SEVER HELLO 消息

需要新密钥?

等待 CLIENT MASTER KEY 消息

解开密钥

发出 SERVER VERIFY 消息

第二阶段

Y

N

 


需要注意的一点是每一通信方向上都需要一对密钥,所以一个连接需要四个密钥,分别为客户方的读密钥、客户方的写密钥、服务器方的读密钥、服务器方的写密钥。

2)        第二阶段:

第二阶段的主要任务是对客户进行认证,此时服务器已经被认证了。服务器方向客户发出认证请求消息: REQUEST CERTIFICATE 。当客户收到服务器方的认证请求消息,发出自己的证书,并且监听对方回送的认证结果。而当服务器收到客户的认证,认证成功返回 SERVER FINISH 消息,否则返回错误消息。到此为止,握手协议全部结束。

 

3.         典型的协议消息流程:

消息名

方向

内容

不需要新密钥

CLIENT HELLO

C >S

challenge, session_id, cipher_specs

SERVER HELLO

S >C

connection-id, session_id_hit

CLIENT FINISH

C >S

E client_write_key [connection-id]

SERVER-VERIFY

S >C

E server_write_key [challenge]

SERVER FINISH

S >C

E server_write_key[ session_id]

需要新密钥

CLIENT HELLO

C >S

challenge, cipher_specs

SERVER HELLO

S >C

connection-id,server_certificate,cipher_specs

CLIENT MASTER KEY

C >S

E server_public_key[ master_key]

CLIENT FINISH

C >S

E client_write_key[ connection-id]

SERVER VERIFY

S >C

E server_write_key[ challenge]

SERVER FINISH

S >C

E server_write_key[ new_session_id]

需要客户认证

CLIENT HELLO

C >S

challenge, session_id, cipher_specs

SERVER HELLO

S >C

connection-id, session_id_hit

CLIENT FINISH

C >S

E client_write_key [connection-id]

SERVER-VERIFY

S >C

E server_write_key [challenge]

REQUEST CERTIFICATE

S >C

E server_write_key[ auth_type,challenge']

CLIENT CERTIFICATE

C >S

E client_write_key[ cert_type,client_cert,response_data]

SERVER FINISH

S >C

E server_write_key[ session_id]

 

四.相关技术:

1.         加密算法和会话密钥:

如前所述,加密算法和会话密钥是在握手协议中协商并有 CIPHER CHOICE 指定的。现有的 SSL 版本中所用到的加密算法包括: RC4 RC2 IDEA DES ,而加密算法所用的密钥由消息散列函数 MD5 产生。 RC4 RC2 是由 RSA 定义的,其中 RC2 适用于块加密, RC4 适用于流加密。下述为 CIPHER CHIOCE 的可能取值和会话密钥的计算:

SSL_CK_RC4_128_WITH_MD5

SSL_CK_RC4_128_EXPORT40_WITH_MD5

SSL_CK_RC2_128_CBC_WITH_MD5

SSL_CK_RC2_128_CBC_EXPORT40_WITH_MD5

SSL_CK_IDEA_128_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]

KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY = KEY-MATERIAL-0[0-15]

CLIENT-WRITE-KEY = KEY-MATERIAL-1[0-15]

SSL_CK_DES_64_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY = KEY-MATERIAL-0[0-7]

CLIENT-WRITE-KEY = KEY-MATERIAL-0[8-15]

SSL_CK_DES_192_EDE3_CBC_WITH_MD5

KEY-MATERIAL-0 = MD5[ MASTER-KEY, "0", CHALLENGE, CONNECTION-ID ]

KEY-MATERIAL-1 = MD5[ MASTER-KEY, "1", CHALLENGE, CONNECTION-ID ]

KEY-MATERIAL-2 = MD5[ MASTER-KEY, "2", CHALLENGE, CONNECTION-ID ]

CLIENT-READ-KEY-0 = KEY-MATERIAL-0[0-7]

CLIENT-READ-KEY-1 = KEY-MATERIAL-0[8-15]

CLIENT-READ-KEY-2 = KEY-MATERIAL-1[0-7]

CLIENT-WRITE-KEY-0 = KEY-MATERIAL-1[8-15]

CLIENT-WRITE-KEY-1 = KEY-MATERIAL-2[0-7]

CLIENT-WRITE-KEY-2 = KEY-MATERIAL-2[8-15]

其中 KEY-MATERIAL-0[0-15] 表示 KEY-MATERIAL-0 中的 16 个字节, KEY-MATERIAL-0[0-7] 表示 KEY-MATERIAL-0 中的头 8 个字节, KEY-MATERIAL-1[8-15] 表示 KEY-MATERIAL-0 中的第 9 个字节到第 15 个字节。其他类似形式有相同的含义。 "0" "1" 表示数字 0 1 ASCII 0x30 0x31

 

2.         认证算法:

认证算法采用 X 509 电子证书标准,通过使用 RSA 算法进行数字签名来实现的。

1)        服务器的认证:

在上述的两对密钥中,服务器方的写密钥和客户方的读密钥、客户方的写密钥和服务器方的读密钥分别是一对私有、公有密钥。对服务器进行认证时,只有用正确的服务器方写密钥加密 CLIENT-HELLO 消息形成的数字签名才能被客户正确的解密,从而验证服务器的身分。

若通信双方不需要新的密钥,则它们各自所拥有的密钥已经符合上述条件。若通信双方需要新的密钥。首先服务器方在 SERVER-HELLO 消息中的服务器证书中提供了服务器的公有密钥,服务器用其私有密钥才能正确的解密由客户方使用服务器的公有密钥加密的 MASTER-KEY ,从而获得服务器方的读密钥和写密钥。

2)        客户的认证:

同上,只有用正确的客户方写密钥加密的内容才能被服务器方用其读密钥正确的解开。当客户收到服务器方发出的 REQUEST-CERTIFICATE 消息时,客户首先使用 MD5 消息散列函数获得服务器方信息的摘要,服务器方的信息包括: KEY-MATERIAL-0 KEY-MATERIAL-1 KEY-MATERIAL-2 CERTIFICATE-CHALLENAGE-DATA( 来自于 REQUEST-CERTIFICATE 消息 ) 、服务器所赋予的证书 ( 来自于 SERVER-HELLO) 消息。其中 KEY-MATERIAL-1 KEY-MATERIAL-2 是可选的,与具体的加密算法有关。然后客户使用自己的读密钥加密摘要形成数字签名,从而被服务器认证。

 

五.与 SET 协议的比较

在当今的电子商务中使用最为广泛的两种安全协议是 SSL 协议和 SET 协议。以下就两种协议在电子商务方面的应用作一比较。

1.         SET 协议概述:

SET 协议 (Secure Electronic Transaction ,安全电子交易 ) 是由 VISA MasterCard 两大信用卡公司于 1997 5 月联合推出的规范。 SET 主要是为了解决用户、商家和银行之间通过信用卡支付的交易而设计的,以保证支付信息的机密、支付过程的完整、商户及持卡人的合法身份、以及可操作性。 SET 中的核心技术主要有公开密匙加密、电子数字签名、电子信封、电子安全证书等。 SET 能在电子交易环节上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺诈的可能性。 SET 协议用以支持 B to C Businessto Consumer )这种类型的电子商务模式,即消费者持卡在网上购物与交易的模式。 SET 交易分三个阶段进行 :

?        在购买请求阶段,用户与商家确定所用支付方式的细节;

?        在支付的认定阶段,商家会与银行核实 , 随着交易的进展,他们将得到付款;

?        在受款阶段,商家向银行出示所有交易的细节,然后银行以适当方式转移货款。

如果不是使用借记卡,而直接支付现金,商家在第二阶段完成以后的任何时间即可以供货支付。第三阶段将紧接着第二阶段进行。用户只和第一阶段交易有关,银行与第二、三阶段有关,而商家与三个阶段都要发生关系。每个阶段都涉及到 RSA 对数据加密,以及 RSA 数字签名。使用 SET 协议,在一次交易中,要完成多次加密与解密操作,故要求商家的服务器有很高的处理能力。

 

2.         协议比较:

事实上, SET SSL 除了都采用 RSA 公钥算法以外,二者在其他技术方面没有任何相似之处。而 RSA 在二者中也被用来实现不同的安全目标。

SET 协议比 SSL 协议复杂,因为 SET 不仅加密两个端点间的单个会话,它还非常详细而准确地反映了卡交易各方之间存在的各种关系。 SET 还定义了加密信息的格式和完成一笔卡支付交易过程中各方传输信息的规则。事实上, SET 远远不止是一个技术方面的协议,它还说明了每一方所持有的数字证书的合法含义,希望得到数字证书以及响应信息的各方应有的动作,与一笔交易紧密相关的责任分担。 SET 实现起来非常复杂,商家和银行都需要改造系统以实现互操作。另外 SET 协议需要认证中心的支持。

SET 是一个多方的报文协议,它定义了银行、商家、持卡人之间的必须的报文规范,与此同时 SSL 只是简单地在两方之间建立了一条安全连接。 SSL 是面向连接的,而 SET 允许各方之间的报文交换不是实时的。 SET 报文能够在银行内部网或者其他网络上传输,而 SSL 之上的卡支付系统只能与 Web 浏览器捆绑在一起。

两者相比最不安全的可以说是 SSL ,实际上当初它并不是为支持电子商务而设计的,后来为了克服其局限性在其基础上发展了 PKI 。然而就当初的设计目的而言, SSL 和它的继任者 — — 传输层安全协议( the transport layer security protocol )的功能完成的非常圆满。很多银行和电子商务解决方案提供商还在谈论着使用 SSL 构建更多的安全支付系统,但是如果没有经裁剪的客户方软件的话,基于 SSL 的系统是不能到像 SET 这种专用银行卡支付协议所能达到的安全性的。

 

六.前景展望

就我个人观点来说, SSL 协议与 SET 协议之争类似于 IP ATM 之争。 IP 协议的应用非常广泛,实现简单成本低廉,但服务质量没有保证。 ATM 实现复杂,需要对现有的设备和应用进行改造,成本高昂,但对服务质量有保证。结果是 ATM 迟迟不能推出成熟的规范, IP 设备迅速抢占市场。随着应用需求的增加和扩展,对服务质量要求的呼声也日益高涨。这时 CISCO 等厂商也提出 IP 上的 QoS ,并且通过扩展 IP 协议实现对 QoS 的支持。所以评价一种技术的前景,最重要的就是这种技术能不能在现有的条件下占有市场。至于这种技术是不是先进、是不是有好的扩展性等等相对来说处于次要地位。从已有的应用份额、实现成本、技术支持等影响市场占有率的最重要的因素来看, SSL 协议已经占据了有利的形势。我对 SSL 协议的发展充满乐观。

 

参考文献:

1. Netscape Communication Corp Kipp E.B. Hickman The SSL Protocol. Feb, 9th, 1995

2. CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988.

3. RSA Laboratories. PKCS #1: RSA Encryption Standard, Version 1.5, November 1993.

4. R. Rivest. RFC 1321: The MD5 Message Digest Algorithm. April 1992.

5. 陆首群 : 剖析 SET. 1998

 

posted on 2006-12-26 17:37 游子 阅读(1299) 评论(0)  编辑 收藏 引用 所属分类: 软件
只有注册用户登录后才能发表评论。

欢迎大家扔鸡蛋!送鲜花!

博客可以收入过千吗?

<2006年12月>
日一二三四五六26272829301234567
8910111213141516171819202122232425262728293031123456

常用链接

留言簿(8)

随笔分类(313)

随笔档案(336)

文章分类(7)

文章档案(10)

相册

收藏夹(1)

其它

友情链接

数字电视

生活、旅游

自己的链接

计算机

搜索

  •  

积分与排名

  • 积分 - 340758
  • 排名 - 9

最新评论

阅读排行榜

评论排行榜