sip加密机制

本文转载自：http://blog.sina.com.cn/s/blog_737adf5301013rb7.html

1、加密和解密

加密系统的组成：

（1）加密前的报文——明文

（2）加密后的报文——密文

（3）加密解密算法

（4）用于加密和解密的钥匙

 

2、关于密钥

要想加密必须使用密钥，他是将信息内容变为内容的工具。它可能是字符串或者数字或者两者的混合。

密码算法分为

（1）对称密码算法：即加密和解密用相同的密钥，如DES算法。

                  优点：算法保密强度高

                  缺点：1）对密钥的传输途径安全性十分苛刻，且要求通信双方都保证不泄露

                        2）如果在网络上有N个用户，为了不被截听，需要使用N(N-1)/2个密钥

                         3）同样因为上述原因，用户密钥不唯一且需要共享，不满足数字签名的唯一和私有

                            性，不能实现数字签名功能

（2）非对称密码算法：加密和解密使用不同的密钥，两者有一定关系但是不能互推，常把用来加密的公开，称之为公钥，把用来解密的独立保存，称之为私钥。这样就可以把公钥放在公开服务器上或者是自己的网页里，他人想给自己发加密信息就通过公共渠道获得公钥加密后发送，自己收到后用私钥解密即可。

 

现在假设网络中有N个人，现在需要两两之间能够加密通信。采用对称加密算法由于每两个人之间需要不同的钥匙对，相当于拓扑中将每两个点之间进行连线。这是正比于N^2。但是非对称算法则不一样，每一个人只需要保证自己的私钥唯一，并知道其余N-1个人的公钥即可。现在可以看出，采用对称加密算法，想要整个系统中的通信加密手段需要N*(N-1)/2，而非对称加密只需要2N，优势非常明显。方便管理和分发。

3、双向HTTP摘要认证：

首先给出传统的HTTP摘要认证

其流程也十分简单，即用户端要求登录，服务端将相关nonce、realm、和用户端共享的密码等值传给客户端发起挑战，用户端使用这些值经函数F运算后得到response发回给服务器端，服务器端对比自己的计算结果然后回复200OK或者再次401挑战。

 

评价：（1）采用这种机制, 使得客户机与服务器的共享密码不以明文形式在网络中发送, 提供了一定程度的认证保密性。
      （2）能提供服务器对客户机的单向认证,但容易遭受服务器伪装攻击( impersonating a server) 。攻击者有可能截获发往服务器的请求,并伪装成该服务器对客户机进行认证, 此时客户机无法察觉。

      （3）认证过于依赖共享密钥。密钥管理方式的选取对认证的可靠性有直接影响。这里的共享密钥的可理解为与服务器共享的密码。

再给出双向HTTP摘要认证

注意这张图片是以Invite为示例的，并且考虑到项目要求在业务鉴权是使用双向鉴权，难道双向鉴权更多用于InviteAuthentication？？但是在项目要求中的单呼组呼都没有涉及到407再鉴权的问题，这个需要咨询项目方的。

假设业务鉴权是指Invite Authentication，则流程如下：

（1）UAC发给代理服务器，或者代理服务器发给UASInvite请求，要求连接。或者是代理服务器向注册服务器发送Register请求，要求更改位置信息。

（2）Server收到请求消息后, 就会发送一个错误的SIP响应消息以表示挑 战信息 challenge_s,challenge_s一般包括作用域 realm _s、随机数 nonce_s、摘要算法H1等。若Server是代理服务器,则该响应消息的状态码为407, 并将挑战信息封装在Proxy Authenticate头域中;若Server是UAS或是注册服务器,则响应消息的状态码为401, 将挑战信息封装在WWW Authenticate头域中。

（3）Client 发送 ACK 请求消息, 表示成功接收到挑战信息。

（4）Client 发送挑战信息challenge_s的响应值response_c和对Server的挑战信息challenge_c。response_c将用户名username、共享密钥passwd、随机数nonce_s、作用域realm_s、自己的公钥v_c按一定规则组合,经H1摘要算法运算后生成;挑战信息challenge_s由v_c、随机数nonce_c、摘要算法H2、自己支持的加密算法和模式等构成。若Server是代理服务器,则 response_c 和 challenge_c 封装在Proxy- Authentication 头域中;若Server是UAS或是注册服务器, 则应将其封装在Authentication头域中。

（5）Server验证响应值response_ c 若对 Client的身份认证合法且同意连接,则先发送状态码为180的响应消息以通知振铃。

（6）Server发送状态码为200 的响应消息,其中包括与第4步类似的方式生成的响应值response_s和由Client的公钥加密的会话密钥和加密方式。信息采用与第2步类似的方式进行封装。

（7）Client 验证响应值response_s,并用自己的私钥对会话密钥信息解密。若对Server身份认证合法且同意采用Server 指定的加密算法和会话密钥进行通信,则发送ACK请求消息。

注：机制中的摘要算法推荐采用256位SHA1, 而不主张MD5算法。

其实总结来看就是在用户回复challenge的时候告知服务器相应信息，这篇文章用了公钥甚至。然后服务器验证成功给响铃，然后回复200OK来回复客户端，客户端验证后ACK。

 

4、其实到现在我们可以到看HTTP摘要认证涉及到的SIP消息头域包括Authorization、Proxy-Authorization、WWW-Authenticate和Proxy-Authenticate。这些认证头域中携带了客户机与服务器的全部认证信息，客户机与服务器把认证头域包含在特定的请求和响应消息中发送给对方，完成认证信息的交互。

 

5、关于nonce值和response的计算

WWW-Authenticate和Proxy-Authenticate里面包含的是服务器向客户机的挑战（challenge），格式可以表示如下：
challenge = "Digest" digest-challenge

字符串“Digest”指出认证类型为摘要认证，“digest-challenge”部分由若干个参数组成。

其中“realm”和“nonce”是必需的参数，其余参数均为可选项。参数nonce的值是一串采用Base64编码的字符串，被客户机用来产生自己的身份凭证，它的计算方法如下：

          time-stamp H(time-stamp ":" ETag ":" private-key)

其中，“time-stamp”是服务器产生的时间戳，可以保证字符串的全局唯一；H是哈希摘要算法，使用MD5；“ETag”是服务器的标识，设置为服务器的域名；“private-key”是服务器知道的一串数据，设置为服务器收到的请求消息中Call-ID 头域里的数值。

 

 

 

Authorization、Proxy-Authorization这两种认证头域中包含的是客户机向服务器出示的身份凭证（credentials），格式可以表示如下：

          credentials = "Digest" digest-response

其中，“digest-response”中也包含 realm、nonce、qop、opaque、algorithm参数，它们的值与WWW-Authenticate 或 Proxy-Authenticate头域中的相应参数相同。其余的参数如下

其中，username、realm、nonce、digest-uri 和 response 是必需的参数，其余参数为可选项
 参数response的值就是客户机通过哈希算法计算得到的摘要（request-digest），服务器通过这个摘要来判断客户机的身份凭证是否有效，它的计算方法如下：
request-digest = <">                                   ":" nc-value
                                  ":" unq(cnonce-value)
                                  ":" unq(qop-value)
                                  ":" H(A2)
                          ) > <">
A1 = unq(username-value) ":" unq(realm-value) ":" passwd
A2 = Method ":" digest-uri-value
KD(secret, data)的意义是把密钥与数据一起计算哈希摘要，即 H(secret":"data)，passwd为用户的口令。

 

------------

这样看来，我们现在还需要做的或者问题如下：

（1）从挑战头域中提取opaque并在身份凭证时候直接加上（也有可能是系统函数自动完成的，比如说realm、nonce、algorithm等）

（2）现实中服务器回带来qop参数，这时候需要cnonce,cnonce是个随机值，怎么计算？长度多少？

（3）nonce-count指的是请求消息中包含该nonce的次数，有>1的情况？？？

（4）双向鉴权的问题在项目要求只提到：业务鉴权使用双向鉴权，具体流程参见RFC2617。通过200OK中的Authentication-Info头域中的rspauth携带用于完成双向鉴权的信息。双向鉴权成功后，DC继续其他操作；若DC对SCC鉴权失败，则DC重新发起注册请求。

这里猜测需要如下操作：本地计算rspauth应该有的值，同样的方法生成nonce值，同样的计算response？？另外需要从200OK的Authentication-Info头域中提取rspauth进行对比。

但是项目要求的实例消息中都没有体现。

（5）关于服务器在qop中的auth（鉴别方式）和auth-int（鉴别完整性保护）：

服务一般回应：qop="auth,auth-int"，应该由客户端选择其一

如果没有给出qop，response的计算式子有影响

auth还是auth-int会影响response A2的组成

（6）关于服务器在algorithm中的MD5和MD5-sess（允许第三方鉴别）会影响A1的组成